NZ726067A - System and methods for using cipher objects to protect data - Google Patents

Abstract

Systems, methods, and devices configured to build and utilize an intelligent cipher transfer object are provided. The intelligent cipher transfer object includes a set of participants protected by cloaking patterns. A portable dynamic rule set, which includes executable code for managing access to the protected set of participants, is included within the intelligent cipher transfer object. For a given user, the intelligent cipher transfer object may provide access to some of the participants while preventing access to other participants, based on the portable dynamic rule set therein.

Description

SYSTEM AND METHO‘DS FGR USlNG CIFi-iER OBJECTS T0 .i RGTECT DATA This application is a divisional ofNZ No. 726067 which claims priority of US.

Provisional Application No. 61/980,617, filed April 17, 2014.

The specifications, figures and complete disclosures of US. ation No. 61/980,617 and NZ 726067 are incorporated herein by this cross reference.

) GTE ENVENTEGN This inVention relates to a system and related methods for ting and controlling data using self—encryption and selfgovernance, including, but not limited to, the use of an intelligent cipher transfer object.

BACKGRGEJND GE THE ENVENTEON/ Current techniques for protecting data have certain cks When information is e of a trusted environment, like a secure network, it is typically protected by encryption in large part because other security measures, such as network 1AM and PAC applications, no longer govern use of the information. in current techniques, encryption keys must be present within an applicatior, or revealed or traded by users or via an application, for encrypted data to be useful, thereby potentially compromising protection and confidentiality. tion .ceys can be stolen [\JO in a discovery or APT assault, or can be compromised via social engineering or other means. Further, once an encryption key (or password) is shared and 'he data unlocked, l of the data is lost. Even when data is within a trusted environment, such as behind a firewall or the like, it is vulnerable to attack or misuse, as fi es are available to anyone with access to their storage location. Protecting ation traditionally requires teams of people with expertise in networks, BYOD, telecommunication, s and applications, integrating them all and nating efforts on an enterprise scale to achieve a level of security which nevertheless can be compromised by exploiting flaws and gaps inherent in complex integrations.

Typical data encryption relies on algorithms that run in a predetermined sequence to encrypt and then run in the reverse ce to decrypt. There may also be a process of moving pieces of data in a static pattern to cloak it, and then reversing the attacker process to reveal the complete, unencrypted file. With this prior—art method, an who understands the encryption algorithm used to encrypt data can break the encryption by reversing the encryption process.

Fully homomorphic encryption attempts to remove the trust aspect of a relationship, making trust n parties an irrelevant factor. For example, one party can send their data to an rcer for storage or processing without trusting what the outsourcer might do with it, as the outsourcer is only given access to an encrypted version of the data to perform processing that does not e decryption. However, fully homomorphic encryption is too curnbersome to be practical.

Another traditional technique for protecting data is the use of dynamic controls. Dynamic controls are application dependent, such as password protected PDF files generated and used by document viewing and editing software produced by , or the like. Traditional dynamic controls are dependent on the application or reside within an application. Rules are executed by the application. ~While also dependent on a key (password) exchange as given above, another drawback to this method is that application—dependent rules may be overridden (as in the example of a ted PDF opened with Adobe® t®) or, a developer could write an application that ignores the rules imposed by the authoring application.

Accordingly, what is needed is a data assurance solution that is self—protecting and self~governing, that is less dependent on keys and passwords for authentication, on predictable reversible encryption sequences for protection, and on external applications for execution while remaining functional and efficient both within and e the secure environment, both for data at rest and in transit.

SUMMARY OF INVENTION This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features of the claimed subject matter, nor is it intended to be used as an aid in ining the scope of the claimed subject matter.

In l exemplary ments, the t invention comprises a self— protecting, self—controlling intelligent cipher transfer object (ICTO), which may be stored a set of participants including a on a cornputer~readab1e medium. The lCTO comprises portable dynamic rule set (PDRS). The PDRS, in response to execution by one or more processors or microprocessors of a computing device, causes the computing device to m actions, including, but not limited to, the following: receiving, from an agent, a request for access to a portion of a participant of the set of participants; verifying that the agent is authorized to access the requested participant portion; and providing access to the requested participant portion for the agent without providing access to other portions of the set of participants for the agent. A computer—implemented method of creating such an ICTO and a computing device configured to execute the executable portions of such an lCTO are also provided.

In one exemplary embodiment, the present ion comprises an ICTO~ limited aware application, operating system, or device, including, but not to, computer chips, es, controls panels, FGPAS, and the like, that activates the ICTO in response to a request for access. The ICTO comprises a set of participants including but not limited to owner data, and a PDRS. Upon activation of the dynamic ipant controller (DPC) Within the ICTO, ly or locally, the PDRS within the ICTO takes and maintains control of the ICTO until the protected object is closed (i.e., inactive or asleep). The PDRS, responding to the agent access request, through the dynamic participant controller, to all or some of the participant data, verifies the agent is authentic and authorized to access all, some, or none of the protected data set. Upon verification, the agent can only access authorized portions of the protected data set while the remaining protected data within the ICTO remains ssible to the agent. A computer—implemented method of creating such an ICTO utilizing the an lCTO—aware ation, ing system or device to activate executable portions of such an ICTO is also provided.

In a further embodiment, a computer—implemented method of protecting a set of participants is provided. A set of participants to be protected is ed by a computing device. One or more cloaking patterns for ting the set of participants a first are ined. A first cloaking n is used to protect or mix subset of the set of participants, and a second cloaking pattern different from the first cloaking pattern is used to protect or mix a second subset of the set of participants. The determined cloaking patterns are applied by the computing device to the set of participants to create a set of cloaked or mixed participants. The set of cloaked participants are added by the computing device to an ICTO. A computing device configured to perform this method and a computer—readable medium having computer—executable instructions stored thereon that, in response to execution by one or more processors of a computing device, cause the computing device to m such a method are also provided.

In yet another embodiment, the present ion comprises an iCTO-aware application. eperating system, 01 {ievi ethat .amntates this method for protecting a set of ipants. A set of participants is gathered through an MTG-aware application. cperatmg svstem or device to create an m iatte.111 TCTO, which inciteices a set of v J ipants and H starter ‘1 a temporary or rule set ded by the cipher engine or d.vnamia1artii1a111t c ntr‘oll1.1 until O is fully i111 Diet—heated. The interim attern lC’i‘t} is (1:0...)er bv one or more eioalans patterns dynammaiy selected or protinceca911d applied by the c prrttiipant controiier. The temp/01121.13 rule set is subsequently repiaced with one 01' m ore specitic or unique tale sets as deticnd b'1 the1.12/116; one1 or more cloaiing pattc1113 are dynamically and randomly sccleted or produced for each iCTQ by the PDRS within the ETC). Cloaking patterns may be applied randomiy to all 1‘ some portio1 of the paartici‘: ants White additic-nal cioai:ing patterns may be applied randomiy' to all or some portion of the 1);}1'FIL3§2313.§.S to create a. unique cloaked set of participants for each KITS. in another embodiment. a computing device configured to access data protected an ICTO is provided. An access request from an agent to access a 01' ed by portion of a participant stored or mixed in the ICTO is received by the computing device. A PDRS Within the ICTO is activated by the computing device. At least one rule in the PDRS is executed by the computing device to evaluate the access request. In response to determining that the access request is sible, access to the portion of the participant requested by the agent is ed Without providing access to other participant ns.

In yet another embodiment, the present ion comprises an IiCrlU—avy'are appiication, or;crating system or device that activates the lCTO upon receiving an access A use. v~-u4~,v-v .VU request from an agent. The dynamic participant controller within the {CEO is activated: and upon activation. the embedded PDRS takes and maintains control of the ECTO. At least one rule is or" PDRS is executed to evainate the authenticity and ization of the agent to access ail, some, or none of the protected data. it the agent is granted access to an or some of the protected data, the protected data not authorized for access r‘mains pro acted and not visible. to the peepssng agent. The inactive FTC is inaccessible without an, iCTi‘Qawate application, operating system or device.

BRIEF DESCRIPTEGN OF THE DRA‘WENGS The ing ' s and many of the ant advantages of embodiments of the present disclosure will become more readily appreciated as the same become better understood by nce to the following detailed description, when taken in conjunction with the accompanying drawings Figure 1 shows a schematic diagram that illustrates an exemplary embodiment of data governance according to s s of the present invention.

Figure 2 shows a flowchart that illustrates an exemplary embodiment of a method of constructing an lCTO according to various aspects of the t invention.

Figure 3 shows a flowchart that illustrates an exemplary embodiment of a method of accessing data protected by an lCTO according to various aspects of the present invention.

Figure 4 shows a schematic diagram that illustrates an exemplary use case for an embodiment of the nt invention.

Figure 5 shows a schematic diagram that illustrates aspects of an exemplary workflow for an embodiment of the present ion.

Figure 6 shows a block diagram that illustrates an exemplary hardware ecture of a computing device suitable for use with embodiments of the present invention.

Figure 7 shows a schematic diagram that illustrates an exemplary embodiment of data governance according to another exemplary embodiment of the present invention.

Figure 8 shows a flow chart that illustrates a exemplary embodiment of creating an ICTO according to another exemplary embodiment of the present invention.

Figure 9 shows a flow chart that illustrates a ary ment of accessing an lCTO according to another exemplary embodiment of the present invention.

Figure 10 shows a View of a portable identity appliance system in accordance with another exemplary embodiment of the present invention.

Figure ll shows a diagram of a portable identity appliance used to produce a protected .

