Automated licensing and management of digital assets

Abstract

Disclosed herein are systems and methods digital asset management using perfect secrecy encryption and transcryption technology. This can be used for signature / approval as well as digital ledgers without the need for a blockchain for generic assets. Digital assets and the associated meta data can be combined into a single digital bundle protected in perfect secrecy. The technology can be deployed in two different methods depending on the desired application; mutable and immutable.

Description

[0001] AUTOMATED LICENSING AND MANAGEMENT OF DIGITAL ASSETS

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to and benefit of U.S. provisional patent application 63 / 527,937 filed July 20, 2023, which is fully incorporated by reference and made a part hereof.

[0004] BACKGROUND

[0005] Companies have digital assets which could provide revenue if they can be cost-effectively and rapidly licensed out for an appropriate fee. Some complex license agreements simply take too long to bring to agreement by all parties involved and don’t bring a lot of value in this day and age with content being ingested into Large Language Models (LLM) or other Large Transformer Systems. Theft of these digital assets and digitally altered derivative products trying to avoid licensing tends to be more common. Digital Licensing of assets and the automation of this process provides additional revenue streams for these companies by making it simple and cost effective for content creators to properly license digital assets. This will significantly increase the licensed assets, thus increasing the value and bottom line of the asset owners.

[0006] SUMMARY

[0007] Disclosed and described herein is an Automated Licensing and Management system and method with quantum proof encryption that facilitates digital asset licensing. The type of assets can vary from digital images, documents, templates, videos, music, sound, code libraries, business data, research data, digital services such as news / weather / entertainment, and the like, as well as creative output from trained Large Language Models (LLM) and Large Transformer models to product either text, image, or video version of assets or derived assets. Automation of the process is desired to keep costs low and speed up licensing of the assets. The issue at hand is bundling both an asset, its licensing, and management in a tamper proof bundle. The following specification discloses embodiments of such systems and methods that license an asset, create the contract / terms (acceptable use) based upon licensees needs and licensors restrictions, bundle the asset with the former, and record a signed version of the terms by both licensor and licensee into a self-contained encrypted bundle for repeat use and direct billing of the licensee for use of the assets under the contract.

[0008] Artificial Intelligence (Al) Transformer technology such as LLMs can be leveraged in the disclosed approaches to licensing digital assets. The LLMs can either build legal documents to support the licensing model or read documents to obtain data for licensing and charging of a licensee.

[0009] Different licensing schemes can be selected depending on the needs of the licensor and licensee. These could include a per asset fee, per use fee, per word, per page, annual fee, etc. More complex embodiments could include licensing per view or per watch of end users.

[0010] Other systems, methods, features and / or advantages will be or may become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features and / or advantages be included within this description and be protected by the accompanying claims.

[0011] BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The components in the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding parts throughout the several views.

[0013] FIG. 1 illustrates an overview block diagram of an exemplary Automated Licensing and Management System;

[0014] FIG. 2A illustrates a block diagram of an example of Bundled Licensing with Asset;

[0015] FIG. 2B illustrates a block diagram of an example of Bundled Licensing; FIG 3A illustrates a block diagram of an example of Automated Licensing with Bundled Licenses and Asset;

[0016] FIG 3B illustrates a block diagram of an example of Automated Licensing with Bundled Licenses;

[0017] FIG 4 illustrates a block diagram of an example of Minimal License System Flow; and

[0018] FIG. 5 shows an example computing environment in which example embodiments and aspects may be implemented.

[0019] DETAILED DESCRIPTION

[0020] Before the present methods and systems are disclosed and described, it is to be understood that the methods and systems are not limited to specific synthetic methods, specific components, or to particular compositions. It is also to be understood that the terminology used in this entire application is for the purpose of describing particular embodiments only and is not intended to be limiting.

[0021] As used in the specification and the appended claims, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” one particular value, to “about” another particular value, or from “about” one value to “about” another value. When such a range is expressed, another embodiment includes from the one particular value, to the other particular value, or from the one particular value to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another embodiment. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint. “Optional” or “optionally” means that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.

[0022] Throughout the description and claims of this specification, the word “comprise” and variations of the word, such as “comprising” and “comprises,” means “including but not limited to,” and is not intended to exclude, for example, other additives, components, integers or steps. “Exemplary” means “an example of’ and is not intended to convey an indication of a preferred or ideal embodiment. “Such as” is not used in a restrictive sense, but for explanatory purposes.

[0023] Disclosed are components that can be used to perform the disclosed methods and systems. These and other components are disclosed herein, and it is understood that when combinations, subsets, interactions, groups, etc. of these components are disclosed that while specific reference of each various individual and collective combinations and permutation of these may not be explicitly disclosed, each is specifically contemplated and described herein, for all methods and systems. This applies to all aspects of this application including, but not limited to, steps in disclosed methods. Thus, if there are a variety of additional steps that can be performed it is understood that each of these additional steps can be performed with any specific embodiment or combination of embodiments of the disclosed methods.

[0024] As will be appreciated by one skilled in the art, the methods and systems may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the methods and systems may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. More particularly, the present methods and systems may take the form of web-implemented computer software. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, DVD- ROMs, optical storage devices, or magnetic storage devices.

[0025] Embodiments of the methods and systems arc described below with reference to block diagrams and flowchart illustrations of methods, systems, apparatuses and computer program products. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.

[0026] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0027] Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

[0028] The present methods and systems may be understood more readily by reference to the following detailed description of preferred embodiments and the Examples included therein and to the Figures and their previous and following description.

[0029] Automated Licensing and Management systems and methods for digital assets are described herein. An exemplary overview of one embodiment of the system can be seen in FIG. 1 - Automated Licensing and Management System Overview 100. Many of the modules / blocks show can be either combined or out into other modules / blocks as needed by the implementation complexity. The disclosed embodiments provide automated licensing with implementations including appendable mutable documents and records which are immutable. This can include both the asset and license / contract / terms or in another implementation the asset is bundled more on demand and the license / contract / terms as encrypted and bundled together for future reference. In some instances, the encryption can be performed as described in PCT / US2023 / 083388, international publication number WO2024129596 filed December 11, 2023, which is fully incorporated by reference and made a part hereof, though other forms of encryption (and decryption) are contemplated within the scope of this disclosure. FIG. 1 comprises modules to automate the licensing and management of digital assets. A significant part of the automation process is the Digital Asset(s) 105. One or more assets can be processed through the automation pipeline at the same time if they are of a similar nature and can be bound under the same contract / terms. A digital asset is any digital product, art, video, audio, creative, software, source code, or service owned by a company or individual. More specifically, but not an exhaustive list, would include images, NFTs, songs, music videos, animated series, production service, REST API for a product, or SaaS which generates a digital asset / product, and the like. A SaaS that produces a digital asset might include a service to produce movie scripts in a certain style, a video with certain characters, customized legal documents, on-demand music creation, on-demand image production, streaming service, etc. Generally speaking, any digital content can be licensed, as discussed herein, in any number of ways. In a broad implementation of the Automated Licensing and Management system, these assets likely have some form of meta-data associated to identify the asset as well as its features / options as well as acceptable use.

[0030] Furthermore, the digital representation of a physical item can also be managed through the same mechanism. Contracts, lease agreements, rental agreements, purchases, titles, digital driver’s license, government issued ID, a government-issued proof of citizenship (e.g., a passport), travel documentation, travel tickets, and many other physical items can be represented in the digital world. In some of these cases, the “Customer Access 150” might represent the viewing or presenting of proof of the digital representation. For example, showing a driver’ s license to law enforcement or presenting it at a liquor store can be accessed. This system can be used to encrypt concert tickets for seating and access. Attendees can purchase tickets and get a digital representation and they would be listed as the owner (or licensee) for that seat at that event. They can quickly confirm authenticity of the ticket and if allowed even the ability to resell their tickets if they cannot attend, transferring the rights of that ticket to a new owner while revoking their own claim. A house or car title could be handled the same way.

[0031] The Licensee Selections and Intended Use 110 module is the start of the Licensee process for the Licensees. The actual mechanism here can be an automated API, if appropriate, or a manual user interface. This might also be the selection of an already existing contract to attach to a new asset. The purpose of 110 is to collect from a prospective licensee what assets they wish to license from the licensor, meta data selecting any additional features, review Licenses Agreement 120, license times / periods / quantity / volume, if appropriate, other needed licensee data, and the intended use of the assets to help form the License Contract / Terms 130, which are described in more detail herein. Module 110 has the option of providing prices or total price is appropriate for the desired assets. This is to avoid any surprises to the Licensee once Payment Module 135 bills for the assets, assuming the Licensee meets all restrictions and applicable requirements of License Agreement 120. Once all data is collected from the Licensee, the data is sent onto the License Contract / Terms 130 portion of the system.

