NZ726067B2 - 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. he 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.

FEEL?!) GTE EGN This inVention relates to a system and related s for protecting and lling 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 drawbacks When information is outside 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 t techniques, encryption keys must be present within an applicatior, or revealed or traded by users or via an application, for encrypted data to be , 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. r, once an encryption key (or password) is shared and 'he data unlocked, control of the data is lost. Even when data is within a trusted environment, such as behind a firewall or the like, it is able to attack or misuse, as fi es are available to anyone with access to their storage location. Protecting information traditionally requires teams of people with expertise in networks, BYOD, telecommunication, servers 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 nt in complex integrations.

Typical data encryption relies on algorithms that run in a predetermined sequence to encrypt and then run in the reverse sequence 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 tion thm 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 between parties an irrelevant factor. For example, one party can send their data to an outsourcer for storage or processing t ng 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 require decryption. However, fully homomorphic encryption is too curnbersome to be practical.

Another traditional technique for ting data is the use of dynamic controls. Dynamic ls are application dependent, such as rd protected PDF files generated and used by document viewing and editing software produced by Adobe®, or the like. Traditional dynamic ls 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 protected PDF opened with Adobe® Acrobat®) 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 ent on keys and passwords for authentication, on predictable reversible tion sequences for protection, and on external applications for execution while remaining functional and efficient both within and outside 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 y is not intended to identify key es of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

In several exemplary embodiments, the t invention comprises a self— protecting, self—controlling intelligent cipher transfer object (ICTO), which may be stored a set of participants ing a on a cornputer~readab1e . The lCTO comprises portable dynamic rule set (PDRS). The PDRS, in response to ion 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 n 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 ns 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 ns of such an lCTO are also ed.

In one exemplary embodiment, the present ion comprises an ICTO~ limited aware application, operating system, or device, ing, but not to, computer chips, switches, controls panels, FGPAS, and the like, that activates the ICTO in response to a request for access. The ICTO comprises a set of ipants including but not limited to owner data, and a PDRS. Upon activation of the dynamic participant controller (DPC) Within the ICTO, remotely or locally, the PDRS within the ICTO takes and maintains l 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 inaccessible to the agent. A computer—implemented method of creating such an ICTO utilizing the an lCTO—aware application, operating 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 obtained by a computing device. One or more cloaking patterns for protecting the set of participants a first are determined. A first cloaking pattern is used to protect or mix subset of the set of ipants, and a second cloaking pattern different from the first cloaking pattern is used to protect or mix a second subset of the set of ipants. The determined ng patterns are d by the ing device to the set of participants to create a set of cloaked or mixed participants. The set of d 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 perform such a method are also provided.