Figure 12 shows a diagram of a portable identity appliance used to facilitate secure messaging of protected data.

Figure 13 shows a diagram of a portable identity appliance used to guard access to websites, portals, networks, or other resources.

DETAELED DESCRlFTlGN OF EXEMPLAEY EMBGDVEMENTS In several exemplary embodiments, the present invention comprises a self— contairred, self—protecting, self—controlling intelligent cipher transfer object (lCTO), which may be stored on a computer~readable medium. The lCTO ses a set of participants including a portable c rule set (FDRS). Computer-implemented methods of creating, accessing, and using such an lCTO, and a computing device configured to execute the able portions of such an lCTO, also are ed.

In various embodiments, the present invention addresses critical faults with previous data protection systems and methods. The present invention fills a gap in existing protection schemes because existing schemes address perimeter defenses, user access (both users and their devices) and anomaly ion, but are not attached to the data itself. If art encryption is utilized, the burden of key code management may reduce productivity or flaws may create yet other vulnerabilities by exposing keys that likewise need to be ted. ments of the present disclosure provide a self—contained, self—protecting, self—governing, entric solution, meaning that the controls for data management, protection, and administration are grafted into, and become part of, each data set and directly e the data set‘s access and use. Though, in some embodiments of the present disclosure, some data can be removed from protection for analysis or use by an ized agent, the method of removal from protection is not predictable because it is not a reversal of the protection mechanism or mechanisms. The present invention comprises an unpredictable and irreversible system and associated methods to retain dynamic, portable, independent, persistent, intelligent governance of data over the life of the data‘s existence. This system is capable of protecting data while the data is stored or in t, and in the hands of trusted data users or untrusted data users.

In some embodiments of the present disclosure, the data protection scheme is ed within, d to, and maintained within the data—set. The data protection scheme may also create an audit trail of attempts to access the data. Known or ized users of the data are noted in an embedded log, while unknown parties or other unauthorized attempts to access the data are likewise noted in the embedded log and can be transmitted and displayed to the data owner in real time. it an unauthorized party attempts to access the data, the self—protecting data can defend itself, take offensive action against the ion, alert the data owner to the unauthorized attempt, and/or take any other appropriate action.

The data owrier utilizes the tion scheme as a simple and eight management tool that continuously validates the relationship of the parties to the data. From an attacker's point of View, the system is ictable because every authorized party has its established identity incorporated into the protection scheme.

A unique pretecticn, scheme may be provided fer eachccnibinaticn cfcrvner, usernr . r, and dataset; this means that the method by which data is revealed to Authorized Party A would not be the way data is revealed to ized Party B.

Further, the unique protection scheme that may be provided for a combination of owner, user, data set and rule set will likewise be unique to itself when the same combination is protected subsequent times. That is, each time a combination of owner, user, data set and rule set is protected as described herein, whether it is the same combination or a different combination, the ICTO will be a uniquely protected TCTO.

In some embodiments, different techniques may be. used to protect the data and to access the protected data. For example, an irreversible protection scheme may be used to combine le pieces of data into a single digital mixture, such that a selective retrieval scheme may be used to selectively retrieve pieces of data from the single l mixture without obtaining access to other protected data in the l mixture. In such an embodiment, when the data is properly accessed, it is selectively revealed, based upon the owner’s wishes for the authorized recipient. The path to reveal information is not a function of retracing the original steps, and the original protection scheme used to combine the le pieces of data may not be reversible other than with respect to individually requested pieces of data. In other words, even though pieces of data stored by the protection scheme may be accessed, the totality of the digital mixture is not accessible in such a way that allows the totality of the al contents to be reconstituted. Embodiments of the present disclosure are configured to positively identify any user or entity identity such that is included as a participant as legitimate or not, and the data owner controls which portions or pieces of data to which the identified legitimate users can gain access. orized parties, whether inside or external to the intended recipient or the ed recipients network, can never access the data in its unprotected form. Embodiments of the present disclosure unequivocally confirm the identity of a trusted party before providing access to ensure data security.

Reversing or reverse engineering the protection scheme cannot yield the original results.

In several embodiments of the present ion, rules are executed by an executable. portion of the digital mixture, ensuring the absolute wishes of the data owner are enforced Without relying on a third party or an outside entity or application or ing system. The protection scheme is not dependent on an application or an operating system to protect/unprotect the data: the data is self— protecting and self~controlling The protection scheme is independent of ing , environment, and application (i.e., external or centralized or server key management, password management and ty management applications).

Methods in the protocol are implemented in executable code stored in the data mixture, and are executed in response to ing a request by the user to access the data through a ured API. Furthermore, the data can be of any type (e.g., text, audio, video, or combination thereof), and in any kind of container, database or environment: (eg, buffer, directory, file, or combinations thereof). Any attempt to access the data other than through the API or other means described herein will be foiled by the applied cloaking patterns, which will he undeterminable by any component outside of or other than the components implementing the API. When attempting to access the data through the API or other means described herein, the protection scheme ensures that legitimate users are only able to access data as permitted by the data owner.

Other methods initiated through the API, or other ICTQ¥aware application, device or operating system, initially validate the ICTO. Subsequently, the outer ng technology locates the able code, cipher engine, or mixer stored in the l e. A request for access is received by the executable code via the API or other lCTO—aware application, device or operating system on behalf of the agent. The executable code is energized, or “awakened,” at which point the portable dynamic rule set takes and maintains control until the self~governed data object is closed or becomes inactive. Any t to access the self—protecting, self— control ing digital mixture without energizing the executable code will be unsuccessful. 1316. l is a schematic diagram that illustrates an exemplary embodiment of self governing data ing to various aspects of the present invention. A c ipant controller £16, or ”mixer,” identifies a set of digital ingredients ("participants") 1&1, including descriptions of authorized agents, device locations, rules for using the data, and/or other ingredients as discussed further below. By mixing these ingredients, the mixer 11% forms a cloaked , the intelligent cipher transfer object, or ICTO 115. The ICTO 115 may also be called a al mixture.“ As discussed herein, one of ordinary skill in the art will recognize that the terms "lCTO" and “digital mixture" and “self—governing data” may be used hangeably. To an unauthorized entity or third party g the ICTO 115 directly, the ICTO 115 may simply appear to be a set of data. The ICTO 115 appears to the outside as a homogenous mixture Without resembling or exposing the original ients. However, when accessed via an application implementing the API (such as the mixer 110, an ICTO—aware client application (not illustrated), and/or the like), executable portions of the ICTO 115 are accessible to e access to the data governed by the ICTO 115.

In some embodiments, the executable portions of the ICTO 115 may be stored at a determinable location within the ICTO 115 to allow an application implementing the API to easily find the executable portions. In some embodiments, additional protection may be applied to the ICTO 115 by storing one or more executable portions of the ICTO 115 at variable locations within the ICTO 115‘, While these variable locations make the executable portions of the ICTO 115 exceedingly difficult for an unauthorized user to find, an ICTO~aware application l0 implementing the API for accessing the ICTO 115 may be able to compute the variable locations for a given ICTO 115 based on a feature of the ICTO 115. For example, the secure application may read an attribute of the ICTO 115 such as a file size, a on time, and/or the like, and may perform a calculation that determines the location using the ute as a seed. By keeping the details of the calculation l5 secret, the location of the executable portions of the ICTO 115 can likewise be kept secret.

The set of participants 1111 may include object descriptions 1112, mixture metadata 104, owner data 166, cloaking patterns 107, an ty module 109, and an igence module 111. In some embodiments, a combination of the identity module 1619 and the intelligence module 111 may be considered together as a portable dynamic rule set 108. The object descriptions 1112 may include owner~supplied and owner— defined ‘ks, ,data identifiers,and/or pmperties. Owner data 106 may include1data that is to be protected within the ICTO 115, such as a nt, a file, a buffer, a directory, a pointer to remotely stored data, database, and/or the like. In some embodiments, owner data 106 may be optional, if the ICTO 115 is merely used, for example, for a signature verification method that is not associated with underlying signed data. In some embodiments, multiple pieces of owner data 106 may be included within a single ICTO 115. In some embodiments, owner data 106 from multiple owners may be ed within a single ICTO 115‘ 3O The cloaking patterns 107 specify various combinations of data tion and access ques supported by the mixer 110. The data protection and access .L V.“ VVJ-UAL'IUHV’TUU techniques included in cloaking patterns 107 may include techniques such as industry rd ed tion, compression, ization, normalization, and/or other techniques. Techniques suitable for use as ng patterns 107 are not limited to currently known techniques, but could include any privately or publicly available encoding and/or decoding technique, known now or developed in the future. Use of a cloaking pattern 107 to protect and/or access data may involve applying the combination of data protection and/or access techniques specified in the cloaking n 167 to the data.

The mixture metadata 104- provides organizational information for the digital mixture 115, such as virtual file system data containing directories, key codes, user files, signatures, and/or the like.

