Systems and methods for controlling electronic document use

One exemplary embodiment involves receiving, at a server, a request for a document key for accessing a document on a client device, wherein the request comprises an identity of an access policy and information about the document. The exemplary method further comprises determining, at the server, whether access to the document is permitted according to the access policy. If access to the document is permitted, the exemplary method involves computing, at the server, the document key using the information about the document, wherein the document key is document specific, wherein, prior to the computing of the document key, the document key is not stored for access by the server. The exemplary method further involves responding to the request by providing the document key for use in accessing the document on the client device.

FIELD

This disclosure relates generally to computer software and more particularly relates to controlling the use of and access to electronic documents.

BACKGROUND

There are various techniques available to control the use of text, graphics, computer aided designs and other electronic documents. In many circumstances, it is desirable to ensure that a given document can only be used by one or more specific persons. Additional limitations on use are also often desirable. For example, a particular person's use of a document may be limited with respect to time of use such that that person can only use the document until a specified date. As another example, a person's use of a document may be limited with respect to type of use such that the person can view the document but cannot edit, copy, or print the document.

Documents are commonly encrypted to ensure that unauthorized persons cannot access the contents of the document. Distribution of the encryption keys that allow use of such encrypted documents can be controlled in various ways. Such encryption keys can, for example, be maintained at a separate network location and accessed by remote client devices when an authorized person attempts to use a document. The client device can send the person's credentials to a remote server, receive an encryption key from the remote server, and use that key to access the document. The person using the client device may be unaware of this process and may not have access to the provided encryption key. For example, the person may simply enter a username and password and the client device application may use that information to access the server, obtain the key, and open the document for the person to use. The remote server may have also provided particular policy information that defines how that person may use the document. The client device may receive this policy information and enforce the policy details, for example, by preventing the person from editing the document.

Existing servers that maintain document encryption key and policy detail information for documents require the storage and use of information about each individual document. For example, a database is used to store one or more records for each document that identifies whether a particular person has access to the document and defines the particular uses for which the person has permissions. One deficiency of such systems is that they can require a large amount of storage and communication. The storage and communication requirements can require significant resources particularly in circumstances in which the number of documents and persons is very large. As a particular example, if a service provider sends out monthly statements to hundreds of millions of customers where each such document requires a record in a database, the volume of storage and communication can be particularly burdensome.

SUMMARY

One exemplary embodiment involves receiving, at a server, a request for a document key for accessing a document on a client device, wherein the request comprises an identity of an access policy and information about the document. The exemplary method further comprises determining, at the server, whether access to the document is permitted according to the access policy. If access to the document is permitted, the exemplary method involves computing, at the server, the document key using the information about the document, wherein the document key is document specific, wherein, prior to the computing of the document key, the document key is not stored for access by the server. The exemplary method further involves responding to the request by providing the document key for use in accessing the document on the client device.

These illustrative features are mentioned not to limit or define the disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there. Advantages offered by one or more of the various embodiments may be further understood by examining this specification or by practicing one or more embodiments presented.

DETAILED DESCRIPTION

Improved systems and methods for controlling document use are disclosed. Document encryption keys can be used to control access to documents. In one embodiment, when a document is accessed on a client device, the client device requests the corresponding document key from a server to gain access to the document. The server responds to the request by confirming that access to the document is allowed by the requester and computing and returning an appropriate document key. A server may store only limited information or even avoid storing any information for use in access determinations and document key computations. For example, rather than storing document-specific access control information and other document-specific information, a server may store more limited information that is applicable to multiple documents.

Determining whether to allow access to the document or not can be based on information received in a request in addition to, or instead of, being based upon information stored by a server device performing that determination. For example, a request to access a document may include information about the particular document license information and information about the person requesting access that can be compared or otherwise used to determine whether to allow access to the document or not.

