Patent Description:
Managing access to a company's electronic data presents a number of challenges. Historically, it is known to utilize data rights management (DRM) software to establish an initial level of security for access to the electronic data. DRM software commonly requires a user to provide credentials, such as a user name and password. The DRM software may further employ two-step authentication, requ1ring, for example, the user to receive a code from the DRM software via a text message and subsequently enter that code to verify a user's identity. The DRM software may employ still other restrictions such as limiting access to data to a predefined list of devices or during a certain time of the day. Further the DRM software may utilize encryption techniques to encrypt electronic data prior to storing the data on a storage device. Each of the measures employed by the DRM software provides an initial level of security for the electronic data.

The limitations placed by the DRM software on accessing data restrict an application from initially accessing that data. The data is commonly stored on a data storage device, such as a remote server or a local storage device, which may include one or more fixed or removable storage devices such as hard-drives, solid-state d1ives, CD drives, DVD drives, USB drives, memory cards or the like. Read and/or write access to this data is slow when compared, for example, to accessing data from memory. The computing device will commonly copy either a portion of a file or even the entire file into memory for rapid read and/or write access to the data while an application is utilizing the data. The data is commonly copied to a memory location with shared access between different applications. A memory management unit on the computing device controls storage of the data into the memory and provides pointers back to the application for subsequent access to the memory.

While the DRM software may be configured to provide an initial level of security, the potential still exists for unauthorized access to data protected by the DRM software. Once the data has been copied from the data storage device to memory, additional applications executing on the same device may request access to the same data. The memory management unit first checks if the requested data has already been copied from the data storage device to memory. When the data has already been copied to memory, the memory management unit returns a pointer to the additional application providing access to the location of the stored data without creating a second copy of the data in memory. The memory management unit then controls access to this data between the two applications such that both applications are not attempting to write to the same location at the same time, The memory management unit, however, is typically not configured to check the access rights as established by the DRM software, The DRM software manages access to data on the data storage device, Because the data has already been copied to shared memory, a second application, which would not have access to the data based on the rights configured in the DRM software may now have access to the data stored locally in the shared memory. Documents <CIT> and <CIT> are relevant documents in the field of unauthorized access to data stored in a memory.

Thus, it would be desirable to provide an improved system for managing access to secure files stored in memory.

The subject matter disclosed herein describes an improved system for managing access to secure files stored in memory. A data access manager is provided on the computing device. The data access manager may be, for example, a process executed on power up and executable by the host operating system. The data access manager intercepts function calls from applications to the memory management unit and determines whether an application is allowed to access secure data stored in the memory of the computing device.

An initial function call from an application to the memory management unit is used to map data to memory. The initial function call may, for example, identify a data file or data from a data file to which the application is requesting access. The data access manager is configured to intercept the function call before it is received by the memory management unit and to determine whether the calling application has permission to access the data file. The data access manager may utilize a local data rights management (DRM) software executing on the computing device. The DRM software may store login credentials, such as a user name and password and include a database defining file access rights associated with the login credentials. It is contemplated that still other forms of DRM software may be executing on the computing device, without deviating from the scope of the present invention.

When the data access manager determines that the application is allowed to access the requested data, the data access manager coordinates the required steps to copy the data from the data file into memory for subsequent access. The data access manager requests that the memory management unit map the data into memory. If the data is encrypted, the data access manager may first request a copy of the encrypted data and store the encrypted data in a first memory location. The data access manager may call a decryption module to decrypt the data and then instruct the memory management unit to store the decrypted data in a second memory location for ready access. The memory management unit generates a pointer, also referred to as a file handle, each time data is mapped to memory. Thus, the memory management unit may pass the data access manager a first pointer to secure data and a second pointer to clear data. \V11en the calling application has permission to access the data, the data access manager returns the pointer to the clear data to the calling application such that it has access the clear data. When the data access manager detem1ines that the application is not allowed, the data access manager passes the pointer to the encrypted data, such that it is unable to access the clear data.

