Systems and methods for remote ownership and content control of media files on untrusted systems

Abstract

One exemplary method includes receiving, by a client computing device, a request to open a superfile stored on a memory device at the client computing device, the superfile including encrypted content and the request including user credential information; communicating, by the client computing device in response to receiving the request to open the superfile, a request to a remote server to access the superfile, the request including credentials associated with a user account; receiving cryptographic information from the remote server; decrypting the encrypted content using the cryptographic information; accessing and presenting the decrypted content; and maintaining communication with the remote server while the decrypted content is being accessed.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 056,288, filed July 24, 2020, entitled "A New Computer File Type That Is Trackable, Analyzable, Has the Ability to Change Access at Any Time, Allows the Owner of the File to Update It, Which in turn Updates the File for Everyone Who Has the File," which is incorporated herein by reference in its entirety.

[0002]

[0002] The present invention relates generally to remotely controlling access to media content, and more particularly to a system and method for remote ownership and content control of media files on untrusted systems. [Background technology]

[0003]

[0003] Computing systems can store data in a variety of ways. One common way to store data is in a file on a non-volatile memory device such as a hard drive. Data in such a file may be accessed by different applications executed by the computing system, and the file may be copied to other storage devices. Summary of the Invention

[0004]

[0004] Various examples of systems and methods for remote ownership and content control of media files on untrusted systems are described. One exemplary method includes receiving, by a client computing device, a request to open a superfile stored on a memory device at the client computing device, the superfile including encrypted content, the request including user credential information; communicating, by the client computing device in response to receiving the request to open the superfile, a request to a remote server to access the superfile, the request including credentials associated with a user account; receiving cryptographic information from the remote server; decrypting the encrypted content using the cryptographic information; accessing and presenting the decrypted content; and maintaining communication with the remote server while the decrypted content is being accessed.

[0005]

[0005] Another exemplary method includes receiving a request from a remote client device to access encrypted content in a superfile, the request including user credential information, and the superfile is stored in a memory device of the remote client device and includes the encrypted content; determining an authorization level for accessing the encrypted content; providing cryptographic information to the remote client device in response to determining the authorization level; and receiving and storing usage information from the remote client device associated with the encrypted content while the superfile is open on the remote client device.

[0006]

[0006] Another exemplary method includes receiving, from a remote client device, an instruction to create a new superfile; creating one or more records in a data store associated with the new superfile; storing one or more encryption keys in the one or more records, wherein one of the one or more keys is used to encrypt content in the superfile; and receiving and storing a copy of the superfile.

[0007] These illustrative examples are mentioned not to limit or define the scope of the present disclosure, but rather to provide examples to aid in understanding thereof. Illustrative examples are described in the Detailed Description section, which provides further explanation. Advantages offered by the various examples may be further understood by examining this specification.

[0008]

[0008] 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 implementations of the particular examples. [Brief explanation of the drawings]

[0009] [Figure 1] 1 illustrates an exemplary system for remote ownership and content control of media files on an untrusted system. [Figure 2] 1 shows an exemplary structure of a superfile. [Figure 3] 1 illustrates an exemplary system for remote ownership and content control of media files on an untrusted system. [Figure 4] 1 illustrates an exemplary sequence diagram of a process for remote ownership and content control of media files on an untrusted system. [Figure 5] 1 illustrates an exemplary method for remote ownership and content control of media files on an untrusted system. [Figure 6]1 illustrates an exemplary method for remote ownership and content control of media files on an untrusted system. [Figure 7] 1 illustrates an exemplary method for remote ownership and content control of media files on an untrusted system. [Figure 8] 1 illustrates an exemplary method for remote ownership and content control of media files on an untrusted system. [Figure 9] 1 illustrates an exemplary computing device suitable for use with an exemplary system and method for remote ownership and content control of media files on an untrusted system. DETAILED DESCRIPTION OF THE INVENTION

[0010]

[0015] Examples are described herein in the context of systems and methods for remote ownership and content control of media files on untrusted systems. Those skilled in the art will understand that the following description is exemplary only and is not intended to be limiting in any way. Reference will now be made in detail to example implementations that are illustrated in the accompanying drawings. The same reference numerals are used throughout the drawings and the following description to refer to the same or similar items.

[0011]

[0016] For clarity, not all of the routine features of the examples described herein are shown and described, and it will, of course, be understood that in developing any such actual implementation, many implementation-specific decisions must be made to achieve the developer's particular goals, such as compliance with application and business-related constraints, and that these particular goals will vary from implementation to implementation and from developer to developer.

[0012]

[0017] 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, computer files offer few features that allow the owner of the content contained within the file to exercise control over that content. While some applications allow users to password-protect or otherwise lock files from editing, such features apply to the file, and once the file is distributed to another person, the owner has no ability to subsequently change these restrictions except by providing the necessary password or by providing an alternative copy of the file that is not locked from editing.

[0013]

[0018] Alternatively, computer files can be stored and shared via online platforms, such as cloud services, allowing different users to access the files on the platform, such as to view or edit them. However, control over these files is provided by the platform itself and is not an inherent feature of files stored on the platform. Thus, sharing of files is limited to sharing a reference to where the file is stored and interacting with the platform, which retains control over the file. While this configuration can offer certain advantages, it requires that all users access the same copy of the file, with access mediated by the platform.

[0014]

[0019] To enable content creators to widely distribute content as individual files, the individual files can be copied or shared like traditional files, and users can store the content in a file structure called a "superfile," which contains both the content (video, audio, text, spreadsheet, etc.) created by the file's author and information that allows a computing device or client device to communicate with a remote server to gain access to the content of the superfile or to provide information regarding use of the file's content and any restrictions imposed on the user.

[0015]

[0020] An example superfile includes a header portion and a content portion, where the content is encrypted but the header is not. The content portion contains content generated by the file's creator or editor. In contrast, the header portion contains information that allows a user's client device to request cryptographic information to decrypt and access the superfile's content.

[0016]

[0021] When a user attempts to open a superfile, the operating system detects the file type as a superfile, for example, by detecting the file extension .super (e.g., movie.super), and accesses the header portion of the superfile. From the header, the operating system extracts information identifying the server computer(s), which can be encoded as a universal resource identifier ("URI"), such as a universal resource locator ("URL"), and an identifier for the superfile, such as a file ID and a cryptographic hash value. The operating system then contacts the server using the URL and provides the file ID and hash value, as well as user credential information.

[0017]

[0022] The server receives the file ID and hash value and verifies that the two 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, so the server can access the blockchain corresponding to the file ID and verify whether the hash value received from the client computer matches the hash value stored on the blockchain. If the two match, the server verifies that the blockchain corresponds to the identified superfile and that the superfile is authentic.

[0018]

[0023] After identifying the corresponding record in the superfile's blockchain, the server determines whether the supplied user credentials are accepted. For example, the user may have a user account with the superfile server. Thus, the user credentials may be the user's username and password, or some other verifiable information for establishing the user's identity, such as a cryptographic signature. The server can then verify the user's identity and access the blockchain record to determine whether the user has access to the file, or a separate data store containing such information.

[0019]