[0032] The License Agreement 120 of FIG. 1 can be a fixed or dynamic license agreement for the assets being licensed by the system. For a dynamic system, standard substitution can be used in a template license agreement. Another embodiment of this system module would be to use a Al Technique such as a Large Language Model (LLM) to generate a license agreement based upon the Digital Assets(s) 105 meta-data, making a generic licensing system such as a third-party store for licensing assets for different licensors as a service. Here, module 120 would take the meta-data from 105 and create a License Agreement for the licensor. This is ideal for creators without an attorney or legal team to support their asset licensing efforts. The same type of Al technology such as LLM can be used to read the license agreement to extract meta-data for inclusion into the License Contract / Terms 130. This meta-data can be used in 130 to compare against the Licensee selections from module 110 to determine if a contract / terms can be written to satisfy both the Licensor’s and Licensee’s needs. Some considerations at this step might include exclusions of use to prevent damage to the licensor’s brand such using the assets within Hate Speech, Deceptive Advertisements, Misinformation, or Adult Content. Other considerations might include the intended use which may compete with the brands on use of the asset such as inclusion in the licensee’s movies, which may compete with the licensor’s movie revenue or future desires for exclusive use of the assets in this medium. Additional restrictions can be imposed or allowed based upon the contract such as the ability to resell the licensed / purchased asset. Violations of the License Contract / Terms 130 can lead to termination of access to the licensor’s assets as well as potential breach litigation, for example. Here, Approval Module 145 is used as the gatekeeper of the active contract if Payment Module 135 considers the license fees current as well as if the Licensor has terminated the contract due to breach.

[0033] The License Contract / Term 130 module collects the intent of the Licensor and Licensee to form a contract or term sheet for the licensed asset(s). This can be a fixed format contract depending upon on the implementation of 110 and 120. One embodiment for 130 would include additional Al Technology such as an LLM to combine the Licensor and Licensee meta data to form a final contract and terms if there is no contradiction. For example, the Licensor might restrict the use of their content in adult content, where the Licensee might request use for adult content. This would cause a licensing exception and reject the licensee’s request to license the assets ending the process. In some instances, manual coding of these options bypasses the need for Al Technology, but may make the system less flexible but possibly more streamlined for certain assets. For example, a company licensing abstract background images for any purpose could simplify 110, 120, and 130 to only involve collecting and tracking of the licensee’s legal entity and cost information. In simple cases, costs can be passed directly to Payment Module 135 for processing. Module 130 passes the contract and terms to License Module 125 and optionally Payment Module 135. In some instances, the meta-data and / or costing is included with the contract / terms, to be charged after release of the asset. This allows for the system to process the asset; in some cases, the asset needs to be generated or streamed on demand. There is a possibility the licensed asset isn’t available due to availability or error in customers asset production. In these cases, charging immediately would be inappropriate and thus an embodiment for 135 payments would be triggered at release based upon the contract / terms and is discussed more below.

[0034] Licensing Module 125 can be implemented in a number of different ways to include static, multiple, bidirectional, stand-alone licensing / contract, and on-demand licensing. In the generic case, its purpose is to bundle the digital asset, with the license agreement, and signed contract / terms to bind the parties together. Signature Module 115 can be used to assist in signing of assets, if desired, and license agreements and contracts into a tamper proof asset bundle. This signature module 115 can be either automated signatures and / or manual signatures collected by either the Licensee and licensor depending upon the implementation needs. In some embodiments, the Al Based Agent described in co-pending PCT patent application filed concurrently herewith and entitled, “ARTIFICIAL INTELLIGENCE (Al) BASED ENCRYPTION FOR DATA ACCESS CONTROL AND TRANSCRYPTION,” filed July 19, 2024, which is fully incorporated by reference and made a part hereof, can be used to bundle both the asset as well as the contracts, licenses, meta data, costs, uses, access types, etc. based upon the License agreement and Terms.

[0035] AI-Based Agent

[0036] An Al-based agent approach provides data security as well as data production. While the AI- based agent provides encryption, the disclosed Al based agent also introduces a very powerful probability driven Al based data manipulation capability which can apply to almost any data processing needs outside of cryptograph such as compression or transcoding data. The disclosed aspects include an ability to produce a quantum proof encrypted data output based upon input. Another is the capability of producing a near' infinite number of encryption / decryption algorithms without the need to transfer any key or mask along with the encrypted data like in the case of the current quantum proof One Time Pad (OTP) implementations. This encryption / decryption can apply equally to different data type applications which include data in flight (streaming) or data at rest (storage). This is accomplished by a classical entanglement between one or more Al based agents. This is the digital equivalent of quantum entanglement providing the ability to know what each agent is doing at the same time without communicating that activity. Much like all Al based agents have a priori knowledge of what the other similar configured agents will do. Another novel feature includes the ability to transcrypt data from one encryption algorithm to a second algorithm without first decrypting the original encrypted data. As described herein, this allows the distribution of a highly secure data set to other trusted and untrusted sources securely without ever exposing the original / master encryption algorithm or decryption to “white text” (original unencrypted content). Finally, the Al based agent is configurable such that it can scale the encryption up / down based upon available compute and memory on bare metal or virtualized platform. This makes it usable within some of the most basic intemet-of- things (IOT) devices including use with supercomputers.

[0037] To clarify the purpose and novelty of classical entanglement, this allows for the transmission and storage of encrypted message / data without the need to store the mask / pad. Due to the entanglement of the Al Based encryption & decryption, secret pad / mask data as well as other Al Decision data is generated locally and doesn’t need to be transmitted. For example, the approach described in this specification in one embodiment for One Time Pad (OTP) encryption, among other more complex algorithms, to be utilized with no transmission of the mask to decrypt the message. Current OTP technology requires the transmission of not only the encrypted message but also some secret way of transmitting the mask data to the decryptor to restore the original message. This has many drawbacks including twice the bandwidth requirement, public exposure of the mask, which is a security risk, as well as limited manipulation that can be done to the original message / data to ensure security. Furthermore, this entanglement method allows for any level of complex operations to be performed at a first location and have the reverse preformed at the same or multiple other locations without the need to retain such a mask or instructions to recover the original message / data.

[0038] In some instances, an Al-based agent comprises multiple elements. Note that other supporting elements can be added as well as some can be removed based upon the final need for the Al based agent as stated above to cover scalability and functions outside of encryption / decryption. One element comprises Agent Action Determination. It maintains the coordination of the overall agent based upon the Al Agent Configuration Data to give the initial setup / state / probabilities, State Machine to maintain system state while the agent works, and the Encryption Generator and Decoder to drive the agent actions for proper encryption / decryption. These portions of the disclosed Al based agent determine the actions and initial configuration with the ability to encrypt or decrypt input data if applicable. “If applicable” here is referenced here due to the capabilities of the Al based agent to generate data, it doesn’t need to ingest data to produce data. Also note, the disclosed Al based agent can ingest data and not produce output data. The simplest example use case of this generation without ingesting is to produce a channel / stream of digital network noise. A sending agent might create a noise stream with no input data to fill a silent network channel with noise while the receiving agent would ingest this noise and discard it so as to not burden the systems connected on both ends of the channel. If needed, these agents can inject valid data across the channel such that the receiving agent would discard noise and recover only the valid data.

[0039] The Al based agent internal intelligence depends upon both the Deterministic Pseudo Random Number Generator that creates one or more deterministic random number streams and the Probability Converter used to generate a deterministic percent value which connects with Deterministic Pseudo Random Number Generator to specifically provide probabilities upon request of the Agent Action Determination to drive the current Al based encryption algorithm using a multitude of functions, test, calculations, meta data, configuration changes, system state changes, and other actions. Another way to think of this Al based agent is that of a genetic algorithm where it mutates over time and is probability based. One exemplary embodiment of Deterministic Pseudo Random Number Generator comprises initializing with a pre-amble, a block of random data, to define a new random sequence based upon the pre-amble. During the encryption, a pre-amble is generated after initial configuration, then added to the initialization changing the overall random data stream dependent upon the supplied pre-amble data. Upon inverting the process, the pre-amble is read from the previously output stream and then used to re-initialize the random number data stream. The size of the pre-amble can be pre- configured or dynamically determined from the supplied configuration prior to applying the pre-amble data. It is worth noting that in some applications, Random Number Generator may also provide non- deterministic random numbers if needed by the Agent Action Determination element.

