A kernel interface is a low-level communication bridge between a process and the kernel of an operating system. The kernel interface typically includes entry points where a process' execution enters the kernel and calling conventions, which control how function arguments are passed to the kernel and how return values are retrieved.
The kernel interface of a typical operating system may include functions to start and stop threads of execution, to synchronize threads of execution, to read and write data from files, to enlist in regions of shared memory, to draw on a screen, to communicate with a network, or to read a system clock. Kernel interfaces can range from dozens of entry points to hundreds and even thousands of entry points.
A kernel interface is one component of the operating system's application programming interface (API) presented to programmers. An API typically defines the interface between an application programmer's source code and operating system libraries so that the same source code will compile on any system supporting the API. Many conventional operating systems encapsulate the kernel interface within a higher-level API because the kernel interface varies from version to version of the kernel.
For example, to insulate application programmers from changes in the kernel of the Microsoft® Windows® XP brand operating system, the kernel interface of that operating system is hidden behind the Win32® API and not published. In the case of the Microsoft® Windows® XP brand operating system, programs are dynamically linked to the libraries of the Win32® API at load time.
On the other hand, a conventional kernel interface allows processor-executable instructions to function without changes on any system using the same or compatible kernel interface. From a security perspective, the processor-executable instructions of the conventional kernel interface are secure from tampering as they reside within the protection domain of the operating system kernel. On the other hand, the processor-executable instructions of the conventional high-level API may not be secure from tampering as they execute within the context of the process.
A common characteristic of conventional operating system kernel interfaces is that they use an access control pattern to decide which operations may be performed by a process through the kernel interface. With an access control pattern each “kernel object”—such as a thread, open file, or user interface windows—has an access control list that specifies which security principals are allowed to perform a specific action (or set of actions) on the kernel object. Kernel objects are abstractions provided by the kernel. Kernel objects are the things that an application affects through the kernel interface. Examples of kernel objects in the Microsoft® Windows® XP brand OS are “open files”, “windows”, “threads of execution”, “shared memory mappings”, etc.
Security principals (i.e., “security ids”) are the unit of identifying a party for security purposes. For example, on Unix, each user is a security principal with their own unique user id. Security principals are not always users. For example, the Microsoft® Windows® XP brand OS has a “network logon” principal that is used to run services that communicate over the network. As security principals typically have a one-to-one correspondence with users, each process typically has one associated security principal.
Metaphorically, an access control list is like guest list at private gathering, only processes on the list are allowed to use the kernel object. Because a running kernel may have thousands or tens of thousands of objects—such as threads, open files, and user interface windows—and dozens or hundreds of security principals, the access control lists of kernel can become unmanageable. Incorrectly set access control lists on kernel objects are a common source of security vulnerabilities in conventional operating systems.
To avoid the complexities of managing access control lists, other operating systems employ a capability pattern to control which operations may be performed by a process through the kernel interface. With a capability pattern, a “capability” represents the right to perform a specific action on a specific kernel object. The capability can be shared from one process to another to grant access to the kernel object. Metaphorically, a capability is like a key to a door, any process holding a capability can access the object that the capability unlocks. The complexities of tracking potentially hundreds of capabilities within a single process can quickly lead to security vulnerabilities in which a capability is accidentally leaked to another process. Furthermore, like a key, it is extremely difficult to get back a key once it has been lent out or lost.
Described herein are one or more implementations that separate kernel interfaces functions into those that act on kernel objects owned by a process and accessed exclusively by that process—described herein as local kernel objects—from access to kernel objects owned by a process and accessible_by other active processes—described herein as peer kernel objects. One or more implementations further prevent, by rigorous omission, the conversion of local kernel object identifiers into peer kernel object identifiers. By construction of a distinct type of identifier for local kernel objects, one or more implementations described prevent a calling process from inadvertently or maliciously directing the kernel to perform functions that alter the in-process data of peer processes.
Furthermore, with one or more implementations described, a calling process is allowed to—via a kernel interface call—to spawn a new child process, but it cannot alter the in-process data of that child process once the child is executing. The construction allows program verification tools, including compilers, to catch inadvertent or malicious attempts to alter the in-process data of another process
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The same numbers are used throughout the drawings to reference like elements and features.
The following description sets forth one or more implementations of an interface between processes and a kernel of an operating system. More specifically, the one or more implementations described are a kernel interface or some component (e.g., a process or kernel) that communicates or uses the kernel interface. More particularly, one or more implementations described restrict and separate the kernel operation a calling process may request for local kernel objects from those a process may request for peer kernel objects. By this construction, one or more implementations describe prevent a calling process from directing the kernel to perform functions—via a kernel interface call—that directly alter the state of other processes.
The following co-pending patent applications (which are commonly owned by the same assignee as this application) are incorporated herein by reference:
An operating system's security architecture often seek to guarantee that a process can access only appropriate kernel objects and that a process can execute without corruption from a second process. However, years of practical experience suggest that both access-control systems and capability systems seldom achieve these guarantees.
A kernel interface function operates on kernel objects. As expressed herein, kernel objects are divided into two categories based upon how kernel interface functions operate on them:
One reason both access control and capability systems so often fail to provide adequate security is because they allow a process to indiscriminately mix the ability to access its own “local” kernel objects with “peer” kernel objects, which are owned by peer processes. For example, as long as a process has appropriate security privileges, a conventional kernel interface does not discriminate between the process halting a local thread of execution and halting a peer thread of execution.
To understand why, consider the conventional kernel interface. The kernel interfaces exposes kernel objects through kernel-object identifiers, known variously as a handle, descriptor, port, or capability. When a process calls an entry point in the kernel interface, it provides the kernel-object identifier of the kernel object to be affected. For example, to halt a thread of execution, a process might call a TerminateThread entry point in the kernel interface giving the thread's identifier as an argument.
A drawback with conventional access-control and capability kernel interfaces is that they do not distinguish between kernel-object identifiers of local kernel objects, those owned by a process, and kernel-object identifiers of peer kernel objects, those owned by another process.
Because all local and peer identifiers are structurally identical in conventional kernel interfaces and because a process can acquire identifiers of peer objects, such as peer threads, the TerminateThread call of a conventional approach will let a process indiscriminately terminate not only local threads of executions, but those of a second process as well. Accidental or malicious misuse of identifiers is quite common in practice because the same peer identifier can often be used to synchronize with a thread of execution in a second process (a benign operation) or to halt it (a destructive operation).
The lack of discrimination between local and peer kernel object identifiers in kernel interfaces is common across all conventional operation systems. It is also pervasive within the entry points of a given kernel interface. Most conventional OSs do not distinguish between local and peer kernel-object identifiers.
However, one or more implementations, described herein, do distinguish between categories of kernel-object identifiers. In particular, it classifies them as “local” and “peer” kernel-object identifiers.
Exemplary OS Architecture
As depicted in
An OS 112 is shown stored in the memory 110 and is executed on the computer 102. OS 112 has a kernel 120. Generally, a kernel (such as kernel 120) is the central and privileged module of an OS that provides essential services required by other parts of the OS, processes, and applications. Typically, the kernel is responsible for input/output management, memory management (e.g., allocating and reclaiming memory), process and task management (e.g., creating and scheduling threads and providing intraprocess thread synchronization), and managing access to hardware resources.
In the realm of computer science and, more particularly, in the art of OSs, the term “software process” (or more simply, “process”) is well known. Execution of a program occurs within one or more processes. Operating systems typically associate memory resources, execution resources, and one or more security identities with a process. The OS is aware of and, indeed, may manage and supervise one or more separate processes running on a computer.
As depicted in
In some implementations, all kernel interfaces use the same processor-executable instructions. In other implementations, kernel interfaces use different processor-executable instructions which provide different functionality based on the version of the kernel interface definition used to build the application.
With one or more implementations, the software processes (such as 130, 140, and 150) employ inter-process communication. With this, processes communicate with each other by exchanging messages through bi-directional, strongly typed, higher-order channels. A channel is strongly typed by a computer-readable channel contract, which specifies various characteristics of the channel, including specifying permissions on the message sent across the channel. The “Inter-Process Communications Employing Bi-directional Message Conduits” (referenced above) discloses additional details regarding the inter-process communication.
In addition to the mechanism of message-passing channels, processes communicate with the kernel through the kernel interface entry points (such as 132, 142, and 152) that invokes kernel interface functions in kernel code. This interface helps isolates the kernel and process spaces. With one or more implementations, the parameters to this kernel interface are values, rather than pointers, so that kernel and processes' garbage collectors need not coordinate.
In one or more implementations, the kernel interface includes one set of functions that operate on local kernel objects, which are objects created for use solely by the process, and another set of functions that operate on peer kernel objects, which are objects create for use by the process or peer processes. One or more implementations further include execution thread objects, thread synchronization objects, or memory objects for processing heap in the set of local objects, but do not include those same objects in the set of peer objects. One or more implementations include inter-process communication objects in the set of peer objects.
At least one implementation kernel interface functions maintain a system-wide state isolation invariant between processes. A process cannot alter the state of any other process through the kernel interface. In other words, the kernel interface calls affect only the state of the calling process (in at least one implementation).
Exemplary Kernel Interface
Using the exemplary OS architecture 100, processes (such as processes 130, 140, and 150) communicate with the kernel via their exemplary kernel interface (such as kernel interface 132, 142, and 152). The exemplary kernel interface described herein allows the process to call the kernel to perform actions on some kernel object.
The exemplary kernel interfaces separates kernel objects into two categories: local kernel objects, which are created for exclusive use of the local process, and peer kernel objects, which are create for use within the local process or by peer processes. The exemplary kernel interfaces includes functions that can act only on local kernel objects and functions that can act only on peer kernel objects. Examples of local kernel objects in the exemplary kernel interface include (but are not limited to):
Examples of peer kernel objects in the exemplary kernel interface include (but are not limited to):
Examples of functions in the exemplary kernel interface that act only on local kernel objects include (but are not limited to):
Examples of functions exemplary kernel interface that act only on peer kernel objects include (but are not limited to):
Because conventional kernel interfaces know of no distinction between local and peer kernel objects, they expose processes to both accidental and malicious misuse of kernel objects. This misuse can allow a first process to alter or corrupt the state of a second process.
Fortunately, with one or more implementations described herein, a calling process is restricted through the separate of kernel objects into local and peer objects as to the function it may direct the kernel to perform. By separating different type of kernel objects into distinct local and peer object categories, one or more implementations described herein prevent a first process from either accidentally or maliciously altering or corrupting the in-process data of a second process.
Because the exemplary kernel interface separates specific types of kernel objects into either local or peer object categories, static analysis tools, such as compilers or program verifiers, can easily check the instructions of statically typed programs to verify that it will not attempt, either accidentally or maliciously, to alter the in-process data of a second program. The verification step is to read the instructions of the first program, identify the type of each kernel object identifier used in the program, identify each kernel interface call in the first program, and verify that each kernel interface call uses only the appropriate types of kernel object identifiers.
Using “local” kernel objects, a calling process may have a purview which, for example, limits it to the calling the process itself. Therefore, in this instance, the calling process can only direct the kernel to perform functions that directly affect only the calling process itself. With this purview and with reference to
In another implementation, the purview of a calling process may be, for example, limited to the calling process itself, any children of that calling process, and the state of the kernel with respect to the calling process and its children. Thus, in this instance, the calling process can only direct the kernel to perform those functions directly affecting the calling process itself its children, or the state of the kernel with respect to the calling process or its children.
With this purview and with reference to
In still another implementation, the purview of a calling process may be, for example, limited to the calling process itself, to initiating or terminating children, and the state of the kernel with respect to the calling process. Therefore, in this instance, the calling process can only instruct the kernel to perform those functions that directly affect the calling process itself while it is executing, its children upon initiation or termination (but not while it is executing), or the state of the kernel with respect to just the calling process.
Thus, in other words, the calling process may directly affect (via a kernel interface call) the state of a child process either before or after the child process executes, but not during the child's execution. The parent process may call to create a child process, which specifies the code in the child process before the child begins execution. The parent process may call to stop a child process, which reclaims the state of the child process after all threads of ceased execution.
With this purview and with reference to
Furthermore, with one or more implementations described, the communication between the calling process and the kernel—via its kernel interface—cannot be redirect to a second process because redirection to a second process would require conversion of “local” kernel objects to “peer” kernel objects. Consequently, the OS can guarantee a dependable execution environment for the child process. This guarantee also prevents an untrusted parent process from snooping on private communication between the child process and the kernel.
With the kernel interfaces (like what is described herein) bounded to the state of the calling process (and its purview), the OS guarantees the integrity of the kernel interface. In addition, the described kernel interfaces may establish a trusted isolation boundary between the parent and child process. The exemplary bounded kernel interface may enforce a model that allows the parent process to limit a child's access to all additional software services (accessed through channels). At the same time, the exemplary bounded kernel interface gives a child process the ability to identify the providers of all software services (accessed through channels) and limit its use of services based on its trust policies.
Methodological Implementation Regarding Kernel Interface Calls
At block 202 of
At block 204, the OS facilitates a calling process (e.g., process 130) to make a call—via the kernel interface—to the kernel. With the call, the calling process seeks to access to one or more kernel objects via the kernel interface and the kernel. In one implementation, the call specifies a categorized kernel-object identifier that identifies one or more called kernel objects.
At block 206, the OS determines whether a categorized kernel-object identifier specified by the call is a member of a designated first category of kernel-object identifiers. The first category here can be the either the “local” or “peer” kernel-object identifiers. So, the second category would be the other identifiers.
With at least one implementation, membership in the categorized lists is mutually exclusive. In other words, an identifier may be member of only one list. Indeed, there is no mechanism (in at least one implementation) for transferring membership amongst categories.
Furthermore, each categorized kernel object is identified by a unique kernel-object identifier. That identifier is formatted differently from the identifiers in the other category and that format is incompatible with the format of the other categories.
At block 208, if the category is determined to be “local”, the the OS permits the calling process to access the one or more kernel objects identified by the kernel-object identifier which has been determined to be a member of the designated first category of kernel-object identifiers.
At block 210, if the category is determined to be “peer”, the the OS permits the calling process to access the one or more kernel objects identified by the kernel-object identifier which has been determined to be a member of the designated first category of kernel-object identifiers.
Methodological Implementation Regarding Parent-Child Relationship
At block 302 of
At block 304, the OS facilitates the execution of a kernel in the computer operating system environment. For example, the kernel 120 runs as part of the OS 112 on the computer 102.
At block 306, the OS provides an kernel interface. The kernel interface is configured for the executing processes to call the kernel in order to instruct the kernel to perform a function that directly affects the execution of the kernel itself or the execution of the processes.
At block 308, the OS facilitates a parent process (e.g., process 130) spawning a new child process via a call through the kernel interface to the kernel. When the child is spawned, the call by the parent directs and defines the scope of access of the new child process. In other words, it defines which other process that the child process may communicate with (via inter-process communication channels). Simultaneously, the exemplary bounded kernel interface gives a child process the ability to identify the providers of all software services (accessed through channels) and limit its use of services based on its trust policies. In addition to creating them, a parent process may be allowed to terminate its children.
At block 310, the OS restricts calls—via the kernel interface—from the child process in such a way that the function to be performed by the kernel only directly affects the execution of the child process. Thus, calls by the child do not affect the execution of any of the other executing processes.
With regard to block 310, this is an example of just one purview of the child process. In other implementations, the purview may be extended and redefined. Examples of such purviews are discussed above in the section titled “Exemplary Kernel Interface.”
Conclusion
The term “software process” or “processes” is used herein for convenience and is not intended to limit the scope of this concept. Indeed, this concept can be implemented in software, hardware, firmware, or a combination thereof.
The techniques described herein may be implemented in many tangible ways, including, but not limited to, program modules, i.e., software, hardware, firmware, or a combination thereof. One or more implementations described herein may be implemented via many well-known computing systems, environments, and/or configurations that are suitable for use. Examples of such include, but are not limited to: personal computers (PCs), server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, wireless phones and equipment, general- and special-purpose appliances, commercial electronics, application-specific integrated circuits (ASICs), network PCs, thin clients, thick clients, set-top boxes, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like.
Although one or more of the above-described implementations were described in language specific to structural features and/or methodological steps, it is to be understood that other implementations may be practiced without the specific exemplary features or steps described herein. Rather, the specific exemplary features and steps are disclosed as preferred forms of one or more implementations. In some instances, well-known features may have been omitted or simplified to clarify the description of the exemplary implementations. Furthermore, for ease of understanding, certain method steps are delineated as separate steps; however, the steps delineated separately should not be construed necessarily as order dependent in their performance.
Appendix A
In general usage, the exemplary kernel interface is accessed through an API library. In this exemplary kernel interface, the executable instructions of the process are verified to insure that only trusted code in the API library can invoke the methods marked with the unsafe attribute. Each struct in the exemplary kernel interface represents a unique type of kernel object. Custom attribute tags below mark local kernel objects, [LocalKernelObject] and peer kernel objects, [PeerKernelObject]. The [LocalKernelObject] and [PeerKernelObject] tags are used to inform compilers and other tools that validate the correct usage of local and peer kernel objects and kernel interface entry points.
Number | Name | Date | Kind |
---|---|---|---|
4885684 | Austin et al. | Dec 1989 | A |
4916637 | Allen et al. | Apr 1990 | A |
5031089 | Liu et al. | Jul 1991 | A |
5057996 | Cutler et al. | Oct 1991 | A |
5179702 | Spix et al. | Jan 1993 | A |
5317568 | Bixby et al. | May 1994 | A |
5329619 | Page et al. | Jul 1994 | A |
5339443 | Lockwood | Aug 1994 | A |
5349682 | Rosenberry | Sep 1994 | A |
5361359 | Tajalli et al. | Nov 1994 | A |
5367681 | Foss et al. | Nov 1994 | A |
5455951 | Bolton et al. | Oct 1995 | A |
5469571 | Bunnell | Nov 1995 | A |
5481717 | Gaboury | Jan 1996 | A |
5522075 | Robinson et al. | May 1996 | A |
5551051 | Silverthorn et al. | Aug 1996 | A |
5574911 | D'Angelo et al. | Nov 1996 | A |
5590001 | Ino et al. | Dec 1996 | A |
5590281 | Stevens | Dec 1996 | A |
5666519 | Hayden | Sep 1997 | A |
5694601 | White | Dec 1997 | A |
5737605 | Cunningham et al. | Apr 1998 | A |
5752032 | Keller et al. | May 1998 | A |
5768532 | Megerian | Jun 1998 | A |
5794052 | Harding | Aug 1998 | A |
5845129 | Wendorf et al. | Dec 1998 | A |
5857195 | Hayashi et al. | Jan 1999 | A |
5878408 | Van Huben et al. | Mar 1999 | A |
5923878 | Marsland | Jul 1999 | A |
5931938 | Drogichen et al. | Aug 1999 | A |
5938723 | Hales, II et al. | Aug 1999 | A |
5958050 | Griffin et al. | Sep 1999 | A |
5963743 | Amberg et al. | Oct 1999 | A |
5974572 | Weinberg et al. | Oct 1999 | A |
5991518 | Jardine et al. | Nov 1999 | A |
6003129 | Song et al. | Dec 1999 | A |
6006328 | Drake | Dec 1999 | A |
6009476 | Flory et al. | Dec 1999 | A |
6038399 | Fisher et al. | Mar 2000 | A |
6066182 | Wilde et al. | May 2000 | A |
6072953 | Cohen et al. | Jun 2000 | A |
6078744 | Wolczko et al. | Jun 2000 | A |
6080207 | Kroening et al. | Jun 2000 | A |
6092189 | Fisher et al. | Jul 2000 | A |
6115819 | Anderson | Sep 2000 | A |
6144992 | Turpin et al. | Nov 2000 | A |
6157928 | Sprenger et al. | Dec 2000 | A |
6161051 | Hafemann et al. | Dec 2000 | A |
6182275 | Beelitz et al. | Jan 2001 | B1 |
6202147 | Slaughter et al. | Mar 2001 | B1 |
6247128 | Fisher et al. | Jun 2001 | B1 |
6279111 | Jensenworth et al. | Aug 2001 | B1 |
6292941 | Jollands | Sep 2001 | B1 |
6321334 | Jerger et al. | Nov 2001 | B1 |
6324622 | Okpisz et al. | Nov 2001 | B1 |
6341371 | Tandri | Jan 2002 | B1 |
6351850 | van Gilluwe et al. | Feb 2002 | B1 |
6381742 | Forbes et al. | Apr 2002 | B2 |
6405361 | Broy et al. | Jun 2002 | B1 |
6434694 | Slaughter et al. | Aug 2002 | B1 |
6438549 | Aldred et al. | Aug 2002 | B1 |
6442754 | Curtis | Aug 2002 | B1 |
6446260 | Wilde et al. | Sep 2002 | B1 |
6487723 | MacInnis | Nov 2002 | B1 |
6542926 | Zalewski et al. | Apr 2003 | B2 |
6546546 | Van Doorn | Apr 2003 | B1 |
6629152 | Kingsbury et al. | Sep 2003 | B2 |
6658447 | Cota-Robles | Dec 2003 | B2 |
6715144 | Daynes et al. | Mar 2004 | B2 |
6732220 | Babaian et al. | May 2004 | B2 |
6748592 | Porter | Jun 2004 | B1 |
6816905 | Sheets et al. | Nov 2004 | B1 |
6817013 | Tabata et al. | Nov 2004 | B2 |
6842782 | Malik et al. | Jan 2005 | B1 |
6868539 | Travison et al. | Mar 2005 | B1 |
6912692 | Pappas | Jun 2005 | B1 |
6944754 | Zilles et al. | Sep 2005 | B2 |
6973517 | Golden et al. | Dec 2005 | B1 |
6977994 | Stephenson et al. | Dec 2005 | B2 |
6988261 | Sokolov et al. | Jan 2006 | B2 |
7000092 | Gehman et al. | Feb 2006 | B2 |
7062764 | Cohen et al. | Jun 2006 | B2 |
7086056 | Fukushima | Aug 2006 | B2 |
7089289 | Blackmore et al. | Aug 2006 | B1 |
7155713 | Burkhardt et al. | Dec 2006 | B1 |
7167867 | Rago | Jan 2007 | B1 |
7222106 | Block et al. | May 2007 | B2 |
7222341 | Forbes et al. | May 2007 | B2 |
7278030 | Chen et al. | Oct 2007 | B1 |
7451435 | Hunt et al. | Nov 2008 | B2 |
7454477 | Talluri et al. | Nov 2008 | B2 |
7484245 | Friedman et al. | Jan 2009 | B1 |
7600232 | Hunt et al. | Oct 2009 | B2 |
7882317 | Hunt et al. | Feb 2011 | B2 |
20010029605 | Forbes et al. | Oct 2001 | A1 |
20020004852 | Sadovsky et al. | Jan 2002 | A1 |
20020099954 | Kedma et al. | Jul 2002 | A1 |
20020100017 | Grier et al. | Jul 2002 | A1 |
20030031404 | Pedersen | Feb 2003 | A1 |
20030056084 | Holgate et al. | Mar 2003 | A1 |
20030061067 | Atwal et al. | Mar 2003 | A1 |
20030061404 | Atwal et al. | Mar 2003 | A1 |
20030084256 | McKee | May 2003 | A1 |
20030097581 | Zimmer | May 2003 | A1 |
20030130854 | Galanes et al. | Jul 2003 | A1 |
20030191867 | Czajkowski | Oct 2003 | A1 |
20030200402 | Willman et al. | Oct 2003 | A1 |
20030212990 | Brodkorb et al. | Nov 2003 | A1 |
20030221012 | Herrmann et al. | Nov 2003 | A1 |
20030233644 | Cohen et al. | Dec 2003 | A1 |
20040025016 | Focke et al. | Feb 2004 | A1 |
20040034850 | Burkhardt et al. | Feb 2004 | A1 |
20040061067 | Clauss | Apr 2004 | A1 |
20040064736 | Obrecht et al. | Apr 2004 | A1 |
20040078799 | Koning et al. | Apr 2004 | A1 |
20040123273 | Hammerich et al. | Jun 2004 | A1 |
20040153991 | Chen et al. | Aug 2004 | A1 |
20040187096 | Dumont | Sep 2004 | A1 |
20040193819 | Marinescu et al. | Sep 2004 | A1 |
20040199763 | Freund | Oct 2004 | A1 |
20040226023 | Tucker | Nov 2004 | A1 |
20040236861 | Bondar et al. | Nov 2004 | A1 |
20040268171 | Inoue et al. | Dec 2004 | A1 |
20050005261 | Severin | Jan 2005 | A1 |
20050021537 | Brendle et al. | Jan 2005 | A1 |
20050050069 | Vaschillo et al. | Mar 2005 | A1 |
20050060687 | Ghazaleh et al. | Mar 2005 | A1 |
20050071592 | DeCaro | Mar 2005 | A1 |
20050071828 | Brokenshire et al. | Mar 2005 | A1 |
20050081181 | Brokenshire et al. | Apr 2005 | A1 |
20050081203 | Aguilar et al. | Apr 2005 | A1 |
20050091658 | Kavalam et al. | Apr 2005 | A1 |
20050119902 | Christiansen | Jun 2005 | A1 |
20050125789 | Dijkstra et al. | Jun 2005 | A1 |
20050188372 | Inoue et al. | Aug 2005 | A1 |
20050203988 | Nollet et al. | Sep 2005 | A1 |
20050223239 | Dotan | Oct 2005 | A1 |
20050246718 | Erlingsson et al. | Nov 2005 | A1 |
20060005082 | Fossum et al. | Jan 2006 | A1 |
20060031815 | Bhagia et al. | Feb 2006 | A1 |
20060047875 | Aguilar et al. | Mar 2006 | A1 |
20060069692 | Pernia | Mar 2006 | A1 |
20060085789 | Laborczfalvi et al. | Apr 2006 | A1 |
20060123401 | O'Brien et al. | Jun 2006 | A1 |
20060123417 | Hunt et al. | Jun 2006 | A1 |
20070011199 | Hunt et al. | Jan 2007 | A1 |
20070033592 | Roediger et al. | Feb 2007 | A1 |
20070043936 | Day et al. | Feb 2007 | A1 |
20070061483 | Dauger | Mar 2007 | A1 |
20070094495 | Hunt et al. | Apr 2007 | A1 |
20070094673 | Hunt et al. | Apr 2007 | A1 |
20070256080 | Smith et al. | Nov 2007 | A1 |
20070283337 | Kasahara et al. | Dec 2007 | A1 |
20080022278 | Gschwind et al. | Jan 2008 | A1 |
20080244507 | Hodson et al. | Oct 2008 | A1 |
20080250414 | Brokenshire et al. | Oct 2008 | A1 |
Number | Date | Country |
---|---|---|
1549108 | Nov 2004 | CN |
1033648 | Sep 2000 | EP |
1443398 | Aug 2004 | EP |
2002506247 | Feb 2002 | JP |
2003233521 | Aug 2003 | JP |
2004513412 | Apr 2004 | JP |
20010007119 | Jan 2001 | KR |
2307388(C2) | Sep 2007 | RU |
2337398(C2) | Oct 2008 | RU |
WO02093370 | Nov 2002 | WO |
WO03038599 | May 2003 | WO |
WO2004025491(A1) | Mar 2004 | WO |
WO2004099949(A1) | Nov 2004 | WO |
Number | Date | Country | |
---|---|---|---|
20080005750 A1 | Jan 2008 | US |