Computing a document key may similarly be based upon limited or no information stored by the server. Such a computation may use information received in the document access request rather than, or in addition to server stored information. In one exemplary embodiment, a document key is computed using document information, a timestamp, a policy identification and a user identification of a user who is requesting access to or use of the protected document. A system may be configured to require some or all of such information for the computation of a document key such that the document key and therefore access to and use of the document can not be obtained without the required information.

In one exemplary embodiment, a server stores one or more seed values that are each used to compute document keys for multiple documents, for example, by providing a seed value used in generating a random number that is used for, or as part of, the document key. Given a particular seed value and/or other document information a serve may compute a document key in a way such that given those same inputs the same document key can be recreated at a later time. Thus, when a document is first secured the document key can be computed using one or more of those inputs and when the document is later accessed, the same document key can be computed again using those same inputs. Generally, a server can use the same technique and/or inputs to compute a document key to allow access to document as was used previously to compute the same document key when the document was created and first secured using the document key.

Document keys, even document keys computed using a given seed value, may be the same or different for multiple documents. Document keys may be computed such that each document is secured by and accessed with a unique document key. If document keys are unique for each document or otherwise differ from one another from document to document, such differences in document keys can be based on information received in a request to secure or access the document in addition to, or instead of, being based upon information stored by a server device. For example, a request to access a document may include information about the individual document such as a unique document identifier, document descriptive information, license information, information about the context in which the document was first secured, information about a policy used to secure the document, and information about the time and date when the document was secured, etc. In attempting to access a document, such information may have been retrieved by a client device from the metadata or other unprotected portion of the document itself. The document-specific information that is used to compute an appropriate document key thus need not be stored or separately accessed by a server to compute a document key. In one embodiment, document keys can be computed to differ from one another in meaningful ways even though limited or no document-specific information is stored by the document key providing server.

These illustrative examples are given to introduce the reader to the general subject matter discussed here and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional embodiments and examples with reference to the drawings in which like numerals indicate like elements.

Referring now to the drawings,FIG. 1is a block diagram depicting exemplary computing devices in an exemplary computing environment for implementing certain embodiments. Applications, documents, and other electronic content executes or is otherwise used on the exemplary computer devices10,20,30and are shown as functional components or modules. As is known to one of skill in the art, such applications and content may be resident in any suitable computer-readable medium and execute on any suitable processor. For example, as shown the network device10comprises a computer-readable medium such as a random access memory (RAM)12coupled to a processor11that executes computer-executable program instructions and/or accesses information stored in memory12. Such a processor11may comprise a microprocessor, an ASIC, a state machine, or other processor, and can be any of a number of computer processors. Such a processor can comprise, or may be in communication with a computer-readable medium which stores instructions that, when executed by the processor, cause the processor to perform the steps described herein.

A computer-readable medium may comprise, but is not limited to, an electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable instructions. Other examples comprise, but are not limited to, a floppy disk, CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, an ASIC, a configured processor, optical storage, magnetic tape or other magnetic storage, or any other medium from which a computer processor can read instructions. The instructions may comprise processor-specific instructions generated by a compiler and/or an interpreter from code written in any suitable computer-programming language, including, for example, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, and ActionScript.

The device10may also comprise a number of external or internal devices such as a mouse, a CD-ROM, DVD, a keyboard, a display, audio speakers, one or more microphones, or any other input or output devices. For example, device10is shown with a display18and various user interface devices19. A bus, such as bus16, is included in the device10. Device10could be a personal computing device, a mobile device, or any other types of electronic devices appropriate for providing one or more of the features described herein.

As used herein the terms “document” and “electronic document” refer to any electronic content that can be displayed, executed, or otherwise used on an electronic device to provide content. A document or electronic document may comprise one or more electronic files that may be stored on and/or transferred between electronic devices. Exemplary content of a document or electronic document may comprise text, graphics, audio, video, and any other content. A document may be presented or otherwise used on an electronic device in a variety of ways.

