Organizations are facing increasing risks and threats from various causes, including, for example, fraud, unauthorized access to systems, and insider threats. Current organizational attempts to identify and eliminate these risks/threats are ineffective and/or are difficult to understand and implement. There is no current way to document, communicate and implement how controls are managed across the organization.
Thus, there is a need for a transparent (i.e. easy to understand) and actionable risk/reward approach for organizational processes, controls, training and development.
In accordance with an aspect of the present invention, embodiments of the present invention are directed to methods, systems and computer program products for a control transparency framework in order to control and manage risks or threats. The method for a control transparency framework includes identifying threats to an organization, developing a risk score for each of the threats to develop a threat portfolio, developing a maturity portfolio, developing a control portfolio, determining a gap portfolio, and developing a control transparency portfolio to close gaps. A gap exists between a target state maturity level of each identified threat and a current maturity level of each control assigned to handle each identified threat, such that the gap occurs if the target state maturity level is at a level that is lower than the control's current maturity level.
Other aspects and features of the present invention, as defined solely by the claims, will become apparent to those ordinarily skilled in the art upon review of the following non-limited detailed description of the invention in conjunction with the accompanying figures.
Embodiments of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and/or combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block(s).
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block(s). Alternatively, computer program implemented steps or acts may be combined with operator or human implemented steps or acts in order to carry out an embodiment of the invention.
Embodiments of the present invention are directed to methods, systems, computer program products and the like that provide for a transparent and actionable risk/reward approach to communicate how controls and/or risks are managed across an organization. The embodiments are directed to a “right-sized” control portfolio that determines a span and maturity of controls based on the current risk threat landscape. These embodiments provide transparency into the controls environment, proactively manage controls environment, and create a measurement system that reflects how well the controls are working.
The following detailed description refers to the accompanying drawings which illustrate specific embodiments in accordance to the present the invention. Other embodiments having different structures and operations do not depart from the scope of the present invention.
In order to demonstrate transparency (i.e. ease of understanding) in the controls, six deliverables are developed, including a threat portfolio 128, maturity portfolio 138, vulnerability management (VM) control strategy 122, control portfolio 142, gap portfolio 150 and control transparency portfolio 162. The activities for developing the threat portfolio 128 are undertaken by the Threat Management and Innovation sector 102. The activities for developing the maturity portfolio 138, vulnerability management (VM) control strategy 122, control portfolio 142, gap portfolio 150 and control transparency portfolio 162 are undertaken by the Cyber Security Control Engineering & Reporting (CSCER) sector 110. Each of the activities and roles/responsibilities are discussed below with reference to
In block 120, a VM control strategy is developed to establish a common control strategy. The VM control strategy provides a basis for all control decisions as each sector or group moves forward in the future. The VM control strategy not only provides a foundation but also a vision for each organizational sector and group. The strategy describes how controls will be applied throughout the organization, the priority the organization assigns to each identified risk, and what level of controls will be assigned to which risks. For example, the VM control strategy may indicate that a high risk threat will be controlled by a highly mature control. Resulting from the VM control strategy is the VM control strategy deliverable, shown in block 122. This deliverable 122 may be a report, spreadsheet, database, or any other type of strategy or plan.
In block 124, a threat list is established. Because many organizations are threat-based, the foundation of the control framework is also threat based. However, the foundation of the control framework may be based on one or more factors in addition to threat-based factors, such as risk/reward based factors, action plan based factors and other factors related to implementing a plan in an organization. Regardless, the threat portfolio, shown in block 128, provides structure and reason around placement of controls. For assessment purposes, the Threat Management and Innovation sector 102 is responsible for providing an updated threat list periodically after a predetermined time period, such as every financial quarter. An example of the threat list excerpt 200 is shown in
In block 126, the risks/threats 204 are rated and ranked. As shown in
As illustrated in
Referring back to
In block 130, current and new controls and supporting processes are determined. All current controls must be identified within each sector and each supporting function, including Threat Management & Innovation 102, Enterprise Security Assessment 104, Security Monitoring & Containment 106, Insider Threat 108, and Cyber Security Control Engineering & Reporting 110.
In one embodiment, a control is any administrative, management, technical, or legal method that is used to manage risk. Controls are safeguards or countermeasures and include practices, policies, procedures, programs, techniques, technologies, guidelines, organizational structures and/or other approaches or strategies to manage risk.
In block 132, control metrics are established by all organizational sectors or groups, including Threat Management & Innovation 102, Enterprise Security Assessment 104, Security Monitoring & Containment 106, Insider Threat 108, and Cyber Security Control Engineering & Reporting 110. Each mitigating control includes a set of reporting metrics. Once the control metrics accomplish control transparency and development of a risk profile, the control metrics drive organizational change. The control metrics are established using a Hoshin model which shows what amount or percentage of each control has a defined control target in the control transparency model. The goal of the Hoshin model is to be at 100% so that each target is addressed and controlled. The Hoshin model is met by utilizing the reporting triad model 300 (
Once processes 312 are identified and metrics 314 are determined, the processes 312 are then to be documented (both with process map and process document) with appropriate control points in an appropriate repository, as is described below with regard to block 134. If documentation has already been completed, the documentation phase can be skipped and the process will go under review.
Referring to block 134 of
To begin the process modeling, process maps are first created for all core business processes. Software is used to create these process maps and is used as a central, enterprise repository for the process maps and related process data elements. The software is web browser based and utilizes shapes, data and model types via a graphical user interface (GUI).
While there are a variety of process maps that may be available, the creation of three basic levels of process maps will be sufficient for most organizational sectors, including overall process maps, high-level maps, and mid-level process maps. These process maps are illustrated in the diagram 400 of
As previously mentioned, in block 134, the control points of the organization are identified. A control point is any point in the process that is designed to provide reasonable assurance regarding the achievement of objectives including the effectiveness and efficiency of operations, reliability of financial reporting, compliance with applicable laws and regulations and safeguarding of assets. A control point should be designed to mitigate risk and provide reasonable assurance that associates, management or other organizational employees will prevent or detect a “failure” from occurring. A “failure” results when a risk is not properly controlled such that a threat becomes reality and the organization is impacted. Control points are necessary to ensure that processes are running efficiently and will serve as a type of “engine warning light” to alert the organization to possible issues. Control points can be actions taken to ensure that what the organization desires to occur will occur in response to predetermined triggers.
In the initial stages of process modeling, current control points are identified to determine what controls points exist. As the methodology progresses, gaps in the controls are determined and identified, as will be discussed later in this disclosure. Objectives of the control points include accomplishing goals and objectives of the organization, achieving reliability and integrity of information, realizing economical and efficient use of resources, and safeguarding of assets. Failure of one or more control points may result in inconsistent objectives, lack of organizational integrity, weak control environment, inability to understand and react to changing conditions, and poor communication.
The control points have various classifications that should be adhered to in order to sufficiently document the control points. For example, one or more control points may be classified as preventative and/or detective. The control points may also be classified as automated or manual. Tiers may also be used to create an additional classification to relate the control points to associated metrics and/or to show their relationship to the overall process. It should be understood that these classifications are not mandatory, but, instead, are merely a consideration in case that an additional metric detail is needed.
In block 136, the organization, such as the Cyber Security Control Engineering & Reporting sector 110, performs two maturity assessments (i.e. process maturity assessment and organizational maturity assessment) as a part of the control transparency framework process 100. These assessments allow an understanding of the level of maturity and capability with each process and organization. First, the process maturity is established based on common criteria across the organization. The organization uses one or more maturity models to determine the processes maturity. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization. The maturity model may provide, for example, a place to start the assessment, the benefit of prior experiences, a common language and a shared vision, a framework for prioritizing actions, and a way to define what improvement means for your organization. The maturity model can be used as a benchmark for comparison and as an aid to understanding, for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of a Capability Maturity Model (CMM), for example, the basis for comparison would be the organization's software development processes.
In one embodiment, a blend of two maturity models is employed, including a Control Objective for Information and related Technology (COBIT) Maturity Model and the Capability Maturity Model (CMM). COBIT is a framework of best practices for IT management. COBIT is the general framework used in the IT industry. The COBIT mission is to research, develop, publicize and promote an authoritative, up-to-date, international set of generally accepted information technology control objectives for day-to-day use by business managers and auditors. There are various advantages to using COBIT. First, COBIT provides best practices for the management of IT processes in a manageable and logical structure. Second, COBIT is an internationally accepted set of guidance materials for IT governance.
COBIT consists of various control objectives over multiple domains. In one embodiment, the domains include: 1) Plan and Organize (PO), 2) Acquire and Implement (AI), 3) Deliver and Support (DS) and 4) Monitor and Evaluate (ME). The PO domain provides direction to solution delivery (AI) and service delivery (DS). The AI domain provides solutions and transfers these solutions so that they may be turned into services. The DS domain receives the solutions and makes them usable for end users. The ME domain monitors all processes to ensure that the direction provided is followed.
Because COBIT is a framework, associations between control points and each respective COBIT control objective should be created by the organization representative or other persons. When mapping to the COBIT framework, the COBIT domain is first identified based on the functional description of the control points. Next, the control objectives that most closely match the identified control points are drilled down and the point of correlation is marked. Multiple correlations may exist between a single control point and multiple control objectives.
As previously mentioned, CMM may also be employed in determining the maturity assessments. CMM is a process capability maturity model which aids in the definition and understanding of an organization's processes and the organizational maturity in diverse areas, such as, for example, software engineering, system engineering, project management, software maintenance, risk management, system acquisition, information technology (IT), and personnel management.
Both COBIT and CMM are used to determine the two maturity components—the organization's process maturity and the organizational maturity. The organizational maturity is established through a series of interviews and reviewing a sample of the process documentation. The interviews consist of questions around awareness and communication, processes and procedures, tools and automation, skills and expertise, responsibility and accountability, and goals and metrics. In addition to COBIT and CMM, it should be understood that other maturity models may also be employed, such as EOP or SSE-CMM.
As shown in the illustrated embodiment of
The CMM model (not shown) also has levels to indicate the control maturity. The levels range from 0-5. Level 0 indicates that no process is in place. Level 1 indicates that the base practices are being performed, but they are only being “performed informally.” Level 1 focuses on whether an organization or project performs a process that incorporates the base practices and thus level 1 can be characterized by the statement, “you have to do it before you can manage it.” For level 2, the processes are “planned and tracked.” Level 2 focuses on project-level definition, planning, and performance issues and thus, can be characterized by the statement, “let's understand what's happening on the project before defining organization-wide processes.” In Level 3, the processes are “well defined,” which focuses on disciplined tailoring of the defined processes at the organization level. This level can be characterized by the statement, “use the best of what you've learned from your projects to create organization-wide processes.” Level 4 indicates that processes are “quantitatively controlled,” which focuses on measurements being tied to the business goals of the organization. Although it is essential to begin collecting and using basic project measures early, measurement and use of data is not expected organization-wide until the higher levels have been achieved. This level can be characterized by the statements, “you can't measure it until you know what ‘it’ is” and “managing with measurement is only meaningful when you're measuring the right things.” Level 5 indicates that the processes are “continuously improving.” Level 5 gains leverage from all the management practice improvements seen in the earlier levels, and then emphasizes the cultural shifts which, if implemented, will sustain the gains made. This level can be characterized by the statement, “a culture of continuous improvement requires a foundation of sound management practice, defined processes, and measurable goals.”
In block 138, the maturity portfolio is created. The maturity portfolio provides transparency for all controls and includes all processes that support each of the controls.
After the maturity portfolio is developed, controls 506 are mapped to the risks/threats, as represented in block 140. This mapping creates a control portfolio, as represented in block 142. For example, the control portfolio 142 is created by mapping the risk score values 212 of each risk/threat 204 from the threat portfolio 230 (
Once the control portfolio 520 is completed, the control strategy is applied via a strategy mapping, as represented in block 144. The control strategy is determined by the organization. In other words, the organization will determine which blocks in the 9-block NIST model will have the highest, middle, and lowest level of control. For example, in the illustrative embodiment 600 of
After the strategy mapping is achieved represented by block 144 of
Also in block 146, the current level of the control maturity is determined. For example, by applying a value of 1, 3, 9 for low, medium and high, respectively, based on the NIST 9-Block 700 in
After achieving the total threat score 712 of a control 710, the total threat score 712 is compare to threshold values for the COBIT/CMM models. In one embodiment, the threshold values are determined based on all of the selected threats. For example, if the sum 712 of all of the selected threats' values 704 equals 190, then the threshold value for the “managed” level will be 190. In this instance, since the control total score 712 was calculated above to be equal to 210, this would exceed the 190 threshold value and thus, the current maturity level of the “supplier assessment” control 710 is determined to be at “managed.” The other level thresholds may also be determined in a similar fashion. For example, the threshold level of “defined” and “repeatable” is set at, for example, 90 such that if the total threat score 712 of the control 710 is less than 90, then the current maturity level is “repeatable.” However, if the total threat score 712 of the control 710 is greater than 90, then the current maturity level is determined to be “defined.”
In addition to the target maturity, in block 146, the second layer of control that will be analyzed is the span of control. Analyzing the span of control allows for the organization to determine when additional controls are needed rather than a more mature control or process. In the exemplary chart 800 shown in
After the initial modeling is complete, it is necessary to conduct an assessment of all related systems, policies, procedures and practices and accompanying it with a security risk analysis. While performing this assessment, it is important to review key business processes, workflow, and data flow, giving special attention to use, storage and transmission of data. Gaps due to low maturity must be identified in order to reach the target maturity for each process, as represented in block 148. Also, after a current span of control and target span of control is established, gaps need to be documented in order for planning to move forward to close the gaps and reach the desired target state.
The organization should identify gaps between the organization's current policies, procedures, systems and applications in all facilities in order to minimize any disruptions to your services, financial penalties and audit issues. This is done in contrast to many organizations which might wait for gaps to be identified for them by external third parties, audits or regulatory agencies. In order to ensure ongoing process stability, one should look at future business trends in order to anticipate changes in both internal and external factors that may be relevant to the organization's product/service stream. Such factors include future business demands (new products/services, acquisitions, etc), resource capacity and training, regulatory assessment, data flow and integrity evaluation, information latency evaluation, communication gaps, and reaffirming key performance indicators.
As can be readily seen in
After potential process gaps have been identified, work can begin towards making improvements to the overall process and begin brainstorming the best solutions to fill these gaps (both non-existent gaps and maturity gaps). Further, after process gaps and inefficiencies have been identified, a control accelerator (described below with respect to
As represented in block 150, the gap portfolio is created by comparing the current state of the control portfolio with the target levels. An example of the gap portfolio 1000 is illustrated in
In block 152, after data is gathered, each organizational sector or group evaluates and prioritizes the gaps based on related threats and overall control level and resources available within the team. Once the evaluation and prioritization is complete, any organizational risk needs to be escalated to a governing body in the organization in order to manage risk appropriately within the organization.
In block 154, the risks are managed by the organization. The risk management process is utilized to establish transparency with senior management. As previously mentioned, the risks are escalated to an organizational governing body. The governing body consists of the company executives, such as managers, CIO, and other executives, as well as the risk management sector which determines and manages risks for the organization. The organizational governing body makes the decisions to accept, avoid, mitigate, or transfer the risks based on a case-by-case basis. In assisting in making these decisions, the gap portfolio is used to provide the gap information as well as the risks posed. In other embodiments, one or more of the other portfolios (e.g. threat portfolio, control portfolio, maturity portfolio, etc.) are used in the decision-making process.
If the decision is to accept the risk, the governing body accepts the possibility of consequences in the event that the risk becomes reality. The acceptance by the governing body is be documented and signed by governing body at the time of the decision. An example of when a governing body may accept the risk is if the costs of managing the risk exceed the reward or advantages of management of the risk.
If the decision is to avoid/eliminate the risk, the governing body may discontinue the technical or business activities associated with a particular risk. For example, the governing body may eliminate a particular operating system which may present risks through its use. By eliminating the operating system, any associated risks are avoided.
If the decision is to mitigate the risk, the governing body may seek to reduce the magnitude of a potential risk consequence or to reduce the likelihood of the consequence arising, by, for example, reducing casual threats or eliminating vulnerabilities. To mitigate the risk, business approval from the governing body, for example, needs to be acquired.
If the decision is to transfer the risk, the governing body assigns the line of business or sector responsible for taking responsibility for at least some of the consequences associated with a particular risk. In this case, the governing body may indemnify or compensate the line of business for any resulting consequences of a particular risk.
In any event, based on the decision of the governing body, each team is responsible for taking the appropriate action to close the identified gaps. In decision block 156, a determination is made as to whether funding is required to close a particular gap. If so, a business case is developed, as is described in more detailed with regard to block 160. On the other hand, in block 158, if no funding is required and approval is granted, the sector of the organization which is responsible for the control implements actions and/or controls to close the gaps.
If needed, each team can utilize the control accelerator, as previously mentioned, in order to establish an adequate level of control for the organization. The control accelerator is a defined process with tools & templates that drive clarity on how to move from little or no control to detective/preventative controls. As illustrated in
In block 160, a business case is developed to justify the need for additional controls or modifications to existing products and/or services. New business case initiatives are created to either meet the changing demands of a particular business process or to address possible deficiencies or gaps. Business case development supports key organizational considerations in making a decision for pursuing a new opportunity or approach. As a communications vehicle, the business case identifies goals and measures for tracking the move to the final end state. Business case development typically examines five areas of organizational planning to make their case statements: 1) deciding goals and actions, including developing alternative approaches; 2) estimating the likely costs and developing potential risks; 3) estimating the likely benefits; 4) developing a proposal for proceeding; and 5) closing the deal, including making final adjustments and proceeding to development.
In block 162, the control transparency portfolio incorporates people, sectors/groups, processes and technology to have an established risk profile for all gaps as well as current controls.
Figure block schematic of an example of a system 1300 for the control transparency framework in accordance with an embodiment of the present invention. The system 1300 may include a module for control transparency framework (hereinafter “control transparency framework module”) 1302 operable on a computer system 1304, or similar device of a user 1306 or client. Alternatively, or in addition to the control transparency framework module 1302 on the user's computer system 1304 or client, the system 1300 may include a control transparency framework module 1308 operable on a server 1310 (hereinafter “server control transparency framework module”) and accessible by the user 1306 or client 1304 via a network 1312. The methods 100, 900 and 1100 may be embodied in or performed by the control transparency framework module 1302 and/or the server control transparency framework module 1308. For example, the methods 100, 900 and 1100 may be performed by the control transparency framework module 1302. In another embodiment of the invention, the methods 100, 900 and 1100 may be performed by the server control transparency framework module 1308. In a further embodiment of the present invention, some of the features or functions of the methods and systems 100, 900 and 1100 may be performed by the control transparency framework module 1302 on the user's computer system 1304 and other features or functions of the methods 100, 400, 500, and 600 may be performed on the server control transparency framework module 1308.
The network 1312 may be the Internet, a private network or other network. Each computer system 1304′ may be similar to the exemplary computer system 1304 and associated components illustrated in
The control transparency framework module 1302 and/or 1308 may be a self contained system with embedded logic, decision making, state based operations and other functions. The self contained system may allow businesses, individuals, services, locations, and the like to obtain data and/or information related to controls, risks/threats, strategies and the like.
The control transparency framework module 1302 may be stored on a file system 1316 or memory of the computer system 1304. The control transparency framework module 1302 may be accessed from the file system 1316 and run on a processor 1318 associated with the computer system 1304.
The user computer system 1304 may also include a display 1330 and a speaker 1332 or speaker system. The display 1330 may present information related to the control transparency framework system 1300, such reports, portfolios, and the like, as described herein, and may permit input of data and information into the system 1300. Any GUIs (not shown) associated with the control transparency framework module 1308 may also be presented on the display 1330. The speaker 1332 may present any voice or other auditory signals or information to the user 1306.
The user computer system 1304 may also include one or more input devices, output devices or combination input and output device, collectively I/O devices 1334. The I/O devices 1334 may include a keyboard, computer pointing device or similar means to control operation of the control transparency framework processes 100 and system 1300, as described herein. The I/O devices 1334 may also include disk drives or devices for reading computer media including computer-readable or computer-operable instructions.
The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention, unless the context clearly indicates otherwise. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations and modifications of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein
Number | Name | Date | Kind |
---|---|---|---|
20020018269 | Chaudhuri et al. | Feb 2002 | A1 |
20020030864 | Chaudhuri et al. | Mar 2002 | A1 |
20020109879 | Wing So | Aug 2002 | A1 |
20030018513 | Hoffman et al. | Jan 2003 | A1 |
20030028412 | Hoffman et al. | Feb 2003 | A1 |
20030040986 | Hoffman et al. | Feb 2003 | A1 |
20030041001 | Hoffman et al. | Feb 2003 | A1 |
20030046089 | Menninger et al. | Mar 2003 | A1 |
20030046120 | Hoffman et al. | Mar 2003 | A1 |
20030046121 | Menninger et al. | Mar 2003 | A1 |
20030046136 | Hoffman et al. | Mar 2003 | A1 |
20030046190 | Hoffman et al. | Mar 2003 | A1 |
20030046214 | Menninger | Mar 2003 | A1 |
20030048301 | Menninger | Mar 2003 | A1 |
20030050807 | Hoffman et al. | Mar 2003 | A1 |
20030050808 | Mor | Mar 2003 | A1 |
20030050809 | Hoffman et al. | Mar 2003 | A1 |
20030050822 | Hoffman et al. | Mar 2003 | A1 |
20030050823 | Gehman et al. | Mar 2003 | A1 |
20030050828 | Hoffman et al. | Mar 2003 | A1 |
20030050845 | Hoffman et al. | Mar 2003 | A1 |
20030050859 | Rodriguez et al. | Mar 2003 | A1 |
20030050867 | Menninger et al. | Mar 2003 | A1 |
20030050868 | Hoffman et al. | Mar 2003 | A1 |
20030055692 | Menninger | Mar 2003 | A1 |
20030055693 | Hoffman et al. | Mar 2003 | A1 |
20030055694 | Menninger | Mar 2003 | A1 |
20030055700 | Hoffman et al. | Mar 2003 | A1 |
20030055704 | Reece | Mar 2003 | A1 |
20030055708 | Hoffman et al. | Mar 2003 | A1 |
20030055709 | Hoffman et al. | Mar 2003 | A1 |
20030055710 | Burk et al. | Mar 2003 | A1 |
20030055731 | Fouraker et al. | Mar 2003 | A1 |
20030055734 | Hoffman et al. | Mar 2003 | A1 |
20030055750 | Menninger | Mar 2003 | A1 |
20030061084 | Menninger | Mar 2003 | A1 |
20030061102 | Menninger et al. | Mar 2003 | A1 |
20030061124 | Menninger et al. | Mar 2003 | A1 |
20030061125 | Hoffman et al. | Mar 2003 | A1 |
20030061130 | Hoffman et al. | Mar 2003 | A1 |
20030061174 | Menninger | Mar 2003 | A1 |
20030065541 | Menninger | Apr 2003 | A1 |
20030065549 | Hoffman et al. | Apr 2003 | A1 |
20030065550 | Hoffman et al. | Apr 2003 | A1 |
20030065551 | Hoffman et al. | Apr 2003 | A1 |
20030065557 | Hoffman et al. | Apr 2003 | A1 |
20030065627 | Menninger | Apr 2003 | A1 |
20030066886 | Hoffman et al. | Apr 2003 | A1 |
20030069765 | Menninger | Apr 2003 | A1 |
20030069766 | Hoffman et al. | Apr 2003 | A1 |
20030069767 | Menninger | Apr 2003 | A1 |
20030069768 | Hoffman et al. | Apr 2003 | A1 |
20030069769 | Hoffman et al. | Apr 2003 | A1 |
20030069770 | Burk et al. | Apr 2003 | A1 |
20030069771 | Menninger et al. | Apr 2003 | A1 |
20030069774 | Hoffman et al. | Apr 2003 | A1 |
20030069778 | Menninger et al. | Apr 2003 | A1 |
20030069779 | Menninger et al. | Apr 2003 | A1 |
20030069786 | Hoffman et al. | Apr 2003 | A1 |
20030069791 | Menninger | Apr 2003 | A1 |
20030069794 | Hoffman et al. | Apr 2003 | A1 |
20030069798 | Hoffman | Apr 2003 | A1 |
20030069799 | Hoffman et al. | Apr 2003 | A1 |
20030069813 | Burk | Apr 2003 | A1 |
20030069814 | Hoffman et al. | Apr 2003 | A1 |
20030069818 | Menninger | Apr 2003 | A1 |
20030069823 | Hoffman et al. | Apr 2003 | A1 |
20030069824 | Menninger | Apr 2003 | A1 |
20030069825 | Hoffman et al. | Apr 2003 | A1 |
20030069859 | Hoffman et al. | Apr 2003 | A1 |
20030074205 | Menninger | Apr 2003 | A1 |
20030074206 | Hoffman et al. | Apr 2003 | A1 |
20030074237 | Sechrist et al. | Apr 2003 | A1 |
20030074238 | Hoffman et al. | Apr 2003 | A1 |
20030074239 | Hoffman et al. | Apr 2003 | A1 |
20030074249 | Hoffman et al. | Apr 2003 | A1 |
20030074250 | Burk | Apr 2003 | A1 |
20030074262 | Hoffman et al. | Apr 2003 | A1 |
20030074263 | Hoffman et al. | Apr 2003 | A1 |
20030074264 | Hoffman | Apr 2003 | A1 |
20030074281 | Hoffman et al. | Apr 2003 | A1 |
20030074285 | Hoffman et al. | Apr 2003 | A1 |
20030074355 | Menninger et al. | Apr 2003 | A1 |
20030078787 | Hoffman et al. | Apr 2003 | A1 |
20030078818 | Hoffman et al. | Apr 2003 | A1 |
20030078819 | Hoffman et al. | Apr 2003 | A1 |
20030078827 | Hoffman | Apr 2003 | A1 |
20030078845 | Hoffman et al. | Apr 2003 | A1 |
20030078846 | Burk et al. | Apr 2003 | A1 |
20030078860 | Hoffman et al. | Apr 2003 | A1 |
20030078861 | Hoffman et al. | Apr 2003 | A1 |
20030083909 | Hoffman et al. | May 2003 | A1 |
20030083918 | Hoffman et al. | May 2003 | A1 |
20030083947 | Hoffman et al. | May 2003 | A1 |
20030088449 | Menninger | May 2003 | A1 |
20030088474 | Hoffman et al. | May 2003 | A1 |
20030097317 | Burk et al. | May 2003 | A1 |
20040093298 | McClure, III et al. | May 2004 | A1 |
20040193482 | Hoffman et al. | Sep 2004 | A1 |
20040236621 | Eder | Nov 2004 | A1 |
20050060245 | Hoffman et al. | Mar 2005 | A1 |
20050086530 | Goddard | Apr 2005 | A1 |
20060015416 | Hoffman et al. | Jan 2006 | A1 |
20060053043 | Clarke | Mar 2006 | A1 |
20060059253 | Goodman et al. | Mar 2006 | A1 |
20060064481 | Baron et al. | Mar 2006 | A1 |
20060064485 | Baron et al. | Mar 2006 | A1 |
20060064486 | Baron et al. | Mar 2006 | A1 |
20060095915 | Clater | May 2006 | A1 |
20060161444 | Lubrecht et al. | Jul 2006 | A1 |
20060161879 | Lubrecht et al. | Jul 2006 | A1 |
20060206246 | Walker | Sep 2006 | A1 |
20070226099 | Senturk-Doganasksoy et al. | Sep 2007 | A1 |
20070288208 | Grigsby et al. | Dec 2007 | A1 |
20080047016 | Spoonamore | Feb 2008 | A1 |
20080086342 | Curry et al. | Apr 2008 | A1 |
20080208667 | Lymbery et al. | Aug 2008 | A1 |
20080221944 | Kelly et al. | Sep 2008 | A1 |
20080222734 | Redlich et al. | Sep 2008 | A1 |
20080243524 | Agrawal et al. | Oct 2008 | A1 |
20080270448 | Brennan et al. | Oct 2008 | A1 |
20090254572 | Redlich et al. | Oct 2009 | A1 |
20090265787 | Baudoin et al. | Oct 2009 | A9 |
20100010968 | Redlich et al. | Jan 2010 | A1 |