After mapping the data to memory, subsequent function calls from the application to the memory management unit are generated to access the previously mapped data either for reading or writing. The data access manager is configured to intercept the function call before it is received by the memory management unit and to determine whether the calling application has permission to access the data file. When the application has permission to access the requested data or data file, the data access manager sends the memory management unit the pointer to the clear data. The memory management unit, via the data access manager provides the application access to the clear data in memory. When the application does not have permission to access the requested data or data file, the data access manager sends the memory management unit the pointer to the secure data. The memory management unit, via the data access manager provides the application access only to the encrypted data in memory. When the data is encrypted, the calling application will not be able utilize the data within the file and will return an error message with respect to the data received it attempted to access.

According to one embodiment of the invention, a method of managing access to secure data mapped into memory a computing device receives a request to view the secure data mapped into memory. The request to view is received by a data access manager from an application executing on the computing device, and the data access manager determines whether the application is allowed to access the secure data. A first pointer is transmitted to a memory management unit when the application is not allowed to access the secure data, and a second pointer is transmitted to the memory management unit when the application is allowed to access the secure data. The first pointer directs the memory management unit to access the secure data and the second pointer directs the memory management unit to access clear data.

According to another aspect of the invention, initial steps include receiving a request to map the secure data to the memory from a data storage module communicatively coupled to the computing device. The request to map is received by the data access manager from the application, and the data access manager transmits a first request to the memory management unit to map the secure data to memory. The first pointer is received at the data access manager from the memory management unit, and the secure data is converted to clear data. The data access manager transmits a second request to the men1ory management unit to map the dear data to memory, and the second pointer is received at the data access manager from the memory management unit.

According to still another aspect of the invention, a second request to view the secure data mapped into memory is received, where the second request is received by the data access manager from another application executing on the computing device. The data access manager determines whether the other application is allowed to access the secure data. The first pointer is transmitted to the memory management unit when the other application is not allowed to access the secure data, and the second pointer is transmitted to the memory management unit when the other application is allowed to access the secure data.

According to another embodiment of the invention, a system for managing access to secure data on a computing device includes a memory configured to store data, a data storage module configured to store multiple files, and a processor in communication with the memory and the data storage module. The files include at least one application and at least one data file. The processor is configured to execute the application and to execute a data access manager. The application and the data access manager are operative to generate a request to access data with the at least one application, transmit the request to access data from the at least one application to a memory management unit, intercept the request to access data with the data access manager before the request is received by the memory management unit, determine whether the application is allowed to access the data with the data access manager, transmit a first pointer from the data access manager to the memory management unit when the application is not allowed to access the data, and transmit a second pointer from the data access manager to the memory management unit when the application is allowed to access the data. The first pointer directs the memory management unit to access secure data, and the second pointer directs the memory management unit to access clear data.

According to still another embodiment of the invention, a method of managing access to secure data mapped into memory on a computing device intercepts a request to map secure data into memory with a data access manager. The request is transmitted from an application executing on the computing device to a memory management unit A first request from the data access manager to the memory management unit is issued to map the secure data into memory, and the data access manager receives a first pointer from the memory management unit. The secure data is converted to clear data. A second request from the data access manager to the memory management unit is issued to map the clear data into memory, and the data access manager receives a second pointer from the memory management unit. Both the first pointer and the second pointer are associated with the requested secure data in the data access manager, and the second pointer is returned to the application from the data access manager.

These and other advantages and features of the invention will become apparent to those skilled in the art from the detailed description and the accompanying drawings. It should be understood, however, that the detailed description and accompanying drawings, while indicating preferred embodiments of the present invention, are given by way of illustration and not of limitation.

For example, the -word "connected," "attached," or terms similar thereto are often used.