As used herein, the term “player application” refers to any application used to play or otherwise use a document on an electronic device. A document may be played or used through various types of player applications including, but not limited to, word processing applications, audio playing applications, video playing applications, rich Internet application players, and Internet browser applications.

As used herein, the term “document key” refers to any value, identifier, or other information useable to control access to a document. A document key may or may not be used to encrypt a document such that the document key is required to decrypt the document to gain access to some or all of the content of the document.

As used herein, the term “client device” refers to any electronic device that attempts to obtain a document or access to a document from a server device that provides the document and/or access to the document.

As used herein, the term “computing” refers to determining a value based on one or more inputs. For example, computing a document key may involve using an algorithm, function, or some other process that uses user information, document information and seed values.

As used herein, the terms “policy” and “access policy” refer to a record or other information about the rights of users with respect to accessing and using a document. An access policy can be used to determine if permission to a document can be granted and may be periodically or otherwise updated.

As used herein, the term “license” refers to an association of a policy with a particular document or documents and a user or users who may access and use that document. Thus, a policy can be applied to a particular document or documents to create a license.

As used herein, the term “user” refers to a person accessing, using, or attempting to access and use a document, unless otherwise expressly indicated. A person accessing, using, or attempting to access and use a document may or may not be the same person that originally secured or published the secured document.

As used herein, the term “document specific” refers to something being different for different documents. For example, a document specific document key is different than document keys computed for other documents. Document keys may be computed as document specific, for example, by computing document keys based at least in part on document specific information, such as information about a particular document received in a request to access that particular document.

FIG. 1illustrates an exemplary client device10that comprises, in memory12, a player application13and a document14. A person using the client device10may desire to access the document14using the player application13. For example, the person may execute the player application13and attempt to open the document14within the player application13. However, access to the document14may be restricted such that the player application13cannot open the document without obtaining permission and/or an appropriate document key. In the exemplary computing environment ofFIG. 1, such permission and/or document key may be sought by the player application13from server device20, for example, by the client device10sending a request for permission and/or a document key to the server20through network5.

The server20is illustratively shown as comprising an access module23and a document key module24, which may reside in memory (not shown) and be executed using a processor (not shown) at the server20. The access module23may respond to requests for access to documents by making one or more determinations using information in such requests. As an example, a request may request permission to allow access to a particular document. The access module23may make one or more determinations and access locally and/or remotely stored records to determine whether to allow such access or not. Similarly, document key module24may respond to requests for access to documents by computing a document key using information in such requests and/or by accessing locally and/or remotely-stored records.

In the exemplary computing environment ofFIG. 1, server20via one or both of its access module23and document key module24is able to use database30to provide an appropriate response to a request for access to a document from the client device10. Database 30 is shown as illustratively comprising key computation data33that illustratively includes a seed value(s)34. One or more such seed value(s)34may be used, for example, in computing a document key that is used to secure and/or access document14on client device10. Database 30 is further shown as illustratively comprising access control data35that illustratively includes multi-document access controls36. An example of one these multi-document access controls36is a single record providing one or more access rules applicable to multiple documents. Such a single record may do so without individually identifying documents.

Other types of access control data can be used to achieve various access control objectives. Generally, access control data35may be defined in an efficient manner such that access module23and/or document key module24can utilize such information, possibly in combination with information otherwise known about documents, to control access to the documents in accordance with various access control objectives. Using document information that is otherwise known about a document can reduce the amount of information that needs to be stored to provide the desired access control functionality. Accordingly, the amount and/or type of information that is stored at database30or otherwise stored at a location accessible to server20can be less than it otherwise would without the use of information otherwise known about the document, e.g., without using information in the request for access to a document that identifies information about the document and/or context in which the document access is being attempted.

In one exemplary embodiment, when a server20is accessed by a client attempting to secure a document14, the server20calculates a document key for securing the document14and returns that document key to the client device10that then encrypts or otherwise secures the document14using the document key. The client device10may also include information in the document14such as license information that identifies which access policy applies to each authorized user of the document. The document14may include this information by simply including a license identifier. In one exemplary embodiment, a license identifier comprises a policy identifier, a user identifier, and a timestamp.

