Trusted card system using secure exchange

CROSS-REFERENCE TO RELATED APPLICATIONS

p-0002This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/188,808, filed Aug. 13, 2008, and U.S. Provisional Patent Application Ser. No. 61/205,201, filed Jan. 16, 2009, both of which are hereby incorporated by reference in their entirety.

BACKGROUND

p-0003This invention relates generally to information distribution including information protection and control and, more particularly, to secure transmission, exchange, and storage of data on a transportable media, authentication of users and transactions, and digital signing and tracking of transactions. As used herein, the term “transaction” refers to sharing of information and related work (e.g., database updating). Such sharing and related work may be viewed as a unit, which is sometimes referred to herein as a transaction.

p-0004Sharing information across multiple networks for use in many different contexts presents numerous challenges. For example, certain types of information cannot simply be uploaded or downloaded from one computer to another across a network. Rather, certain types of information may be stored on a disk (i.e., a transportable media) and physically carried from one computer to another. When information on the disk is updated, information stored on a network database or on numerous network databases also should be updated. Ensuring that all appropriate information is up-to-date across a network, particularly when transportable media is utilized, can be a significant challenge.

p-0005Also, in some contexts, laws or policies impose strict confidentiality and authentication obligations in connection with enabling sharing of such information. The confidentiality obligations can, for example, pertain to particular types or segments of information. For example, in the medical context, doctors and health care providers generally desire a reliable and secure approach for assembling comprehensive patient records from distributed sources. The sources may include multiple provider facilities, such as clinics and hospitals, each of which maintains their own patient database. Each facility database may change each time the provider is visited by a particular patient. Outright sharing of the data across a network, however, can be difficult due to the security obligations imposed by the Health Insurance Portability and Accountability Act (HIPPA).

p-0006Smartcards have been proposed for use in a medical context. One known smartcard based system includes a computer system for storing medical histories and a smartcard to store data. The smartcard is about the size of a credit card, and medical data about the individual can be downloaded, or added, to the smartcard. When the individual is examined by a physician all observations should be added, or downloaded, to the smartcard. Also, each time the patient visits a provider, the entire medical history of the individual can be retrieved from the smartcard. The smartcard makes it possible for an individual's medical history to be “read” by a computer, displayed on the computer's monitor, printed, or transmitted. This allows individuals to carry on their person a medical history of themselves.

p-0007Known smartcard technology, however, generally has limited memory storage which constrains the amount of data that can be stored on the smartcard. For example, the known smartcard does not have sufficient memory to store large records such as radiography image files. In addition, with such known smartcards, privacy is attempted to be maintained by encrypting a patient identifier. Once access to a file is granted to a user, the access to the information contained in file may be without limit. The user can, for example, modify the file, copy the file, display the file, print the file, e-mail the file, and/or transfer the file to another information system via a network. Also, after the file is distributed outside of the immediate control of the patient, security for the distributed file is left to the discretion of those who obtain a copy.

BRIEF DESCRIPTION

p-0008In one aspect, a system for secure, role-based exchange of information between a client and at least one provider of services to the client is provided. The system includes a client device comprising a memory, the memory including data relating to the client, at least a portion of the data controlled by the client, a user access component, a queuing application, a routing application, and an enforcement agent stored therein, a central server comprising an authentication method, a queuing application, a routing application, and a roles server running thereon, the central server including the data relating to the client, and an interface device capable of communications with the central server and capable of communicative coupling with the client device. The system is operable to, upon a communicative coupling between the interface device and the client device, activate the user access component, in conjunction with the authentication method, to ensure that the client is the proper holder of the client device, and the enforcement agent is operable with the roles server and user interface input from the client to define and maintain access rights to the data relating to the client for the at least one provider of services to the client, the provider of services to the client having access to the central server, the provider of services able to update the memory of the client device, and the data at the central server, based on the access rights defined by the client and contained within the enforcement agent.

p-0009In another aspect, a method for providing controlled access by various providers of services to data related to a client, a portion of the data maintained within a client device, another portion of the data maintained at a central server, the providers of services and the client device communicatively coupled to the central server that includes an authentication method and a roles server running thereon is provided. The method includes authenticating that the holder of the client device is the client using a user access method stored within the client device in conjunction with the authentication method running at the central server, providing a level of access to the data by the client, the level of access based on a role defined for the client within the roles server, the level of access enforced by an enforcement agent running on the client device, and providing a level of access to the data for the various providers, the level of access for each provider based on a role defined for each provider within the roles server, the level of access for each provider enforced by an enforcement agent running on the client device, the client capable of defining, within the enforcement agent, at least a portion of the level of access to the data for at least one of the providers.

p-0010In still another aspect, a method for securing communications between a portable memory device and a server is provided. The method includes starting a client application when the portable memory device is connected to an interface capable of capable of communications with a server, establishing a secure channel between the client application and the server, authenticating a user of the portable memory device, and using the sessionID and sequence number in transactions between the portable memory device and the server. Authenticating a user of the portable memory device is accomplished by encrypting, at the server, a sessionID and sequence number using a public key associated with the portable memory device, encrypting, the encrypted sessionID and sequence number using a private key associated with the server to form an authentication transaction, sending, the sessionID and sequence number, encrypted with both the public key and the private key to the client application, decrypting, with the client application, the authentication transaction with a public key associated with the server, and decrypting, with the client application, the sessionID and sequence number using a private key associated with the portable memory device.

p-0011In yet another aspect, a portable device for secure storage of personal records is provided. The portable device includes a physical interface for communicative coupling to an external device, and a memory accessible via the physical interface. The memory includes a data section operable for storage of the personal records, a user access component operable to provide an interface to records stored in the data section via the external device, and a security component. The security component is activated upon communicative coupling of the physical interface to an external device, and is operable with a roles server running external to the portable device to provide restricted access to portions of the personal records to a plurality of authorized users. The accessible portions for such authorized users is based on roles for the authorized users as defined within the user access component by a person to whom the portable device has been allocated.

p-0012In another aspect, a method for maintaining personal record data on a portable memory device, the device allocated to a first user, the personal record data relating to the first user is provided. The method includes authenticating the first user, authenticating that a second user has access to the personal record data, granting access to the second user, upon authentication, to an application operable to provide a user interface for accessing the personal record data, allocating a role to the second user, the second user role defined by the first user, and providing access and update privileges to the second user, to at least a portion of the personal record data relating to the first user, the privileges restricted based on the role allocated to the second user, the restricted privileges and allocated role enforced by an enforcement agent application resident on the portable memory device.

p-0013The features, functions, and advantages that have been discussed can be achieved independently in various embodiments as described herein or may be combined in yet other embodiments further details of which can be seen with reference to the following description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0014<figref idrefs="DRAWINGS">FIG. 1</figref> is a front view of a trusted card according to one embodiment.

p-0015<figref idrefs="DRAWINGS">FIG. 2A</figref> is a front view of another embodiment of a trusted card operable with a secure exchange system.

p-0016<figref idrefs="DRAWINGS">FIG. 2B</figref> is a back view of the trusted card of <figref idrefs="DRAWINGS">FIG. 2A</figref>, showing a USB connector embedded therein.

p-0017<figref idrefs="DRAWINGS">FIG. 2C</figref> is another front view of the trusted card of <figref idrefs="DRAWINGS">FIG. 2A</figref> with the USB connector extended from the trusted card.

p-0018<figref idrefs="DRAWINGS">FIG. 3</figref> is a diagram illustrating a data hierarchy for the memory associated with the trusted card of <figref idrefs="DRAWINGS">FIGS. 1</figref>, <b>2</b>A, <b>2</b>B, and <b>2</b>C.

p-0019<figref idrefs="DRAWINGS">FIG. 4</figref> is a flow chart example illustrating the hierarchical security levels associated with different provider roles related to the memory within the trusted card.

p-0020<figref idrefs="DRAWINGS">FIG. 5</figref> is a workflow chart illustrating an example admission sequence for a patient based on operation of the trusted card in conjunction with a secure exchange system.

p-0021<figref idrefs="DRAWINGS">FIG. 6</figref> is a diagram that illustrates the distributed information protection and control system according to one embodiment of the trusted card/secure exchange system.

p-0022<figref idrefs="DRAWINGS">FIG. 7</figref> is an exemplary policy data table.

p-0023<figref idrefs="DRAWINGS">FIG. 8</figref> is a representation a trusted card/secure exchange solution with several possible components represented.

p-0024<figref idrefs="DRAWINGS">FIG. 9</figref> is a flowchart illustrating the processes associated with the trusted card/secure exchange system.

p-0025<figref idrefs="DRAWINGS">FIG. 10</figref> is a diagram that provides an architectural solution for the trusted card/secure exchange system.

p-0026<figref idrefs="DRAWINGS">FIG. 10A</figref> is a system partitioning diagram that depicts the above described applications within the architectural solution of <figref idrefs="DRAWINGS">FIG. 10</figref> as components and further depicts their relationship to one another.

p-0027<figref idrefs="DRAWINGS">FIG. 11</figref> is a diagram of the security architecture associated with the trusted card/secure exchange system.

p-0028<figref idrefs="DRAWINGS">FIG. 11A</figref> is a diagram depicting a communications channel security process that establishes a secure communications channel between a trusted card and the SES platform.

p-0029<figref idrefs="DRAWINGS">FIG. 11B</figref> is an illustration of transactions sent between the card and server once a secure channel is established and authentication has been completed.

p-0030<figref idrefs="DRAWINGS">FIG. 12</figref> is a logical depiction of a Trusted Card data storage and access mechanism.

p-0031<figref idrefs="DRAWINGS">FIG. 12A</figref> illustrates storage of data with encrypted metadata in order to identify different records.

p-0032<figref idrefs="DRAWINGS">FIG. 12B</figref> is a diagram illustrating one embodiment of a trusted card logical data model which shows the relationships between the various logical data sources contained on the trusted card.

p-0033<figref idrefs="DRAWINGS">FIG. 12C</figref> depicts the relationships between the various SES data elements that are used for authentication and authorization and is referred to as a SES security database logical data model.

p-0034<figref idrefs="DRAWINGS">FIG. 13</figref> is an exploded diagram showing the layers of an exemplary image transfer.

p-0035<figref idrefs="DRAWINGS">FIG. 14</figref> is a block diagram of all necessary process steps for making and applying the above-described transfer

p-0036<figref idrefs="DRAWINGS">FIG. 15</figref> is a diagram of the components of one embodiment of digital printer.

p-0037<figref idrefs="DRAWINGS">FIG. 16</figref> illustrates a secure file for a distributed information protection and control system.

p-0038<figref idrefs="DRAWINGS">FIG. 17</figref> illustrates a manifest record.

p-0039<figref idrefs="DRAWINGS">FIG. 18</figref> illustrates a typical payload.

p-0040<figref idrefs="DRAWINGS">FIG. 19</figref> illustrates a security directive.

p-0041<figref idrefs="DRAWINGS">FIG. 20</figref> illustrates an identity and its relationship to a user and a security directive.

p-0042<figref idrefs="DRAWINGS">FIG. 21</figref> illustrates a flowchart for creating a secure file in relation to distributed information protection and control system.

p-0043<figref idrefs="DRAWINGS">FIG. 22</figref> illustrates a flow chart for accessing a secure file in relation to the distributed information protection and control system.

p-0044<figref idrefs="DRAWINGS">FIG. 23</figref> illustrates an exemplary user interface for the display of the distributed information protection and control system.

DETAILED DESCRIPTION

p-0045In one aspect, a secure exchange and trusted card system is described. Such system includes software implemented methods and a system architecture that facilitates allowing individuals to carry voluminous confidential records in his or her pocket. Such system also facilitates allowing others to have access, at a remote location, to a full set of records via computer, in accordance with a hierarchical permissions policy and allocated roles.

p-0046The system is sometimes herein described in the context of a trusted medical record system to enable patients to carry their medical records within a device that is generally shaped like a business card. The medical records context should only be considered as one of many examples of a context in which the system and its components can be utilized. The secure exchange and trusted card system can also be utilized in other applications, such as financial services cards, identity cards, and other portable record storage device applications.

p-0047In a medical context, the system enables the transport of critical and confidential information across multiple non-related enterprises. For example, in accordance with one embodiment, medical and other providers employ a patient-carried data card with large-capacity record storage. A client/server network with card-reader capabilities and software maintains a robust security framework for facilitating confidentiality by allowing others to have access to the patient's selective records via computer, in accordance with a hierarchical permissions policy.

p-0048The embodiments described herein relate to a secure exchange system that provides a balance between security and versatility. The secure exchange system also allows an individual to carry a data card which facilitates instant access to confidential records, while facilitating avoidance of tampering and invasion of privacy. A card is provided that allows for unique identifiers and/or other identification to match the card to the owner, either manually or electronically, or both. The card, when matched with a similar device, allows for a secure transaction, either locally or over a remote session. In one embodiment, software is included on the card or other device that facilitates the securing of data, locally to the device, and/or to a remote destination. Utilization of the trusted card further provides for a secure exchange of data with third parties, and further provides for the promulgation of roles based on credentials assigned by the holder of the trusted card. Trusted relationships also can be established between parties based on the authentication process associated with the trusted card and secure exchange service. The establishment of the trusted relationship also allows for secure transacting with a third party.

p-0049The central management of functions is provided within the described embodiments, including, but not limited to roles, authentication, switching and queuing. Such management ensures that activity, for example, accessing of content, is digitally signed to provide proof of access and any changes made to the data.

p-0050More specifically, and in one embodiment, the trusted card and secure exchange system provide a surface to which information and graphics can be written, using one or more of graphic printers, adhesive materials and pens. The system ensures easy access to data of any type such as sound files, images, text files, executable files and transaction records that may be stored on the trusted card using public and/or private key authentication. Each access event to these files is associated with a digital signature. Further, the secure exchange system facilitates secure transmission of any data using one or more of keys, sound files, images, text files, executable files and transaction records, to an intermediately, or end destination.

p-0051One aspect of the secure transmission and secure access to the data on the trusted card is based on the roles assigned to the users. Specifically, roles are retrieved based on the credentials provided by the authentication process to determine authorization for various access privileges, for example viewing, editing, printing, e-mailing, securing and transmitting of files. In some instances, two or more of the trusted cards, representing different parties to the transaction, are present to enable certain transactions. In at least one embodiment, by the pairing of two or more unique cards, trusted transactions can be initiated with external services, including, but not limited to, secure storage sites, mediation services, video conferencing facilities, authentication services and transaction processing services. In other embodiments, by providing the appropriate authentication with a single card, transactions via the secure exchange system can be initiated with external services, including but not limited to, secure storage sites, mediation services, video conferencing facilities, authentication services and data vaults.

p-0052<figref idrefs="DRAWINGS">FIG. 1</figref> is a front view and back view, respectively, of the data card <b>100</b>, which is sometimes referred to herein as a trusted card. In the illustrated embodiment, card <b>100</b> is substantially the same size as a standard credit card or identification card and may be carried in a standard wallet. Data card <b>100</b> includes a 30-50 Mbyte wallet-sized CDRom and may also include one or both of a magnetic strip or a bar code thereon. The data card <b>100</b> is a business-card size rectangular optical disk including a front section (<figref idrefs="DRAWINGS">FIG. 1</figref>) bearing promotional information, and rear section (not shown) bearing the functional features of the optical disk. The disk is formed from plastic with optical data-recording tracks formed by encased perforated gold foil as is typical of optical discs, the perforations being optically readable from the back. An aperture <b>105</b> is provided for a reader spindle.

p-0053Data card <b>100</b> is flexible and is capable of bearing a magnetic strip <b>114</b> or bar code. The magnetic strip <b>114</b> contains magnetically encoded patient ID information that can be read by “swiped” current credit card or debit card verification readers at any location and transmitted to a server for authentication. The optically readable portion contains up to 50 Mb of digital information encrypted per permission-based content control software (to be described). In addition to the magnetic strip <b>114</b>, the card <b>100</b> may include a paper strip or a specially coated strip (not shown) like a regular credit card to allow for a patient to sign.

p-0054As an addition or alternative to the magnetic strip <b>114</b>, the disk <b>100</b> may be provided with a two- or three-dimensional barcode (not shown) containing the same information. In this case, a two- or three-dimensional barcode can be applied by an image transfer printed by modified large-format digital printer. In one embodiment, the transfer is applied by a selective release transfer process as set forth in U.S. patent application Ser. No. 11/879,744 entitled DIGITAL TRANSFER METHOD FOR PRINTING ON A TARGET SURFACE.

p-0055Most general purpose computers and similar devices contain an optical data disk reader (Compact Disk—CD or Digital Versatile Disk—DVD) and/or USB port, and can thereby read and write information to/from a removable optical disk or USB token card. The removable optical disks or USB tokens can be written, read, re-written or erased many times. Business-card shaped CD's or USB tokens are relatively new but commonplace.

p-0056<figref idrefs="DRAWINGS">FIGS. 2A</figref>, <b>2</b>B, and <b>2</b>C are, respectively, a front view, a rear view, and a USB connector extended view of a trusted data card <b>120</b>, which is substantially the same size as a standard credit card, business card, or identification card. Though the description herein utilizes card <b>120</b> as an example, it should be noted that any device capable of communicating with a computer and containing memory sufficient to hold the data desired could be utilized, including, but not limited to, cell phones, PDAs, optical storage devices, and other portable devices that contain such memory.

p-0057<figref idrefs="DRAWINGS">FIG. 2A</figref> illustrates the front side <b>130</b> of the card <b>120</b> which in various embodiments includes one or more of a graphic representation of an image of the holder, participant, and corporate image identification or logo. The front side <b>130</b> may also include descriptive information of holder, participant, company, for example, a name, a surname, a date of birth, a gender, a social security number, an enrollment identification number, contact information and marital status. In addition, the front side <b>130</b> may include the rendering of a two dimensional or a three dimensional bar code or any other representation of identification that can be read or recognized by any form of reading or recognition device. Other information or graphics that may be used to identify the card to an individual or company or any other party may be included on the front side of the card <b>120</b> as space permits.

p-0058<figref idrefs="DRAWINGS">FIG. 2B</figref> illustrates the back side <b>140</b> of the card which may include any of the information described in the preceding paragraph, in addition to any additional information that the card supplier wants printed on the card, including but not limited to, instructions, graphics, controls and advertising collateral. The USB connector <b>150</b> housed in an alcove <b>152</b> formed in the card <b>120</b> which is fabricated to store the connector <b>150</b> flush with the overall structure of the card <b>120</b>.

p-0059<figref idrefs="DRAWINGS">FIG. 2C</figref> is an illustration of the front side <b>130</b> of card <b>120</b> with the USB connector <b>150</b> extended therefrom. Referring generally to trusted card <b>120</b>, data is stored in memory embedded in the card and is accessible via the USB connector <b>150</b>. The USB connector <b>150</b> is stored simply by sliding the connector <b>150</b> into the alcove <b>152</b> in the card <b>120</b>. The USB connector <b>150</b> slides flush with the casing defined by alcove <b>152</b> to maintain a traditional card form factor. When the contents of the memory within the card <b>120</b> are to be accessed or updated, the USB connector <b>150</b> is pulled out and can be subsequently plugged into any conventional computer USB port. In one embodiment, the USB connector <b>150</b> provides access to an embedded flex-film PC card with on-board memory of various sizes thereon. Through the described embodiments, trusted card <b>120</b> includes a capability to store data in a resident memory that is embedded within card <b>120</b>.

p-0060As with card <b>100</b> described above, card <b>120</b> may also include a substantially flat front side and at least a portion of a substantially flat rear side that accommodates multiple forms of rendering thereon, which is described above. The images that may be placed on the card <b>130</b> may include, but are not limited to, one or more two dimensional bar codes, one or more three dimensional bar codes, personal information, one or more photographs, either in color or black and white, one or more signature blocks, printed instructions, and logos.

p-0061All data written to the trusted card <b>120</b> and its supporting secure exchange system is encrypted and digitally signed, and the retrieval thereof, as described above, is managed via authentication of users and permission based roles that are implemented by the card interacting with a remote authentication and roles server. The secure exchange system includes services rendered from a central location which in various embodiments includes, but is not limited to an enforcement agent that enforces the security policy look-up table in accordance with the identity of each user that attempts to access the record data, a routing agent that allows for the routing of information to designated endpoints, and an authentication methodology, that provides for password, challenge-response, and/or bio-metric authentication of an individual based on data entered into the system in association with trusted card <b>120</b>.

p-0062<figref idrefs="DRAWINGS">FIG. 3</figref> is a view of the logical structure of security, management and data that may be stored within a memory <b>200</b> of the trusted card <b>120</b>. <figref idrefs="DRAWINGS">FIG. 3</figref> is but one embodiment of the components that could be constructed and represented on card <b>120</b>, however, any particular embodiment may include the addition or removal of certain memory components.

p-0063Data section <b>202</b> represents data that is stored on the card <b>120</b>. This data can represent anything that can be stored electronically in any format. The data can be stored in any format within a database, or a file structure or any other manner of organizing of the data. The following description describes one embodiment of the data storage capability and should not be construed to be limiting. For example, access to the data can be controlled by way of rules, roles, and access rights, amongst others that can be initiated by way of physical or logical security and authentication. The data can be encrypted or left in an original format. The data can be compressed using multiple variations of compression algorithms. The data can be set up to be viewed in a generic form or structure, or via an application or viewer. The data can be digitally signed and certified.

p-0064A user access component <b>204</b> of the memory <b>200</b> represents the application component that provides a user or application an interface to the data or logic stored within the card <b>120</b>. Depending on the application of the card <b>120</b>, the data or any other logic stored on the card or remote environment as part of the secure exchange, or external to the secure exchange as further described herein, is accessed. However, the access to this area will be achieved in the following manner, in one embodiment. For example, access may be achieved through a web site, a thin client, an application, any editor or file viewer resident on the card <b>120</b> giving access to the data or logic. Access may also be achieved through a web site, a thin client, an application, any editor or file viewer resident on any other device which can provide access to the data or logic. Access may also be achieved by using any application to execute any specific logic stored on the card <b>120</b>. This methodology can be built up in any language including, Java, C++, any tool in the Visual Studio pack, or any other language. A web site, a thin client, an application, any editor or file viewer resident within a secure exchange server, described below, may also provide access to the data stored within the card <b>120</b>.