[0040] The Al based agent can ingest data via the Dynamic Buffered Inputs to access any input IO functions such as static files, Network Ports, Network Protocols, data acquisition hardware, serial input, hardware-based input (USB for example), keyboard, WIFI, Bluetooth device, IOT device, audio capture, video capture, IR detectors, GPS data, Satellite downlink, streaming input, dynamic input, etc. The Al based agent can also generate / produce output at the Dynamic Buffered Outputs. Much like the list that can ingest, the output can include similar things such as static files, Network Ports, Network Protocols, data acquisition hardware controls, serial output, hardware-based output (USB for example), WIFI, Bluetooth device, IOT device, audio output, video display, LEDs, Satellite uplink, streaming output, dynamic output, etc. There can be more than one input and / or type as well as more than one output and / or type. For Dynamic Buffered Inputs and Dynamic Buffered Outputs, dynamic is important here as well, although most applications would use a static connection, the Al based agent could dynamically select a new input / output based upon probability of obtaining new input or output, most likely used to dynamically update the state of the system, increase the security, or assure private access to data only available for short periods of time. Both inputs and outputs may be buffered to facilitate functions that reach backwards / forward in the data stream. This allows for more complex invertible functions which further mutate the data stream based upon prior or past data within the stream.

[0041] Another aspect of the Al based agent is its ability to manage pre / post processing of the data at Dynamic Buffered Inputs and Dynamic Buffered Outputs. For example, a customer may wish to have their data encrypted with a OTP, but also wrapped in another form of encryption such as, but not limited to, AES256. Depending upon the Al agent Configuration Data, data pulled into Dynamic Buffered Inputs may first be wrapped by an AES256 with a key memorized by the Al based agent. Then during a decrypt cycle, Dynamic Buffered Outputs can then unwrap the encrypted data on last time by decrypting the AES256 encryption with the memorized key. Having the Al based agent memorize the key is the general approach, but alternative methods can be employed as the key can be encrypted in the output stream for use by the decrypt cycle.

[0042] The same Al based agent may have the capability of transcryption (directly converting from encryption A to encryption B) by the addition of Al agent Mx Configuration Data. Generally, transcryption addresses a need to convert data encrypted with one algorithm into another format without exposing the original plaintext. The goal is to achieve this conversion while maintaining security and without revealing the unencrypted data. As a non-limiting example, consider the following: Starting with an initial common encryption step (e.g., XOR) that both formats share; Instead of applying the PRNG data directly to decrypt the data, store it; For the second format, calculate the XOR stage PRNG data without applying it; Combine the XOR mask data from both formats to create a Transcryption Mask; Apply this Transcryption Mask to the encrypted data from the first format (XOR stage) to produce the XOR stage of the second format; Additional encryption steps can follow as needed.

[0043] This process allows translating Encryption A to Encryption B without exposing the plaintext data. Transcryption can be applied to various encryption algorithms, including AES256, by adapting the code to perform the specific cipher transcryption.

[0044] One or more configuration files can optionally be added. One embodiment would be to add a single additional configuration data set of the secondary encryption the Al based agent can use for transcryption. This allows the Al based agent to maintain a child Al based agent internally to facilitate the direct conversion between Encryption A and Encryption B. The Encryption Generator and Decoder would now need to be able to compute a combination of encryption / decryption functions between the two or more compatible encryption algorithms. For operations to be compatible, the operations performed in sequence individually must produce the same result as the operation of the combined operations. That is to say C being the combined result of operation fl + f2 must be equal to some new combined operation f3 which replaced the combined fl and f2 operations; C = fl + f2 = f3.

[0045] One way to think of this computation would be the difference between the fractional decryption of A and fractional encryption of B. Fractional since more than one invertible function may be statistically applied and all invertible function need to be applied to the data stream in a reverse sequence and more than one function can be applied to the same data. So, where an OTP hypothetical mask_A and mask_B are the associate XOR values to decrypt A and encrypt B, internally the A XOR mask_A which decrypts A and then the result XOR mask_B to encrypt to B is never performed. Rather the mask_DIF is computed as mask_A XOR mask_B, then B is generated by A XOR mask_DIF. This is similar for other functions such as ADD. If add_A and add_B respectively are needed to add to A to decrypt and added to B to encrypt, a similar dif function can be calculated to make a one-step operation. In this case, add_DIF = add_A + add_B. So, for example, if A was encrypted with ADD 10, and B is encrypted with ADD 10, then A would be fractionally decrypted at this point with ADD -10 (using the inverse of subtraction). So, add_DIF = -10 + 10 = 0 meaning 0 would be added as the computed change to the data stream. Many function types can be used to create a valid DIF function like the above such as BIT ROTATE, BUFFER ROTATE, NOISE, etc. Any operation / function F that is both invertible and constant within the fractional step going from A to B would be DIF = F-l(A) + F(B). This is referred to as a difference due to the negative / reversing nature of the F-l decryption. Some functions that rely on data not yet determine are not eligible for use in a transcryption.

[0046] Functions / Operations / Calculations that make up one exemplary embodiment. Data Access Control handles all IO requests to and from Input / Output buffers. It would be responsible for opening static and temporary inputs / outputs as dictated by the agent. The Invertible Function Library makes up all the functions / operations / calculations which need to be inverted. The inversion is required when and if the data flow is reversed such as a decryption. A simple way to think of these functions would be; x = F-l(F(x,pl,p2,...),pl,p2,...) where F-l is the inverse function of F which returns the original input x parameter / object to F. The pl, p2, ... are extra parameters needed by F and provided by the Al based agent. An example would be the XOR function where F and F-l are both the XOR function. Another example would be F being the ADD function and F-l being SUB. Here again, the function parameter / objects can be of any type / size as determined by the application. The only requirement is that it must be invertible. Please note, some invertible functions may be lossy, but this has been considered as either a desired or acceptable invertible function. An example of an application where lossy might be either desired or acceptable would be in rounding errors when inverting a function for a binary WAV format audio file. Generally, in the case of audio, small changes to the waveform can be kept to an unperceived level, and in some cases can be used to water mark the destination of the audio for tracking purposes. Some invertible functions might not require “x” as an input such as for “noise”. Here x can be the “null” set or omitted, and a parameter p 1 might be the size of the noise data requested. The inverse here will simply return the “null” or zero data. Other invertible functions might include self-repairing algorithms such as Forward Error Correction (FEC) or Error-Correcting Code (ECC). These would take x, returning x with error correction data, the inverse would take the questionable data x’ which may have errors but include the correction codes and return x. Internally, null, error flag, or exception can be thrown to handle the fact that the data is corrupt. Similar for a CRC function as well which may use supplemental data in blocks or meta-data to carry CRC or similar check results. Forward would calculate the CRC, reverse would test CRC much like describe above for handling errors to detect corruption of the data stream.

[0047] Block Size is responsible for maintaining the proper block size used for block operations. Although many implementations may be a static block size, this disclosure contemplates including the ability to have a variable block size based upon a range and the probability of those values in the range. Another aspect of this portion of the agent actions is for the inverse block size calculations. Here, the forward or encryption function may have generated more (injection) or less data (compression) than the original input block size. It is desired that the Agent Actions to understand, a priori knowledge, of what the new encrypted block size might be as well as the final decrypted block size. Probability Tester is used throughout the agent’s lifecycle to determine what Functions / Operation / Calculations need to be performed based upon configured probability. It might also be used to determine meta parameters over a probability range such as discussed above for block size. Keep in mind, one valid operation of the agent is to dynamically update the configuration thus changing the probability of said operation on the next iteration. Configuration Management maintains the current Agent configuration. As discussed earlier, the configuration is not necessarily static over the agent lifecycle. Configuration management is responsible to tracking those changes and understand the initial configuration if the agent needs to be restarted.

[0048] Meta Data Processor handles the generation, injection, extraction, actions, and update of meta data within the data stream. Since the underlying technology can bundle meta data within the output stream and read back meta data within the input streams, this processor is responsible to coordinating those activities. It is also responsible for triggering additional actions that may originate from the included meta data. An example here might be an included meta data which changes the system state such as a pin code for the remainder of the agent lifecycle.

