Controlling and tracking access to disseminated information

Technology to control and track the access actions to disseminated information

<p>100. . . system</p><p>102-4. . . user</p><p>106. . . Key storage</p><p>108-12. . . Link chain</p><p>200. . . Key server</p><p>202. . . Key database</p><p>204. . . Key information</p><p>206. . . Key data registration item</p><p>208. . . Registration item</p><p>300. . . Log</p><p>302. . . Link chain</p><p>308-30. . . Cube</p><p>400. . . Strategy manager</p><p>402. . . Link chain</p><p>404. . . Policy definition</p><p>410-6. . . Cube</p><p>500. . . Configuration</p><p>502-6. . . user</p><p>508-16. . . Key storage</p><p>518. . . network</p><p>520-30,602-60,702-12,</p><p>720-28. . . Cube</p><p>900. . . system</p><p>902-4. . . user</p><p>906. . . Message repository</p><p>908-14. . . Link chain</p><p>916. . . Strategy manager</p><p>1000. . . flow chart</p><p>1002-12. . . step</p><p>1100. . . computer system</p><p>1102. . . Busbar</p><p>1104. . . processor</p><p>1106. :. Main memory</p><p>1108. . . ROM</p><p>1110. . . Storage device</p><p>1112. . . monitor</p><p>1114. . . Input device</p><p>1116. . . Cursor controller</p><p>1118. . . Communication interface</p><p>1120. . . Network connection chain</p><p>1122. . . Local network</p><p>1124. . . Host computer</p><p>1126. . . Internet service provider</p><p>1128. . . Internet</p><p>1130. . . server</p>

Specific embodiments are illustrated (but not limited to) in the figures of the accompanying drawings, where similar reference numbers indicate similar elements. In the accompanying drawings:

Figure 1 is a block diagram of the system for controlling and tracking access to disseminated information;

Figure 2 is a block diagram of the key storage;

Figure 3A is a flowchart of the process of deleting a sent message;

Figure 3B is a flow chart of the process of tracking a sending message;

Figure 4A is a block diagram of a system for controlling and tracking access actions to broadcast messages. The system includes log entries;

Figure 4B is a block diagram of a system for controlling and tracking access actions to broadcast messages. The system includes log registration and policy managers;

Figure 4C is a block diagram of various strategies;

Figure 5A is a block diagram illustrating a configuration for controlling and tracking access to data by using multiple key repositories according to a specific embodiment;

Figure 5B is a flow chart of the process of sending a message by associating one of multiple key depositories;

Figure 6A is a flowchart of key layering processing;

Figure 6B is a flowchart of the processing of reading messages with hierarchical keys;

Figure 6C is a flowchart of the process of re-encrypting a message;

Figure 7A is a flowchart of the processing of reading messages offline;

Figure 7B is a flowchart of the processing of separating the message keys into categories;

Figure 8 is a flow chart of the processing of applying a digital signature to a message;

Figure 9 is a block diagram illustrating the configuration of data processing using message storage control and tracking according to a specific embodiment;

Figure 10 is a flowchart of the process of using the message repository to control and track the access to data according to a specific embodiment; and

Figure 11 is a block diagram of a computer system that can implement specific embodiments.

Invention field

Generally speaking, the present invention relates to networked data processing, and particularly relates to a method of controlling and tracking the access of information disseminated by the network.

Background of the invention

Many computers today are connected to one or more networks or the Internet. One of the most widely used communication networks is the international packet data communication network called the Internet. The Internet provides access to a large amount of information and can be used to send electronic mail (email). Internet users such as the Internet have a unique email address. The email address represents the account maintained on the email server. Anyone can remotely send one or more e-mail messages to any of the millions of addresses from a computer and e-mail processing program (e-mail client), and the recipient can use his e-mail client to read it Get the message.

Despite the benefits that the Internet can provide, users have recently discovered important security issues associated with Internet email. First of all, the complexity of the Internet makes it possible for rewards to fall into the hands of unintended third parties. For example, when e-mail is sent over the Internet, the e-mail travels through countless subnets to reach its destination. Many subnets include locations where data is temporarily stored and then sent to the next location. As a result, copies of emails may be stored in countless locations unknown to the sender, even if the sender intends to only provide the email to a specific recipient or a specific group of recipients.

Furthermore, the e-mail is easily sent to other recipients whose original sender is unknown. As a result, although the sender only wants a certain recipient to receive a certain email, the email may be sent to and received by other recipients.

Once the email has been sent over the Internet, it becomes difficult (if not impossible) to delete all copies of the email. Consider a sensitive email sent over the Internet and now want to delete it completely. It is straightforward to locate and delete emails by sending and receiving locations. However, it is difficult (if not impossible) to locate and delete all copies of emails because it is difficult to determine the location of all copies of emails. Since the Internet is a packet-switched network, the reward packet that constitutes a specific message or a complete copy of a message can be stored in the intermediate server of the intermediate Internet between the logical locations of the sender and the receiver; this kind of server The location of the device is unpredictable. In addition, even if copies of all emails are located, privileges or permission may be required to delete the copies. For example, some copies may reside on remote servers in other countries. As a result, deleting all email copies becomes extremely difficult (if not impossible).

These problems are not limited to the Internet. Many companies already have a comprehensive communication network, with countless servers, archives, gateways, and backup systems, where e-mail may be stored.

In addition, these problems are not limited to e-mails, but also apply to all types of information transmitted through communication networks.

Based on the above description, it is necessary to control and track the access to the information disseminated on the communication network. This is a special requirement for an all-encompassing method of controlling and tracking access to data disseminated on a communication network.

Summary of the invention

The foregoing requirements and other requirements and objectives that are apparently self-evident from the following description can be achieved by the present invention. One characteristic aspect includes a method for controlling and tracking the access of disseminated information. In particular, a method is provided to control and track the access of messages from the first node of the network to the second node. According to this method, the first node receives a request for a message identifier that can uniquely identify the message and a key that can be used to encode the message. The message identifier and key are generated in response to the request. Both the message identifier and the key are provided to the first node to allow the message to be encoded with the key to generate an encoded message. A request for the key from the second node is received. The key is supplied to the second node to allow the encoded message to be decoded, and the key is used to retrieve the message. Finally, the key is deleted based on the specified key policy standard to prevent the copy of the encoded message from being decoded.

According to another characteristic aspect of the present invention, there is provided an apparatus for controlling and tracking the access of messages from a first node to a second node in a network route. The device includes a storage medium and a key repository which can be communicatively coupled to the storage medium. The key repository is configured to receive a request from the first node for a message identifier of a unique identification message and a key used to encode the message, and generate a message identifier and a key in response to the request. The key repository is also configured to provide both the message identifier and the key to the first node and allow the message to use the key encoding to generate an encoded message. The key repository is further configured to receive a request for the key from the second node, and provide the key to the second node to allow the encoded message to be decoded, and the message can be extracted using the key. Finally, the key repository is configured to delete the key based on the specified key policy standard to prevent the copy of the encoded message from being decoded.

Schematic description

Specific embodiments are illustrated (but not limited to) in the figures of the accompanying drawings, where similar reference numbers indicate similar elements. In the accompanying drawings:

Figure 1 is a block diagram of the system for controlling and tracking access to disseminated information;

Figure 2 is a block diagram of the key storage;

Figure 3A is a flowchart of the process of deleting a sent message;

Figure 3B is a flow chart of the process of tracking a sending message;

Figure 4A is a block diagram of a system for controlling and tracking access actions to broadcast messages. The system includes log entries;