p-0065Security method <b>206</b> represents the security component or enforcement agent of the trusted card <b>120</b>. The security component of the card <b>120</b> controls the overall behavior of the device under any condition. More specifically, the security component of the card <b>120</b> is activated once the card is activated and accessed by placing the USB connector <b>150</b> in the USB port of a computer. The security component, which may also be referred to herein as an enforcement agent has the following non-limiting functions. Specifically, the security component acts as an authentication agent, to ensure that the user(s) are who they say they are, identify the data that describes any person, application, logic, or any other means by which an attempt could be made to access the data stored within the card <b>120</b> outside of the roles allocated by the card holder as further explained herein. The data stored within the card <b>120</b> includes any information, byte, anatomical particle, graphical file, compressed file or any other data stored on the device that is requested by someone attempting to access the data <b>202</b> maintained on the card <b>120</b>.

p-0066More specifically, the security component <b>206</b> determines access rights to “What data” by “Who (as identified by other data)” and allows or blocks, the rights associated to any access to any content or application on the device. These rights can include, but are not limited to the open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse functions of anything on the card. The security component interacts with a roles server to provide authentication, and any other service or server required to enforce any role or restriction of access that has been defined. The security component also serves to provide the encryption of the information stored on the card <b>120</b> and digitally certify any activity associated with the trusted card.