In yet r embodiment, the present invention comprises an iCTO-aware application. eperating , 01 {ievi ethat .amntates this method for protecting a set of participants. A set of participants is gathered through an are application. cperatmg svstem or device to create an interim iatte.111 TCTO, which inciteices a set of v J participants and H starter ‘1 a temporary or rule set 111cvided by the cipher engine or d.vnamia1artii1a111t c ntr‘oll1.1 until thelCTO 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 dynamic 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 ed. An access request from an agent to access a 01' governed 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 ing 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 provided t providing access to other participant portions.

In yet r embodiment, the present invention comprises an IiCrlU—avy'are appiication, or;crating system or device that activates the lCTO upon receiving an access A use. ,v-v .VU request from an agent. The c 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 authorization 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 e. 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 foregoing ' s and many of the attendant advantages of embodiments of the present disclosure will become more readily appreciated as the same become better understood by reference 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 various aspects 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 ment 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 ary workflow for an embodiment of the present invention.

Figure 6 shows a block diagram that illustrates an ary 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 t invention.

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

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

Figure 10 shows a View of a portable identity nce system in accordance with r ary embodiment of the present invention.

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

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

Figure 13 shows a diagram of a le 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 comprises a set of participants including a le dynamic rule set . Computer-implemented methods of creating, accessing, and using such an lCTO, and a computing device configured to execute the executable portions of such an lCTO, also are provided.

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 detection, but are not ed to the data . If prior—art encryption is utilized, the burden of key code management may reduce productivity or flaws may create yet other abilities by exposing keys that likewise need to be protected.

Embodiments of the present disclosure provide a self—contained, self—protecting, self—governing, data~centric solution, meaning that the controls for data management, protection, and administration are grafted into, and become part of, each data set and directly oversee 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 ion comprises an ictable 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 transit, and in the hands of trusted data users or untrusted data users.

In some embodiments of the present disclosure, the data protection scheme is embedded within, grafted 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 authorized users of the data are noted in an embedded log, while n 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 intrusion, alert the data owner to the orized attempt, and/or take any other appropriate action.

The data owrier utilizes the protection 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 nibinaticn cfcrvner, usernr . r, and dataset; this means that the method by which data is ed to Authorized Party A would not be the way data is revealed to Authorized 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 ation, the ICTO will be a ly protected TCTO.

In some embodiments, different techniques may be. used to protect the data and to access the ted data. For e, an irreversible protection scheme may be used to combine multiple pieces of data into a single l e, such that a selective retrieval scheme may be used to selectively retrieve pieces of data from the single digital mixture without obtaining access to other protected data in the digital 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 on of retracing the original steps, and the original protection scheme used to combine the multiple 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 ty of the original 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. Unauthorized 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 ering the protection scheme cannot yield the original s.

In several ments of the present invention, rules are executed by an executable. n 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 operating 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 ontrolling The protection scheme is independent of operating system, environment, and application (i.e., external or lized or server key management, password management and identity ment applications).

Methods in the protocol are implemented in executable code stored in the data mixture, and are executed in response to detecting a request by the user to access the data through a structured 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 h the API or other means bed 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. uently, the outer cloaking technology locates the able code, cipher engine, or mixer stored in the digital mixture. 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 c rule set takes and maintains control until the self~governed data object is closed or becomes inactive. Any attempt to access the self—protecting, self— control ing digital mixture without zing the executable code will be unsuccessful. 1316. l is a tic diagram that rates an exemplary embodiment of self governing data according to various aspects of the present invention. A dynamic participant controller £16, or ”mixer,” identifies a set of digital ingredients ("participants") 1&1, including descriptions of ized agents, device locations, rules for using the data, and/or other ients as discussed further below. By mixing these ingredients, the mixer 11% forms a cloaked entity, the intelligent cipher transfer object, or ICTO 115. The ICTO 115 may also be called a "digital 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 interchangeably. To an unauthorized entity or third party viewing 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 ng the original ingredients. However, when ed via an ation 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 provide 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 ns 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 ation l0 implementing the API for accessing the ICTO 115 may be able to compute the variable ons for a given ICTO 115 based on a feature of the ICTO 115. For example, the secure ation 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 attribute 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 identity module 109, and an intelligence 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 eannai‘ks, ,data identifiers,and/or pmperties. Owner data 106 may e1data that is to be protected within the ICTO 115, such as a document, a file, a , a directory, a pointer to remotely stored data, se, and/or the like. In some embodiments, owner data 106 may be optional, if the ICTO 115 is merely used, for e, 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 included within a single ICTO 115‘ 3O The ng patterns 107 specify various combinations of data protection and access techniques 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 standard verified tion, compression, randomization, normalization, and/or other techniques. Techniques suitable for use as cloaking patterns 107 are not limited to currently known ques, but could include any privately or publicly available encoding and/or ng technique, known now or developed in the . Use of a ng pattern 107 to protect and/or access data may involve applying the combination of data tion and/or access techniques specified in the cloaking pattern 167 to the data.

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

The identity module 109 may include dynamic identity attributes 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 object. The identity module 189 may contain specific information about hardware or re configurations installed on the computing device usable to identify the ing device. The ty module 109 may contain data including, but not limited to, CPU ation ing 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 storage device serial numbers and/or model numbers; installed software titles and/or version numbers, and/or the like. , In some embodiments, a transaction is an atomic action using the lCTO 115 in which one or more agents securely 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 electronic object, a unique software or m object, and/or the like. Dynamic identity attributes contained in the TCTO 115 may be modified 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 tamp and/or the like, which may allow rules or other intelligent code to enforce timers, expirations, dynamic keys, and/or the like. The temporal 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 digital signature key. The l signature key may be validated using an external digital 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 tly accessing the ICTO 115. In some embodiments, multiple agents may sign off on the ICTO 115, In such an embodiment, the ICTO MS may include a chain of signature keys, wherein each signature key may be associated with a separate al digital certificate for tion. 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 setscapable of recording and icating access data and other relevant y; along with intelligent code that provides configurable functionality for performing actions to t 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 e, 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 able 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 ements of the identity module 109, the intelligence module 111 acts on its rules and ements.

Application—specified identifiers may vary from access to access, and may vary depending on a type of agent. For example, for a human user, application-specified identifiers may e account keys, transaction information, context keys, associated intents, and/or the like. For an electronic object, a digital asset, or any other potential agent, ation—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 embedded 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 information such as date, time, place, and the like, and/or to destroy the data if an attack is ed. Some examples of decisions made or actions taken by intelligent code within rules may e, but are not d to: evaluating object content and context for validity; nging 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, dataiavndmr the like.

The use of portable dynamic rules may have various ts. 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 thm specified in a pre—encryption rule. As another example, 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 another example, because the rules are portable 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 orized access even when off—line or out~of~network As a further example, 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 le dynamic rule set 108 to form a mixture of the object descriptions 102, the e metadata 104:, the owner data 106, the cloaking patterns 107, the identity module 1&9, and the intelligence module ill that comprises a self—protecting, self—governing ICTO ”£15, In some embodiments, s 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 ted based on the contents of the checksurn target. In some embodiments, the algorithm used to te the checksum is sensitive enough to reliably detect a change of a single bit value of even a large data-set. Some suitable algorithms e MDS and SHA, though any other suitable thm may be used. Each checksum may be appended, prepended, or otherwise combined with the um target for storage, or may be stored in a separate location.

FIG. '7 is a schematic diagram that illustrates another exemplary embodiment of self—contained, self~controlling, self—governing data protection according to additional embodiments of the present invention. An API or other lCTO-aware application, , 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 limited to, authorized , devices,,, , , ,, ons, 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., digital mixture, or ICTO) 710. The dynamic participant controller 702, when energized, s an interim cipher object 703 utilizing a temporary or ”starter“ rule set While said object is being ucted. 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, additional 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 offsets is made available to the DPC 74112 to locate the portable dynamic rule set 711 within the ICTO 710* which takes and maintains control while the ICTO 71% is active.

The set of digital ipants 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 ty 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 ments, 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 embodiments, multiple pieces of owner data may be mixed into a single ICTO 71%. In other embodiments, 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 portable dynamic rule set 711 and supported by the dynamic participant 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 industry standard encryption, etary encryption, compression, randomization, normalization, and the like. Techniques le for use as inner ng patterns 707 are not limited to currently known ques, but could e 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 techniques 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 thms calculated, used, or created by the dynamic participant controller 792 ing 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 standard verified tion, compression, randomization, normalization, and the like. Techniques suitable for use as outer ng patterns 7% 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 . Use of an outer cloaking pattern 704 to protect and/or access data may involve applying the combination of data protection calculated by the dynamic participant ller 7&2 and ied by the interim rule set. The mixture metadata 705 es 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 identity attributes that ly identify legitimate 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 behavior. Learned ation is collected and can be utilized in a future access request session, thereby adding additional intelligence and decision points. Additionally, dynamic identity, attributes, can also be volatile (ii: unpredictable) details. They may be ted during the authentication s, alone or in conjunction with personal identity attributes, in the determination of legitimate identification of an agent requesting access to an ICTO.

In some embodiments, the identity module 708 may include data that ents a configuration of a computing device that may be given certain rights with respect to a protected object. The identity module 708 may n specific information about hardware or software configurations installed on the computing device usable to identify the computing device. The identity module 708 may contain data including, but not limited to, CPU ation 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 embodiments, a transaction is an atomic action using the ICTO 71th in which one or more legitimate and authorized agents securely exchange data or information within a given context and with a specified intent.

Legitimate, ized agents may e human and non—human entities, such as a *humanuser,a"tmiqueemechanical objectfa’ unique electronic object, a unique software or program object, or the like. Dynamic 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 include, but are not limited to, application— specified identifiers, t 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 logy, such as GPS, GSM network 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 location data such as street, city, state, country, postal code, and the like may also be t. In some embodiments, the temporal data may e a timestamp or similar information, which may allow rules or other igent code to enforce timers, expirations, dynamic keys, and the like. The temporal data may e a simple date/time value, or may e a x schedule Compl’iSingtilllaatalniz lfllgfisélld/QLQQEI ling guidelinesi WAVAA, min.“ , , ._ W, , ,7, In some embodiments, each ICTO 716} may include one or more digital ure 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 enforce a chain of digital signature requirements, wherein each digital signature may be associated with a separate legitimate agent. For e, an ICTO 718 may be used by an owner to create a self— governing file for approvals, signature and transfer to le legitimate agents wherein each legitimate agent may access different sections of the file but not the entire file, either simultaneously or sequentially. Both the owner and the legitimate agents may have to provide valid digital signatures to allow the transaction to proceed.

The igence module 709 may include dynamic rule sets e of recording and communicating access data and other relevant events; along with intelligent code that es urable 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 ements. 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 specified identifiers may include account keys, transaction information, context keys, associated intents, and the like. For an electronic object, a digital asset, or any other potential agent, portable dynamic rules set 7111 identifiers may also e an I]? address, a URL, a file ication, and the like.