Figure 4B is a block diagram of a system for controlling and tracking access actions to broadcast messages. The system includes log registration and policy managers;

Figure 4C is a block diagram of various strategies;

Figure 5A is a block diagram illustrating a configuration for controlling and tracking access to data by using multiple key repositories according to a specific embodiment;

Figure 5B is a flow chart of the process of sending a message by associating one of multiple key depositories;

Figure 6A is a flowchart of key layering processing;

Figure 6B is a flowchart of the processing of reading messages with hierarchical keys;

Figure 6C is a flowchart of the process of re-encrypting a message;

Figure 7A is a flowchart of the processing of reading messages offline;

Figure 7B is a flowchart of the processing of separating the message keys into categories;

Figure 8 is a flow chart of the processing of applying a digital signature to a message;

Figure 9 is a block diagram illustrating the configuration of data processing using message storage control and tracking according to a specific embodiment;

Figure 10 is a flowchart of the process of using the message repository to control and track the access to data according to a specific embodiment; and

Figure 11 is a block diagram of a computer system that can implement specific embodiments.

Detailed description of preferred embodiments

The following description is used for explanatory purposes, and specific details are listed for a thorough understanding of the present invention. However, it is obvious that the present invention can be implemented without these specific details. In some cases, well-known structures and devices are illustrated in block diagram form to prevent unnecessary obscuring of the present invention.

The features and characteristics of various specific embodiments are described in further detail in the following sections: (1) Introduction; (2) System overview; (3) Make the disseminated data inaccessible; (4) Track the storage of disseminated data (5) Key management; (6) Multi-key storage application; (7) Key layering; (8) Key change; (9) Offline application; (10) Message confirmation; (11) Delisting of messages as confidential ; (12) Message storage application; and (13) Execution agency.

1 Introduction

Explain the control and tracking of access to disseminated information. Usually the data exchanged between users is protected by any one of a variety of encoding methods. One kind of encoding is encryption, for example, but any kind of encoding can be used. The data used to encrypt data is exchanged between users called "keys" and is only maintained in the key repository. The user must obtain the key from the key repository to encode or decode, encrypt or decrypt the data, and then destroy the user's copy of the key or invalidate it in other ways. The key management strategy is used to control access to the keys maintained by the key repository.

This method can effectively control and track the access to the rewards at any location known or unknown to the user. In addition, copies of data at all locations become inaccessible without knowing where the copies reside. This method can be applied to any type of data in any format, and the present invention is not limited to any type of data or any type of data format. The data includes text data, voice data, graphic data, and e-mails, for example.

2. Structure overview

Figure 1 illustrates a system 100 for controlling and tracking access actions to disseminated information according to a specific embodiment. The system 100 includes users 102 and 104 and a key repository 106. As used in this document, the term "user" is similar to a location, node or customer of a network. Nodes include physical or logical locations or devices. For example, the node may be a network terminal station such as a workstation, a personal computer, a server or an equivalent device.

The users 102 and 104 are logically coupled by the connection chain 108 and can communicate via the connection chain 108. The user 102 and the key repository 106 communicate through the connection link 110. The user 104 and the key repository 106 communicate through the connection link 112. The connection chains 108, 110, and 112 can be implemented using any mechanism to provide data exchange between the users 102, 104 and the key repository 106. The connection chains 108, 110, and 112 include, but are not limited to, network connection points, lines, optical fiber connection chains, and wireless communication connection chains, for example.

The connection chain 108, 110, 112 includes a number of connection points, networks or the Internet. For example, the connection chain 108 includes Internet connection points. In this way, the users 102, 104 and the key repository 106 can be located on the same node or distributed in different nodes. The present invention is not limited to the practice of any specific connection chain 108, 110, 112.

The structure of the key repository 106 and, according to a specific embodiment, the operation of the system 100 to control and track the access of disseminated information will now be described with reference to FIG. 1. The following description uses the message sent by the user 102 to the user 104 for description. As used in this text, the term "message" means the body of the reward material that is formatted in any way to transmit the reward. The message is, for example, an email message, but the message may include a packet, a database, or a message sent at any extraction level within the network, its delivery mechanism, or its application.

First, the user 102 generates a message to be sent to the user 104. Then the user 102 requests a message identifier (message ID) and a key from the key repository 106 through the connection chain 110.

In response to this, the key repository 106 generates and stores a unique message ID and a unique key associated with the generated message ID. Ideally, the generated message ID is sufficiently unique and complex to prevent or at least reduce the possibility of users requesting and collecting keys in a systematic manner to decode the messages that are subsequently intercepted.

Figure 2 is a block diagram illustrating a specific embodiment of the key repository 106. The key repository 106 can be implemented in a variety of ways, and the present invention is not limited to specific key repository embodiments.

In the configuration in FIG. 2, the key repository 106 includes a key server 200 and a key database 202. The key server 200 generates a unique message ID and key in response to the user's request. The key server 200 also stores the generated message ID and key in the key database 202. The key server 200 also enables the stored message ID and key to be retrieved by the key reward database 202 in response to the user's request, which will be described in detail later. The key database 202 can be implemented as any type of electrical or non-electrical storage device, but is usually a non-electrical storage device such as one or more disks. The key database 202 can utilize a commercial database server system such as Oracle or Sybase database server.

In this example, the message ID and key are stored in the key data 204. The special key data 204 includes one or more key data registration items 206 corresponding to the paired message ID/key. For example, item 208 corresponds to the message MSG1 with the key KEY1. Each registration item 206 also contains one or more attributes of the corresponding message specified by the intermediary data. The corresponding messages are used to manage key access and deletion according to multiple key management strategies, which will be described in detail later. Special item 208 includes intermediary material MD1.

In some cases, the preservation of the key repository 106 is quite important. It is particularly concerned that unauthorized users may access the key repository 106 and change or destroy the data contained in the key repository 202, such as the message ID and the key. In this way, much caution is required to prevent or at least reduce the possibility that unauthorized users can access and change or destroy the data stored in the key database 202.

For example, the key repository 106 can be implemented in a secured entity structure, which restricts unauthorized entities from accessing the key repository 106. The key repository 106 can also be implemented on the security interface of the connection chain 110 and the connection chain 112. The key repository can also use a secure communication protocol to reduce the possibility of unauthorized users accessing the key repository 106. For example, when a user requests a key, he may be required to provide a unique user ID to the key repository 106 to verify that the user is authorized to obtain the key from the key repository 106. In addition, the key repository 106 can be implemented with one or more backup key databases to maintain data.

There are similar concerns regarding the security of the connecting chain 110 and the connecting chain 112. In particular, there may be concerns that unauthorized users will receive the message ID and key sent through the connection chain 110 and the connection chain 112. Therefore, according to a specific embodiment, the connection chain 110 and the connection chain 112 are secured, so as to reduce the possibility of a third-party stealer intercepting the message ID and key sent through the connection chain 110 and the connection chain 112. After generating and storing the unique message ID and unique key, the key repository 106 provides the message ID and the associated key to the user 102. The user 102 uses the key to encrypt the message to be sent to the user 104 to generate an encrypted message. Any type of encryption can be used to generate encrypted messages, and the present invention is not limited to any specific type of encryption. The appropriate encryption method is Data Encryption Standard (DES) encryption. The user 102 then destroys or otherwise renders the local copy of the key unusable.

