Computer method for secure disclosure of information

A system provides an immutable record of human creative output as one or more secure disclosure threads. The immutable record may be stored on a blockchain. Addresses to the data corresponding to the one or more secure disclosure threads may be encrypted and stored on a blockchain. The immutable record and the addresses to the data may be stored on the same blockchain. The immutable record and the addresses to the data may be stored on different blockchains.

SUMMARY

According to an embodiment, a computer method for providing an immutable record of human creativity includes displaying a graphical user interface (GUI) to a user including a directory screen, the directory screen displaying one or more selection objects each configured for accessing a respective corresponding secure disclosure thread. The computer method includes receiving a user-input selection of one of the selection objects and receiving a cryptographic key. The computer method includes decrypting, using the cryptographic key, at least a portion of the secure disclosure thread corresponding to the selected one of the selection objects, and displaying the portion of the secure disclosure thread on the graphical user interface.

According to embodiments, a computer method includes receiving a securely stored disclosure. The method includes receiving, into a server computer from a first user via a graphical user interface (GUI) displayed on an electronic display of a first user computing device, a computer data file carrying a representation of a human creative product of the first user. The first user may have a first user account. The method further includes receiving, from the first user via one or more entry fields of the GUI or via actuation of icons of the GUI, one or more character strings constituting metadata related to the human creative product. The method also includes encrypting the computer data file and storing the encrypted computer data file in a high capacity storage service at an addressable storage location. The addressable storage location is encrypted to form an encrypted storage location and is recorded in a low or medium capacity data storage structure. The method further includes writing, in a database, a database record associated with the first user account, the database record including an addressable portion of the low or medium capacity data storage structure. The database may be stored locally to the server computer, such as in in a RAID array, or may be stored in one or more remote resources, such as in cloud storage. The database may include a conventional database such as a SQL variant, or in another service such as MongoDB. The method also includes outputting to the GUI an indication carrying information associated with the first user account, the indication corresponding to the stored computer data file representing the human creative product.

According to an embodiment, a computer method includes receiving, from a user via a graphical user interface, metadata related to a disclosure, recording the received disclosure in an encrypted high capacity data storage structure, and logging the recording in an access history to an encrypted medium capacity data storage structure different from the high capacity data storage structure. The computer method may further include transmitting access information to a second user for retrieving some or all of the disclosure, receiving a request for the secure and/or secret disclosure, transmitting corresponding data for decryption using a “Public” decryption key provided to the second user, and logging the transmission in the access history to the encrypted medium capacity data storage structure. The metadata may be written to a third data storage structure. Further disclosures by the user and/or the second user may similarly be securely recorded. The computer method may include displaying a directory screen showing the existence and linking to the encrypted disclosure. The high capacity data storage structure may include a blockchain carried by non-transitory computer readable media distributed across a plurality of devices. The medium capacity data storage structure may include a blockchain carried by non-transitory computer readable media distributed across a plurality of devices. The third data storage structure may include a blockchain carried by non-transitory computer readable media distributed across a plurality of devices.

DETAILED DESCRIPTION

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. Other embodiments may be used and/or other changes may be made without departing from the spirit or scope of the disclosure.

FIG.1is a simulated graphical user interface screen100showing a secure disclosure directory, according to an embodiment. The secure disclosure directory screen100includes one or more selection objects102a,102b,102ccorresponding to current secure disclosure threads. The term “disclosure thread”, as used herein, may refer to an electronic record containing or configured to receive disclosure of a creative effort. Disclosure may include textual, graphic, video, audio and/or other information including detail, examples, history, and/or background related thereto, etc., all related to a result of human creativity. Non-limiting examples may include details of an invention, trade secret, process, formula, or the like. The secure disclosure directory screen100may additionally or alternatively display past (e.g., closed) secure disclosure threads. A user may initiate a process to review and/or add new material to a current secure disclosure thread by graphically actuating its corresponding object. The secure disclosure directory screen100may also include an Add New Disclosure object104. The user may initiate a process to start a new secure disclosure thread by graphically actuating the Add New Disclosure object104.

A Your Secure Disclosure object106may be provided to select the secure disclosure directory screen100view that includes the current secure disclosure thread objects102a,102b,102cthat were initiated by the user.

The secure disclosure directory screen100selected by the Your Secure Disclosure object106may include a partial or complete history of the user's prior secure disclosures. The selection objects102a,102b,102cenable the user to access and view previous disclosure objects or previous disclosure objects or disclosure threads.

