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

Abstract

The method includes the step of receiving a request to open a superfile stored in a memory device on a client computing device. The superfile contains encrypted content, and the request includes user credentials. The method also includes, in response to receiving the request to open the superfile, communicating a request to a remote server to access the superfile. The request includes credentials associated with a user account. The method further includes the steps of 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. [Effect] Users can use the super file as any conventional file and receive or provide updates in near real-time.

Description

Technical Field

[0001] Cross - Reference to Related Applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 056,288, filed Jul. 24, 2020, entitled "New Computer File Type That is Traceable, Analytical, Has the Ability to Change Access at Any Time, Can Be Updated by the Owner of the File, and Then Updates the Files of Everyone Who Has the File", which is hereby incorporated by reference in its entirety.

[0002]

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

Background Art

[0003]

[0003] Computing systems can store data in various ways. One common way to store data is within a file on a non - volatile memory device such as a hard drive. The data within 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 the steps of: receiving a request by a client computing device to open a superfile stored in a memory device on the client computing device, wherein the superfile contains encrypted content and the request includes user credentials; in response to receiving the request to open the superfile, the client computing device communicates a request to a remote server to access the superfile, wherein the request includes 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 comprising user credentials, the superfile being stored in the memory device of the remote client device and containing encrypted content; determining the authorization level for accessing the encrypted content; providing the remote client device with cryptographic information in response to the authorization level determination; 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 the steps of receiving instructions from a remote client device to create a new superfile; creating one or more records in a datastore associated with the new superfile; storing one or more cryptographic keys in one or more records, wherein one of the one or more keys is used to encrypt the contents in the superfile; and receiving and storing a copy of the superfile.

[0007]

[0007] These exemplary examples are mentioned not to limit or define the scope of the present disclosure, but rather to provide examples to aid in its understanding. The exemplary examples are described in “Modes for Carrying Out the Invention” which provide further explanation. The advantages provided by the various examples can be further understood by examining this specification.

[0008]

[0008] The accompanying drawings incorporated herein and constituting part thereof illustrate one or more specific examples and, together with descriptions of the examples, are useful in illustrating the principles and implementations of the specific examples. [Brief explanation of the drawing]

[0009] [Figure 1] This provides an exemplary system for remote ownership and content control of media files on untrusted systems. [Figure 2] An exemplary structure of a superfile is shown. [Figure 3] This provides an exemplary system for remote ownership and content control of media files on untrusted systems. [Figure 4] This diagram illustrates the process of remote ownership and content control of media files on untrusted systems. [Figure 5] This document illustrates an exemplary method for remote ownership and content control of media files on untrusted systems. [Figure 6]This document illustrates an exemplary method for remote ownership and content control of media files on untrusted systems. [Figure 7] This document illustrates an exemplary method for remote ownership and content control of media files on untrusted systems. [Figure 8] This document illustrates an exemplary method for remote ownership and content control of media files on untrusted systems. [Figure 9] This document illustrates exemplary computing devices suitable for the use of exemplary systems and methods for remote ownership and content control of media files on untrusted systems. [Modes for carrying out the invention]

[0010]

[0015] This specification provides examples 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 illustrative and not intended to be limiting. Hereinafter, the implementations of the examples shown in the accompanying drawings are referred to in detail. 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 everyday characteristics of the examples described herein are shown or explained. Naturally, in developing such actual implementations, numerous implementation-specific decisions must be made to achieve the developer's specific goals, such as compliance with application and business-related constraints, and it will be understood that these specific goals will differ 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 little control over the content they contain. While some applications allow users to password-protect files or lock them to prevent editing, such features apply only to the file itself. Once the file is distributed to others, the owner has no ability to change these restrictions afterward, except by providing the necessary password or offering an unlocked copy of the file.