[0024] After receiving the decryption key, the client device maintains a connection to the superfile server and, while also deleting the decryption key, decrypts the contents of the file in memory and presents it to the user. While the client device has the superfile open, the client device can send information to the superfile server, such as which portion of the content is being viewed, how long the file has been open, how much idle time has been detected, and whether the user is attempting to copy or edit the content. The superfile server can store the received information in a data store record corresponding to the superfile's blockchain record. When the user then closes the superfile, the user's computer deletes the decryption key and stops presenting the superfile's contents.

[0020]

[0025] While this example provides a simple example of a user accessing a superfile, one advantage of a superfile is that the owner of the superfile 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 currently open on the user's computer. For example, if the owner of the superfile edits text within a superfile document, those edits are sent to the superfile server, which then provides them to each copy of the file currently open on other client computers. These other client computers thus receive the edited content, both updating the content of the superfile itself but also dynamically changing the displayed and decoded content that can be viewed by users. Thus, users see updates in near real time as the updates are made by the file owner. When one of the viewing users closes the superfile, the changes received up to that point are stored in their copy of the superfile. Users who were not viewing the superfile but access it later are immediately provided with the updated content, such as when access to the superfile is authorized. Thus, a superfile provides a way for users to use a superfile as any conventional file and receive (or provide) updates in near real time.

[0021]

[0026] Similarly, the owner of a superfile can change the access restrictions on the contents of the superfile, which can then be propagated in near real time to any other copies of the file currently open at that time. For example, if the owner revokes a user's access while the user has a superfile open, the superfile server will send a message to the client computer causing it to immediately stop providing the decrypted content to the user by overwriting the memory containing the decrypted content, so that the content is no longer accessible by the user. A notification may also be provided that the user's access rights have been revoked by the owner.

[0022]

[0027] Using superfiles, content creators can allow anyone to freely copy their copyrighted work while maintaining control over access to their work. Furthermore, usage information collected by superfile servers allows users to monitor their engagement with their content, allowing them to monetize it directly, for example, by selling access to the content, or indirectly, for example, by selling advertising associated with the content. Furthermore, by employing blockchain as a mechanism for recording information about superfiles, the authenticity and chain of ownership of the superfile can be verified by accessing the blockchain.

[0023]

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

[0024]

[0029] Referring now to Figure 1, Figure 1 illustrates an exemplary system for remote ownership and content control of media files on an untrusted system. The exemplary system includes an author device 130 and several client devices 120a-n that can communicate with a super file server 110 via one or more communications networks 140. Each of these computing devices 110, 120a-n, 130 includes a corresponding data store 112, 122a-n, 132, where each computing device can persistently store and access one or more data files.

[0025]

[0030] Each user of client device 120a-n or creator device 130 can use their respective device to do any number of different things, such as creating or viewing creative content. Such 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 that content with other users by providing copies of the associated files, with or without the creator's knowledge. The recipient can then access the files, view the content, and in some cases edit the content. However, once the recipient receives a copy of the file, the recipient has a self-contained electronic package containing the entire content, which the recipient can then access and use as they wish.

[0026]

[0031] In the illustrated exemplary system 100, each of the client devices 120a-n is operated by one or more users and is generally referred to as an "untrusted" client with respect to the creator device 130. "Untrusted" in this sense refers to a device operated by an autonomous user independent of the creator's control. That is, the creator has no way to access the user's client devices 120a-n, such as to prevent actions that another user may take with respect to the content. Furthermore, without using such an exemplary system 100, the creator has no ability to establish content authorship or track the use of their data files by other users.

[0027]

[0032] To allow creators to maintain control over their content, creators can store the content as part of a superfile. A superfile is a type of file that includes the ability to request permission from a superfile server to access the file's content. However, in addition to permission to initially open the file and access its content, a superfile requires ongoing communication with the superfile server to ensure that permission to access the file content is not changed or revoked and to track user usage of the file content.

[0028]

[0033] When a user receives a superfile, they receive the entire superfile, which appears to be a normal file. That is, the receiving user (or "recipient") owns the entire file and its contents, not just a portion of a file residing on a remote computer. In some instances, a superfile may be identified as such by a filename extension (e.g., .super), but in some instances, a superfile may not have a file extension or a particular file extension.

[0029]

[0034] To access the file, a user can attempt to open the file using a client device, such as client device 120a, like any other file, for example, by using a mouse to select and double-click the file icon of the superfile. An operating system (“OS”) executed by the recipient's client device can detect the file-open command based on user input and determine that 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). Upon determining that the file is a superfile, the OS may first attempt to open the file normally or may launch an application installed on the recipient's 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.

[0030]

[0035] To open a file, the OS or an application (both referred to as "application") attempts to contact a super file server, e.g., super file server 110. To do so, the application may issue a DNS request to obtain a network address for a pre-configured server name, e.g., files.superfile.org. The DNS response provides a network address, e.g., an Internet Protocol ("IP") address, which the application then uses to contact super file server 110. The application may also attempt to authenticate the identified server, e.g., via a trusted authentication authority, before or during establishing communication with server 110.

[0031]

[0036] 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 send the information necessary to decrypt or decompress the content of the superfile. After receiving the information, the application uses the information to decrypt or decompress the content, after which the application itself may present the content or may execute a separate application to present the content. In this exemplary system, once the content is decrypted, it is simply decrypted to volatile system memory to enable presentation to the user. No decrypted copy of the superfile is made. This can help ensure the security of the superfile's content in the event access is changed or revoked.

[0032]

[0037] While the content is being presented to the user (commonly referred to as the superfile remaining "open"), the application maintains communication with the superfile server and sends usage information to the server, such as how long the user has the file open, what portions of the content are being viewed or presented, etc. The superfile server 110 can store such information in its data store 112 and associate it with the record corresponding to the superfile.

[0033]

[0038] 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 deleting information needed to decrypt or decompress the content (if not already deleted), deleting or overwriting any information from the superfile content that was copied to memory to enable presentation of the content, closing any separate applications used to view the content, etc. In some examples, the application can wait a predetermined period (e.g., 5 or 10 minutes) before terminating access to mitigate problems associated with intermittent network failures. If communication with the superfile server is resumed, access may be restored, terminated, or the predetermined period may be reset.

[0034]

[0039] When a user attempts to access a superfile, the user may be granted access according to the permissions established by the creator of the content in the superfile. For example, the creator may have "owner" access to the file, which allows the creator to freely edit or delete the content, change permissions for different users, and transfer ownership of the content to another user. Other users may have "viewer" access, which allows the user to view the content but not edit it. Some users may have "editor" access, which allows them to edit the content but not perform ownership functions. Yet other types of permissions may be established that allow other users to view the content, such as by allowing them to edit the content but not perform ownership functions.

[0035]

[0040] Different permission levels for each file may be maintained by one or more superfile servers, e.g., superfile server 110. Thus, 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.). The permission level can affect the user's ability to make or save changes to the content within the superfile. For example, a user may open a document saved as a superfile and only have "viewer" permission to the content. To prevent a user from editing a file, an operating system or an application, such as an editing application (e.g., a word processing application), may open the file as "read-only" to prevent the user from editing the content of the superfile.