Turning initially to <FIG>, a general block diagram representing an exemplary computing device <NUM> is illustrated. It is understood that each computing device <NUM> may have various configurations and additional components to those illustrated. Further, the block diagram represents general elements of the computing device <NUM>, and the general elements may vary between computing devices. According to the illustrated block diagram, each computing device <NUM> includes a processing component <NUM> with a processor <NUM> and memory <NUM> in communication with the processor <NUM>. The processor <NUM> may include a single processor or multiple processors. The processors may operate synchronously or asynchronously. Optionally, a single processor may include multiple processing cores, where each processor and/or core may execute one or more applications <NUM>. The memory <NUM> may include volatile memory, non- volatile memory, or a combination thereof. It is contemplated that at least a portion of the memory <NUM> is cache memory utilized for temporary storage and rapid access of data by an application <NUM> as the application executes. Each computing device further includes a physical data storage module <NUM>. The data storage module <NUM> may be, for example, a hard drive, a solid state drive, a removable memory card, a universal serial bus (USB) storage device, and the like. A processor interface I <NUM> and a storage interface <NUM>. are physical layers in the processing component <NUM> and the data storage module <NUM>, respectively, which establish communication between the processor <NUM> and the physical data storage module <NUM>. The data storage module <NUM> includes block storage <NUM> on which data and files are saved. Each file <NUM> (see also <FIG>) stored in the data storage module <NUM> may include metadata <NUM> and file data <NUM>. The metadata <NUM> may include, for example, pointers to particular blocks <NUM> in the block storage <NUM> at which the file data <NUM> is stored.

Each computing device <NUM> further includes an operating system <NUM> to manage the resources of the computing device and to provide common services between applications <NUM> executing on the computing device. The operating system <NUM> may be stored on the data storage module <NUM>, the memory <NUM> for the processing component <NUM>, or a combination thereof. The operating system <NUM> may vary between computing devices and is configured to control the hardware components for the associated computing device. The operating system <NUM> includes a library of function calls by which an application <NUM> may interact with the hardware components. The library includes, for examples, functions to read from and write to the data storage module <NUM> or to read from and write to memory <NUM>. The processor <NUM> is configured to execute the functions of the operating system <NUM> and to execute each of the applications <NUM> stored in the memory <NUM> or data storage module <NUM>.

With reference next to <FIG>, the computing device <NUM> includes a data access manager <NUM> loaded onto the computing device and configured to interface between applications <NUM> and the operating system <NUM> to manage secure access of data files mapped to memory <NUM>. The data access manager <NUM> may be a device driver, application program interface (API), or other such routine or protocol configured to be loaded onto the computing device <NUM>. The data access manager <NUM> may be stored in memory <NUM> for the processing component I <NUM> or on the data storage module <NUM>. During power-up or during initialization of the operating system <NUM>, the operating system detects the presence of the data access manager <NUM> on the computing device <NUM> and launches the data access manager <NUM> so it is available when other applications <NUM> are executing. The data access manager <NUM> monitors data access requests <NUM> from applications and intercepts the data access request <NUM> before it is received by the intended recipient of the operating system.

In operation, the data access manager <NUM> operates transparently to the calling application <NUM> and to the operating system <NUM> to control access to data read from data files <NUM> and mapped into men1ory <NUM>, Turning initially, to <FIG>, an illustration of a memory management unit <NUM> executing according to conventional operation is illustrated. The memory management unit <NUM> controls access to data stored in memory <NUM>. It is contemplated that the data may be either persisted or non-persisted data. Persisted data is data associated with a file <NUM> stored in the data storage module <NUM>. The data from the file <NUM> may be copied to memory <NUM> either in whole or in part for subsequent access by applications <NUM> executing on the computing device <NUM>. When the last application <NUM> is finished with persisted data, the data in memory <NUM> is written back to the file <NUM> and saved on the data storage module <NUM>. Non-persisted data is data generated by an application <NUM> for temporary use and is not stored into the data storage module <NUM>. One or more applications <NUM> may need access to the data and the memory management unit <NUM> controls access to the data. When the last application <NUM> is finished with non-persisted data, the data in memory <NUM> is lost and the memory locations released by the memory management unit for subsequent use by other applications <NUM>.