[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 for viewing or editing. However, control over these files is provided by the platform itself and is not an inherent function of the files stored on the platform. Therefore, file sharing 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 have access to the same copy of the file through platform-mediated access.

[0014]

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

[0015]

[0020] An example of a superfile includes a header section and a content section; the content is encrypted, but the header is not. The content section contains content generated by the file's creator or editor. In contrast, the header section contains information that allows the 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) that can be encoded as a Universal Resource Identifier ("URI"), such as a Universal Resource Locator ("URL"), and identifiers of the superfile, such as the file ID and 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 credentials.

[0017]

[0022] The server receives the file ID and the hash value, and verifies that the two match the corresponding information regarding the file. In this example, when a new superfile is created or modified, the server adds the blockchain to the blockchain network. Thus, 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 in the blockchain. If the two match, the server verifies that the blockchain corresponds to the identified superfile and that the superfile is genuine.

[0018]

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

[0019]

[0024] After receiving the decryption key, the client device maintains its connection to the superfile server, decrypts the contents of the file in memory while also deleting the decryption key, 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 parts of the content are being viewed, how long the file has been open, how much idle time has been detected, whether the user is attempting to copy or edit the content, etc. The superfile server can store the received information in a data store record corresponding to the blockchain record of the superfile. Thereafter, when the user closes the superfile, the user's computer deletes the decryption key and stops presenting the content of the superfile

[0020]

[0025] This example provides a simple illustration of a user accessing a superfile, but one advantage of superfiles is that the owner of a superfile can edit its content or change the level of access to the superfile, and these changes can then be propagated in real time to any copy of the superfile that is currently open on a user's computer. For example, if the owner of a 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 that is currently open on other client computers. Thus, these other client computers receive the edited content, and both update the content of the superfile itself, but also dynamically change the displayed and decoded content that can be viewed by users. Therefore, users will 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 the copy of the superfile. Users who were not viewing the superfile but access it later will be provided with the updated content immediately, for example, when their access to the superfile is authorized. Thus, superfiles provide a way for users to use superfiles as any conventional file and receive (or provide) updates in near real time.

[0021]

[0026] Similarly, the owner of the superfile can change the access restrictions on the content of the superfile, and then that can be propagated to any other copies of the file that are currently open at that time, almost in real time. For example, if the owner invalidates the user's access while the user has the superfile open, the superfile server sends a message to the client computer, which immediately stops providing the decrypted content to the user by overwriting the memory containing the decrypted content, and as a result, the content becomes inaccessible to the user. Also, a notification that the user's access rights have been invalidated by the owner may be provided.

[0022]

[0027] Using the superfile, the content creator can allow anyone to freely copy their work while maintaining control over access to their work. Further, the usage information collected by the superfile server enables the user to monitor their involvement with their content, and thereby the user can directly monetize it, for example, by selling access to the content, or indirectly monetize it, such as by selling advertisements associated with the content. Additionally, by adopting a blockchain as a mechanism for recording information about the superfile, the authenticity and chain of ownership of the superfile can be verified by accessing the blockchain.

[0023]

[0028] This exemplary example is provided to introduce the reader to the general subject matter discussed in this specification, and the present disclosure is not limited to this example. In the following sections, examples of systems and methods for remote ownership and content control of media files on untrusted systems, as well as various additional non-limiting examples, will be described.

[0024]

[0029] Referring here to Figure 1, Figure 1 shows an exemplary system for remote ownership and content control of media files on an untrusted system. The exemplary system includes a creator device 130 and several client devices 120a-n that can communicate 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 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 devices 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 devices 120a-n. The user (or “creator”) can then share that content with other users by providing a copy of the relevant file, whether or not the creator is aware of it. The recipient can then access the file, view the content, and, if necessary, edit it. 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 means a device operated by an autonomous user independent of the creator’s control. In other words, the creator has no way of accessing the users’ client devices 120a-n to prevent actions that another user might take with respect to the content. Furthermore, without such exemplary system 100, the creator would have no ability to establish that they are the creator of the content, nor to track the use of their data files by other users.

[0027]

[0032] To allow creators to maintain control over their content, they can store their content as 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, beyond simply granting permission to initially open the file and access its content, a superfile requires continuous communication with a superfile server to ensure that permission to access the file's content is not altered or invalidated, and to track user usage of the file's content.

[0028]

[0033] When a user receives a superfile, they receive the entire superfile, which appears to be a regular file. That is, the receiving user (or "recipient") owns the entire file and its contents, rather than just a part of the file that resides on the remote computer. In some examples, a superfile may be identified as such by a file name extension (e.g., .super), but in other examples, a superfile may not have a file extension or any particular file extension.

[0029]

[0034] To access a file, a user can attempt to open it using a client device, such as client device 120a, just like any other file, for example, by selecting the file icon of the superfile with a mouse and double-clicking it. The operating system ("OS") running on the recipient's client device can detect a command to open the file based on user input and can determine that a file is a superfile, for example, based on the file extension or by accessing header information within the superfile (described in more detail below). Once the OS determines that a file is a superfile, it may first attempt to open the file in a standard manner, or it may launch an application installed on the recipient's client device to open the file. For example, the content header may 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 application (both referred to as “application”) attempts to contact a super file server, for example, super file server 110. To this end, the application may issue a DNS request to obtain a network address for a pre-configured server name, such as files.superfile.org. The DNS response provides a network address, for example, 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, for example, through a trusted certification 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 superfile content. After receiving the information, the application uses it to decrypt or decompress the content, and then the application itself may present the content, or a separate application may be executed to present the content. In this exemplary system, once the content is decrypted, it is only decrypted into volatile system memory to enable presentation to the user. No decrypted copy of the superfile is created. This can help ensure the security of the superfile content in case event access is modified or disabled.

[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 had the file open and which parts of the content are being viewed or presented. The superfile server 110 can store such information in its data store 112 and associate it with a record corresponding to the superfile.

[0033]

[0038] If an application loses contact with the superfile server 110 while a superfile is open, the application may immediately terminate access to the superfile by deleting information necessary to decrypt or extract the content (if it has not already been deleted), deleting or overwriting any information from the superfile content copied to memory to enable content presentation, closing any separate applications used to view the content, etc. In some examples, the application may wait for 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 within 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 them to view the content but not edit it. Some users may have “editor” access, which allows them to edit the content, such as allowing other users to view the content, but does not exercise ownership functionality. Further types of permissions may be established.

[0035]

[0040] Different permission levels for each file may be maintained by one or more superfile servers, for example, 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 superfile's content, and if so, to what extent (e.g., owner, editor, viewer). Permission levels can affect a user's ability to make or save changes to the content within a superfile. For example, a user might be able to open a document saved as a superfile, in which case they only have "viewer" permission to the content. To prevent a user from editing a file, an OS or editing application (e.g., a word processing application) can open the file as "read-only" to prevent the user from editing the superfile's content.

[0036]

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

[0037]

[0042] As a result of client devices 120a and 120b maintaining communication with the super file server 110, any updates made to the contents of the super file by, for example, the owner or "editor" can be immediately propagated to any client devices 120a and 120b that have a copy of the super file opened by the super file server. Client devices that do not have a copy of the super file open will instead receive the updated content when the super file is next opened. Similarly, if user permissions are changed, the updated permissions are immediately propagated to affected users who have the super file open. For example, if a user has "editor" permissions and their permissions are changed to "viewer" permissions while the file is open, the client device will receive the changed permissions from the super file server 110 and ensure that no changes are saved to the super file. In some cases, changes made by an editor while the super file was open before the permission change will be rolled back (reverted to the previous state), but in other cases, only editing will be prohibited. Furthermore, if a user's permission to access the file is invalidated, the contents of the super file become immediately inaccessible, for example, by closing the super file and discarding the cryptographic information used to access the contents. In some cases, the superfile may remain open, but its content will no longer be presented; instead, a message will appear indicating that permissions have been changed.

[0038]

[0043] It should be understood that, since client devices 120a-n are not under the control of the super file server 110, the super file server 110 itself cannot guarantee that a user has not tampered with one or more applications run by a client device in order to enable functions that would otherwise be prohibited. However, even if a user attempts to illegally modify the contents of a super file, the modification is detectable by the super file server 110 or another unmodified client device 120a-n. As described above, a user with “editor” permission can modify the contents of a super file, and this is then propagated to the super file server 110 and then to other users who have a copy of the super file. However, if a user tampers with a super file and modifies its contents, the super file server 110 will reject the modification based on the permissions maintained by the super file server 110. Therefore, a user can modify their own copy of a super file, but it will not spread to others via the super file server 110. Alternatively, a user could tamper with the contents of a super file and attempt to distribute the file to another user (in this example, the “recipient”), for example, via email.

[0039]

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

[0040]

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

[0041]

[0046] Referring to Figure 2, which 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 contains any type of content created by the author. Suitable examples of content include copyrighted 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 designs, or manufacturing files, etc.). In some cases, the content payload 220 may contain another superfile.

[0042]

[0047] To protect the contents of a 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, like the Advanced Encryption Standards (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) can be used to reduce the size of the content payload 220. For content payloads 220 that do not contain sensitive information, such as user manuals or resumes, compression may suffice, but for other types of information, encryption may be preferable. However, the creator of the superfile may choose whether encryption or compression is used, and if used, may choose which type is used. Furthermore, the creator (or another user with sufficient permission) can change or remove (or reapply) encryption or compression from the superfile at any time.

[0043]

[0048] The superfile header 210 includes information that identifies 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, and the checksum or hash value of the content payload 220. It may also include specific bibliographic information such as the creator of the superfile, the creation date of the superfile, the checksum or hash value of the bibliographic information, and the checksum or hash value of the entire superfile 220. Generally, the superfile header 210 may include any information about the superfile that may be desirable to maintain along with the superfile content, and specific information that may be necessary for the client device to contact the superfile server and access the content payload 220.

[0044]

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

[0045]

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

[0046]

[0051] In this example, superfile servers 310a-m have the ability to read and write blockchains 332a-k, and client devices 320a-n can read records within blockchains 332a-k. However, in some examples, only superfile servers 310a-m can access the blockchain network. When a new superfile is created, the creator's client device contacts the superfile server (e.g., superfile server 310a) to register the superfile. Superfile server 310a receives a copy of the superfile and establishes a blockchain for the superfile. When other users receive a copy of the superfile (or when the creator accesses the superfile again), they can verify the integrity of the superfile by accessing the corresponding blockchain and traversing it as needed. The blockchain also provides ownership information about the superfile, which may include records of 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 a block to the blockchain, and the blockchain provides an audit track 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, a user (e.g., a creator) or organization may operate its own superfile server and manage its own set of superfile and blockchain networks. For example, a film studio could manage its own superfile server and blockchain network 330, which would allow the studio to create superfiles to manage access to films it publishes, publish updates, or embed different features within films over time. For example, a film studio could update film superfiles to change trailers or marketing promotions related to various films. Similarly, other creative organizations such as advertising agencies, recording studios, and research institutes 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] Therefore, the exemplary systems described herein may include the use of a blockchain network to guarantee the authenticity and validity of the superfiles, while the superfile server mediates access to the superfile content. However, the use of 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 the in-system interaction for remote ownership and content control of media files on an untrusted system as described in this disclosure. The system includes several client devices 410a-c, a super file server, and a blockchain network 430.

[0050]

[0055] This sequence begins with the user of client device 410a creating content and saving it as a superfile 440. This causes client device 410a to send a message to the 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 the superfile server 420. The superfile includes both a header and a content payload, similar to the superfile example described above with respect to Figure 2. The header contains a unique identifier for the superfile that 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 a superfile identifier from the superfile server 420. Client device 410a can then insert the superfile identifier into the superfile header.

[0051]

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

[0052]

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

[0053]

[0058] In this example, as described above with respect to Figure 3, the blockchain network may be distributed across multiple super file servers and client devices. Therefore, adding a new blockchain to the blockchain network may involve distributing one or more blocks between different computing devices, such as one or more of the super file servers 420 or 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 on another client device 410b. For example, the creator may email the superfile to the recipient or save it to a portable storage device (e.g., a thumb drive, portable hard drive) that can be physically connected to the other client device 410b. Since the superfile is a self-contained unit like a conventional file and is stored by the computing device as a conventional file, it can be easily transferred to other computing devices or storage devices.

[0055]

[0060] Next, the recipient opens the superfile 446 using the client device 410b. To open a superfile, the user can double-click the icon corresponding to the superfile, such as in a graphical user interface ("GUI") provided by the client device's OS. In response to user input to open a superfile, the recipient's client device 410b determines that the selected file is a superfile and determines which superfile server to contact to open the file. For example, an application can contact a superfile server by retrieving information from the superfile itself, for example, using a URI or IP address stored in the superfile header. 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] Messages transmitted by client device 410b may include user credentials, 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 superfile that client device 410b is attempting to open, such as a superfile identifier, checksum, or hash value. If user credentials are not provided, the superfile server 420 may request them.