p-0067Keeping with the medical records example used throughout this document, the patient's partial medical records are stored on the card <b>120</b>, and depending upon user preference, some or all of the patient's complete record is remotely stored on a central server. In some instances the user may elect to only store data on their trusted card. However, for archiving, backup, or other reasons, the card holder may elect to store some or all of their records at the server. The portion of the patient's medical records is limited only by the amount of memory on the card <b>120</b> and by the decisions made by the patient. When the patient presents his or her trusted card <b>120</b>, the provider's office verifies the patient against a photograph of the card holder printed on the card <b>120</b>, swipes the card to authenticate the user (and preferably verifies the patient's signature), and then inserts the card in an ordinary desktop computer containing a USB port. The desktop computer then asks for a password, and the user (patient) will furnish their password. The desktop computer then asks for a password associated with another user (nurse, physician, resident, or other user) who also provides their password, initiating the role allocation process described throughout this document.

p-0068When a password is entered into the desktop computer, in certain embodiments twice for confirmation, the desktop computer sends an electronic “key” to a secure server. If the password has been recorded on the server, the key will be recognized and the secure server will respond by sending another, matching electronic key back to the desktop. When the exchange of matching keys is completed, the user will receive information that is decrypted at the individual user's permitted level of access. The verification process is completed in a matter of a few seconds. It should be apparent that the card <b>120</b> offers multiple security measures: 1) passwords assigned locally according to local policy that must be known to gain access; 2) central server-based security where the password must be recognized according to pre-determined rules; 3) a photograph and/or a signature block for visual authentication. In one alternative embodiment, the trusted card may also include a magnetic strip imprinted with a unique identity key to provide an additional level of security.

p-0069Information is “locked” at some levels of access and is open at others, based on the user's classification and assigned user-rights. As described by further example below, some users are allowed to read only parts of a record. Some users will be allowed to read all parts of a record. Some users are allowed to make changes to a file. Some are allowed to print and disseminate information. Newly entered information is encrypted and recorded to the trusted card <b>120</b> on the spot and may also be sent to a server for permanent storage. When a user reads, changes, or adds to a record, the transaction is recorded and it becomes part of an electronic audit trail on the permanent record. Thus, if a user gives his or her password to an unauthorized party, that person's entry to the system will be recorded and monitored.

p-0070<figref idrefs="DRAWINGS">FIG. 4</figref> is a flow chart <b>250</b> example illustrating the hierarchical security levels of the present disclosure. <figref idrefs="DRAWINGS">FIG. 5</figref> is a workflow chart illustrating an example admission sequence for a patient using the trusted card <b>120</b>. An example admission sequence will now be described with combined reference to <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref>. In this example there are four different users: Admitting Registrar, Triage Nurse, Doctor, and Psychiatrist.

p-0071Each of these users is permitted different levels of access to the information. Some may be allowed to read only parts of a record, some will be allowed to read everything, some users will be allowed to make changes, and some will be allowed to print and disseminate information. Specifically, the Admitting Registrar has access rights to basic patient information such as contact and insurance information. They are permitted to view data only to this extent as seen at #1. The Triage Nurse has access to basic patient information, admission history, and standard medical records as seen at #2, and has authority to view and print any of these records. The Doctor has access to basic patient information, admission history, and standard as well as restricted psychiatric medical records as seen at #3, and is free to edit, view and print any of the foregoing as shown at #3. Finally, the Psychiatrist only has access to the restricted psychiatric medical records as seen at #4, but can view and print these.

p-0072As seen in <figref idrefs="DRAWINGS">FIG. 5</figref>, patient Kim Klien goes to the emergency room with shoulder injuries. Her first stop is the Admitting Registrar, where Ms. Klien hands her data card <b>120</b> to the Registrar. The Registrar verifies the trusted card <b>120</b> by checking the signature, verifying a photograph on card <b>120</b>, swiping the magnetic stripe, and inserting the USB connector <b>150</b> into a computer USB port. The Registrar then enters her own password, confirms it, and transfers either the patient's records that are stored on the card <b>120</b> and/or the patient's complete medical records from a central server to the on-site provider database. In one embodiment, Kim Klien has to first enter her password prior to password entry by any of the providers. The workflow proceeds to the Triage Nurse, Danielle DeFoe, where Ms. Klien hands her data card <b>120</b> to the Triage Nurse. The Triage Nurse again verifies the datacard by checking the signature, swiping the magnetic stripe, and inserting the USB connector <b>150</b> into a computer USB port. The Triage Nurse then enters her own password, confirms it, and proceeds to review the patient's Medical History. The Triage Nurse can access to basic patient information, admission history, and standard medical records, and has authority to view and print any of these records.

p-0073The Triage Nurse completes her customary duties which include checking the patient's vital signs. This information is keyed into the computer where it updates the provider database and is immediately written to the data card <b>120</b>. Ms. Klien next visits the ER Doctor Francis Field, who verifies the data card <b>120</b> by checking the signature, swiping the magnetic stripe, and inserting the USB connector <b>150</b> into a computer USB port. Dr. Field then enters his own password, confirms it, and makes an initial assessment and reviews the patient's medical information. Dr. Field has access to basic patient information, admission history, and standard as well as restricted psychiatric medical records, and is free to edit, view and print any of the foregoing. He is alerted to a special note on the patient's file. Ms. Klien next visits the Psychiatrist Doctor Indra Ivy, who verifies the trusted card <b>120</b> by checking the signature, swiping the magnetic stripe, and inserting the USB connector <b>150</b> into a computer USB port. Dr. Ivy then enters his own password, confirms it, and makes an initial assessment and reviews the patient's medical information. Dr. Ivy has access to the restricted psychiatric medical records and can view and print these, but not the other records. He enters a new note on the patient's file regarding adverse drug reactions. The workflow continues in this manner through to discharge, from station to station, with each attendant having only the information authority needed to complete their job properly. All along the workflow path an audit trail is being laid revealing who had what access to what data, and when. It should be noted that in one embodiment, the card holder (Kim Klien in this example) has to enter her password before each provider initiates their authentication process.

p-0074Thousands of combinations of access policies can be set for the various users as a result of the hierarchical security software described herein. Additionally, the encryption process allows records to be time limited. Records can be programmed to expire or to become locked after the passage of time. Users can be required to log on to the system for updates, thereby lessening the likelihood that a holder of a trusted card or one that has access to the records on a holder's card will mistakenly rely on out of date information.

p-0075The details of both the hardware and software will now be described.

p-0076Hardware Architecture

p-0077<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates one embodiment of a distributed information protection and control system according to the present disclosure. The information protection system includes an information system <b>300</b> accessible by a user <b>302</b> using a trusted card <b>120</b> along with theft password <b>304</b> according to one embodiment. The information system <b>300</b> may be embodied using any computer apparatus that accepts data, processes the data in accordance with one or more stored software programs, generates results, and typically includes input, output, storage, arithmetic, logic, and control units, inclusive of a desktop computer, notebook computer, supercomputer, mainframe, mini-computer, workstation, server or the like.

p-0078The information system <b>300</b> includes a number of standard computer components, including: non-persistent storage <b>310</b> and data readers <b>312</b> (for example a computer USB port plus a magnetic stripe reader). The readers <b>312</b> retrieve persistent data storage from the data card <b>120</b> to the information system <b>300</b>. The non-persistent storage <b>310</b> comprises one or more storage devices used for volatile data storage accessible by the information system <b>300</b>. Examples of the non-persistent storage <b>310</b> include: random access memory (RAM), non-volatile random access memory (NVRAM), and read-only memory (ROM).

p-0079The information system <b>300</b> also includes, in one embodiment, one or more information processors (e.g., central processing units, CPU), keyboard, mouse, display and printer, and other standard computer peripherals as desired.

p-0080The information system <b>300</b> is connected to a network <b>330</b> via a communications link. The network <b>330</b> comprises a number of computers and associated devices that are connected by communication facilities. The network <b>330</b> can involve permanent connections (e.g., cables) or temporary connections (e.g., those made through telephone or other communication links). Examples of a network include: a local area network (LAN); a wide area network (WAN); a satellite link; and a combination of networks, such as an internet and an intranet. The communications link can be established using any combination of well-known communications protocols, for example: X.25, ATM, SSH, SSL, HTTP, SMTP, NetBIOS, and/or TCP/IP.

p-0081In accordance with the described embodiments, the network <b>330</b> is coupled to an authentication identification system <b>340</b>, an authentication certification system <b>342</b>, an audit server <b>350</b>, a directory service <b>352</b>, and a policy server <b>354</b>.

p-0082The authentication identification system <b>340</b> comprises a system to authenticate the identity of the user <b>302</b> and patient to whom the data card <b>120</b> was issued. For the user <b>302</b>, the authentication identification system <b>340</b> can be an authentication service-type device capable of one or more types of challenge-response authentication protocols. Examples of challenge-response authentication protocols include: username/password authentication, secret-question/secret-answer type authentication, or any other authentication techniques to verify the identity of user <b>302</b>. Alternatively, the user <b>302</b> may identify themselves by a smartcard, a biometric reader (e.g., fingerprint reader or palm analyzer), or other authentication devices. Any number of conventional authentication devices using any combination of authentication protocols may be used to augment or replace conventional username-password type authentication, as may be provided as part of the capabilities of the information system <b>300</b>. For the patient, the authentication identification system <b>340</b> verifies the identity of the patient as read from the magnetic stripe (or barcode) on data card <b>120</b>.

p-0083The authentication certification system <b>342</b> comprises a system to generate, certify, and/or distribute cryptographic information, including cryptographic keys, to perform authentication, signing and/or other cryptological tasks to authenticate the identity of the user <b>302</b>. Conventional public key cryptosystems are known and have associated cryptographic keys that can be used to encipher and decipher information. One or more cryptographic keys can also be used to authenticate the identity of the user <b>302</b>.

p-0084The audit server <b>350</b> comprises a separate information system or storage device or devices accessible via the network <b>330</b>. The audit server <b>350</b> can be used for the collection, storage and analysis of auditing information obtained from one or more information systems, including any of the following exemplary systems: authentication identification <b>340</b>, authentication certification <b>342</b>, audit server <b>350</b>, directory service <b>352</b>, and policy server <b>354</b>. Within the prior-art, the audit server <b>350</b> may also be referred to as a data logger or a system log.

p-0085The directory service <b>352</b> comprises a system to share public and semi-public identity information regarding user <b>302</b>, as well as other known users, with those having access to network <b>330</b>. Examples of the directory service <b>352</b> include: an http server, a lightweight directory access protocol (LDAP) service, a relational database management system, and a Microsoft Exchange Server. The directory service <b>352</b> can provide user-specific information, for example: personal information of the user <b>302</b>, such as name, addresses, telephone numbers, and email addresses and cryptographic keys used by the user.

p-0086Referring back to the non-persistent storage <b>330</b>, this may include an operating system <b>370</b>, and any number of concurrently running application processes including application process <b>372</b>, for example, a word processor such as Microsoft Word. The operating system may be a conventional operating system such as Microsoft Windows™ or Linux™, alone or in combination with a virtual operating system/virtual machine. A virtual operating system can host other operating systems. Similarly, a virtual machine is a programming language interpreter (such as Java Virtual Machine™ or Python™. These allow different operating systems to run on the same computer at the same time, and it prevents applications from interfering with each other. Each virtual machine is like a “machine within the machine” and functions as if it owned the entire computer. The operating systems in each virtual machine partition are called “guest operating systems,” and they communicate with the hardware via a virtual machine control program called a “virtual machine monitor” (VMM). The VMM “virtualizes” the hardware for each virtual machine. With a virtual operating system/virtual machine the present software need not be dedicated to the Microsoft operating system.

p-0087A program application <b>374</b> runs within application process <b>376</b> which runs, and enforcement agent <b>378</b> is associated with application process <b>376</b>. Similarly, enforcement agent <b>379</b> is associated with application process <b>380</b>, within which OS shell application <b>382</b> runs. Generally, a command line interface or operating system shell or executive may be run as a type of application running in an application process, depicted as OS shell <b>382</b>, examples of which include: “command.com” and “explorer.exe” for one known operating system <b>370</b>, and the “bash” command for another known operating system <b>372</b>. Examples of an application <b>374</b> running inside of application process <b>376</b> include: Microsoft Word, Adobe Acrobat Reader, Netscape Internet Browser and the GNU Image Manipulation Program.

p-0088The enforcement agents <b>378</b> and <b>379</b> are instances of a software program that modifies the interface between the application process and operating system kernel, and permits additional non-discretionary access controls to be enforced without requiring changes to user application programs. In <figref idrefs="DRAWINGS">FIG. 6</figref>, enforcement agent <b>378</b> is associated with application process <b>376</b> within which program application <b>374</b> runs, and enforcement agent <b>379</b> is associated with application process <b>380</b>, within which OS shell application <b>382</b> runs. Each enforcement agent controls access to the contents of secure files <b>390</b> by application <b>374</b> running within application process <b>376</b>. The access is controlled in accordance with a policy model that permits different classes of users different levels of access to the information, depending on predetermined authorization. For example, admission personnel will have access to insurance and selected personal information, however can only copy it to a selected file and nothing else. Nurses, pharmacists and physicians would have policies that grant higher levels of access. Individual users are granted access only to the information that they need for their specific roles in the health care process. The secure exchange system's multi-level policy capability can be custom-tailored to provide the high level of security required under the federal HIPPA laws, while allowing an extraordinary level of versatility and portability. If an unauthorized person tries to enter the system to read, copy or change a medical record, the secure exchange system disallows the action and records the intrusion in an activity log and it notifies the responsible persons automatically. At the Security Policy Server <b>354</b>, the user name, password and patient identifier are matched to a system-wide policy that is designed to comply with HIPPA. The system-wide policy is maintained as a data table at the Security Policy Server <b>354</b>.

p-0089<figref idrefs="DRAWINGS">FIG. 7</figref> represents an exemplary policy data table <b>398</b>. The policy table is a graphical representation of the role allocated to any person, application, device or any other role-player that can execute the following roles, but not limited to the open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse functions of anything on the card. Once the necessary authentication has been applied, the roles service user the policy data table to determine levels of authorization. Authorization levels can range from complete access or limit it to restricted access.

p-0090As represented by the policy data table <b>398</b> example, at any intersection of data category and level of access, the open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse functions of any information or application on the card can be managed. The rights associated to any user, device or application is granted once a call is made to the roles logic of the solution, and the necessary authorizations have taken place. In response to a query, the policy service determines whether sufficient authorization exists for the enforcement agent to allow the requested action or actions initiated by any user, application or logic.

p-0091The data categories are arranged in rows by type of record/information. In the medical records example, these may include Personal Information, Medical Information, Restricted Medical Information, Medical Records, etc. The policy table is arranged in columns by categorical status with respect to the roles that access the data. Examples of these roles may include Patient, Primary Care Physician, ER Triage Nurse, Resident, Admitting Nurse, Radiologist, Psychiatric, etc. Defined user actions are specified in the second column, and these may include View, Change Policy, Copy/paste, Modify, Print, Append, Set Date Range, etc. The security policy broker <b>354</b> implements this pre-defined policy. The security policy broker <b>354</b> interprets security policy within the context of information system <b>300</b>. There may be one or more security policy brokers <b>354</b> running in information system <b>300</b>. Referring back to <figref idrefs="DRAWINGS">FIG. 6</figref>, one security policy broker <b>384</b> is assigned to enforcement agents <b>378</b> and <b>379</b>. The security policy broker <b>384</b> and the enforcement agents <b>378</b> and <b>379</b> run on the same information system <b>300</b>, and each enforcement agent runs in different application processes.

p-0092In response to a query by an enforcement agent, the security policy broker <b>384</b> determines whether sufficient authorization exists for the enforcement agent to allow the requested action or actions initiated by user <b>302</b>. In other words, the enforcement agent communicates with the security policy broker <b>384</b> to determine how specific user-actions should be enforced. The security policy broker <b>384</b> is also responsible for ensuring compliance with the correct security policy, whether this policy information is carried within the secure file <b>390</b>, maintained in the policy broker cache <b>392</b>, or retrieved from the security policy server <b>354</b>.

p-0093Each enforcement agent controls access to the contents of secure files <b>390</b> by application <b>374</b> running within application process <b>376</b>. The enforcement agent <b>378</b> monitors, intercepts, and as needed, mitigates, the requested actions performed to and with the contents of secure files <b>390</b>. The enforcement agent <b>378</b> intercepts the flow of instructions between the operating system <b>370</b> and the application program <b>374</b> running in application process <b>376</b>.

p-0094This interception can be accomplished in any number of ways. For example, the interception can use one or more existing application programming interfaces (APIs) and other well-known programmatic conventions implemented by the operating system <b>370</b>. Information on such interfaces and conventions can be obtained from the published documentation associated with the operating system <b>370</b> or obtained from by careful study and analysis of actual programs, or obtained using other conventional techniques.

p-0095The specific design and implementation of the enforcement agent depends on the operating system <b>370</b>, and includes measures to identify, detect, and as necessary, modify, the flow of instructions between the application program <b>374</b> and the kernel of the operating system <b>370</b>. By way of example, the enforcement agent can be implemented on a process-by-process basis for all application processes <b>372</b>, or possibly as an enhancement to the programs and tools provided with the operating system <b>370</b>, or possibly even as an extension to the kernel of the operating system <b>370</b>. Such an extension to the kernel can, for example, be implemented using a pseudo-device driver or other loaded module of the kernel executive of the operating system <b>370</b>; or by enhancing the capabilities of the existing system-wide library routines, such as “glibc” or kernel32.exe; or by extending the capabilities of existing command level applications, such as bash, ash, or command.com; or by modifying the attributes of each application process <b>372</b> as it is created by the operating system <b>370</b>.

p-0096The trusted card <b>120</b> includes the data files for a patient which are read into the secure exchange upon insertion of the USB connector <b>150</b> into a USB port of a computer and subsequent user authentication. These patient files include data files <b>394</b>, secure files <b>390</b>, policy broker caches <b>392</b>, and enforcement agent caches <b>396</b>.

p-0097Each secure file <b>390</b> contains both information to be secured (e.g., from a file <b>394</b> or generated by the user <b>302</b>) and additional information to maintain its security. The contents of a secure file <b>390</b> cannot be successfully accessed without the intercession of an enforcement agent and a security policy broker <b>384</b> implementing the security policy under which the security policy broker <b>384</b> was configured. For example, the secure file <b>390</b> can contain a Microsoft Word file, which can be shared with others, but whose content is accessed through the use of a Microsoft Word application running in an application process <b>376</b> associated with an enforcement agent <b>378</b>. The details of the secure file <b>390</b> are discussed below.

p-0098The policy broker cache <b>392</b> is used by the security policy broker <b>384</b> to retain and reuse information used to make enforcement decisions. The policy broker cache <b>392</b> can store additional information on the security policy, identity information about users of the described embodiments, and/or other information. The policy broker cache <b>392</b> can be shared between multiple security policy brokers <b>384</b>, and/or there may be one policy broker cache <b>392</b> for each security policy broker <b>384</b>.

p-0099The enforcement agent cache <b>396</b> is used by the enforcement agents to store any temporary information created by applications protected by the enforcement agents. Information in the enforcement agent cache <b>396</b> is protected from unauthorized access. Temporary information can include, for example, automated backups, automatically generated revisions, and others types of temporary files. The enforcement agent cache <b>396</b> is used to ensure that this temporary information is maintained in a protected state and that no unprotected copies of any temporary files are vulnerable to unauthorized access. The enforcement agent cache <b>396</b> may also temporarily store decrypted plaintext blocks of information otherwise contained within protected secure files <b>390</b> in an encrypted state. In other embodiments, the enforcement agent cache <b>396</b> may be shared between multiple enforcement agents <b>378</b> and <b>379</b>, and/or there may be one enforcement agent cache <b>396</b> for each enforcement agent.

p-0100The policy broker cache <b>392</b> and/or the enforcement agent cache <b>396</b> can include a time- to-live (TTL) interval, where the cached information remains authoritative for a specified interval of time. After the time-to-live interval ends, the cached information expires. The TTL interval may vary according to the specific security policy in place, and indeed, different TTL values may be used with different users, for different files, and/or with different information systems.

p-0101With regard to <figref idrefs="DRAWINGS">FIG. 6</figref>, and in addition to the prior art connections via the network <b>330</b>, the information system is connected via the network <b>330</b> to an audit server <b>350</b>, a directory service <b>352</b>, and a security policy server <b>354</b>. The audit server <b>350</b> receives the detailed event data from the enforcement agents and the security policy brokers <b>384</b> of various information systems coupled to the audit server <b>350</b> via network <b>330</b>. This event data indicates what users attempted what actions under what conditions, along with other security related information collected by enforcement agents and security policy brokers <b>384</b>. The collection of these events can be directed by the security policy. In various embodiments, there may be one audit server <b>350</b>, multiple audit servers <b>350</b>, or no audit servers <b>350</b>. In the case of no audit server <b>350</b>, all information that would otherwise be sent to an audit server <b>350</b> may be stored in information system <b>300</b>.

p-0102The directory service <b>352</b> contains additional information associated with users required for the operation of the information systems utilizing the currently described embodiments. Such additional information includes, for example: identity records and other configuration data for the enforcement agents <b>378</b> and <b>379</b> and security policy brokers <b>384</b> specific to users <b>302</b>. In various embodiments, there may be one directory service <b>352</b>, multiple directory service <b>352</b>, or no directory service <b>352</b>. In the case of no directory service <b>352</b>, all information that would otherwise be sent to a directory service <b>352</b> may be stored in information system <b>300</b>.

p-0103The security policy server <b>354</b> provides updates to the security policy broker <b>384</b> on the security policy for the information system <b>300</b>. Depending on the security policies of a given organization and the privileges of the user <b>302</b>, the information system <b>300</b> may be permitted to function for periods of time without a connection to the security policy server <b>384</b>, depending on information stored with the policy broker cache <b>392</b> and enforcement agent cache <b>396</b>. If such disconnected operation is permitted, the actions of the user <b>302</b> can be further restricted while the information system <b>300</b> is in a disconnected state. In addition to the initial activation of the information system <b>300</b>, the information system <b>300</b> at other times can access the security policy server <b>354</b> for additional security policy information. For example, the information system <b>300</b> can access the security policy server <b>354</b> periodically, non-periodically, and/or in response to rules established in the security policy itself. In various embodiments, there may be one security policy server <b>354</b>, multiple security policy servers <b>354</b>, or no security policy servers <b>354</b>. In the case of no security policy server <b>354</b>, all information that would otherwise be sent to a security policy server <b>354</b> may be stored in information system <b>300</b>.

p-0104The security policy obtained from the security policy server <b>354</b> may be specific to a given person, a particular information system, or both. Such person-specific information can include, for example: authentication-related credentials (e.g., passwords, cryptography keys, biometric attributes, and authentication tokens); and references to various authenticated-related information located elsewhere via the network <b>330</b> (e.g., passwords, cryptography keys, biometric attributes, and authentication tokens). The security policy information obtained from the security policy server <b>354</b> can be stored for an indefinite period of time in the policy broker cache <b>392</b>, a defined period of time in the policy broker cache <b>392</b> before needing refreshment by the security policy server <b>354</b>, or retrieved from the security policy server <b>354</b> each time it is required.

p-0105In other embodiments, the security policy broker <b>384</b> can obtain authentication related information from the security policy server <b>354</b>, the authentication identification system <b>340</b>, authentication certification system <b>342</b>, and/or the directory service <b>352</b>. The security policy broker <b>384</b> can also make use of authentication mechanisms provided in the operating system <b>370</b>.

p-0106<figref idrefs="DRAWINGS">FIG. 8</figref> is a representation of one embodiment of a secure exchange/trusted card solution with several possible components of the secure exchange system represented. It should be noted that any particular deployment, may or may not include all the aspects described with respect to <figref idrefs="DRAWINGS">FIG. 8</figref>.

p-0107A first card holder <b>401</b> is the person who has been allocated a trusted card for any reason or application. The trusted card provides a secure, portable mechanism for transporting data. The first card holder <b>401</b> can assume any role and use the card for the transportation of any data. The ability to access the data and the role that the person plays when the card is accessed is defined by User Access Method <b>408</b>, Enforcement Agent <b>409</b>, Authentication Method <b>415</b>, Role allocation <b>416</b>, and user two <b>402</b>. The first card holder <b>401</b> may interface with numerous role-players and require the card to be accessed by numerous devices to complete a transaction.

p-0108With respect to a second card holder <b>402</b>, there are a number of transactions, but not all, that will require the role of a second or third card holder. Specifically, there are a number of scenarios where a second role-player will have rights associated with them to participate or fulfill types of transactions. However these roles will always be managed by the Authentication Method <b>415</b>, and the Role Server <b>416</b>.

p-0109The trusted card <b>403</b> is the physical device described in <figref idrefs="DRAWINGS">FIGS. 2A</figref>, <b>2</b>B, and <b>2</b>C. As further described, trusted card <b>403</b> includes the Data Store <b>407</b>, User Access Method <b>408</b>, and Enforcement Agent <b>409</b> (analogous to <figref idrefs="DRAWINGS">FIG. 3</figref>) and represents a secure method for the transportation of information. The access to the information of the card, the Data Store <b>407</b>, is managed and controlled by, User Access Method <b>408</b>, Enforcement Agent <b>409</b>, the Authentication server <b>415</b>, and the Roles Server <b>416</b>.

p-0110A second trusted card <b>404</b> is utilized in a number of transactions, but not all transactions require the role of a second or third trusted card <b>404</b>. The second trusted card <b>404</b> is similar to the trusted card <b>403</b>. The pairing of two or more trusted cards <b>403</b> and <b>404</b> can be used to activate specific types of transactions. These transactions include, but are not limited to roles allocated by the Roles Server <b>416</b> to the Enforcement Agent <b>409</b> on card <b>403</b> and the enforcement agent <b>412</b> on card <b>404</b>. Trusted card <b>403</b> is utilized to issue specific rights to second card holder <b>402</b>, for either card <b>403</b> or card <b>404</b>. Another transaction includes the pairing of cards <b>403</b> and <b>404</b>, together with the roles allocated by the Roles Server <b>416</b>, which may result in a transaction to an external system <b>500</b> using any gateway service represented as integration service <b>417</b>, or initiate any other service within the trusted exchange environment <b>414</b>.

p-0111The pairing of the first trusted card <b>403</b> and the second trusted card <b>404</b>, together with the roles allocated by the Roles Server <b>416</b>, allows either first card holder <b>401</b>, and/or second card holder <b>402</b> to effect one, some, or all of the following functions: open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse functions of anything on the card

p-0112Together, the various components make up the trusted card <b>403</b>. Those components include the content (data store <b>407</b>) which is accessed via user access method <b>408</b>, however all access, encryption, roles and restrictions are managed by the Enforcement Agent <b>409</b> with reference to the Authentication server <b>415</b>, and the Roles Server <b>416</b>.

p-0113With regard to Data Storage system <b>407</b>, the Trusted Card <b>403</b> is able to store anything that can be converted to a format that can be stored on a memory device. First card holder <b>401</b> can, by inserting the USB connector into any device that can execute the User Access Method <b>408</b>, get access to data stored on the data store <b>407</b>. The level of access and the role that first card holder <b>401</b> assumes is governed by the enforcement agent <b>409</b>.

p-0114With regard to the user access method <b>408</b>, the content of the card is made available to a user via the user access method <b>408</b>. Method <b>408</b> can be built using any coding language, methodology and logic. The presentation of anything stored on the card <b>403</b>, as well as the ability to initiate any other transaction, is accomplished via the User Access Method <b>408</b>. The functionality provided by user access method <b>408</b> can be provided via any method that can be developed using any coding method.

p-0115Access to any aspect of the card is controlled and managed by way of an enforcement agent <b>409</b>. The enforcement agent <b>409</b> is, amongst other functions, the encryption method, the authentication methodology, and security for all aspects of the content of the trusted card <b>403</b>. The Enforcement Agent <b>409</b>, depending on what the system is being used for, will make use of any methodology, cryptology, and security system to authenticate a user or application. Based on the level or authentication required to access any component of the solution, the Enforcement Agent <b>409</b> will limit access to the Data Store <b>407</b> and enable features and functions in the User Access Method <b>408</b>. The Enforcement Agent <b>409</b> passes user credentials to the Authentication server <b>415</b> to authenticate the user if connected to the secure exchange and to the Roles Server <b>416</b>, for specific roles to be passed to the Enforcement Agent <b>409</b>, which are filtered down to the User Access Method <b>408</b> and the Data Store <b>407</b>.

p-0116With regard to data storage system <b>410</b>, the second trusted card <b>404</b> is able to store anything that can be converted to a format that can be stored on a memory device. As mentioned above, under certain conditions, one, two or multiple cards can form part of the solution. The second, third or multiple cards may or may not have stored information on them, and depending on the application of the solution it may or may not be accessed by second card holder <b>402</b>, after the relevant authorization by the second enforcement agent <b>412</b>, and using the appropriate method defined in the second user access method <b>411</b>.

p-0117The content of the trusted cards is made available to a user via the user access method <b>411</b>, which is used when the multi card solution is being deployed. In the normal application of this solution, the functionality, and methods activated on second trusted card <b>404</b>, by way of the second user access method <b>411</b>, is controlled by the second enforcement agent <b>412</b>.

p-0118The second enforcement agent <b>412</b> controls and manages access to any aspect of the card <b>404</b>. The second enforcement agent <b>412</b> is, amongst other functions, the encryption method, the authentication methodology and security for all aspects of the content. The second enforcement agent <b>412</b> secures all aspects of the Trusted Card <b>404</b>. When a multi card solution is deployed, the roles that second, third, and fourth, etc. trusted cards provide in the solution are managed by the second enforcement agent <b>412</b>, after identifying the second card user <b>402</b>.

p-0119The second enforcement agent <b>412</b> authenticates the second user <b>402</b> locally and also by calling the authentication method <b>415</b>, then identifying that users role, on the role server <b>416</b>. After the authentication process has been executed, and the user's role defined, the second user <b>402</b>, can access data on the second card <b>404</b>, the Data Store <b>410</b>, or have access to some, or all data on the first trusted card <b>403</b>, which is stored in data store <b>407</b>. In this scenario, second enforcement agent <b>412</b> will ship credentials to the Authentication server <b>415</b>, the Roles Server <b>416</b>, and the Enforcement Agent <b>409</b>.

p-0120Trusted exchange <b>414</b> is a service to authenticate all users and applications of the solution, host and enforce the roles identified and described with respect to <figref idrefs="DRAWINGS">FIG. 7</figref>, provide the ability to queue messages when necessary, provide the means to integrate to third party or other systems, and provide an audit capability. Components of the Trusted Exchange <b>414</b> interact with all parts of the overall solution.

p-0121With regard to authentication method <b>415</b>, any aspect of the trusted solution is managed and executed by the authentication method <b>415</b>. This role can be fulfilled by any technology executing LDAP type services installed in the Trusted Exchange. More specifically, the authentication method <b>415</b> includes an authentication server that interacts with the total solution in different ways and at different times. For example, when first card user <b>401</b> inputs the first trusted card <b>403</b> into any system, the enforcement agent <b>409</b> applies access rights to those user credentials. The enforcement agent <b>409</b> may, under certain conditions, initiate a request to the authentication server <b>415</b> to get additional rights to engage the user access method <b>408</b> and/or the data store <b>407</b>. The authentication server <b>415</b> may also, under certain conditions, accept a request from a second trusted card <b>404</b>. These requests could take place concurrently, or singularly, and under specific conditions, the rights issued to second card user <b>402</b>, using second trusted card <b>404</b>, could depend on the identity of the first card user <b>40</b>, and their trusted card <b>403</b>.

p-0122The role allocation server <b>416</b> manages the roles executed by any component of the solution. Once first card user <b>401</b> and trusted card <b>403</b> have been identified and authenticated, and the enforcement agent <b>409</b> has activated, a request many be issued to the authentication method <b>415</b> to authenticate the first card user and first trusted card <b>403</b> into the Trusted Exchange <b>414</b>. Once this transaction has taken place, the credentials will be passed to the role allocation server <b>416</b>, which will issue the relevant role to the first card user <b>401</b>, which could include some or all of these functions open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse functions of anything on the card.

p-0123There are instances where first card user <b>401</b> and second card user <b>402</b> will be executing a joint or mutual transaction that will require different roles being issued by the role allocation server <b>416</b> to trusted card <b>403</b> and trusted card <b>404</b>. In addition, there are instances where with the appropriate authentication and role allocation being issued to the second trusted card <b>404</b>, and thus second card user <b>402</b>, will be given access to the data on trusted card <b>403</b>. Depending on the authentication and role allocation process, the second card user <b>402</b> may be issued some or all of these functions open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse functions of anything on the first trusted card <b>403</b>.

p-0124With regard to integration with an external system, integration service component <b>417</b> of the Trusted Exchange <b>414</b> allows the trusted solution to send transactions to and receive transactions from systems external to the trusted solution, in a secure and managed way. The first card holder <b>401</b> independently, or in combination with the second card holder <b>402</b>, can initiate certain transactions. In this scenario a call will be generated by the integration service <b>417</b> to an external system to initiate transactions with that external system. The transaction will typically be initiated by first card user <b>401</b> inserting first trusted card <b>403</b> into a device, being authenticated by the enforcement agent <b>409</b>, and then being authenticated into the trusted exchange by the Authentication server <b>415</b>, and an appropriate role being issued by the role allocation server <b>416</b>. Concurrently, or independently, the second card user <b>402</b> inserts the second trusted card <b>404</b> into an appropriate device, and second card user <b>402</b> is authenticated by the enforcement agent <b>412</b> for the second trusted card <b>404</b>. The second card user <b>402</b> is then authenticated into the trusted exchange <b>414</b> by the enforcement agent <b>412</b> transacting with the authentication method <b>415</b> in the Trusted Exchange <b>414</b> via the Authentication server, and an appropriate role being issued with respect to the first card holder <b>401</b> and the first trusted card <b>403</b> by the role allocation server <b>416</b>. The matching of the two appropriately authenticated cards and users, will allow for a unique set of transactions which could include any type of transaction to an external system such as a financial institution of clearing agent.

p-0125<figref idrefs="DRAWINGS">FIG. 9</figref> is a flowchart <b>500</b> further illustrating the processes associated with the trusted card/secure exchange system described herein. Some of the reference numerals used in <figref idrefs="DRAWINGS">FIG. 9</figref> are also shown in <figref idrefs="DRAWINGS">FIG. 8</figref> to provide additional context to the processes described with respect to <figref idrefs="DRAWINGS">FIG. 9</figref>. Specifically, the first card user <b>401</b>, after inserting the card into an appropriate device, is authenticated <b>502</b> by the enforcement method, using any appropriate methodology. After the user is authenticated <b>502</b> appropriately, access is granted <b>504</b> to the application resident on the card that enables a user interface to the data stored on the card.

p-0126The first card user <b>401</b> is able to gain access <b>503</b> to the contents on the card <b>403</b>, based on the level of access granted by the enforcement agent including the allocation of the appropriate role from the role server. The user can open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse the contents of the card. Depending on the application, the access right granted <b>505</b> to the data to open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse, can be administered to the byte level.

p-0127Depending on the nature of the transaction required, the enforcement agent will access <b>506</b> the secure exchange, where the card user and card will be authenticated to the secure exchange, and a role will be allocated <b>508</b> to the relationship of user and card. Once a card and user has been authenticated by the enforcement agent, a call can be made to the role server, to allocate a role to that user. That role is then passed to the enforcement agent associated with that trusted card.

p-0128The second card user <b>402</b>, after inserting the card <b>403</b> into an appropriate device, is authenticated <b>510</b> by the enforcement method, using any appropriate methodology. After the second card user <b>402</b> is authenticated appropriately, access is granted <b>512</b> to the application resident on the card that enables user interface to the data stored on the second card as well to the contents on the card <b>403</b>. Based on the level of access granted <b>513</b> by the enforcement agent (a provider's defined role), the user can open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse the content of either card <b>403</b> and <b>404</b>. Depending on the application the access right granted <b>515</b> to the data to open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse, can be to the byte level.

p-0129Depending on the nature of the transaction required, the enforcement agent will access <b>514</b> the trusted exchange, where the user and card will be authenticated to the secure exchange and a role will be allocated <b>516</b> to the relationship of user and card. Once a card and user have been authenticated by the enforcement agent, a call can be made to the role server, to allocate <b>516</b> a role to that user. That role is then passed to the cards enforcement agent. Under certain conditions, the transactions may result in a transaction where the combination of two cards results in the holder of one card getting access <b>518</b> to the content of the other card once the appropriate authentication and role allocation has been done, this will allow the appropriately authenticated user to open, save, update, edit, create, delete, rename, move, add, append, concatenate, comment, compile and/or browse the content.

p-0130Trusted Card/Secure Exchange Example

p-0131The following example will be used to illustrate the functionality of the trusted card/secure exchange system described herein. Though the example is provided in the medical records context, the disclosure should not be construed to be so limited.

p-0132The context of the example is a health care insurance company wants to deploy a solution to provide a secure portable mechanism for their members to record and store all appropriate medical information, make sure that all relevant practitioners have appropriate rights to information that is required as part of the health care process, ensure that collection and accuracy of insurance claims, processing of information with little or no time delay, reduce the instances of fraud through the system, and implement a system to speed up the settlement of practitioners claims.

p-0133In the example, a health care insurance company issues, by way of the secure exchange company a series of trusted cards. There are two distinct cards, the one is for the client base, and the other is for the service providers.

p-0134For the client's card, the health insurance company issues a card specifically for its clients. The card may be printed with an image of the card owner, for example, in color and at the right hand top corner of the card. This card is also printed with a 3D barcode that represents all relevant information of the client, that can be scanned via a static or hand held bar code reader. The card is further printed with all information required to identify the card to the client and to the health insurance company, including name, plan, coverage date, client number, etc.

p-0135The card, in preferred embodiments also includes certain logical features. Specifically, the trusted card is issued with a storage system where any data written to the card is stored in a logical, secure manner. In the described example, the data is stored as a database. In addition, the trusted card is issued with an embedded application that renders a web based application local to the card, which is initiated every time the card is inserted into a computer and allows the user to interact with the content.

p-0136The card may further include a firewall application that authenticates any access to the application as well as the data stored on the card. The firewall application in this instance also digitally signs any access to any content on the card providing a detailed audit trail of all activity. The startup page on the embedded website contains attributes that can be used to link ownership of the card to the client presenting it this includes an image of the client. The database is pre-populated with a patient detail transcript, a prescription form, a diagnosis form and a claim submission form. Also embedded in the cards logic is a unique identifier, which identifies, systematically, the card and user to the secure exchange, and the health insurance company. This identifier cannot be changed, to provide a new number to a client, requires issuance of a new card.

p-0137The health insurance company issues a card specifically for its registered practitioners. The card is printed with all information required to identify the card to the practitioner and to the health insurance company, including name, practice number, issue date, etc. The card is printed with a 3D barcode that represents all relevant information of the practitioner, that can be scanned via a static or hand held bar code reader.

p-0138Logical features included in the practitioner's card include an embedded application that manages authentication of the practitioner, establishes a session with the secure exchange, and issues appropriate credentials of the user to the secure exchange for authentication purposes, as well as role allocation.

p-0139For the sake of this example, the patient is seeing a doctor for the treatment of flu. The patient makes an appointment to see a general practitioner located near the local hospital, as the patient's house doctor is unavailable for the day. The patient arrives at the practice at the agreed time. Upon arrival, the administrative assistant requests the name of the health insurance company that will be covering the cost of the visit. The patient produces the trusted card, and hands it to the administrative assistant. The administrator takes the card from the patient, uses the graphic image embedded on the card to verify the card belongs to the patient and then verifies the other details.

p-0140The administrator starts the engagement by inserting the USB Connector of the doctor/practice's card into a USB port on the PC in the practice. The enforcement agent embedded on the card requests immediate password authentication, the administrator enters the appropriate password which then initiates a call to the secure exchange. The patient may also have to enter a password in certain embodiments. The data transmitted to the secure exchange includes the practice identification data and the authentication parameters generated when the administrator entered the password requested by the embedded system on the card. The data handed to the secure exchange is passed to an LDAP server, which authenticates the doctor based on the credentials received from the embedded application on the doctors trusted card. The secure exchange generates a “logon successful” message which is displayed on the screen of the PC.

p-0141Once this process has been completed the administrator extends the USB connector from the patient's card. This USB connector is then also inserted in to the practice's PC. The embedded Web Site auto initiates, and presents the administrator with a number of options. These options include, in one specific embodiment, print a medical history of the patient, print a practice admittance form, prepopulated with all required information, update records, export data in a file format to import into the practice's system, and backup the data on the card.

p-0142However, before any transaction can be processed, the application that was initiated from the doctor's card, which is still resident in the PC's memory, queries the enforcement agent on the patient's card and extracts the information that identifies both the card and the patient. This data includes the card's unique identification number and the patient's identification number. This data is then sent to the secure exchange system.

p-0143These data points, “card and patient id” are also authenticated by the LDAP server. The LDAP server will then verify the patient credentials and validate the patient's membership with the health insurance company.

p-0144Once the dual validation process has completed, the credentials are passed to the roles server within the secure exchange. The role server uses the credentials that have been passed to it via the LDAP server to reference the policy data table on the roles server. Based on the doctor's function, as well as a number of other criteria a role will be issued by the roles server to the enforcement agent on the patient's card. The enforcement agent will use the credentials that have been passed to it from the roles server to assign privileges to the administrator to execute certain functions on the patients trusted card.

p-0145By virtue of the access that has been granted, the administrator selects the option to print the patient's medical history, patient detail transcript, a diagnosis form and a claim submission form. Each one of these actions is recorded in an audit file on the patients trusted card. The administrator places the patients detail transcript in a file and places the patient's medical history and diagnosis form on a clip board for the doctor.

p-0146The patient sees the doctor, undergoes an examination, and the doctor diagnoses the patient with the flu. The doctor reviews the patient history record that has been printed from the patients trusted card to identify whether the patient is on any other treatment, or has any other condition that may affect the doctor's decision on a course of treatments. Once the doctor has identified the treatment that the patient should received, he completes the diagnosis form with the diagnosis, treatment prescribed and all relevant HIPPA codes. The doctor also makes out a prescription for the patient.

p-0147The patient then returns to the administrator with the completed forms. The administrator then re-inserts the patients trusted card's USB connector into the PC's USB port. The enforcement agent re-authenticates with the doctors credentials, and grants the administrator access to the relevant aspects of the patients trusted card. In this case, the administrator has been granted edit and updates rights, and accordingly is able to enter the information as documented by the doctor into the trusted card via the update information template; the administrator also captures the content of the prescription onto the patients trusted card prescription template, which writes the data to the database on the card. This data is all digitally certified, and any activity is certified for audit purposes.

p-0148Once the administrator has updated the medical history database on the card, a transaction is generated to the secure exchange, which includes, doctor's credentials, patient credentials, diagnosis and treatment code. The transaction is again authenticated by the LDAP server, and then routed to the broker service within the secure exchange. The broker service is configured to route the compete transaction which includes, health insurance company routing address, practitioners details specific to that health insurance company, patients details as well as relevant treatment codes to the health insurance company. On receipt of this transaction, the health insurance company's gateway responds with a transaction successful message that is rendered to the PC in the practice.

p-0149The health insurance company has all the information it requires for an immediate settlement of the transaction with the doctor. On receiving the “transaction successful” message, the administrator in the practice removes the patients trusted card and returns it to the patient. The patient then proceeds to the pharmacy where the patient presents their trusted card to the pharmacist.

p-0150The pharmacist starts the engagement by inserting the USB Connector of the pharmacy's card into a USB port on the PC in the practice. The enforcement agent embedded on the card requests immediate password authentication, the pharmacist enters the appropriate password which then initiates a call to the secure exchange. The data transmitted to the secure exchange includes, the pharmacist identification data and the authentication parameters generated when the pharmacist entered the password requested by the embedded system on the card. The data handed to the secure exchange is passed to an LDAP server, which authenticates the pharmacist based on the credentials received from the embedded application on the pharmacist trusted card. The secure exchange generates a “logon successful” message which is displayed on the screen of the PC.

p-0151Once this process has been completed the pharmacist extends the USB connector from the patient's card. This USB connector is then also inserted in to the pharmacist PC. The embedded Web Site auto initiates, and presents the pharmacist with a number of options. These options include print a medical history of the patient, print prescription, and backup the data on the card.

p-0152However, before any transaction can be processed, the application that was initiated from the pharmacist card, which is still resident in the PC's memory, queries the enforcement agent on the patient's card and extracts the information that identifies both the card and the patient. This data includes the cards unique identification number and the patient's identification number. This data is then sent to the secure exchange system.

p-0153These data points, “card and patient id” are also authenticated by the LDAP server. The LDAP server will then verify the patient credentials and validate the patient's membership with the health insurance company.

p-0154Once the dual validation process has completed, the credentials are passed to the roles server within the secure exchange. The role server uses the credentials that have been passed to it via the LDAP server to reference the policy data table on the roles server. The pharmacist has a standard function defined on the role server, this role will be issued by the roles server to the enforcement agent on the patient's card. The enforcement agent will use the credentials that have been passed to it from the roles server to assign privileges to the pharmacist to execute certain functions on the patients trusted card.

p-0155The pharmacist then prints the prescription as made out by the doctor and fills it. Once he has completed these steps, he updates the prescription file on the patients trusted card, which is digitally signed, and a transaction is generated to the secure exchange, which includes, pharmacist credentials, patient credentials and medication. At least one effect of these steps is to prevent the patient from securing multiple prescriptions from multiple doctors and multiple pharmacists. The transaction is again authenticated by the LDAP server, and then routed to the broker service within the secure exchange. The broker service is configured to route the compete transaction which includes, health insurance company routing address, pharmacist details specific to that health insurance company, patients details as well as relevant medication codes to the health insurance company. On receipt of this transaction, the health insurance company's gateway responds with a transaction successful message that is rendered to the pharmacist PC. The health insurance company has all the information it requires for an immediate settlement of the transaction with the pharmacist.

p-0156As described repeatedly herein, security is a core requirement of the Secure Exchange Solution (SES) and Trusted Card. As such, the Trusted Card must authenticate any user that requests access to any data that is secured as part of the SES platform. Various options for achieving such authentication include validation of card credentials are identify the card owner, local (card-based) authentication against a set of credentials stored on the card, and online authentication against a server-based credential store.

p-0157In one embodiment, the authentication mechanism is accomplished online against an LDAP service that is hosted and controlled as part of the SES platform. Every user must also be linked to a public/private key pair certificate that will identify the user and card uniquely on the SES platform. Hashed or encrypted information on the card must allow the SES platform to identify whether the user authenticating on the platform is the card owner or not.

p-0158The authentication mechanism is managed in the SES controlled environment so that the user directory is not exposed thereby preventing unknown or inactive users from gaining access to the SES platform and eases the management of issuing and revoking credentials. The card itself does also not provide the basis to assume that the user is a valid user or the card owner, so authentication must always take place to use the card.

p-0159Any user that is authenticated must be provided with only those rights and roles that have been granted by SES and by the card owner (if the user is not the card owner). The authentication credentials include a unique user identifier, user password and access role so that the server can identify what type of access requested and whether the user authenticating is the card owner or another user that is trusted and has the permissions to access the card data and the SES platform. The level of access must then restrict what actions the user can perform and what data the user can access.

p-0160Roles-based access to the Trusted Card is managed by the software application (User Access Method). Specifically, user roles are configured in the database on the card that manages what data can be accessed in the database. User roles are also configured on the SES platform back-end and linked to roles stored in the LDAP service.

p-0161The role that a user can assume is determined by the SES platform back-end LDAP service. When a user is authenticated, the user credentials determine whether the user is the card owner or a guest user. A card owner is authorized to perform specific actions that no other user can. If a guest user (any other user accessing a card that does not belong to them) wants to access information on the card, the guest user's credentials (card) must first be paired with the card owner's card. The pairing of cards creates facilitates the granting of access rights by a data owner to a requester. Both parties authenticate themselves on the SES platform to perform the card pairing process and rights are determined based on the pairing configuration in terms of the roles of each of the card holders and the data that the data owner wants to make available.

p-0162The access to data is controlled through the partitioning of data for different roles. The reliance on a software component to filter the access poses a threat and can be manipulated to expose data or allow actions that the card owner never intended. Leaving the data authorization of a user's access to data to the database engine on the card is also susceptible as the database would be accessible to any authenticated user and be exposed to attacks where an authenticated user may attempt to elevate his rights or gain access to the database data in other ways.

p-0163Access to data on the card cannot be determined by the software components or restricted Java database that resides on the card because both would be vulnerable as the Trusted Card operates in a hostile environment. The Trusted Cards is paired to exchange security information that allows an entity that is requesting data to be given the correct access rights by the entity that is the data owner. This requestor and grantor roles can be reversed in scenarios where both parties can be given rights on each others cards.

p-0164Encryption must protect the data that is stored or transmitted using the Trusted Card and SES platform. Options include software-based encryption, and hardware-based encryption (encryption device or embedded encryption). In one embodiment, software-based encryption is used to encrypt data stored on the Trusted Card, on the SES platform back-end and during transmission. A mixture of asymmetric and symmetric encryption algorithms are used with random numbers that have a high level of randomization and are sufficiently large. Embodiments of the Trusted Card hardware have already been standardized without any hardware-based encryption. Should hardware-based encryption become available then the software encryption will still be used as it is often stronger and more versatile than the hard-based encryption options.

p-0165Trusted cards operate over the internet so the communications channel must be secure and encrypt all data that travels “over the wire” to prevent tampering and disclosure or data. A channel is created between the Trusted Card and the SES platform to facilitate all communications.

p-0166The channel is established before any communication takes place as the first communication with the SES platform will typically be the credentials of a user requesting authentication. Transport Layer Security (TLS) is used to establish and maintain a secure and encrypted communications channel for the duration of an active user session. OpenSSL may be used to provide this channel with the use of encrypted user information on the card. Messages transmitted over the secure channel will also make user of message digests (symmetric algorithms) to prevent tampering with the content of the message.

p-0167If the communications channel is not secure and both ends of the channel cannot establish a trusted connection then there is no way to protect the data “over the wire” and ensure that the parties at either end can trust that the data will not be tampered with and is destined for the intended party. TLS/SSL is also a widely used standard and can be trusted to secure the data adequately from any browser or hardware platform.

p-0168The Enforcement Agent, User Access Method and Data Storage system must be capable of functioning on Windows, Linux and Macintosh operating systems. The technologies used for these components must operate on all three environments. The major technologies and standards used in any software on the Trusted Card include JavaSE—The Java Virtual Machine operates on the Windows, Linux and Macintosh operating systems and Java Standard Edition libraries will be used. No operating system dependent libraries are permitted for development of software on the Card.

p-0169HTML is a ubiquitous technology that can be executed on many different browsers and application software. Related technologies such as JavaScript, Cascading Style Sheets and Dynamic HTML are also permitted.

p-0170XML—The use of XML for data structure definition and possible reporting when combined with XSLT are allowed. Certain industry-specific XML libraries will be permitted for compliance, data import, data export or integration.

p-0171JavaDB—All structured data are stored in a database on the Trusted Card. The database engine is a multi-user relational database with a small footprint that runs on JavaSE and JavaEE. Other important features are that the database can operate in an embedded mode or in a stand-alone mode and is fully ACID compliant. It also supports database encryption and crash recovery.

p-0172TrueCrypt—TrueCrypt is a software component for establishing and maintaining an on-the-fly-encrypted volume (data storage device). The software is used to create an encrypted file container on the Trusted Card that will contain the Data Storage system and primary User Access Method. It forms part of the Enforcement Agent system by providing a secure storage area that can only be accessed once the Enforcement Agent activates the TrueCrypt decryption routines on authentication and authorization has been successful. The TrueCrypt software will be shipped with the Trusted Card, in one embodiment, and will run on all required operating systems without requiring any installation.

p-0173The Secure Exchange Solution is highly scalable when accessing the central Authentication Method and Role Allocation as well as when managing Secure Online Transactions. Secure Online Transactions will often exchange data with third-party service providers using system integration. The central Authentication Method and Role Allocation may be hosted by a set of synchronous web services that can be scaled out in a web farm configuration. The Secure Online Transactions are scaled by using a messaging system to queue messages for processing to manage system resources and provide a high level of transaction management and fault recovery.

p-0174The Secure Exchange Solution back-end provides an integration mechanism to third-party service providers or in-house services that are available to the Trusted Cardholder. Integration is implemented using an integration service that can manage message storage, queuing, routing, transformation, rules and multi-channel and multi-format message and data integration.

p-0175The Trusted Card User Access Method also provides a framework for standard authentication and authorization but is also flexible to accommodate different user interfaces for different applications. For example, unique applets can be created for each scenario (e.g. Health scenario, Digital document signing scenario, etc.). In addition, an applet can be created that can run dynamic user interfaces. This is highly flexible but also more complex to build and manage.

p-0176Finally, the Trusted Card has a software update component that is able to download new versions of application software for the Trusted Card. The update component ensures that the software on the Trusted Card is always the latest when executing a Secure Online Transaction.

p-0177<figref idrefs="DRAWINGS">FIG. 10</figref> is a diagram <b>600</b> that provides one possible architectural solution for the trusted card/secure exchange system. The card application <b>602</b> provides functionality for login, running a user interface, reading and writing the data stored on the trusted cards.

p-0178An SES launcher is a trusted card application that provides the initially capability to launch the SES Update Service and any Industry Application on the Trusted Card. The SES launcher application is responsible for identifying the platform that the Trusted Card is running on, calling the appropriate versions of applications for a given platform, and calling the SES Update Service to download application updates.

p-0179A SES Update Service is a service that maintains the versions of the SES and Application software components. The Update service initiates a software component update on a Trusted Card if any software components on the card are outdated when the card is used. The service is responsible for storing major and minor release versions of the software components, detecting the versions of software components installed on a Trusted Card, and initiating the necessary software updates to the Trusted Card.

p-0180A SES security service is a service that maintains the users and roles for the system, including any trust relationships that have been formed between Trusted Cards. The SES security service is responsible for, authenticating Users/Cards, authorizing Users, linking and unlinking Cards (Trust Relationships), maintaining all Users and Roles, and maintaining a link to the SES Certificate Store.

p-0181A SES Certificate Service is a service that maintains the master repository for the security certificates that are used to identify each card and user of the SES system. The SES Certificate Service is responsible for storing all security certificates, providing access to create and maintain the security certificates, encrypting and decrypting data using private and public keys stored in the Certificate Store.

p-0182A SES transaction service validates and signs all transactions and data updates to Trusted Cards. The service is responsible for determining transaction validity, determining transaction authorization, signing transactions, and storing transactions or routing transactions for processing by other external or internal interfaces.

p-0183A SES Integration Service is an infrastructure service in the form of an enterprise service bus (ESB) that provides a platform for other SES Services and for integration with third party service providers. It is responsible for maintaining a service registry, maintaining service on and off ramps, message transformation, message routing and implement service itineraries, and message persistence.

p-0184The Trusted Card Application is an industry implementation that runs on the SES platform. The application will execute a user interface on the Trusted Card that can perform specific transactions and will overlay the SES functionality. The Trusted Card Application interacts with an Industry Application Services that are hosted by SES. The Industry Application Services are specific services that service an Industry Application running on a Trusted Card. The services provide specific industry-based functionality and conform to the SES platform requirements in terms of security, transactions and data storage.

p-0185<figref idrefs="DRAWINGS">FIG. 10A</figref> is a system partitioning diagram that depicts the above described applications as components and their relationship to each other. The infrastructure services have not been depicted and the data stores are considered to be part of the applications, so are not depicted separately.

p-0186A Certificate Authority (CA) is an entity trusted by all parties involved that for the purpose of authentication issues a certificate to a user or a computer whose identity it has already verified so that other users and computers can rely on the authenticity of the certificate holder's identity. Digital certificates contain information about the holder's public key, its expiration date, and the digital signature of the certification authority.

p-0187A Transport Layer Security (TLS) Mechanism is a protocol that is used for establishing a secure connection between a client and a server. TLS is able to authenticate both the client and the server while it creates an encrypted connection between them both. The TLS protocol is extensible which means that new algorithms can be added as long as both the server and the client know about the new algorithms.

p-0188An OpenSSL Mechanism refers to an open source implementation of the SSL and TLS protocols that is available as a library and can be integrated into a custom system.

p-0189<figref idrefs="DRAWINGS">FIG. 11</figref> is a diagram of the security architecture <b>700</b>. The Secure Exchange Solution with the Trusted Card is primarily an enabler of secure transactions. As such the security of the Trusted Card has been layered to provide a public access layer <b>702</b>, a private access layer <b>704</b>, a secure online transactions layer <b>706</b>, and a secure card administration layer <b>708</b>.

p-0190The public access layer <b>702</b> is not controlled by the Trusted Card. Files can also be stored in this space as part of the Trusted Card flash drive file system. The User Access Method will challenge the user for credentials to launch if any actions are requested that require further access.

p-0191In order to gain access to the Private Access layer <b>704</b>, the card user has to be authenticated online with the Secure Exchange. The User Access Method establishes a secure channel for communication to the SES platform and authenticates the user credentials. It is important to note at this stage that the card user is not necessarily the card owner. This data area is encrypted. Personal data that identifies the Cardholder or the forms part of the SES authentication cannot be edited by the Cardholder. The Cardholder password can publish this data into the Public Access area if desired.

p-0192The Secure Online Transactions layer <b>706</b> is accessible when the Cardholder is authenticated online using the Secure Exchange and will also allow read and write access to additional cards with the required access rights that have been authorized by the Secure Exchange in a multi-card scenario. Note that the additional cards must be linked to the card being accessed before any access can be granted to this data area. Secure authorized transactions can be written to this data area and Secure Exchange integration transactions will be initiated where necessary.

p-0193The Secure Card Administration layer <b>708</b> is reserved for administration purposes. The Secure Exchange software and database components may be updated at this level and card-based audit trails, access logs and error logs will be kept in this data area for compliance and security reporting.

p-0194<figref idrefs="DRAWINGS">FIG. 11A</figref> is a depiction of communications channel security which is a process that deals with the establishment of a secure communications channel between a trusted card and the SES platform.

p-0195The web server has a Web Application Firewall (WAF) installed. Web Application Firewalls are often called Deep Packet Inspection Firewalls because they look at every request and response within the HTTP/HTTPS/SOAP/XML-RPC/Web Service layers. Some Web Application Firewalls look for certain attack signatures to try to identify a specific attack that an intruder may be sending, while others look for abnormal behavior that doesn't fit the websites normal traffic patterns. Web Application Firewalls can be either software, or hardware appliances based and are installed in front of a web server in an effort to try and shield it from incoming attacks.

p-0196When the trusted card <b>120</b> is connected to the USB device of the computer, the client application will start. The client application will then access the SES server environment using OPENSSL, configured for using TLS 1.2, via the web. The server will recognize the request and send its public certificate to the client application. The client application will verify this certificate against the Certificate Authority (CA) stored on the smartcard, confirming whether the server is a trusted entity. The client application will also send the card's public certificate to the server where the server will authorize the certificate against the CA on the server to establish if the card is a trusted card.

p-0197Once all these checks are completed a trusted and secure channel will be established between the client app and the SES server. Encryption technology will be configured in OPENSSL and SHA512 will be used as the hashing algorithm and RSA1024 bit will be used for encryption.

p-0198A smart chip will be programmed to write private and public keys once, read public key many times, and will have no read functionality of private keys. Without the Smart Card chip, the system maintains a private key and protects it via software encryption. The private key will be transmitted over the secure channel to the card application once the user has been authenticated.

p-0199Authentication will happen once the trusted channel has been established. The session id and sequence number will be used to do the authentication. The steps for authentication include the server encrypting the SessionID and Sequence number with the user's public key stored in the key store, encrypting the result of the above encryption with the SES private key and sending it to the client application. The client then decrypts the authentication transaction with the SES public key and the SessionID and sequence number are then decrypted with the user's private key.

p-0200The SessionID and sequence number are used in each transaction sent from the card to the server and vice versa. The sequence number is a number generated by the SES system to track all sessions and to check if “replays” happen.

p-0201In regard to authorization, the SES Platform will maintain a database of all paired “linked” cards and the rights that card owners have granted. This configuration can be maintained by a card owner at any time after authenticating and authorizing against SES.

p-0202A secure transaction is any transaction or record update that affects the card owner's data store and can also initiate a transaction to third party service providers. Once the secure channel is established and the authentication has completed, all transactions sent between the card and server will have the make up shown in <figref idrefs="DRAWINGS">FIG. 11B</figref>.

p-0203A magic number is a 32 bit number assigned by SES to use with all transactions. The number is the same for all transactions and is used by the system to identify if the transaction packet is a SES transaction. The magic number is an early checkpoint to check if the transaction is a valid SES transaction. If the magic number is not a SES number the transaction will be ignored.

p-0204The hash algorithm type is an identifier of which algorithm type was used when hashing the file. The hash algorithm gives SES the ability to change the hash algorithm over time and still have the ability to compare hash codes using the specified algorithm type.

p-0205The SessionID is the identifier of the established secure session between the client and server. If transactions are received with different SessionID's than the current established session, the transaction will be identified as an unsafe transaction and ignored.

p-0206All transactions have a transaction code. The transaction code is used to group transactions together and is not to be confused with a transaction identifier.

p-0207Different transaction types used by SES have a unique transaction instruction type identifier. This identifier code is used by the system to know what type of transaction it is expecting and how to handle it.

p-0208Transaction Sequence Number: Each transaction has a sequence number. Sequence numbers are incremented per transaction, per transaction code, thereby ensuring that all transaction packets for a specific code are received and received in sequence. The application will pick up gaps and or duplicate transactions early in the process by validating the sequence number.

p-0209Instruction Issuer: Transactions must be signed by the issuer and the system will need to know the identity of the signatory. The system can then get the signatory's public key from the key store and use this key to decrypt the signed hash code.

p-0210Length of content is the expected number of bytes of the expected content, protecting the system from buffer overruns when receiving transactions. If the length of the received content is more than the specified length, the transaction will be identified as unsafe and ignored.

p-0211The content packet is the metadata that is sent between the client and the application and contains the actual data of the transaction.

p-0212Issuer Signed Hash: Transaction segments, as per <figref idrefs="DRAWINGS">FIG. 11B</figref>, are hashed by using SHA512 or MD6. Hashing is the ability to mathematically reduce a variable length of data into a reproducible fixed length “digest” of that message. The hash string is then encrypted using the issuer's private key and is added to the transaction packet. This encryption acts as the signature of the transaction and cannot be decrypted by anyone other than the issuer.

p-0213SES Signed Hash is an additional hash stringed signed by the issuer using SES's public key. This hash string will then be decrypted by SES, using the SES private key, and the validity of transaction content will be checked using the SES Signed hash.

p-0214The architecture in terms of data storage is to create multiple containers of data that are related to a trusted relationship between the card owner and any other user with which the card owner interacts. The concept is that each trusted user will have a container that holds transactions and data updates (documents) generated by that trusted user. Containers records can only be appended, never edited or deleted so each record will be treated as immutable (unalterable) providing verifiable, trusted and reputable proof of a transaction. A master container which is only editable by SES will consolidate specific data updates and transactions to create a view of the data that is applicable to the software application that is being used by the Trusted Card.

p-0215The Trusted Card data storage and access mechanism is depicted logically in <figref idrefs="DRAWINGS">FIG. 12</figref>. There is a single Master container (Cardholder container <b>802</b>) that can only be updated by the SES platform and contains all available data elements. The card owner is the only user that can access all information in the Master container and the SES user is the only “user” (key) that can write data to the Master container.

p-0216When Trusted Cards are linked, the card owner forms a trust relationship with another trusted cardholders. The card owner determines what data can be read. The access rights that a card owner provides to another trusted card is stored and configured on the SES platform back-end <b>810</b>. A separate protected and trusted container <b>822</b>, <b>824</b>, <b>826</b>, and <b>828</b> is created for each trusted card user and allows only that user to write to the container and therefore created verifiable and digitally signed records.

p-0217All records written to a secure container are published to the SES platform back-end <b>810</b>. The SES platform determines whether the record must be written to the Cardholder store to form part of the card owner's master data and/or execute a third-party service (like billing, claims, etc.). The SES platform also creates required cryptographic hashes to allow the necessary users to read the data from the Cardholder master container and sign all records that have been entered with the SES platform key. The SES platform maintains the cryptographic hashes of all containers to detect tampering with any of the containers but will not store any data other than transaction data that must be audited.

p-0218The containers also contain images and media files that are signed by the trusted user to verify authenticity. Media files will not be copied into the Master container and will always be referenced from the Master container using a media index. This ensures that the flash memory space is not wasted and that media files can be accessed quickly through the index. The index can be maintained in a database.

p-0219In one embodiment, the W3C XAdES standard is used to form the containers and store the documents in a standards-based format. Each record or transaction that is enacted will result in a document that will form the record for that transaction. The standard provides the basis for digitally signing each document and ensuring non-repudiation of the document transaction.

p-0220Data on the trusted card are stored encrypted using a symmetric key generated by both the SES key generator and a client key generator. Additional data are stored with the encrypted metadata in order to identify the different records as shown in <figref idrefs="DRAWINGS">FIG. 12A</figref>.

p-0221For each record in the data table there will be at least one corresponding record in the key store table. These records are linked using the unique transaction id. The record in the key store contains the encryption type, proxy certificate fingerprint and the encrypted symmetric key that was used to encrypt the transaction in the data table. The encryption type field is used to know which encryption to use when decrypting the symmetric key. The proxy certificate fingerprint is the public key fingerprint of the entity that can decrypt the symmetric key. The symmetric key is encrypted using the proxy's public key and stored in the key store. Only an entity with that specific public/private key can decrypt the symmetric key which in turn will be used for decrypting the transaction.

p-0222If the card owner wants to give an entity (proxy) access to a specific record the system uses the card owner's public key to decrypt the saved symmetric key. This symmetric key is then be encrypted using the proxy's public key. A new record will be added to the key store with the transaction id and the relevant details of the proxy as well as the newly encrypted symmetric key. When the proxy reads the data he can use his own private key to decrypt the transaction and thus he can read the transaction.

p-0223This configuration provides the basis for digitally signing each document and ensuring non-repudiation of the document transaction. Additional standards such as XAdES for data storage can be applied but are not necessary to achieve digital signing.

p-0224With regard to data architecture, the above described solution contains several data sources that must be managed on the trusted card and on the back-end SES platform. The data sources are listed in Table 1 with a short description of each

p-0225<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="98pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="35pt" align="left" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry /><entry>SES/Industry</entry><entry /></row><row><entry /><entry /><entry>Application</entry></row><row><entry>Data Source</entry><entry>Description</entry><entry>specific</entry><entry>Location</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Card Application Records</entry><entry>Data records and media stored</entry><entry>Application</entry><entry>Card</entry></row><row><entry>Database</entry><entry>specifically by the Industry</entry></row><row><entry>(Structured/Unstructured)</entry><entry>Application, such as personal</entry></row><row><entry /><entry>data, images, videos.</entry></row><row><entry>Card Application</entry><entry>Metadata for all encrypted</entry><entry>SES</entry><entry>Card</entry></row><row><entry>Transaction Database</entry><entry>data and a pointer to the data</entry></row><row><entry /><entry>record or data item (if</entry></row><row><entry /><entry>unstructured)</entry></row><row><entry>Card Application Key</entry><entry>Stores encrypted symmetric</entry><entry>SES</entry><entry>Card</entry></row><row><entry>Store</entry><entry>keys that act as pointers to the</entry></row><row><entry /><entry>Card Application Transaction</entry></row><row><entry /><entry>Database.</entry></row><row><entry>Card Application Master</entry><entry>Master Data that is used by</entry><entry>Application</entry><entry>Card</entry></row><row><entry>Database</entry><entry>the Industry Application on the</entry></row><row><entry /><entry>Trusted Card (e.g.</entry></row><row><entry /><entry>ICD10/Tariff, etc.)</entry></row><row><entry>SES Integration</entry><entry>Transactions that are</entry><entry>Application</entry><entry>SES</entry></row><row><entry>Transaction Database</entry><entry>generated by SES and routed</entry></row><row><entry /><entry>to 3^rdparty providers for</entry></row><row><entry /><entry>processing.</entry></row><row><entry>SES Transaction Metadata</entry><entry>Records all metadata for</entry><entry>SES</entry><entry>SES</entry></row><row><entry>Database</entry><entry>transactions that are processed</entry></row><row><entry /><entry>through SES.</entry></row><row><entry>SES Master Database</entry><entry>Master Data database stored</entry><entry>SES</entry><entry>SES</entry></row><row><entry /><entry>at SES and drives business</entry></row><row><entry /><entry>rules, integration and acts as a</entry></row><row><entry /><entry>source for synchronizing the</entry></row><row><entry /><entry>Card Application Master</entry></row><row><entry /><entry>Database.</entry></row><row><entry>SES Audit Database</entry><entry>An audit database that records</entry><entry>SES</entry><entry>SES</entry></row><row><entry /><entry>all auditable data items and</entry></row><row><entry /><entry>stores them for further</entry></row><row><entry /><entry>investigation.</entry></row><row><entry>SES Synchronization</entry><entry>Versions/Release Packages.</entry><entry>SES</entry><entry>SES</entry></row><row><entry>Database</entry><entry>May also retain interim data</entry></row><row><entry /><entry>for master data</entry></row><row><entry /><entry>synchronization.</entry></row><row><entry>SES Certificate Database</entry><entry>Database for private and</entry><entry>SES</entry><entry>SES</entry></row><row><entry /><entry>public key certificate pairs</entry></row><row><entry /><entry>and any</entry></row><row><entry>SES Security Database</entry><entry>Stores all users, groups, roles</entry><entry>SES</entry><entry>SES</entry></row><row><entry /><entry>and privileges. It also stores</entry></row><row><entry /><entry>the trusted relationships</entry></row><row><entry /><entry>(paired cards) with their</entry></row><row><entry /><entry>relevant privileges.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0226<figref idrefs="DRAWINGS">FIG. 12B</figref> is a diagram illustrating one embodiment of a trusted card logical data model which illustrates the relationships between the various logical data sources contained on the Trusted Card <b>120</b>. The example data used is that of a Personal Health Record (PHR). The sources depicted in <figref idrefs="DRAWINGS">FIG. 12B</figref> include a card application key store, a card application transaction database, a card application records database, and a card application master database.

p-0227The card application key store and contains records of certificates that are capable of decrypting the protected card application records. The certificate thumbprint is used to uniquely identify the certificate, and thus the card user, that can decrypt the data. The key store record is related to the transaction by the unique TransId.

p-0228The card application transaction database includes records that contain metadata for a specific entry into the card application records database. The metadata stored in the transaction data store are used for identifying, filtering and searching of entries in the card application records database without decrypting the records. Metadata that must be searchable from the application must be promoted to the metadata level. Every record in the card applications records database will be linked to a transaction by using the unique TransId.

p-0229The card application records database contains the content records for any structured or unstructured data that is stored on the trusted card. The content is encrypted and linked to the card application transaction database via the TransId.

p-0230The card application master database contains master data that is used to run the card application. Master data references can be stored as part of records stored in the card application records database. This database is synchronized with master data from SES.

p-0231The key data elements are described in Table 2 which follows:

p-0232<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="119pt" align="left" /><thead><row><entry namest="1" nameend="3" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Data Source</entry><entry>Data Element</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Card Application Key Store</entry><entry>TransId</entry><entry>Transaction id of the record. Linked to</entry></row><row><entry /><entry /><entry>the Transaction table.</entry></row><row><entry>Card Application Key</entry><entry>Encryption Type</entry><entry>Type of encryption used to encrypt the</entry></row><row><entry>Store</entry><entry /><entry>record.</entry></row><row><entry>Card Application Key</entry><entry>Proxy Certificate</entry><entry>Thumbprint of the certificate used to</entry></row><row><entry>Store</entry><entry>Thumbprint</entry><entry>encrypt the symmetric key. This is to</entry></row><row><entry /><entry /><entry>identify the certificate.</entry></row><row><entry>Card Application Key</entry><entry>Encrypted</entry><entry>This contains the symmetric key used</entry></row><row><entry>Store</entry><entry>Symmetric Key</entry><entry>to encrypt the record content. The</entry></row><row><entry /><entry /><entry>symmetric key is encrypted using the</entry></row><row><entry /><entry /><entry>proxy entity's certificate.</entry></row><row><entry>Card Application</entry><entry>Id</entry><entry>Unique transaction id used to identify</entry></row><row><entry>Transaction Database</entry><entry /><entry>transactions and links to PHR data</entry></row><row><entry /><entry /><entry>records.</entry></row><row><entry>Card Application</entry><entry>Type</entry><entry>This is used to filtering and searching</entry></row><row><entry>Transaction Database</entry><entry /><entry>of PHR records. It contains the</entry></row><row><entry /><entry /><entry>transaction type e.g. Doctor Visit.</entry></row><row><entry>Card Application</entry><entry>DateTime</entry><entry>Date and time at which the transaction</entry></row><row><entry>Transaction Database</entry><entry /><entry>occurred</entry></row><row><entry>Card Application</entry><entry>MetaData</entry><entry>Metadata used to search and filter the</entry></row><row><entry>Transaction Database</entry><entry /><entry>records.</entry></row><row><entry>Card Application</entry><entry>Signed Hash</entry><entry>Hash of the transaction signed by SES.</entry></row><row><entry>Transaction Database</entry><entry /><entry>This will be used to identify if a record</entry></row><row><entry /><entry /><entry>has been tampered with.</entry></row><row><entry>Card Application</entry><entry>Encrypted?</entry><entry>Boolean to identify if the transaction is</entry></row><row><entry>Transaction Database</entry><entry /><entry>encrypted.</entry></row><row><entry>Card Application</entry><entry>TransId</entry><entry>Transaction id of the PHR transaction.</entry></row><row><entry>Records Database</entry><entry /><entry>Linked to the Transaction table.</entry></row><row><entry>Card Application</entry><entry>Data Record</entry><entry>Content relevant to the specific PHR</entry></row><row><entry>Record Database</entry><entry /><entry>element. This will be elaborated on in</entry></row><row><entry /><entry /><entry>the database design phase.</entry></row><row><entry>Card Application</entry><entry>Data Record</entry><entry>Content relevant to the specific Meta</entry></row><row><entry>Master Database</entry><entry /><entry>Data element. This will be elaborated</entry></row><row><entry /><entry /><entry>on in the database design phase.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0233<figref idrefs="DRAWINGS">FIG. 12C</figref> depicts the relationships between the various SES data elements that are used for authentication and authorization and is referred to as a SES security database logical data model. These elements form part of the SES security service that is maintained centrally. The elements depicted in <figref idrefs="DRAWINGS">FIG. 12C</figref> include cards, user cards, links, roles, and privileges. A card is a record containing the details of a physical card. A user card can be a patient card or a doctor (provider card. The patient card represents the records of a patient and is linked to roles associated with the specific user type. The doctor card includes the record of a doctor and is linked to roles associated to the specific user type. Links are the specific privileges that are granted to a proxy user. These can be via roles or specific privileges. Roles are a hierarchal grouping of privileges and are linked to a user type. Privileges are the lowest level functions a user can perform on the card application.

p-0234The relationships between these logical data elements, in the medical context utilized herein are described. With respect to cards, and user cards, every card is associated to a user. A user can be registered to more than one card. A card can only be registered to one or no users. With respect to patient and doctor, when a trusted relationship has been setup between cards, and therefore the users that holds the card, a set of privileges will be associated to the link. These privileges determine the functions that can be performed on the patient card by the proxy user. The privileges are inherited from the privileges assigned to roles of the proxy user. The patient card holder can then alter these privileges if required.

p-0235The Physical Trusted Card

p-0236The above-described secure USB business and/or personal ID card (trusted card <b>120</b>) bears full-color external text and/or graphics, including a unique two- or three-dimensional barcode applied by an image transfer printed by modified large-format digital printer. The transfer is applied by a selective release transfer process in which the adhesive layer attaches only in the image area to the target surface and the adhesive layer is peeled off except for the image area which is left attached to the target surface. This produces a high-resolution four color graphic inclusive of white, which is used to apply the three-dimensional barcodes at potential volumes of upward of 200,000 per day. It is envisioned that the USB business and/or personal ID card may contain any combination of: the name or logo of the company; office address, individual name, telephone numbers, fax, and email address. The opposite side of the card could contain pertinent information concerning its use or other promotion materials. This card could be used as an identity card, driver license, insurance card, financial services card, credit card, prescription drug cards, Medicaid card, and Internet transaction card. The outside of the card could contain: a bar code, including two and three dimensional codes; a photograph; and other biometric information that can be printed on the outside of the card.

p-0237As such the present disclosure includes the digitally-printed transfer bearing a digitally created image that can be heat and/or pressure-applied to a target surface, and a method for transferring the digitally created images from film to a target surface via digital printing and heat and/or pressure transfer. The process employs a modified digital printer (converted from a double sided fusing printing process to a back fusing web printing process) to create an image on transfer film subsequently coated with adhesive that is then heat and/or pressure-applied to a substrate to yield a high-resolution four color graphic with white. The basic fabrication steps comprise 1) coating one side of a disposable base transfer film (or carrier) with a releasable coating; 2) digitally printing one or more images overtop the base transfer film in reverse-image format; and 3) applying an adhesive coating over the image.