Then the user provides the encrypted message and the message ID to the user 104 through the connection chain 108. The user ID can be separated from the encrypted message or can be provided to the user 104 together with the encrypted message. According to a specific embodiment, the message ID can be attached, for example, to the beginning or end of the encrypted message. As explained above, the connection chain 108 includes connection points through the Internet or other connection networks. Because the message is encrypted, it is impossible or at least computationally infeasible, so anyone cannot determine the content of the encrypted message without using the correct key.

At this point in the example processing, the user 104 owns the encrypted message from the user 102 and the message ID. However, the user 104 cannot retrieve the encrypted message content received from the user 102. Therefore, according to a specific embodiment, the user 104 requests a key from the key repository 106 to decrypt the message received from the user 102. If the message ID is already attached to the encrypted message, the user 104 can extract the message ID from the encrypted message.

The user 104 provides the message ID to the key repository 106 to identify which key the user 104 requests. The key repository 106 retrieves the key associated with the message ID received from the user 104 and provides the key to the user 104. The user 104 uses the key to decrypt the encrypted message and retrieve the original unencrypted message. The user 104 then destroys or otherwise renders the local key copy useless.

Once the user 104 receives the original message, the user 104 can distribute the original message to other users in the form of an unencrypted clean script. For example, if the user 104 is using or executing a specific embodiment under the control of an operating system with a user graphical interface, such as Windows NT, Mac OS or Solaris operating system, the user 104 can use the operating system "Clip and Paste" tool to copy unencrypted text. Therefore, in order to reduce the distribution of unencrypted text by the user 104 to other users, various controls can be added to the user who decrypts the message.

According to a specific embodiment, a mechanism is provided that allows users to view unencrypted text, but cannot provide any form of unencrypted text for distribution to other users. For example, the user 102 and the user 104 can be implemented using a shell, which automatically retrieves the key from the key repository 106 and displays the message to the user 102 and the user 104 in unencrypted text. The application shell call operation function displays unencrypted text in the operating system window, but the window cannot be used or is prevented from using the editing function. Such an application shell is an example of a mechanism that prevents users from receiving confidential information that can be copied or further disseminated.

According to another specific embodiment, when the encrypted message is converted into unencrypted text, the key repository 106 is notified so that it can track the location of the unencrypted message.

3. Make broadcast messages inaccessible

The foregoing description shows that in order for the user 104 to determine the content of the encrypted message received from the user 102, the user 104 must request and receive the key of the specific encrypted message from the key repository 106. Without the correct key, the encrypted message is useless to the user 104.

At a certain point in time, it is hoped that all copies of specific dissemination information will become inaccessible. For example, the dissemination material may contain valuable company secrets and is distributed to a group of specific employees, and it is hoped that all copies of the dissemination information containing the secrets may be inaccessible. The decision to make certain dissemination materials inaccessible is typically based on various strategies or management considerations, which will be detailed later.

Assuming that the data sent by the user 102 to the user 104 becomes inaccessible, according to a specific embodiment, the key associated with the message is deleted by the key repository 106. The associated message ID is also deleted by the key repository 106 because the message ID becomes useless after the key is deleted. The key is deleted by the key repository 106 based on a specific key policy standard evaluated by the key repository or in response to a user's request. This characteristic aspect of the present invention will be described later on key policy management.

If the user 102 and the user 104 destroy the copy of the key they received from the key repository 106, there will be no remaining or existing copy of the key to decrypt the message. Without the correct key, it is impossible or at least computationally infeasible to extract the original message from any copy of the encrypted message originally generated by the user 102, no matter where the copy resides. For example, suppose that the connection chain 108 is a connection across an open and unreliable network such as the Internet. It is further assumed that the encrypted message sent by the user 102 to the user 104 causes several or even multiple copies of the encrypted message to be generated and stored in various locations on the Internet. Without the correct key, it is impossible or at least computationally feasible to extract the original message from a copy of the encrypted message. All copies of encrypted messages become inaccessible regardless of where they reside, indicating that each copy is useless. As a result, the encrypted message copy does not need to be individually located by the previous method.

In an alternative specific embodiment, the user 102 or the user 104 can execute an email client, and the message that the client's configuration is that the key has been deleted is not displayed. For example, the deleted flag can be associated with each message storage stored by the email client. For example, the deleted flag can be associated with each message storage stored by the email client. The deletion flag indicates that the key associated with the message has been deleted from the key repository. Each time the email client is initialized, the client checks the key repository to find the key matching the message stored in the folder or file box maintained by the email client. If the key has been deleted, the email client deletes the associated message from the file folder, file box or associated display device to delete the associated display screen. In addition, the email client checks the associated key when the folder or file box is displayed. In another alternative, when the user selects and tries to open or display a message, the email client checks the key.

Figure 3A is a flowchart of the process of deleting the sent message. Usually processing starts with a user request to delete the sent message. At block 308, the process verifies that the user has determined that the user is authorized to request deletion. Usually verification involves determining whether the user is related to the message being sent in some way. For example, verification also involves testing whether the requesting user is the author of the message or the original sender.

In block 310, the process searches for the key associated with the message in the key repository. At block 312, the key is deleted from the key repository. In block 314, the message ID and key associated with the message are deleted from the key repository. As shown in block 316, all copies of the message become unreadable.

In an alternative embodiment, the process also accesses the log entry 300, as shown in block 328. The form, structure and general functions of the log entry 300 will be described in detail later. Block 328 involves opening the log entry, from which the information of each registration item whose association is to be inaccessible is read, and the identity of each user who has converted the message into unencrypted text is determined. At block 330, the process notifies each user identified by the log entry that the message has become inaccessible. In response to this, each user is expected to remove its unencrypted version of the message from the local storage device.

4. Track the access actions to disseminated data.

In some cases, it is desirable to know which user (if any) has read a particular message or email. So I hope to know who (if any) has requested the key and what kind of information the key is associated with. According to a specific embodiment of the present invention, log tracking is used when the key is issued.

FIG. 4A illustrates that the system 100 includes a login log 300, which is logically coupled to the key repository 106, and uses a connection chain 302 to track the issuance and request of the key. The connection chain 302 can be implemented using any mechanism that can provide data communication between the key repository 106 and the log entry 300. Every time a new key is issued, the log 300 is updated to directly or indirectly identify the new key, the message ID associated with the new key, and the specific user to whom the new key is sent. Further, every time a key is requested and provided to the user, the log 300 is updated to indicate that the key has been requested and provided to the user.

With reference to the previous example, when a new key is sent to the user 102 to encrypt a message to be sent to the user 104, the log 300 is updated to instruct to issue a new key to the user 102 for a specific message. Similarly, when the user 104 requests and is sent a key to decrypt the message received by the user 102, the log 300 is updated to reflect the user 104 request and is sent to the key.

Figure 3B is a flow chart of the process of tracking and sending messages. At block 320, a log is formed and stored. In block 322, the process generates and sends a new key and associated message identifier to the requesting user. Block 322 can be used as part of step 3 in Figure 1 (for example). At block 324, the log is updated to store the message that the new key was sent, along with information identifying the user and other related information. For example, log entries include the IP address of the requesting user, the associated account name and account number of the requesting user, the server name, or the index path of the location where the key is stored in the user's machine, or other machine-specific information.

At block 326, the log is queried or accessed. The log can be queried as part of block 328 in Figure 3A, or in other cases when the rewards stored in the log become useful.

According to this method, the ability to track the access of disseminated data provides multiple effects. For example, to understand all recipients of a specific message requesting a key for a specific message. Including later recipients, the original recipient can send a copy of the message to the later recipient without notifying the original sender. It further includes unintended recipients who obtain a copy of a specific message and request a key to decrypt the message. For a sufficiently unique message ID, the registration item requesting the key of a specific message must receive or otherwise obtain a copy of the message.