[0057]

[0062] In response to receiving a request from client device 410b to open file 446, the superfile server 420 determines whether the recipient has permission to access the superfile, and if so, what level of access they are assigned. The superfile server 420 can also perform checks on the superfile itself, such as determining whether the received checksum or hash value matches the checksum / hash value stored in the corresponding blockchain record of the superfile. In addition, the 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, the superfile server 420 can search the blockchain corresponding to the superfile to identify a record with a checksum / hash value that matches the one received from client device 410b.

[0058]

[0063] If the received checksum / hash value matches the latest version of the superfile in the blockchain, the 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, which is described in more detail below in items 470 and 472. If the checksum or hash value does not match any block in the blockchain, the 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 superfile's content payload, it can send the information necessary to access the content payload 458. Such information may include one or more encryption keys, an identification of the compression algorithm used to compress the content payload, and so on. 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 neither encrypted nor compressed, it may not receive 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 access information, it can access the content payload. However, in this example, the client device 410b decrypts the superfile's content, but only decrypts the content into volatile system memory to enable presentation to the user. The client device 410b does not decrypt the content into non-volatile storage. Therefore, no separate file is created on the decrypted client. This can be useful in preventing access to the content without first contacting the super file server 420.

[0060]

[0065] While accessing the content payload, the client device 410b may report information about its use of the superfile 450 to the superfile server 420. The usage information may be reported periodically (e.g., every minute) or in response to events that occur while the superfile is open (e.g., in response to scrolling to a new page, playing / pausing / rewinding a movie or audio, zooming in on a photo, etc.). Usage information may include identification of actions performed on 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 the GUI presented to the user, when the content was minimized, and so on. It can also detect potential unauthorized actions such as attempting to capture screenshots of the presented content, attempting to modify the content payload, or attempting to export the content payload to a separate file. Such usage information may be reported to the Super File Server 420, thereby enabling the maintenance of statistics related to the Super File. Such information may be used to determine the level of engagement with the content, to determine the interests of different users, to determine advertisements or other monetization information related to the content, etc. Such information may also be accessible to the creator or owner of the Super File, and may be obtained by issuing a request to the Super File Server 420 or by accessing an account maintained by the Super File Server 420.