To access data from written to memory, the data must first be mapped by the memory management unit <NUM>. According to the example illustrated in <FIG>, data from a data file <NUM> is loaded into memory as a memory mapped file <NUM>. A first application 120A issues a request to map data from the data file <NUM> to memory I <NUM>. The memory management unit <NUM> receives the request and copies the data to memory <NUM> creating the memory mapped file <NUM>. Although illustrated as a series of consecutive address locations in memory I <NUM>, the memory mapped file <NUM> may be stored in several non-consecutive memory blocks and the 1nernory management unit <NUM> may maintain a record of the memory blocks associated with the memory mapped file <NUM>. The memory management unit <NUM> maintains a pointer, or series of pointers, to the physical locations of memory <NUM> to which the memory mapped file <NUM> is stored. The memory management unit <NUM> generates another pointer which it returns to the first application 120A. The first application may use the additional pointer as a file handle to later access the memory mapped fi1e <NUM>.

With reference still to <FIG>, the first application 120A accesses the memory mapped file <NUM> using the file handle returned from memory management unit <NUM> during the initial mapping of the data from the data storage module <NUM> to memory <NUM>. The first application 120A may request to access the entire mapped file data <NUM> or to access portions of the file data, referred to as blocks <NUM> of the file data. Each request to access data may be for read access, write access, or to both read and write the data, The request to access data is illustrated as a view by the calling application <NUM>. In <FIG>, the first application 120A is requesting access to two different blocks <NUM> of the memory mapped file <NUM>. A first view 162A is requesting access to a first block 164A, and a second view 162B is requesting access to a second block 164B. To create a view <NUM> of the data in the memory mapped file <NUM>, the first application 120A generates a request to view the data using the file handle it received when the data was mapped to memory. The memory management unit <NUM> uses a first memory address <NUM> to identify the desired block of memory I <NUM> to which the first application 120A is requesting access and returns a second address <NUM> to the first application, The memory management unit <NUM> uses the two different addresses to establish a virtual memory map between the application and memory. While the calling application requires access to the data, it can generate subsequent access requests using the second memory address <NUM> to the memory management unit <NUM> and the memory management unit <NUM> retrieves the data from memory <NUM> using the first memory address <NUM>.

By creating the virtual memory map, the memory management unit <NUM> is able to manage requests to the same data from multiple applications. According io the example illustrated in <FIG>, a first application 120A and a second application 120B are both requesting access to the same data file <NUM>. The first application 120A has a first view 162A requesting data from a first block 164A and a second view 162B requesting data from a second block 164B. The second application 120B has a first view 162C, which is also requesting data from the second block 164B, and a second view 162D requesting data from a third block 164C. Because the first and second applications 120A, 120B are the only applications requesting data from the first and third blocks <NUM>, 164C, respectively, the memory management unit <NUM> may pass the data freely back and forth between the application and memory <NUM>. However, because both applications 120A, 120B are requesting access to the second block 164B, the memory management unit <NUM> must control access such that one application does not overwrite data while another application is attempting access. By the virtual memory map, the memory management unit <NUM> assigns a first pointer I 42B to the second block 164B for use by the first calling application 120A and a second pointer 142C to the second block 164B for use by the second calling application 120B. The memory management unit <NUM> knows which application <NUM> is requesting the data and may provide access accordingly.

Turning next to <FIG>, the data access manager <NUM> is executed by the operating system <NUM> and is configured to intercept requests generated by applications <NUM> to either map data to memory I <NUM> or to subsequently access the data mapped to memory. The data access manager <NUM> is illustrated between each application <NUM> and the memory management unit <NUM>. As previously indicated, the data access manager <NUM> operates transparently to the calling application <NUM> and to the operating system <NUM> to control access to data read from data files <NUM> and mapped into memory <NUM>. Each application 120A, 120B, I 20C generates the same system call for the corresponding operating system <NUM> as it would if the data access manager <NUM> were not present. The data access manager <NUM> intercepts the system calls and then determines whether the calling application <NUM> is permitted to access the data in memory <NUM>. When the calling application <NUM> is permitted to access the data, the data access manager <NUM> returns a pointer to clear data. When the calling application <NUM> is not permitted to access the data, the data access manager <NUM> returns a pointer to encrypted data.