[0049] To help implement the classical entanglement between Al based agents, State Process maintains and reads the deterministic state. State Machine which helps to drive the Deterministic Pseudo Random Number Generator maintaining synchronized random data between instances with identical configurations. This then synchronizes the Probability Converter, keeping the Agent Action Determination making the same probability selections for everything configured within Al agent Configuration Data which in turn drives the Encryption Generator and Decoder maintaining a fully invertible data stream.

[0050] Data Output Processor fills the output buffcr(s) as determined by the configuration files, Block Size determination, and invertible functions. It is also responsible for injecting the metadata into the data stream output. Optionally, the Config Difference Engine is only required for Al based agents that perform transcry ption. It is responsible for making sure the fractional DIF is calculated properly for successful transcryption. Child Agent(s) Management would be required with the transcryption feature or any other complex operation requiring two or more configurations. For the transcryption case, it would be responsible for synchronizing the secondary configuration file with the state of the primary agent (parent agent) and sharing said state with the parent. This state will be used by the Config Difference Engine to calculate the DIF to apply for the fractional data / configuration / state manipulation operations.

[0051] Referring back to the licensing module 125 of FIG. 1, another review might be performed here as well to make sure the Al Technology used created a valid contract which is compliant with the License Agreement 120 as well as the Licensee’s desires stated in 110. This might be another Al Technique such as LLM to test for conflict between all the collected / generated data and contracts. The result of this step would be to produce a Quantum Proof encrypted asset bundled with the above information for future use by the Release Module 140.

[0052] The asset, or access to the asset, can now be controlled with the encrypted asset bundle. In some implementations, Release Module 140 might be best to encrypt the data for efficiency depending on the type of protection of the original asset and type of asset. For a video stream, for example, as the Digital Asset 105, License Module 125 may only bundle the non-asset portions, other than a reference to such asset for future reference. This may be the case if the asset is already protected or of a size or format that will not facilitate ease of use by the licensee. So, the asset and license bundle flow independently through to Release Module 140 for additional tests and encryption. The video might already be encrypted, so Release Module 140 might transcrypt the content upon release based upon Approval Module 145 for the customer in a different encrypted format to Customer Access 150. As used herein, transcrypt, and its variants (e.g., transcription), means a method of converting obfuscated data of one type into a second obfuscated data type without exposing the underlying obfuscated original data in memory or storage medium. This includes CPU Memory, GPU Memory, local / connected storage of temporary files, etc. Systems and / or devices used for performing transcryption are also included within the scope of this definition. The other optional purpose of the Release Module 140 would be to add a digital watermark to the asset for tracking. This is optional, it could be a visible or hidden watermark to the asset to indicate who has licensed it and it is a valid license such that it can be tracked back to this current license / terms. This might also include meta data which will be sent to the Customer Access 150 for verification / inclusion into the final output. For example, a video streaming company might randomly flash the contract ID or name of licensee over the viewed content as a watermark. 150 might also embed this meta data into the asset during the customer extraction of the asset depending on the type of asset and needs of the licensor. This module may optionally update the encrypted contract with a journal entry of an asset that has been requested by the licensee and produced to Customer Access 150. 140 can also be used as a means to validate an asset is licensed by a certain contract through a similar connect Customer Access 150 device, this could be the Licensor’s access to verify the asset is licensed as well.

[0053] The Payment Module 135 is responsible for charging the appropriate fees for the released content based upon the contract / terms. It may get encrypted payment information from the meta-data within the contract / tcrms such as credit cards, EFT, SWIFT, PayPal, etc. as the desired form of payment. This might be a single charge, per use charge, per minute charge, per word charge, per licensed character charge, per month, per year, and so on. It can also notify the Licensee of charges applied and send a receipt back to the Release Module 140 for inclusion into the License / Asset encrypted bundle by appending it to the end. Depending upon the implementation pipeline formed for the system, payment received might be passed directly from Payment Module 135 to Approval Module 145 in simpler implementation of this Licensing System. This module could be combined with Release Module 140 in simpler implementations of the licensing system.

[0054] Another feature of an embodiment of the system includes the Approval Module 145. Note that many of these features in simpler implementations can be combined within 140 for simple payment processed testing and access rights being established via Customer Access 150. This module tests for up-to-date payment or correctness of the contract / terms among other “needed” aspects of the contract / terms of the licensed asset. Depending upon the implementation of the contract / terms the 145 might need to obtain additional purchasing authorization or account information from Customer Access 150. This might be updated pricing, or over-run of prior contracted amounts of assets and costs. The module 145 updates any amendments to the contract / terms that were obtained on-demand through 150. This might even include the use of a different Customer Access 150 (still image vs video access, or text story in style of character vs the original contract). In some instances, these requests pass back to 125 for validation against the licensor’s requirements for update / approval. In some instances, this module provides transcryption details on proper decryption of assets if appropriate for the licensing system.

[0055] Module 145, in some implementations, perform compliance tests upon either a request coming from Customer Access 150, or upon the asset produces based upon the Customer Access 150 request before allowing that asset to be used by the licensee. For example, Customer Access 150 might allow “Prompts” to be sent back to the licensor’s asset generator (LLM system for example) on demand. In some instances, the prompts are filtered or tested before sending for processing, as well as testing the output of the asset generator to make sure it meets the terms. So, for example, horror might not be an acceptable use of the licensor’s assets, so 145 might screen the request from the licensee for a horror sentiment or feel and reject it prior to processing. But the licensee might find work-arounds on these filters and produce works that are not to the terms, so the returned asset can also be screened for the same sentiment or feel prior to release. This module can also be used to flag contracts that are found to be in violation of the terms and shut down access for the prior Licensee, preventing future abuse or misuse of the Licensor’s assets.

[0056] Customer Access 150 can be any compliant system for the Licensee to gain access to the Licensor’s contracted assets. This likely includes a decryptor to recover the assets into a format usable by the Licensee. It can be an automated API or a manual system. The format of the Customer Access 150 is going to depend upon the type of asset, contract / terms, licensor’s protection, and licensee’s access. One embodiment might be a custom Graphic User Interface which creates a pipeline back through the licensing system to generate licensed content based upon a creator’s needs. Another embodiment might be a system that sends out REST API calls for certain images or videos based upon their licensing needs. Depending upon the needs of the licensing system, a contract ID or such might be meta data passed by 150 back to 145 / 140 to assure the proper contract is being considered, this might also include some authentication system such as Decentralized Identifiers (DIDs) or Signed requests. This may utilize the same Al Based Agent encryption through a reverse channel.

[0057] As described above, 150 may also be asset verification. This could be an automated process through an access API for a licensor to test if assets they find in the wild are properly licensed or even as a manual process. This module could then push a flag invalidating the Licensee’s contract with a description of the violation which the Licensee could review and then either correct if allowed. This verification mechanism could easily be made available to the licensee to self-verify compliance with their contract / terms. If the violation cannot be remedied, the contract will be considered void and no additional assets can be accessed. In cases of digital / live assets that need re-authorization using 150 to access 140 / 145 for continued use will also fail to allow the asset to function / exist.

[0058] FIG. 2A - Bundled Licensing with Asset 101, shows how, in some instances, the system can be broken into multiple sections based upon the application and assets being licensed. This figure shows how the front end of the Licensing System of 100 can be used to create a License Bundle With Asset 160, which can be stored for later access. The same 105, 110, 115, 120, 125, and 130 are included in 101, but the output of the licenses system is a stand-alone bundle, preferred embodiment of 160 would be a non-mutable quantum proof encrypted bundle using the Al Based Encryption so that all asset(s), licenses, signatures, contracts, terms, and meta-data are included within the same digital object. This keeps this information together, 160 can alternately be encrypted or transcrypted so that it can be directly supplied to a licensee to offload storage or streaming of said assets from the licensor’s resources.

[0059] Control of the asset happens as seen in FIG. 3A - Automated Licensing with Bundled Licenses and Asset 103. This figure shows how the 160 would be used within the release, payment, approval, and customer access portion of the system. Modules 140,135, 145, and 150 are the same as described in FIG. 1, above. Optionally 140, 150, and 160 could be hosted by the Licensee with 135 and 145 being accessed as a remote service to remain in control of the Licensor or their Licensing agent (third party licensing company).