[0061]

[0066] At some point, the recipient may further distribute the superfile to other users, such as the user of client device 3 (410c) ("second" recipient). With respect to item 444, the recipient may distribute the superfile to any other user using any appropriate mechanism. The second recipient may then attempt to open the superfile, thereby initiating a similar process of sending one or more messages 462 to the superfile server 420 and receiving access information 464, if the second recipient is authorized to access the content payload. The second recipient's client device 410c then also maintains 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 a superfile, or other editor (referred to as the creator in this example), can modify the superfile's content payload. When this happens, 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, and so on.

[0063]

[0068] When a modification is reported 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 persistent and immutable record of the superfile, while being revised over time.

[0064]

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

[0065]

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

[0066]

[0071] In response to receiving the modified file access permission, the superfile server 420 determines that client devices 410b-c do not currently have permission to access the contents of the superfile, and therefore the superfile server 420 sends one or more messages 482,484 to client devices 410b-c to immediately interrupt the presentation of the contents of the superfile and to discard any access information (e.g., encryption keys) previously received by each client device 410b-c, if not already discarded. To further protect the contents from unauthorized access, client devices 410b-410c may also overwrite the memory containing the decrypted contents to ensure that the decrypted contents have been completely erased from the client's device. Thus, the creator can disable (or grant) access in real time to anyone who has 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 demonstrate specific functionality. However, systems with significantly more components are conceivable, such as tens, hundreds, or thousands of super file servers interacting with thousands or millions of client devices, and can provide similar functionality 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 embodiments of the method. While these embodiments may be related to each other, each computing system may perform its own distinct method, which may include receiving input from or transmitting information to another computing device.