To apply a security policy to a document14, a client device10may send a request to apply the security policy to the document to a document-key-providing server, such as server20. Such a server20may calculate the document key from information in the request. For example, prior to sending the request, the client device10may receive input from a person using the client device10and from that input identify a particular policy, user identity of a user that will access and use the document, and other information. Based on such input and a received command specifying that a security policy should be applied to the document14, the client device10creates and sends a request that includes, as examples, a policy identifier, a user identifier, and a timestamp associated with the time when the request was made. Different policy identifiers and user identifiers may be provided for different persons who will be authorized to use the document14. The request to apply the security policy may include the file name or other identifier of the document14.

FIG. 2is a flow chart illustrating an exemplary method of a flow of communications between electronic devices in the circumstance of a client device10securing a document14. In this exemplary embodiment, client device10accesses server20to attempt to secure a document14, ofFIG. 1. The client device10initiates such a request by sending a request201to secure the document14to the server20. Request201may or may not include a copy of the document14itself and may or may not include additional information. In one exemplary embodiment the request201identifies a person or persons that will be allowed to access the document14after security has been applied to the document14.

In response to receiving request201, server10computes a document key for securing the document14and sends a message204returning that document key to the client device10that then encrypts or otherwise secures the document14using the document key. In an alternative embodiment, the request201includes the document and the server20encrypts or otherwise secures the document using a document key and returns the secured document in message204to the client device10.

Information in the request201from the client device10may be used by the server20to compute a document key. A document key may be computed without the server20accessing a database30. A document key may be computed based on information such that, given the same information, the same document key can be recreated by the server20. In one exemplary embodiment, information provided in the request201is simply concatenated together to form a unique document key. In another exemplary embodiment, a function is applied to such information to create the document key. In yet another exemplary embodiment, additional or alternative information is also used in creating the document key. For example, a document key may involve computing a random number using a particular seed value. The random number can be included as part of or otherwise used in creating the document key.

To compute the document key that is used to secure the document, server20may use information in request201such as an identity of an access policy and/or information about the document14. In one embodiment, the server20accesses database20through messages202and203to obtain a seed value. In one embodiment, the server20does not store the created document key since the document key can be recreated to control future access to the document14. Not having to store individual document keys for all documents may provide efficiency and various other advantages. Embodiments that avoid or limit storage of document-specific keys and access control information are particularly useful in contexts involving millions and even billions of documents that are created for access by a more limited number of users to individually access can particularly benefit from not having to store document access and/or document key information for each such document.

A server20calculating a document key can involve accessing some information stored in a database30. Even though some database30access may be used, in one embodiment, a document key is created without the server20creating or accessing document-specific information stored in a database30or otherwise stored by the server. As a specific example, a server20may retrieve seed value(s)34(FIG. 1) from a database30to compute a random number for use as part of the document key. A single seed value34may be used for multiple documents. In one particular example, the database30or other storage medium has only twenty six seed values as seed value(s)34, such that each of the twenty-six is associated with a particular alphabet character. In one exemplary use of such seed value(s)34, a first seed value is used for computing document keys for requests associated with a user identifier (e.g., a user name of a user for whom the license is being created to allow access and use of the document) beginning with the character “a”, a second seed value is used for computing document keys for requests associated with a user name beginning with the character “b”, etc. Based upon the user credentials of a user for whom a license has been created using a policy, one can obtain the seed value in a formulaic manner or obtain it from a database30or other location where seed values are stored in a limited set of records. A variety of techniques may be used so that seed value(s)34and/or other information used in creating a document key is the same for multiple documents such that document-specific database or otherwise stored document-specific entries are not required to compute document-specific document keys.