[0036]

[0041] Because superfiles can be freely distributed, any number of copies of a particular superfile may be in circulation and open simultaneously. Thus, a user of one client device, say client device 120a, may have a copy of the superfile open, while a user of another client device 120b may also have a copy of the superfile open. Both client devices 120a,b communicate with superfile server 110, generally as described above.

[0037]

[0042] As a result of client devices 120a, b maintaining communication with the superfile server 110, any updates made to the contents of the superfile, for example, by the owner or “editor,” can be immediately propagated to any client devices 120a, b that have a copy of the superfile opened by the superfile server. Client devices that do not have a copy of the superfile open instead receive the updated content the next time the superfile is opened. Similarly, if user permissions are changed, the updated permissions are immediately propagated to affected users who have the superfile open. For example, if a user has “editor” permissions and is changed to “viewer” permissions while the file is open, that client device receives the changed permissions from the superfile server 110 and prevents any changes from being saved to the superfile. In some cases, editor changes made while the superfile was open before the permission change are rolled back (returned to its previous state), while in other cases, only editing prohibition is intended. Furthermore, if a user's permission to access the file is revoked, for example, by closing the superfile and discarding the cryptographic information used to access the content, the contents of the superfile are immediately made inaccessible. In some instances, the superfile may remain open, but the content is no longer presented, and instead an indication that the permissions have changed is displayed.

[0038]

[0043] It should be understood that because client devices 120a-n are not under the control of superfile server 110, superfile server 110 itself cannot guarantee that a user has not tampered with one or more applications executed by the client device to enable functionality that would otherwise be prohibited. However, even if a user attempts to illicitly modify the contents of a superfile, the modification is detectable by superfile server 110 or another untampered client device 120a-n. As described above, a user with “editor” permissions can modify the contents of a superfile, which is then propagated to superfile server 110 and then to other users who have copies of the superfile. However, if a user tampers with a superfile to modify its contents, superfile server 110 will deny the modification based on the permissions maintained by superfile server 110. Thus, a user can modify their own copy of the superfile, but it will not be disseminated to others via superfile server 110. Alternatively, a user can tamper with the contents of a superfile and attempt to distribute the file to another user (the “recipient” in this example), for example, via email.

[0039]

[0044] When recipients attempt to access the tampered superfile, their client devices can contact the superfile server 110 as described above and present a message indicating that the file's contents differ from the superfile's current known state. In some examples, the superfile server 110 can instead detect the file content differences between the user's copy of the superfile and the superfile's current known state and then send the correct file content to the user to replace the contents of the user's copy. Still other exemplary actions can be taken, such as presenting the user with an error indicating that the file contents have been tampered with.

[0040]

[0045] The functionality enabled by the exemplary system 100 is based in part on the structure of a superfile (described below), the use of a superfile server 110, and, in some examples, a blockchain network.

[0041]

[0046] Referring to Figure 2, Figure 2 shows an exemplary file structure of a superfile 200. The superfile 200 in this example includes a header 210 and a content payload 220. The content payload 220 includes any type of content created by an author. Examples of suitable content include literary works (e.g., articles, books, manuscripts, etc.), audio or visual works (e.g., music, videos, images, etc.), technical information (e.g., 3D printer blueprints, computer-aided design or manufacturing files, etc.), etc. In some cases, the content payload 220 may include another superfile.

[0042]

[0047] To protect the contents of the superfile from unauthorized access, in some examples, the content payload 220 may be encrypted, compressed, or both. Any suitable encryption technique may be used, according to different examples, such as symmetric key encryption, such as the Advanced Encryption Standard (AES) family of encryption techniques, such as AES-256, or asymmetric key encryption. In addition to (or instead of) encryption, compression techniques (such as LZ compression) may be used to reduce the size of the content payload 220. For content payloads 220 that do not contain confidential information, such as user manuals or resumes, compression may be sufficient, but for other types of information, encryption may be desirable. However, the creator of the superfile may choose whether encryption or compression is used, and if so, the type used. Furthermore, the creator (or another user with sufficient permissions) can change or remove (or reapply) encryption or compression from the superfile at any time.

[0043]

[0048] The superfile header 210 includes information identifying the file as a superfile, a unique identifier for the superfile, information indicating the type of encryption or compression applied to the content payload 220, a checksum or hash value for the content payload 220, etc. It may also include specific bibliographic information such as the creator of the superfile, the creation date of the superfile, a checksum or hash value of the bibliographic information, and a checksum or hash value of the entire superfile 220 . In general, the superfile header 210 can include any information about the superfile that may be desirable to maintain along with the contents of the superfile, as well as specific information that may be required for a client device to contact the superfile server and gain access to the content payload 220.

[0044]

[0049] The example superfile 200 is described as including a header portion 210 and a content payload 220. However, other portions, such as trailers, may also be included. In some examples, the superfile 200 may include multiple content payloads 220, each of which may be separately accessible depending on the user's permission level. For example, the superfile 200 may have two content payloads 220, one of which may be viewable by anyone with a copy of the file (e.g., a movie trailer or a book prologue), and the other of which may be accessible only after purchasing access (e.g., the entire movie or book). Thus, a superfile may have any suitable structure for storing, regulating, and monitoring access to content.

[0045]

[0050] Referring now to Figure 3, Figure 3 illustrates another exemplary system 300 for providing remote ownership and content control of media files on untrusted systems. The exemplary system 300 illustrated in Figure 3 includes multiple superfile servers 310a-m and multiple client devices 320a-n that collectively implement a blockchain network 330 that includes blockchains 332a-k. The blockchains 332a-k provide a persistent, immutable record of the superfiles, and the superfile servers 310a-m and client devices 320a-n can trust and track and verify the superfiles over time and across different computing systems.

[0046]

[0051] In this example, superfile servers 310a-m have the ability to read and write to blockchains 332a-k, and client devices 320a-n can read records in blockchains 332a-k. However, in some examples, only superfile servers 310a-m have access to the blockchain network. When a new superfile is created, the creator's client device contacts a superfile server (e.g., superfile server 310a) and registers the superfile. Superfile server 310a receives a copy of the superfile and establishes a blockchain for the superfile. When other users receive copies of the superfile (or when the creator accesses the superfile again), they can verify the integrity of the superfile by accessing and, as needed, traversing the corresponding blockchain. The blockchain also provides ownership information about the superfile, which may include a record of information about the creator of the superfile and the transfer of ownership from user to user. When changes are made to the superfile, superfile servers 310a-m add blocks to the blockchain, and the blockchain provides an audit trail of changes made to the superfile over time.

[0047]

[0052] In this exemplary system, the superfile servers 310a-m are hosted by a trusted third-party superfile service provider. However, in some examples, users (e.g., creators) or organizations can operate their own superfile servers and manage their own set of superfiles and blockchain networks. For example, a movie studio could manage its own superfile server and blockchain network 330, allowing the studio to create superfiles to manage access to the movies it releases, publish updates, or embed different features within movies over time. For example, a movie studio could update a movie superfile to change trailers or marketing promotions associated with various movies. Similarly, other creative organizations, such as advertising agencies, recording studios, and research labs, could manage their own superfile servers and blockchain networks to make their content accessible to users while monitoring and maintaining control over the use of that content.