In, $0.1m eiandinientsrmleshave. read/write access mine d1 anal participants. 7613, even while the digital participants 7%: are protected 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 y the data if an attack is detected. Some examples of decisions made or actions taken by the intelligence module 709 may e, 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 verification of trust; g 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 on—line and/or off~line object ; creating new rules based on c server updates; cloaking 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, ally managed, unique keys based on owner—specified criteria. Said unique keys may be based on temporal data, nment data, or any other algorithm specified by an owner’srule set. As another example, said rules may access protected identity artifacts within the ICTO 07% in order to authenticate and validate the agent without exposing the ted 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 orized access even when off line.

As a further example, rules may add nested protection: if the lCTO 710 protects one or more lCTOs 710 within the t 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-. r example, the rules self—contained within the PDRS 7111 of an ICTO 710 are self~goveming If the lCTO 710 protects a document that is meant to be aCCSSSleJY a single legitimate agent uone 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 participant controller 702, or mixer, utilizing a portable dynamic rule set 711’creates a mixture of the outer cloaking patterns 704, mixture metadata 705, the owner data 706, the inner cloaking patterns 707, the identity module 708 and the intelligence module 709 that makes up the lCTO 710. In some embodiments, various ents of the ICTO 710 may be combined for encoded checksums 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 checksum 712 targets. ~ In some ments, the algorithm used to generate the checksum is sensitive enough to ly detect a change of a single bit value of even a large document. Some suitable algorithms include MDS and SHA, though any other suitable algorithm may be used. Each checksum 712 may be appended, prepended, or otherwise combined with the checksum target for storage, or may be stored in a separate location.