[0069]

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

[0070]

[0075] In block 514, the user chooses to store the content as a superfile. This may be done after the content has been stored in an existing file according to a single 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 the 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 an appropriate superfile structure and store the content within the superfile's content payload. During this process, the application may prompt the user to provide certain information, such as access control information, a selection of one or more encryption options, a selection of one or more compression options, and a selection of a superfile server provider. Based on the provided information, the application can generate or complete the header portion of the new superfile. The application can then store the superfile's content in non-volatile memory, such as a hard drive, or in cloud storage.

[0071]

[0076] While generating the superfile, the client device 510 contacts the superfile server 520 (for example, a superfile server selected by the user or a superfile server automatically selected by the application) to provide 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 provided to the client device 510, but in some examples, the client device 510 can generate its own unique identifier for the superfile.

[0072]

[0077] In addition to obtaining a 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 keys (or more keys) from the superfile server 520. The client device 510 then encrypts the superfile content using the encryption keys.

[0073]

[0078] In block 522, the superfile server 520 registers a superfile by creating a record in the datastore corresponding to the superfile. The record may include information about the superfile, such as a superfile identifier, the owner of the superfile, and the 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., symmetric encryption key, asymmetric encryption key pair, etc.) or compression information. In addition to creating a record in the datastore, the superfile server 520 may generate and provide to the client device 510 a confirmation that the superfile has been successfully created.

[0074]

[0079] In block 524, the superfile server 520 adds a blockchain to the blockchain network. The new blockchain is associated with a new superfile, and a block is created in the blockchain based on the new superfile. The block may contain information similar to that described above for block 522. It may also contain some or all of the superfile's content (such as the header or content payload). By including the content payload, the superfile server 520 can provide the content payload to other computing devices that open the superfile, for example, to update a copy of the superfile with the current content or to repair a corrupted copy of the superfile. Furthermore, depending on the implementation, any appropriate information can be stored in a block within 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 user, and other users can access the contents of the superfile, as described in more detail below.

[0076]

[0081] It's important to understand that not all superfile systems can utilize blockchain technology. Therefore, in some examples, block 524 may be omitted.

[0077]

[0082] Referring now to Figure 6, which shows an exemplary method 600 for accessing, modifying, and updating a superfile. Method 600 in this example includes three different computing systems that perform different embodiments of the method. While these embodiments may be related to each other, each computing system may perform its own distinct method, which may include receiving input from another computing device 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 downloaded 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] In block 614, the client device 610 opens a superfile. Opening a superfile may include accessing the contents of the superfile, or it may not include accessing encrypted or compressed data stored within the superfile's content payload. A user can use the client device 610 to open a superfile as generally described above with respect to items 446, 462, etc., in Figure 4. Furthermore, opening a superfile may include sending information to the superfile server 630 in order to obtain access to the contents stored within the superfile, as described above with respect to items 446, 462.

[0080]

[0085] In block 632, the super file server 630 receives user credentials from the client device 610 that can identify the user of the client device 610. User credentials may include user account information (e.g., username and password), an authenticable token associated with the user's identity established by a trusted organization, etc. In some examples, if user credentials are not received, the super file server 630 may respond to the client device 610 with a request for user credentials. In some examples, if user credentials are not received, the super file server 630 may treat the user as an anonymous user.

[0081]

[0086] In block 634, the superfile server 630 determines the access permissions to the superfile for the users of the client device 610. Access permissions may be established for individual users, predetermined user groups, etc. Therefore, based on user credentials, the superfile server 630 can determine whether a user has specific access permissions to the superfile, such as access to view, edit, or transfer ownership. 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 in Figure 5, or in the blockchain of the superfile.

[0082]

[0087] Access permissions for different users may be enforced by defining permission groups, each with specific types of permitted and prohibited actions, and assigning users to one of these groups, or by establishing custom-tuned permitted and prohibited actions for each user. Groups may be established for owners, editors, viewers, time-limited viewers, etc. Actions that may be permitted 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 of the superfile, a portion of the content payload, or a smaller number than the entire content payload. In this example, the superfile contains an encrypted content payload, and the superfile server 630 determines that the requesting user has permission to access the contents of the superfile. In response to this determination, the superfile server 630 retrieves cryptographic information from the record corresponding to the superfile stored in the datastore accessible by the superfile server 630 and provides the client device 610 with the cryptographic information necessary to decrypt the content payload. In an example where the content payload is compressed, the superfile server 630 may also provide information indicating the type of compression applied to the content payload.