The simulated graphical user interface screen100is part of a secure disclosure system that utilizes blockchain to enable users to instantly affirm inventorship and secure evidence of prior art. When the user has an inventive or creative moment, whether the user jots the idea down on a piece of paper and snaps a picture, makes an audio or video recording of the concept, or creates a detailed document describing the invention, the secure disclosure system can help the user to simultaneously create a permanent, encrypted and immutable record of the invention or creation. Users can share the secure disclosure with colleagues or collaborate with peers with confidence because the user's contribution to the art is immutably recorded.

A Shared With Me object108may similarly select a secure disclosure directory screen100that includes current selection objects (e.g.,102a,102b,102c) corresponding to disclosure threads shared with the user by one or more second users.

According to an embodiment, selecting the Add New Disclosure object104enables the user to initiate a process to start a new disclosure thread.

FIG.2is a simulated graphical user interface screen200from which a new disclosure or disclosure thread can be added, according to an embodiment. The screen200can be accessed by selecting the Add New Disclosure object104from the secure disclosure directory screen100shown inFIG.1.

According to an embodiment, the screen200includes a Title field202. The user can select the title field202in order to add a title for the new disclosure. The user can type or paste a title into the title field202.

According to an embodiment, the screen200includes an Add Media object204. The Add Media object204enables the user to add one or more media files to the new disclosure. The user can add a media file to the new disclosure by dragging a media file onto the Add Media object204. Additionally or alternatively, the user can select the Add Media object204in the screen200that can provide a file browsing option to enable the user to browse a file system in order to add media files to the new disclosure.

According to an embodiment, the media files can include one or more of an image file, an audio file, a video file, a text file, a document file, a PDF file, or other types of media. When a user has a new creative idea, the user can make an audio recording, video recording, capture an image, make a drawing, or produce a document proving conception of the creative idea. The user can then upload the one or more media files to the add new disclosure screen200. In this way, the user can secure proof of conception of the creative idea. According to an embodiment, the media files are encrypted as a privileged asset. According to an embodiment, the media files are immutable and time stamped.

According to an embodiment, the screen200can include Added Media Indicator objects206a,206b. The Added Media Indicator objects206a,206brepresent media files that have already been added to the new disclosure. The Added Media Indicator objects206a,206bcan include a deletion object208that enables the user to delete the media from the new disclosure by selecting the deletion object208.

According to an embodiment, the screen200includes an Abstract field209. The user can select the Abstract field209in order to provide an abstract for the new disclosure. The abstract can include a brief overview or description of the content of the new disclosure.

According to an embodiment, the screen200includes a Keywords field210. The Keywords field210can enable the user to add keywords to the new disclosure as hashtags, metadata, or other kinds of labels. The keywords that have been added to the new disclosure can be utilized for search indexing.

According to an embodiment, the Keywords field210can display keywords that have already been added, as well as an object to delete those keywords that have already been added.

According to an embodiment, the screen200can include a Submit to Blockchain object212. The Submit to Blockchain object212can enable the user to submit the new disclosure to the blockchain. Submitting the disclosure to the blockchain creates an immutable record of the new disclosure, according to an embodiment.

FIG.3is a simulated graphical user interface screen300that enables sharing settings to be configured, according to an embodiment. By selecting among the various options shown on the screen300, the user can define who may access disclosures that have been added to the system.

According to an embodiment, the screen300includes an Institutional Sharing field302. The Institutional Sharing field302enables the user to select whether or not guest access will be granted to users within an organization or an institution selected by the user. The Institutional Sharing field302enables the user to enter email domains defining users that will be granted guest access. The user can enable or disable institutional sharing from the Institutional Sharing field302. According to an embodiment, the Institutional Sharing field302grants read-only access to other people within the selected institution or organization. According to an embodiment, the selected institution or organization is a company, a business, an organization, or an institution to which the user belongs.

According to an embodiment, the screen300includes a Guest Access Enablement field304. The Guest Access Enablement field304enables the user to select whether or not guest access will be allowed.

According to an embodiment, the screen300includes a Non-Disclosure Agreement (NDA) Requirement field306. The NDA Requirement field306enables the user to select whether or not those who are granted guest access will be required to agree to an NDA before being allowed to view the disclosure thread.

According to an embodiment, the NDA Requirement field306can enable the user to use a default NDA or a custom NDA. If the user selects a custom NDA, then the user can upload the custom NDA to the system.

FIG.4is a simulated graphical user interface screen400including a disclosure thread that has been added by the user, according to an embodiment. The disclosure thread as shown on the screen400includes a title402, a digital signature of the owner403, a vault date405, an abstract404, media attachments406, a Download object408, a Share object410, an Edit Disclosure object412, a Delete object414, and a View Access History object416, according to an embodiment.