[0048]

[0053] Thus, an exemplary system according to the present disclosure may include the use of a blockchain network to ensure the authenticity and validity of the superfile, while a superfile server mediates access to the superfile content, although the use of a blockchain is an optional feature in some exemplary systems and may be omitted in others.

[0049]

[0054] Referring now to Figure 4, Figure 4 shows an exemplary sequence diagram illustrating interactions within a system for remote ownership and content control of media files on an untrusted system according to the present disclosure. The system includes several client devices 410a-c, a super file server, and a blockchain network 430.

[0050]

[0055] The sequence begins with a user of client device 410a creating content and saving it as superfile 440. This causes client device 410a to send a message to superfile server 420 indicating that a new superfile has been created. In this example, client device 410a also sends a copy of the superfile to superfile server 420. The superfile includes both a header portion and a content payload, similar to the superfile example described above with respect to FIG. 2. The header portion includes a unique identifier of a superfile that client device 410a previously requested from the superfile server. However, in some examples, the client may create and save a superfile and receive a superfile identifier from superfile server 420 in response. Client device 410a can then insert the superfile identifier into the superfile header portion.

[0051]

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

[0052]

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

[0053]

[0058] In this example, the blockchain network may be distributed across multiple super file servers and client devices, as described above with respect to Figure 3. Thus, adding a new blockchain to the blockchain network may involve distributing one or more blocks between different computing devices, such as super file server 420 or one or more of client devices 410a-c.

[0054]

[0059] After creating the superfile, the creator of the superfile provides a copy of the superfile 444 to another user of another client device 410b. For example, the creator may email the superfile to the recipient or save it on a portable storage device (e.g., a thumb drive, portable hard drive, etc.) that may be physically connected to the other client device 410b. Because a superfile is a self-contained unit like a conventional file and is stored by a computing device as a conventional file, it can be easily transferred to other computing devices or storage devices.

[0055]

[0060] The recipient then opens the superfile 446 using the client device 410b. To open the superfile, a user can double-click an icon corresponding to the superfile, such as in a graphical user interface ("GUI") provided by the client device's OS. In response to the user input to open the superfile, the recipient's client device 410b determines that the selected file is a superfile and determines the superfile server to contact to open the file. For example, an application can retrieve information from the superfile itself, e.g., using a URI or IP address stored in the superfile's header, to contact the superfile server. The application may then send one or more messages to the superfile server 420 over one or more networks to access the superfile content payload.

[0056]

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

[0057]

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

[0058]

[0063] If the received checksum / hash value matches the latest version of the superfile in the blockchain, superfile server 420 determines that client device 410b has the latest version of the superfile. However, if it matches a blockchain record of an earlier version of the superfile, client device 410b may update the superfile, as 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, superfile server 420 may send an error message or update the superfile.

[0059]

[0064] If the superfile server 420 determines that the recipient has permission to access the content payload of the superfile, it can send the information necessary to access 458 the content payload. Such information may be one or more encryption keys, an identification of the compression algorithm used to compress the content payload, etc. However, in some examples, the content payload may not be encrypted or compressed, in which case the superfile server 420 can return a response indicating that decryption or decompression is not required. Furthermore, in some examples, the superfile itself may indicate whether the content payload is encrypted or compressed. If the superfile indicates that it is not encrypted or compressed, it may not receive the access information in 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, the client device 410b decrypts the content of the superfile, but only decrypts the content to volatile system memory for presentation to the user. The client device 410b does not decrypt the content to non-volatile storage. Thus, a separate file is not created on the decrypted client, which can help prevent access to content without first contacting the super file server 420.

[0060]

[0065] While the client device 410b is accessing the content payload, it can report information regarding its usage 450 of the superfile to the superfile server 420. The usage information may be reported periodically (e.g., every minute) or in response to an event that occurs while the superfile is open (e.g., in response to scrolling to a new page, playing / pausing / rewinding / etc. a movie or audio, zooming in on a photo, etc.). The usage information may include identification of actions taken with respect to the content payload (e.g., those described above), the time the content payload was open, the time the client device 410b was active or idle, when the content payload was in the foreground or background of a GUI presented to the user, when the content was minimized, etc. It can also detect potential unauthorized actions such as attempts to capture screenshots of the presented content, attempts to modify the content payload, or attempts to export the content payload to a separate file. Such usage information may be reported to the superfile server 420, which may maintain statistics related to the superfile. Such information may be used to determine the level of engagement with the content, to determine the interest of different users, to determine advertising or other monetization information associated with the content, etc. Such information may be accessible by the creator or owner of the superfile and may be obtained by issuing a request to the superfile server 420 or by accessing an account maintained by the superfile server 420.

[0061]

[0066] At some point, the recipient can further distribute the superfile to other users, such as the user of client device 3 (410c) (the "second" recipient). With respect to item 444, the recipient can distribute the superfile to any other users using any suitable mechanism. The second recipient can then attempt to open the superfile, which, if the second recipient is authorized to access the content payload, initiates a similar process of sending one or more messages 462 to the superfile server 420 and receiving access information 464. The second recipient's client device 410c can then also maintain communication with the superfile server 420 while the superfile is open and can report usage information 466 to the superfile server 420, as described above with respect to item 450.

[0062]

[0067] At some point, the creator or owner of the superfile or other editor (referred to as the creator in this example) may modify the content payload of the superfile. When this occurs, the client device 410a reports the modification to the superfile server 420. The modification may be reported in real time as the creator modifies the superfile, but in some examples, the modification may only be reported when the user saves changes to the superfile or closes the superfile. The modification may be any change to the superfile, and may be to the content payload, header portion, or any other aspect of the superfile. Such modifications may include changes to ownership or permission levels, changes to the content payload, etc.

[0063]

[0068] When a modification is reported 466 to the superfile server 420, the superfile server 420 adds a new block to the blockchain associated with the superfile and stores it in the blockchain network 430. Thus, the blockchain maintains a permanent, immutable record of the superfile, as it is revised over time.

[0064]

[0069] In addition to updating the blockchain, superfile server 420 identifies any other client devices that have the superfile open when the modification is made. In this example, superfile server 420 identifies two other client devices 410b-c that have open copies of the superfile based on maintained connections with superfile servers 410b-c. After identifying client devices 410b-c, superfile server 420 provides the superfile updates to each of client devices 410b-c, which apply and store the superfile. Additionally, the presented content of the superfile (if modified) is updated in real time for users viewing the content. Thus, users can see changes to the file content in real time or near real time as the creator revises the file.

[0065]

[0070] Later, the creator changes the file access permissions 480 for the superfile content payload. These changes are reported to the superfile server 420, just like the modifications to the file 466 described above.

[0066]