The identity module 109 may include dynamic ty utes that uniquely identify protected agents in a transaction. In some embodiments, the identity module 1G9 may include data that represents a configuration of a computing device that may be given certain rights with respect to a protected . The identity module 189 may contain specific information about hardware or software configurations installed on the computing device usable to identify the computing device. The identity module 109 may contain data including, but not limited to, CPU information including model numbers, number of cores, speed, and/or the like; a chassis serial number; manufacturer data; a volatile memory size; a nonvolatile memory size; one or more e device serial numbers and/or model numbers; installed software titles and/or n numbers, and/or the like. , In some embodiments, a transaction is an atomic action using the lCTO 115 in which one or more agents ly exchange data within a given context and with a specified intent. Authorized agents may include human and non~human entities, such as a human user, a unique mechanical object, a unique onic object, a unique software or program object, and/or the like. Dynamic identity attributes contained in the TCTO 115 may be ed by the intelligence module 111 within or during the course of an interaction with the ICTO 115’, and may include application— specified identifiers, account identifiers, biometric signatures, device and/or location signatures, temporal data, cryptographic keys, and/or the like. In some embodiments, a location signature may include data from a geolocation technology, such as GPS, GSM network locating, IP address locating, dead reckoning, and/or the like. The location signature may include a longitude, latitude, an altitude, an approximate street address, and/or the like. Additional location data such as street, city, state, country, postal code, and/or the like may also be present. In some embodiments, the temporal data may e a tirnestamp and/or the like, which may allow rules or other igent code to enforce timers, expirations, dynamic keys, and/or the like. The al data may include a simple date/time value, or may include a complex schedule comprising timestamp ranges and/or other scheduling guidelines.

IO In some embodiments, each ICTO 115 includes at least one l signature key. The digital signature key may be ted using an external l certificate available to the mixer 110. During access of the ICTO 115, the mixer 110 validates the digital signature key using the external digital certificate and verifies that the digital signature key is valid for an agent currently accessing the ICTO 115. In some embodiments, multiple agents may sign off on the ICTO 115, In such an embodiment, the ICTO MS may e a chain of ure keys, wherein each ure key may be associated with a separate external digital certificate for validation. For example, an ICTO 115 may be used by an owner to create a protected file for a transfer to multiple agents wherein each agent may access different sections of the file but not the entire file, either simultaneously or sequentially. Both the owner and the agents may have to provide valid digital sig— natures to allow the transaction to proceed.

The igence module 111 iliayinelilde dmarnic rule pable of recording and communicating access data and other nt y; along with intelligent code that provides configurable functionality for performing actions to protect the ICTO 115.

Rules may be provided at object creation time. However, in some embodiments, a rule may have a capability to modify itself or other rules for a previously created ICTO 115. In some embodiments, a rule may have a capability to create additional rules. For example, a rule may determine, from identity data, that additional protection is desirable for a given ICTO 115, The rule may then create additional encryption and/or decryption rules to be applied. The rules are protected and contained Within the ICTO 115. In some embodiments, the rules may only be executable by an executable portion of the intelligence module 111, and/or may be written in a proprietary language and stored in com— piled or binary form. Based on the rules and requirements of the identity module 109, the intelligence module 111 acts on its rules and requirements.

Application—specified identifiers may vary from access to access, and may vary depending on a type of agent. For example, for a human user, ation-specified fiers may include t keys, transaction information, context keys, associated intents, and/or the like. For an electronic object, a digital asset, or any other potential agent, application—specified identifiers may also include an IP address, a URL, a file specification, and/or the like.

In some embodiments, the embedded portable dynamic rule set or sets have read/write access to the ed participants 1611, even while the participants 1921 are protected by the ICTO 115° In other words, a rule may read and write data to the mixture metadata 1614 and the owner data 106 of the ICTO 115. This may be useful for recording access ation such as date, time, place, and the like, and/or to destroy the data if an attack is detected. Some examples of decisions made or actions taken by intelligent code within rules may include, but are not limited to: evaluating object content and context for validity; challenging an agent for proof of identity; interacting with client code; contacting a server for validation; causing the lCTO 115 to self~destruct; maintaining a history of object access and sending the history information to a server; allowing on~line and/or off—line object access; creating new rules based on dynamic server updates; encrypting and decrypting data; marshes and unniangling, vndmr the like.

The use of portable dynamic rules may have various benefits. For example, pre~ encryption and pie—decryption rules may provide dynamic salt and encryption keys based on participant—specified criteria. Such dynamic keys may be based on temporal data, environment data, or any other algorithm specified in a cryption rule. As another e, rules may access encrypted identity artifacts within the ICTO 115 in order to validate the agent without exposing unprotected data to unauthorized users. As yet r e, because the rules are le and are therefore included Within the ICTO 115, rules may be written in such a way as to allow the lCTO 115 to be fully protected from unauthorized access even when off—line or out~of~network As a further e, rules may add nested protection. If the TCTO 115 protects a document that is meant to be read by a single agent Within one hour of creation, 21 rule may implement the timer and issue a self—destruct mechanism.

As stated above, the embedded mixer 110 uses an embedded portable dynamic rule set 108 to form a mixture of the object descriptions 102, the mixture metadata 104:, the owner data 106, the ng patterns 107, the identity module 1&9, and the intelligence module ill that comprises a self—protecting, self—governing ICTO ”£15, In some embodiments, various components of the lCTO 115 may be marked by encoded checksums to detect tampering. For example, the entire ICTO M5, the rules, the owner data, and/or the user data may each be validated by an embedded checksurn. The checksum may be a hash value generated based on the contents of the checksurn target. In some embodiments, the algorithm used to generate the checksum is sensitive enough to reliably detect a change of a single bit value of even a large data-set. Some suitable algorithms include MDS and SHA, though any other suitable algorithm may be used. Each checksum may be appended, prepended, or otherwise combined with the checksum target for storage, or may be stored in a separate location.

FIG. '7 is a schematic diagram that illustrates another exemplary embodiment of ontained, self~controlling, self—governing data protection according to additional ments of the present ion. An API or other lCTO-aware application, device, or operating system initiates a request to the dynamic participant controller or executable mixer 732, thereby energizing it, to protect a set of digital participants 7&1. Digital participants include, but are not d to, authorized agents, devices,,, , , ,, locations, rules for using the data, and/or other digital ingredients as discussed further below, gathered for inclusion in the self—protecting, self—governing data object (i.e., l mixture, or ICTO) 710. The dynamic ipant controller 702, when energized, creates an interim cipher object 703 utilizing a temporary or er“ rule set While said object is being constructed. The interim cipher object 793 is cloaked using one or more outer Cloaking patterns 704 selected, created or produced by algorithms generated by the mixer 702.

In some cases, onal protection or functions, or combinations thereof, may be applied by storing one or more executable portions of the ICTO 718 at variable locations within the ICTO 716}. The initial entry point for the executable portions of the ICTO 71% can only be calculated and located by an ICTO aware application, operating system or device. Once the executable or DPC 792 is located and awakened, a unique table of s is made available to the DPC 74112 to locate the portable dynamic rule set 711 within the ICTO 710* which takes and maintains l while the ICTO 71% is active.

The set of digital participants 7% may include, but are not limited to, outer cloaking—patterns 704‘, mixture metadata 78:3”, owner data 706, inner cloaking patterns 797, an identity module 78%, and an intelligence module 7G9. In some embodiments, a combination of the inner cloaking patterns 707, the identity module 7818 and the intelligence module 7819 can be considered together as the portable dynamic rule set (PDRS) 711. Owner data 706 that is to be protected within the ICTO 710 and governed by the PDRS 711, may e a number of data types, including, but not limited to, an image, a Video, a message, an email, a document, a file, a buffer, a directory, a pointer to remotely stored data, a portal, and the like. In several embodiments, owner data 7% may be optional and thus not included, such as when the ICTO 7104 is merely used, for example, as an irrefutable and certain signature verification method. In some ments, multiple pieces of owner data may be mixed into a single ICTO 71%. In other ments, owner data from multiple owners may be included in a single ICTO 7%. hr further embodiments, multiple ICTOs could be mixed into a single ICTO.

The inner cloaking patterns 707 specify various combinations of datapr‘otect'ron and access techniques determined by the owner’s rules set forth in the le dynamic rule set 711 and supported by the dynamic ipant controller or mixer 702, The data protection and access techniques included in the inner cloaking patterns 707 may include, but are not d to, techniques such as ry rd encryption, proprietary encryption, compression, randomization, normalization, and the like. Techniques le for use as inner cloaking patterns 707 are not limited to currently known techniques, but could include any privately or publicly available ng and/or decoding techniques, known now or developed in the future. Use of an inner cloaking pattern 707 to protect and/or access data may involve applying the combination of data protection and/or access ques specified in the portable dynamic rule set 711 to the data and other participants.

The outer cloaking patterns 704 specify various combinations of data protection and access techniques selected through one or more algorithms calculated, used, or created by the dynamic participant controller 792 utilizing the interim rule set to create the interim cipher object 703. The data protection and access techniques included in the outer cloaking patterns ’7ta. may include, but are not limited to, techniques such as industry rd verified encryption, compression, randomization, normalization, and the like. ques suitable for use as outer cloaking patterns 7% are not d to currently known techniques, but could include any privately or publicly available encoding and/or decoding technique, known now or developed in the future. Use of an outer cloaking n 704 to protect and/or access data may involve applying the combination of data tion calculated by the dynamic participant controller 7&2 and specified by the interim rule set. The mixture metadata 705 provides organizational information for the digital mixture 710, such as, but not limited to, virtual file system data containing directories, user files, and the like.

The identity module 7®8 may include dynamic ty utes that uniquely identify mate agents in a transaction. Dynamic identity attributes can be learned information that are added to the identity module Within the PDRS such as, but not limited to, location, device, and access or. Learned ation is collected and can be utilized in a future access request session, thereby adding additional intelligence and on points. Additionally, dynamic identity, attributes, can also be volatile (ii: unpredictable) details. They may be presented during the authentication process, alone or in conjunction with personal identity attributes, in the determination of mate identification of an agent requesting access to an ICTO.