F1652 is a flowchart that illustrates an exemplary embodiment of a method % of constructing an ICTO 115 ing to s s of the present invention.

While the illustrated method 281} describes on 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 computing device, as bed below, that is configured to provide 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 r 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 obtained. 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 reciiiedm and/or ted 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 identity module 169’, and the igence module ill; may all be common participants. Next, at block 204, a dynamic participant controller (”mixer") 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 discussed above, in some embodiments the owner data 166 may be optional, and the access protection features of the ICTO 115 may be used to verify user ties 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 desires of the owner of the data to be protected.

Different cloaking patterns may be d to each participant ML Further, each participant lfil may be protected 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 le piece of information. ion of a cloaking pattern may include selecting from a pre— existing cloaking pattern, and/or may e creating a new cloaking pattern from a ation of protection techniques * supported by the mixer 110. s of the d cloaking patterns may be stored in the mixture 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 lipwthose 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 cloaking pattern may e 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 ization is performed by any suitable s that places the data in a form that may efficiently be processed. In some embodiments, the data may be passed through a r 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 algorithms may be used to normalize the data.

In some embodiments, a cloaking pattern may cause the ty module 109 and the igence module 111 to apply separate encryption techniques to different components of the participants 101. For example, a first encryption rule, when executed, may identify and encrypt a first n of the ted 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 different encryption key, and/or the like.

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

Hence, to later access the first portion of the encrypted l e 115, a second decryption rule ponding to the second encryption 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 ext 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 ipants, the'method 200 proceeds to block 2417 where the mixer 110 creates a digital mixture (ICTO) 115 and adds the set of cloaked participants to the digital mixture 115. In some embodiments, additional protection 115 as a Whole, such as shuffling of the‘data, may be applied 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 n 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 departing from the scope of the t sure. For example, 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; rules-within-war nested IGTO‘ may be provided with access to participant data ml within the outer ICTO 115. In some ments, 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 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 ICTQ is a process flow that illustrates an alternative exemplary ment of a method 8% of constructing 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 te 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 c 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, , 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 mixture metadata 705, additional cloaking patterns 7&7, the identity module 768, and the intelligence module 709 may all be considered common digital participants 7&1.

Proceeding to block 804, the mixer 702 utilizing one or more algorithms selects one or more outer ng patterns-7044 to be applied to the set of digital 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 optional, 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 m rule set initially used in the creation of the ICTO 710. Proceeding to block 807, utilizing one or more algorithms the mixer 702 selectsone or more inner cloaking 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 ize the inner cloaking patterns 707. The thms used are added to the identity module 708, managed internally by the PDRS 711 and not shared externally. y in block 808 the mixer 702' completes the construction of the lCTO 710 creating a set of cloaked digital ipants 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 ns .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 cloaking patterns 707 are then added to the identity module 708, managed internally and not ‘shared/exchanged/exposed externally of the ICTO 710. Each participant 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 ipant 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 ng patterns 707 and internal rules utilized to protect the identity module 708. Further, utilization of one or more inner cloaking patterns 707 and the random use of time as a unique number and internal rules in turn creates unique cloaking patterns that are added to the identity module 788 for each ipant 701. The internal rules embedded in the intelligence module 708 may include but are not limited to such things as location, time, ization 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 “ '*thosetransforniations may here-versed to access parts or all of the participant 76131. The transformations may e, but are not limited to, data compression, data normalization, and tion. A given inner cloaking pattern 797 may include one or more of these techniques, and/or other techniques. Data ssion 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 lossless 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 through 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 algorithms may be used to normalize the data.

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

, . ,. ., * The glaalging, patterns may, Sp§§1f3t,,_111<:t119(i§ 913, derbingencryption keys, mayrspecifymrzm;_ particular encryption algorithms, such as, but not limited to, NIST or FIPS, other proprietary encryption algorithms, or key s, or may specify other configurable options such as time seeds, Xor ng, 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 ations other than encryption, such as deriving a hash value for the nced content or the like. In some embodiments, the inner cloaking pattern 707 may store (or may contain rules that require storage 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 externally: When the inn er cloaking pattern 707 is used to access the protected ation, the ng/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 available to any agents, and so there is no need for al key management ons, thus no vulnerabilities there from and their secrecy is maintained. in some embodiments, the rules set forth in the intelligence module 709 may cause the mixer 702 to apply separate inner cloaking patterns 7@7 to te components of the participants 701. For e, a first rule, when executed, may identify and apply a cloaking 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 portion of the protected digital mixture 718' using a ent cloaking pattern with a different pattern, or the like.

In some embodiments, the intelligence module 709 of the le 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 ted l mixture 71%, Execution of a second rule by the 7®2nray then fltliemgloaked first portion of thewprot‘ected, digital mixture“ 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 corresponding 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 l mixture 716} to generate a plaintext version of the first portion of the digital mixture 71%.

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

Other steps not explicitly illustrated in may also be ed 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 ing rules, the method 86%} may stop, and may not produce 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 ing 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 ary embodiment of a method 36%? of accessing data protected by an ICTO 115 according to various s 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 staitup, continuously during an active period, periodically during an active period, 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 permits access to ized 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 e 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 agents, notification of self—destruct or self—recreation) over the life of the data. Further, e 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 tion protocol can be customized and is unique to each owner, data set, and user combination, as specified in cloaking ns.