p-0238The result is a roll of pre-printed transfers. In accordance with the present method for transferring the digitally created images from film to a target surface, 4) the base transfer film is indexed over a target substrate (image down and showing through the film) and heat and/or pressure is applied to the base transfer film to adhere the image to the target substrate. The base transfer film is peeled from the target substrate and is discarded, leaving a high-resolution color graphic image on the target substrate.

p-0239The method is described in detail below with various options, and in all cases the method is unique because when the image is transferred there is “selective release”, meaning that there is transfer to the target substrate only in a pre-determined area (most commonly in the specific area of the print image, though for some applications it may be desirable to have a release that includes non-imaged areas), despite the adhesive coating which may, and indeed, usually exceeds the borders of the printed image. This selective release improves the quality of the transfer because there are no unsightly borders or margins around the image, and holes and gaps in fairly complex images are not filled in.

p-0240<figref idrefs="DRAWINGS">FIG. 13</figref> is an exploded diagram showing the layers of an exemplary image transfer <b>1000</b>. The image transfer <b>1000</b> includes a disposable base transfer film <b>1002</b>. T his can be any suitable transfer carrier formed of plastic or non-woven material and that is capable of being passed as a web through the production machinery. For example, the presently preferred transfer film <b>1002</b> is polyester teraphthlate (PET). In accordance with one optional feature, the transfer film <b>1002</b> may be preformed with distinct surface patterns or texture to give the final transfer a textured aesthetic.