In some embodiments, the identity module 708 may include data that represents a configuration of a computing device that may be given certain rights with respect to a protected object. The identity module 708 may contain specific information about hardware or software configurations installed on the computing device usable to fy the computing device. The identity module 708 may contain data including, but not limited to, CPU information including model numbers, number of cores, speed, and/or the like; a chassis serial number; manufacturer data; a volatile memory size; a non— volatile memory size; one or more storage device serial numbers and/or model numbers; installed software titles and/or version numbers, and/or the like.

In several ments, a transaction is an atomic action using the ICTO 71th in which one or more legitimate and authorized agents securely ge data or information within a given context and with a specified intent.

Legitimate, authorized agents may include human and non—human entities, such as a *humanuser,a"tmiqueemechanical objectfa’ unique electronic object, a unique software or program object, or the like. c identity attributes contained in the ICTO 710! IO may be modified by the intelligence module 709 within or duiing the course of an interaction with the ICTO 718, and may e, but are not limited to, application— specified identifiers, account identifiers, biometric signatures, device and/or location signatures, temporal data, crypto—graphic keys or data, and the like. In some embodiments, a location signature may include data from a geolocation technology, such as GPS, GSM k locating, IP address locating, dead reckoning, and the like.

The location signature may include a longinide, latitude, an altitude, an approximate street address, and the like. Additional on data such as street, city, state, y, postal code, and the like may also be present. In some embodiments, the temporal data may include a timestamp or similar information, which may allow rules or other intelligent code to enforce timers, expirations, dynamic keys, and the like. The temporal data may include a simple date/time value, or may include a complex schedule iSingtilllaatalniz lfllgfisélld/QLQQEI scheduling guidelinesi WAVAA, min.“ , , ._ W, , ,7, In some embodiments, each ICTO 716} may include one or more l signature requirements, human or non—human. During authentication by the ICTO 710, the portable dynamic rule set 711 determines the digital signature to be valid for a legitimate, agent requesting access to information governed by the PDRS 711. In some embodiments, multiple legitimate agents may verify the authority of other legitimate agents. In such an embodiment, the PDRS 711 may e a chain of l signature requirements, wherein each digital signature may be associated with a separate mate agent. For e, an ICTO 718 may be used by an owner to create a self— governing file for approvals, signature and transfer to multiple legitimate agents wherein each legitimate agent may access different sections of the file but not the entire file, either aneously or sequentially. Both the owner and the legitimate agents may have to provide valid digital signatures to allow the transaction to proceed.

The intelligence module 709 may include dynamic rule sets capable of recording and communicating access data and other nt events; along with intelligent code that provides configurable functionality for performing actions to govern the lCTO 716}.

Rules. may be provided at object creation time. However, in some embodiments, a rule may» modify itself “or othererules-of a given IGTfi—‘i-‘rtl-instanceteln some embodiments; a rule may create additional rules. For example, a rule may determine, during authentication of a legitimate agent, that additional protection is desirable for a given ICTO 71%. The rule may then create additional access, defensive, cloaking and the like requirements. In some embodiments, the rules may only be executable by the dynamic participant controller 702, or may be stored in a binary form as a participant of the ICTO, or a combination thereof. Based on the rules and requirements of the identity module 7%, the intelligence module 789 acts on its rules and requirements as supplied by the owner agent. Portable dynamic rule set 71}; identifiers may vary from access to access, and may vary depending on atype of agent. For example, for a human user, portable dynamic rule set 7131 ied identifiers may include account keys, ction information, context keys, associated intents, and the like. For an electronic object, a l asset, or any other potential agent, portable dynamic rules set 7111 identifiers may also e an I]? address, a URL, a file specification, and the like.

In, $0.1m eiandinientsrmleshave. read/write access mine d1 anal ipants. 7613, even while the digital ipants 7%: are ted by the ICTO 7102‘. In other words, a rule may read and write data to the mixture metadata 705 and to the owner data 706 of the ICTO 716. This may be useful for recording access information such as date, time, place, and the like, and, in some cases, to destroy the data if an attack is detected. Some examples of decisions made or actions taken by the intelligence module 709 may include, but are not d to: evaluating object content and t for validity; challenging an agent for proof of identity; interacting with client code; contacting a server for verification of trust; causing the ICTO 710 to self—destruct; maintaining a history of object access and sending the history information to a server, by email, SMS, FTP or stored with the lCTO 710', allowing e and/or off~line object access; creating new rules based on dynamic server updates; ng and de—cloaking data; and mangling and unmangling data.

The use of said portable dynamic rule sets 711 has various benefits and purposes.

In one exemplary embodiment, access rules may utilize intern ally created, internally managed, unique keys based on owner—specified criteria. Said unique keys may be based on temporal data, environment data, or any other algorithm specified by an owner’srule set. As another example, said rules may access protected ty artifacts within the ICTO 07% in order to authenticate and validate the agent without exposing the protected data to the world. As yet another example, because said rules are self—contained, portable, platform independent and are therefore included within the ICTO 710, rules may be written in such a way as to allow the ICTO 710 to be fully protected from unauthorized access even when off line.

As a further e, rules may add nested protection: if the lCTO 710 protects one or more lCTOs 710 within the current or outer lCTO 710, the outer ICTO 710 may be able to icate with one or more of the lCTOs 710 managed as part of the owner data 706 of each. Where the outer ICTO 710', or vice—versa, can cause the execution of rules managed within any of the ICTOS 710 included in the owner data 706 of the outer ICTO 710 or create new rules as a result of rules contained in one or more of the included ICTOS 710-. Another example, the rules self—contained within the PDRS 7111 of an ICTO 710 are self~goveming If the lCTO 710 ts a document that is meant to be aCCSSSleJY a single legitimate agent witlriuone hour of creation for a maximuumf one hour after access, a rule may implement the timer and issue a self—destruct mechanism after expiry.

' As previously described, the dynamic ipant controller 702, or mixer, utilizing a portable dynamic rule set 711’creates a e of the outer cloaking patterns 704, mixture metadata 705, the owner data 706, the inner cloaking patterns 707, the identity module 708 and the igence module 709 that makes up the lCTO 710. In some embodiments, various components of the ICTO 710 may be combined for encoded ums to detect tampering. For example, the entire ICTO 710, the rules, the owner data, and/or the participant data may each be validated by a Checksum 7121a The checksum 712 may be a hash value generated based on the contents of the um 712 targets. ~ In some embodiments, the thm used to generate the checksum is sensitive enough to reliably detect a change of a single bit value of even a large document. Some suitable algorithms include MDS and SHA, though any other le algorithm may be used. Each checksum 712 may be appended, ded, or otherwise combined with the checksum target for storage, or may be stored in a separate location.

F1652 is a flowchart that rates an exemplary embodiment of a method % of constructing an ICTO 115 according to various aspects of the present invention.

While the illustrated method 281} describes creation of a relatively simple ICTO 115, one of ordinary skill in the art will understand that similar techniques may be used to create much mere complex ICTOS 115. In some embodiments, the mixer 11% is configured to perform the method 2%., In some embodiments, the method 200 is performed by a ing device, as described below, that is configured to e the functionality of the mixer 1161. One of ordinary skill in the art will recognize that the construction and utilization of the lCTO 115 is neither dependent on the type of said computing device nor on any operating system associated with said computing device, but may instead by constructed and utilized via any suitable means.

From a start block, the method 2M1! proceeds to block 2%29 where a set of common digital ingredients or participants is ed. The common participants are participants Mil which may be used in more than one ICTO 1115, or may at least have similar corr63ponding carnponents in men: than one ICTO its, and arenspreciiiedm and/or generated by the mixer lit? for inclusion in the ICTO 115., For example, the object descriptions 1&2, the mixture metadata 184, the cloaking patterns 107, the ty module 169’, and the intelligence module ill; may all be common participants. Next, at block 204, a dynamic participant controller r") 11% is initialized. In some embodiments, initializing the mixer 11% may include verifying that the mixer 11% is being executed by an expected or otherwise trusted application.

At block 206, the mixer 110 receives one or more pieces of owner data 106 to be protected. As sed above, in some embodiments the owner data 166 may be al, and the access protection features of the ICTO 115 may be used to verify user identities and/or obtain signatures from users.

The method 200 proceeds to block 2038, where the mixer 110 causes a portable dynamic rule set 108 to be executed. At block 210, an intelligence module 111 of the portable dynamic rule set 1&8 determines one or more identity~based cloaking patterns to be used to protect participants 101, and at block 212, the mixer 110 applies the one or more cloaking patterns to the participants 161, creating a set of cloaked participants.

The portable dynamic rule set HE‘S determines a cloaking pattern to be appliedto- each participant léll based on the s of the owner of the data to be protected.

Different ng patterns may be applied to each participant ML r, each participant lfil may be ted using separate cloaking patterns for access by different agents. In other words, a participant 101 such as owner data 106 may be protected by a first cloaking pattern for access by a first agent, and ted by a second cloaking pattern for access by a second agent. The selection of cloaking patterns may be based on an attribute of the participant ltll- to be protected, an attribute of the agent to be given access to the data, a location, an intent, and/or any other suitable piece of information. Selection of a cloaking n may include selecting from a pre— existing cloaking pattern, and/or may include creating a new cloaking n from a combination of protection techniques * supported by the mixer 110. Records of the applied cloaking patterns may be stored in the e metadata 104% Cloaking atterns describe transformations a lied to a articiPant Mil to a P PP P protect the participant 1%}; within the ICTO 115, and ose transformations mav be reversed to access the participant 16L The transformations may include, but are not limited to, data compression, data normalization, and encryption/decryption. A given ng pattern may include one or more of these techniques, or other techniques not listed here. Data compression may reduce the overall size of the ICTO 115, which may in turn improve transport times and dth usage. Data compression may be performed by any suitable lossless compression algorithm including, but not limited to, DEFLATE, LZW, LZR, LZX, JBIG, DjVu, and/or the like. Data normalization is performed by any suitable process that places the data in a form that may efficiently be processed. In some embodiments, the data may be passed through a Base64r ng algorithm to convert the data, whether binary or text format, into a normalized alphanumeric string. This is an example only, and should not be seen as limiting. In other embodiments, other algorithms may be used to normalize the data.