[0060] FIG. 2B - Bundled Licensing 102, shows how the system can be broken into multiple sections based upon the application and Digital Asset Groups 106 being licensed. Here, the specific asset might not be determined at the time of signing a contract, a dynamic asset, or the assets are too large to bundle directly within the License Bundle 161. 106 is rather a description or generalization of the assets and associated meta-data of the assets. An example might be of a movie streaming platform. The asset group would be of viewable movies at certain variable or fixed costs which gets recorded in License Bundle 161 and charged later on-demand. This figure shows how the front end of the Licensing System of 100 can be used to create a License Bundle 161, which can be stored for later access. The same 110, 115, 120, 125, and 130 are included in 101, but the output of the licenses system is a stand-alone bundle without the asset(s) embedded, preferred embodiment of 161 would be a non- mutable quantum proof encrypted bundle using the Al Based Encryption so that all licenses, signatures, contracts, terms, and meta-data are included within the same digital object. This keeps this information together, 161 can alternately be encrypted or transcrypted so that it can be directly supplied to a licensee to offload storage or streaming of said assets from the licensor’s resources.

[0061] Control of the asset happens as seen in FIG. 3B - Automated Licensing with Bundled Licenses 104. This figure shows how the 161 and 105 would be used within the release, payment, approval, and customer access portion of the system. Modules 140, 135, 145, and 150 are the same as described in FIG. 1 above. Optionally 105, 140, 150, and 161 could be hosted by the Licensee with 135 and 145 being accessed as a remote service to remain in control of the Licensor or their Licensing agent (third party licensing company). The configuration of 104 needs extra consideration to make sure that control of 105 assets and 140 remain under control of the Licensor with proper transcryption and topology to protect any Licensor secrets which can be resolved easily with the preferred embodiment.

[0062] FIG. 4 - Minimal License System Flow 200, gives a minimal flow for an automated licensing system described herein. 205, determine the assets of interest by the licensee so that license agreements and contracts / terms can be properly crafted. Get Licensee Data 210 collects the needs and intended use of the licensed asset. Agree Contract and Terms 215 binds the Licensor and Licensee under an agreement for acceptable use and pricing of the licensed assets. Compile Licensed Object 220, again this can be a separate object for future use such as 160 or 161 or directly fed into Release Module 140 as shown in FIG. 1. The licensor, or their agent, will bill the licensee in 225 per the contract. Note that this can be a free license as well so no billing is required such as shareware or open- source software that the licensor might want to still bind under a free contract agreement. Once billing is successful, 230 will Release Licensed Asset which is generally 140 then providing Customer Access 235 which is equivalent to any / all earlier discussed Customer Access 150 methods. These are the minimal set of steps where the novelty of the invention center around steps 220, 230, and 235.

[0063] Maintaining all these licenses and digital assets would conventionally require something like an immutable database or digital ledger technology. Both offer technical challenges and overhead that increase system complexity. The Al Agent based encryption offers a cleaner and greener solution.

[0064] Using the Al Agent based encryption technology, meta data and raw data are stored in the same stream or file. The file will start with meta data to describe the data that follows. So, meta data may state things like “License agreement”, “Signature of XXX@COMPANY.COM”, “Transaction Update”, “Event XXXX”, etc. This meta data can contain any number of meta data elements such as date stamps, files size, CRC, etc. Following the meta data block will follow the raw data block if applicable. It is possible to skip the raw data block if the meta data captures the required information needed for the application. The raw data block will generally contain digital assets which can be any digital item of interest. This item could be a document, image, video, license, credential, signature, secret, contact information, terms of use, payment information, payment receipt(s), driver's license, ID Card, Event / concert Ticket, etc.

[0065] Due to the Al Agent encryption method forming a mask / pad to obfuscate the contents, appending additional meta data and raw data to the record / file is easily accomplished as it only extends the mask used to obfuscate the earlier contents. Given this, the contents can always be extended for as long as needed for the intended application. In this embodiment, the record would be kept in the cloud or vault to protect from direct access from unauthorized people / applications. The reason for this is due to the corruption detection of the Al Agent can detect alteration in the middle of the document. But if documents are appended, this embodiment doesn’t allow the Al to know a document is missing. This would give an opportunity to remove the last signature or payment information for example. Another embodiment might choose to include a “Final” record meaning a specific meta data / raw data is always appended to the file to lock the data prior. For updates, this record is then moved further down the chain, and new data inserted right before this final record. There are many application where this embodiment is the best approach for creating the record.

[0066] In the case of unauthorized users / applications having direct access to the record, such as a driver’s license on a person’s cellphone. In this example, the DMV would provide a digital asset for drivers licenses but this needs to be tamperproof. If this were a simple digital asset where the DMV provides an encrypted asset using the Al Agent, the asset would be safe from tampering with and would need to be provided to a service for verification / display, possibly with the licensee’s authorization. This service would then decode the asset for display or verification. As in some cases, the verifier might be a bouncer at a bar verifying your Age and Photo. It would report the owner of the ID is over 21 years old and display a photo for verification.

[0067] The complexity comes when this asset needs to be updated. For example, the license is renewed to update the expiration date or the licensee has moved requiring an update of their address. The DMV could produce a new digital asset much like above with the updated data, but this might not be the best solution for other applications as the history of renewals would be lost or the date of the move to a new address would be lost. If the digital asset was a contract with subsequent signatures for approval captured at later times, the parties would want to make sure the contract and all signatures are kept together to maintain the agreement’s integrity.

[0068] With the Al Agent’s transcryption capabilities, assets such as a driver’s license and business contracts can be distributed to all interested parties and maintain their integrity. This is accomplished by adding the new asset to the tail end of the chain during the re-encryption (transcryption to maintain secrecy) the asset group with each new transaction or event. During this re-encryption, a master meta data section would be updated to maintain the record integrity. Any method as described above is acceptable as well as other methods not specifically mentioned. For this example, there might be a total count of document / events / transaction included in the record. This can be tested during verification and the record rejected as altered if it fails. This will eliminate the ability to truncate the file to alter the asset state as all documents / events / transaction would be locked by the integrity test. The transcryption will immutably maintain privacy of the underlying assets / data. Authorized users could use a decryption service to extract the events and assets as needed and if authorized. Again, like the Driver’s License, certain data could be withheld based upon authorization by the holder or asset rules in the meta data. In the license, a bar verifying age doesn’t need your address or name, so these can be kept private.

[0069] Application of Above Technology forms many different topologies. What follows is a description of some of those for illustrative purposes. The Al Based actions described leverage data and meta-data capabilities and an immutable design for the encrypted output. Additional data can optionally be included in the immutable record such as template license agreements to feed into an LLM or field replacement system to form a final contract / agreement. Furthermore, the immutable record might include licensing terms, required payments, acceptable use, and other requirements / details for the digital asset. A required digital asset workflow before access or completion of a contract / document may also be pail of the record. This ultimately makes an end-to- end encrypted immutable Web3 System.

[0070] Before the digital asset is made available to the licensee many other actions will be enforced. Some of these actions might require additional data be collected and processed to form additional input into the immutable record such as; licensee information for personalizing a document, acceptance of a contract / agreement / document, payment processing per terms included with digital asset, request changes to the license or acceptable use, request different format of the asset, and many others. The record will be updated with any new requirements or information, such as payment received extending the immutable record documenting its history. Some applications might include situations where a licensor tags the asset with specific licenses which doesn’t require payment or explicit acceptance such as; Creative Commons, various Github licenses, GNU Public Licenses, Apache, MIT, Open Source Initiative (OSI) Approved Licenses, Free Software Foundation (FSF) Approved Licenses, Software Package Licenses, Microsoft Public License (Ms-PL), Apple Public Source License (APSL), IBM Public License (IPL), Open Data Commons Open Database License (ODbL), LaTeX Project Public Library (LPPL), Clickwrap, Browsewrap, and many others. It is important for creators to tag their work with the appropriate license to eliminate any questions / ambiguity of their intent given the immutability of said license. These licenses are generally accepted through use under these licenses. On the other hand, commercial, enterprise, and custom licenses often require explicit agreement and signatures. These tags will help to defend content owner from theft in the new world of creatives.

[0071] The technologies disclosed handle both implied and explicit agreements. Recording of a licensee’s signature as accepting the terms or recording the users use of the assets can all be added to the immutable record. As disclosed above, a preferred embodiment of release of assets under this system will include specialized software to ensure all required “workflow” items are completed. This will then release the asset; it could even require “acceptance” of the implied licenses with that recorded along with the asset accessed and their identification. This specialized software might be an automated API, portal, product software, smart-TV application, software library file, or any other means to providing a gatekeeper to the asset.