Further, the tracking capability provides a record of the location where the key is sent by the key repository 106 and the current location. Such information can be used when a specific key is to be deleted from the key repository 106 because all copies of the specific key must be deleted to ensure that the corresponding message will not be decrypted.

For example, in the previous example, the log 300 contains data indicating that the key was sent to the user 102, and the message was generated by the user. The log 300 also contains data indicating that the user 104 requests a key for the message sent by the user 102 to the user 104 and the key has been provided to the user 104. As mentioned above, according to this method, the key sent to the user 102 is discarded or otherwise rendered useless after the user 102 has used the key to encrypt the message. In addition, after the user 104 has decrypted the encrypted message received by the user 102, the user 104 discards the key provided by the key repository 106. If the key is deleted by the key repository 106, the log 300 can be used to identify the location where the key copy may reside, in this example, the user 102 and the user 104. Users 102 and 104 can be contacted to make sure that their key copies have been deleted.

Using the log 300 to track the location of the key can also be used for offline purposes, which will be described later. Another advantage is that when the key is deleted, the corresponding message becomes inaccessible, even though it still occupies storage space. Therefore, according to a specific embodiment, when the key is deleted by the key repository 106, the user who generated the message is notified, or when the key repository 106 is inquired about that the message has become inaccessible, the user can delete his message copy. In the same way, the log 300 can be used to notify users who previously requested the key, or to conduct a sample survey of the users who may be found in the key repository 106, and notify that the key has been deleted, so these users can delete their corresponding message copies.

The log 300 can be located at the same node of the key repository 106. In addition, in a distributed configuration, the log 300 can be located at different nodes where the key repository 106 resides. In addition, although the key tracking function provided by the log 300 has been described and described as being implemented by the separate log 300, the tracking function can be implemented in the key repository 106. In this way, the present invention is not limited to the implementation of the key tracking function in the separate log 300 or a part of the key repository 106.

5. Key management

As mentioned earlier, by deleting all the key copies used to encrypt the data, the data can be made inaccessible. The decision to delete a key is usually made based on some specific key policy considerations. Explain two key management methods, including user-based key management methods and third-party key management methods.

A. User-based key management User-based key management usually involves the user who issued a specific key to manage the deletion of the specific key based on the specific key policy standard. Key policy standards include many different types of standards such as time, subject, or other classifications. For example, referring to FIG. 4A, suppose that the user 102 requests a key and multiple keys are sent to a message to be sent to other users, as shown in FIG. 1. The user 102 then uses the key to generate an encrypted message and sends the encrypted message to one or more recipients. The user 102 later decides to make one or more disseminated messages inaccessible according to the key policy standard 306. The user 102 deletes the key associated with the specific message from the key repository 106, so that the specific message generated by the user 102 becomes inaccessible.

According to a specific embodiment, the user 102 must be provided with a user ID that is valid for the key repository 106, and the key repository 106 verifies that the user 102 is the creator of the specific message. For example, the user ID of the user requesting the message ID and the key can be stored in the registration item 206 of the key data 204 as the intermediary data (Figure 2).

In addition, the user 102 can make the message inaccessible based on the subject of the message. For example, the user 102 may wish to make all broadcast messages related to a specific topic inaccessible. The user 102 instructs the key repository 106 to delete the keys of all messages generated by the user 102 related to a specific subject. The user 102 instructs the key repository 106 to delete the keys of all messages known to the user 102 to be associated with the specific subject. In addition, the user 102 can instruct the key repository 106 to delete all the keys issued to the user 102 related to the specific subject. In this case, the key server 200 checks the intermediary data contained in the registration item 206 to identify and delete the key of the message related to the specific subject.

This is a standard example of multiple key policies used by the user 102 to selectively make disseminated messages inaccessible. Countless other categories and standards can be used, and the present invention is not limited to making messages inaccessible based on any specific key management policy standard.

B. Third-party key management Third-party key management methods usually involve the use of third-party policy managers to manage the access to messages. FIG. 4B illustrates that the policy manager 400 is logically coupled to the key repository 106 to provide third-party key management through the connection chain 402 according to a specific embodiment. The policy manager 400 executes the key vault 106 usage policy to control access to messages based on prescribed key policy standards, such as the standards discussed above for the user 102. The strategy is executed through communication between the strategy manager 400 and the key repository 106. Each strategy is defined by the stored rewards in the form of one or more strategy definitions 404, which can be accessed by the strategy manager 400.

For example, suppose as in Figure 1, the user 102 is issued a key to encrypt a specific message. The user 102 encrypts the specific message to generate an encrypted message, and then distributes the encrypted message to a number of users including the user 104. The policy manager 400 can execute the key policy standard, which stipulates that only the user 104 can read the message. The execution method is to store the policy definition in the policy manager 400, and store a reference to one of the policy definitions 404 in the key repository 106, for example, store the intermediate data in the key data 204. When the user attempts to request a key from the key repository 106 to read the message, the key repository 106 checks whether the reference defined by the policy is stored in association with the requested key. If so, the keystore requests the policy manager 400 to provide instructions on how to implement the policy. The policy manager 400 instructs the key repository to issue the key only when the requesting user is the user 104.

Each strategy can define one of several forms. Figure 4C is a block diagram of an example strategy type. As shown in block 410, one type of strategy involves identifying a single user as an authorized reader of the message. Such strategies can be defined and stored in the form of logical condition statements, including one or more objects joined by one or more operands or associated result actions to be taken. Each object corresponds to a role, user, message or node.

An example of the strategy is shown in block 412, where the authorized readers include a group. This strategy is defined as "if message = message 1, then authorized reader = {Matthewson, Malis, Mandolin}". This strategy instructs that only users Matthewson, Malis, and Mandala can read the message message 1. In a specific embodiment, each strategy can be defined and stored using a strategy tool, which is executed by the users 102 and 104.

The key policy standard can also be more complicated. For example, the policy standard may stipulate that the only users who can read messages are employees of the specific group, or those who play a specific role in the enterprise, or those who have a certain degree of authorization in the enterprise.

For example, suppose that the key policy standard specifies the expiration date of the message, as shown in block 414. In other words, according to the key policy standard, any message generated before the specified expiration date becomes inaccessible. In this case, the policy manager 400 can delete all keys corresponding to the message generated before the expiration date, regardless of the user who generated the message. If this item is not reached, the policy manager 400 instructs the key server 200 to delete all the keys corresponding to the message before the expiration date.

Additional information about the message other than the message ID may be needed to test the key policy standard to see if the key has been deleted. This information can be stored in the key data 204 as intermediary data. In addition, this information can be stored in log 300.

User-based key management and third-party key management are not mutually exclusive methods but can be used at the same time. Depending on the requirements of a specific purpose, any policy standard can be adopted, and the present invention is not limited to any specific key policy standard.

According to a specific embodiment, the access and deletion policies are applied to each set of messages, as shown in block 416. In this embodiment, the key repository 106 establishes and maintains multiple sets of messages. Message grouping can be based on a variety of factors and themes. The messages can then be assigned to one or more groups by the users 102, 104 or the policy manager 400. Then access and deletion strategies can be applied to each group of messages. For example, suppose three subject groups A, B and C are established. The original message and the new message can be assigned to each group based on the message attributes. Various strategies can be applied to message groups A, B and C. For example, a policy may stipulate that only employees of a specified level or above can access the messages belonging to the message group A. Another policy stipulates that all messages belonging to message group B are inaccessible.