In some embodiments, a cloaking pattern may cause the identity module 109 and the intelligence module 111 to apply separate encryption ques to different components of the participants 101. For example, a first encryption rule, when executed, may identify and encrypt a first portion of the encrypted digital mixture 315 ‘ While leaving a second portion of the encrypted digital mixture 115 unchanged. A second encryption rule, when executed, may then identify and encrypt the second portion of the encrypted digital mixture 115 using a different encryption algorithm, a ent encryption key, and/or the like.

In some embodiments, the' cloaking patterns and/or the portable c rule set 1%?» may establish two or more nested layers of encryption. For example, execution of a first tion rule may encrypt a first portion of the encrypted digital mixture 115. Execution of a second encryption rule may then cause the encrypted first portion of the ted digital mixture 115 to be encrypted again, along with the first encryption rule and a ponding first decryption rule.

Hence, to later access the first portion of the encrypted digital mixture 115, a second decryption rule corresponding to the second tion rule is executed to decrypt the doubly encrypted first portion of the encrypted digital mixture 115 and to obtain the first decryption rulerThe first decryption rule is then eXecuted torridecrypt the first portion of the encrypted digital mixture 115 to generate a plaintext version of the first portion of the digital mixture 115.

Once the cloaking patterns have been applied to the participants 101 to create the set of cloaked participants, the'method 200 proceeds to block 2417 where the mixer 110 creates a l mixture (ICTO) 115 and adds the set of d participants to the digital e 115. In some embodiments, additional protection 115 as a Whole, such as shuffling of the‘data, may be d to the digital mixture 3O additional encryption or digital signatures, and/or the like. The method 200 then proceeds to an end block and terminates.

One of ordinary skill in the art will understand that certain steps have been omitted from for ease of discussion. However, other steps not explicitly illustrated in may also be included in the method ZEN? without ing from the scope of the present disclosure. For e, if any errors are detected while applying the cloaking patterns or executing rules, the method 26% may stop, and may not produce a completed ICTO 115.As another example, in some embodiments, the owner data 196' may include one or more ICTOs as a way of providing nested - protection.- In some embodiments; within-war nested IGTO‘ may be provided with access to participant data ml within the outer ICTO 115. In some embodiments, a rule within a first ICTO may cause a second ICTO to be created, and cause the first ICTO to be added to the second ICTO such that the first ICTO is'nested inside of the second ICTO. Likewise, in some ments, a rule within a first ICTO may cause a second ICTO to be d, and cause the second ICTO to be added to the first ICTO such that the second ICTO is nested inside of the first ICTQ is a process flow that illustrates an alternative ary embodiment of a method 8% of ucting an ICTO 71% according to various aspects of the present invention. The method 860 shown describes the creation of a simple ICTO 716*; however, utilizing similar techniques one may construct a complex ICTO. In some embodiments an ICTO~aware application, device or operating system is configured to initiate and facilitate the method 86%}. The construction and utilization of an ICTO 7%, simple or complex, is not dependent on a specific operating system or device.

From Start 801, the method 8% begins with initialization 8&2 of the Dynamic Participant Controller 702 or mixer. In some embodiments, initialization of the mixer 802 may include validation that the object is an tic ICTO and/or that the request to [0Ln initialize is from an ICTO—aware application, device, operating System or other ICTO— aware process. Proceeding to block 803, a set of digital participants 701 is provided to the mier 702 for inclusion in the ICTO 710. The digital participants 701 may be used in more than one ICTO 710, or may at least have similar or common components in more than one ICTO 716. For example, the outer cloaking patterns 764, the e metadata 705, additional cloaking patterns 7&7, the identity module 768, and the intelligence module 709 may all be ered common digital participants 7&1.

Proceeding to block 804, the mixer 702 utilizing one or more algorithms selects one or more outer cloaking patterns-7044 to be applied to the set of l participants 701 utilizing an interim rule set to create the initial cloaking patterns for the ICTO 710, creating the initial interim cipher object 703. Proceeding to block 805, one or more owner data elements are added to the digital participants set for inclusion in the ICTO 710. In some embodiments, owner data 706 may be al, and the access protection functionality of the ICTO 710 may be utilized to verify legitimate agent midentitiesandforfor legitimate agent-signatures: The method 800 proceeds to block 806, Where the owner’s rules are obtained from the PDRS 711 and utilized by the mixer 702 to replace the interim rule set initially used in the on of the ICTO 710. Proceeding to block 807, utilizing one or more algorithms the mixer 702 selectsone or more inner ng patterns 707 to be applied to some or all of the digital participant set 701, inclusive of the owner data 706. The algorithms utilize time as a unique number and owner rules to further randomize the inner cloaking patterns 707. The algorithms used are added to the identity module 708, managed internally by the PDRS 711 and not shared ally. Finally in block 808 the mixer 702' completes the construction of the lCTO 710 creating a set of cloaked digital participants 720. While similar or common digital participants 701‘ may be utilized as provided in 803, in combination, the method Will create a unique digital mixture 808 for each iCTO 710 constructed.

The mixer 702 using one or more algorithms determines which inner cloaking patterns .5707 also are to be? d toieach 7digital 7071, while randomly , participant applying time as a unique number and other internal factors generated by the intelligence module 709. The algorithms utilized by the mixer 702 to select the inner ng ns 707 are then added to the identity module 708, managed internally and not ‘shared/exchanged/exposed externally of the ICTO 710. Each ipant 701 may be protected utilizing one or more inner cloaking patterns 707 that may be uniquely different from one or more inner cloaking patterns 707 protecting other participants 701 in the digital mixture 710. For example, a participant such as the owner data 706 may be protected with one or more ng patterns and internal rules that are uniquely different than the one or more inner cloaking patterns 707 and internal rules utilized to protect the identity module 708. r, utilization of one or more inner cloaking patterns 707 and the random use of time as a unique number and internal rules in turn s unique cloaking patterns that are added to the identity module 788 for each participant 701. The internal rules ed in the intelligence module 708 may include but are not limited to such things as location, time, authorization requirements, andvthe like.

The inner cloaking patterns 707 describe transformations applied to a participant 7&1 to protect the participant 7621 Within the ICTO 71%, and how some of “ etransforniations may here-versed to access parts or all of the participant 76131. The transformations may include, but are not limited to, data compression, data normalization, and encryption. A given inner cloaking pattern 797 may include one or more of these techniques, and/or other techniques. Data compression may reduce the overall size'of the ICTO 710, which may in turn improve transport times and bandwidth usage. Data compression may be performed by any suitable ss compression algorithm including, but not limited to, DBFLATE, LZW, LZR, LmX, lS IBIS, DjVu, and/or the like. Data normalization is med by any suitable process that places the data in a form that may efficiently be processed. In some embodiments, the data may be passed h a Base64 encoding algorithm to convert the data, Whether binary or text format, into a normalized alphanumeric string. This is an example only, and should not be seen as limiting. In other embodiments, other thms may be used to normalize the data.

Inner cloaking patterns 707 may also include one or more tion techniques.

, . ,. ., * The glaalging, patterns may, Sp§§1f3t,,_111<:t119(i§ 913, gencryption keys, mayrspecifymrzm;_ ular encryption algorithms, such as, but not limited to, NIST or FIPS, other proprietary encryption algorithms, or key lengths, or may specify other configurable options such as time seeds, Xor encoding, or other industry standard encoding and decoding techniques for generating elements of the cloaking scheme, or combinations thereof. In some embodiments, encryption techniques may perform operations or calculations other than encryption, such as deriving a hash value for the referenced content or the like. In some embodiments, the inner cloaking n 707 may store (or may contain rules that require e of) a record of an encryption key or decryption key used, either in the inner cloaking pattern 7()7 itself or elsewhere Within- the ICTO 71%, managed internally and not shared ally: When the inn er cloaking pattern 707 is used to access the protected ation, the cloaking/de—cloaking algorithrn(s) and keys are maintained internally and provided to the dynamic participant controller 702 within the ICTO 710 to provide access to the information, but are not available to the requesting agent or any other agent or application, device, operating system external to the lCTO 710. in other words, the cloaking/de—cloaking algorithms and keys are not stored or exposed outside of the lCTO 710, are not made ble to any agents, and so there is no need for external key management functions, thus no vulnerabilities there from and their secrecy is maintained. in some ments, the rules set forth in the intelligence module 709 may cause the mixer 702 to apply separate inner cloaking ns 7@7 to separate components of the participants 701. For example, a first rule, when executed, may identify and apply a ng pattern to a first portion of the protected digital mixture 71% while leaving a second portion of the protected digital mixture 71%}! unchanged. A second rule, when executed, may then identify and apply a cloaking pattern to the second n of the protected digital mixture 718' using a different cloaking pattern with a different pattern, or the like.

In some embodiments, the intelligence module 709 of the portable dynamic rule set 711 may require two or more nested layers of cloaking of some or all of the participants 7%1. For example, execution of a first rule by the mixer 7632 may cloak a first portion of the protected digital mixture 71%, Execution of a second rule by the y then fltliemgloaked first portion of thewprot‘ected, digital e“ 7 _ 7 , mixer 716‘ to be cloaked again using a different inner cloaking pattern 707, along with the first rule and a corresponding first cloaking rule. Hence, to later access the first portion of the protected digital mixture 716 a second de—oloaking rule ponding to the second rule is executed to de~cloak the nested cloaked first portion of the protected digital mixture 716 and to obtain the first de—cloaking rule. The first de— cloaking rule is then executed to de—cloak the first portion of the protected digital mixture 716} to generate a plaintext version of the first portion of the l mixture 71%.