In one exemplary embodiment, a server20responds to a request to apply the security policy to a document14by providing a document key and one or more license identifiers back to the client device10that initiated the request. Each such license identifier may associate a person or group of persons with one or more security policies. For example, a first person may be allowed to view, edit, and print a document14while another person may only be allowed to view the document14. The client device10receiving such a document key and the one or more license identifiers may use the document key to encrypt or otherwise secure the document14and use the license identifiers to include information in the document14. In one embodiment, the one or more license identifiers are included in an unsecured or unencrypted portion of the document14.

Prior to sending a request201for a document key to use to encrypt or otherwise secure a document14, a client device20may receive input for inclusion in the request201from a person using the client device20to attempt to access the document14. In one exemplary embodiment, a document14is encrypted or otherwise secured such that information about the document14, such as document identifying information, user identifying information, and/or license information, is accessible by the client device10without accessing other protected portions of the document14, such as, a main portion of document content. In one exemplary embodiment, such unprotected information is stored as document metadata. In the context of later requests for access to the document14, such information from the document14may be used by a server20to compute the same document key to allow the document14to be decrypted or otherwise accessed. Similarly, as another example, a statement distribution system may create monthly electronic statement documents and provide information about the document, the context in which the document was created and/or secured, the potential recipients of the document, etc. for use by the server20in computing an appropriate document key for the document14.

One embodiment involves a server20uses information about a document14received in an access request to derive or otherwise compute a document key that will differ from document to document. This is particularly useful in the context in which the volume of documents is extremely high and where it may be desirable to avoid the requirement of having to store, for every document, access information or other information used to provide documents keys for each document. Thus, in one embodiment, the server20may only store information that is not document-specific. Little or no additional information needs to be stored since information about a document14received in an access request can instead be used to create and recreate the document keys for the different documents.

Document keys may be provided in accordance with document access rules that are applicable to multiple documents. For example, when a request for access to a document is received, a server20may identify a policy that defines document access rights applicable for multiple documents without identifying individual documents. The server20can thus respond to such a request by confirming that access to the document is allowed without having to store and/or access a database30or other storage records that provides document-specific access rights for all individual documents. The server20can thus generally avoid having to store document-specific access policy information for many or all of the individual documents for which access control is provided.

While a system may utilize limited or no storage of document-specific access information and/or other information, document-specific revocations and other features may be implemented using document-specific information available from elsewhere. Such document-specific information may be available at the time the document14is first secured based on user input, from the content of the document itself, and/or from the document creation environment, as examples. Such document information for a document14that has already been secured may be obtained from user input, from the document itself, or from the context in which access to the document14is being requested, as examples. For example, document identifying information may be available from metadata stored in a document14and used to control access to the document14by the server20. In one embodiment, revocation of access rights is applied by storing some document-specific information at the server20, such as the individual document numbers for documents for which document access has been revoked.

In one exemplary embodiment, when a server20is accessed by a client device10attempting to open a document14, if the requester is authorized, the server20computes a document key for opening the document and returns that document key to the client along with policy details specifying what uses of the document14are permitted. The client device10then decrypts or otherwise opens the document14using the document key.

A client device10attempting to open a document14may receive authentication information as input from a person using the client device10and a command to open the document14. The client device10may use this information and information from the document14itself, such as the document identifier and license information obtained from an unsecured portion of the document, to send a request for a document key to a server20. In one embodiment, such a request includes authentication information for the person attempting to open the document14, and license information from the document14where the license information includes a policy identifier, a user identifier of a user allowed to access and use the document, and a timestamp as described with respect to the exemplary license identifiers above.

FIG. 3is a flow chart illustrating an exemplary method300of controlling access to a document. Such an exemplary method300is described in the context of the exemplary computing environment ofFIG. 1. However, method300may be implemented in a variety of other computing environments, including environments that involve the use of mobile devices, environments that do not use databases, and environments that differ from the exemplary environment ofFIG. 1in various other ways. In short, the techniques and features described have a variety of uses and benefits and may be tailored, adjusted, or otherwise modified to fit the particular computing environment in which such techniques and features are implemented.