[0071] In response to receiving the modified file access permissions, the superfile server 420 determines that the client devices 410b-c no longer have permission to access the superfile's contents, and therefore sends one or more messages 482, 484 to the client devices 410b-c, causing them to immediately discontinue presenting the superfile's contents and, if not already discarded, discard any access information (e.g., encryption keys) previously received by the respective client devices 410b-c. To further protect the content from unauthorized access, the client devices 410b-410c may also overwrite the memory containing the decrypted content to ensure that the decrypted content is completely erased from the client's device. Thus, the creator can revoke (or grant) access in real time to anyone with a copy of the superfile.

[0067]

[0072] It should be understood that this exemplary sequence uses only a relatively small system with a single super file server 420 and three client devices 410a-c to illustrate certain functionality, however, systems with significantly more components are contemplated, such as tens, hundreds, or even thousands of super file servers interacting with thousands or millions of client devices or more, which can provide functionality similar to that described above on a much larger scale.

[0068]

[0073] Referring now to Figure 5, Figure 5 illustrates an exemplary method 500 for creating a new superfile as part of a system for remote ownership and content control of media files on an untrusted system. Method 500 in this example includes two different computing systems that perform different aspects of the method. And, although these aspects may be interrelated, each computing system performs its own separate method, which may include receiving input from or transmitting information to another computing device.

[0069]

[0074] At block 512, a user of client device 510 creates file content of any suitable type (e.g., document, audio, video, source code, etc.). The user may create the file content using any suitable authoring or capture tool (e.g., word processing program, source code editor, video camera, etc.). The user may store such content in any suitable file according to any suitable file format.

[0070]

[0075] In block 514, the user selects to store the content as a superfile. This may be done after the content has been stored in an existing file according to one file format, or the user may initially save the content as content within a superfile. To do so, the user can interact with the application and select an option to save or export the content (e.g., content stored in volatile memory or content stored in a file stored in non-volatile memory) to a new superfile. The application can then generate a superfile according to the appropriate superfile structure and store the content within the superfile's content payload. During this process, the application can prompt the user to provide certain information, such as access control information, selection of one or more encryption options, selection of one or more compression options, selection of a superfile server provider, etc. Based on the provided information, the application can generate or complete the header portion of the new superfile. The application can then store the content of the superfile in non-volatile memory, such as a hard drive, or cloud storage.

[0071]

[0076] During generation of the superfile, the client device 510 contacts the superfile server 520 (e.g., a superfile server selected by the user or automatically selected by the application) and provides an indication that a new superfile has been created. The client device 510 also provides information about the superfile, including some or all of the header information or some or all of the content payload. In some implementations, the superfile server 520 can generate a unique identifier for the superfile that is provided to the client device 510, although in some examples, the client device 510 can generate its own unique identifier for the superfile.

[0072]

[0077] In addition to obtaining the unique identifier, if the superfile contains encrypted content, the client device 514 may generate one or more encryption keys to encrypt the content, or may request such a key(s) from the superfile server 520. The client device 510 then encrypts the content of the superfile using the encryption keys.

[0073]

[0078] At block 522, the superfile server 520 registers the superfile by creating a record in the data store corresponding to the superfile. The record may include information about the superfile, such as a superfile identifier, the owner of the superfile, and a checksum or hash value of the superfile. The record may also include some or all of the content payload of the superfile, as well as cryptographic information (e.g., a symmetric encryption key, an asymmetric encryption key pair, etc.) or compression information. In addition to creating the record in the data store, the superfile server 520 may generate and provide to the client device 510 a confirmation that the superfile was successfully created.

[0074]

[0079] At block 524, the superfile server 520 adds the blockchain to the blockchain network. The new blockchain is associated with the new superfile, and a block is created in the blockchain based on the new superfile. The block may include information similar to that described above with respect to block 522. It may also include some or all of the contents of the superfile (e.g., a header portion or a content payload). Including the content payload allows the superfile server 520 to provide the content payload to other computing devices that open the superfile, such as to update their copies of the superfile with current content or to repair corrupted copies of the superfile. Additionally, according to different implementations, any suitable information may be stored in a block in the blockchain.

[0075]

[0080] Once a superfile is created and registered with the superfile server 520, the creator can freely distribute the superfile to any other users, who can then access the contents of the superfile, as described in more detail below.

[0076]

[0081] It should be understood that not all super file systems can use blockchain technology, and therefore, in some examples, block 524 may be omitted.

[0077]

[0082] Referring now to Figure 6, Figure 6 illustrates an exemplary method 600 for accessing, modifying, and updating a superfile. Method 600 in this example includes three different computing systems that perform different aspects of the method. And, although these aspects may be interrelated, each computing system performs its own separate method, which may include receiving input from or transmitting information to another computing device.

[0078]

[0083] In block 612, the client device 610 obtains a copy of the superfile. For example, the superfile can be received via email or by downloading it from a website. In some examples, the user can obtain the superfile using a portable storage device and connect it to the client device 610.

[0079]

[0084] At block 614, the client device 610 opens the superfile. Opening the superfile may include accessing the content of the superfile, or may not include being able to access encrypted or compressed data stored within the content payload of the superfile. A user can use the client device 610 to open the superfile, as generally described above with respect to items 446 and 462 of FIG. 4 . Additionally, opening the superfile may include transmitting information to the superfile server 630 to gain access to the content stored within the superfile, as described above with respect to items 446 and 462.

[0080]

[0085] In block 632, the super file server 630 receives user credential information from the client device 610 that can indicate the identity of the user of the client device 610. The user credential information can include user account information (e.g., username and password), an authenticable token associated with the user's established identity with a trusted entity, etc. In some examples, if the user credential information is not received, the super file server 630 can respond to the client device 610 with a request for user credential information. In some examples, if the super file server 630 does not receive the user credential information, it can treat the user as an anonymous user.

[0081]

[0086] At block 634, the superfile server 630 determines access permissions to the superfile for the user of the client device 610. Access permissions may be established for individual users, predetermined groups of users, etc. Thus, based on user credential information, the superfile server 630 can determine whether the user has specific access permissions to the superfile, such as access to view, edit, transfer ownership, etc. Such access permissions may be maintained in a data store accessible by the superfile server 630, such as the data store described above with respect to block 522 of FIG. 5, or in the superfile's blockchain.

[0082]

[0087] Access permissions for different users may be applied by defining permission groups, each with specific types of allowed and prohibited actions, and assigning users to one of the groups, or by establishing custom-tailored allowed and prohibited actions for each user. Groups may be established for owners, editors, viewers, time-limited viewers, etc. Actions that may be allowed or prohibited may include transferring ownership, adding content, modifying existing content, deleting existing content, changing permission levels or disabling access for one or more users or groups, changing encryption or compression settings, viewing all content, viewing specific portions of content, viewing ownership information, viewing author information, etc.

[0083]

[0088] After determining the access permissions for the requesting user, the superfile server 630 responds to the client device 610. Depending on the response, the client device 610 may access the entire content payload(s) of the superfile, a portion of the content payload, less than all of the content payload, etc. In this example, the superfile includes an encrypted content payload, and the superfile server 630 determines that the requesting user has permission to access the content of the superfile. In response to that determination, the superfile server 630 retrieves cryptographic information from a record corresponding to the superfile stored in a data store accessible by the superfile server 630 and provides the client device 610 with the cryptographic information necessary to decrypt the content payload. In examples in which the content payload is compressed, the superfile server 630 can also provide information indicating the type of compression applied to the content payload.

