U.S. patent application number 14/819322 was filed with the patent office on 2017-02-09 for systems and methods for providing secure data.
This patent application is currently assigned to DELL PRODUCTS L.P.. The applicant listed for this patent is DELL PRODUCTS L.P.. Invention is credited to Christopher Burchett, James Michael Burke, Carrie Elaine Gates, David Konetski, Elliot D. Lewis, Warren Wade Robbins, Richard William Schuckle, Chad Skipper.
Application Number | 20170039376 14/819322 |
Document ID | / |
Family ID | 58052575 |
Filed Date | 2017-02-09 |
United States Patent
Application |
20170039376 |
Kind Code |
A1 |
Skipper; Chad ; et
al. |
February 9, 2017 |
SYSTEMS AND METHODS FOR PROVIDING SECURE DATA
Abstract
Aspects of the present invention provide the ability to enforce
access methods on data based upon a policy or policies identified
within the metadata of a file. The data is self-protected by
including or being wrapped with policies/rules that act as a form
of body armor to the data when in transit or in different
situations. In embodiments, access is only granted upon successful
authentication and compliance with the identified policy or
policies. In embodiments, depending upon the conditions and
policies, varying level access may be granted. In embodiments,
depending upon the conditions and policies, the system may take one
or more mitigations or remedial access levels, such as
containerizing, sandboxing, granting limited access, or erasing the
data.
Inventors: |
Skipper; Chad; (Granger,
TX) ; Lewis; Elliot D.; (Henderson, NV) ;
Konetski; David; (Austin, TX) ; Burchett;
Christopher; (Lewisville, TX) ; Schuckle; Richard
William; (Austin, TX) ; Burke; James Michael;
(Frisco, TX) ; Robbins; Warren Wade; (Celina,
TX) ; Gates; Carrie Elaine; (Livermore, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
DELL PRODUCTS L.P. |
Round Rock |
TX |
US |
|
|
Assignee: |
DELL PRODUCTS L.P.
Round Rock
TX
|
Family ID: |
58052575 |
Appl. No.: |
14/819322 |
Filed: |
August 5, 2015 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/10 20130101;
G06F 21/6209 20130101; G06F 21/604 20130101; H04L 63/20
20130101 |
International
Class: |
G06F 21/62 20060101
G06F021/62; H04L 29/06 20060101 H04L029/06 |
Claims
1. A computer-implemented method for accessing content of a
protected file on a computing device, the method comprising:
receiving a protected file comprising an encrypted payload and
metadata, the metadata comprising information regarding at least
one of: (a) contextual metadata of the protected file and (b) one
or more policies related to contextual conditions under which
access to a user-accessible format of the content of the encrypted
payload may be granted; responsive to receiving an access request
from a user to access the content of the encrypted payload,
performing the steps comprising: obtaining from a memory one or
more policies related to contextual conditions under which access
to a user-accessible format of the content of the encrypted payload
may be granted; collecting contextual data using the computing
device, the contextual data being relevant to the contextual
conditions of the one or more policies; applying the collected
contextual data to the one or more policies to identify one or more
access levels to a user-accessible format of the content of the
encrypted payload; and granting, via the computing device, an
access level from the one or more access levels to the user.
2. The computer-implemented method of claim 1 wherein the
information in the metadata regarding one or more policies related
to contextual conditions under which access to a user-accessible
format of the content of the encrypted payload may be granted
comprises: the one or more policies or one or more identifiers for
accessing the one or more policies from a policy dataset.
3. The computer-implemented method of claim 2 wherein the step of
obtaining from a memory one or more policies related to contextual
conditions under which access to a user-accessible format of the
content of the encrypted payload may be granted comprises:
obtaining the one or more policies from the metadata of the
protected file, from a policy dataset, or both.
4. The computer-implemented method of claim 3 wherein the policy
dataset is obtained from at least one of: a policy module on the
computing device; and a secure data access system management server
that is communicatively coupled to the computing device.
5. The computer-implemented method of claim 1 wherein: the step of
applying the collected contextual data to the one or more policies
to identify one or more access levels to a user-accessible format
of the content of the encrypted payload comprises determining that
no access is appropriate given the collected contextual data and
the one or more policies associated with the protected file; and
the step of granting, via the computing device, an access level
from the one or more access levels to the user comprises not
granting any access to a user-accessible format of the content of
the encrypted payload.
6. The computer-implemented method of claim 1 further comprising:
taking one or more actions to affect one or more conditions of the
computing device related to at least part of the contextual data
prior to granting an access level from the one or more access
levels for accessing the content of the encrypted payload in a
user-accessible format.
7. The computer-implemented method of claim 6 wherein the step of
taking one or more actions comprises at least one of: alerting the
user to configure the device to a specified setting; and
implementing one or more security features of the computing
device.
8. The computer-implemented method of claim 1 wherein the step of
collecting contextual data using the computing device comprises:
collecting one or more contextual data as indicated by the one or
more rules, the contextual data comprising at least some of clock
data, location data, BIOS data, operating system data, file system
data, network data, connectivity data, security features data, user
data, authentication data, user privileges data, software data of
the computing device, and hardware data of the computing
device.
9. The computer-implemented method of claim 1 further comprising:
decrypting the encrypted payload; and responsive to the decrypted
payload comprising encoded data, repeating at least the decryption
process until a user-accessible format of the content is
achieved.
10. The computer-implemented method of claim 9 further comprising:
responsive to the decrypted payload comprising additional metadata
identifying one or more additional policies related to contextual
conditions under which access to a user-accessible format of the
content of the encrypted payload may be granted, analyzing the one
or more additional policies, and, if needed: collecting contextual
data relevant to the contextual conditions of the one or more
additional policies; and applying the collected contextual data to
the one or more additional policies to identify one or more access
levels to a user-accessible format of the content of the encrypted
payload.
11. A system for enforcing one or more policies associated with a
protected filed, the system comprising: a memory for storing the
protected file comprising an encrypted payload and metadata, the
metadata comprising information regarding at least one of
contextual metadata of the protected file and one or more policies
related to contextual conditions under which access to a
user-accessible format of the encrypted payload may be granted; a
secure data format processor that coordinates system components to
determine what level or levels of access rights to a
user-accessible format of the encrypted payload may be granted to a
user of the system based, at least in part, upon applying a set of
contextual data to the one or more policies; an access control
engine that is communicatively coupled to the secure data format
processor and analyzes specific protection policies or rules and
evaluates current situational characteristics; one or more
extensible content transformation modules, communicatively coupled
to the secure data format processor via a security services
component, that provides one or more transformative capabilities to
the secure data format processor by adding one or more trusted
program modules, the one or more transformative capabilities
comprising decoding the encrypted payload into a user-accessible
format; a security service component, communicatively coupled to
the secure data format processor and to the one or more extensible
content transformation components, that provides operational and
data management related to security operations; a policy/rules
module, communicatively coupled a secure data access system
management server and to the access control engine, that acquires
and caches one or more policies related to contextual conditions
under which access to a user-accessible format of the encrypted
payload may be granted; a system instrumentation module,
communicatively coupled to the access control engine and to one or
more instrumentation components, that collects contextual data
relevant to the contextual conditions of the one or more policies
and that provides at least some of the collected contextual data to
the access control engine; and an access environmental controls
module, communicatively coupled to the access control engine, that
executes one or more access control directives related to
determined appropriate by the access control engine.
12. The system of claim 11 further comprising: an
authentication/authorization module, communicatively coupled to the
access control engine, that authenticates a user of the system.
13. The system of claim 11 wherein the access rights comprises one
or more of: decoding at least part of the encrypted payload; and
providing an alternative access means allowed by the one or more
policies based upon the collected contextual data.
14. The system of claim 11 wherein the access control engine also
receives from the access environmental controls module information
about available access controls on the system.
15. The system of claim 11 further comprising: an audit services
module, communicatively coupled to the secure data format process,
that provides one or more audit alerts related to access
operations.
16. The system of claim 15 further comprising: an intelligence
management module, communicatively coupled to the audit services
module, that aggregates and correlate alerts to produce predictive
conditions measurements to provide possible insight into future
behaviors.
17. The system of claim 11 further comprising: a trusted supply
chain component, communicatively coupled to the security module,
that provides run-time instrumentation and root-of-trust
implementation platform.
18. A computer-implemented method for protecting a data file
regarding of contextual conditions in which the data file resides,
enforcing one or more policies associated with a protected filed,
the system comprising: encrypting the data file using one or more
encryption modules; forming one or more rules related to
situational conditions under which access to the data file may be
granted to a user requesting via a computing device to access the
data file; and generating a protected data file comprising the
encrypted data file and metadata comprising information regarding
the one or more rules related to situational conditions under which
access to the data file may be granted.
19. A computer-implemented method of claim 18 wherein the
information in the metadata regarding the one or more rules
comprises: the one or more rules or one or more identifiers for
accessing the one or more rules from a secure rules dataset.
20. A computer-implemented method of claim 18 wherein the one or
more rules identify a mitigation level or levels of access to the
data file responsive, at least in part, to data collected using the
user's system that represents situational conditions under which
the user's request was made.
Description
TECHNICAL FIELD
[0001] The present disclosure relates to data handling. More
particularly, the present disclosure related to systems and methods
for improving the secure handling of data.
DESCRIPTION OF THE RELATED ART
[0002] As the value and use of information continues to increase,
individuals and businesses seek additional ways to process and
store information. One option available to users is information
handling systems. An information handling system (or computing
system) generally processes, compiles, stores, and/or communicates
information or data for business, personal, or other purposes
thereby allowing users to take advantage of the value of the
information. Because technology and information handling needs and
requirements vary between different users or applications,
information handling systems may also vary regarding what
information is handled, how the information is handled, how much
information is processed, stored, or communicated, and how quickly
and efficiently the information may be processed, stored, or
communicated. The variations in information handling systems allow
for information handling systems to be general or configured for a
specific user or specific use, such as financial transaction
processing, airline reservations, enterprise data storage, or
global communications. In addition, information handling systems
may include a variety of hardware and software components that may
be configured to process, store, and communicate information and
may include one or more computer systems, data storage systems, and
networking systems.
[0003] Along with the increased use of information handling systems
has come the dramatic increase in the amount and use of data.
Unfortunately from a security perspective, data has a tendency to
be borderless and to leak. In today's world of mobile data, data
can reside almost anywhere and on any system.
[0004] With the spread of mobile devices and cloud-enabled
software, the ability to protect data has become increasingly
difficult. Prior to the advent of mobility and cloud solutions,
data could be protected by "hardening" the network perimeter and
making sure that data only became available to corporate-owned,
corporate-controlled assets, such as company servers, laptops, and
desktops. Also, data was only previously accessed and handled by
datacenter-based applications and storage solutions. In these
traditional or "classic" models of datacenter and
corporate-controlled endpoints, data could be kept under control by
locking down the perimeter of the network and "walling off" the
data from the outside world.
[0005] FIG. 1 depicts the typical or classic network operational
model. As shown in FIG. 1, data was completely contained on
corporate assets within a singular network design. Data needed to
be accessed within the corporate infrastructure 105 either directly
from corporate-managed clients 115 via secure connections (e.g.,
VPN 120 via a demilitarized zone 110).
[0006] This model has drastically changed in the last few years to
encompass cloud-based solutions for application access, storage,
inter-company operations, and data exchange. The idea of
controlling data has become much more difficult, as the nature of
data today is to "leak" beyond the corporate control.
[0007] Furthermore, with the pervasive expansion of
"Bring-Your-Own-Device" scenarios (in which personally-owned
devices are used in corporate settings and on which corporate-owned
data can arrive and be stored), cloud-based applications,
cloud-based storage solutions, partner networks, and beyond, the
traditional or classic models of containing data and trying to
prevent it from leaking from the network are outdated and
ineffective.
[0008] Accordingly, what is needed are systems and methods that
provides the ability to enforce access methods on data based upon
injected policy or policies within the metadata of the file.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] References will be made to embodiments of the invention,
examples of which may be illustrated in the accompanying figures.
These figures are intended to be illustrative, not limiting.
Although the invention is generally described in the context of
these embodiments, it should be understood that it is not intended
to limit the scope of the invention to these particular
embodiments.
[0010] FIG. 1 ("FIG. 1") depicts the typical or classic network
operational model, in which data was completely contained on
corporate assets within a singular network design.
[0011] FIG. 2 depicts a high-level block diagram of a system that
provides data security according to embodiments of the present
invention.
[0012] FIG. 3 depicts a block diagram of a system that provides
data security according to embodiments of the present
invention.
[0013] FIG. 4 depicts a general phases of the Secure Data Access
System (SDAS) according to embodiments of the present
invention.
[0014] FIG. 5 depicts the initialization phase according to
embodiments of the present invention.
[0015] FIG. 6 depicts SDAS application initialization according to
embodiments of the present invention.
[0016] FIG. 7 depicts preprocessing phase according to embodiments
of the present invention.
[0017] FIG. 8 depicts processing phase according to embodiments of
the present invention.
[0018] FIG. 9 depicts finalization phase according to embodiments
of the present invention.
[0019] FIG. 10 depicts an example secure data file structure
according to embodiments of the present invention.
[0020] FIG. 11 depicts a simplified block diagram of an information
handling system according to embodiments of the present
invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0021] In the following description, for purposes of explanation,
specific details are set forth in order to provide an understanding
of the invention. It will be apparent, however, to one skilled in
the art that the invention can be practiced without these details.
Furthermore, one skilled in the art will recognize that embodiments
of the present invention, described below, may be implemented in a
variety of ways, such as a process, an apparatus, a system, a
device, or a method on a tangible computer-readable medium.
[0022] Components, or modules, shown in diagrams are illustrative
of exemplary embodiments of the invention and are meant to avoid
obscuring the invention. It shall also be understood that
throughout this discussion that components may be described as
separate functional units, which may comprise sub-units, but those
skilled in the art will recognize that various components, or
portions thereof, may be divided into separate components or may be
integrated together, including integrated within a single system or
component. It should be noted that functions or operations
discussed herein may be implemented as components. Components may
be implemented in software, hardware, or a combination thereof.
[0023] Furthermore, connections between components or systems
within the figures are not intended to be limited to direct
connections. Rather, data between these components may be modified,
re-formatted, or otherwise changed by intermediary components.
Also, additional or fewer connections may be used. It shall also be
noted that the terms "coupled," "connected," or "communicatively
coupled" shall be understood to include direct connections,
indirect connections through one or more intermediary devices, and
wireless connections.
[0024] Reference in the specification to "one embodiment,"
"preferred embodiment," "an embodiment," or "embodiments" means
that a particular feature, structure, characteristic, or function
described in connection with the embodiment is included in at least
one embodiment of the invention and may be in more than one
embodiment. Also, the appearances of the above-noted phrases in
various places in the specification are not necessarily all
referring to the same embodiment or embodiments.
[0025] The use of certain terms in various places in the
specification is for illustration and should not be construed as
limiting. A service, function, or resource is not limited to a
single service, function, or resource; usage of these terms may
refer to a grouping of related services, functions, or resources,
which may be distributed or aggregated. Furthermore, the use of
memory, database, information base, data store, tables, hardware,
and the like may be used herein to refer to system component or
components into which information may be entered or otherwise
recorded.
[0026] The terms "packet," "datagram," "segment," or "frame" shall
be understood to mean a group of bits that can be transported
across a network. These terms shall not be interpreted as limiting
embodiments of the present invention to particular layers (e.g.,
Layer 2 networks, Layer 3 networks, etc.); and, these terms along
with similar terms such as "data," "data traffic," "information,"
"cell," etc. may be replaced by other terminologies referring to a
group of bits, and may be used interchangeably. Any headings used
herein are for organizational purposes only and shall not be used
to limit the scope of the description or the claims.
[0027] Furthermore, it shall be noted that: (1) certain steps may
optionally be performed; (2) steps may not be limited to the
specific order set forth herein; (3) certain steps may be performed
in different orders; and (4) certain steps may be done
concurrently.
A. General Overview
[0028] Maintaining data security is an important issue that is
becoming increasingly more complex. Previous attempts to address
this issue typically fall within two categories. As discussed above
the classic model is to control the location of the data. Another
category relates to application-level security. Each one can imbed
information into a data file in a particular way that will keep the
file from being accessed without permissions. However, these
application-level approaches have significant shortcomings.
[0029] Consider, by way of comparison, an application-level
encryption of files, such as Adobe Acrobat files, which have been
password-protected. In this case, the file is encrypted and only
readable if the Adobe Reader software is present and the user knows
the password. Assuming, for sake of argument, that a password
requirement might be considered a "policy," it is at best a static
password policy. Acrobat files have no the ability to create and
implement any complex policies.
[0030] In contrast, embodiments of the present invention allow
files to assess their current environment for conditions, such as,
by way of illustration only, validation of identity, system OS,
device type, network detection, etc. and use this information in
assessing complex policies. Furthermore, embodiments of the present
invention allow for multiple methods of access beyond simple
decryption. This approach comprises a much more complex and
comprehensive policy assessment capability than just a simple
password.
[0031] Also consider, by way of comparison, Microsoft Digital
Rights Management (DRM), which works on an application level. The
DRM works with Microsoft Office to apply certain access and control
rights to an Office document (e.g., .docx, .xlsx, .pptx, etc.) by
applying a wrapper that has a policy applied to it using XrML
(eXtensible Rights Markup Language) coding that can be authorized
for access using Microsoft Active Directory Group Policy Object
(GPO) coding. To be able to access a Microsoft DRM-enabled file,
the file must be accessed using a Microsoft DRM-enabled application
(e.g., Microsoft Office applications such as Word, Powerpoint,
Excel, Outlook). The application reads the XrML policies and
applied controls and restrictions embedded in the application
level.
[0032] However, once again there are several key differences
between embodiments of the present invention and Microsoft DRM.
First, in embodiments, XrML is not used for the encoded policy.
Second, the data secured according to embodiments of the present
invention are not dependent upon Microsoft applications to read the
policy. Third, the policy or policies of the present invention
affect what the application can do with the file in question, which
is a key differentiator from Microsoft DRM. Embodiments of the
present invention work at a data file level and are independent of
Microsoft Office, Microsoft Active Directory, and Microsoft Group
Policy Object (GPO). Fourth, Microsoft DRM only works on
Microsoft-based Windows and Office systems; whereas embodiments of
the present invention are platform and application agnostic.
[0033] Unlike embodiments of the present invention, these prior
approaches do not embed policy or policies into the data files; nor
do they perform any interactive investigation of the current
environment conditions and heuristics to make complex decisions on
various factors, such as, by way of example: (1) whether a file
will decrypt under the current conditions or stay encrypted; (2) if
the decision is for the local file to stay encrypted, will the
policy of the file allow for access to the data under another means
(i.e., viewing another copy of the file virtually in a different
location, under a secure container on a mobile device, etc.); and
(3) if the decision is not to allow access, should the data file
destroy itself in place and remove itself from the current
environment without allowing any access.
[0034] To enable the original owner of data to maintain control of
their data no matter where it goes, what it is accessed on, under
any circumstances, embodiments of the present invention provide
data the ability to do several actions, including but not limited
to:
[0035] (1) The data can be encrypted at all times in order to
protect itself from unauthorized access;
[0036] (2) The data can carry with it a set of policy
controls/rules that define for the data at any time how, when, on
what, and by whom it can be accessed;
[0037] (3) The data has tools available to assess its current
environment and situation, and apply the heuristics of its current
situation against an on-board policy controls/rules to determine
whether it should allow access to itself;
[0038] (4) The data--in conjunction with a reader software--is able
to deny access to itself entirely if its on-board policy does not
allow for the current conditions;
[0039] (5) The data--in conjunction with the reader software--is
able to determine, from multiple options, exactly how it can be
viewed under the current conditions;
[0040] (6) The data--in conjunction with the reader software--is
able to destroy itself if the current environment is not within the
parameters set by the on-board policy; and
[0041] (7) The data--in conjunction with the reader software--is
able to report back to the original owner of the data what its
current conditions are and provide intelligence as to where it is,
on what system it resides, who is trying to access it.
[0042] FIG. 2 depicts a high-level block diagram of a system that
provides data security according to embodiments of the present
invention. As shown in FIG. 2, the secure data access system (SDAS)
210 is resident on a computing device/information handling system
205. In embodiments, the SDAS 210 may comprise data transformation
services 215, policy enforcement services 220, security services
225, and remote management client services 230. And, in
embodiments, the device 205 may be connected to one or more
networks (e.g., local and/or geographic networks 270). Embodiments
of system components that perform these various services are
presented with respect to FIG. 3--although it shall be noted that
other configuration may also be used.
B. System Embodiments
[0043] FIG. 3 depicts a block diagram of a system that provides
data security according to embodiments of the present invention. As
shown in FIG. 3, the system 310 is resident on a computing
device/information handling system 305. In embodiments, a secure
data access system (SDAS) 310 comprises a secure data format
processor (SDFP) 315, an access control engine (ACE) 320, system
instrumentation 325, access environmental control (AEC) 330, a
security services component (SSC) 335, one or more extensible
content transformation (ECT) modules 340, an audit services module
345, a security module 350, an authentication/authorization
security component (AASC) 355, and policy/rules module 360. In
embodiments the secure data access system operates 310 on a
computer system 305 and may operate in conjunction with a trusted
supply chain module 365. As shown in FIG. 3, in embodiments, the
SDAS 310 is also communicatively coupled to an intelligence
management server 370 and an SDAS management server 375. The
function of each of these components is described in more detail
below.
[0044] 1. Secure Data Format (SDF)
[0045] In embodiments, the data uses a secure data format (SDF),
which is a format specification that supports the SDAS. In
embodiments, the SDF format may be a Resource Interchange File
Format (RIFF)-based file format. In embodiments, this format is an
extension of the standardized RIFF (Resource Interchange File
Format) specification with additions supporting content integrity
verification, encryption, embedded policies, audit data, and other
SDAS manifests and metadata. In embodiments, files of this format
type may have an extension of ".sdf"--although other file
extensions names may be used. This file format allows the data to
be self-protecting; that is, the policies/rules about that data
travel with the data.
[0046] FIG. 10 depicts an example secure data file structure
according to embodiments of the present invention. In embodiments,
the .SDF file structure generally comprises to main types of data,
metadata 1005 and payload data 1010--although other fields may also
be present. In embodiments, the format is extensible to allow for
future expansion to include data within a field, to include
additional data fields, or both.
[0047] In embodiments, the metadata 1005 sections may include
various fields, such as: an SDF header that comprises information
related to the file, which may include information that describes
one or more of who, what, when, and where data; a policy/policy
identifier field that comprises one or more injected policies or
references to policies. In embodiments, the metadata 1005 may
contain one or more other fields.
[0048] One skilled in the art shall recognize that numerous types
of metadata information may be included in the fields. For example,
in embodiments, the metadata may support features or provide
information regarding: integrity and tampering checksums, embedded
encryption key material or encryption key references, encrypted
original filename, Adobe Extensible Metadata Platform (XMP)
metadata, file descriptors (e.g., creation time, last access, last
write, file size, etc.), embedded policies or references to
policies that reside on a server, etc.
[0049] In embodiments, the payload 1010 is encrypted data (e.g., an
encrypted file), which may be encrypted using any of a number of
well-known algorithms (e.g., AES-256) and may use a key that is
embedded in the SDF metadata or a key stored on the server
referenced by a unique ID stored in the SDF metadata. In
embodiments, the file may be a nested file in which the payload is
an SDF file.
[0050] Embodiments of the present invention will allow files to be
assessed based upon a myriad of heuristics and situational
conditions to determine who, how, when, and under what conditions a
file can be accessed, if at all. Presented below is an embodiment
of an architecture for assessing file accessibility:
[0051] (1) Contextual access assessment comprising one or more of:
(a) Identification processing; (b) Endpoint platform assessment;
and (c) Connection allowance assessment;
[0052] (2) Identity management & data access policy comprising
one or more of: (a) Identity verification; (b) Policy selection;
(c) Stateful classification access assessment; (d) Resultant Set of
Policy Resolution (RSOP); and (e) Policy conflict resolution;
[0053] (3) Enforcement controls comprising one or more of: (a)
Firewall; (b) DLP (Data Loss Prevention); (c) AV/AM
(Anti-Virus/Anti-Malware); (d) Network segmentation; (e)
Sandboxing; (f) Containerization; (g) Virtual Private Network
(VPN); (h) Virtualization; and (i) Secure browser;
[0054] (4) Encryption Processing comprising one or more of: (a) Key
management; (b) Platform assessment; (c) Decryption processing; (d)
Encryption processing; (e) Key storage; and (f) Process
closure;
[0055] All of the above items flow into Intelligence management
comprising one or more of: (a) Audit/compliance; (b) Mitigation
selection, activation & monitoring; (c) Ongoing monitoring
& policy adherence; (d) Data integrity monitoring; and (e)
Session monitoring & closure control.
[0056] Some or all of these items discussed above may be considered
and have enforced control(s) that are considered regarding whether
a file should be accessed. In embodiments, one mechanism for
achieving this result is to imbedded policy data in the file
encryption wrapper. Then, in embodiments, a reader application can
assess the policies and the situation of the file in conjunction
with the systems around it to determine whether or not to allow
access or to allow a certain type of access.
[0057] 2. SDAS Management Server (375)
[0058] In embodiments, the secure data access system (SDAS) 310 is
communicatively coupled to and operates under the direction and
authority of a management server 375. In embodiments, the server
375 may be located on premise or may be hosted, such as in
platform-as-a-service (PaaS) resources. In embodiments, the server
375 is where an administrator manages such items as policies, users
and user group settings, and centralized audit data. In
embodiments, it is also the security manager responsible for data
such as keys, certificates, and certain authentication and
authorization-related controls.
[0059] 3. Secure Data Format Processor (SDFP)
[0060] In embodiments, the secure data format processor (SDFP) 315
is responsible for reading and writing secure data format content
(e.g., .SDF files). In embodiments, the processor 315 is
communicatively coupled to and collaborates with the other system
components to ultimately transform clear, unprotected content into
protected content and vice versa.
[0061] 4. Extensible Content Transformation (ECT)
[0062] In embodiments, the extensible content transformation
module(s) 340 is communicatively coupled to the secure data format
processor 315 via a security services component 335 and provide a
mechanism for extending the transformative capabilities of the
secure data format processor 315 by adding one or more trusted
program modules to the system 310. In embodiments, these modules
340 embody programmatic capabilities for transforming data
according to rules of a larger system. By way of illustration and
not limitation, one ECT 340 may deliver content analysis and
filtering/tokenization, while another ECT 340 may offer
compression. This capability allows for multiple ECTs 340 to
operate in concert but in an order or sequence. In embodiments,
that sequence is expressed or recorded in the metadata of the SDF
content upon creation/update and must be honored in reverse order
to transform secure content to a viewable or usable format.
[0063] 5. Access Control Engine (ACE)
[0064] In embodiments, the access control engine (ACE) 320
component is communicatively coupled to the secure data format
processor 315 and is responsible for analyzing specific protection
policies or rules. In embodiments, the ACE 320 also is responsible
for evaluating the current situational characteristics of an
operational request (e.g., encode/decode, protect for access,
provide one or more alternative access means, or protect specific
access content). In embodiments, the results of its evaluation are
made available to the SDFP 315 and other system components
responsible for controlling the access experience, which may
include allowing access, denying access, and enforcing policy
directives such as content or key deletions.
[0065] Given that the Secure Data Access System can understand the
data format, it understands the transformation of the data and can
communicate with all the services components. The system wants to
analyze the specific protection policies or rules that came with
and are protecting that data. Recall that the data is
self-protecting and protects itself as its going anywhere in
transit, like body armor for a soldier who leaves the safe confines
of his or her fortification.
[0066] In embodiments, the Access Control Engine evaluates
situational characteristics, and then provides an operational
request (e.g., encode or decode, protect or unprotect, etc. as
examples). In embodiments, its evaluation is in conjunction with
and interfaces with the SDF processor.
[0067] Also, in embodiments, for the Access Control Engine to allow
access and control, it receives input from other components.
Consider the following example. Given that one of the components
that supplies information to the ACE 320 is the system
instrumentation (SI) 325, the SI 325 may assess one or more current
environment factors, such as, location. The policy that the Access
Control Engine received from the Extensible Content Transformation
that is wrapped around the data, where it was read by the Secure
Data Format Processor might include a policy that states, "If this
data can only be opened within the geographical location of the
United States." Thus, the System Instrumentation 325 informs the
Access Control Engine 320 of the current location and this
information can be used in the determination whether to grant
access. If the file is on a computer in Austin, Tex., then the user
is allowed to open the file, but if the computer is in Montreal,
Quebec, Canada, then the Access Control Engine ascertain that this
policy is violated and will not allow to access in that
environment.
[0068] It should be noted that many environmental factors may be
used for the situational awareness, such as BIOS data properties,
operating system (OS) data properties, network access, hardware
properties, etc. In embodiments, for analysis of directive, the
Access Control Engine may interfaces with components of the SDAS in
a bidirectional manner--receiving data and making requests to the
instrumentation for data. For example, it may ask for policies and
rules from the policies and rules component 360, from the SDAS
management server 375, or both. Thus, if there is any policy
change, the Access Control Engine ask the appropriate system
instrumentation component for data related to the new policy (e.g.,
Is the contextual environment in compliance or out of compliance
with the new policy?).
[0069] 6. Access Environment Control (AEC)
[0070] In embodiments, the access environment control (AEC) 330
component of the system 310 is communicatively coupled to the
Access Control Engine (ACE) 320 and is responsible for carrying out
the access control directives determined appropriate by the ACE 320
component. In embodiments, this logic may be embodied in a secure
access application, which constrains the user experience to the
confines of a single, user mode application. Alternatively, this
access control may be implemented as part of the system software,
which controls access through the device's 305 operating system
using file system filter drivers, network filter drivers, system
services, shell extensions, etc.
[0071] Consider, by way of illustration only, the following
example. Assume that the file has a policy to restrict opening when
outside the U.S. and the file is outside the U.S. One or more
policies may allow certain restricted access when outside the U.S.
For example, the policy may not allow the user to open the file
locally, but may allow one or more options, such as: (1) allow the
user to open, via a secure browser, the file stored at a secure
datacenter; (2) allow the user to open the file via a container on
that endpoint so that it is contained within an environment to
prevent data leaks; (3) allow the user to open the file but grant
read-only access (no printing, saving, sending, etc.); or the like.
Or, a policy may state that if the file is outside the United
States, destroy the file. Thus, in embodiments, the Access Control
Engine receive the policies/rules and data from the system
instrumentation. Based upon that, in embodiments, the ACE 320
obtains the different access environment controls from the AEC 330
that are available on that endpoint. For example, if the endpoint
does not have a secure browser or does not have a container, the
ACE may limit access to what the endpoint does have that is
acceptable; and if there is no acceptable option, the ACE may not
allow access. It shall be noted that many different access
environment controls may be used. It shall also be noted that one
important benefit of such embodiments of the system is that they
provide the power of saying more than just "yes" and "no" under
these constraints and circumstances. In the past, prior systems
either decrypted the file or kept it encrypted--simple binary
results. Here, a range of options may be available based upon the
particular environmental/situations circumstances. Finally, it
shall also be noted that these varied options may also be order or
ranked according to preference of use when one or more are
available to the SDAS 310 when granting access to a file.
[0072] 7. System Instrumentation
[0073] In embodiments, to deliver--for the purposes of assessing
the given security threat environment of the data at its current
location, access environment, and exposure--the environmental
situational awareness, the system leverages system instrumentation
325 to read targeted measurements as indicated by one or more
access rules/policies. Thus, in embodiments, one or more
instrumentation 325 components may be communicatively coupled to
the access control engine (ACE) 320 and may also be communicatively
coupled to the access environmental control component 330.
[0074] Examples of targeted situational/contextual measurements may
include sensor data (e.g., GPS readings, video and/or audio data of
the current surroundings), BIOS data/properties, OS
data/properties, network access data/properties, and other hardware
or software data/properties. In embodiments, the ACE 320 makes
requests for instrumentation readings based on analysis of the
policy servers' directives (e.g., policies stored in module 360
and/or server 375, given the connected environment of the target.
In embodiments, a priority may be set between sources of policies.
For example, in embodiments, policies in the server 375 may be
defined to trump or even overwrite the policies in policy/rules
module 360.
[0075] 8. Security Services Component (SSC)
[0076] In embodiments, a security services component (SSC) 335,
which may be communicatively coupled to the secure data format
processor 315 and to the one or more extensible content
transformation components 340, provides operational and data
management related to security operations. In embodiments, these
security operations may include cryptographic functionality, key
material management, validation, etc. In embodiments, the SSC 335
may communicate with a remote server (not shown) for
security-related services, such as key requests.
[0077] 9. Policy/Rules Component
[0078] In embodiments, the policy/rules component 360 is
communicatively coupled to the SDAS management server 375 and
acquires and caches policies, rules, and settings from the server
375. It should be noted that examples of policies may include
controls related to network access allowances, data sensitivity
allowances (classification access rules, e.g. user can access data
rated as secret), and the like.
[0079] In embodiments, policies may be embedded directly into the
SDF file metadata itself or a reference via unique ID may be
embedded in place of the actual policy. In the latter embodiment,
at the time of file access, the unique ID would be sent to the
server (e.g., SDAS management server 375) to retrieve the current
policy.
[0080] Multiple copies may exist of this file (e.g., via network
shares, sent via email, or stored on cloud storage). In
embodiments, if the policy is embedded into the file, then this
embedded policy may only be updated at certain times (e.g., when a
new copy of the document is saved, because the policy is retrieved
from the server at that time). Although in embodiments, the system
may be configured to update the embedded policy at different times
such a when attempting to be access, at various intervals, or under
other conditions. With embedded policies, older copies of this file
would still contain the old policy if no update condition is
triggered.
[0081] In cases in which a unique policy reference ID is embedded,
it forces the reader application to retrieve the most current
policy from the server at the time of access. This allows users
(e.g., administrators) to change the policy for a file in the
middle of its lifecycle and have that affect how that data is
treated going forward.
[0082] In embodiments, polices/rules may have priority or
precedence levels associated with them to define precedents of when
to update or what policies/rules should trump others.
[0083] 10. AASC--Authentication/Authorization Services
Component
[0084] In embodiments, the SDAS system 310 also comprises an
authentication (AuthN) and authorization (AuthZ) services component
(AASC) 335 to provide operational authentication and authorization
services. It shall be noted that authentication and authorization
services are well known in the art and that any such services may
be employed herein.
[0085] 11. Audit Services
[0086] In embodiments, an audit services component 345 may be
communicatively coupled to the SDFP 315 and provide audit services
for the SDAS 310. For example, in embodiments, the audit services
component 345 provides operational audit alerts for the use and
incorporation into security operations whereby giving the proactive
conditions set forth by the SDAS 310. For example, in embodiments,
these operational audit alerts allow the Intelligence Management
370 to then aggregate and correlate the alerts to produce a
predictive condition or conditions measurements thus providing
possible insight into future behaviors of a target.
[0087] In embodiment, because of the instrumentation data, the
access control environment, the policy rules that are around the
access control engine, and other information available from the
SDAS, alerts from the SDAS can leverage this information and
incorporate aspects of it into security operations--both for
historic and proactive/predictive condition. For example, in
embodiments, the audit services allows an administrator to see what
the data is doing and report back all the transactions and
experiences to the intelligence management 370 and/or SDAS
management server 375.
[0088] 12. Intelligence Management Services
[0089] In embodiments, the SDAS system may be communicatively
coupled to intelligence management services 370. In embodiments,
the intelligence management 370 can aggregate and correlate alerts
to produce predictive conditions measurements, thus providing
possible insight into future behaviors of a target.
[0090] 13. Security Module
[0091] In embodiments, the SDAS system includes a security module
350 communicatively coupled to the access control engine 320 and
may also be communicatively coupled to the trusted supply chain
module 365. In embodiments, the security module 350 provides one or
more security services, such as credentialing participants,
screening and/or validating contents of data and tamper-proof
certificates.
[0092] 14. Trusted Supply Chain
[0093] In embodiments, a trusted supply chain component 365 is
communicatively coupled to the secure data access system 310 or may
be a component of the system 310. In embodiments, the trusted
supply chain component 365 provides run-time instrumentation and
root-of-trust implementation. In embodiments, this provides a set
of instructions in the trusted platform module that is always
trusted by the computers operating system. In embodiments, this
component with the set of instructions serves as a separate compute
engine controlling the trusted platform.
[0094] In embodiments, the trusted supply chain represents an
ability to have a root of trust from a firmware and chip
perspective on the endpoints. For example, if a protected file--a
file with a policy--arrives on a laptop, that laptop hardware can
adapt to the security policy of the file while that file is
resident on that laptop. Thus, in embodiments, the SDAS 305 can
interface with system components in the OS, firmware, and hardware
components to effect changes in the devices functionality.
[0095] Consider a laptop, with a secure data access system, that is
typically not used for working with sensitive data. If a sensitive
file arrives with a policy and rules indicating that it is
sensitive and must be treated in a particular way and/or exists in
a particular environment, the SDAS via the trusted supply chain 365
can have the laptop adopt the security level of that file while it
is resident on the laptop. Thus, the hardware can actually adopt
the sensitivity of the file. For example, wireless access,
Bluetooth, networking functions may be curtailed, USB port access
may be restricted, etc.
[0096] The trusted supply chain 365 allows company devices to
automatically configure themselves to the appropriate security
level based on the resident data. Thus, when no sensitive
information is on the endpoint device, it can maintain a default
security setting. But, when a protected data file is put onto the
device, the system senses the arrival of that protected data and
puts itself into an appropriate security mode while that data is
resident.
[0097] It should also be noted that, in embodiments, any policy may
be implemented, including ones that vary based on the inputs such
as from the system instrumentation 325, the ACE 330, etc. For
example, the access environment control 330 may assess that the
laptop is physically inside of the secured corporate network and
the user may therefore be allowed to view any document while in
that state. But, if the laptop is now connected to a coffee shop's
Wi-Fi, access to the files may be completely restricted.
[0098] By way of further example, in normal mode, the laptop may
connect to the coffee shop's Wi-Fi and allow a VPN. But when a
protected file is resident on it, the laptop adopts the policy of
that file and may indicate to the user, "VPN is no longer an
option. This laptop may only communicate to the networks of
Corporation D campus while this data is resident."
[0099] It should be noted that a significant benefit to this system
is the implementation. Because the security follows the file, the
device matches the appropriate level if the file is present. Thus,
government agencies and corporations need not work about how large
numbers of devices are configured and where data is going, and on
which devices. Using aspects disclosed herein, if the data appears
on a system, that system configures itself to the desired policy
level
[0100] Additional functionality and interoperation of the
above-listed components in FIG. 3 is provided in the following
example method embodiments.
C. Method Embodiments
[0101] Embodiments of the present invention comprise
computer-implemented methods for protecting a data file no matter
where it resides or travels. In embodiments, the protection may be
accomplished, at least in part, by generating a protected data file
that includes the data file in an encrypted format and metadata,
which comprises information regarding one or more policies/rules
related to situational conditions under which access to the data
file may be granted. To access the data file within the protected
data file, situational factors as set in the policies must be met.
For example, who, what, where, when, and how questions (which
individually or collectively) may be formed into one or more
policies and must be satisfied in order to access the native
data.
[0102] In embodiments, given a protected data file,
computer-implemented methods for accessing content of a protected
file on a computing device may comprise several steps. For example,
when an access request (e.g., to read, to write, or both) is made
by a user of a computing device, the computing device may obtain
from a memory one or more policies related to contextual conditions
under which access to a user-accessible format of the content of
the encrypted payload may be granted. The policies may be embedded
in the metadata of the protected file or may only be securely
associated with the protected file and obtained from a data store.
In embodiments, the one or more policies related to the context or
situations under which access rights may be granted. Accordingly,
the user's computing system obtains the relevant contextual data.
The computing system applies the collected contextual data to the
one or more policies to identify what access level or levels are
appropriate in that setting. In embodiments, a mitigation access
level or levels may be allows (e.g., decrypting the data on the
user's system may not be allowed, but the user may be allowed to
securely access the content via a VPN to a secure server).
[0103] In embodiments, the situational or contextual data may
involve collecting, by way of example, clock data, location data,
BIOS data, operating system data, file system data, network data,
connectivity data, security features data, user data,
authentication data, user privileges data, software data of the
computing device, and hardware data of the computing device.
[0104] In embodiments, the protected data file may be or have
nested levels of encryption and/or metadata, and may undergo
iterations of application of policies/rules to determine access
rights.
[0105] FIG. 4 depicts a general phases of the Secure Data Access
System (SDAS) according to embodiments of the present invention.
These are examples of phases the system may undergo when, for
example, a user wishes to collaborate with a colleague who sent a
protected document. As shown in FIG. 4, the four main phases are:
(1) initialization (405); (2) preprocessing (410); (3) processing
(415); and (4) finalizing (420). Embodiments of each of these
phases are described in more detail below.
[0106] 1. Phase 1--Initialize
[0107] FIG. 5 depicts the initialization phase according to
embodiments of the present invention. In the embodiment depicted in
FIG. 5, the method commences with the user receiving (505) a
protected file (e.g., file_name.sdf) such as via email and saves it
to a local folder. In embodiments, the user selects (510) the file
for opening. For example, the user may use Windows.RTM. File
Explorer to open the file's location and select or click on the
file to request that it be opened. The operating system has
associated .SDF files with the SDAS application; therefore, it
launches the SDAS application and supplies file_name.sdf as a
parameter to the application. In embodiments, upon launch, the SDAS
application initializes (515); embodiments of the application
initialization are depicted in FIG. 6.
[0108] FIG. 6 depicts SDAS application initialization according to
embodiments of the present invention. In the embodiment depicted in
FIG. 6, the process commences with the Authentication/Authorization
Security Component (AASC) 335 authenticating (610) the user.
Authentication and authorization methods are well-known in the art
and any such methods may be used. In embodiments, the SDAS
processor 315 loads previously cached policies, settings, and
security materials (e.g., key ring from cache). In embodiment, this
information may be loaded from the ACE module 320, the policy/rules
360 (which may receive updates from the SDAS management server
375), or a combination thereof.
[0109] In embodiments, the Secure Data Access System (SDAS)
processor 315 performs (615) a shallow scan of the file (e.g.,
file_name.sdf) to create a trial document table of contents (TOC)
and metadata map. In embodiments, included in the TOC and metadata
map may be environmental context like who (user identity), what
(device context), when (time), and where (geo location). Also, in
embodiments, the Secure Data Format Processor (SDFP) 315 along with
the Security Services Component (SSC) 335 verify document
integrity, such as by using checksums. Finally, as depicted, the
SDAS application assesses the user access request (e.g., in this
case, to open contents for reading and potentially editing).
[0110] 2. Phase 2--Preprocessing
[0111] FIG. 7 depicts a preprocessing phase according to
embodiments of the present invention. In embodiments, the SDAS
application collects (705) pertinent information for forming the
rules to be applied for access. For example, in embodiments, the
SDAS application may select related policies already on device that
were obtained during initialization. Alternatively or additionally,
in embodiments, the SDAS application may ask the SDAS management
server 375, via the policy/rules component 360, for any policy
updates since last check-in. In embodiments, the rules specified in
the metadata within the file (e.g., file_name.sdf) may also be
included.
[0112] In embodiments, the SDAS application collects (710)
environmental data as indicated by rules to be enforced. Potential
contextual/environmental data includes: clock information, location
via GPS or wireless information, BIOS data, operating system (OS)
data, file system information, network information, etc. In
embodiments, this information may be obtained by the system
instrumentation component 325, from instrumentation services like
Dell Data Vault (DDV) or Windows Management Instrumentation (WMI),
or a combination thereof. In embodiments, the environmental data
may also include items related to the user potential identity,
LDAP/AD attributes, attestations, privileges level, and the like.
In embodiments, the AuthN/Z security component 355 may help supply
some of this information.
[0113] Returning to FIG. 7, in embodiments, the SDAS application
configures the SDF processor 315 in preparation of
decoding/transforming by specifying metadata to one or more
Extensible Content Transformation (ECTs). In embodiments, if one or
more particular ECTs that are to be used in decoding/transforming
the file as specifying in metadata are not present in the SDAS, the
system can download, install, and configure them from a server via
one or more server interfaces.
[0114] In embodiments, the SDAS application also configures (720)
the Security Services Component (SSC) 335. For example, in
embodiments, based on the metadata associated with the file, scan
key IDs are searched in a local key ring. Responsive to the keys
not being found, the system 310 may ask a server 375 for the
appropriate key(s) and store on key ring and/or save to a
cache.
[0115] 3. Phase 3--Processing
[0116] FIG. 8 depicts processing phase according to embodiments of
the present invention. In embodiments, the SDAS application
assembles one or more audit messages, which messages may include a
summary at this point in the process and reports impending access
to the file. In embodiments, the system 310 sends one or more of
the audit messages, via the Audit Services component 345, to the
intelligence management server 370. It shall be noted that the
audit messages may serve a number of functions, including
maintaining an audit trail and allowing intelligence management
system, the SDAS management server, or both to intervene before the
file is opened.
[0117] In embodiments, responsive to the complying with the
applicable rules/policies (e.g., correct user authentication,
proper environmental factors, etc.), the SDAS application instructs
(810) the SDF Processor (SDFP) 315 to begin decoding/transforming
the protected content of the file (e.g., file_name.sdf) into a
user-accessible form. It shall be noted that the intermediate
results are handled securely so there is no opportunity for leakage
to occur until finalization approves it. In embodiments,
intermediate results relate to a process whereby the SDAS verifies
accessibility prior to access. In embodiments, in order to verify
accessibility, the system opens portions of the document to render
a result, and it is in this situation that, in order to render
results, the intermediate results are handled security so that no
leakage or man-in-the middle attacks may be accomplished. In
embodiments, the SDF Processor 315 streams or filters the encoded
payload to the appropriate ECT Processor or Processors 340 for the
decoding/transforming, the results of which are returned to the SDF
Processor 315. In embodiments, if the results are encoded, then the
process is repeated until final, untransformed results are
achieved.
[0118] It should be noted that embodiments of the present invention
may include nested layers of security for a file. In embodiments,
the ECT Processor decoding may return additional metadata and
rules. In such cases, the SDF Processor 315 adds those new
policies/rules to the previously configured working policies/rules
set for use in subsequent process and enforcement. In embodiments,
if needed, the SDAS application will make additional requests for
data, such as instrumentation reading for newly realized
environmental constraints.
[0119] 4. Phase 4--Finalize (Enforcement, Result)
[0120] FIG. 9 depicts finalization phase according to embodiments
of the present invention. In embodiments, the SDAS application
applies currently accumulated rules set to the accumulated
environmental measurements. For example, the policy questions, such
as (by way of example only): who is trying to access the file?,
what are they trying to access?, when?, on what computing system
are they trying to access the file?, where is the computing system
and file currently located?, how are they trying to access or use
the file?, etc., are answered (905) and tested for compliance with
the gathered data.
[0121] The outcome of this determination is then applied (910) as
the result. In embodiments, if access is allowed, a usable version
of the file contents are delivered to the requestor 380, or a
representation of the data content may be delivered, based on the
access allowance determination. In embodiments, mitigations and/or
remediation may be applied. For example, depending upon the
gathered data conditions and policies, the system may delete some
or all of the date, wipe some or all of the data from the system,
execute a kill-pill, containerize the data, sandbox the application
and data, require the data to be securely accessed via an virtual
private network (VPN), etc.
[0122] In embodiments, intermediate work cleanup is performed and
the data is secured. In embodiments, intermediate work may be
defined as any set of resultant policies that may overlap and
therefore need to be referred to the SDAS management server 375 for
execution of prioritized mitigation.
[0123] Finally, in embodiments, the SDAS application assembles one
or more audit message with summary of results that may be
transmitted to the intelligence management server 370 for logging
and other purposes.
D. Exemplary Systems Embodiments
[0124] Aspects of the present patent document are directed to
information handling systems. For purposes of this disclosure, an
information handling system may include any instrumentality or
aggregate of instrumentalities operable to compute, calculate,
determine, classify, process, transmit, receive, retrieve,
originate, route, switch, store, display, communicate, manifest,
detect, record, reproduce, handle, or utilize any form of
information, intelligence, or data for business, scientific,
control, or other purposes. For example, an information handling
system may be a personal computer (e.g., desktop or laptop), tablet
computer, mobile device (e.g., personal digital assistant (PDA) or
smart phone), server (e.g., blade server or rack server), a network
storage device, or any other suitable device and may vary in size,
shape, performance, functionality, and price. The information
handling system may include random access memory (RAM), one or more
processing resources such as a central processing unit (CPU) or
hardware or software control logic, ROM, and/or other types of
nonvolatile memory. Additional components of the information
handling system may include one or more disk drives, one or more
network ports for communicating with external devices as well as
various input and output (I/O) devices, such as a keyboard, a
mouse, touchscreen and/or a video display. The information handling
system may also include one or more buses operable to transmit
communications between the various hardware components.
[0125] FIG. 11 depicts a block diagram of an information handling
system 1100 according to embodiments of the present invention. It
will be understood that the functionalities shown for system 1100
may operate to support various embodiments of an information
handling system--although it shall be understood that an
information handling system may be differently configured and
include different components. As illustrated in FIG. 11, system
1100 includes a central processing unit (CPU) 1101 that provides
computing resources and controls the computer. CPU 1101 may be
implemented with a microprocessor or the like, and may also include
a graphics processor and/or a floating point coprocessor for
mathematical computations. System 1100 may also include a system
memory 1102, which may be in the form of random-access memory (RAM)
and read-only memory (ROM).
[0126] A number of controllers and peripheral devices may also be
provided, as shown in FIG. 11. An input controller 1103 represents
an interface to various input device(s) 1104, such as a keyboard,
mouse, or stylus. There may also be a scanner controller 1105,
which communicates with a scanner 1106. System 1100 may also
include a storage controller 1107 for interfacing with one or more
storage devices 1108 each of which includes a storage medium such
as magnetic tape or disk, or an optical medium that might be used
to record programs of instructions for operating systems, utilities
and applications which may include embodiments of programs that
implement various aspects of the present invention. Storage
device(s) 1108 may also be used to store processed data or data to
be processed in accordance with the invention. System 1100 may also
include a display controller 1109 for providing an interface to a
display device 1111, which may be a cathode ray tube (CRT), a thin
film transistor (TFT) display, or other type of display. The
computing system 1100 may also include a printer controller 1112
for communicating with a printer 1113. A communications controller
1114 may interface with one or more communication devices 1115,
which enables system 1100 to connect to remote devices through any
of a variety of networks including the Internet, an Ethernet cloud,
an FCoE/DCB cloud, a local area network (LAN), a wide area network
(WAN), a storage area network (SAN) or through any suitable
electromagnetic carrier signals including infrared signals.
[0127] In the illustrated system, all major system components may
connect to a bus 1116, which may represent more than one physical
bus. However, various system components may or may not be in
physical proximity to one another. For example, input data and/or
output data may be remotely transmitted from one physical location
to another. In addition, programs that implement various aspects of
this invention may be accessed from a remote location (e.g., a
server) over a network. Such data and/or programs may be conveyed
through any of a variety of machine-readable medium including, but
are not limited to: magnetic media such as hard disks, floppy
disks, and magnetic tape; optical media such as CD-ROMs and
holographic devices; magneto-optical media; and hardware devices
that are specially configured to store or to store and execute
program code, such as application specific integrated circuits
(ASICs), programmable logic devices (PLDs), flash memory devices,
and ROM and RAM devices.
[0128] Embodiments of the present invention may be encoded upon one
or more non-transitory computer-readable media with instructions
for one or more processors or processing units to cause steps to be
performed. It shall be noted that the one or more non-transitory
computer-readable media shall include volatile and non-volatile
memory. It shall be noted that alternative implementations are
possible, including a hardware implementation or a
software/hardware implementation. Hardware-implemented functions
may be realized using ASIC(s), programmable arrays, digital signal
processing circuitry, or the like. Accordingly, the "means" terms
in any claims are intended to cover both software and hardware
implementations. Similarly, the term "computer-readable medium or
media" as used herein includes software and/or hardware having a
program of instructions embodied thereon, or a combination thereof.
With these implementation alternatives in mind, it is to be
understood that the figures and accompanying description provide
the functional information one skilled in the art would require to
write program code (i.e., software) and/or to fabricate circuits
(i.e., hardware) to perform the processing required.
[0129] It shall be noted that embodiments of the present invention
may further relate to computer products with a non-transitory,
tangible computer-readable medium that have computer code thereon
for performing various computer-implemented operations. The media
and computer code may be those specially designed and constructed
for the purposes of the present invention, or they may be of the
kind known or available to those having skill in the relevant arts.
Examples of tangible computer-readable media include, but are not
limited to: magnetic media such as hard disks, floppy disks, and
magnetic tape; optical media such as CD-ROMs and holographic
devices; magneto-optical media; and hardware devices that are
specially configured to store or to store and execute program code,
such as application specific integrated circuits (ASICs),
programmable logic devices (PLDs), flash memory devices, and ROM
and RAM devices. Examples of computer code include machine code,
such as produced by a compiler, and files containing higher level
code that are executed by a computer using an interpreter.
Embodiments of the present invention may be implemented in whole or
in part as machine-executable instructions that may be in program
modules that are executed by a processing device. Examples of
program modules include libraries, programs, routines, objects,
components, and data structures. In distributed computing
environments, program modules may be physically located in settings
that are local, remote, or both.
[0130] One skilled in the art will recognize no computing system or
programming language is critical to the practice of the present
invention. One skilled in the art will also recognize that a number
of the elements described above may be physically and/or
functionally separated into sub-modules or combined together.
[0131] It will be appreciated to those skilled in the art that the
preceding examples and embodiment are exemplary and not limiting to
the scope of the present invention. It is intended that all
permutations, enhancements, equivalents, combinations, and
improvements thereto that are apparent to those skilled in the art
upon a reading of the specification and a study of the drawings are
included within the true spirit and scope of the present
invention.
* * * * *