Exemplary method300comprises receiving a request for a document key for accessing a document14on a client device10, as shown in block310. In one embodiment, such a request for a document key is received by a server20from a client device10. In one exemplary context, a client device10attempting to open a document14may receive authentication information as input from a person using the client device10and receive a command to open the document14. The client device10may use this information and information from the document14itself, such as a document identifier and license information obtained from an unsecured portion of the document14, to send a request for a document key to a server20.

The request may include various information. In the embodiment ofFIG. 3, the request comprises an identity of an access policy and information about the document. In one embodiment, the request additionally or alternatively comprises license information. Exemplary license information comprises an identifier of an access policy, a licensed person identifier identifying a person whose access to the document is controlled by the access policy, and a timestamp identifying a time at which security was first applied to the document. License information may include different and/or additional information or combinations of information. The request may additionally and/or alternatively include a user identity of a person requesting access to the document on the client device.

Exemplary method300further comprises determining whether access to the document is permitted using an identity of an access policy, as shown in block320. Such a determination may be performed by server20in response to receiving the request for the document key. Determining whether access to the document is permitted may involve identifying a stored record comprising the access policy. The access policy may specify access privileges applicable to one or more documents without specifying access privileges specific to individually-identified documents. Such a stored record may be stored at the server20, the database30, or otherwise accessible at the server30.

FIG. 4is a flow chart illustrating an exemplary method400of determining whether access to the document by the requester is permitted. The exemplary method400involves identifying a licensed person from license information provided in a request for a document, as shown in block410. The method400further involves identifying a person requesting access to the document from information provided in the request, as shown in block420. For example, the identity of such a person may be provided in a request from the client device10where the client device received login credentials, e.g., username and password, from a person using the client device10to attempt to access a document14. The exemplary method400further comprises determining whether access is permitted, as shown in block430. As a particular example, such a comparison may involve comparing two pieces of information provided in a request for accessing a document. Examples of such pieces of information are (1) a licensed person identifier in license information provided in the request and (2) an identity of the person requesting access to the document on the client device10. If the person requesting access is determined to be a person permitted to access the document, i.e., as identified by the licensed person identifier, then access to the document is allowed. If not, access is denied, as shown in block440.

If access to is permitted, then the method440proceeds to block450to determine access privileges using the license information in the request, as shown in block450. Examples of access privileges include, but are not limited to privileges to open, edit, save, print, copy, modify, etc., the document14. Various combinations of access privileges may be enforced. In one exemplary embodiment, a request includes license information that identifies a particular access policy under which a licensed user may access a document14. A server20may use such an identifier to access one or more stored records on database30to identify or otherwise the particular privileges that are applicable. For example, the request may identify policy “X” and the server may retrieve a record for policy “X” that identifies that under the policy the document14may be opened but not edited, etc. In one embodiment, wherein determining whether access to a document14is permitted comprises identifying a stored record comprising the access policy, where the access policy specifies access privileges applicable to one or more documents without specifying access privileges specific to individually-identified documents and without specifying access privileges specific to individual persons. A stored record providing access privileges and/or other document access information may be stored at the server20, the database30, or in any other storage location accessible by the server20. In various ways, access to a document14can be controlled by using a limited number of records or even no records. In one embodiment, document access is controlled without using document-specific access control records.

Returning toFIG. 3, after determining whether access to the document14by the requester is permitted, the method300performs additional steps if access to the document14is permitted. If access to the document is permitted, the method300computes the document key using information about the document14, as shown in block330. The information in the request to open or otherwise access a document14may be used by the receiving server20to calculate a document key in various ways. As described previously, the document key may be computed without the server20accessing a database30. The same or similar techniques used to compute the document key when applying a security policy can be used to compute the same document key when access of the document14is later requested. The document key may be computed such that the document key is different than document keys determined for other documents. Such variation can be achieved using the information about the document. For example, if such information about the document14is the date the document was secured, that date can be used consistently to compute a document key for the document14such that the document key for that document14will always be the same. Document keys computed for documents secured on different dates can be computed consistently to have different document keys using the difference in dates to provide such differences in the document key computation.