[0084]

[0089] In block 616, the client device 610 receives the cryptographic information and decrypts the content in the superfile. In this example, the superfile includes only one content payload; however, if the superfile includes multiple content payloads, the client device 610 can receive the cryptographic information necessary to decrypt some or all of the content payloads. After receiving such cryptographic information, the client device 610 decrypts the content payloads for which the cryptographic information was received. Similarly, if the content payloads are compressed, the client device 610 also decompresses any content payloads that can be decrypted. It should be understood that compression may be applied before or after encryption, and thus the order of operations for compression and decryption may be received from the superfile server or obtained from the header portion of the superfile. In this example, the client device also deletes the decryption key as soon as the content is decrypted. However, in other examples, a copy of the decryption key may be kept while the file is open.

[0085]

[0090] In block 618, the client device 610 presents the decoded superfile content to the user. Depending on the type of content in the superfile, the presentation may vary by playing audio, displaying video, presenting a document, etc.

[0086]

[0091] In block 620, the client device 610 maintains a communications connection to the superfile server 630 and sends usage information to the superfile server 630 based on the user's use of the content. For example, the client device 610 can report which portions of the content were presented to the user (e.g., pages of a document viewed by the user, tracks in a music album played by the user, portions of a movie or television show played by the user), whether the user rewound, paused, or fast-forwarded the content, how long the user had the superfile open, etc. Other information (e.g., attempts at prohibited actions, including editing the document, changing permissions, viewing ownership information, etc.) can also be provided.

[0087]

[0092] It should be understood that in some examples, usage information may be transmitted over time while the superfile is open, but may also be collected at the client device 610 and transmitted only when the client device 610 closes the file. Still other mechanisms for reporting usage information may be used. Also, in this example, the usage information is transmitted to the same superfile server 630 that was originally contacted to open the superfile, but the usage information may be transmitted to any suitable computing device. For example, the owner of the superfile may include information indicating where the usage information should be transmitted when the superfile is created.

[0088]