[0072] It is important to note, the above disclosure of the licensing can apply generically to any other asset digital or physical. In the case of physical assets, there would need to be a means to digitize the said asset such as a registration, title, deed, ownership, lease, rental, bill of sale, purchase contract, loan agreement, certificate of authenticity, Articles of Incorporation, Partnership Agreement, Operating Agreement, Stock Certificates, shareholder agreements, business license, Franchise Agreement, Patent, Trademark, Copyright, License agreement, certificate of deposit, Safe Deposit Box Lease, Power of Attorney, Guardianship Papers, Adoption Papers, Marriage Certificate, Court Order, School Enrollment, Government Issued ID, as well as others not listed. The asset will be handled the same way but the license agreements, fees, conditions, acceptable use, etc. will change or be eliminated depending upon the type of asset. Additional items / meta-data not listed above might be added reflecting the special purpose / needs of a specific asset. For example, a cellphone might have an International Mobile Equipment Identity (IMEI), Mobile Equipment Identifier (MEID), Electronic Serial Number (ESN), Integrated Circuit Card Identifier, Subscriber Identity Module (SIM) Number, International Mobile Subscriber Identity (IMSI), Bluetooth and / or Wi-Fi MAC address, and / or Device Serial Number.

[0073] Computing Environment

[0074] FIG. 5 shows an example computing environment in which example embodiments and aspects may be implemented. The computing device environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality. The computing environment of FIG. 5 may be a computing device 500 used by a controller, and / or other hardware aspects of the disclosure, to implement aspects of the disclosure. For example, computing device 500 may be a component of or comprise a cloud computing and storage system. Computing device 500 may comprise all or a portion of a server or a controller. State machines, as described herein, may be implemented on one or more computing devices 500. Each computing device may have one or more processors. In various implementations, computing devices 500 used by the various parlies may be interconnected with one another through various connections, including networks. Such networks may be wired (including fiber optic), wireless, or combinations thereof including parallel, RS-232 (all serial communication from point to point), Visual (Infra-Red), audible (modem for example). Other connections / communication standards can also be improved such as USB, PCI Express, Firewire, Fiber Channel, HDMI, I2C, SPI, etc. Some of these are important for applications such as wireless barcode readers, Credit Card Terminals, walkie-talkies, radios, video conferencing, etc.

[0075] Numerous other general purpose or special purpose computing devices environments or configurations may be used. Examples of well-known computing devices, environments, and / or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, cloud-based systems, microprocessorbased systems, network personal computers (PCs), minicomputers, mainframe computers, embedded systems, Internet of Things devices, network switches, network routers, network edge devices, Modulator-demodulators (modems), industrial control equipment, including distributed computing environments that include any of the above systems or devices, and the like. The computing environment may include a cloud-based computing environment.

[0076] Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.

[0077] With reference to FIG. 5, an example system for implementing aspects described herein includes a computing device, such as computing device 500. In its most basic configuration, computing device 500 typically includes one or more processing units 502 and one or more memory