p-0241An image release layer <b>1004</b> is uniformly applied onto the base transfer film <b>1002</b>. Image release layer <b>1004</b> may be, for example, a wax, lacquer, or combination of wax and lacquer, with or without specific additives. The application of the image release layer <b>1004</b> may be attained by applying the wax and/or lacquer onto the base transfer film II in individual coats from either solvent or waterborne solutions or suspensions. It is known from experience that the final parameters of the coating can be adapted to any requirement by the changing coating weights, the addition or substitution of resins, waxes and wax solutions, and there are many conventional coating methods that can be used to achieving a desired coat weight. The appearance of the final coating can be full gloss or be matted down to the required level by the addition of matting agents. When applied the release layer <b>1004</b> must be uniform, and free from all coating defects and application patterns (except where a coating pattern is an intended aspect). The presently-preferred release layer <b>1004</b> comprises a lacquer mixture of commercially available polymethyl methacrylate resin with a commercially available wax suspension (BYK 151 ex-Samual Banner). The ratio of resin to wax is on the order of 80% to 95% resin to 5% to 20% wax. These two components are provided in a 5% to 15% solid solution (depending on method of application) in a butanone and toluene solvent blend (of which toluene is around 10% of the total solvent). The release layer coating is then forced air-dried giving a dry coat weight coat weight of 1.15 to 1.35 grams per square meter.

p-0242The image <b>1006</b> itself is then digitally printed with a four color graphic (as will be described) on the transfer film <b>1002</b> (overtop release layer <b>1004</b>). The digital printer may employ either electro-ink or dry powder toner, and otherwise conventional print techniques. Preferably, a registration mark is printed at this same time, and when desired the four-color image <b>1006</b> (and registration mark) is then overprinted with a white background <b>1008</b>.

p-0243Finally, a pressure and/or heat activated adhesive layer <b>1010</b> may be applied evenly over the whole of the web, both where there is image and no image, or may be selectively applied only in the image area. Presently, the adhesive layer <b>1010</b> is applied in line directly after the printing step using a 3.5% to 4% solution of commercially available polyamide (Lioseal V 7036 ex-Henkel) in a solvent system, which is predominately Isopropyl alcohol. This solution is then coated onto the image <b>1006</b> and/or transfer film <b>1002</b> by a wire wound rod at a dry coating weight of 0.2 to 0:3 grams per square meter, the applied coating being forced air-dried.

p-0244To then transfer the digitally created image from the transfer film <b>1002</b> to a target surface, the base transfer film <b>1002</b> is placed on a target substrate and is indexed in position using the index lines (image down and showing through the film). The adhesive layer is then heat and/or pressure-fused to a subject material and the image itself <b>1006</b> adheres more strongly to the material than does the image release layer <b>1004</b>. Thus, when the image transfer film <b>1006</b> is applied image-down to a target substrate by application of pressure and/or heat (as will be described), the dried adhesive layer <b>1010</b> attaches to the target substrate only in the image <b>1006</b> area but is otherwise retained by the transfer film <b>1004</b> (“selective release”). To then apply the transfer <b>1000</b>, the image transfer film <b>1002</b> is peeled off the target substrate together with the dried adhesive layer <b>1010</b> except for the image area which is left attached to the target substrate by the pressure and/or heat activated adhesive layer <b>1010</b>. For this to happen, the thickness of the non-printed areas of release layer <b>1004</b> and adhesive layer <b>1010</b> must be thinner than printed areas containing the release layer <b>1004</b>, image <b>1006</b> and adhesive layer <b>1010</b> such that more pressure is exerted where there is image to the target substrate than where there is no image. The characteristics of the image release layer <b>1006</b>, the adhesive layer <b>1010</b> and the image layers <b>1006</b>, <b>1008</b> are selected so as to work with a wide variety of target substrates, including textured and porous materials such as leather to give this selectivity.

p-0245<figref idrefs="DRAWINGS">FIG. 14</figref> is a block diagram of all necessary process steps for making and applying the above-described transfer <b>1000</b>.

p-0246Step 1: Modify Digital Printer

p-0247This printer can be any conventional digital printer that uses either Electrolnk™ or dry powder toner, or other conventional print techniques. For example, a Xeikon™ large format digital printer is suitable. This and most other large format digital printers employ heater roller assemblies and fusers generally contained within a protective housing. A toner image is transferred to a sheet or web and is then fixed to the web by heat and/or pressure. Typically the paper is transported in a nip between the fuser and pressure roller, which are rotating. Thermal radiation from a lamp heats the fuser roller, causing the toner on the web to melt and press into—the web fibers. In accordance with one embodiment, the printer is modified to essentially convert it from a front and back fuser system to a back fusing web printing process. The modification initially entails disabling the heaters in the infeed module removal of the front fusers (substep <b>1102</b>) and removal of the GEM rollers <b>1104</b>. Specifically, for a Xeikon digital printer, the front fusers and part nos. CNS-1262-01 5208 32D (Gem Roller) would be removed as seen in <figref idrefs="DRAWINGS">FIG. 15</figref>. In addition, the print color order is changed from the conventional CMYK to KMCY.

p-0248Step 2: Prepare Web

p-0249The current process uses a plastic web in roll form for the base transfer film <b>1002</b> of <figref idrefs="DRAWINGS">FIG. 13</figref> and pre-coats this with the release layer <b>1004</b> which may be a releasing lacquer, a wax, a release coating, or a combination of any of these as described above. At substep <b>1110</b> it is necessary to mix the releasing layer (lacquer, wax, coating, or combination of any of these). The lacquer, wax and release coating are custom-mixed to create the correct release factor for a range of heat and pressure used. A suitable wax release can be mixed with a combined acrylic nitrocellulose overlacquer for this purpose.

p-0250If desired, the release layer <b>1004</b> may be texturized or mixed with specific additives, such as UV absorbers or biocides, to give the release layer specific properties.

p-0251For example, the release layer <b>1004</b> may be texturized with a distinct carrier surface pattern (matte or scratch). Since the image is printed onto the release layer <b>1004</b> and is then transferred, the net effect is to impart the surface pattern onto the surface of the transfer. Most any texture or pattern that can be made to the surface of the release layer <b>1004</b>, for example, embossing, etching or addition of a solid component, e.g. silica. In each case this is transferred when it is applied to the target substrate. These changes can be aesthetic for example, matte, brushed effect, geometric pattern, regular pattern or random pattern. The effect can also be subtle such as wording, images or patterns that are only visible with light shining on the surface at a particular angle, thereby serving as a simple security device.

p-0252As another example, the release layer <b>1004</b> may contain a functional additive that confers a property to the transfer <b>1000</b> that is not present in the transfer without the additive. For example the addition of 1% of an anti-microbial additive such the transfer surface as applied to a target will inhibit bacteria. Inorganic, silver-based antimicrobials are generally recognized as safe and are well suited for this purpose.

p-0253The addition of a small percentage (less than 10%) of a UV absorber will protect the toner image from degradation in color intensity due to prolonged exposure to direct sunlight.

p-0254The addition of a phosphorescent or fluorescent additive will make the transfer “glow” when UV light is shined onto it. This addition can be used in conjunction with the above-described surface pattern, making the effect easier to detect.

p-0255Step 3: Prepare Image