From a start block, the method 308! proceeds to block 389;, where a portable c rule set M8 within a digital mixture 11% is activated in se 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 criteria 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 thms for data cloaking as specified in cloaking patterns. Verification criteria such or the like as challenge/response pairs, digital signatures, biometric infonnation, and/ of the agent. At block 304, the portable dynamic may be used to verify the identity rule set 1% is ed 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 cation and validation participant 101: the data owner, the agent (data user) and the data itself. in some embodiments, pre access rules from the portable dynamic rule set 108 may be executed by the mixer 11% to decrypt at least some portion of the ICTO 115 for al use by the mixer 11% without allowing access to the decrypted data to agents other than the mixer 11%. cess rules have access to the participants N1, including the ability to test ty artifacts and evaluate owner and agent data. If the trust level goes down, the proto col reassesses the participants 1611: in some embodiments, 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 continue.

In some embodiments, the pre—access rules are merely allowed read access to identity or authentication 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 g (or attempting to open) the ICTO 115° The method 3848‘: proceeds to block 3%, where the portable dynamic rule set 1‘38 determines a ng 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 d 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 determined, the method 3% proceeds to block 3118, where the cloaking pattern 187 is used to provide the requested access to the agent. Similar to how the cloaking pattern 1617 indicated a set of techniques 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 version stored in the ICTO 115. The method 380 then ds 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 nment, access ts, mate agents, and other conditions as specified in the PDRS 711.