[0084]

[0089] In block 616, the client device 610 receives cryptographic information and decrypts the content in the superfile. In this example, the superfile contains only one content payload, but if the superfile contains multiple content payloads, the client device 610 may receive the cryptographic information necessary to decrypt some or all of the content payloads, and after receiving such information, decrypts the content payloads from 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. Compression may be applied before or after encryption, and therefore 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 retained while the file is open.

[0085]

[0090] In block 618, the client device 610 presents the decrypted superfile content to the user. Depending on the type of content in the superfile, the presentation method may differ, such as audio playback, video display, or document presentation.

[0086]

[0091] In block 620, the client device 610 maintains a communication connection to the super file server 630 and sends usage information to the super file server 630 based on the user's use of the content. For example, the client device 610 can report which parts 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, parts of a movie or television program played by the user), whether the user rewound, paused, or fast-forwarded the content, and how long the user had the super file open. It can also provide other information (e.g., attempts at prohibited actions, including editing documents, changing permissions, or viewing ownership information).

[0087]

[0092] In some examples, usage information may be transmitted over time while the superfile is open, but it should be understood that it may also be collected by the client device 610 and transmitted only when the client device 610 closes the file. Further mechanisms for reporting usage information may be used. Also, in this example, the usage information is sent to the same superfile server 630 that was initially contacted to open the superfile, but the usage information may be sent to any suitable computing device. For example, the owner of the superfile may include information indicating where the usage information should be sent when the superfile was 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 interrupted immediately or after a certain period of time. For example, a viewer of superfile content may lose their internet connection, at which point the client device will interrupt the presentation of the superfile content. While communication with the superfile server 630 is interrupted, the encryption key may be further discarded to prevent access to the superfile content. Once the connection is re-established, the client device 610 can present the content again, which may include requesting encryption information from the superfile server 630 again. Disabling 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 work. Other users may have shorter timeout periods. For example, non-anonymous viewers of the content may have a short timeout period (e.g., 5-10 minutes) to smooth out the internet server, which may be sporadic in some cases. Anonymous viewers of content may immediately lose access if interrupted. However, as different examples show, any appropriate scheme may be used.

[0089]

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

[0090]

[0095] In block 662, the second client device modifies the content stored in the same copy of the superfile accessed by client device 610. For example, the owner of the superfile content can use client device 610 to modify the superfile content while client device 660 has the copy of the superfile open. The modifications made by client device 660 may be of any kind, including modifications to the content payload, the header portion, the addition of a new content payload, or the deletion of an existing content payload.

[0091]

[0096] After making changes, client device 660 provides the changes to the super file server 630. The changes may be sent as an update to only a specific portion of the super file's content, or they may be sent by sending the entire updated super file to the super file server 630. Furthermore, the changes may 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.

[0092]

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

[0093]

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

[0094]

[0099] In an example where multiple superfile servers are associated with a particular superfile, each may access the same blockchain network and manage to create and add blockchains or blocks to the blockchain network. Furthermore, each may access the same data store to retrieve or update information about the superfile. Additionally, 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 has been received, and the other superfile servers can determine which client devices currently have a copy 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 contains 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] In block 622, the client device 610 receives the modified content from the super file server 630 while the super file is open. As described above, the modified content may be pushed by the super file server 630, or it may be requested by the client device 610 in response to, for example, a user indicating that they want to receive the modified content.

[0097]

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

[0098]

[0103] Therefore, this exemplary method demonstrates 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 latest version of the superfile, and the owner of the content in the superfile can ensure that the copy of the superfile always presents the current version of the content. If the user closes the superfile before the changed content is received, it should be understood that 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 then provide the changed content. Therefore, even if the user does not have the superfile open when the changes are 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] Referring now to Figure 7, Figure 7 illustrates an exemplary method 700 for remote ownership and content control of media files on an untrusted system. The example shown in Figure 7 is described with respect to the exemplary system 100 shown in Figure 1, but any suitable system provided herein can be used.

[0100]

[0105] In block 712, the client device (for example, client device 120a) receives a request to open a superfile, such as when the user double-clicks the icon corresponding to the superfile or selects a superfile to open within the application.

[0101]

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

[0102]

[0107] In block 718, the client device 120a decrypts the superfile content using the received access information. Depending on the encryption or compression applied to the content (if any), block 718 may be omitted, or instead involve decompressing the content, or may include both decompression and decryption of the content.

[0103]

[0108] In block 720, the client device 120a generally presents the super file content to the user as described above with respect to block 618 in Figure 6.

[0104]

[0109] In block 722, the 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 in Figure 4 or block 622 in Figure 6.

[0105]

[0110] In block 724, the client device 120a presents the modified superfile content, generally as described above with respect to block 624 in Figure 4 or Figure 6.

[0106]