p-0256The image is designed into a vector image file, or scanned into a raster image file, in both cases using four color CMYK pixilation. As seen at substep <b>1120</b>, the emblem graphic design may be generated using computer drawing software. This is generally accomplished using graphics programs such as well-known Adobe Illustrator™, Photoshop™, etc. Such software is capable of calculating the image dimensions from the design, and colors are chosen from a selectable palette. Photoshop software developed by Adobe uses a palette technique in which the image data is coded and compressed to a prescribed number of colors (a range of from 256 to 16M colors depending on the selected palette). The image file can be manipulated as desired to resize/rescale, redraw or alter the coloration. The final image is then saved as a CMYK raster image file.

p-0257Step 4: Print Image

p-0258Given a prepared image, at substep <b>1130</b> the image is printed directly from the raster image file and at substep <b>1140</b> an additional toner drum of white toner (W) is used to print a white overprint. The process imprints electrostatically charged toner or inkjet images onto the base transfer film <b>1002</b>. The process prints the desired image, laying on colors in registration patterns in the order Black, Magenta, Cyan, Yellow (KMCY), and finally White, instead of the CMYK patterns that are applied by an unmodified Xeikon. The printing of a white layer of color at substep <b>1140</b> is unique to the disclosed embodiments and this improves contrast by filling in blank areas. When working on the design computer white is seen as black. White cannot be seen on the screen. The black image (the part we want to be white) is given a specific reference, for example, pantone. This specific reference number is added as a 5th color that the Xeikon combines with the normal CMYK colors of the design, and yet printing this reference color as white as it has been programmed to do.

p-0259Step 5: Apply Release Layer

p-0260Next, at step 5, the mixed release layer <b>1004</b> is applied to the plastic transfer film <b>1002</b>. The release layer <b>1004</b> is applied over the whole surface of the base transfer film <b>1002</b> using a conventional coating machine.

p-0261Step 6: Apply Adhesive

p-0262At step 6 a water or solvent based adhesive is applied over both the image (with nor without white) and the areas that do not contain a printed image. These areas may include parts of the image that have intentionally been left clear of print for example between numbers, backgrounds to let the substrate be seen through the print, etc. The transfer <b>1000</b> is now complete.

p-0263Step 7: Apply Finished Transfer <b>1000</b>

p-0264Finally, at step 7, the image transfer <b>1000</b> may be applied to a wide variety of materials including rough and/or porous materials such as leather. At substep <b>1150</b>, the image <b>1006</b> may be transferred to the substrate material by a roller-to-substrate process, or through a heat-stamping process, in both cases using conventional presses. In both cases the differential pressure of the transfer film <b>1002</b> with toner versus the transfer film <b>1002</b> without toner is the factor that controls the selective release according to the described embodiments. More specifically, at substep <b>1160</b> the dried adhesive on the printed area of the image <b>1006</b> encounters more pressure due to the additional thickness added by the toner, and thus the printed areas of image <b>1006</b> attach to the target material. After the transfer film <b>1002</b> contacts the target substrate, the transfer film <b>1002</b> may be peeled away. The printed image <b>1006</b> transfers to the target substrate as the web separates. The adhesive on the printed area attaches to the target surface and pulls the printed image off the transfer film <b>1002</b> and onto the target substrate. The process does not leave a “lacquer halo” around the printed images as in conventional transfer processes.

p-0265Where a heat-stamping process is used, the stamping press may be used a second time directly onto the transferred image to imbed the printed image into the selected substrate.

p-0266This differential pressure is obtained by the difference in thickness between the areas of the film that are imprinted with the image <b>1006</b> and areas where there is no image. Although it is imperceptible to the naked eye, the transfer <b>100</b> is thicker in the areas where the toner has been applied. The image is transferred selectively through the interaction of the release layer, image and adhesive and the target substrate. The release layer and adhesives being specifically formulated to exploit this differential pressure.

p-0267<figref idrefs="DRAWINGS">FIGS. 16-23</figref> are provided to describe alternative embodiments for providing the trusted card/secure exchange system whose functionality has been described herein. Specifically, <figref idrefs="DRAWINGS">FIG. 16</figref> illustrates a secure file <b>1240</b> that could be utilized with the distributed information protection and control system of <figref idrefs="DRAWINGS">FIG. 6</figref>. For purposes of the following paragraphs, secure file <b>1240</b> is equivalent to secure file <b>390</b> described with respect to <figref idrefs="DRAWINGS">FIG. 6</figref>. The secure file <b>1240</b> includes a header section <b>1310</b> and a payload section <b>1320</b>. Conceptually, the secure file <b>1240</b> is a container in which files are placed for safekeeping, where the header section <b>1310</b> contains the information describing how the secure file <b>1240</b> is assembled, and the payload section <b>1320</b> contains the actual information being protected.

p-0268The header section <b>1310</b> includes a secure file identification <b>1312</b>, a security policy namespace <b>1314</b>, a version <b>1316</b>, and a manifest <b>1318</b>. The secure file identification <b>1312</b> includes a quasi-unique identifier to identify the secure file <b>1240</b> without relying upon any operating system specific attributes (e.g., file name). Conventional techniques to generate a quasi-unique identifier include, for example, generating a sufficiently large pseudo random number which may be used as a quasi-unique identifier; issuing sequentially numbered identifiers from some agreed upon location; and generating identifiers in a relational database.

p-0269The security policy namespace <b>1314</b> includes an identifier specific to the security policy tinder which the secure file <b>1240</b> is being managed. Conventional techniques to assign such an identifier include, for example, using the fully qualified domain name of security policy server <b>354</b>, expressed as a string of ASCII characters; and the distinguished name (DN) of an LDAP entry within the directory service <b>352</b>.

p-0270The version <b>1316</b> identifies the revision level of the format for the secure file <b>1240</b>. Conventional techniques to identify the revision level include, for example: a pair of numerical values expressing a major and minor revision number; and the URL of a formal extensible markup language (XML) data type definition (DTD) describing the format of the secure file <b>1240</b>.

p-0271The manifest <b>1318</b> provides details of the payload section <b>1320</b> and includes one or more manifest records <b>1330</b>, where each manifest record <b>1330</b> further describes a payload <b>1340</b> present in the payload section <b>1320</b>. Each manifest record <b>1330</b> in the manifest <b>1318</b> corresponds to a specific payload <b>1340</b> in payload section <b>1320</b>. For the exemplary secure file <b>1240</b>, the manifest <b>1318</b> includes four manifest records <b>1330</b>, where the first manifest record <b>1330</b> corresponds to the directive payload <b>1322</b>, the second manifest record <b>1330</b> corresponds to the primary payload <b>1324</b>, the third manifest record <b>1330</b> corresponds to the ancillary payload <b>1326</b>A, and the fourth manifest record <b>1330</b> corresponds to the ancillary payload <b>1326</b>B.

p-0272<figref idrefs="DRAWINGS">FIG. 17</figref> illustrates a manifest record <b>1330</b>. There is one manifest record <b>1330</b> for each payload <b>1340</b> in the payload section <b>1320</b> of a secure file <b>1240</b>. Each manifest record <b>1330</b> includes an offset <b>1332</b>, a descriptor <b>1334</b>, a security label <b>1336</b>, and one or more crypto keys <b>1338</b>.

p-0273The offset <b>1332</b> includes offset pointers and other bookkeeping attributes useful for randomly accessing individual blocks of information the payload section <b>1320</b> associated with the manifest record <b>1330</b>. Information maintained within offset <b>1332</b> may be advantageously used with information maintained within the crypto-keys <b>1338</b>, thus permitting this same random access to encrypted payloads <b>1340</b> in the payload section <b>1320</b>.

p-0274The descriptor <b>1334</b> is used to at least differentiate between different types of payloads <b>1340</b> in the payload section <b>1320</b> (e.g., a directive payload <b>1322</b>, a primary payload <b>1324</b>, and an ancillary payload <b>1326</b>A, <b>1326</b>B), and may also include additional descriptive information specific to the payload <b>1340</b>. The descriptor <b>1334</b> can include, for example, the same types of file-type information that are conventionally associated with files, or other types of file-system specific information were associated in the file from which the payload <b>1340</b> originated at the time when the secure file <b>1240</b> was created. Such file-type information can include, for example: a file name, a file extension type, a creation date, size of the file, and a character encoding method (e.g., unicode, utf/8, iso latin 1).

p-0275The security label <b>1336</b> includes an encoded representation of a security label <b>1460</b> (in <figref idrefs="DRAWINGS">FIG. 19</figref>) associated with the corresponding payload <b>1340</b> in the payload section <b>1320</b>. The security label <b>1336</b> can be cryptographically protected (e.g., digitally signed and/or encrypted).

p-0276The crypto keys <b>1338</b> include the cryptographic information used to encrypt the secure file <b>1240</b>. Examples of information contained in the crypto keys <b>1338</b> include: cipher modes, cipher keys, public keys, private keys, and PKI certificates. In various embodiments, some or all of the cryptographic information may be advantageously stored in other locations (e.g., a smartcard or FIPS-140 type device connected to information system <b>200</b>), and the crypto keys <b>1338</b> contain one or more pointers or references to this remotely stored information. Crypto keys <b>1338</b> may themselves also be encrypted and protected, using any number of conventional ways used to protect similar types of cryptographic information.

p-0277A frequent problem associated with many prior art cryptographic implementations is the requirement to decrypt the entire cipher text of a file in order to access just a small section of the plaintext. Just as most operating systems permit quasi-random access to a block within a given file, the described embodiments advantageously provide a technique for the enforcement agent <b>378</b> to access and decipher any arbitrary payload block (e.g., <b>1341</b>, <b>1342</b>, <b>1343</b>, <b>1344</b>, or <b>1349</b>) of a payload <b>1340</b> in the payload section <b>1320</b> that may be encrypted. More specifically, the use of blocks cipher modes that allow cryptographic operations to be performed on arbitrary blocks within a secure file <b>1240</b> is permitted, thus permitting random-access cryptologic operations to the underlying clear text in each payload <b>1340</b> within payload section <b>1320</b>. This capability is the so-called random-access property associated with some block cipher modes. For example, cipher block chaining mode (CBC) ciphers permit parallelizable decryption, thus permitting random-access read operations to a file, and electronic code book (ECB) mode ciphers permit parallelizable encryption and decryption, thus permitting random-access read and write operations to a file.