In one embodiment, a document key is computed without the server20accessing a stored record comprising document-specific information. In one embodiment, computing a document key comprises forming a unique value that comprises some or all of the information about the document14that was received in a request to access the document14. Computing the document key may involve applying a function to such information. In one embodiment, computing a document key involves applying a function to the information about the document14received in a request and using a seed value that is stored at a location accessible to the server20that computes the document key. Such a seed value may be retrieved from a record accessible to the server20. Such a seed value may be used to compute document keys for multiple documents. In one embodiment, computing a document key involves using the information about the document14received in a request and a user identity received in the request. For example, the user identity may be used directly or may be used to retrieve a user key that is stored at a location accessible to the server20that computes the document key. Such a user identity and/or user key may be used to compute document keys for multiple documents.

If access to the document is permitted, the method300responds to the request by providing the document key for use in accessing the document14on the client device10, as shown in block340. The document key may be provided to the client device10from the server20such that the client device10will use the document key to access the document and then will discard the document key such that to access the document14again in the future, the client device10will need to again request access to the document from the server10. In one exemplary embodiment, when a server20is accessed by a client device10attempting to open a document14, if the requester is authorized, the server20calculates a document key for opening the document14and returns that document key to the client device10. The server20may or may not also return policy details specifying what uses of the document14are permitted for the requesting person. The client device20then decrypts or otherwise opens the document14using the document key.

Some embodiments described herein allow a server20to limit or eliminate the amount of stored information required to control document access by including some or all of that information in the documents themselves. A system may be configured to reduce or minimize the amount of information that is written to and read from a database30. A system may even avoid the use of a database30altogether. In one exemplary embodiment, access determinations are implemented by a system that stores only policy details for a limited number of access policies such that the number of access policies is less than, and preferably substantially less than, the number of documents and/or licensed persons. In one exemplary embodiment, document key computation features are implemented by a system that stores only a limited number of seed values for computing the document keys where the number of seed values is less than, and preferably substantially less than, the number of documents and/or licensed persons. Stored access policies, seed values, and other information used for access determination and document key computation may be applicable to a large number of document rather than specific documents. A system with reduced storage requirements may provide improved capabilities with respect to efficiency, speed, and scaling, among other benefits.

One embodiment allows for electronic statement documents to be provided for access by particular individual users, i.e., where each a particular document14is accessible by only a single person and, possibly, a customer service representative in the event of a problem. A system may be configured to reduce or eliminate having to write document-specific records to database by storing document-specific information into the document14itself, e.g., identifying the user, a timestamp, an access policy, and having that information provided to the server10when access to the document14is later requested. Rather than looking up a document key in a stored record, a server20can use the received document-specific information to compute a key that will preferably be unique for the document.

In one embodiment a system is configured so that a server20is the only device that computes a document key and/or makes access determinations. In an alternative embodiment, the client device10is configured to additionally and/or alternatively compute the document key and/or make access determinations. In another alternative embodiment, the server20controls document access when the client device10is connected to the network5, and different techniques, i.e., offline access techniques, are used to control access when the client device10is not connected to the network and thus does not have access to server20. Offline access to a document14may be controlled by the client device10. In one exemplary embodiment, such a document14has the document key for the limited purposes of allowing offline access to the document14. The document key may be included in a protected portion of a document14or otherwise secured to prevent unauthorized use of the document key. When a person attempts to use the document14offline, a player application13may make access determinations and retrieve the document key from the document if appropriate input information (e.g., username and password) is received from the person attempting to access the document. Offline access may be more limited than and/or requires additional verification information from a person requesting access than access that is controlled by a server20when the client device10is no offline.

General