With reference next to <FIG>, the steps performed by the data access manager <NUM> according to one embodiment of the invention are illustrated. With reference first to <FIG>, the application <NUM> generates a request to create a file mapping as shown in step <NUM>. The request may be for secure data or clear data stored in the data storage module <NUM> or the request may be to establish a section of memory <NUM> in which the application may read and write non-persistent data as needed by the application <NUM>. The data access manager <NUM> is configured to intercept each request to create a file mapping as shown in step <NUM>. After intercepting a request to create a file mapping, the data access manager <NUM> determines whether a mapping for the requested data already exists, as shown in step <NUM>. If the data is not yet mapped, the data access manager <NUM> interfaces with the memory management unit <NUM> to coordinate mapping of the requested data as shown in step <NUM>. If the data requested by the application <NUM> has already been mapped to memory by another application, the data access manager <NUM> will verify whether the new application <NUM> has permission to access the mapped data as shown in step <NUM>. At step <NUM>, the data access manager <NUM> returns a pointer to clear data, a pointer to encrypted data, or, optionally, the data access manager may pass through an error message to the calling application.

Turning next to <FIG>, additional detail for the step <NUM> of establishing a new memory mapped file is illustrated. As an initial step, the data access manager <NUM> determines whether the requested data is encrypted, as shown in step <NUM>. It is contemplated that the request from the application <NUM> may indicate whether the data is encrypted and provide an encryption key. If the data requested by the application is not encrypted, the data access manager <NUM> reads the clear data from the data file <NUM> on the data storage module <NUM>, as shown in step <NUM>, and interfaces with the memory management unit <NUM> to map the dear data into memory I <NUM>, as shown in step <NUM>. It however, the data requested by the application is encrypted, the data access manager <NUM> first reads the encrypted data from the data storage module <NUM>, as shown in step <NUM>, and requests that the encrypted data is stored as a mapped data file <NUM>, as shown in step <NUM>. The data access manager <NUM> receives a file handle from the memory management unit <NUM> corresponding to the location of the encrypted data in memory.

The data access manager <NUM> is also configured to interface with DRM software executing on the computing device <NUM>. As shown in step <NUM>, the data access manager <NUM> determines whether the calling application <NUM> is permitted to access the requested data. The data access manager may call the DRM software to determine whether the requested data is protected under the DRM software. If the requested data is a data file <NUM> for which there are no permissions established, the data access manager <NUM> proceeds as if the calling application is defined as an allowed application. If the data is non-persistent data utilized by the requesting application <NUM>, the data access manager <NUM> may similarly pass the request to create a file mapping to the memory management unit <NUM> such that it may reserve the appropriate blocks of memory <NUM>. If the requested data is a data file <NUM> for which the DRM software has established permissions, the data access manager <NUM> examines the permissions to determine whether the requesting application <NUM> has permission to access the file <NUM>. If the requesting application <NUM> does not have permission to access the file <NUM>, the data access manager <NUM> returns a pointer to the encrypted data mapped in step <NUM>. If the requesting application <NUM> has permission to access the file <NUM>, the data access manager <NUM> calls a decryption routine at step <NUM> to decrypt the data. At step <NUM>, the data access manager I <NUM> then requests that the memory management unit <NUM> store the clear data in memory <NUM> as a second mapped data file <NUM>. The memory management unit maps the clear data to memory <NUM> and provides a file handle for the clear data to the data access manager <NUM>. For encrypted data, therefore, the data access manager <NUM> has received two file handles from the memory management unit <NUM> where a first file handle identifies secure data mapped to rnen1ory <NUM> and a second file handle identifies clear data mapped to memory. The data access manager <NUM> provides an additional level of virtual memory abstraction on top of that provided by the memory management unit <NUM>. The data access manager <NUM> maintains a record of the file handles for both the encrypted data and the clear data and associates both file handles with the requested data. When the calling application <NUM> has permission to access the secure data, the data access manager <NUM> returns the pointer for the clear data to the application. When the calling application <NUM> does not have permission to access the secure data, the data access manager <NUM> returns the pointer for the clear to the application. In any event, both the requesting application <NUM> and the memory management unit <NUM> are unaware of the presence or intervention by the data access manager.