The two major differences between the third-party key management method and the user-based key management method are that the policy manager 400 controls the user to access any information, and also makes the information inaccessible. According to the user-based key management method, a specific user can control which recipient is issued a key to access the generated message. In addition, a specific user can only make messages generated by the specific user inaccessible and cannot make messages generated by other users inaccessible.

For example, suppose that the user 102 generates a specific message and the key repository 106 sends a key to encrypt the specific message. The user 102 then uses the key to encrypt the message, and distributes the encrypted message (referred to as message #4422) to the user 104. Suppose further that the user 104 also receives an encrypted message from a third user (referred to as message #5678). The user 102 cannot control whether the user 104 is sent a key to decrypt the message #5678, but can control whether the user 104 is sent a key to decrypt the message #4422. In addition, the user 102 cannot control whether the message #5678 becomes inaccessible because the user 102 has not been sent the key of the message #5678. However, the user 102 can instruct the key repository 106 to delete the key of the message #4422, making the message #4422 inaccessible, because the key of the message #4422 was sent to the user 102.

The policy manager 400 may be located at the same node of the key repository 106, or may be located at a different node where the key repository 106 resides. In addition, although it has been described that the third-party key management function provided by the policy manager 400 and executed by the separate policy manager 400, the third-party key management function can be implemented in the key repository 106. In this way, the present invention is not limited to the third-party key management function implemented by the separate policy manager 400 alone or as a part of the key repository 106 alone.

In some cases, it is desirable to ensure that certain messages do not become inaccessible. According to a specific embodiment, the message retention policy is used to ensure that certain messages cannot become inaccessible. The message retention strategy is implemented by separately maintaining the key pair that can meet the specified retention strategy rate. For example, the retention policy standard stipulates that all messages related to a specific subject are retained. In this example, all copies of messages related to a specific topic are stored in non-electrical storage media, and copies of the associated key are stored in the backup key repository. A group of special permission and control executables are used to control the access to the backup key repository. Message retention is particularly useful for e-mail content, where the company wishes to retain certain e-mails, such as all e-mails related to a particular lawsuit.

6. Multi-key storage application

The method described in this case can be applied to applications that use two or more key repositories. For example, the key storage capacity limitation requires the use of multiple key storage to manage a large number of messages. In other cases, it may be desirable to use several key repositories and to logically organize the key repositories by organization, project, or theme. For example, a company with three subsidiaries may use a separate key vault for each subsidiary. In another example, a company with five product lines uses a separate key repository 106 for each product line.

It is also hoped to provide a backup key repository to prevent users from deleting keys from all information generated by users. For example, an unhappy employee tries to retaliate against the employer by deleting the key of all messages generated by the employee. Special permission and control can be used to control the deletion of keys from the backup key repository. In addition, a legal key deletion requires that the key be deleted from all key stores.

FIG. 5A is a block diagram illustrating a configuration 500 for controlling and tracking data access according to a specific embodiment. The configuration 500 includes users 502, 504 and 506 and key storage 508, 510, 512, 514 and 516 which are coupled to the network 518 in a communication manner. The network 518 can be any type of network such as a local area network (LAN), a wide area network (WAN) or even the Internet.

According to a specific embodiment, for the purpose of multiple key storage, when the user requests a key, the key storage provides the message ID, the key, and the key storage ID to the user. The user then provides the key repository ID to any other user who wants to send the encrypted message, and the recipient knows who the user can query the key to decrypt the encrypted message.

For example, suppose user 502 wants to send encrypted according to the method described in this document

Message to user 502, users 504 and 506. The user 502 requests the key from the key repository 514. The key repository 514 provides the message ID, key, and repository ID to the user 502. The repository ID specifies the key of the key repository 514 to send the message, and the user 502 uses the key provided by the key repository 514 to generate an encrypted message. When the user 502 provides encrypted messages to the users 504 and 506, the user 502 also provides the repository ID. When the users 504 and 506 want to decrypt the encrypted message obtained from the user 502, the users 504 and 506 check the repository ID provided by the user 502 to determine which key repository 508, 510, 512, 514, or 516 has the key of the message. The users 504 and 506 then request the key from the key repository 514 to decrypt the encrypted message from the user 502.

Figure 5B is a flowchart showing the process of forming and sending messages based on multiple banks.

In block 520, the first user forms a message to be sent to the second user. In block 522, the first user requests a key from one of the plurality of key repositories. In block 524, the selected key repository provides a new message ID, key, and repository identifier in response to the request. In block 526, the user generates an encrypted message and sends the message. In block 528, the message is sent to the second user and the library identifier is attached to the message or associated message.

In block 530, the second user determines the bank identifier and contacts the bank to obtain the key of the message. Then the second user reads the message.

One or more of the foregoing steps can be performed in a manner that is not visually observed by the first user, the second user, or both. For example, the email client of the first user can be configured to automatically select one of the depositories and generate the identifier of the depository. At the receiving end, the email client of the second user can be configured to automatically determine which repository is used to generate the key, and contact the repository to obtain the key.

7. Key layering

In some cases, it is desirable to apply the method described in this case to the received message, which was previously encrypted using the method described in this case. Key layering is a way to manage messages previously encrypted using the method described in this case.

The key layering approach usually involves encrypting a message that has been previously encrypted using the approach described in this case without removing the previous encryption. For example, referring to Figure 1, suppose that the user 104 receives a message encrypted by the user 102 according to the method described in this case. Assume that the user 104 wishes to immediately send an encrypted message to another user (not shown in the figure) without decrypting the message. One method is for the user 104 to simply send encrypted messages to other users without changing the encrypted messages.

According to the key layering approach, the user 104 encrypts the encrypted message with another key to generate a double-encrypted message. If this item is not reached, the user 104 first requests a new message ID and key from the key repository 106. Then the user 104 generates a double-encrypted message by one of the aforementioned two methods.

According to the first method, the user 104 encrypts the encrypted message and the original message ID with the new key, and then attaches the new message ID to the double-encrypted message. In this way, the original encrypted message and the original message ID are encrypted in the second layer of encryption.

According to the second method, the user 104 extracts the original (unencrypted) message ID from the encrypted message, encrypts the previously encrypted message with the new key, and then attaches the original message ID and the new message ID to the double-encrypted message. Then the user 104 sends a double-encrypted message to other users.

Figure 6A is a flowchart illustrating these methods. In block 602, the encrypted message is received by the user. An encrypted message is a message that has been formed and sent by another person in the system, for example, according to the processing and system shown in Figure 1. In block 604, the receiving user requests a new key and message ID for the received message from the key repository.

In the first method, as shown in block 606, the receiving user uses the new key to re-encrypt the received message and its message ID. The message received in this way is now double-encrypted. In block 608, the receiving user attaches the new message identifier to the double encrypted message. At block 616, the receiving user sends the message to another recipient.

In the second method, as shown in block 610, the original message ID is extracted. In block 612, using the new key obtained in block 604, the message is encrypted a second time. In block 614, both the original message ID and the new message ID are attached to the double-encrypted message. At block 616, the message is sent.

The method used by the receiver to retrieve the original unencrypted message depends on which method the user 104 uses to generate the double-encrypted message. Figure 6B is a flow chart of the two methods that can be used. In block 620, the user receives the sent double encryption message. If the first method is used to generate a double-encrypted message, as shown in block 622, the receiver extracts the new message ID from the double-encrypted message. At block 624, the user requests a new key from the key repository 106. In block 626, the receiver uses the new key to decrypt the double-encrypted message to retrieve the original encrypted message and the original message ID. The recipient then requests the original key from the key repository, as shown in block 628. Once the recipient receives the original key from the key repository 106, the recipient decrypts the encrypted message and retrieves the original (unencrypted) message, as shown in block 630.

If the second method is used to generate a double-encrypted message, as shown in block 632, the recipient extracts the original message ID and the new message ID from the double-encrypted message. The recipient then requests the original key and the new key from the key repository, as shown in block 634. The recipient then uses the new key to decrypt the double-encrypted message and extract the original encrypted message, as shown in block 636. The recipient then decrypts the original encrypted message and extracts the original unencrypted message, as shown in block 638. After performing either method, the recipient user can read the message, as shown in block 640.

Using the key layer method to retrieve encrypted messages in this way requires the recipient to obtain the keys of each layer of encryption from the key repository 106, and then use the key to remove the layers of encryption.

The key layering approach provides several advantages due to single-key encryption. First of all, key layering provides additional protection against third-party theft, because layered encryption makes it more difficult for a stealer to retrieve the original message. In particular, the stealer must obtain all the keys or consume a lot of computing resources to determine the key.

Secondly, key layering can increase control so that the entity that caused the last outermost encryption cannot access the message. In the previous example, it is assumed that the user 104 received the encrypted message from the user 102 but the user 104 did not encrypt the message. Since the user 102 generates an encrypted message, the user 102 can control the encrypted message to become inaccessible. The reason is that the user 102 can control whether the corresponding key contained in the key repository 106 is deleted. The key repository 106 and the policy manager 400 can also control the keys, but it is not important for this example. What is important is that if the user 104 does not further encrypt the encrypted message obtained by the user 102, the user 104 cannot control the encrypted message to become inaccessible. In this case, if the user 104 wants to make the encrypted message inaccessible, the user 104 must rely on the user 102. This feature of the present invention is very important for many applications.

For example, consider a situation where Company A and Company B separately implement the methods described in this case to control and track access to disseminated information. Suppose that company A receives a large number of encrypted messages from company B on a regular basis, which are generated using company B's system. If Company A wants to make one or more encrypted messages inaccessible using the method described in this case, the corresponding key must be deleted from Company Bs key repository. As a result, Company A must rely on Company B to delete the corresponding key from its key repository for Company A who wants to become inaccessible to the encrypted message.

The key layering approach can solve this problem, allowing Company A to control the encrypted messages received from Company B to become inaccessible. Company A performs key layering on part or all of the encrypted messages received by Company B. This ensures that company A can make the key hierarchical message inaccessible by deleting the corresponding key from the key repository of company A. In this case, Company A cannot control the unencrypted messages of Company A and become inaccessible. The key layering method can be used to add any new encryption layer of any number of layers to the original encryption of any number of layers, and the present invention is not limited to a specific number of original layers or a specific number of new encryption layers.

8. Change the key

Changing the key is another way to manage messages that have previously been encrypted using the method described in this case. Generally speaking, changing the key involves replacing one or more previous encryptions with one or more different layers of encryption.

Referring to Figure 1, suppose that user 104 receives a message encrypted by the method described in this case from user 102. According to the key modification method, the user 104 first requests the original key from the key repository 106 and decrypts the encrypted message to extract the original (unencrypted) message. Then the user 104 obtains the new message ID and key from the key repository 106 and uses the new key to generate a new encrypted message. Then the user 104 sends the new encrypted message to other recipients. This way of changing the key can remove the original encryption layer and replace it with a new encryption layer.

Figure 6C is the flow chart of the message rekeying process. In block 650, the user receives the encrypted message. At block 652, the user requests the original key from the key repository. In block 654, the user decrypts the received message using the original key to obtain the decrypted message.

In block 656, the user requests the new key and message ID from the key repository. In block 658, the user encrypts the message with the new key, and then sends the message as shown in block 660. One or more of the foregoing steps can be performed in a manner invisible to the recipient user. For example, the recipient user can perform an email client, and the email client performs the aforementioned steps when the user selects the "send" or "reply" function for a specific message.

Changing the key to encrypt messages provides several effects. First, changing the key makes it more difficult for a stealer to restore the original (unencrypted) message. For example, the thief intercepted or determined the original key by calculation, and now must obtain a new key.

Second, changing the key can control the message so that the last (outermost) encrypted entity makes the message inaccessible. In the previous example, the user 104 has control over making the encrypted message inaccessible because the original encryption is replaced by the encryption made by the user 104. But the change key also provides control over the access to encrypted messages. Using the key layering method, all the keys used to provide each layer of encryption are required to retrieve the original (unencrypted) message. If a user controls one of the keys, causing one of the keys to be deleted from the key repository, the original (unencrypted) message cannot be retrieved. This risk can be eliminated by changing the key because the previous layers of encryption have been removed and a new layer of encryption has been added.

Consider the previous example where Company A received an encrypted message from Company B. Company A uses the key change method to replace one or more layers of encryption applied by Company B with one or more of its own encryption layers. In this way, company A can control the access of encrypted messages and can also make encrypted messages inaccessible. It should be noted that the key change method can replace any previous encryption layer with any new encryption layer, and the present invention is not limited to the use of a specific layer.

9. Offline application purpose.

The present invention can be applied to offline use, and the user wants to view the message without coupling to the key store 106 in a communication manner. For example, a user wants to use a portable computer to view encrypted messages.

According to a specific embodiment, the user wishes to view messages that are simultaneously decoupled or unlinked from one or more key repositories, and the key is obtained from one or more key repositories and stored. For example, the user can request all the keys sent to the user by any key repository, allowing the user to view any message generated by the user. The user can also request the keys of all messages received by the user. Allow the user to view any message accepted by the user. It is assumed that the user has downloaded the encrypted message to the offline system. The key can be locally stored in an electrical or non-electrical storage device. Then the user decrypts any information that the user needs to obtain.

Referring to FIG. 4A, suppose that the user 102 plans to unlink from the key repository 106, but wants to read some encrypted messages stored locally. The user 102 obtains the key from the key repository 106 and stores the key for any message desired to be viewed. The log 300 is used to track which key is sent to the user 102. Then even if the user 102 is unlinked from the key repository 106, the user 102 can still decrypt the message that the user 102 has obtained the corresponding key in advance.

A possible problem with offline applications is that the key removed by the sender's key repository is no longer controlled by the sender's key repository, but may be controlled by any entity that obtains the key. As a result, deleting a specific key from the key repository does not guarantee that the corresponding message can no longer be decrypted because the copy of the key may reside in offline users. In addition, the key obtained by the user may be distributed to other users when the user connects to the network again.

Therefore, according to a specific embodiment, a specific offline user is configured such that when the specific offline user is connected to the key repository again, all the locally stored keys of the offline user are deleted. According to a specific embodiment, the key stored offline is securely stored to prevent or at least reduce the chance that an unauthorized user may obtain the key. For example, the offline key can be protected by a passcode that only the user knows and stored in the encrypted block. As another example, the offline key can be stored in an electrical RAM card, which can be erased by removing the power source. As another example, the offline key can be stored in the chip card and can be taken out and kept by the user.

Figure 7A is a flow chart of a summary of offline message processing. At block 702, the user receives one or more messages that have been formed using the system of Figure 1. The user is a portable computer or an associated portable computer such as a laptop connected to the network in the system in Figure 1.

In block 704, the user requests, receives, and locally stores all keys from the key repository, and all keys correspond to all messages received in block 702. In block 706, the user is decoupled or unlinked by the key repository logic, so the user no longer communicates with the key repository. This is done with an equivalent device, which is disconnected from the network running the system in Figure 1. At block 710, the user links to the key repository again. At block 712, the key is deleted. Block 712 may involve deleting the key locally stored in the user and the corresponding key in the key repository.

At block 708, the user reads the message. Can use a portable computer or

10. Message confirmation

In some cases, worry about whether the message has been changed, including deliberate or unintentional changes. It is hoped that the sender of the message cannot be denied, and the receiver or interceptor cannot be sure to modify the content of the message without knowing the sender. Therefore, according to a specific embodiment, a "fingerprint" of a message is provided to the message recipient, so it is determined whether the message has been changed.

Each message fingerprint is a stored value that uniquely represents the content of the message. The message fingerprint can be generated in a variety of ways, and the present invention is not limited to any specific method of generating the message fingerprint. For example, the message fingerprint can be generated based on the message content using a one-way hash function. The MD5 hash function is suitable for this project. The message fingerprint can be a digital signature. It can be a digital certificate, such as a digital certificate compatible with the ITU X.509 standard. Message fingerprints can be generated based on other information, such as message timestamps or pass codes.

When the message is sent to the recipient, the fingerprint of the message can be provided along with the message. In addition, the fingerprint of the message can be stored in the key repository along with the corresponding key of the message. The message fingerprint can be provided to the message receiver when the receiver requests the key from the key repository.

FIG. 8 is a block diagram of the message processing system 100. Generally, the system 100 has the same structure and function as the system in FIG. 1.

However, in Figure 8, the digital signature of the message is generated in step 4. At this time, the user 102 is based on the message ID and key received from the key repository 106 through the connection chain 110.

Encrypted message. In step 5, the encrypted message together with its message ID and digital signature are sent to the user 104 through the connection chain 108. In step 9 of Figure 1, after the message is decrypted, its content is compared with the digital signature to verify that it is valid. The verification process depends on the type and form of the digital signature. For example, if the digital signature is a hash value, the verification process involves applying the contents of the hash function, generating a second hash value and comparing the two hash values. If it matches, the content remains unchanged.

11. The message is released from confidentiality

In some cases, it is desirable to "unclassify" encrypted messages so that the encrypted messages can be read by any user.

According to a specific embodiment, the message is released from being classified by making the key available to any user requesting the key. This effectively removes any permission and/or control established by the previous key policy standard for controlling key distribution.

Figure 7B is the flow chart of the key release from being classified as confidential. In block 722, mark the key to be unlisted in the key repository as the unlisted secret. Marking can involve setting a flag bit, storing the key identifier in a table, or other methods. At block 724, the key is issued to any requesting user, regardless of whether the user-defined policy or the policy manager instructs the key to be sent.

The key can also be disclosed in a location outside the key repository 106 that is convenient for the user to access, as shown in block 726.

In addition, the key can be stored in the backup key repository, as indicated by block 728, to ensure that the key can be obtained so as not to be accidentally deleted by the key repository 106.

12. Message storage application

According to another specific embodiment, a method is provided to control and track the access of information using a message storage method. According to this method, when the user wants to send a message to the recipient, the user generates the message and then sends the message to the designated location. The user informs the recipient: a message has been generated for the recipient and can be retrieved from a specific location. The recipient then picks up the message from that specific location. A variety of strategy controls can be applied to control access and deletion of messages from specific locations.

Figure 9 is a block diagram illustrating an example of a system 900 for controlling and tracking the access of disseminated information according to the message storage method. The system 900 includes users 902, 904 and a message repository 906. The users 902 and 904 are logically coupled by the connection chain 908 and can communicate using the connection chain 908. The user 902 and the message storage 906 are communicatively coupled through the connection link 910. The user 904 and the message repository 906 are communicatively coupled through the connection link 912. The connection chain 908, 910, 912 includes a number of connection points, networks or the Internet. For example, the connection chain 908 includes Internet connection points. In this way, the users 902, 904 and the message storage 906 can be located at the same node or distributed in different nodes. The present invention is not limited to any specific embodiment of the connecting chain 908, 910, 912.

Assume that the user 902 wishes to send a message to the user 904. According to this method, the user 902 first generates a message and then sends the message to the message repository 906. The user 902 can choose to encrypt the message before sending the message to the message repository 906, and the present invention is not limited to the encrypted or unencrypted message sent to the message repository 906. Then the user 902 informs the user 904 that a message has been generated for the user 904 and indicates the location of the message. In this example, the user 902 informs the user 904 that a message is waiting for the user 904 in the message store 906. According to this method, the user 902 does not actually send a message to the user 904, but instead sends a notification to the user 904. The notification message can be obtained by the message repository 906.

When the user 904 reads the message, the user 904 requests the message from the message repository 906. The user 904 is asked to provide information to the message repository 906 to verify that the user 904 is authorized to receive messages. For example, the user 904 is required to provide a unique identification code to the message repository 906, so the message repository 906 understands that the user 904 is authorized to receive messages. Once the message repository 906 agrees that the user 904 is authorized to receive the message, the message repository 906 provides the message to the user 904. The message can be encrypted or unencrypted. Such a message can be stored in the message repository 906 in an unencrypted type or directly provided to the user 904. In addition, the message can be stored in the message repository 906 in an encrypted type, and provided to the user 904 in an encrypted or unencrypted type.

The policy manager 916 communicatively couples the message storage 906 through the connection link 914. The policy manager 916 is used to execute various policies for controlling the access and deletion of various messages stored in the message repository 906. For example, a specific policy stipulates that users with certain user attributes can access certain messages. This can be applied to the original recipient as well as to the secondary recipient who receives the sent message. User attributes can take many forms. For example, user attributes can be permissions, members of a group, or any other information. Access and deletion of messages can also be managed based on certain message attributes. For example, it may be desirable to delete messages associated with a specific topic or category contained in the message repository 906, such as "tagging" groups of messages based on message attributes. The message attributes can be specified by the intermediate data maintained in the message repository 906 on the messages maintained in the message repository 906. As explained above, user policy standards can also be used to control the access and deletion of messages maintained in the message repository 906.

This method is not limited to only the messages maintained in the message repository 906, but also applies to messages maintained in any location. Numerous message storage 906 can be used to store messages based on user attributes or message attributes. For example, the message can be stored in the message repository 906 based on the subject of the message. The message repository 906 can be located at different nodes other than the users 902 and 904.

This method is also applicable to the system 900 implemented using the Internet. For example, when the recipient receives the notification message, the recipient can use it, and the recipient is provided with a uniform resource locator (URL) that specifies the location of the message to the recipient. Then the recipient does not use the browser but retrieves the message from the specified location. In this way, the receiver can retrieve different messages from the same location or from different locations. The present invention is not limited to storing information in a single location or multiple locations.

Figure 10 is a flowchart 1000 illustrating the use of the message storage method to control and track the process of accessing data. After starting at step 1002, at step 1004, the user generates a message. In step 1006, the user provides the message to the message repository. The message repository can reside locally or remotely, such as in a distributed configuration.

In step 1008, the user notifies the receiver that a message has been generated for the receiver and the location of the message is specified. In step 1010, the recipient retrieves the message from a specified location. As mentioned above, the recipient may be required to provide proof that the recipient is authorized to retrieve the message. The processing is completed in step 1012.

13. Implementing agency

A. Summary The method of controlling and tracking the access to disseminated information described in this case can be implemented in computer software, hardware circuits, or a combination of computer and hardware circuits. As such, the present invention is not limited to specific embodiments. For example, the key repository 106 can be implemented as a "key server" to be communicatively coupled to the network. The approach can also be implemented as an isolated

Institutions or integration into existing systems, such as network or customer use. In addition, the key vault 106 log 300 and the policy manager 400 can be implemented as separate organizations or implemented in any combination, and the present invention is not limited to any specific embodiment or combination.

B. Implementing hardware FIG. 11 is a block diagram illustrating a computer system 1100 that can implement the computer program embodiment of the present invention. The computer system 1100 includes a bus 1102 or other communication mechanisms for communicating information, and a processor 1104 is coupled to the bus 1102 for processing information. The computer system 1100 also includes a main memory 1106, such as a random access memory (RAM) or other dynamic storage device coupled to the bus 1102 for storing information and instructions to be executed by the processor 1104. The main memory 1106 can also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by the processor 1104. The computer system 1100 further includes a read-only memory (ROM) 1108 or other static storage device coupled to the bus 1102 for storing static information and instructions of the processor 1104. A storage device 1110 such as a magnetic disk or an optical disk is supplied and coupled to the bus 1102 for storing information and commands.

The computer system 1100 may be coupled to the display 1112 through the bus 1102, such as a cathode ray tube (CRT) for displaying information to the computer user. The input device 1114 includes a text key and other keys. The input device 1114 is coupled to the bus 1102 for communication information and selection of commands to the processor 1104. Another type of user input device is the cursor controller 1116, such as a mouse, a trackball or a cursor direction key for communicating direction information and command selection to the processor 1104 and for controlling the cursor movement on the display 1112. The input device typically has two degrees of freedom on two axes. The first axis (such as the X axis) and the second axis (such as the y axis) allow the device to specify a position on a plane.

The present invention relates to the use of the computer system 1110 to control and track the access actions of disseminated information. According to a specific embodiment of the present invention, the control and tracking of access to disseminated information is provided by the computer system 1100 in response to the processor 1104 executing one or more sequences of one or more commands contained in the main memory 1106. Such instructions can be read in the main memory 1106 by another computer readable medium such as the storage device 1110. The execution of the sequence of instructions contained in the main memory 1106 causes the processor 1104 to execute the processing steps described in this specification. One or more processors in a multi-processing configuration can also be used to execute the sequence of instructions contained in the main memory 1106. In alternative embodiments, wired circuits can be used to replace software instructions to implement the present invention. Therefore, the specific embodiments of the present invention are not limited to any combination of specific hardware circuits and software.

The term "computer-readable medium" is used here to mean any medium that participates in providing instructions to the processor 1104 for execution. This kind of media can take many forms, including but not limited to non-electric media, electric media, and transmission media. Non-electrical media include, for example, optical disks or magnetic disks such as storage devices 1110. Electrically dependent media includes dynamic memory such as main memory 1106. Transmission media includes coaxial cables, copper wires and optical fibers, including wires that make up the bus 1102. The transmission medium also takes the form of sound waves or light waves, such as the waves generated in the transmission of radio waves through infrared data.

Common computer-readable media formats include, for example, floppy disks, floppy disks, hard disks, tapes or any other magnetic media, CD-ROM, any other optical media, punched cards, paper tape or any other physical media with hole patterns, RAM, PROM, and EPROM, flash EPROM, any other memory chip or cassette, carrier described in this manual, or any other computer readable medium.

Various forms of computer readable media involve carrying one or more sequences of one or more instructions to the processor 1104 for execution. For example, the command can be initially loaded on the disk of the remote computer. The remote computer can load the commands in the dynamic memory and use the modem to send the commands through the telephone line. The local modem of the computer system 1100 can receive the data on the telephone line and use an infrared transmitter to convert the data into an infrared signal. The infrared detector coupled to the bus 1102 can receive the data carried on the infrared signal and place the data on the bus 1102. The bus 1102 loads data to the main memory 1106, where the processor 1104 can retrieve and execute instructions. The instructions received by the main memory 1106 can be selectively stored in the storage device 1110 before or after execution by the processor 1104.

The computer system 1100 also includes a communication interface 1118 coupled to the bus 1102. The communication interface 1118 provides two-way data communication coupling to the network connection link 1120, and the network connection link 1120 is connected to the local network 1122. For example, the communication interface 1118 can be an integrated services digital network (ISDN) card or a modem to provide information communication connection to a corresponding type of telephone line. For example, the communication interface 1118 can be a local area network (LAN) card to provide a data communication link to a compatible LAN. Wireless connection chain can also be implemented. In this embodiment, the communication interface 1118 sends and receives electrical, electromagnetic or optical signals carrying digital streams representing various types of information.

The network connection link 1120 typically provides data communication to other data devices via one or more network data. For example, the network connection link 1120 provides a connection to a host computer 1124 via a local network 1122, or a connection to a data device operated by an Internet Service Provider (ISP) 1126. ISP1126 also provides data communication services via the global packet data communication network (commonly known as the "Internet" today) 1128. The local network 1122 and the Internet 1128 may use electrical, electromagnetic or optical signals to carry digital data streams. The signals that carry digital data to and from the computer system 1100 through various networks and the signals on the network connection chain 1120 and through the communication interface 1118 are exemplary forms of carrier waves for transmitting information.

The computer system 1100 can send messages and receive data, including program codes, via the network, the network connection link 1120, and the communication interface 1118. In the Internet example, the server 1130 sends the code requested by the application program via the Internet 1128, the ISP 1126, the local network 1122, and the communication interface 1118. According to the present invention, such a download application can provide control and tracking of access to disseminated information as described in this specification.

The received code can be executed by the processor 1104 in the received form, and/or stored in the storage device 1110, or stored in other non-electrical storage devices for later execution. In this way, the computer system 1100 can obtain the application code in the form of a carrier wave.

The control and tracking of access to and dissemination of information described in this case provide several advantages over previous methods. In particular, this method makes all data copies inaccessible, regardless of where the copy resides and does not need to know the true location of the copy. This method applies to data copies stored in any form of media, including any form of electrical or non-electrical storage devices. For example, the method is applied to data copies stored in a computer's electrical memory, and data copies stored in a non-electric storage system. This method is compatible with existing communication systems. In addition, this method can track all entities that have requested the key to access the data. The foregoing description has described specific specific embodiments. However, it is obvious that various modifications and changes can be made without departing from the broad spirit and scope of the present invention. Such description and drawings shall be regarded as illustrative rather than restrictive.

Symbol description of main components

100. . . system

102-4. . . user

106. . . Key storage

108-12. . . Link chain

200. . . Key server

202. . . Key database

204. . . Key information

206. . . Key data registration item

208. . . Registration item

300. . . Log

302. . . Link chain

308-30. . . Cube

400. . . Strategy manager

402. . . Link chain

404. . . Policy definition

410-6. . . Cube

500. . . Configuration

502-6. . . user

508-16. . . Key storage

518. . . network

520-30,602-60,702-12,

720-28. . . Cube

900. . . system

902-4. . . user

906. . . Message repository

908-14. . . Link chain

916. . . Strategy manager

1000. . . flow chart

1002-12. . . step

1100. . . computer system

1102. . . Busbar

1104. . . processor

1106. :. Main memory

1108. . . ROM

1110. . . Storage device

1112. . . monitor

1114. . . Input device

1116. . . Cursor controller

1118. . . Communication interface

1120. . . Network connection chain

1122. . . Local network

1124. . . Host computer

1126. . . Internet service provider

1128. . . Internet

1130. . . server