p-0278Referring back to <figref idrefs="DRAWINGS">FIG. 16</figref>, the payload section <b>1320</b> includes zero or more directive payloads <b>1322</b>, a primary payload <b>1324</b>, and zero or more ancillary payloads <b>1326</b> (illustrated as ancillary payload #1<b>1326</b>A, . . . , ancillary payload #N <b>1326</b>B).

p-0279The directive payload <b>1322</b> can include a security directive record <b>1410</b> (<figref idrefs="DRAWINGS">FIG. 19</figref>) associated with a security label <b>1460</b> (<figref idrefs="DRAWINGS">FIG. 19</figref>). The security label <b>1460</b> can be, but need not be, the security label <b>1336</b> associated with the manifest record <b>1330</b> of payload <b>1340</b>. The directive payload <b>1322</b> can be cryptographically protected. To facilitate the enforcement of the security policy, the enforcement agent <b>262</b> provides the contents of the directive payload <b>1322</b> to the security policy broker <b>384</b>. The security policy broker <b>384</b> can obtain information directly from other authoritative sources (for example, the security policy server <b>354</b> and/or the directory service <b>352</b>) to ascertain if the directive payload <b>1322</b> remains current, and to verify the accuracy of any digital signature(s) associated with directive payload <b>1332</b>, if present. The payload section <b>1320</b> can include multiple directive payloads <b>1322</b> in various embodiments, for example, one directive payload <b>1332</b> for primary payload <b>1324</b> and all ancillary payloads <b>1326</b>, one directive payload <b>1332</b> corresponding to each primary payload <b>1324</b> and ancillary payload <b>1326</b>, and zero or more directive payloads <b>332</b> corresponding to one or more primary payloads <b>1324</b> and any ancillary payloads <b>1326</b>.

p-0280The primary payload <b>1324</b> contains the exact same information contained in file <b>394</b> to be protected and controlled. The primary payload <b>1324</b> can also contain information generated by the user to be protected and controlled. The primary payload <b>1324</b>, as with the directive payload <b>1322</b> and ancillary payloads <b>1326</b>, may be cryptographically protected (e.g., digitally signed and/or encrypted).

p-0281The ancillary payloads <b>1326</b> contain other types of information associated with the file <b>394</b>, or other information, to be protected and controlled. Each ancillary payload <b>1326</b> is composed of an ordered sequence of bytes, characters, or other atomic elements of storage in a fashion similar to that of the primary payload <b>1324</b> and utilizes the same storage semantics dictated by the underlying file system. Ancillary payloads <b>1326</b> can also be used to distribute the information to be protected across multiple payloads, thus permitting different security directives to be associated with different sections of the secure file <b>1240</b>. For example, if a file <b>394</b> to be protected is composed of both text and images, the text can be placed in the primary payload <b>1324</b> and assigned one security label <b>1336</b>, and the images can be placed in one or more ancillary payloads <b>1326</b> and assigned the same and/or other security labels <b>1336</b>. By way of example, this flexibility permits the invention to protect the contents of a complex HTML file composed of multiple MIME blocks by distributing each of the MIME blocks into their own ancillary payloads <b>1326</b> within the secure file <b>1240</b>.

p-0282Advantageously, this capability could also be used to apply security labels <b>1336</b> and security directives to elements of information more granular than that of an entire file <b>394</b>, allowing each element to be protected and controlled differently. Examples of such information elements include subsections of files, linked or embedded objects within a file, storage allocation within databases (e.g., tables, rows, columns, and cells), or any other addressable element of digital or digitized information. This capability permits, for example, having a single version of a file, but different users having different views of it, based on which elements they were authorized to access.

p-0283<figref idrefs="DRAWINGS">FIG. 18</figref> illustrates a typical payload <b>1340</b> (e.g., a directive payload <b>1322</b>, a primary payload <b>1324</b>, or an ancillary payload <b>1326</b>) in the payload section <b>1320</b>. Each payload <b>1340</b> is an ordered set of logical blocks. For example, the payload <b>1340</b> includes payload block <b>1</b><b>1341</b>, payload block <b>2</b><b>1342</b>, payload block <b>3</b><b>1343</b>, payload block <b>4</b><b>1344</b>, and payload block N <b>1349</b> as the last logical block.

p-0284To ensure ongoing compliance with the security directives associated with the contents of secure file <b>1240</b>, it is important that the information contained within the secure file <b>1240</b> cannot be accessed through some means other than via the enforcement agent and security policy broker. However, it is still be possible to use other programs and utilities to act upon the secure file <b>1240</b> as a whole, without explicitly taking action on its contents. For example, secure files <b>1240</b> may be backed up to archival media, copied to floppy diskettes, and/or distributed by email.

p-0285Cryptography is utilized in one embodiment to maintain the confidentiality and integrity of the information within secure files <b>1240</b>, while still permitting these secure files <b>1240</b> to be handled by the operating system <b>370</b>. Thus, while a user may still use any “discretionary” abilities afforded to them by their information system <b>200</b> and distribute secure files <b>1240</b> to others, the information within these secure files <b>1240</b> still remains sacrosanct and the cipher text within cannot be successfully be decrypted without proper authorization. Further still, since proper authorization and decryption takes place under the supervision of the enforcement agent and security policy broker, the information contained within this redistributed secure file <b>1240</b> remains under the protection and control of the security policy being enforced by the enforcement agent and security policy broker. Any conventional cryptographic techniques can be used to digitally sign and/or encrypt the contents of secure file <b>1240</b>, or any portion thereof. Examples of conventional encryption techniques include: public key cryptosystems; symmetric key cryptosystems, such as block ciphers and stream ciphers; cryptographic hash algorithms, such as SIIA-1, MDS, and HMAC algorithms; and digital signing and verification. The cryptographic keys are stored and protected using conventional techniques. Examples of conventional cryptographic key techniques include: passwords and passphrases for the protection of cryptographic keys; and FIPS-140 type storage devices.

p-0286In various embodiments, any of the data structures used can be encrypted and/or digitally signed. For example, if security label <b>1336</b> is digitally signed by the security policy server <b>354</b>, the security policy broker <b>384</b> verifies the validity of this digital signature before attempting to look up the corresponding security directive record <b>1410</b>.

p-0287<figref idrefs="DRAWINGS">FIG. 19</figref> illustrates a security directive <b>1400</b>. The enforcement agent and security policy broker use security directive records <b>1410</b> associated with each secure file <b>1240</b> to determine how the security of each such secure file <b>1240</b> is to be maintained. More specifically, security directive record <b>1410</b> is associated with a specific payload <b>340</b> within a secure file <b>1240</b>, and different payloads <b>1340</b> may be associated with different security directive records <b>1410</b>. The security label <b>1336</b>, <b>1460</b> is the mechanism through which a security directive record <b>1410</b> is associated with the object it protects. However, in addition to protecting secure files <b>1240</b>, the embodiments may also be used to protect different types of resources, including both hardware components within the information system (e.g., printer <b>150</b>, communication interface <b>154</b>) and software constructs within the information system (e.g., files <b>130</b>, directories, named-pipes, communications protocols).

p-0288Target <b>1480</b> identifies a component of the information system <b>200</b>, and represents any hardware or software element within an information system <b>200</b> that the security policy broker has been configured to protect. Each target <b>1480</b> has an associated security label <b>1460</b>, which directs the security policy broker <b>384</b> to the security directive record <b>1410</b> associated with the target. For example, the target <b>1480</b> can identify, for example, a secure file <b>1240</b>, a communications interface, a printer, optical reader, and a folder, a directory, or other file organization structure within an optical reader.

p-0289The security label <b>1460</b> is an electronically encoded representation of a humanly readable artifact (e.g., a text string, symbol, glyph, or other marking) which can be made apparent to user <b>101</b> in any number of ways. For example, the security label can be made apparent to user <b>101</b> by being: shown on the display, rendered on hardcopy by the printer, or captured as part of the name of the secure file <b>1240</b> placed in the optical reader. The security label <b>1460</b> is not limited to simple text and may include any marking or indicia. This flexibility allows, for example, security labels <b>1460</b> to be encoded in different languages, allowing meaningful country-specific word choices; without incurring the administrative overhead of having to maintain a large number of identical security directives.

p-0290For targets <b>1480</b> that are within secure files <b>1240</b>, security labels <b>1460</b> and security directive records <b>1410</b> are used to apply non-discretionary access controls to each payload <b>1340</b> contained within the payload section <b>1320</b> of secure file <b>1240</b>. The enforcement agent accessing the specific manifest record <b>1330</b> associated with each payload <b>1340</b> passes the security label <b>1336</b> contained within manifest record <b>1330</b> to a security policy broker. The security policy broker is then able to determine the security directive record <b>1410</b> associated with that security label <b>1336</b> under the current security policy.

p-0291The mechanism used to associate a security directive records <b>1410</b> with non-file targets varies depending upon the specific architecture of each operating system (or virtual operating system virtual machine), and the manner in which an enforcement agent is configured. For example, UNIX and UNIX-type operating systems represent hardware devices and software constructs as file-like devices (e.g.,/dev,/proc/), and a pseudo-device driver can be used to associate an enforcement agent with these components.

p-0292The security directive <b>1400</b> is formed as a data structure and the relationships between the components of the data structure are illustrated in <figref idrefs="DRAWINGS">FIG. 16</figref>. The arrowheads in <figref idrefs="DRAWINGS">FIG. 19</figref> (and in <figref idrefs="DRAWINGS">FIG. 20</figref>) do not refer to directionality, but instead indicate the type of relationships between components. A single black arrowhead (e.g., between security directive record <b>1410</b> and security classification record <b>1470</b>) indicates exactly one, and can be read as: “security directive record <b>1410</b> has exactly one security classification <b>1470</b>.” A double black arrowhead (e.g., between security directive record <b>1410</b> and security label <b>1460</b>) indicates one or more (1+), and can be read as: “security directive record <b>1410</b> has one or more security labels <b>1460</b>.” A double outline arrowhead (e.g., between rule record <b>1412</b> and c-list record <b>1434</b>) indicates zero or more (0+ or 0/1/1+), and can be read as: “rule record <b>1412</b> has zero or more c-lists <b>1434</b>.” A single outline arrowhead (e.g., between security directive record <b>1410</b> and crypto-flags <b>1462</b>) indicates zero or exactly one (0/1), and can be read as: “security directive record <b>1410</b> has zero or one crypto-flags <b>1462</b>.”

p-0293The logical structure of security directive <b>1400</b> begins with the security directive record <b>1410</b>. The various components of the security directive record <b>1410</b> can be referred to as records, although other types of data structures and/or formats can be used to implement this logical structure. For example, the logical structure can be implemented using: arrays, linked lists, data sets, b-trees, queues, and lookup tables.

p-0294The security directive record <b>1410</b> includes one or more rule-related records <b>1416</b>, a security classification <b>1470</b>, zero or more security labels <b>1460</b>, and zero or one crypto-flags <b>1462</b>. In other embodiments, instead of having both rule-related records <b>1416</b> and a security classification <b>1470</b>, the security directive record <b>1410</b> includes one or more rules-related records <b>1416</b> and zero or one security classification <b>1470</b>, or the security directive record <b>1410</b> includes zero or more rule-related records <b>1416</b>, and a security classification <b>1470</b>.

p-0295The rule-related records <b>1416</b> include rules that specify how specific actions and conditions are to be handled with respect to the payload <b>1340</b> of a secure file <b>1240</b> or other target <b>1480</b>. Any specified conditions must be satisfied before the application is permitted to perform the specified actions. The rule-related records <b>1416</b> include r-list records <b>1414</b>, rule records <b>1412</b>, a-list records <b>1424</b>, c-list records <b>1434</b>, e-list records <b>1444</b>, s-list records <b>1454</b>, action records <b>1420</b>, condition records <b>1430</b>, event records <b>1440</b>, and subject records <b>1450</b>. Each r-list record <b>1414</b> includes one or more rule records <b>1412</b>. Each rule record <b>1412</b> includes zero or more a-list records <b>1424</b>, zero or more c-list records <b>1434</b>, zero or more e-list records <b>1444</b>, and at least one s-list record <b>1454</b>. Each a-list record <b>1424</b> includes at least one action record <b>1420</b>. Each c-list record <b>1434</b> includes at least one condition record <b>1430</b>. Each e-list record <b>1444</b> includes at least one event record <b>1440</b>. Each s-list record <b>1454</b> includes at least one subject record <b>1450</b>.

p-0296The rule-related records <b>1416</b> include elements referred to as lists, although other types of data structures and/or formats can be used, for example: arrays, linked lists, data sets, b-trees, queues, and lookup tables.

p-0297An action record <b>1420</b> comprises any activity performed upon the target <b>1480</b> of a security directive record <b>1410</b>. Examples of actions include: opening and closing a payload <b>1340</b> of a secure file <b>1240</b>; making changes to a payload <b>1340</b> of a secure file <b>1240</b>; making a copy of a payload <b>1340</b> of a secure file <b>1240</b>; making a copy of secure file <b>1240</b>; deleting a secure file <b>1240</b>; creating a new secure file <b>1240</b>; printing a payload <b>1340</b> of a secure file <b>1240</b>; printing a screen capture of display <b>148</b> while payload <b>1340</b> is visible; unauthorized printing of unsecured files to secured printers; transmitting a copy of a secure file <b>1240</b> to another party through email or the network <b>330</b>; transmitting unsecured files through a secured communications device to a destination outside of the local area network; and placing copies of unsecured files on secured diskette drive.

p-0298A condition record <b>1430</b> comprises any condition or conditional expression that can be measured or evaluated within the context of the information system <b>200</b>. Examples of conditions include: restrictions on time of day a payload <b>1340</b> within a secure file <b>1240</b> can be accessed; the availability of a low-latency network connection to the network <b>190</b>; and bow the identity of a subject in the subject record <b>1450</b> must be authenticated.

p-0299An event record <b>1440</b> (also referred to as an auditing event record) comprises an auditing-related activity associated with a given rule and causes an audit record to be written, depending upon the specifics of the event. Examples of events include: the creation of auditable records when a given rule is evaluated by the security policy broker (i.e., a rule-evaluated event); when an action associated with a given rule is permitted to take place by the security policy broker (i.e., a rule-allowed event); and when a given action associated with a given action is not permitted to take place by the security policy broker (i.e., a rule-denied event).

p-0300A subject record <b>1450</b> comprises one or more users and/or processes against which the rule record <b>1412</b> applies. Examples of a subject record include: Joe B. Smith; and all employees.

p-0301Different types of action records <b>1420</b>, condition records <b>1430</b>, and event records <b>1440</b> can be applicable to different types of secure files <b>1240</b>, depending on, for example, the nature of the secure file <b>1240</b>, the format of the secure file <b>1240</b>, the application being used to manipulate the secure file <b>1240</b>, or how the secure file <b>1240</b> is used. For example, a secure file <b>1240</b> having auditory information can have an associated action record <b>1420</b> of “play-through-speaker,” while this same action has no meaningful semantic equivalent for a secure file <b>1240</b> having JPEG information. Conversely, a secure file <b>1240</b> having JPEG information can have an associated condition record <b>1430</b> of “black-and-while image,” while this same condition has no meaningful semantic equivalent for a secure file <b>1240</b> having auditory information.

p-0302The security classification record <b>1470</b> advantageously allows security classification of large numbers of targets <b>1480</b> into compartments or categories in a manner that simplifies the management of the protections afforded by the invention. The security classification record <b>1470</b> is a category or compartment to which confidential information is assigned to denote the degree of damage that unauthorized disclosure might cause. Depending upon the specific security policy, any number of such categories can be defined. The security classification record <b>1470</b> includes a security level <b>1474</b> and zero or more security compartments <b>1472</b>.

p-0303The security level <b>1474</b> comprises a hierarchical representation of the relative confidentiality associated with the security directive <b>1400</b>, as exemplified by the policy table <b>398</b> of <figref idrefs="DRAWINGS">FIG. 7</figref>. One or more security levels can be determined for the security policy. For example, a company or government agency may desire that information be hierarchically organized according three security levels of classified, secret, and top-secret. In some embodiments, security level <b>1474</b> can be represented as a numerical value, where lower-valued security levels represent less confidential information, and higher-valued security levels represent more confidential information.

p-0304Each security compartment <b>1472</b> is a non-hierarchical attribute of the security directive <b>1400</b>. The security compartments <b>1472</b> permit further compartmentalization (which may also be referred to as compartmentalization) for a security level <b>1474</b>. Compartmentalization provides a technique to add additional security-related categories that allow information to be managed and shared between users only to the extent required for the performance of their individually assigned duties. In other words, compartmentalization may be conceptually thought of as a mechanism of dividing information into categories so that some users may be granted permission to access information in one category, and not another. The use of compartmentalization techniques provides a mechanism for implementing the “need to know” principle common to many secure environments.

p-0305The crypto-flags <b>1462</b> specify what cryptographic techniques, if any, are associated with the security directive record <b>1410</b>. If no cryptographic techniques are to be used, the crypto-flags may indicate this condition, or the crypto-flags may be omitted. The crypto-flags <b>1462</b> dictate the type of cryptography, if any, that the security policy requires for target <b>1480</b>. Examples of crypto-flags <b>1462</b> include, specific algorithms that can or must be used, allowed cryptographic key lengths, specific requirements for crypto-key storage (e.g., only use FIP-140 type device), and other crypto-related requirements or specifications. The crypto-flags <b>1462</b> do not necessarily include a specific cryptographic state, such as an actual cryptographic cipher key but specify the mandated cryptographic techniques.

p-0306The data structure of the security directive <b>1400</b> can be stored in a variety of locations, including, for example, the policy server <b>354</b>, the directory service <b>352</b>, the policy broker cache <b>392</b>, and a secure file <b>1240</b>. In most cases, however, the canonical copy of any given security directive record <b>1410</b> associated with security directive <b>1400</b> is maintained by the security policy server <b>354</b> with copies of these records temporarily stored in other locations for the convenience of processing without always requiring a networked connection to the policy server <b>354</b>.

p-0307For example, a copy of the rule-related records <b>1416</b> associated with the security directive record <b>1410</b> can be part of the directive payload <b>1322</b> of the secure file <b>1240</b>. The rule-related records <b>1416</b> can then be loaded and temporarily maintained within the policy broker cache <b>392</b> In another embodiment, the rule-related records <b>1416</b> can be retrieved as needed from the policy server <b>354</b>. In another embodiment, a portion of the rule-related records <b>1416</b> can be stored as part of the directive payload <b>1322</b> of the secure file <b>1240</b>, and another portion of the rule-related records <b>1416</b> can be retrieved as needed from the policy server <b>354</b>. By requiring retrieval from the policy server <b>354</b>, the security policy can be updated for secure files <b>1240</b> that have previously been distributed to information systems.

p-0308In other circumstances, for example for non-file targets <b>1480</b>, the security directive record <b>1410</b> associated with a target <b>1480</b> may be implicitly specified as part of the initialization of the security policy broker <b>384</b> for the information system <b>200</b>.

p-0309The security directive <b>1400</b> can be dynamic. Any of the components of the security directive <b>1400</b> can be modified in any way, at any time, by an authorized party or process, and the resulting changes are honored by all subsequent enforcement decisions rendered by the security policy broker <b>384</b>. For example, if the rules-related records <b>1416</b> are modified, upon retrieving the updated security directive record <b>1410</b>, security policy broker <b>384</b> determines policy for targets <b>1480</b> associated with security label <b>1460</b> according to the modification. If a large number of secure files <b>1240</b> have the same security label <b>1460</b>, all of the secure files <b>1240</b> are protected and controlled according to the modified rules of the security directive <b>1400</b>.

p-0310<figref idrefs="DRAWINGS">FIG. 20</figref> illustrates an identity <b>1500</b> and its relationship to a user <b>101</b> and a security directive <b>1400</b>. The security directive <b>400</b> of <figref idrefs="DRAWINGS">FIG. 20</figref> is the same as the security directive <b>1400</b> of <figref idrefs="DRAWINGS">FIG. 19</figref> but is not depicted with all components for the sake of clarity.

p-0311The identity <b>1500</b> can be associated with a user <b>101</b>. Examples of a user include: a person or persons; a role or position; an automated process (e.g., a software daemon, agent, or process); a physical automated agent (e.g., as a robot or an unmanned aerial vehicle); “batch-type” programs that run with other periodic interaction with real persons; various system services which run in process context specific (e.g., “mail daemon” running under the pseudo-identity of “mail”); and programs the run on behalf of the system itself (e.g., “telnet” or “sshd”).

p-0312The identities <b>1500</b> are stored within the security policy server <b>354</b> and/or the directory service <b>352</b>. The identity <b>1500</b> specifies the manner by which the security policy broker can authenticate user <b>101</b> and the security clearance that user <b>101</b> is authorized to hold. An identity <b>1500</b> is created for user <b>101</b> by a competent authority. The relationship between the user <b>101</b> and the identity <b>1500</b> is illustrated with a user-identity relationship <b>1514</b>. The user-identity relationship <b>1514</b> is verified via the authentication credentials <b>1520</b>. Any number of prior art authentication methods and protocols can be utilized to validate and verify the identity <b>1500</b> of user <b>101</b>, and thus validate the user-identity relationship <b>1514</b>.

p-0313The logical structure of identity <b>1500</b> begins with the identity record <b>1510</b>, and the relationships between the components of the data structure are illustrated using the same relationship notations used in <figref idrefs="DRAWINGS">FIG. 5</figref>. The various components of the identity record <b>1510</b> can be referred to as records, although other types of data structures and/or formats can be used to implement this logical structure. For example, the logical structure can be implemented with: arrays, linked lists, data sets, b-trees, queues, and lookup tables.

p-0314The identity <b>1510</b> includes one or more authentication credentials <b>1520</b>, one or more security clearances <b>1570</b>, and zero or more authorization directives <b>1580</b>.

p-0315Each authentication credential <b>1520</b> includes a password <b>1522</b>, zero or more token <b>1524</b>, zero or more biometric <b>1526</b>, and zero or more crypto-keys <b>1528</b>. In other embodiments, the authentication credential <b>1520</b> can includes at least one of a password <b>1522</b>, a token <b>1524</b>, a biometric <b>1526</b>, and crypto-keys <b>1528</b>, or any combination of them. Other prior art identity verification techniques can also be employed.

p-0316The password <b>1522</b> is a shared secret, known to both the authentication identification system <b>340</b> and the user <b>101</b>. The password <b>1522</b> can be a conventional text string (e.g., alphanumeric) or can be any information type determined by the user <b>101</b> as secret information to obtain access to the information system <b>200</b>. Other embodiments may utilize any type of secret information that can be shared between user <b>101</b> and the security policy server <b>354</b> and readily provided by user <b>101</b> when requested.

p-0317The token <b>1524</b> contains information specific to the hardware authentication token permitted to be used to authenticate the identity of user <b>101</b>. Examples of the token <b>1524</b> include: the type of hardware authentication protocol being used, the location of the authentication identification system <b>340</b> to be used, and other types of hardware-specific authentication information that may necessary.

p-0318The biometric <b>1526</b> contains information specific to the biometric authentication device permitted to be used to authenticate the identity of user <b>101</b>. Examples of the biometric <b>1526</b> include: the type of hardware authentication protocol being used; the location of the authentication identification system <b>340</b> to be used; and other types of biometric hardware-specific authentication information that may necessary.

p-0319The crypto-keys <b>1528</b> contain cryptologic information necessary to authenticate the identity of user <b>101</b> based on one or more cryptographic keys. For example, if PKI-based authentication is being used, crypto-keys may contain the public key of user <b>101</b> signed by a recognized certificate authority.

p-0320All of the authentication credentials <b>1520</b>, including password <b>1522</b>, token <b>1524</b>, biometric <b>1526</b>, and crypto-keys <b>1528</b> are based on well known and well established prior art authentication techniques and protocols. Different embodiments may implement these various authentication credential records <b>1520</b> in different ways. In some embodiments, the security policy broker may also rely upon any authentication mechanisms provided as part of the operating system <b>370</b> in information system <b>200</b>.

p-0321Each clearance record <b>1570</b> provides the security clearance authority given to the user <b>101</b>. Each classification record <b>1570</b> includes a security level <b>1574</b> and zero or more security compartments <b>1572</b>. The security clearance is a property associated with users, and the security classification is a property associated with targets. Thus, the security compartments <b>1572</b> and the security level <b>1574</b> of the identity record <b>1510</b> mirror the security compartments <b>1472</b> and the security level <b>1474</b>, respectively, in the security directive record <b>1410</b>.

p-0322The authorization directive <b>1580</b> constrains what protections and controls user <b>101</b> may apply to information. The authorization directive <b>1580</b> is used to apply non-discretionary controls that user <b>101</b> may be mandated to apply with regards to targets <b>1480</b> of security directives <b>1400</b>. The authorization directive <b>1580</b> specifies what elements of the security policy (e.g., security labels <b>1460</b> and security directives records <b>1410</b>) must and/or may be applied by user <b>101</b>. Each authorization directive <b>1580</b> has the same form as a security directive record <b>1410</b>, can contain all of the information contained in a security directive record <b>1410</b>, and further specifies the circumstances and conditions under which the included security directive record <b>1410</b> applies.

p-0323To determine if the user <b>101</b> can perform the requested action to a secure file <b>1240</b> (or other target <b>1480</b>), the security policy broker <b>384</b> performs a clearance-classification check <b>1516</b> and an identity-subject check <b>1518</b>. To perform the clearance-classification check <b>1516</b>, the security clearances <b>1570</b> of the identity record <b>1510</b> and the security classification <b>1470</b> of the security directive record <b>1410</b> are compared. More specifically, the security compartments <b>1572</b> and the security compartments <b>1472</b> are compared, and the security level <b>1574</b> and the security level <b>1474</b> are compared. To pass the clearance-classification check <b>1516</b>, the security clearances <b>1570</b> of the identity record <b>1510</b> must dominate (e.g., via the Bell-LaPadula domination rule) the security classification <b>1470</b> of the security directive record <b>1410</b>.

p-0324For this embodiment, to pass the clearance-classification check <b>1516</b>, the security compartments <b>1572</b> must include (or be as large as) the security compartments <b>1472</b>, and the security level <b>1574</b> must be at least as great as the security level <b>1574</b>. To perform the identity-subject check <b>1518</b>, the subject <b>1450</b> associated with the security directive record <b>1410</b> is used. The security policy broker authenticates the identity <b>1500</b> of user <b>101</b> using one or more of the authentication credentials <b>1520</b> associated with the identity record <b>1510</b>. Based on the strength of the results from the identity-subject check <b>1514</b>, the security policy broker ascertains if user <b>101</b> satisfies the rule <b>1412</b>. The identity-subject check <b>1518</b> is performed when a subject record <b>1450</b> is present in the security directive record <b>1410</b>.

p-0325<figref idrefs="DRAWINGS">FIG. 21</figref> illustrates a flowchart for creating a secure file <b>1240</b> in relation to the described system embodiments. In block <b>1601</b>, the user <b>101</b> is enrolled in the distributed information protection and control system. An identity record <b>1510</b> is created by/for the user <b>101</b> and stored in directory service <b>352</b>.

p-0326The creation of the identity record <b>1510</b> may require additional identity records <b>1510</b>, a subset of such records, and/or appending additional data to existing records in the directory service <b>352</b>. In block <b>1602</b>, the user <b>101</b> initializes the information system <b>200</b>. As part of the information system <b>200</b> initialization, the enforcement agent <b>379</b> can be associated with operating system shell <b>382</b> in application process <b>380</b>. Additionally, the security policy broker can be initiated to work with enforcement agent <b>379</b>.

p-0327In block <b>1603</b>, the user <b>101</b> is authenticated. The information system <b>200</b> matches the user <b>101</b> with the identity <b>1500</b> and associated identity records <b>1510</b>. The matching is accomplished with the authentication credentials <b>1520</b>. The user <b>101</b> may be required to reply correctly to authentication challenges by the information system <b>200</b>. If the user <b>101</b> provides the appropriate response(s) based on the authentication credentials <b>1520</b>, the user <b>101</b> is matched with the identity <b>1500</b> and associated identity records <b>1510</b>. In other embodiments, the matching can occur using any conventional techniques. For example, the information system can match the user <b>101</b> based on authentication techniques implemented by the operating system <b>370</b>. Once authenticated, the information system <b>200</b> matches the user <b>101</b> with identity <b>1500</b>, and this user-identity relationship is illustrated with the dotted line <b>1514</b>.

p-0328In block <b>1604</b>, an application is loaded. The user <b>101</b> starts up the application <b>374</b> within the application process <b>376</b>. In some embodiments, the invention is in either an active state or an inactive state. For the active state, when the operating system <b>370</b> loads application program <b>374</b> into non-persistent storage <b>310</b>, enforcement agent <b>378</b> is associated with the application process <b>376</b>. The enforcement agent <b>379</b> associated with the operating system shell <b>382</b> monitors the application processes that the operating system shell <b>382</b> loads into the non-persistent storage <b>370</b>. When the operating system shell <b>382</b> loads the application process <b>114</b>C into the non-persistent storage <b>370</b>, the enforcement agent <b>378</b> assigns the enforcement agent <b>378</b> to the application process (transforming it to application process <b>376</b>). For the inactive state, enforcement agent <b>379</b> does not assign enforcement agent <b>379</b> to application process, in which case secure files <b>1240</b> can neither be created nor accessed by application <b>374</b> in application process <b>114</b>C. In other embodiments, various actions within this flow could cause enforcement agent <b>378</b> to be assigned to application process <b>114</b>C.

p-0329In block <b>1605</b>, user <b>101</b> loads a file <b>394</b> using the application <b>374</b>. Loading a file <b>394</b> can include, for example: creating content; opening an existing file <b>394</b>; and manipulating the application <b>374</b> (e.g., a file manager), which does not open and load a file <b>394</b> in the same manner as an application normally used to create and manipulate that type of file <b>394</b>, but which may take certain actions on the file <b>394</b>.

p-0330In block <b>1615</b>, the user <b>101</b> requests to save the file. Enforcement agent <b>378</b> intercepts the resulting data-saving request made by the application process to the operating system <b>370</b>.

p-0331In block <b>1620</b>, the security policy broker determines, based upon the authorization directive <b>1580</b>, that the user <b>101</b> must protect the file <b>394</b> and proceed on to block <b>1630</b>. If authorization directive <b>1580</b> does not require that user <b>101</b> protect file <b>394</b> or if an authorization directive <b>1580</b> does not exist, the user <b>101</b> has an option to choose whether to protect the file <b>394</b>. If the user <b>101</b> chooses not to protect the file <b>394</b>, the flow ends at block <b>1660</b>, and the application <b>374</b> conventionally saves the file <b>394</b>.

p-0332In block <b>1625</b>, the user <b>101</b> requests to protect the file. In some embodiments, this request can originate from the user <b>101</b> selecting this action via the title bar icon <b>1804</b> (<figref idrefs="DRAWINGS">FIG. 23</figref>). In other embodiments, this request can be initiated through a separate application program or utility.

p-0333In block <b>1630</b>, user <b>101</b> selects a security label <b>1460</b> to be associated with the secure file. The security label <b>1460</b> is assigned as security label <b>1336</b> with the manifest record(s) <b>1330</b> of the payload(s) <b>1340</b> within which the information contained in file <b>394</b> is to be stored. If the user <b>101</b> selects to assign a previously defined security label <b>1460</b>, flow proceeds to block <b>1635</b>. If the user <b>101</b> selects to create a new security directive <b>1400</b>, flow proceeds to block <b>1640</b>. Only the security labels <b>1460</b> that the user <b>101</b> is authorized to assign (including the option to create a new security label <b>1460</b>), as specified in authorization directive <b>1580</b>, are offered to the user <b>101</b> for selection in block <b>1630</b>.

p-0334In block <b>1635</b>, the security policy broker <b>384</b> retrieves the security directive record <b>1410</b> corresponding to the selected security label <b>1460</b>. The security policy broker <b>384</b> can retrieve security directive records <b>1410</b> from, for example: the policy broker cache <b>392</b> and/or the security policy server <b>354</b>.

p-0335In block <b>1640</b>, user <b>101</b> creates a new security directive <b>1400</b>. Creating a new security directive <b>1400</b> entails creating a security directive record <b>1410</b>.

p-0336In block <b>1645</b>, the security policy broker <b>384</b> validates that the user <b>101</b> is authorized to apply the selected security label <b>1460</b> as the security label <b>1336</b> of the manifest record <b>1330</b> for the secure file <b>1240</b>. If user <b>101</b> created a new security directive in block <b>1640</b>, the new security directive is validated. The validation can include verification of the authentication credentials <b>1520</b>, if required by security directive record <b>1410</b>. If user <b>101</b> is authorized to apply security label <b>1460</b>, flow proceeds to block <b>1650</b>. If the user <b>101</b> is not authorized to apply the selected security label, flow returns back to block <b>1630</b> or continues to block <b>1655</b>. If, at block <b>1620</b>, the user <b>101</b> was required to protect the file, but user <b>101</b> does not select an authorized security label <b>1460</b>, user <b>101</b> is unable to save the file <b>394</b> as secure file <b>1240</b>. In some embodiments, if in active state, user <b>101</b> is prohibited from saving file <b>394</b>.

p-0337In block <b>1650</b>, the enforcement agent <b>378</b> generates the secure file <b>1240</b>, with file <b>394</b> becoming the primary payload <b>1324</b>, and applies the cryptographic techniques as required by the crypto-flags <b>1462</b> of the security directive record <b>1410</b>. The manifest record <b>1330</b> of primary payload <b>1322</b> contains security label <b>1336</b>, as selected via blocks <b>1630</b>, <b>1635</b>, <b>1640</b>, and <b>1645</b>. The security policy broker <b>384</b> can require the user <b>101</b> to present authentication credentials <b>1520</b> to perform acts of cryptographically signing one or more parts of the secure file <b>1240</b>. The enforcement agent <b>378</b> and the security policy broker <b>384</b> can communicate with the directory service <b>352</b> to determine various identity information related to potential recipients of the file <b>394</b>, such as identity group resolution, contact details, and crypto-keys. If desired, enforcement agent <b>378</b> can securely delete file <b>394</b> at step <b>650</b>.

p-0338In block <b>1655</b>, if required, the security policy broker <b>384</b> logs the creation of the new secure file <b>1240</b> to the audit server <b>350</b>. If, at block <b>1645</b>, user <b>101</b> was denied authorization to apply desired security label, security policy broker <b>384</b> may log the attempted security label to audit server <b>350</b>. Logging may be required by the security directive record <b>1410</b> associated with the selected security label <b>1336</b>, as specified within the e-list <b>1444</b>.

p-0339In block <b>1660</b> the flow ends, when the user <b>101</b> closes the file <b>394</b>, or when the user <b>101</b> closes the file <b>394</b> without saving or protecting the file <b>394</b>. In another embodiment, secure file <b>1240</b> may not be physically created in an optical reader until user <b>101</b> chooses to save file <b>394</b>.

p-0340<figref idrefs="DRAWINGS">FIG. 22</figref> illustrates a flow chart for accessing a secure file <b>1240</b>. In block <b>1700</b>, the information system <b>1240</b> is running properly, and blocks <b>1601</b>-<b>1604</b> have been performed.

p-0341In block <b>1705</b>, the user <b>101</b> requests to access a secure file <b>1240</b> via application <b>374</b> in application process <b>376</b>. Enforcement agent <b>378</b> intercepts the request made to the operating system <b>370</b> by the application process <b>376</b> accessing the secure file <b>1240</b>.

p-0342In block <b>1710</b>, the enforcement agent <b>378</b> determines if the selected secure file <b>1240</b> can be accessed. The enforcement agent <b>378</b> checks the user-identity relationship <b>1514</b> using the authentication credentials <b>1520</b>. If the user <b>101</b> passes the check, the secure file <b>1240</b> is accessed, and flow proceeds to block <b>1715</b>. If the enforcement agent <b>378</b> and security policy broker <b>384</b> are not available, the operating system <b>370</b> can start the enforcement agent <b>378</b> and the security policy broker <b>384</b>. If the enforcement agent <b>378</b> or the security policy broker <b>384</b> cannot be found or started, or if user <b>101</b> fails the check (i.e., cannot provide the required authentication credentials <b>1520</b> to validate the user-identity relationship <b>1514</b>), flow proceeds to and ends at block <b>1780</b>, and the user <b>101</b> cannot access the secure file <b>1240</b>.

p-0343In block <b>1715</b>, the enforcement agent <b>378</b> provides the security policy broker <b>384</b> with header section <b>1310</b> of the secure file <b>1240</b>.

p-0344In block <b>1720</b>, the security policy broker <b>384</b> obtains the security directive record <b>1410</b> associated with the security label <b>1336</b> for the primary payload <b>1324</b>. The security directive record <b>1410</b> can be contained, for example, within the directive payload <b>1322</b> of the secure file <b>1240</b>, within the policy broker cache <b>392</b>, and/or retrieved from the security policy server <b>354</b>. If the security directive record <b>1410</b> is located within the directive payload <b>1322</b>, the enforcement agent <b>378</b> forwards the security directive record <b>1410</b> to the security policy broker <b>384</b>. In other embodiments, the enforcement agent <b>378</b> can provide callback functions to the security policy broker <b>384</b> to retrieve the directive payload <b>1322</b>.

p-0345In block <b>1730</b>, the security policy broker <b>384</b> performs a clearance-classification check <b>1516</b> and an identity-subject check <b>1518</b>. To perform the checks, the security policy broker <b>384</b> accesses the security classification record <b>1470</b> and the subject records <b>1450</b> for the security directive record <b>1410</b>. As discussed above, the clearance-classification check <b>1516</b> is performed using the security clearance records <b>1570</b> of the identity record <b>1510</b> associated the user <b>101</b> and the security classification records <b>1470</b> of the security directive record <b>1410</b> associated with the security label <b>1336</b>. As discussed above, the identity-subject check <b>1518</b> is performed using the identity record <b>1510</b> and the subject record <b>1450</b>. If user <b>101</b> passes, flow passes to block <b>1735</b>. If user <b>101</b> fails either the clearance-classification check <b>1516</b> or the identity-subject check <b>1518</b>, user <b>101</b> is denied access to the payload <b>1340</b> of secure file <b>1240</b>, and flow proceeds to block <b>1770</b>.

p-0346In block <b>1735</b>, the enforcement agent <b>378</b> determines whether the crypto-keys <b>1338</b> from the manifest record <b>1330</b> corresponding to the payload(s) <b>1340</b> being accessed within the secure tile <b>1240</b> can be accessed. The crypto-keys <b>1338</b> of the secure file are accessed via the crypto-keys <b>1528</b> for the identity record <b>1510</b>. Crypto-keys <b>1338</b> may be required in order to decrypt a payload <b>1340</b>, but crypto-keys <b>1338</b> may also be encrypted. In various embodiments, various mechanisms may be employed to provide enforcement agent <b>378</b> with access to crypto-keys <b>1338</b> to decrypt payload <b>1340</b> of secure file <b>1240</b>. For example, enforcement agent <b>378</b> may communicate with to have crypto-keys <b>1338</b> decrypted and re-encrypted in such a manner that crypto-keys <b>1528</b> are able to access crypto-keys <b>1338</b>. As another example, enforcement agent <b>378</b> may retrieve crypto-keys <b>1338</b>, which are stored on security policy server <b>354</b> rather than within manifest record <b>1333</b>. As a further example, payload <b>1340</b> may not be encrypted. If the crypto-keys <b>1528</b> for the identity record <b>1510</b> decrypt crypto-keys <b>1338</b>, flow proceeds to block <b>1740</b>. If the crypto-keys <b>1528</b> cannot decrypt crypto-keys <b>1338</b>, user <b>101</b> is not permitted access to payload <b>1340</b>, and the flow proceeds to block <b>1770</b>.

p-0347In block <b>1740</b>, the enforcement agent <b>378</b> loads one or more payloads <b>1340</b> from the payload section <b>1320</b> of the secure file <b>1240</b> into non-persistent storage associated with application process <b>376</b>, provided that user <b>101</b> has the required authorization to access the desired payload blocks <b>1341</b>, <b>1342</b>, <b>1343</b>, etc. It is possible that different payloads <b>1340</b> (e.g., primary payload <b>1324</b> and each ancillary payload <b>1326</b>) have different security labels <b>1336</b> and, hence, different associated security directive records <b>1410</b>, such that user <b>101</b> may be authorized to access one payload <b>1340</b> but not another. Any encrypted blocks can be decrypted by the enforcement agent <b>378</b> using the accessed crypto-keys <b>1338</b>. Thus, application <b>374</b> within application process <b>376</b> is able to reference primary payload <b>324</b>, just as if it were the original file <b>394</b>.

p-0348In block <b>1750</b>, the user <b>101</b> requests an action on the information in a payload <b>1340</b> of the secure file <b>1240</b>. The enforcement agent <b>378</b> intercepts the request from the application <b>374</b> in application process <b>376</b> to the operating system <b>370</b>.

p-0349In block <b>1755</b>, the security policy broker <b>384</b> evaluates the requested action by checking rule-related records <b>1416</b> of the security directive records <b>1410</b> to determine if the user <b>101</b> is permitted to perform the requested action. Additionally, as an option, the security policy broker <b>384</b> can again verify the user-identity relationship <b>1514</b>. For example, the user <b>101</b> can be required to provide and/or revalidate authentication credentials <b>1520</b> prior to being authorized for the action.

p-0350If the rule-related records <b>1416</b> of the security directive records <b>1410</b> has action records <b>1420</b>, the security policy broker <b>384</b> notifies the enforcement agent <b>378</b> that the user <b>101</b> is authorized for and/or prohibited from the actions of the action records <b>1420</b>. If rule-related records <b>1416</b> has condition records <b>1430</b>, the security policy broker <b>384</b> determines if the condition records <b>1430</b> are satisfied, and notifies the enforcement agent <b>378</b> whether or not the association action should be permitted. If the action is permitted, flow proceeds to block <b>1760</b>; otherwise if the action is not permitted, flow proceeds to block <b>1765</b>.

p-0351In block <b>1760</b>, user <b>101</b> is authorized, and the security policy broker <b>384</b> notifies the enforcement agent <b>378</b> that the user <b>101</b> can continue with the request. Enforcement agent <b>378</b> passes the request made by application <b>374</b> to the operating system <b>370</b>.

p-0352In block <b>1765</b>, user <b>101</b> is not authorized, and the security policy broker <b>384</b> notifies the enforcement agent <b>378</b> that the user <b>101</b> cannot continue with the request. The enforcement agent <b>378</b> prevents the action from occurring by not permitting the intercepted request made by the application process <b>376</b> to proceed to the operating system <b>370</b>, and providing an appropriate response to the application <b>374</b> within application process <b>376</b>. In other embodiments, this response may emulate operating system request-return values. In other embodiments, this response may include request-return values. The enforcement agent <b>378</b> can also present an error message <b>1825</b> (see <figref idrefs="DRAWINGS">FIG. 23</figref>) to the user <b>101</b> via the display <b>148</b>.

p-0353In block <b>1770</b>, the user <b>101</b> is denied access to the contents of secure file <b>1240</b>, as a result of decisions made in blocks <b>1730</b> or <b>1735</b>.

p-0354In block <b>1775</b>, the result of previous block steps <b>1760</b>, <b>1765</b>, and <b>1770</b> are audited, if required by security directive records <b>1410</b>. If the security directive record <b>1410</b> has event records <b>1440</b>, the security policy broker <b>384</b> and/or the enforcement agent <b>378</b> supplies a record audit of the events to the audit server <b>350</b>. Such audit logs may, for example, contain information such as: the secure file identifier <b>1312</b> of the secure file <b>1240</b>; the identity record <b>1510</b> of the user <b>101</b>; identification of the information system <b>200</b>; the security label <b>1460</b>; the application <b>116</b>; the action attempted; the conditions, relating to condition records <b>1430</b>; and the success or failure of the requested action. In other embodiments, the enforcement agent <b>378</b> can access the audit server <b>350</b> periodically, non-periodically and/or “on demand” when an event occurs. In some embodiments, auditable events may be temporarily stored in the enforcement agent cache <b>268</b> by enforcement agent <b>378</b>, and in the policy broker cache <b>392</b> by the security policy broker <b>384</b>, prior to their being transmitted to audit server <b>350</b>.

p-0355As long as the user <b>101</b> continues to access secure file <b>1240</b>, flow proceeds from block <b>1775</b> to block <b>1750</b>. The enforcement agent <b>262</b> continues to intercept requested actions, and the security policy broker <b>384</b> continues to intercept these actions in the manner so described (blocks <b>1750</b>-<b>1775</b>). Any additional files created in persistent storage by application <b>374</b> that are associated with the contents of secure file <b>1240</b> (e.g., temporary files, earlier revisions of the file, and backups of the file) are stored either within enforcement agent cache <b>396</b> or as other secure files. If the crypto-flags record <b>1462</b> of security directive record <b>1410</b> specifies that such information is to be encrypted, all such additional and/or temporary files are encrypted appropriately.

p-0356The presence of the invention in the information system <b>200</b> can be indicated to the user I/O in a variety of ways (e.g., visual and/or audio). For example, for operating systems <b>370</b> with a graphical user interface (“GUI”), such as Microsoft Windows or X-Windows, the presence can be shown visually, and user <b>101</b> can be provided with various GUI elements for interacting with the invention. Sound, and other acoustic indications, can also be used to facilitate user interaction in a manner appropriate to the operating system and user-interface. <figref idrefs="DRAWINGS">FIG. 23</figref> illustrates an exemplary user interface for the display <b>148</b> of the information system <b>200</b>. As an example, if the operating system <b>370</b> is Microsoft Windows, a task bar icon <b>1802</b> can be displayed within the task bar <b>1800</b> as a visual GUI-based indication of the presence of the invention. This task bar icon <b>1802</b> can also provide pictorial representations of the state of the enforcement agents <b>379</b>, <b>378</b> running within the application process <b>376</b>, <b>380</b>. The user may “click on” or otherwise select this task bar icon <b>1802</b> to further reveal a task bar menu with additional choices. With the menu, the user <b>101</b> can, for example: change the state of existing enforcement agents; change the state of all enforcement agents; and access other command and control functions provided. The task bar icon <b>1802</b> and task bar menu <b>1805</b> may be managed by the security policy broker <b>384</b> or by an independent software process created solely to provide these user-interface constructs.

p-0357Continuing with this example, if an enforcement agent is assigned to an application process having GUI elements, a title bar icon <b>1804</b> in the title bar <b>1806</b> in the window <b>1808</b> for the application process can be provided. The title bar icon <b>1804</b> indicates whether the information displayed in window <b>1808</b> is contained in a secure file <b>1240</b>, and displays the associated security label <b>1460</b> (i.e., determined by the security label <b>1336</b> associated with the manifest record <b>1330</b> of the payload <b>1340</b> containing the displayed information) as application window label <b>1820</b>. If information is being displayed from multiple payloads (e.g., both primary and ancillary payloads), the label <b>1820</b> of title bar <b>1806</b> of the application window <b>1808</b> is updated appropriately. If an application process has multiple application windows <b>1808</b>, each title bar icon <b>1804</b> and application window label <b>1820</b> will reflect the security label associated with the information specific to that window.

p-0358The title bar icon <b>1804</b> of window <b>1808</b> can further be selected to reveal a security policy broker menu <b>1815</b>. For example, the user <b>101</b> can, if authorized: convert a file <b>394</b> to a secure file <b>1240</b>; view currently authorized actions on the payload <b>1320</b> of secure file <b>1240</b>; and modify security directive records <b>1410</b>. Selecting one or more of these options may cause the security policy broker <b>384</b> to launch additional dialogs for user input and/or output, as required by the information being manipulated. Within some application processes, such as a file manager, menu <b>1815</b> may be appended to a context menu, often associated with a secondary mouse button click, such that user <b>101</b> may select a file <b>394</b> and display security policy broker menu <b>1815</b>.

p-0359Other informational messages <b>1825</b> may be displayed as needed, in a fashion common to GUI display, by the enforcement agent or security policy broker <b>384</b>.

p-0360In some embodiments, the graphical elements of the invention (e.g., title bar icon <b>1804</b>, application window label <b>1820</b>, menu <b>1815</b>, and message <b>1825</b>) are implemented using conventional GUI constructs provided by the operating system <b>370</b> that are outside of the direct control of application <b>116</b> displaying information within window <b>1808</b> (e.g., within the window manager itself, and not the application). Thus, the graphical elements associated with the invention are unapparent to and exist outside the knowledge and control of application <b>374</b>.

p-0361In general, an operating system graphical user interface (e.g., the desktop in Microsoft Windows) is used for the operating system <b>370</b>, and an application graphical user interface (e.g., a window in Microsoft Windows) is used for an application <b>374</b>. The operating system graphical user interface and/or the application graphical user interface can be adorned with additional elements to identify the enforcement agent and/or the security policy broker <b>384</b>. Further, a task bar icon <b>1802</b> or equivalent of the operating system graphical user interface and/or a title bar icon <b>1804</b> or equivalent of the application graphical user interface can be used to identify the enforcement agent and/or the security policy broker <b>384</b>.

p-0362Other embodiments for operating systems <b>370</b> utilizing a GUI may use similar techniques to allow the user to control and interact with the invention. In other embodiments without a conventional GUI, other exemplary forms of interacting with the user may be used, depending upon the capabilities provided in the operating system.

p-0363To illustrate the operation of the invention outside the medical records context, another example is provided. Consider a company that establishes an information classification scheme with five security levels (with values 0 to 4) and four security compartments (called UR, FA, SM, and SM). The five levels, in ascending order of confidentiality, along with their corresponding semantics are: public (level 0), official-use only (level 1), internal-use only (level 2), company confidential (level 3), and restricted (level 4). The four compartments are associate with various aspects of the companies business units: human resources (HR), finance and accounting (FA), sales and marketing (SM), and product development (PD). The company's security directives <b>1400</b> stipulate that in the absence of file-specific rules, a user may have read-only access to the payload <b>1320</b> of a secure file <b>1240</b> only if their individual security clearance level (i.e., security level <b>1574</b>) is greater than or equal to the classification level (i.e., security level <b>1474</b>) associated with the information contained in a secure file <b>1240</b>.

p-0364Example users in the company include: Bob, the Vice-President of Sales and Marketing, with a non-compartmentalized security clearance <b>1570</b> of “restricted” (level 4), as well as security clearances <b>1570</b> of SM-4 and FA-3; Marie, Bob's assistant, with a non-compartmentalized security clearance <b>1570</b> of level 2; and Alice, a human resources manager with a non-compartmentalized security clearance <b>1570</b> level 3, as well as security clearances <b>1570</b> of HR-3 and FA-2.

p-0365A security directive <b>1400</b> of the company requires that only senior human resources personnel may create and share information related to employee salaries. An increasing number of regulations also require that the company protect personal and private data. The invention implements this security policy to ensure that an employee's salary, which is deemed private, is not released to unauthorized individuals.

p-0366To meet this security directive <b>1400</b>, the company defines security directive record <b>1410</b> with a security label <b>1460</b>, SALARY, which has a security classification record <b>1470</b> of HR-3 (i.e., a security level <b>1474</b> of 3 and a security compartment <b>1472</b> of HR). Additionally, the security directive record <b>1410</b> has a security classification record <b>1470</b> of HR-3 for actions other than read via an action record <b>1420</b>. In other words, users with a general clearance record <b>1570</b> having a security level <b>1574</b> of 3 or higher can only read SALARY labeled secure files, unless the user also has a clearance record <b>1570</b> having a security compartment <b>1572</b> of HR at a security level <b>1574</b> of 3 or higher. Further, the rules <b>1416</b> in the security directive record <b>1410</b> for SALARY also permit only users who are members of the human resources department identified via a subject record <b>1450</b> to label files as SALARY via an action record <b>1420</b> and that any denied actions be audited via an event record <b>1430</b>.

p-0367Alice creates a salary report for the company as a secure file <b>1240</b> using, for example, Microsoft Excel and selects the security label <b>1460</b> for the secure file <b>1240</b>, which is incorporated as the security label <b>1336</b> in the secure file <b>1240</b>. Alice sends the secure file <b>1240</b> with the salary report as an email attachment to a distribution list via, for example, Microsoft Outlook. Bob receives the secure file <b>1240</b> and is permitted to open it, since he has a security level <b>1574</b> of 4. However, when Bob attempts to print the report or to copy its content to another document, the enforcement agent prevents him from doing so, as he does not have a clearance record of HR-3. Due to the enforcement agent of Marie's information system <b>200</b>, Marie, who has access to Bob's e-mail, is unable to open the secure file <b>1240</b> because she has only a security level of 2. Bob's denied attempt to print the secure file and Marie's denied attempt to read the secure file are captured in the audit logs of the audit server <b>350</b> for the company. On the other hand, Tom, another human resources manager with a security clearance record with HR-3 has full control over the salary report in the secure file and may copy, modify, or redistribute the secure file according to the rules in the security directive record <b>1410</b> for SALARY.

p-0368If an authorized individual determines that Bob should access to the salary report, a variety of techniques can provide Bob with this ability. One option is to give the identity record <b>1510</b> of Bob a clearance record <b>1570</b> with HR-3, which would allow him full control of the salary report in the secure file <b>1240</b> as well additional authorization on other secure files <b>1240</b> which include a payload <b>1320</b> with a security label <b>1336</b> of HR-3. Another option is to add a rule in the security directive record <b>1410</b> for SALARY that permits printing by all individuals with a general clearance record <b>1570</b> of level 4. Yet another option is to add a rule in the security directive record <b>1410</b> for SALARY that allows anyone in the company with the title of Vice-President or above to print secure files having a security label <b>1336</b> of SALARY.

p-0369If Bob intentionally or unintentionally attempts to forward the secure file <b>1240</b> with the salary report to a colleague, Joe, at another company, Joe may not receive the secure file <b>1240</b>. For example, the rules <b>1416</b> of the security directive record <b>410</b> for SALARY would likely not allow sharing such information with external entities. If Joe did receive the secure file <b>1240</b>, Joe is unable to access the salary report. If Joe does not have the invention (i.e., enforcement agent <b>1262</b> and security policy broker <b>384</b>) running on his information system, the received secure file <b>1240</b> would be unintelligible to his information system <b>200</b>. If Joe does have the invention running on his information system <b>200</b>, it is unlikely that he would have a security level <b>1574</b> of 4 for a security clearance record <b>1570</b> from Bob's company. Additionally, a hacker who managed to pilfer the secure file <b>1240</b> from Alice, Bob, Marie, or Joe would be unable to access the salary report of the secure file without being able to break the encryption and structure of the secure file <b>1240</b>.

p-0370In this example, all users are interacting only with their applications <b>374</b>, such as Microsoft Excel for manipulating spreadsheets and Microsoft Outlook e-mail client. The users do not need to leave their familiar environments. In Alice's case, an additional step is required to assign the security label <b>1460</b> of SALARY to the salary report. She does not need to understand the complexities of the data classification scheme in the company and only needs to know that she must label secure files <b>1240</b> containing salary data as SALARY. The recipients, such as Bob and Marie, of the email with attached secure file of the salary report open the attachment in the same manner as all other attachments are opened. If Bob uses a different spreadsheet program than Alice, for example OpenOffice or Microsoft Works, the embodiment behaves in an identical manner and enforces the security directive <b>1400</b> of SALARY.

p-0371This written description uses examples to disclose various embodiments, which include the best mode, to enable any person skilled in the art to practice those embodiments, including making and using any devices or systems and performing any incorporated methods. The patentable scope is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.