Once the inner cloaking patterns 787 have been applied to the participants 781 to create the set of cloaked participants 720*, the method 8M} ds to block 8®8, where the mixer 7&2 completes the construction of a digital mixture (i.e., ICTO) 71%. In some embodiments, additional protection may be d to the digital mixture 711%} as a whole, such as shuffling of the data, additional cloaking and/or the like. The method 8% then proceeds to an end block and ates.

Other steps not explicitly rated in may also be included in the method 8%? without departing from the scope of the present disclosure. For example, if any anomalies are detected while applying the cloaking patterns or executing rules, the method 86%} may stop, and may not e a completed ICTO 713% As another example, in some embodiments, the owner data 7&6 may include one or more ICTOS as a way of providing nested protection. In some embodiments, rules within a nested ICTO may be provided with access to participant data 701 within the outer ICTO 7181. In some embodiments, a rule within a first ICTO may cause a second or multiple lCTO(s) to be created, and cause the first ICTO to be added to the second lCTO such that the first lCTO is nested inside of the second ICTO. Likewise, in some embodiments, a rule within a first ICTO may cause a second ICTO to be created, and cause the second ICTO to be added to the first ICTO such that the second ICTO is nested inside of the first ICTC. is a flowchart that illustrates an exemplary embodiment of a method 36%? of accessing data protected by an ICTO 115 ing to various aspects of the present disclosurerréfter the VlCTQHl‘lS, is agriywatedhthe lCIQ, 115 begins verification and validation of its current environment, access attempts, authorized agents, and other ions as specified in the rule set included in the portable dynamic rule set 10% This verification and validation may be performed once upon p, continuously during an active period, periodically during an active , or at any other suitable interval or in response to, any suitable change in state. When rules and agent identity have been positively confirmed, the ICTO 115 s access to authorized portions of itself while maintaining the homogenous essence of the mixture and protection of the rest of the data.

As With the method 280 described above, in some embodiments the mixer 11% is configured to perform the method 30%; In some embodiments, the method 309 is performed by a computing device if one or more processors of the computing device execute computer executable instructions that cause the computing device to do so. As understood by one of ordinary skill in the art, the construction and utilization of the ICTO 115 is neither dependent on the type of said computing devices nor on any operating systems associated with said computing devices. The data protection protocol ismmbeddedfirrthe’data’ set. An activated '*11‘5' can cornmunicatewvith thedata owner (information such as access attempts, alerts to unauthorized locations or unauthorized , notification of self—destruct or self—recreation) over the life of the data. Further, because the rules in the lCTO 115 may update themselves and other portions of the ICTO 115, the TCTO 115 may learn from its environment, and may change its future behavior based on that learning. The protection protocol can be customized and is unique to each owner, data set, and user combination, as specified in cloaking patterns.

From a start block, the method 308! ds to block 389;, where a portable dynamic rule set M8 within a l mixture 11% is activated in response to a t by an agent to access the digital mixture 115 In several embodiments, a super» identity is embedded in the ICTO 115 and includes ia to verify an identity of an agent attempting to access the ICTO 115, dynamic rules to provide an intelligent awareness that validates the agent and determines the data‘s current state, and algorithms for data cloaking as ied in ng patterns. cation criteria such or the like as challenge/response pairs, digital signatures, ric infonnation, and/ of the agent. At block 304, the portable dynamic may be used to verify the identity rule set 1% is executed to verify that the agent is allowed the requested access to the digital mixture 115 in a relevant context. The identity module 109 and the intelligence ‘module 111, when activated, assess the current access attempt by the verified agent and establish a level of trust. In some embodiments, this assessment is of each an ng process, in that there is a continuous verification and validation participant 101: the data owner, the agent (data user) and the data itself. in some embodiments, pre access rules from the le dynamic rule set 108 may be ed by the mixer 11% to decrypt at least some portion of the ICTO 115 for internal use by the mixer 11% without allowing access to the decrypted data to agents other than the mixer 11%. Pre—access rules have access to the participants N1, including the ability to test identity artifacts and evaluate owner and agent data. If the trust level goes down, the proto col sses the participants 1611: in some ments, if the agent attempting to access the ICTO 115 is unable to re establish their legitimacy, defensive or offensive actions may be invoked. If the * a'gentri'srab‘letorsatisfy the new set of challenges, access will be allowed to proceed or In some embodiments, the pre—access rules are merely allowed read access to identity or tication data, but in some embodiments, the pre—access rules may also have write access, which may be used, for example, to record access attempt attributes when opening (or attempting to open) the ICTO 115° The method 3848‘: proceeds to block 3%, where the portable dynamic rule set 1‘38 determines a cloaking pattern used to protect the requested data. The portable dynamic rule set 108 consults the mixture metadata 184 to determine which cloaking the context pattern 107 was applied based on the identity of the agent, the data request, in which the data is being requested, and/or the like. Once the used cloaking pattern 167 is ined, the method 3% proceeds to block 3118, where the ng pattern 187 is used to provide the requested access to the agent. Similar to how the cloaking pattern 1617 indicated a set of ques used to protect the requested data, the cloaking 1%‘7 also indicates a set, of techniques used to reconstruct the requested data pattern from the protected n stored in the ICTO 115. The method 380 then proceeds to an end block and terminates. is a process flow that illustrates an alternative embodiment of a method 900 of accessing data protected by an ICTO 710, After the ICTO 710 is activated, the PDRS 711 begins verification and validation :of the ICTO’S 710 current environment, access attempts, legitimate agents, and other conditions as specified in the PDRS 711.

This verification and validation process is inherently efficient, s the ity of the data and may be performed once upon startup, continuously during an active period, periodically during an active period, or at any other suitable interval or in response to any suitable change instatus or state. When rules and legitimate agent ty have been'positively confirmed, the PDRS 711 permits access to authorized portions of lCTO 710 While ining the homogenous essence of the mixture and protection of the rest of the participants. In some embodiments, an lCTO—aware application, device or operating system is configured to initiate and facilitate the method 9%.

From a, start block 981, the method §€l® proceeds to block $82, Where the ~ dynannc-p‘articipantmoritroil-erw‘filii' within the protected digital mixturepr' IETQ 716‘ is energized by an ICTO—aware application, device, or operating system in se to a request by an agent to access the digital mixture or lCTO 71th In some embodiments, the owner/agent identity and/ or one or more agent identities are included in the identity module 708 embedded in the ICTO 710 and includes ia to verify the identity, authenticity and legitimacy of an agent attempting to access the ICTO 710, dynamic rules to e an intelligent awareness that validates the legitimacy of the agent and determines the data's current state, and algorithms for data cloaking as specified in cloaking patterns. Verification criteria such as challenge/response pairs, external authorizations, biometric information, and/ or the like may be used to authenticate, validate and/or verify the identity of the agent. At block 9813, utilizing the portable dynamic rule set 711, the requesting agents are verified in an efficient, full, complete and relevant context and granted access to the digital mixture 710?.

The method 9384 proceeds to block 93%;, Where the portable dynamic rule set L711 P¥0Yid6§,t11§> dynamic ipautcautmller 7029115 or. more cloaking patterns used to protect the requested data based on the ty of the agent, the data request, the t in which the data is being ted, and the like. Proceeding to block 965, the UPC or mixer 702 on instruction from the portable dynamic rule set 711 de—cloaks Within the ICTO 710 based on the data owner” 3 rules for some or all of the ted data the legitimate agent, the data request, the context in which the data is being requested, and/or the like managed by the portable dynamic rule set 711.

Other steps not'explicitly illustrated in :IG. 9 may also be included in the method 900 Without ing from the scope of the t disclosure. For example, if any anomalies are detected While applying the debloaking patterns or executing rules, the method 9%} may stop, and may not allow access to the protected ICTO 7109 Another example, the method 9%) may determine legitimacy of a requesting agent to ICTO 710 which may cause external authOrizations to be required prior to completion of authorization of the legitimate agent.- onally, alerts may be sent as a result of legitimate and authorized access to the ICTO 71%.

As another example, in some embodiments, the method 9%) may ine that unauthorized access is being attempted which may cause the PDRS 711 within the ICTO 71¢} to send alerts, record accessattempts and/or'the like. In*arro'mermxammermmomF—**A embodiments, the method 996} may determine an unauthorized access attempt is underway, and enable access to false data in the ICTO 71E}, recording activity, sending alerts and/or the like. Alerts e, but are not limited to, failed access attempt, schedule. unrecognized access address (which can include device and location specifics), violations, unauthorized movement of an ICTO, and the like.