According to an embodiment, the screen400includes public-editable attributes. The public-editable attributes can include the title402and the abstract404. In an embodiment, a public-editable attribute may include a sharing configuration. The public-editable attributes are attributes that can be edited by the public, according to an embodiment.

According to an embodiment, the screen400includes immutable attributes. The immutable attributes can include the media attachments406, the vault date405, and the digital signature of the owner403. The immutable attributes cannot be edited by the public.

According to an embodiment, the user can download the disclosure thread via the Download object408. According to an embodiment, the user can share the disclosure thread by selecting the Share object410. According to an embodiment, the user can edit the attributes of the disclosure thread by selecting the Edit Disclosure object412. According to an embodiment, the user can delete the disclosure thread by selecting the Delete object414. According to an embodiment, the user can view the access history by selecting the View Access History object416. The access history indicates who has viewed the disclosure thread, and the date and the time when the disclosure thread was accessed.

FIG.5is a simulated graphical user interface screen500enabling the user to share access to the disclosure thread, according to an embodiment. The screen500can be accessed by selecting the Share object410from the screen400, according to an embodiment.

According to an embodiment, the screen500includes an address field502. The address field502enables the user to select an email address or other type of address for a guest with whom access to the disclosure thread will be shared.

According to an embodiment, the screen500includes a Comments field504. The Comments field504enables the user to enter a message that will be provided to the guest with whom the disclosure thread will be shared.

According to an embodiment, the screen500can include a Share object506. The Share object506enables the user to finally share the disclosure thread with another individual.

According to an embodiment, the screen500can include an NDA Opt-In object508. The NDA Opt-In object508can enable the user to require that the guest agree to an NDA before being granted access to the disclosure thread.

According to an embodiment, the screen500enables an audited invitation to be sent to a third party to view the disclosure thread.

FIG.6is a simulated graphical user interface screen600corresponding to a guest invitation message granting access to view a disclosure thread, according to an embodiment. The guest invitation message can be received by the guest as a result of the owner of a disclosure thread selecting the share object506after filling in the contents of the screen500.

According to an embodiment, the screen600includes a sender identification602. The sender identification602indicates the identity of the individual sending the guest invitation message.

According to an embodiment, the screen600includes a title604of the disclosure thread being shared.

According to an embodiment, the screen600includes a vault date606and a digital signature608of the owner of the disclosure thread.

According to an embodiment, the screen600includes message text610. The message text610corresponds to the message provided by the sender to the guest.

According to an embodiment, the screen600includes an NDA Opt-In object612. According to an embodiment, the guest cannot access the disclosure thread until the guest has agreed to the terms of the NDA.

According to an embodiment, the screen600includes a view secure disclosure object614. After the guest has agreed to the terms of the NDA, the guest can select the view secure disclosure object614.

FIG.7is a simulated graphical user interface screen700showing an access history of a disclosure thread, according to an embodiment. The screen700can be accessed by selecting the View Access History object416from the screen400ofFIG.4.

According to an embodiment, the screen700includes an access history702. The access history702is a secure and immutable audit record across all users that have accessed the disclosure thread in any way. The access history702can include the date and the time of the vault date of the disclosure thread, i.e., the date and time the disclosure thread was created, as well as the name of the user responsible for the vault date. The access history702can include the date and the time of each instance in which the disclosure thread was downloaded, as well as the identities of the individuals who downloaded the disclosure thread. The access history702can include the date and the time of each instance that the disclosure document was shared, as well as the identity of the individual that shared the disclosure thread. Although the dates shown in the access history702in the illustrative embodiment ofFIG.7are identical, in practice the access dates would correspond to actual dates and times of access that may be spread across many different times and/or dates. The access history702can also indicate the date and the time that an individual accepted the terms of an NDA for viewing the disclosure thread, as well as the identity of the individual that accepted the terms of the NDA.

According to an embodiment, the screen700includes an access history printing object704. The access history printing object704enables the user to print the access history702.

According to an embodiment, the screen700includes an Access History Download object706. The Access History Download object706enables the user to download the access history702.