After a first application 120A has requested that data be mapped to memory <NUM>, a second application 120B may request that the same data be mapped to memory. The second application 120B will also issue a request to create a file mapping, as shown in step <NUM> of <FIG>. The data access manager <NUM> again intercepts the request at step <NUM>. At step <NUM>, the data access manager <NUM> recognizes that the data has already been mapped to memory <NUM> and moves to step <NUM> to detem1ine whether the second application 120B has permission to access the previously mapped data. With reference also to <FIG>, the steps for determining whether the second application has permission to access previously mapped data are displayed in more detail. The data access manager <NUM> determines whether the second application 120B has permission to access the mapped data as shown in step <NUM>. Similar to the steps discussed above with respect to determining permission for the first application 120A, the data access manager may call the DRM software to determine whether the requested data is protected under the DRM software. If the requested data is a data file <NUM> for which there are no pe1rnissions established and is accessible by any calling application, the data access manager <NUM> may simply return a file handle previously established by the memory management unit <NUM>. If the requested data is a data file <NUM> for which the DRM software has established permissions, the data access manager <NUM> examines the permissions to determine whether the second requesting application 120B has permission to access the file and, therefore, to access the previously mapped data. If the data access manager <NUM> determines that the second requesting application 120B does have permission to access the mapped data, the data access manager <NUM> returns the pointer for the clear data to second calling application, as indicated in step <NUM>. If the data access manager <NUM> determines that the second requesting application 120B does not have permission to access the mapped data, the data access manager <NUM> moves to step <NUM> to determine whether the requested data was encrypted data. If the requested data was encrypted data, the data access manager <NUM> has previously stored pointers both to clear data and to encrypted data. As illustrated in step <NUM>, when the second calling application 120B does not have permission to access encrypted data, the data access manager <NUM> will return the pointer for the enc1ypted data to the second calling application. If the requested data was not encrypted but the second calling application 120B does not have permission to access the mapped data, the data access manager may return an access error, as shown in step <NUM>, to the calling application <NUM>. The access error may be generated by the DRM software when the data access manager <NUM> checks permissions and the access error may simply be passed through by the data access manager <NUM> to the calling application.

According to another embodiment of the invention, it is contemplated that the data access manager <NUM> may be configured to generate a first and second pointer for non-encrypted data as well as for encrypted data. When the data access manager <NUM> intercepts a request to read non- encrypted data, the data access manager may first request the memory management unit <NUM> to map data to a first location. It is contemplated that the data access manager <NUM> may request encryption of the data and store the encrypted data to the first location. Optionally, the data access manager <NUM> may fill the location with null characters, zeros, or any other data. According to still another option, the data access manager <NUM> may request the memory management unit <NUM> map a length of memory corresponding to the requested data but leave the existing contents from prior mapping of data such that the contents of the first location are random. The data access manager <NUM> then requests the memory management unit <NUM> to map the clear data to a second location. In this manner, the data access manager <NUM> may always include pointers to first and second memory mapped data regardless of whether the data was previously encrypted. When a second application 120B requests access, the data access manager <NUM> then simply passes the first pointer to approved applications and the second pointer to restricted applications.