This verification and tion process is inherently efficient, ensures the integrity 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 se to any suitable change instatus or state. When rules and legitimate agent identity have been'positively confirmed, the PDRS 711 s access to authorized portions of lCTO 710 While maintaining the homogenous essence of the mixture and protection of the rest of the participants. In some ments, an lCTO—aware application, device or operating system is configured to initiate and tate 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 response 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 criteria to verify the ty, authenticity and legitimacy of an agent ting to access the ICTO 710, dynamic rules to provide 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 ns. 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 ds to block 93%;, Where the portable dynamic rule set L711 P¥0Yid6§,t11§> c participautcautmller 7029115 or. more cloaking patterns used to protect the requested data based on the identity of the agent, the data request, the context in which the data is being requested, 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 protected data the legitimate agent, the data t, the context in which the data is being requested, and/or the like managed by the portable c rule set 711.

Other steps not'explicitly illustrated in :IG. 9 may also be included in the method 900 Without departing from the scope of the present disclosure. For example, if any anomalies are detected While applying the king 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 ine 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.- Additionally, alerts may be sent as a result of legitimate and authorized access to the ICTO 71%.

As r example, in some embodiments, the method 9%) may determine 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 t is underway, and enable access to false data in the ICTO 71E}, ing activity, sending alerts and/or the like. Alerts include, but are not limited to, failed access attempt, schedule. unrecognized access address (which can include device and location specifics), violations, unauthorized nt of an ICTO, and the like.