FIG.8is a flowchart illustrating a computer method800for providing an immutable record of human creative output, according to an embodiment. At step802, a user identity is determined. This may be done using a conventional user account and a password and/or two-factor authentication, for example. Proceeding to step804, a graphical user interface (GUI) is displayed to the user. The GUI may include a directory screen (see, e.g.,FIG.1), the directory screen displaying one or more selection objects (e.g.,102a,102b,102c) each configured for accessing a respective corresponding secure disclosure thread. Step804includes receiving a user-input selection of one of the selection objects. Step806includes receiving a cryptographic key. Step806may include receiving a cryptographic key from the user via the GUI. In another embodiment, step806may include receiving the cryptographic key (e.g., a “private key”, a “public key”, or a “symmetrical key”) from a keystore that is associated with the user account. In some embodiments, the user may be required to provide authentication for accessing the keystore. The keystore may be provided by a medium capacity blockchain. According to an embodiment, receiving the cryptographic key, in step806, may include reading the cryptographic key held in custody and associated with a user account by a server application performing a plurality of steps (e.g., one or more of at least802-816) of the computer method800.

Step808includes obtaining an encrypted data location corresponding to the secure disclosure thread from a blockchain. In step810, the location of the encrypted data is decrypted. According to an embodiment, decrypting the location uses the cryptographic key. In step812, data corresponding to the secure disclosure thread is accessed at the data location. In an embodiment, obtaining an encrypted data location corresponding to the secure disclosure thread from a blockchain includes retrieving the encrypted data location from a medium capacity blockchain. The medium capacity blockchain may include Ethereum. In an embodiment, the data location is addressed as an address in a high capacity blockchain or distributed storage system. The high capacity blockchain may include BigChainDB or Avalanche, for example. In an embodiment, the data location may be a multi-hash in a distributed file system. The distributed file system may be or include an InterPlanetary File System (IPFS). The IPFS storage may be addressed via FileCoin.

Proceeding to step814, at least a portion of the secure disclosure thread corresponding to the selected one of the selection objects is decrypted using the received cryptographic key. In step816, the portion of the secure disclosure thread is displayed to the user via the graphical user interface.

Referring to step804, in an embodiment, displaying the GUI to the user includes displaying a selection object, of the one or more selection objects, for accessing a respective corresponding secure disclosure thread that is established by the user. In another embodiment, displaying the GUI to the user includes displaying a selection object, of the one or more selection objects, for accessing a respective corresponding secure disclosure thread that is shared with the user by a second user.

FIG.9is a system900diagram illustrating a non-limiting embodiment for how a secure disclosure thread is encrypted and decrypted, according to an embodiment.

Data is encrypted and stored in a hash tree, e.g., a Merkle tree, using IPFS and the reference to the data is hashed on the blockchain. A base58 network encoding library for the platform is located on a GITHUB repository which is used inside a command library904, identified as “Argos” inFIG.9. The command library904includes conversions from a selected high level language, such as Javascript, Python, or C#, etc., to low level commands supported by a blockchain. To add new secure disclosure materials to the secure disclosure thread, “some data” is sent from the web application902to the command library904.

The command library904encrypts and stores the data then hashes a data reference, shown as process906, and sends it to the medium capacity blockchain908.

For example:

“some data”→encrypt(aes256ctr)→store data in Merkle tree dag→sha.keccak256 hash the store id→bytes32→chain

Result on Blockchain:

To read a secure disclosure thread, the storing process is reversed in the command library904, shown as process910, to retrieve the data from the medium capacity blockchain908. The retrieved data provides one or more pointers to encrypted storage locations, from which data is retrieved to the web application902as requested by the user.

The medium capacity blockchain908has a built-in keystore912which stores all the keys for accounts, assets and attestations. When a call is made by an individual, the identity key exchange, in order to transact, is made as:

In other words, private keys may be held in trust by the medium capacity blockchain908provider, such as Ethereum.

Referring to the process906, to encrypt a Secure Disclosure, the Secure Disclosure is packaged and encrypted using protocols914. The encrypted Secure Disclosure is stored in an IPFS Merkle Tree916, and the address of the encrypted Secure Disclosure is (itself) encrypted in918, and then stored on the medium capacity blockchain908.

According to an embodiment, the address of the encrypted Secure Disclosure, under IPFS, is a hash result of its content. If a would-be hacker were to change a single bit in the original Secure Disclosure, the IPFS address would change and it would mismatch to the encrypted value stored on the blockchain. This would be evidence of tampering. Another way to think of it is that the immutable IPFS address stored on the medium capacity blockchain908points to a unique spot in the cloud (e.g., in a high capacity blockchain or distributed file system) that mathematically can only contain the original unaltered encrypted version of the Secure Disclosure.