[0093] If communication between the client device 610 and the superfile server 630 is interrupted while a superfile is open, access to the superfile's content may 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 the client device discontinues presenting the superfile content. The encryption key may further be discarded to prevent access to the superfile content while communication with the superfile server 630 is interrupted. Once the connection is re-established, the client device 610 may re-present the content, which may include re-requesting encryption information from the superfile server 630. Revoked access may depend on the access level of a particular user. For example, the owner of a superfile will never lose access to the superfile's content, but the creator or editor may have a substantial timeout period (e.g., 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 a short timeout period (e.g., five to ten minutes) to facilitate sometimes sporadic Internet server traffic. Anonymous viewers of the content may lose access immediately upon interruption, however, according to different examples, any suitable scheme may be used.

[0089]

[0094] In block 636, the superfile server 630 receives and stores the usage information in a data store and associates the usage information with the superfile.

[0090]

[0095] In block 662, a 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 610 to modify the content of the superfile while client device 660 has its copy of the superfile open. The modifications made by client device 660 can be of any type, including to the content payload, the header portion, adding a new content payload, deleting an existing content payload, etc.

[0091]

[0096] After making the changes, the client device 660 provides the changes to the superfile server 630. The changes may be sent as updates to only certain portions of the superfile's contents, or by sending the entire updated superfile to the superfile server 630. Furthermore, the changes may be sent at any appropriate time, including in real-time as the changes are made, when the user of the client device 660 selects the "save file" option, or when the user of the client device 660 closes the superfile.

[0092]

[0097] In block 638, super file server 630 receives the changes from client device 660. In this example, super file server 630 is the same super file server 630 that is in communication with client device 610. However, in some examples, client device 660 may be in communication with a different super file server 630 than client device 610.

[0093]

[0098] After receiving the modified content, superfile server 630 updates one or more records in the data store associated with the superfile, as necessary, based on the changes made by client device 660. It then adds a new block to the blockchain corresponding to the superfile, as described below with respect to block 638. Superfile server 630 also notifies client device 610 that the superfile has been modified. In this example, superfile server 630 pushes the modified content to client device 610 (and any other client devices that have an open copy of the superfile). However, in some examples, superfile server 630 may notify client device 610 of the modified content, and client device 610 may send a request for the modified content to superfile server 630. For example, client device 610 may query the user whether to retrieve the modified content.

[0094]

[0099] In instances where multiple superfile servers are associated with a particular superfile, they may each access the same blockchain network to manage the creation and addition of blockchains, or blocks, to the blockchain network. Furthermore, they may each access the same data store to retrieve or update information about the superfile. Furthermore, when one superfile server in a group of superfile servers receives an update to the superfile, it can broadcast a notification indicating that the change was received, and the other superfile servers can determine which client devices currently have copies of the superfile open and deliver the modified content, as described above.

[0095]

[0100] In block 640, the superfile server 630 adds a new block to the blockchain corresponding to the superfile. The new block includes information indicating changes from the previous block in the blockchain, and in some examples, a copy of the modified superfile may be stored in the new block.

[0096]

[0101] At block 622, while the client device 610 has the superfile open, it receives the modified content from the superfile server 630. As described above, the modified content may have been pushed by the superfile server 630 or may have been requested by the client device 610, for example, in response to the user indicating a desire to receive the modified content.

[0097]

[0102] In block 624, the client device 610 presents the modified content to the user, generally as described above with respect to block 618, and continues to send usage information by returning to block 620.

[0098]

[0103] Thus, this exemplary method shows how a user obtains a copy of the superfile and how the system updates the user's copy of the superfile in real time while the user has the file open. Thus, the user can always view the most recent version of the superfile, and the owner of the content in the superfile can ensure that their copy of the superfile always represents the current version of the content. It should be understood that if the user closes the superfile before the changed content is received, the next time the superfile is opened, the superfile server 630 will detect that the user has an older version of the content and will provide the changed content at that time. Thus, even if the user did not have the superfile open when the change was made, the next time the file is opened, the superfile will generally be updated as described above with respect to blocks 662, 636, 638, 622, and 624.

[0099]

[0104]

[0041] Referring now to Figure 7, Figure 7 illustrates an example method 700 for remote ownership and content control of media files on an untrusted system. The example illustrated in Figure 7 is described with reference to the example system 100 shown in Figure 1, although any suitable system according to this disclosure may be used.

[0100]

[0105] In block 712, a client device (e.g., client device 120a) receives a request to open a superfile, such as a user double-clicking an icon corresponding to the superfile or selecting a superfile to open within an application.

[0101]

[0106] In blocks 714 and 716, client device 120a sends a request for superfile access information to superfile server 110 and receives access information in response, generally as described above with respect to items 446, 362 of FIG. 4 and / or block 614 of FIG. 6.

[0102]

[0107] Client device 120a decrypts the superfile content using the received access information at block 718. It should be understood that, depending on the encryption or compression (if any) applied to the content, block 718 may be omitted or may instead include decompressing the content, or both decompressing and decrypting the content.

[0103]

[0108] At block 720, client device 120a presents the superfile content to the user, generally as described above with respect to block 618 of FIG.

[0104]

[0109] In block 722, client device 120a receives the modified superfile content from the superfile server (e.g., superfile server 110) and replaces the existing superfile content with the modified superfile content, generally as described above with respect to items 470, 472 of FIG. 4 or block 622 of FIG. 6.

[0105]

[0110] At block 724, client device 120a presents the modified superfile content, generally as described above with respect to block 624 of FIG. 4 or FIG.

[0106]

[0111] At block 726, client device 120a receives an access revocation indication from the super file server, generally as described above with respect to items 482 and 484 of FIG.

[0107]

[0112] At block 728, client device 120a revokes access to the superfile content. For example, client device 120a may revoke an encryption key, such as the encryption key obtained at block 716. Client device 120a may also erase any decrypted copies of the content stored in memory, such as for presenting the content to a user. In some examples, client device 120a may also delete copies of the superfile from long-term storage (e.g., a hard disk, etc.).

[0108]

[0113] It should be understood that while the blocks of this exemplary method are performed in a particular order, the blocks may be performed in a different order, and some blocks may not be performed at all. For example, if no modified superfile content is received, blocks 722 and 724 may be omitted. Similarly, if no access revocation message is received, blocks 726 and 728 may be omitted. Additionally, if the superfile is modified multiple times, blocks 722 and 724 may be repeated.

[0109]

[0114]

[0041] Referring now to Figure 8, Figure 8 illustrates an example method 800 for remote ownership and content control of media files on an untrusted system. The example shown in Figure 7 is described with reference to the example system 100 shown in Figure 1, although any suitable system according to this disclosure may be used.

[0110]

[0115] In block 812, the superfile server 110 receives an identification of the new superfile from a client device (eg, client device 120a), generally as described above with respect to item 440 of FIG. 4 or blocks 514 and 522 of FIG.

[0111]

[0116] In block 814, the super file server 110 adds the new blockchain to the blockchain network (e.g., blockchain network 330), generally as described above with respect to item 442 of FIG. 4 or block 524 of FIG.

[0112]

[0117] At block 816, the superfile server 110 receives a request to access the superfile content from a client device, generally as described above with respect to items 446 and 462 of FIG. 4 or block 614 of FIG.

[0113]

[0118] In blocks 818 and 820, the superfile server 110 determines the access level of the superfile and provides access information, generally as described above with respect to items 448 and 464 of FIG. 4 or blocks 632 and 634 of FIG.

[0114]

[0119] In block 822, the super file server 110 receives usage information from the client device, generally as described above with respect to item 450 of FIG. 4 or block 636 of FIG.

[0115]

[0120] In block 824, the superfile server 110 receives modifications to the contents of the superfile from the client device, as generally described above with respect to item 466 of FIG. 4 or block 638 of FIG.

[0116]

[0121] In block 826, the superfile server 110 adds the new block to the blockchain associated with the superfile, generally as described above with respect to item 468 of FIG. 4 or block 640 of FIG. 6.

[0117]

[0122] In block 828, the superfile server 110 distributes the changes to the superfile to client devices that have open copies of the superfile, generally as described above with respect to items 470 and 472 of FIG. 4 or blocks 622 and 638 of FIG.

[0118]

[0123] At block 830, the superfile server 110 receives modifications to the access levels of the superfile. For example, the owner of the superfile may modify the access levels of different groups of users or individual users. The superfile server 110 receives those changes and can update corresponding records in the data store 112 or add a new block to the blockchain corresponding to the superfile to reflect the updated permissions.

[0119]

[0124] In block 832, the superfile server 110 sends instructions to clients that have open copies of the superfile. For example, if the modification to the access level revokes access to one or more users, the superfile server 110 sends instructions to any client devices that have an open superfile to revoke access to the superfile by one of the identified users, as described above with respect to items 482 and 484 of FIG. 8 or blocks 726 and 728 of FIG. 7. If the access level modification lowers the access level (e.g., from editor to viewer), the superfile server 110 can send corresponding instructions, which can prevent the corresponding client from making or saving further modifications to the superfile content. The client device may present the access level change to the user. Similarly, if the access level modification increases the user's access level (e.g., from viewer to editor), the client device can present a notification of the access level change to the user and enable options in the corresponding application to edit and save changes to the superfile content.

[0120]

[0125] It should be understood that while the blocks of this exemplary method are performed in a particular order, the blocks may be performed in a different order, and some blocks may not be performed at all. For example, if no modified superfile content is received, blocks 824-828 may be omitted. Similarly, if no access changes to any access levels are received, blocks 830 and 832 may be omitted. Furthermore, one or more of blocks 822-832 may be repeated based on actions taken by various client devices.

[0121]

[0126] Referring now to FIG. 9, FIG. 9 illustrates an exemplary computing device 900 suitable for use in an exemplary system or method for remote ownership and content control of media files on an untrusted system according to the present disclosure. The exemplary 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 for mediating participant interactions during a video webinar conference according to different examples, such as some or all of the exemplary methods 500-800 described above with respect to FIGS. 5-8. 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 device 940 for providing visual output to the user.

[0122]

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

[0123]

[0128] Although some example methods and systems herein are described in terms of software running on various machines, the methods and systems may also be implemented as specifically configured hardware, such as a field programmable gate array (FPGA), specifically for performing various methods according to the present disclosure. For example, examples can be implemented in digital electronic circuitry, or computer hardware, firmware, software, or combinations thereof. In one example, an apparatus may include one or more processors. The processor includes a computer-readable medium, such as a random access memory (RAM), coupled to the processor. The processor executes computer-executable program instructions stored in 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 comprise programmable electronic devices, such as programmable logic devices (PLCs), programmable interrupt controllers (PICs), programmable logic devices (PLDs), programmable read-only memories (PROMs), electronically programmable read-only memories (EPROMs or EEPROMs), or other similar devices.

[0124]

[0129] Such a processor may include or be in communication with a medium (e.g., one or more non-transitory computer-readable media) capable of storing processor-executable instructions that, when executed by the processor, cause the processor to perform a method according to the present disclosure, as performed or assisted by the processor. 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 tape or other magnetic media, or any other medium that can be read by a computer processor. The described processors and processes may be in one or more structures or distributed across one or more structures. A processor may include code for executing a method (or portion of a method) according to the present disclosure.

[0125]

[0130] The foregoing description of several examples has been presented for purposes of illustration and description only and is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the spirit and scope of the disclosure.

[0126]

[0131] Reference to an example or embodiment herein means that a particular feature, structure, operation, or other characteristic described in connection with the example may be included in at least one embodiment of the present disclosure. The present disclosure is not limited to the particular example or embodiment so described. The appearance of the phrases "in one example," "in an example," "in one implementation," or "in an implementation," or variations thereof, in various places herein do not necessarily refer to the same example or embodiment. Any particular feature, structure, operation, or other characteristic described herein in connection with one example or embodiment may be combined with other features, structures, operations, or other characteristics described in connection with any other example or embodiment.

[0127]

[0132] Use of the word "or" herein is intended to cover an inclusive and exclusive OR condition. In other words, A or B or C includes any or all of the following alternative combinations as appropriate for the particular application: A alone, B alone, C alone, A and B only, A and C only, B and C only, and A, B and C. An example is shown below. (Example 1) receiving, by a client computing device, a request to open a superfile stored on a memory device at the client computing device, the superfile including encrypted content, and the request including user credential information; In response to receiving the request to open the superfile, communicating, by the client computing device, a request to a remote server to access the superfile, the request including credentials associated with a user account; receiving cryptographic information from the remote server; decrypting the encrypted content using the encryption information; accessing and presenting the decrypted content; maintaining communication with the remote server while the decrypted content is being accessed; A method comprising: (Example 2) 2. The method of Example 1, further comprising providing usage information associated with the superfile while the superfile is open and using the maintained communication with the remote server. (Example 3) 3. The method of example 2, wherein the usage information indicates a portion of the decrypted content being presented or a user input associated with the decrypted content. (Example 4) While the decrypted content is being accessed, receiving the modified encrypted content from the remote server; replacing the encrypted content with the modified encrypted content; presenting the modified encrypted content; The method of Example 1 further comprises: (Example 5) While the decrypted content is being accessed, receiving an indication of a loss of access to the encrypted content; terminating the presentation of the decrypted content; deleting the decrypted content; The method of Example 1, further comprising: (Example 6) While the decrypted content is being accessed, receiving, by the client computing device, a modification of the decrypted content; updating the encrypted content based on the modification; replacing the encrypted content with the updated encrypted content in the memory device of the client computing device; providing the updated encrypted content to the remote server; The method of Example 1, further comprising: (Example 7) While the decrypted content is being accessed, detecting a loss of connection to the remote server; terminating the presentation of the decrypted content; deleting the decrypted content; The method of Example 1, further comprising: (Example 8) 2. The method of Example 1, further comprising providing usage statistics related to the encrypted content to the remote server while the decrypted content is being accessed. (Example 9) receiving a request from a remote client device to access encrypted content in a superfile, the request including user credential information, the superfile being stored in a memory device of the remote client device and including 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; receiving and storing usage information from the remote client device associated with the encrypted content while the superfile is open on the remote client device; A method comprising: (Example 10) 10. The method of example 9, wherein the usage information indicates a portion of content in the superfile being presented or a user input associated with the content in the superfile being presented. (Example 11) 10. The method of example 9, wherein the authorization level includes at least one of an owner of the encrypted content or an authorized viewer of the encrypted content. (Example 12) receiving modified content associated with the superfile; determining a second remote client device that has an open copy of the superfile; sending updated superfile information to the second remote client device, the updated superfile information including the modified content; The method of Example 9, further comprising: (Example 13) generating a block record for a blockchain corresponding to the superfile based on the modified content; adding the block record to the blockchain; The method of Example 12, further comprising: (Example 14) receiving a request from a third remote client device to access encrypted content in a copy of the superfile, the request including second user credential information, the copy of the superfile being stored in a second memory device of the third remote client device and including the encrypted content; determining an authorization level for accessing the encrypted content; In response to determining the authorization level, providing updated superfile information to the third remote client device, the updated superfile information including the modified content; providing cryptographic information to the third remote client device; receiving and storing usage information from the third remote client device associated with the modified content while the superfile is open on the third remote client device; The method of Example 12, further comprising: (Example 15) receiving modifications to one or more access levels of the superfile; sending instructions to one or more clients having open copies of the superfile based on the modifications to the one or more access levels of the superfile; The method of Example 9, further comprising: (Example 16) receiving an instruction to create a new superfile from a remote client device; creating one or more records in a data store associated with the new superfile; storing one or more encryption keys in the one or more records, one of the one or more keys being used to encrypt content in the superfile; receiving and storing a copy of the superfile; A method comprising: (Example 17) receiving one or more access restrictions associated with the superfile; storing said access restrictions in said one or more records; The method of Example 16, further comprising: (Example 18) generating a new blockchain corresponding to the new superfile; inserting a block into the blockchain, the block including a copy of the superfile; The method of Example 16, further comprising: (Example 19) 20. The method of Example 18, further comprising storing one or more access restrictions for the superfile in the block. (Example 20) 20. The method of Example 18, further comprising storing one or more check values ​​for the superfile or contents of the superfile in the block.

Claims

1. receiving, by a client computing device, a request to open a superfile stored on a memory device at the client computing device, the superfile including encrypted content, and the request including user credential information; In response to receiving the request to open the superfile, communicating, by the client computing device, a request to a remote server to access the superfile, the request including credentials associated with a user account; receiving cryptographic information from the remote server; decrypting the encrypted content using the encryption information; accessing and presenting the decrypted content; maintaining communication with the remote server while the decrypted content is being accessed; While the decrypted content is being accessed, receiving, by the client computing device, a modification of the decrypted content; updating the encrypted content based on the modification; replacing the encrypted content with the updated encrypted content in the memory device of the client computing device; providing the updated encrypted content to the remote server; A method comprising:

2. 2. The method of claim 1, further comprising providing usage information associated with the superfile while the superfile is open and using the maintained communication with the remote server.

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

4. While the decrypted content is being accessed, receiving the modified encrypted content from the remote server; replacing the encrypted content with the modified encrypted content; presenting the modified encrypted content; The method of claim 1 further comprising:

5. While the decrypted content is being accessed, receiving an indication of a loss of access to the encrypted content; terminating the presentation of the decrypted content; deleting the decrypted content; The method of claim 1 further comprising:

6. While the decrypted content is being accessed, detecting a loss of connection to the remote server; terminating the presentation of the decrypted content; deleting the decrypted content; The method of claim 1 further comprising:

7. The method of claim 1 , further comprising providing usage statistics related to the encrypted content to the remote server while the decrypted content is being accessed.

8. receiving a request from a remote client device to access encrypted content in a superfile, the request including user credential information, the superfile being stored in a memory device of the remote client device and including 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; receiving and storing usage information from the remote client device associated with the encrypted content while the superfile is open on the remote client device; receiving modified content associated with the superfile; determining a second remote client device that has an open copy of the superfile; sending updated superfile information to the second remote client device, the updated superfile information including the modified content; A method comprising:

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

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

11. generating a block record for a blockchain corresponding to the superfile based on the modified content; adding the block record to the blockchain; The method of claim 8 further comprising:

12. receiving a request from a third remote client device to access encrypted content in a copy of the superfile, the request including second user credential information, the copy of the superfile being stored in a second memory device of the third remote client device and including the encrypted content; determining an authorization level for accessing the encrypted content; In response to determining the authorization level, providing updated superfile information to the third remote client device, the updated superfile information including the modified content; providing cryptographic information to the third remote client device; receiving and storing usage information from the third remote client device associated with the modified content while the superfile is open on the third remote client device; The method of claim 8 further comprising:

13. receiving modifications to one or more access levels of the superfile; sending instructions to one or more clients having open copies of the superfile based on the modifications to the one or more access levels of the superfile; The method of claim 8 further comprising:

Images