Accordingly, the present invention results in an ICTO that is self—contained, self— controlling, and self—governing. All access rights, rules of engagement, compliance rules, audit ements, and similar rules and restrictions as determined by the data owner are contained in the PDRS, and embedded in the ICTO, and thus lled on behalf of the data owner by the PDRS (whether online or offline, control is maintained :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 e any outside sources (e.g., 1AM or STEM systems) or specific ing environments to maintain control and governance. The PDRS controls the complete management of the ICTO from within the ICTO. The PDRS is permanently embedded in the ICTO and travels with the ICTO, thereby creating a self—contained, 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 created that es a protected 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 c 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 challenge/ response pair stored in the lCTO 488 and/or consulting a trusted service 489‘ (such as a certificate server, 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 t 426 to access data two 486‘ HOWever, because the ICTO 44138 has not been instructed to provide access to data two 44.4fm thesecmdrrserézg, the 1910 448mm notallow the second user 422 to access data two 486° In an ate s flow, a first computing device 416 its 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 network, the internet, and/or the like. The second user 422 utilizing an ICTO aware application, device or operating system awakens the ICTO 408 which receives a t 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 le 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 mate), the lCTO 4-08 determines the one or more cloaking patterns used to create protected data one 416*, and decloaks 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. r, because the second user 4322 is not authorized to access protected data two in the ICTO 4&8, ‘ the second user 422,-is not granted access to the‘protecte‘ddata'two—4d2r Though a trusted service 409 that provides authentication services is described, 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 trusted service 469 may seek input from other users while the ICTO 4&8 is determining whether to grant access to an agent. As rated, a trusted service 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 attempted access until a corresponding approval is received from the first user 418., This use case rates several ages 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 work £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 l features of the present disclosure, much more complex use cases are also possible. For e, 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 documents (”Documents X, 3O the Y, and Z”) to be approved and , 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 nt X has been signed, Document Z needs to be signed by User D, but only after Documents X and Y have been signed.

Further, 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 ed signatures of Doc X and Y, the audit logged, and then Doc Z destroyed, with the audit also logged. U ' "n v ' ,_ ' __,,,,,___. ments 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 nt X is obtained. User A may create an access rule for Document X that allows User C to review Document X to check for a signature, or the access rule for nt X may detect the ure applied to Document 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 nt 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 documents back to User A, so that 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 invokes an application configured to activate the executable code within the ICTO. The executable code determines the identity of User B, either by consulting a d 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 satisfied, 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 receives 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 presents multiple challenge/response pairs and /or external authorizations codes. Once the identity, time, on, 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 workfiow.

In another exemplary embodiment, protection protocol is instituted in a portable ty nce (PIA). The PIA defines a portable and discrete digital identity using an instinctive and autonomic authentication method. The PIA ultimately implements an orated ICTO protocol, thus becoming an intelligent object . 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 ble 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 rotecting, 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 e a protected data object, facilitate the transmission of secure message between one or more parties (e.g., validating and maintaining sender and receiver legitimacy and data integrity), and e a secure, trustworthy identity that can be used to assure or guard websites, portals, networks, or other resources.

The PIA thus present numerous advantages over existing ure techniques. ng signature techniques are typically based on certificates that are purchased from a certificate ity. Certificates are presumed trust—worthy based on who holds the cert and who issues the cert. E—iiewever, certificates can he stoien, 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 et‘. Signature lCTOs can be ed as external ty verification in conjunction with an ICTO containing legal documents requiring absolute verification of identity. The Signature lCTO(s) can become part (embedded) of the “final” legal documents contained within the al ICTG. Further, Signature lCTOs can be included within the lCTO (i.e., nested) as additional protected data elements in addition to the owner documents requiring signature, thus pre—defining and providing rification of the required signerfiraveli-rrgwith’theuecumentsfi—Signatare-IGTOs also can be used as ’ irrefutable cation 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 version of the owner that has been ly verified and notarized,” but also is irrefutable.

Each ure 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 represent 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 authorization to proceed; and this signature must be documented. Signature lCTGs can be used anywhere a standard l signature is required today, but are not limited to just how digital signatures are used today. As discussed above, in l embodiments tlier‘errrrnuseberv lCTO—awareness as a pre—requisite for use.

One of ordinary 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 example, because the le dynamic rule sets e 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 response to the success or failure of any rule, the ICTO may log successful accesses or take action such as ng 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 disclosed herein. For example, because an ICTO includes executable 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 ned 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 s 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 suitable for use with ments of the present disclosure.

Those of ordinary skill in the art and others will recognize that the ing device 50% may be any one of any number of currently available or yet to be ped devices including, but not limited to, desktop computers, server computers, lap top ers, ed 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 currently being operated on by the processor 5832, In this regard, the processor 592 serves as a ational center of the computing device $00 by sup porting the execution of instructions.

As further illustrated in the computing device 500 may e a network interface 510 comprising one or more components for communicating with other devices over the network. Embodiments of the present dis e may access basic services that utilize the network interface 516} to perform communications using common net work protocols. In the ary embodiment ed in the computing device 500 also includes a storage medium 508. However, 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 te that the e medium SQS is optional. In any event, the storage medium 508 may be volatile or nonvolatile, removable or ovable, implemented using any technology e of storing information such as, but not limited to, a hard drive, solid state drive, CD ROM, DVD, or other disk e, magnetic cassettes, magnetic tape, magnetic disk storage, and the like.

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