Referring to the process910, to access a Secure Disclosure, the medium capacity blockchain908is accessed to obtain the encrypted address of the encrypted secure disclosure. The address is decrypted in920and the decrypted address obtains data from a storage asset (e.g., a high capacity blockchain) and is output to an IPFS Merkle Tree922. The IPFS Merkle Tree922is unpacked and decrypted, in924, using protocols.

The private keys may be held in trust by the blockchain provider (e.g., Ethereum) as a service to its clients, according to embodiments. Additionally or alternatively, one or more private keys may be entered by the user using the GUI of the web application902.

FIG.10is a flowchart illustrating a computer method1000for establishing a securely stored disclosure, according to an embodiment. The computer method1000may include, in operation1002, downloading data defining a graphical user interface (GUI) to a first user computing device, e.g., a smartphone, tablet, laptop computer, or other computing device. In operation1004, the method includes receiving, into a server computer from a first user via the GUI displayed on an electronic display of the first user computing device, a computer data file carrying a representation of a human creative product of the first user. The first user may have a first user account, e.g., for access to the server computer, upload of documents, review of shared documents, sharing access to documents to a second user account, and the like. In operation1006, the method1000includes receiving, from the first user via one or more entry fields of the GUI or via actuation of icons of the GUI, one or more character strings (or characters or preselected information) constituting metadata related to the human creative product. In operation1008the method includes encrypting the computer data file and, in operation1010, storing the encrypted computer data file in a high capacity storage service at an addressable storage location. According to an embodiment, encrypting the computer data file, in operation1008, may include hashing the computer data file. Operation1012includes encrypting the addressable storage location to form an encrypted storage location. Operation1014includes recording the encrypted storage location in a low or medium capacity data storage structure. In operation1016, the method includes writing, in a database stored at a location accessible to the server computer, a database record associated with the first user account. The database record includes an addressable portion of the low or medium capacity data storage structure. In operation1018the method includes outputting to the GUI an indication carrying information associated with the first user account. The indication may correspond to the stored computer data file representing the human creative product.

According to an embodiment, recording the encrypted storage location in a low or medium capacity data storage structure, in operation1014, includes recording the encrypted storage location as carried data in a blockchain transaction having a blockchain transaction identity. According to an embodiment, writing a database record associated with the first user account, in operation1016, includes writing the database record to include the blockchain transaction identity. According to an embodiment, storing the encrypted computer data file in a high capacity storage service at an addressable storage location, in operation1010, may include storing the encrypted computer data file in a distributed file system. Storing the encrypted computer data file in a distributed file system may include storing the encrypted computer file in an IPFS storage location.

The computer method1000may further include hashing the encrypted computer data file to derive a hash value. In such instance, the operation (1010) of storing the encrypted computer data file in a high capacity storage service at an addressable storage location may include storing the encrypted data file at a storage vector corresponding to the hash value. According to an embodiment, hashing the encrypted computer data file may include performing a multi-hash on the encrypted computer data file.

The computer method1000may further include an operation1020for receiving a command from the first user via the GUI to provide, to a second user having a second user account, access to the computer data file carrying a representation of a human creative product of the first user. The method1000may further include, in operation1022writing, in the database, a database record associated with the second user account. The database record may be associated with the second user account and may include data (a) to cause a second user account GUI to display an indication corresponding to the computer data file carrying the representation of the human creative product of the first user and (b) to provide second-user access to the computer data file via the second user account. The computer method1000may further include, in operation1024, receiving, from the second user via the second user account GUI displayed on an electronic display of a second user computing device, a command to display the computer data file. In operation1026, the computer method1000may include performing steps to display the computer data file on the electronic display of the second user computing device.

The method1000may also include receiving, in operation1028, a command from the second user via the second user account GUI, where the command is to receive a new version of the computer data file including information from the second user. The new version of the computer data file may be stored, in operation1030, in a second addressable storage location in the high capacity storage service, and recording the second addressable storage location in a second addressable portion of the low or medium capacity data storage structure. The computer method1000may include logging each access of the computer data file or the new version of the computer data file by the first user or the second user. Such log may be stored in and accessed via the database record associated with the first user account. The operation1030may further include writing database records associated with the first user account and the second user account including the second addressable portion of the low or medium capacity data storage structure and second metadata indicating that a new version of the computer data file is available.

The method1000may include a step1032, wherein the first user is notified of revision of the computer data file by the second user.

According to an embodiment, downloading data defining the GUI to the first user computing device in operation1002may include communicating, to the first user computing device, HTML data to a browser application running on the first user computing device. Alternatively, according to an embodiment, downloading data defining the GUI to the first user computing device, in operation1002, may include conveying, to the first user computing device, data defining an application configured to run on the first user computing device.