[0111] In block 726, the client device 120a receives an access revocation instruction from the super file server, generally as described above with respect to items 482 and 484 in Figure 4.

[0107]

[0112] In block 728, client device 120a disables access to the superfile content. For example, client device 120a can discard encryption keys, such as the encryption key obtained in block 716. Client device 120a can also erase any decrypted copies of the content stored in memory, for example, to present the content to the user. In some examples, client device 120a can also delete copies of the superfile from long-term storage (e.g., a hard disk).

[0108]

[0113] It should be understood that the blocks in this exemplary method are executed in a specific order, but the blocks may be executed in a different order, and some blocks may not be executed 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. In addition, if the superfile is modified multiple times, blocks 722 and 724 may be repeated.

[0109]

[0114] Referring now to Figure 8, Figure 8 illustrates an exemplary method 800 for remote ownership and content control of media files on an untrusted system. The example shown in Figure 7 is described with respect to the exemplary system 100 shown in Figure 1, but any suitable system provided herein can be used.

[0110]

[0115] In block 812, the super file server 110 receives the identification of a new super file from a client device (e.g., client device 120a), generally as described above with respect to item 440 in Figure 4 or blocks 514 and 522 in Figure 5.

[0111]

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

[0112]

[0117] In block 816, the super file server 110 receives requests from client devices to access super file content, generally as described above with respect to items 446, 462 in Figure 4 or block 614 in Figure 6.

[0113]

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

[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 in Figure 4 or block 636 in Figure 6.

[0115]

[0120] In block 824, the super file server 110 receives modifications to the super file content from the client device, generally as described above with respect to item 466 in Figure 4 or block 638 in Figure 6.

[0116]

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

[0117]

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

[0118]

[0123] In block 830, the superfile server 110 receives modifications to the access levels of the superfile. For example, the owner of the superfile can modify the access levels of different groups of users or individual users. The superfile server 110 receives these changes and can update the corresponding records in the datastore 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 a command to a client that has an open copy of the superfile. For example, if a modification to the access level disables access for one or more users, the superfile server 110 sends a command to any client device that has an open superfile to disable access to the superfile for one of the identified users, as described above with respect to items 482, 484 in Figure 8 or blocks 726, 728 in Figure 7. If the modification to the access level lowers the access level (e.g., from editor to viewer), the superfile server 110 can send a corresponding command, thereby preventing the corresponding client from making further modifications to or saving the superfile content. The client device may present the user with the change in access level. Similarly, if the modification to the access level raises the user's access level (e.g., from viewer to editor), the client device may present the user with a notification of the change in access level and enable the corresponding application option to edit and save the changes to the superfile content.

[0120]

[0125] It should be understood that the blocks in this exemplary method are executed in a specific order, but the blocks may be executed in a different order, and some blocks may not be executed at all. For example, if no modified superfile content is received, blocks 824-828 may be omitted. Similarly, if no access changes are received at any access level, 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 here to Figure 9, Figure 9 shows 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 as described in this disclosure. The exemplary computing device 900 includes a processor 910 that communicates with 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 memory 920 to perform one or more methods for mediating participant interaction during a video webinar conference, as in different examples, such as some or all of the exemplary methods 500-800 described with respect to Figures 5-8. The computing device 900 also includes one or more user input devices 950, such as a keyboard, mouse, touchscreen, and microphone, for accepting user input. The computing device 900 also includes a display device 940 for providing visual output to the user.

[0122]

[0127] The computing device 900 also includes a communication interface 930. In some examples, the communication interface 930 can enable communication over one or more networks, including a local area network ("LAN"), a wide area network such as the Internet ("WAN"), a metropolitan area network ("MAN"), and point-to-point or peer-to-peer connections. Communication with other devices can be achieved using any suitable network protocol. For example, a 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] While some examples of methods and systems described herein are described in relation to software running on various machines, methods and systems may also be implemented as specifically configured hardware, such as a field-programmable gate array (FPGA), for particularly performing the various methods described herein. For example, examples can be implemented in digital electronic circuits, or in computer hardware, firmware, software, or a combination thereof. In one example, the apparatus may include one or more processors. The processors include computer-readable media, such as random access memory (RAM), coupled to the processors. The processors execute 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 include programmable electronic devices, such as PLCs, programmable interrupt controllers (PICs), programmable logic devices (PLDs), programmable read-only memory (PROMs), electronically programmable read-only memory (EPROMs or EEPROMs), or other similar devices.

[0124]

[0129] Such a processor may include, or communicate with, a medium (e.g., one or more non-temporary computer-readable media) that can store processor-executable instructions that, when executed by the processor, cause the processor to execute the method according to this disclosure so as to be executed or assisted by the processor. Examples of non-temporary computer-readable media may include, but are not limited to, electronic, optical, magnetic, or other storage devices that can provide processor-executable instructions to a processor (such as a processor in a web server). Other examples of non-temporary 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 that a computer processor can read. The described processors and processes may reside in one or more structures or be distributed through one or more structures. The processor may include code for executing the method (or part of the method) according to this disclosure.

[0125]