Suitable implementations of computing devices that include a processor 5&2, system memory 563552, communication bus S®6, storage 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 matter, 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 computing device 5636-! may also include output devices such as a display, speakers, r, 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 principles of the [\J U! invention and its practical applications to thereby enable one of ordinary skill in the art to best utilize the ion in s embodiments and with s modifications as are suited for particular uses plated. Even though specific embodiments of this invention 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 improved security of data, the system comprising: a network interface red 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: 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 patterns, an application interface configured to receive, from an external agent, a request to access some or all of the owner data; and at least one processor coupled to the network ace and the application ace and configured to: reverse the outer cloaking patterns to retrieve the machine—executable code; activate the le 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 ted, and upon ing 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 portion of the one or more inner cloaking patterns.
2. 2. The system of claim 1, wherein the portable 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 ons within the igent cipher transfer object.
4. 4. The system of claim 1, wherein the portable dynamic rule set es 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 following: a time period, location, or an identity of a computing device.
6. 6. The system of claim 1, wherein the er-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 ns securing the owner data and the portable dynamic rule set.
8. 8. The system of claim 1, n the one or more inner cloaking patterns are used to secure at least a portion of the portable dynamic rule set.
9. 9. The system of claim 1, wherein the executing the machine-executable code r causes the at least one processor to: rule in upon failing to verify that the external agent is authorized, execute at least one the le dynamic rule set, thereby causing at least one of the following events to occur: the intelligent cipher transfer object self-destructs, the intelligent cipher transfer 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 d for access, execute at least one rule in the portable dynamic rule set, thereby 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 intelligent 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 ated with the owner data, and at least one rule in the portable dynamic rule set is added, ed, or deleted.
11. 11. The system of claim 1, wherein 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 er system having ed 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 e a computer—based igent cipher transfer object comprising a portable dynamic rule set, said portable c rule set comprising machine-executable code secured by one or more outer cloaking patterns, at least one processor coupled to the network 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, an identity of an external agent, upon verifying the identity of the external agent, g data indicative of the identity of the al agent in the computer-based intelligent cipher transfer object, ng the data indicative of the identity of the external agent using one or more inner cloaking patterns.
14. 14. The system of claim 13, n the portable dynamic rule set is d at variable locations within the intelligent 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 intelligent cipher transfer object.
16. 16. The system of claim 13, wherein 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 processor comprises a local the portable processor, wherein activating the portable dynamic rule set comprises activating dynamic rule set on the local processor.
18. 18. The system of claim 1, wherein the computer—based igent cipher transfer object further comprises a first set of identifying information for one or more authorized agents, and the executing the e-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 ing the external agent is ized by comparing the first set of fying 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 reverse the at least the portion 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 ses a local processor, wherein ting the portable dynamic rule set comprises activating the portable dynamic rule set on the local processor.