Accordingly, the present invention results in an ICTO that is self—contained, self— lling, and self—governing. All access rights, rules of engagement, ance rules, audit requirements, and similar rules and ctions as determined by the data owner are contained in the PDRS, and ed in the ICTO, and thus controlled on behalf of the data owner by the PDRS (whether online or offline, control is ined :i‘om within the ICTO), and executed by the PDRS. The PDRS is the means for self—governance and control upon creation and throughout the life of the ICTO. It travels with the ICTO, complies at all times with the rules established by the data owner, and can be adaptive ”(Leg dynamic),basedon, butnot d to, the environment (such as place, time, and device), so to self manage and make decision based on learned information. The PDRS does not require any outside sources (e.g., 1AM or STEM systems) or specific operating environments to maintain control and governance. The PDRS controls the complete ment of the ICTO from within the ICTO. The PDRS is permanently embedded in the ICTO and travels with the ICTO, thereby creating a ontained, self—controlled, self~governing entity. is a schematic diagram that illustrates an exemplary use case for an 3O embodiment of the present disclosure. One of ordinary skill in the art will recognize that this use case is exemplary only and is described to show certain features of the disclosure, but that this use case does not utilize or describe every feature of the technology disclosed herein. In a first user 418, using a first computing device 416, uses an embodiment of the present disclosure to protect a first piece of data (data one 484) and a second piece of data (data two 406). An ICTO 408 is d that includes a ted version of data one 418 and a protected version of data two 412. In creating the lCTO 488, the first user 418 specifies that a second user 422 may access data one 484, but does not specify that the second user 422 may access datatwo 486.. Hence, the *T€T®"4€l8"includes a rule "irrityportab‘le dynamic rule set 188 that allows user two 4-22, once verified, to access data one 484., The first computing device 416 transmits the ICTC 488 to a second computing device 428 used by the second user 422 via a network, such as a LAN, a Wireless network, the internet, and/or the like. The second user 422 causes the ICTO 408 to be activated, and submits a request 424 to access to data one 404. The lCTCv 488 verifies the identity of the second user 422., which may include processing a nge/ response pair stored in the lCTO 488 and/or ting a trusted service 489‘ (such as a certificate , a RADIUS or other authentication server, and/or the like) to verify that the second user 422 is who he purports to be. Once the identity of the second user 422 is verified, the ICTO 488 consults the cloaking pattern used to create protected data one 418, and uses the cloaking pattern to give the second user 422 access to data one 484 The second user 422 may also submit a request 426 to access data two 486‘ HOWever, because the ICTO 44138 has not been instructed to provide access to data two 44.4fm mdrrserézg, the 1910 448mm ow the second user 422 to access data two 486° In an alternate process flow, a first computing device 416 transmits an ICTO 4-88 to a second computing device 428 used by the second user 422 via a network, such as a LAN, a wireless k, the internet, and/or the like. The second user 422 utilizing an ICTO aware application, device or operating system s the ICTO 408 which receives a request to access protected data one in the ICTO 498. The lCTO 4G8 verifies the identity of the second user 422, which may include processing of multiple pairs of challenge/ response stored in the ICTO 408 and/or external authorization or the like to verify that the second user 422 is valid and authorized.

Additionally a trusted seivice 4%? may be used for further validation of time, physical location and the like based on the rules of access set forth by owner 418. Once the identity of the second user 4-22 is verified (i.e., established as authentic and legitimate), the lCTO 4-08 determines the one or more cloaking patterns used to create protected data one 416*, and ks the protected data one 418 revealing data one 404- to the second user 4322., The second user 4-22 may also request to access protected data two 412. However, because the second user 4322 is not authorized to access ted data two in the ICTO 4&8, ‘ the second user 422,-is not granted access to otecte‘ddata'two—4d2r Though a trusted service 409 that es authentication services is bed, other types of trusted services may be used. For example, if a rule is included the lCTO 4G8 that only allows access during a given time period, a trusted service 409 that provides a trusted date—time value may be used. As another example, a d e 469 may seek input from other users while the ICTO 4&8 is determining whether to grant access to an agent. As illustrated, a trusted e 4&9 may notify the first user 4—18 of the access attempt via email, SMS, or any other suitable technique, and may wait to allow the ted access until a corresponding approval is received from the first user 418., This use case illustrates several advantages of the present disclosure. Once the ICTO 461% is created, protected data one 41%]? and protected data two 412 cannot be accessed without invoking the processing of the lCTO 4368 to request access.

Accordingly, the data is protected when the ICTO 4&8 is stored on the first computing deviceééjé, when the .ICTQ 428% is in transit on thenetwork £92, and whenthe ICTO, 1 4968 is stored on the second computing device 4116. Also, even though the lCTO 408 provides access to the second user 422 to data one 464, data two 4286 is nevertheless protected from access.

While this simple use case illustrates several features of the t disclosure, much more complex use cases are also possible. For example, is a schematic diagram that illustrates aspects of an exemplary workflow for an embodiment of the present disclosure. A first user (“User A”) may have a set of nts (”Documents X, 3O the Y, and Z”) to be approved and signed, maintaining confidentiality throughout transaction, by a second user ("User B"), a third user (”User C“), and a fourth user (”User D”). Document X needs to be signed by User B. Document Y needs to be signed by User B and User C, but only after Document X has been signed, Document Z needs to be signed by User D, but only after Documents X and Y have been . r, Document X and Document Y must be signed during working hours (e.g., between 9 AM and 5 PM) to ensure compliance with local corporate policy,, while Document Z (the working draft of Doc Y) must be signed immediately upon approved ures of Doc X and Y, the audit logged, and then Doc Z destroyed, with the audit also logged. U ' "n v ' ,_ ' __,,,,,___.

Embodiments of the present disclosure will support such a workflow. User A creates an ICTO that includes Documents X, Y, and Z. User A creates an access rule for Document X that allows User B to review and sign Document X. User A creates an access rule for Document Y that allows User B and User C to review and Sign Document ‘Y once the signature on Document X is obtained. User A may create an access rule for nt X that allows User C to review Document X to check for a ure, or the access rule for Document X may detect the signature applied to nt X, and may dynamically update the access rule for Document Y that allows it to be signed once the signature is detected. User A creates an access rule for Document Z that checks for signatures on Documents X and Y, and upon detecting such signatures, User D is allowed to sign Document Z. Each of these rules also es the associated time requirements, and does not allow access if the time requirements are not satisfied. User A may also create a rule that reports any access to any of the nts back to User A, so that US§}‘,A_11135’ monitor the process. ,Each of the rules specify how each user is to be identified, the related privileges, devices from which the users are allowed to access the documents, and locations from which the users are allowed to access the documents.

Once, for example, User B receives the ICTO, User B s an application configured to activate the executable code within the ICTO. The executable code determines the identity of User B, either by consulting a trusted identity service, by checking the response to a challenge included in a rule, or by any other method. Once 3O the identity, time, location, and other requirements are ied, User B is allowed to access Document X, but not any of the other documents. After User B signs Document X, the ICTO is erred to the next user, and enforces the protections on the documents as the ICTO passes through the rest of the workflow.

Alternatively, for example, User B es the ICTO, User B invokes an ICTO aware application, which activates the PDRS within the ICTO. The executable code determines the identity of User B by utilizing the identity credentials stored within the ICTO which ts multiple challenge/response pairs and /or al authorizations codes. Once the identity, time, location, and other requirements are satisfied, “Usertt “ iS’fl'l’l’OWCCl’fi'O' *acce'SS’HBocument X, but not any of-the other documents. After User B signs Document X, the ICTO is transferred to the next user, and enforces the protections on the documents as the ICTO passes through the rest of the ow.

In another exemplary embodiment, protection protocol is instituted in a portable identity appliance (PIA). The PIA defines a portable and discrete l identity using an instinctive and autonomic authentication method. The PIA ultimately implements an orated ICTO protocol, thus becoming an intelligent object itself. In several embodiments, the PIA is an ICTO that does not include owner data (e.g., files, images, and the like). The PIA comprises an ICTO that utilizes the PDRS along with additional publically available information (similar to the information available on a business card or in a public directory) about the owner, but without necessarily containing owner data. the PIA thus is a seif~protecting, self—controlling, self—governing ICTO with the purpose of representing, in‘efutably, the owner identity.

As seen in Pigurersil0~i3j once theprotected FLATS createdgit can combine with data to produce a protected data object, facilitate the transmission of secure message between one or more parties (e.g., validating and ining sender and receiver legitimacy and data integrity), and provide a secure, orthy identity that can be used to assure or guard websites, portals, networks, or other resources.

The PIA thus present numerous ages over existing ure ques.

Existing signature techniques are typically based on certificates that are purchased from a certificate authority. Certificates are presumed trust—worthy based on who holds the cert and who issues the cert. E—iiewever, certificates can he , can be spoofed, and are not based on a uniquely defined identity, ’i‘lrus, a iCTQ may be used for irrefutable verification of identity where a ”signature“ is requiret‘. Signature lCTOs can be utilized as external identity verification in conjunction with an ICTO containing legal nts requiring te verification of identity. The Signature lCTO(s) can become part (embedded) of the “final” legal documents contained within the original ICTG. Further, Signature lCTOs can be included within the lCTO (i.e., nested) as additional protected data elements in addition to the owner nts requiring signature, thus pre—defining and ing pre—verification of the required signerfiraveli-rrgwith’theuecumentsfi—Signatare-IGTOs also can be used as ’ table verification of identity in documents that are not included in an ICTO but rather in "1 an lCTO aware application tor example, they can be used to provide acceptance of Terms and Conditions electronically, or acknowledgement of privacy notices.

Signature ICTOS in the context of document Signing can be thought of as a digital n of the owner that has been “legally verified and notarized,” but also is irrefutable.