[0130] The above-mentioned examples are provided for illustrative and explanatory purposes only and are not intended to be exhaustive or to limit this disclosure to the exact form disclosed. Numerous modifications and adaptations will be apparent to those skilled in the art without departing from the spirit and scope of this disclosure.

[0126]

[0131] References to examples or embodiments herein mean that certain features, structures, operations, or other characteristics described in relation to the examples may be included in at least one embodiment of this disclosure. This disclosure is not limited to any specific example or embodiment described herein. The appearance of phrases such as “in one example,” “in an example,” “in one implementation,” or “in an implementation,” or variations thereof, in various parts of this specification does not necessarily refer to the same example or embodiment. Any particular feature, structure, operation, or other characteristic described herein in relation to one example or embodiment may be combined with other features, structures, operations, or other characteristics described in relation to any other example or embodiment.

[0127]

[0132] The use of the word "or" in this specification is intended to cover both inclusive and exclusive OR conditions. In other words, A or B or C includes any or all of the following alternative combinations appropriate for a particular use: A alone, B alone, C alone, A and B only, A and C only, B and C only, and A, B and C.

Claims

1. A step of receiving a request from a client computing device to open a superfile stored in a memory device on the client computing device, wherein the superfile contains encrypted content and the request includes user credentials. Steps include: in response to receiving the request to open the superfile, the client computing device communicating a request to a remote server to access the superfile, wherein the request includes credentials associated with a user account; The steps include receiving encrypted information from the aforementioned remote server, The steps include: decrypting the encrypted content using the encrypted information; The steps include accessing and presenting the decrypted content, The steps include maintaining communication with the remote server while the decrypted content is being accessed, A method that includes this.

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

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

4. While the decrypted content is being accessed, The steps include receiving modified and encrypted content from the remote server, The steps include replacing the encrypted content with the modified encrypted content, The steps include presenting the modified and encrypted content, The method according to claim 1, further comprising:

5. While the decrypted content is being accessed, The steps include receiving an instruction that access rights to the encrypted content have been lost, The steps include: ending the presentation of the decrypted content, The steps include deleting the decrypted content and The method according to claim 1, further comprising:

6. While the decrypted content is being accessed, The client computing device receives the modification of the decoded content, The steps include updating the encrypted content based on the aforementioned modifications, The steps include replacing the encrypted content with the updated encrypted content in the memory device of the client computing device, The steps include providing the updated and encrypted content to the remote server, The method according to claim 1, further comprising:

7. While the decrypted content is being accessed, The steps include detecting the loss of connection to the remote server, The steps include: ending the presentation of the decrypted content, The steps include deleting the decrypted content and The method according to claim 1, further comprising:

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

9. The steps include receiving a request from a remote client device to access encrypted content in a superfile, wherein the request includes user credentials, and the superfile is stored in the memory device of the remote client device and contains encrypted content; The steps include determining the authorization level for accessing the encrypted content, In response to the determination of the aforementioned authorization level, The steps include providing encrypted information to the remote client device, The steps include 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, Methods that include...

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

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

12. The steps include receiving the modified content associated with the superfile, The steps include determining a second remote client device that has an open copy of the superfile, A step of transmitting updated superfile information to the second remote client device, wherein the updated superfile information includes the modified content, The method according to claim 9, further comprising:

13. The steps include generating a block record for the blockchain corresponding to the superfile based on the modified content, The steps include adding the aforementioned block record to the blockchain, The method according to claim 12, further comprising:

14. Steps include receiving a request from a third remote client device to access encrypted content in a copy of the superfile, wherein the request includes second user credentials, and the copy of the superfile is stored in a second memory device of the third remote client device and includes the encrypted content; The steps include determining the authorization level for accessing the encrypted content, In response to the determination of the aforementioned authorization level, A step of providing updated superfile information to the third remote client device, wherein the updated superfile information includes the modified content, The steps include providing encrypted information to the third remote client device, The steps include 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 according to claim 12, further comprising:

15. The steps include receiving a modification to one or more access levels of the superfile, The steps of sending a command to one or more clients having an open copy of the superfile based on the modification to one or more access levels of the superfile, The method according to claim 9, further comprising:

16. The steps include receiving instructions from a remote client device to create a new superfile, The steps include creating one or more records in the datastore associated with the new superfile, A step of storing one or more encryption keys in one or more records, wherein one of the one or more keys is used to encrypt the contents in the superfile, The steps include receiving and storing a copy of the aforementioned superfile, Methods that include...

17. The steps include receiving one or more access restrictions associated with the superfile, The steps include storing the access restriction in one or more records, The method according to claim 16, further comprising:

18. The steps include generating a new blockchain corresponding to the new superfile, A step of inserting a block into the blockchain, wherein the block includes a copy of the superfile, The method according to claim 16, further comprising:

19. The method according to claim 18, further comprising the step of storing one or more access restrictions for the superfile in the block.

20. The method according to claim 18, further comprising the step of storing one or more check values ​​for the superfile or the contents of the superfile in the block.

Images