[0078] 504. Depending on the exact configuration and type of computing device, memory 504 may be volatile (such as random-access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 5 by dashed line 506.

[0079] Computing device 500 may have additional features / functionality. For example, computing device 500 may include additional storage (removable and / or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in FIG. 5 by removable storage 508 and non-removable storage 510.

[0080] Computing device 500 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by the device 500 and includes both volatile and non-volatile media, removable and non-removable media.

[0081] Computer storage media include volatile and non-volatile, and removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory 504, removable storage 508, and non-removable storage 510 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, electrically erasable program read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information, and which can be accessed by computing device 500. Any such computer storage media may be part of computing device 500.

[0082] Computing device 500 may contain communication connection(s) 512 that allow the device to communicate with other devices over networks. Such networks may be public or private, combinations thereof, and may include the internet. Computing device 500 may also have input device(s) 514 such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 516 such as a display, speakers, printer, etc. may also be included.

[0083] It should be understood that the various techniques described herein may be implemented in connection with hardware components or software components or, where appropriate, with a combination of both. Illustrative types of hardware components that can be used include Field- programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Applicationspecific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. The methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium where, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter.

[0084] Although exemplary implementations may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices. Such devices might include personal computers, network servers, and handheld devices, for example.

[0085] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

CLAIMSWhat is claimed is:

1. A method of automated licensing and management of a digital asset, comprising: encrypting a digital asset using an artificial-intelligence (Al)-based encryption; receiving, from a prospective licensee, information about the digital asset that the licensee wants to license from a licensor; receiving information about the licensee and information about the licensee’s intended use of the digital asset; generating a term sheet between the licensor and the licensee for licensing of the digital asset by the licensee, wherein the term sheets identifies any exceptions between the licensor and the licensee; generate a license agreement between the licensee and the licensor for the digital asset if the exceptions are resolved; create an executed license agreement between the licensor and the licensee by having the license agreement executed by a representative of the licensee and the licensor; creating a digital bundle comprising the executed license agreement, the term sheet and any associated documents; encrypting the digital bundle using the Al-based encryption; receiving a request from the licensee for access to the digital asset; determining if the request is in compliance with the executed license agreement; and providing the digital asset to the licensee in accordance with the executed license agreement if the request is in compliance with the executed license agreement.

2. The method of claim 1, wherein the digital asset comprises any digital product, art, video, audio, creative, software, source code and / or digital representation of a physical item.

3. The method of claim 2, wherein the digital asset includes at least one of a NFT, a song, a music video, an animated series, a production service, a REST API for a product, and / or a SaaS that generates a digital asset / product.

4. The method of any one of claims 2-3, wherein the digital representation of the physical items comprises a digital representation of a contract, a lease agreement, a rental agreement, a purchase or sales document, a title of ownership, a driver’s license, a government issued ID, and / or a government-issued proof of citizenship, a travel document, a ticket to an event, and / or a travel ticket.

5. The method of any one of claims 1-4, wherein the digital asset and / or the digital bundle is encrypted by a method of Al-based encryption comprising the steps of: a. initializing a system state; b. acquiring a random data set; and c. changing the initialized system state based on the acquired random data set; d. processing data of the digital asset and / or the digital bundle to produce encrypted data from at least a portion of the data, wherein said encrypted data is produced based upon a probabilistic state machine probabilities found through deterministic random data, where said processing comprises: i. determining a configured operation based upon a probability of the configured operation to be applied , ii. acquiring a block size of the data to ingest,iii. acquiring additional parameter data needed for the determined configured operation, iv. applying the configured operation to the ingested data to create encrypted data, v. updating the system state; and e. outputting the encrypted data.

6. The method of claim 5, wherein initializing the system state further comprises generating an initial system state random data set, and obtaining a pre-amble size based upon a size of the initial system state random data set.

7. The method of claim 6, wherein the acquired random data set has a size equivalent to the size of the pre-amble.

8. The method of claim 7, further comprising outputting the random data set, wherein the output random data set has a size equivalent to the pre-amble size.

9. The method of any one of claims 5-8, wherein the data of the digital asset comprises previously encrypted data.

10. The method of any one of claims 5-8, wherein the data of the digital asset comprises unencrypted data.

11. The method of any one of claims 5-10, further comprising repeating steps d.-e. until the data of the digital asset and / or the digital bundle is exhausted.

12. The method of claim 11, wherein outputting the encrypted data comprises outputting a stream of encrypted data after exhaustion of the data, wherein random data is injected into the stream of encrypted data to increase obfuscation of valid data.

13. The method of claim 11, wherein the data is exhausted when no additional output is required.

14. The method of any one of claims 5-13, wherein the data is from any one or more of a random data, deterministic random data, time stamp, IP address, computer internal state, probabilistic state machine internal state, external data acquisition, data file, memory, or a network port.

15. The method of any one of claims 5-14, wherein the block size of the data to ingest is dynamically determined.

16. The method of any one of claims 5-14, wherein the block size of the data to ingest is a configured block size.

17. The method of claim 16, wherein the data is a binary object of any length equal to or smaller than the configured block size.

18. The method of any one of claims 5-17, wherein the configured operation is an invertible function.

19. The method of any one of claims 5-17, wherein the configured operation comprises an injection of configured meta data.

20. The method of any one of claims 5-17, wherein the configured operation is an update to the system state and / or an operation on the ingested data.

21. The method of any one of claims 5-17, wherein the configured operation comprises an external location of updates to the system state.

22. The method of claim 21, wherein the external location comprises another IP address, a website, or a remote or local device.

23. The method of any one of claims 5-17, wherein the configured operation comprises an injection of random data.

24. The method of any one of claims 5-17, wherein the configured operation comprises operations changing the system state.

25. The method of any one of claims 5-17, wherein the configured operation comprises one of a system state, a bit, a binary object, or a block based operation.

26. The method of any one of claims 5-25, wherein the system state includes preconfigured metadata.

27. The method of any one of claims 5-25, wherein the system state includes preconfigured function probabilities.

28. The method of any one of claims 5-25, wherein the system state includes preconfigured constant data.

29. The method of any one of claims 5-25, wherein the system state includes preconfigured access to external metadata, and accesses a remote location to find such metadata.

30. The method of any one of claims 5-25, wherein the system state includes preconfigured access to external constant data, and accesses a remote location to find such constant data.

31. The method of any one of claims 5-30, wherein the method of encryption is used to encrypt an output of an existing data encryption, transformative, or protective algorithm.

32. The method of any one of claims 5-31, wherein a decryption mask or pad information is not required and is not transmitted with the encrypted data.

33. The method of claim 32, wherein the decryption mask or pad information is not stored.

34. The method of any one of claims 1-35, wherein the digital asset further comprises meta data associated with the digital asset.

35. The method of claim 36, further comprising processing meta data associated with the digital asset to obtain an obfuscated meta data package.

36. The method of claim 35, wherein processing the meta data associated with the digital asset to obtain an obfuscated meta data package comprises processing the meta data to produce encrypted meta data from at least a portion of the meta data, wherein said encrypted meta data is produced based upon a probabilistic state machine probabilities found through deterministic random data, where said processing comprises: a. collecting a meta data elements package, b. adding an end of data element to the meta data elements package, c. calculating a meta data elements package size, d. acquiring deterministic random data, and e. obfuscating the meta data elements package with the deterministic random data to create an obfuscated meta data elements package.

37. The method of any one of claims 34-36, wherein the meta data comprises previously encrypted meta data.

38. The method of any one of claims 34-36, wherein the meta data comprises unencrypted meta data.

39. The method of any one of claims 34-38, wherein generating the license agreement between the licensee and the licensor for the digital asset comprises automatically substituting at least a portion of one or more of the information about the digital asset, the meta data associated with the digital asset, information about the licensee, information about the licensee’s intended use of the digital asset , and / or information about the licensor into a template license agreement.

40. The method of claim 39, wherein generating the license agreement between the licensee and the licensor for the digital asset comprises automatically generating the license agreement using artificial intelligence (Al).

41. The method of claim 40, wherein the Al comprises a Large Language Model (LLM) to generate the license agreement based upon the Digital Asset’s meta data.

42. The method of claim 41, wherein the LLM further uses at least a portion of one or more of the information about the digital asset, the information about the licensee, the information about the licensee’s intended use of the digital asset, and / or information about the licensor to generate the license agreement.

43. The method of any one of claims 40-42, wherein the meta data of the digital asset includes constraints on the digital asset and the Al compares the constraints on the digital asset with the information about the licensee and / or the information about the licensee’s intended use of the digital asset to determine if terms of the license agreement can be written to satisfy both the constraints on the digital asset and the licensee’s intended use of the digital asset.

44. The method of claim 43, wherein the constraints on the digital asset include prohibition of the use of the digital asset within Hate Speech, Deceptive Advertisements, Misinformation, or Adult Content, or prohibiting use of the digital asset in products and / or services that may compete with the licensor.

45. The method of any one of claims 1-44, wherein providing the digital asset to the licensee comprises providing the encrypted digital asset to the licensee.

46. The method of any one of claims 1-45, wherein providing the digital asset to the licensee in accordance with the executed license agreement if the request is in compliance with the executed license agreement comprises transforming the encrypted digital asset if the request is in compliance with the executed license agreement.

47. The method of claim 46, wherein transforming the encrypted digital asset comprises decrypting the encrypted digital asset before providing it to the licensee.

48. The method of claim 47, wherein determining if the request is in compliance with the executed license agreement comprises decrypting the digital bundle and determining if the request is in compliance with the executed license agreement.

49. The method of any one of claim 47 or claim 48, wherein the digital asset and / or the digital bundle are decrypted using a method of decryption comprising the steps of: a. initializing a system state, wherein the initialized system state matches a system state of an encrypting method used to encrypt the encrypted data; b. obtaining a pre-amble size based upon the initial system state; c. ingesting a data set, wherein the ingested data set has a size equivalent to the pre-am- ble size; d. updating the system state with the ingested data set size; e. process encrypted meta data associated with the digital asset and / or the digital bundle to produce an unencrypted meta data value from at least a portion of the encrypted meta data; f. update the system state with the unencrypted meta data value;g. repeat e. - f. until the encrypted meta data associated with the digital asset and / or the digital bundle is exhausted; h. process the encrypted data of the digital asset and / or the digital bundle to produce decrypted data from at least a portion of the encrypted data based upon a probabilistic state machine probabilities found through one or more deterministic random data generators, where said processing comprises: i. rendering percentages from deterministic random data, ii. determining one or more configured operation based upon a probability of the configured operation to be applied, iii. mimicking the encrypting method used to encrypt the encrypted data associated with the digital asset and / or the digital bundle to calculate data length and parameters needed, iv. acquire encrypted data of the digital asset and / or the digital bundle to ingest, v. acquire additional parameter data needed for the one or more configured operations, vi. apply inverse operations to the ingested encrypted data, vii. update system state; and i. output the decrypted data.

50. The method of claim 49, further comprising repeating steps e.-i. until the encrypted data is exhausted.

51. The method of claim 50, wherein outputting the decrypted data comprises outputting a stream of decrypted data after the exhaustion of the encrypted data, wherein random data is rejected from the stream of decrypted data.

52. The method of any one of claims 50-31, wherein the encrypted data is exhausted when no additional output is required.

53. The method of any one of claims 49-52, wherein the encrypted data to ingest is from a random data, deterministic random data, time stamp, IP address, computer internal state, probabilistic state machine internal state, external data acquisition, data file, memory, or a network port.

54. The method of any one of claims 49-53, wherein the one or more configured operations are an invertible function.

55. The method of any one of claims 49-53, wherein the one or more configured operations are an injection of configured meta-data.

56. The method of any one of claims 49-53, wherein the one or more configured operations are updates to the system state.

57. The method of any one of claims 49-53, wherein the one or more configured operations are external locations of updates to the system state.

58. The method of claim 57, wherein the external locations include another IP address, a website, or a remote or local device.

59. The method of any one of claims 49-53, wherein the one or more configured operations are an injection of random data.

60. The method of any one of claims 49-53, wherein the one or more configured operations are operations changing the system state.

61. The method of any one of claims 49-53, wherein the one or more configured operations are internal state, bit, binary object, or block based.

62. The method of any one of claims 49-61, wherein the system state includes preconfigured metadata.

63. The method of any one of claims 49-61, wherein the system state includes preconfigured function probabilities.

64. The method of any one of claims 49-61, wherein the system state includes preconfigured constant data.

65. The method of any one of claims 49-61, wherein the system state includes preconfigured access to external metadata, and accesses a remote location to find such metadata.

66. The method of any one of claims 49-61, wherein the system state includes preconfigured access to external constant data, and accesses a remote location to find such constant data.

67. The method of any one of claims 49-66, wherein the decrypted data is processed by an existing data decryption, transformative, or protective algorithm.

68. The method of any one of claims 49-67, wherein a decryption mask or pad information is not required.

69. The method of claim 68, wherein the decryption mask or pad information has not been stored.

70. The method of any one of claims 46-69, wherein transforming the encrypted digital asset comprises transcrypting the encrypted digital asset before providing it to the licensee.

71. The method of claim 70, wherein the encrypted digital asset is transcrypted by a method of transcryption comprising the steps of: a. initializing a system state, wherein the initialized system state matches a system state of an encrypting method used to encrypt a first encrypted data of the digital asset; b. processing the first encrypted data to produce a second encrypted data of a second type from at least a portion of the first encrypted data, wherein said processing comprises: i. acquiring first parameter data needed for primary operations, ii. acquiring second parameter data needed for secondary operations from subsystem, iii. combine primary parameter data and secondary operation data into a replacement operation for a compatible operation, iv. acquiring at least a portion of the first encrypted data to ingest,v. applying the replacement operations to the first ingested data, vi. updating the system states; and c. outputting the secondary encrypted data.

72. The method of claim 71, further comprising repeating steps b.-c. until the encrypted data is exhausted.

73. The method of any one of claims 46-72, wherein transforming the encrypted digital asset comprises re-encrypting the encrypted digital asset before providing it to the licensee.

74. The method of claim 73, wherein the encrypted digital asset is re-encrypted by a method of re-encryption comprising the steps of: a. initializing a system state, wherein the initialized system state matches a system state of a primary encrypting method used to encrypt the encrypted data; b. initializing a system state of a subsystem with a second encryption configuration; c. processing primary encrypted data to produce secondary encrypted data of a second type from at least a portion of the primary encrypted data, wherein said primary and secondary encrypted data arc produced based upon a probabilistic state machine probabilities found through deterministic random data, where said processing comprises: i. rendering percentages from deterministic random data, ii. rendering percentages from deterministic random data from the subsystem, iii. testing for one or more common configured operations probability that can be combined to be applied, iv. acquiring additional parameter data needed for primary operations,v. acquiring additional parameter data needed for secondary operations from subsystem, vi. combine first parameter data and secondary parameter data into a replacement operation, vii. acquire encrypted data to ingest, viii. applying the replacement operations to the ingested encrypted data, ix. updating the system states of the primary encrypting method and the subsystem; and d. outputting the secondary encrypted data.

75. The method of claim 74, further comprising repeating steps c.-d. until the encrypted data is exhausted.

76. The method of any one of claims 1 -75, wherein the digital asset is owned by a company or individual.

77. The method of any one of claims 1-76, wherein the digital asset comprises a plurality of digital assets to be licensed under a single license agreement terms applicable to the plurality of digital assets.

78. The method of any one of claims 1-77, further comprising requiring payment or requiring confirmation of payment prior to providing the digital asset to the licensee.

79. The method of any one of claims 1-78, wherein the encrypted digital bundle is associated with the digital asset as meta data of the digital asset.

80. The method of any one of claims 1-79, wherein the encrypted digital bundle includes the en- crypted digital asset.

81. The method of any one of claims 1-80, wherein providing the digital asset to the licensee comprises providing the digital asset to a designee of the licensee.

82. The method of any one of claims 1-81, wherein the digital asset is created using generative Al.

83. A method of recording events in an encrypted format, comprising: a. initialize a digital record with a known encryption type; b. collect events to record; c. encrypting events using an artificial-intelligence AI-Based encryption; d. appending encrypted events to end of digital record.

84. The method of claim 83, where events is events and meta data.

85. The method of claim 83, where events is digital assets, events, and / or meta data.

86. The method of claim 83, where encrypted format is mutable encrypted format.

87. The method of claim 85, where digital assets is contracts, license agreements, terms of use, acceptable use policy, document, template, event ticket, payments, bills, government issued ID, government issued credentials, digital signature / approval, title, registration, lease, rental agreement, company employee ID / credentials, 2D / 3D digital models, Large Language Model, Al Model, audio, video, or photos.

88. The method of claim 85, where access to digital asset is provided through indirect access such as Uniform Resource Locator (URL), Uniform Resource Identifier (URI), Physical Address, password, access token, or OAuth access.

89. The method of any one of claims 83 - 88, where encrypted format is encrypted format with corruption detection.

90. The method of any one of claim 83 - 89, where steps b.-d. are repeated for new events.

91. A method of recording events in an immutable encrypted format, comprising: a. initialize a digital record with a known encryption type, including an end of record event; b. collect events to record; c. Transcrypt existing digital record, while inserting encrypted collected events before end of record event;92. The method of claim 91, where events is events and meta data.

93. The method of claim 91, where events is digital assets, events, and / or meta data.

94. The method of claim 91, where encrypted format is partially encrypted format.

95. The method of claim 91, where encrypted format is unencrypted format.

96. The method of claim 93, where digital assets is contracts, license agreements, terms of use, acceptable use policy, document, template, event ticket, payments, bills, government issued ID, government issued credentials, digital signature / approval, title, registration, lease, rental agreement, company employee ID / credentials, 2D / 3D digital models, Large Language Model, Al Model, audio, video, or photos.

97. The method of claim 96, where access to digital asset is provided through indirect access such as Uniform Resource Locator (URL), Uniform Resource Identifier (URI), Physical Address, password, access token, or OAuth access.

98. The method of any one of claims 91- 97, where encrypted format is encrypted format with cormption detection.

99. The method of any one of claim 91 - 98, where steps b.-c. are repeated for new events.

100. A method of reading events recorded in an encrypted format, comprising:a. Initialize a decrypter capable of reading the know encrypted format; b. Ingest the event data; c. Decrypt event data; d. Output event data.

101. The method of claim 100, where reading is accessing.

102. The method of claim 100, where events is digital assets, events, and / or meta data.

103. The method of claim 100, where digital assets is contracts, license agreements, terms of use, acceptable use policy, document, template, event ticket, payments, bills, government issued ID, government issued credentials, digital signature / approval, title, registration, lease, rental agreement, company employee ID / credentials, 2D / 3D digital models, Large Language Model, Al Model, audio, video, or photos.

104. The method of claim 103, where access to digital asset is provided through indirect access such as Uniform Resource Locator (URL), Uniform Resource Identifier (URI), Physical Address, password, access token, or OAuth access.

105. The method of any of claims 100 - 104, where output is output if authorized.

106. The method of claim 105, where authorized is granted by the issuer.

107. The method of claim 105, where authorized is granted by the holder.

108. The method of claim 105, where authorized is granted by the verifier.

109. The method of claim 105, where authorized is granted by an included digital asset.

110. The method of any of claims 100 - 109, where steps b. - d. are repeated for each event.

111. The method of any of claims 100 - 110, where access is automated.

112. The method of any of claims 100 - 111, where authorized is automated.

113. The method of any of claims 100 - 112, where output is output delivered securely through transcryption.

114. The methods of 85 and 93, wherein the means to generate records forming a license agreement, are comprising the steps of: a. determine digital assets of interest; b. get licensee data; c. licensor present acceptable use and fees for assets; d. use the above information to compile a binding contract; e. licensee agrees to contract; f. Release licensed assets per contract terms;115. The method of claim 114, where contract charges are billed to customer and appended to recording events.

116. The method of any of claims 114 - 115, where licensee payments are appended to recording events.

117. The method of any of claims 114 - 116, where licensed assets accessed are appended to recording events.

118. The method of any of claims 114 - 117, where digital signatures are appended to recording events.

119. The methods of 85 and 93, wherein the means to generate records forming an authorized event ticket, are comprising the steps of: a. selecting venue showing; b. select venue seating; c. present ticket pricing; d. collect attendee information; e. buying one or more tickets; f. package event tickets into digital record; g. present digital record at venue for seating.

120. The method of 119, where present ticket pricing is present ticket pricing and terms and conditions such as transferable, digital photo required, and / or digital signature.

121. The method of 119, where transferring ticket involves appending new owner’s information to recording.

122. The methods of 85 and 93, wherein the means to generate records forming an is- suer / holder / verifier are comprising the steps of: a. issuer collect digital assets and meta-data for digital record; b. issuer include digital rights to asset; c. issuer generate digital record for holder; d. issuer provide digital record to holder; e. Holder presents digital record to verifier;123. The method of 122, where issuer is government body / agency, company, enterprise, financial institution, educational institution, credentialing organization, or person.

124. The method of 122, where holder presents is holder partial presents.

125. The method of any of claims 122 - 124, where presents is visually, digitally, electronically, auditory, or tactilely.

126. The method of any of claims 122 - 125, where digital assets is photo, contract, description, Personal Identification Number, video, ticketing information, purchase details, Vehicle Identification Number, title, registration, lease, rental, contract, license, credentials.

127. The methods of 85 and 93, wherein the means to generate records forming a controlled digital asset are comprising the steps of: a. owner collect digital asset to be controlled; b. owner set terms of user of asset in meta-data; c. encrypted the above into digital record; d. provide user access to digital record;e. record user access by appending to digital record;128. The method of claim 127, where owner is artist, musician, dancer, content creator, craftsman, Leaser, publisher, news organization, writer, issuer, programmer, Al Model builder, architect, inventor, or studio.

129. The method of claim 127, where provide user access is done through transcryption.

130. The method of claim 127, where provide user access is done through a specialized portal.

131. The method of claim 127, where provide user access is done through a special tool.

132. The method of claim 127, where provide user access is done through transcryption.

133. The method of claim 127, where provide user access is provide user access with a wa- termark.

134. The method of any of claims 83 - 133, where the end applications is Secure FileSharing, Watermark Protection, Format Conversion, Archiving & Backup, collaboration withAl Models,

Images