Each Signature ICTO, just like an ICTO with owner data, is unique and therefore cannot be “spoofed” by a person or entity trying to pretend to be the actual owner of the Signature lCTO, Additionally, a Signature ICTO does not have to ent a human; it can represent a machine, whereby a digital process flow requires signatures (verifications) along the way in order to confirm the validity of the ization to proceed; and this signature must be documented. Signature lCTGs can be used anywhere a standard digital signature is required today, but are not limited to just how digital signatures are used today. As discussed above, in several embodiments tlier‘errrrnuseberv lCTO—awareness as a pre—requisite for use.

One of ry skill in the art will recognize that the above use cases are exemplary only, and that many other use cases for the subject matter disclosed herein are possible. For e, because the portable dynamic rule sets include executable code, the lCTO may protect executable content that is only executable upon satisfying the security checks of the ICTO. Also, since the ICTO may execute such content in se to the success or failure of any rule, the ICTO may log successful accesses or take action such as alerting a data owner, initiating a self— destruct sequence, or other actions upon detecting an unauthorized access attempt.

Alternatively there are many other use cases for the subject matter sed herein. For example, because an ICTO includes able code for independent self—management, the ICTO may protect content that is only accessible upon satisfying the security checks and rules of access set forth by the data owner contained within the ICTO. Also, the ICTO, in response to the success or failure of any rule, may log such accesses and/or take action such as alerting a data owner, initiating a self—destruct sequence, or other actions upon detecting an unauthorized access —fi'fi‘“‘w2ttt€mpt”‘ ’ ———————#fl " M‘ '''''' is a block diagram that illustrates an exemplary hardware architecture of a computing device 5th le for use with embodiments of the present disclosure.

Those of ordinary skill in the art and others will ize that the computing device 50% may be any one of any number of tly available or yet to be ped devices ing, but not limited to, p computers, server computers, lap top computers, embedced computing devices, application specific integrated circuits (ASICS), smartpl ones, tablet computers, and/or the like. In its most basic configuration, the computng device 538* includes at least one processor 5‘32 and a system memory 5%: connected by a communication bus 506. Depending on the exact configuration and type of device, the system memory 504 may be volatile or nonvolatile memory, such as read only memory (”ROM”), random access memory (”RAM"), EEPROM, flash 2O memory, or similar memory technology. Those of ordinary skill in the art and others Will recognize that system memory 5&4: typically stores data and/or program modules that are immediately accessible to and/or tly being operated on by the processor 5832, In this regard, the processor 592 serves as a computational center of the computing device $00 by sup porting the execution of instructions.

As further illustrated in the computing device 500 may include a network interface 510 comprising one or more ents for communicating with other devices over the network. Embodiments of the present dis closure may access basic services that utilize the network ace 516} to m communications using common net work protocols. In the exemplary embodiment depicted in the computing device 500 also includes a storage medium 508. r, services may be accessed using a computing device that does not include means for persisting data to a local storage medium. Therefore, the storage medium 508 depicted in is represented with a dashed line to indicate that the storage medium SQS is optional. In any event, the storage medium 508 may be volatile or nonvolatile, removable or nonremovable, implemented using any technology capable of storing information such as, but not limited to, a hard drive, solid state drive, CD ROM, DVD, or other disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, and the like.

As used , the term ”computer readable media" includes le and 4- ~ “nonvolatile-andremovableVandrnenremovablevmediaeimplemente‘d in any ' method or" technology capable of storing information, such as computer readable instructions, data structures, program s, or other data. In this regard, the system memory ‘84 and storage medium 5&8 depicted in are merely examples of computer readable media.

Suitable entations of computing devices that include a processor 5&2, system memory 563552, communication bus S®6, e medium 5638, and network interface 51% are known and commercially available. For ease of illustration and because it is not important for an understanding of the claimed subject , does not show some of the typical components of many computing devices. In this regard, the computing device Silt]! may include input devices, such as a keyboard, mouse, microphone, touch input device, and/or the like. Similarly, the ing device 5636-! may also include output devices such as a display, speakers, printer, and/or the like. Since all these devices are well known in the art, they are not ,édescribedrfurther herein.

Thus, it should be understood that the embodiments and examples described herein have been chosen and described in order to best illustrate the ples of the [\J U! invention and its practical applications to y enable one of ordinary skill in the art to best utilize the invention in various embodiments and with various modifications as are suited for particular uses contemplated. Even though specific embodiments of this ion have been described, they are not to be taken as exhaustive. There are several variations that will be apparent to those skilled in the art.

Claims (20)

1. l. A computer—system having ed security of data, the system comprising: a network interface configured to communicate with at least one other er system over a ing network and configured to receive a computer—based igent cipher transfer object comprising: owner data secured by one or more inner cloaking patterns, and a le dynamic rule set, said portable dynamic rule set comprising a machine-executable code secured by one or more outer cloaking ns, an application interface configured to receive, from an external agent, a t to access some or all of the owner data; and at least one processor coupled to the network interface and the application interface and configured to: reverse the outer cloaking patterns to retrieve the machine—executable code; activate the portable dynamic rule set by executing the machine—executable code, thereby causing the at least one processor to: verify, using portable dynamic rule set, that the external agent is authorized to access some or all of the owner data as requested, and upon verifying that the external agent is authorized, provide access some or all of the owner data for which the external agent has been verified for access by reversing at least a n of the one or more inner cloaking patterns.
2. 2. The system of claim 1, wherein the le dynamic rule set is located at variable locations within the intelligent cipher transfer object.
3. 3. The system of claim 1, wherein the machine-executable code is located at variable locations within the intelligent cipher transfer object.
4. 4. The system of claim 1, wherein the portable dynamic rule set includes at least one rule that identifies which external agents may access some or all of the owner data, and a context in which a particular external agent may access some or all of the owner data.
5. 5. The system of claim 1, wherein a context in which a particular external agent may access some or all of the owner data comprises one or more of the ing: a time period, location, or an identity of a computing device.
6. 6. The system of claim 1, wherein the computer-based intelligent cipher transfer object further comprises mixture metadata.
7. 7. The system of claim 6, wherein the mixture metadata includes information identifying the one or more inner or outer cloaking patterns securing the owner data and the portable dynamic rule set.
8. 8. The system of claim 1, wherein the one or more inner cloaking patterns are used to secure at least a portion of the portable c rule set.
9. 9. The system of claim 1, wherein the executing the machine-executable code further causes the at least one processor to: rule in upon failing to verify that the external agent is authorized, e at least one the le dynamic rule set, thereby causing at least one of the following events to occur: the intelligent cipher transfer object estructs, the intelligent cipher er object denies access to at least a portion of the owner data, a message or alert is sent to an owner associated with the owner data, and a record of the request is stored in the intelligent cipher transfer object.
10. 10. The system of claim 1, wherein the executing the machine—executable code further causes the at least one processor to: external agent upon providing access to some or all of the owner data for which the has been verified for access, execute at least one rule in the portable dynamic rule set, y causing at least one of the following events to occur: a message or alert is sent to an owner associated with the owner data, a record of the request is stored in the igent cipher transfer objects, the intelligent cipher transfer object provides limited access to at least a portion of the owner data, the limited access comprising at least one of read privileges and write privileges; a signature of the external agent is associated with the owner data, and at least one rule in the portable dynamic rule set is added, modified, or deleted.
11. 11. The system of claim 1, n the intelligent cipher transfer object is nested within a second intelligent cipher transfer object.
12. 12. The system of claim 11, wherein the second intelligent cipher transfer object is nested within one or more additional intelligent cipher transfer objects.
13. 13. A computer system having improved security using digital signatures or verifications, the system comprising: a network interface configured to communicate with at least one other computer system over a computing network and configured to receive a computer—based intelligent cipher transfer object comprising a portable dynamic rule set, said portable dynamic rule set comprising machine-executable code secured by one or more outer ng ns, at least one processor coupled to the network interface and configured to: e the outer cloaking patterns to retrieve the machine—executable code, activate the portable c rule set by executing the machine—executable code, thereby causing the at least one sor to: verify, using portable dynamic rule set, an identity of an external agent, upon ing the identity of the external agent, storing data indicative of the identity of the external agent in the computer-based intelligent cipher transfer object, securing the data indicative of the identity of the external agent using one or more inner cloaking patterns.
14. 14. The system of claim 13, wherein the portable dynamic rule set is located at variable locations within the igent cipher transfer object.
15. 15. The system of claim 13, wherein the data indicative of the identity of the external agent is located at variable locations within the igent cipher transfer object.
16. 16. The system of claim 13, n the inner cloaking patterns are used to cloak at least a portion of the portable dynamic rule set.
17. 17. The system of claim 13, wherein the at least one sor ses a local the portable processor, wherein activating the portable dynamic rule set comprises activating c rule set on the local processor.
18. 18. The system of claim 1, wherein the computer—based intelligent cipher transfer object further comprises a first set of identifying information for one or more authorized , and the executing the machine-executable code causes the at least one processor to verify that the external agent is authorized by: prompting the external agent to provide a second set of identifying information; receiving the second set of identifying information; and verifying the external agent is authorized by comparing the first set of identifying information and the second set of identifying information.
19. 19. The system of claim 1, wherein the computer-based intelligent cipher transfer object further comprises one or more decryption keys, and the executing the machine—executable code causes the at least one processor to e the at least the n of the one or more inner cloaking patterns by using the one or more decryption keys.
20. 20. The system of claim 1, wherein the at least one processor comprises a local processor, wherein activating the portable dynamic rule set comprises ting the portable dynamic rule set on the local processor.