Turning next to <FIG>, an example of three applications <NUM> requesting access to the same encrypted data is illustrated. In the illustrated example, the first application 120A and the second application 120B each have permission to access the data, and the third application 120C does not have permission to access the data. The first application 120A generates a request to map the encrypted data to memory104. The data access manager <NUM> intercepts the request and determines that the data has not yet been mapped to memory <NUM>. The data access manager <NUM> requests that the encrypted data be mapped to memory104. According to the illustrated embodiment, the encrypted data is shown as the second file block 260B in memory <NUM>. The memory management unit <NUM> returns a file handle 244B to the data access manager corresponding to the physical location 246B in memory <NUM> at which the encrypted data is mapped. The data access manager <NUM> decrypts the data and then requests that the memory management unit <NUM> store the decrypted data to memory <NUM> as well. The memory management unit <NUM> returns a file handle 244A to the data access manager corresponding to the physical location 246A in memory <NUM> at which the dear data is mapped. According to the illustrated embodiment, the decrypted data is shown as the first file block 260A in memory <NUM>. After mapping the decrypted data to memory, the data access manager <NUM> provides a unique file handle 242A to the first application 120A for subsequent access to the mapped data file 260A.

In the illustrated embodiment, both the first and second applications 120A, 120B seek access to the same block 264A of data. The first application 120A has requested that the data be mapped to memory and subsequently establishes a view of the data block 264A using the first unique file handle 242A provided by the data access manager <NUM>. The second application 120B subsequently requests the same data to be mapped. The data access manager <NUM> intercepts this request and determines that it has already caused the data to be stored as the first mapped data file 260A. The data access manager <NUM> determines that the second application 120B has permission to access the data and returns a second unique file handle 242B to the second application. The data access manager <NUM> associates both the first file handle 242A and the second file handle 242B provided to the calling applications with the stored file handle 244A, provided by the memory management unit <NUM>, corresponding to the physical address 246A of the clear data mapped into memory <NUM>. Each calling application is unaware of the presence of the data access manager <NUM> and uses its respective pointer 242A or 242B to access the mapped data 260A.

The illustrated embodiment further illustrates a third application 120C attempting to access the data previously mapped by the first application 120A. The data access manager <NUM> again intercepts the request from the third application to map this data. The data access manager <NUM> recognizes that the data is already mapped and determines that the third application 120C does not have permission to access the data. Because the data access manager <NUM> previously stored clear data in a first memory mapped file 260A and the encrypted data in a second memory mapped file 260B, the data access manager <NUM> has stored a first file handle 244A associated with the first memory mapped file 260A and a second file handle 244B associated with the second memory mapped file 260B. The data access manager <NUM> returns a third unique file handle 242C to the third calling application 120C. However, rather than associating the third unique file handle with the clear data, the data access manager <NUM> associates the third unique file handle 242C with the file handle 244B corresponding to the encrypted data. As a result, when the third application 120C attempts to access the data, the view 262C of the data for the third app11cation is directed to the encrypted block 264B rather than the decrypted block 264A, preventing the third application I 20C from accessing the data. The third application 120C only receives encrypted data rather than being able use the clear data also stored in memory. Thus, the data access manager <NUM> prevents a subsequent calling application from accessing data that has already been mapped to memory without the proper authorization.

Claim 1:
A method of managing access to secure data mapped into memory (<NUM>) on a computing device (<NUM>), the method comprising the steps of:
intercepting a request to view the secure data mapped into the memory (<NUM>), wherein the request to view is intercepted by a data access manager (<NUM>) of the computing device (<NUM>) and from an application (120A, 120B, 120C) executing on the computing device, before the request is received by a memory management unit (<NUM>);
determining (<NUM>) whether the application is allowed to access the secure data in the memory (<NUM>) with the data access manager, wherein the memory includes the secure data mapped to a first location in the memory and a clear form of the secure data mapped to a second location in the memory different from the first location;
transmitting (<NUM>) to the application (120C) a first pointer (242C) assigned by the memory management unit (<NUM>) of the computing device (<NUM>), when the application is not allowed to access the secure data; and
transmitting (<NUM>) to the application (120A, 120B) a second pointer (242A) assigned by the memory management unit (<NUM>), when the application is allowed to access the secure data,
wherein the first pointer (242C) directs (244B) the application (120C) to access the secure data mapped (260B) to the first location (246B) in the memory, and the second pointer (242A) directs (244A) the application (120C) to access the clear form of the secure data mapped (260A) to the second location (246A) in the memory.