Associating identifiers with virtual processes

Information

  • Patent Grant
  • 7143024
  • Patent Number
    7,143,024
  • Date Filed
    Friday, July 7, 2000
    24 years ago
  • Date Issued
    Tuesday, November 28, 2006
    18 years ago
Abstract
Multiple virtual processes are each associated with a unique virtual process identifier. For each virtual process, a separate initialization process is started, from which all other processes included in the virtual process originate. The initialization process is associated with the appropriate virtual process identifier. System calls that create new processes are intercepted, and created processes are associated with the virtual process identifier of the appropriate initialization process. Multiple virtual processes are provided on a single, physical computer system.
Description
BACKGROUND

1. Field of Invention


The present invention relates generally to virtual computer processes, and specifically to associating an identifier with each of a plurality of processes comprising a virtual process.


2. Background of Invention


With the popularity and success of the Internet, server technologies are of great commercial importance today. Typically, an individual server application executes on a single physical host computer, servicing client requests. However, providing a unique physical host for each server application is expensive and inefficient. Hosting services are often provided commercially by an Internet Service Provider (ISP). Typically, an ISP has to provide a separate physical host computer on which to execute a server application for every customer that purchases hosting services. Often, a customer purchasing hosting services from an ISP will neither require nor be amenable to paying for use of an entire host computer. Generally, only a fraction of the processing power, storage, and other resources of a host computer will be required to meet the needs of an individual customer.


It is desirable for an ISP to be able to provide multiple server applications on a single physical host computer. However, in order to be commercially viable, every server application would have to be isolated from every other server application running on the same physical host. Obviously, it would be unacceptable to customers of an ISP to purchase hosting services, only to have another server application program (perhaps belonging to a competitor) be able to access the customer's data and client requests. Thus, each server application program would have to be isolated, receiving requests from only its own clients, transmitting data to only its own clients, and being prevented from accessing data associated with other server applications. Furthermore, it would be necessary to allocate varying specific levels of system resources to different server applications, depending upon the needs of and amounts paid by the various customers of the ISP. In effect, each server application would need to comprise a virtual private server, simulating a server application executing on a dedicated physical host computer.


Such functionality has been heretofore impossible because a virtual private server, rather than comprising a single, discrete process, must be made up of a plurality of seemingly unrelated processes, each performing various elements of the sum total of the functionality required by the customer. Because each virtual private server must comprise a plurality of processes, it has been impossible for an ISP to isolate the processes associated with one virtual private server from those processes associated with other virtual private servers. What is needed is a method whereby the individual ones of pluralities of separate processes comprising multiple, virtual private servers can each be associated with their respective virtual private server.


SUMMARY OF INVENTION

The present invention facilitates the association of multiple processes with their respective virtual private servers. In order to run multiple virtual processes on a single, physical computer system, each virtual private server is started by executing a separate, system initialization process. Each system initialization process is associated with a virtual private server identifier, for example by storing the identification number of the process and the virtual private server identifier in a data structure in computer memory. Each virtual private server identifier may be associated with a particular customer to identify the virtual private server belonging to the customer.


System calls that create processes are intercepted, and a system call wrapper associates created processes with the virtual private server identifier with which the process that made the system call is associated. Thus, all processes originating from each system initialization process will be associated with the virtual private server identifier associated with the corresponding system initialization process. Because all processes that are part of a virtual private server will be created by the associated system initialization process or by its progeny, all processes comprising a virtual private server will be associated with the corresponding virtual private server identifier. This allows all processes that are a part of each customer's virtual private server to be identified and segregated from the processes of other customers, even though these processes are executing on the same physical server.


It will be readily apparent to one skilled in the art that the present invention can be utilized to associate a plurality of processes comprising any type of virtual process with a corresponding virtual process identifier. Of course, all such utilizations are within the scope of the present invention. Although in one embodiment, the virtual process is in the form of a virtual private server, the present invention is by no means limited to this embodiment.


The features and advantages described in this summary and the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a block diagram providing a high level overview of a system for associating identifiers with virtual processes, according to one embodiment of the present invention.



FIG. 2 is a block diagram illustrating a system utilizing a virtual process manager program, according to one embodiment of the present invention.



FIG. 3 is a block diagram illustrating a system utilizing a modified loader program, according to another embodiment of the present invention.





The figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.


DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
I. System Overview


FIG. 1 illustrates a high level overview of a system 100 for associating identifiers with virtual processes according to one embodiment of the present invention. A computer memory 101 includes user address space 103 and operating system address space 105. Multiple initialization processes 107 execute in user address space 103. Although FIG. 1 illustrates only two initialization processes 107 executing in user address space 103, it is to be understood that within a given computer memory 101, more than two initialization processes 107 can execute simultaneously.


Also executing in user address space are descendent processes 108, originating from the initialization processes 107. A descendent process 108 is a child process of an initialization process 107, or a child process thereof, extended to any number of generations of subsequent child processes. Although FIG. 1 illustrates only two descendent processes 108 for each initialization process 107, it is to be understood that within a given computer memory 101, fewer or more than two descendent processes 108 per initialization process 107 can execute simultaneously.


Preferably, a data structure for storing associations 129 between executing processes (initialization processes 107 or descendent processes 108) and virtual processes is inserted into the operating system 117. In one embodiment, the data structure is a mapping table 127, but in other embodiments other data structures are utilized, for example a linked list. In one embodiment, the mapping table 127 (or other data structure) is dynamically loaded into the operating system kernel 109, while the kernel 109 is active. In another embodiment, the mapping table 127 is stored in user address space 103. The maintenance and use of the mapping table 127 is discussed in detail below.


It is to be understood that a virtual process is not an actual process that executes in computer memory 101. Instead, the term “virtual process” describes a collection of associated functionality. For example, a virtual private server application is not actually a discrete process, but instead comprises a plurality of actual processes that together provide the desired functionality, thereby simulating the existence of a single server application executing on a dedicated physical host. Each actual process that performs some of the functionality of the virtual private server is a part of the virtual process. In FIG. 1 for example, initialization process 1 and descendent processes 1 and 2 (the processes descended from initialization process 1) comprise one virtual process, whereas initialization process 2 and descendent processes 3 and 4 comprise another.


In order to associate a specific identifier with each actual process that is a part of a virtual process, a separate system initialization process 107 is started for each virtual process. Normally, each process executing on a multitasking operating system is descended from a single system initialization process 107 that is started when the operating system 117 is booted. However, the present invention uses techniques described in detail below to start a separate system initialization process 107 for each virtual process. When each system initialization process 107 is started, an association 129 between the system initialization process 107 and the virtual process is stored in the mapping table 127. All additional processes that are descended from a given initialization process are thus identified with the virtual process associated with that initialization process.


In one embodiment, rather than starting a separate system initialization process 107 for each virtual process, a custom initialization process is started. In this embodiment, all processes that are a part of a specific virtual process are descended from the associated custom initialization process, and are associated with the virtual process with which the custom initialization process is associated. The exact functionality included in the custom initialization process is a design choice that can be made by a system administrator.


System calls 115 that generate child processes (for example, the UNIX® fork and clone functions) are intercepted so that the child processes can be associated with the virtual process with which the parent process is associated. A system call wrapper 111 is utilized in order to intercept system calls 115. In one embodiment, the system call wrapper 111 is dynamically loaded into the operating system kernel 109, while the kernel 109 is active. In another embodiment, the system call wrapper is loaded in user address space 103. The system call wrapper 111 is preferably in the form of object code, the functional features of which are described in detail below.


Pointers 114 to system calls 115 are located in an operating system call vector table 113. It is to be understood that the term “system call vector table” as used herein denotes an area in operating system address space 105 in which there are stored the addresses of system calls. In the UNIX® operating system, this part of the operating system is called the “system call vector table,” and that term is used in this specification. Other operating systems employ different terminology to denote the same system component. A system call vector table by any other name is still within the scope of the present invention.


A copy 116 is made of a pointer 114 to each system call 115 to be intercepted. These copies 116 of pointers 114 are preferably stored in operating system address space 105, but in an alternative embodiment are stored in user address space 103. Once the copies 116 have been made and saved, the pointers 114 in the system call vector table 113 to the system calls 115 to be intercepted are replaced with pointers 118 to the system call wrapper 111, such that when a system call 115 to be intercepted is made, the system call wrapper 111 executes instead. In one embodiment, this copying, storing, and replacing of pointers is performed by the system call wrapper 111. In other embodiments, copying, storing, and replacing of pointers is performed by a pointer management module executing in either operating system address space 105 or user address space 103 as desired. The pointer management module can either be a stand alone program, or a component of a larger application program as desired.


Executing alternative code when a system call 115 is made comprises intercepting the system call 115. The steps of inserting a system call wrapper 111 into the operating system 117, making a copy 116 of an operating system pointer 114 to a system call 115, and replacing the operating system pointer 114 with a pointer 118 to the system call wrapper 111 facilitate interception of a system call 115. When a system call 115 to be intercepted is made, the operating system 117 uses the pointer 118 in the system call vector table 113 to the system call wrapper 111 to execute the system call wrapper 111.


It is to be understood that only system calls 115 that create child processes need be intercepted, and thus only pointers 114 to system calls 115 to be intercepted are replaced with pointers 118 to the system call wrapper 111. Pointers 114 to system calls 115 which are not to be intercepted are not replaced. Thus, when a non-intercepted system call 115 is made, the system call 115 executes, not the system call wrapper 111.


The various initialization processes 107 and descendent processes 108 execute in user address space 103 under control of the operating system 117, and make system calls 115. When a process makes a system call 115 that creates a child process, the system call wrapper 111 reads the mapping table 127, and determines whether the process that made the system call (the parent of the child process being created) is associated with a virtual process. If so, the system call wrapper 111 uses the saved copy of the pointer 116 to execute the system call 115, allowing the creation of the child process. The system call wrapper 111 updates the mapping table 127, storing an association 129 between the newly created child process and the virtual process with which the process that made the system call is associated. Thus, all descendent processes 108 are associated with the virtual process with which their parent process is associated.


II. Starting Initialization Processes by a Manager Program


FIG. 2 illustrates one embodiment of a system 200 for associating identifiers with virtual processes. In the embodiment illustrated by FIG. 2, the initialization processes 107 are started by a virtual process manager program 201 executing in user address space 103.


The virtual process manager program 201 modifies the operating system 117 of the computer to include the mapping table 127. Preferably, the manager program 201 loads the mapping table 127 into the kernel 109 of the operating system 117 while the kernel is active.


For each virtual process, the manager program 201 starts an initialization process 107 from which all other processes that are part of the virtual process will originate as descendent processes 108. Each time the manager program 201 starts an initialization process 107 for a virtual process, the manager program 201 stores, in the mapping table 127, an association 129 between the initialization process 107 and the appropriate virtual process. Subsequently, all additional processes that are part of the virtual process will be originated from the initialization process, and thus associated with the appropriate virtual process.


For example, suppose that the manager program 201 starts a first virtual private server. To do so, the manager process 107 starts an initialization process 107 for the virtual private server, storing an association 129 between the initialization process 107, and a virtual process identifier for the virtual private server. Additional processes that are part of the virtual private server originate from the initialization process 107, and are associated with the virtual process identifier of the virtual private server. The manager process 201 can proceed to start a second virtual private server by starting a separate initialization process 107, and associating the second initialization process 107 with a separate virtual process identifier for the second virtual private server. Consequently, all of the processes associated with the second virtual private server will be associated with the appropriate virtual process identifier. In this manner, multiple virtual processes on the same physical computer are each associated with unique identifiers.


III. Starting Initialization Processes by a Loader Program


FIG. 3 illustrates another embodiment of a system 300 for associating identifiers with virtual processes. In the embodiment illustrated by FIG. 3, initialization processes 107 are not started by a manager program 201, but instead are loaded by a modified loader program 301.


A loader program is an operating system utility that is used to execute computer programs that are stored on static media. Typically, a loader program loads an executable image from static media into user address space 103 of computer memory 101, and then initiates execution of the loaded image by transferring execution to the first instruction thereof.


Like a standard loader program, the modified loader 301 loads executable images (in this case, initialization processes 107) from static media into user address space 103. Additionally, the modified loader program 301 stores, in the mapping table 127, an association 129 between the initialization process 107 being loaded and the appropriate virtual process. Thus, for each virtual process, an initialization process 107 is loaded by the modified loader program, and an association between the initialization process 107 and the virtual process is stored in the mapping table 127. Subsequently, additional processes that are part of the virtual process originate from the associated initialization process 107, and are thus associated with the virtual process as described above.


In another embodiment, the modified loader program 301 loads all processes that are part of each virtual process. In that embodiment, whenever the modified loader program 301 loads a process, the modified loader program 301 also stores, in the mapping table, an association 129 between the loaded process and the appropriate virtual process.


As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming of the modules, features, attributes or any other aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names or formats. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims
  • 1. A method in a computer operating system for associating an identifier with a plurality of processes, the method comprising: starting a first process;associating the first process with the identifier;creating, from the first process, a second process;associating the second process with the identifier;associating a third process with the identifier, wherein the third process is not a descendant of the first process;creating, from the third process, a fourth process; andassociating the fourth process with the identifier.
  • 2. The method of claim 1 wherein the plurality of processes together provide the functionality of a dedicated server application program.
  • 3. The method of claim 1 wherein the first process comprises a system initialization process.
  • 4. The method of claim 1 wherein associating the first process with the identifier comprises storing an entry in a data structure, the entry comprising the identifier and a process identification number of the first process.
  • 5. The method of claim 1 further comprising intercepting a system call, made by the first process, that creates a process.
  • 6. The method of claim 5 wherein intercepting the system call comprises replacing a first pointer, which points to object code of the system call, with a second pointer, which points to different object code, such that making the system call causes the different object code to execute.
  • 7. The method of claim 6 further comprising inserting the different object code into the operating system.
  • 8. The method of claim 7 wherein inserting the different object code into the operating system comprises loading a module into a running operating system kernel, the module comprising the different object code.
  • 9. The method of claim 1 further comprising: loading, by a modified loader program, the first process into computer memory;starting, by the modified loader program, the first process; andstoring, by the modified loader program, an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of the first process.
  • 10. The method of claim 1 further comprising: starting, by a virtual process manager program, the first process; andstoring, by the manager program, an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of the first process.
  • 11. A computer-readable medium storing a computer program product for using a computer operating system to associate an identifier with a plurality of processes, the computer program product comprising: program code for starting a first process;program code for associating the first process with the identifier;program code for creating, from the first process, a second process;program code for associating the second process with the identifier;program code for associating a third process with the identifier, wherein the third process is not a descendant of the first process;program code for creating, from the third process, a fourth process; andprogram code for associating the fourth process with the identifier.
  • 12. The computer-readable medium of claim 11 wherein the computer program product further comprises program code for storing an entry in a data structure, the entry comprising the identifier and a process identification number of the first process.
  • 13. The computer-readable medium of claim 11 wherein the computer program product further comprises: program code for intercepting a system call that creates a process; andprogram code for associating the process being created with the identifier of a process that made the system call.
  • 14. The computer-readable medium of claim 11 wherein the computer program product further comprises: program code comprising instructions to associate the process being created with the identifier of the process that made the system call; andprogram code for replacing a pointer to the system call with a pointer to the instructions to associate, such that making the system call causes the instructions to associate to execute.
  • 15. The computer-readable medium of claim 14 wherein the computer program product further comprises program code for storing the instructions to associate in the operating system by loading a module into a running operating system kernel, the module comprising the instructions to associate.
  • 16. The computer-readable medium of claim 11 wherein the computer program product further comprises: program code for starting the first process; andprogram code for storing an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of the first process.
  • 17. The computer-readable medium of claim 16 wherein the computer program product further comprises program code for loading the first process into computer memory.
  • 18. A computer operating system for associating an identifier with a plurality of processes, the computer operating system comprising: an initiation module, for starting a first process and a third process, wherein the third process is not a descendant of the first process;a creation module, coupled to the initiation module, for creating, from the first process, a second process, and for creating, from the third process, a fourth process; andan association module, coupled to the creation module, for associating the first process with the identifier, and for associating the second process with the identifier, and for associating the third process with the identifer, and for associating the fourth process with the identifier.
  • 19. The system of claim 18 further comprising a storage module, coupled to the association module, for storing an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of the first process.
  • 20. The system of claim 18 further comprising an interception module, coupled to the association module, for intercepting a system call that creates a process; and wherein the association module is further for associating the process being created with the identifier of a process that made the system call.
  • 21. The system of claim 20 further comprising a storage module, coupled to the interception module, for storing object code comprising instructions to associate the process being created with the identifier of the process that made the system call; and wherein the interception module is further for replacing a pointer to the system call with a pointer to the stored object code, such that making the system call causes the object code to execute.
  • 22. The system of claim 21 further comprising an insertion module, coupled to the storage module, for inserting the instructions to associate in the operating system by loading a module into a running operating system kernel.
  • 23. A method in a computer operating system for associating an identifier with a plurality of processes, the method comprising: executing a system initialization process;associating the system initialization process with the identifier;associating a second process, created from the system initialization process, with the identifier;associating a third process with the identifier, wherein the third process is not a descendant of the system initialization process;creating, from the third process, a fourth process; andassociating the fourth process with the identifier.
  • 24. A method in a computer operating system for associating an identifier with a plurality of processes, the method comprising: loading, by a modified loader program, a first process into computer memory; andstoring, by the modified loader program, an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of the loaded process;storing, by the modified loader program, an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of a second process, wherein the second process was created from the first process;storing, by the modified loader program, an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of a third process, wherein the third process is not a descendant of the first process;storing, by the modified loader program, an entry in a data structure in computer memory, the entry comprising the identifier and a process identification number of a fourth process, wherein the fourth process was created from the third process.
  • 25. A method in a computer operating system for associating an identifier with a plurality of processes, the method comprising: associating a first process with the identifier;associating a second process with the identifier, wherein the second process is not a descendant of the first process;creating, from the second process, a third process; andassociating the third process with the identifier.
US Referenced Citations (152)
Number Name Date Kind
3377624 Nelson et al. Apr 1968 A
4177510 Appell et al. Dec 1979 A
5189667 Esaki et al. Feb 1993 A
5212793 Donica et al. May 1993 A
5226160 Waldron et al. Jul 1993 A
5249290 Heizer Sep 1993 A
5263147 Francisco et al. Nov 1993 A
5325530 Mohrmann Jun 1994 A
5437032 Wolf et al. Jul 1995 A
5528753 Fortin Jun 1996 A
5566334 Loader Oct 1996 A
5572680 Ikeda et al. Nov 1996 A
5584023 Hsu Dec 1996 A
5603020 Hashimoto et al. Feb 1997 A
5615400 Cowsar et al. Mar 1997 A
5623492 Teraslinna Apr 1997 A
5636371 Yu Jun 1997 A
5640595 Baugher et al. Jun 1997 A
5692047 McManis Nov 1997 A
5706097 Schelling et al. Jan 1998 A
5706453 Cheng et al. Jan 1998 A
5708774 Boden Jan 1998 A
5719854 Choudhury et al. Feb 1998 A
5727147 van Hoff Mar 1998 A
5727203 Hapner et al. Mar 1998 A
5748614 Wallmeier May 1998 A
5752003 Hart May 1998 A
5761477 Wahbe et al. Jun 1998 A
5764889 Ault et al. Jun 1998 A
5781550 Templin et al. Jul 1998 A
5799173 Gossler et al. Aug 1998 A
5809527 Cooper et al. Sep 1998 A
5828893 Weid et al. Oct 1998 A
5838686 Ozkan Nov 1998 A
5838916 Domenikos et al. Nov 1998 A
5842002 Schnurer et al. Nov 1998 A
5845129 Wendorf et al. Dec 1998 A
5850399 Ganmukhi et al. Dec 1998 A
5860004 Fowlow et al. Jan 1999 A
5864683 Boebert et al. Jan 1999 A
5889956 Hauser et al. Mar 1999 A
5889996 Adams Mar 1999 A
5892968 Iwasaki et al. Apr 1999 A
5905730 Yang et al. May 1999 A
5905859 Holloway et al. May 1999 A
5913024 Green et al. Jun 1999 A
5915085 Koved Jun 1999 A
5915095 Miskowiec Jun 1999 A
5918018 Gooderum et al. Jun 1999 A
5920699 Bare Jul 1999 A
5933603 Vahalia et al. Aug 1999 A
5937159 Meyers et al. Aug 1999 A
5956481 Walsh et al. Sep 1999 A
5961582 Gaines Oct 1999 A
5978373 Hoff et al. Nov 1999 A
5982748 Yin et al. Nov 1999 A
5987242 Bentley et al. Nov 1999 A
5987524 Yoshida et al. Nov 1999 A
5987608 Roskind Nov 1999 A
5991812 Srinivasan Nov 1999 A
5999963 Bruno et al. Dec 1999 A
6016318 Tomoike Jan 2000 A
6018527 Yin et al. Jan 2000 A
6023721 Cummings Feb 2000 A
6038608 Katsumanta Mar 2000 A
6038609 Geulen Mar 2000 A
6047325 Jain et al. Apr 2000 A
6055617 Kingsbury Apr 2000 A
6055637 Hudson et al. Apr 2000 A
6061349 Coile et al. May 2000 A
6065118 Bull et al. May 2000 A
6075791 Chiussi et al. Jun 2000 A
6075938 Bugnion et al. Jun 2000 A
6078929 Rao Jun 2000 A
6078957 Adelman et al. Jun 2000 A
6086623 Broome et al. Jul 2000 A
6092178 Jindal et al. Jul 2000 A
6094674 Hattori et al. Jul 2000 A
6101543 Alden et al. Aug 2000 A
6108701 Davis et al. Aug 2000 A
6108759 Orcutt et al. Aug 2000 A
6122673 Basak et al. Sep 2000 A
6154776 Martin Nov 2000 A
6154778 Koistinen et al. Nov 2000 A
6161139 Win et al. Dec 2000 A
6167520 Touboul Dec 2000 A
6172981 Cox et al. Jan 2001 B1
6189046 Moore et al. Feb 2001 B1
6192389 Ault et al. Feb 2001 B1
6192512 Chess Feb 2001 B1
6230203 Koperda et al. May 2001 B1
6240463 Benmohamed et al. May 2001 B1
6247057 Barrera Jun 2001 B1
6247068 Kyle Jun 2001 B1
6259699 Opalka et al. Jul 2001 B1
6266678 McDevitt et al. Jul 2001 B1
6269404 Hart et al. Jul 2001 B1
6279039 Bhat et al. Aug 2001 B1
6279040 Ma et al. Aug 2001 B1
6282581 Moore et al. Aug 2001 B1
6282703 Meth et al. Aug 2001 B1
6286047 Ramanathan et al. Sep 2001 B1
6298479 Chessin et al. Oct 2001 B1
6314558 Angel et al. Nov 2001 B1
6327622 Jindal et al. Dec 2001 B1
6336138 Caswell et al. Jan 2002 B1
6351775 Yu Feb 2002 B1
6353616 Elwalid et al. Mar 2002 B1
6363053 Schuster et al. Mar 2002 B1
6366958 Ainsworth et al. Apr 2002 B1
6370583 Fishler et al. Apr 2002 B1
6374292 Srivastava et al. Apr 2002 B1
6381228 Prieto, Jr. et al. Apr 2002 B1
6385638 Baker-Harvey May 2002 B1
6385722 Connelly et al. May 2002 B1
6389448 Primak et al. May 2002 B1
6393484 Massarani May 2002 B1
6425003 Herzog et al. Jul 2002 B1
6430622 Aiken, Jr. et al. Aug 2002 B1
6434631 Bruno et al. Aug 2002 B1
6434742 Koepele, Jr. Aug 2002 B1
6438134 Chow et al. Aug 2002 B1
6442164 Wu Aug 2002 B1
6449652 Blumenau et al. Sep 2002 B1
6457008 Rhee et al. Sep 2002 B1
6463459 Orr et al. Oct 2002 B1
6470398 Zargham et al. Oct 2002 B1
6484173 O'Hare et al. Nov 2002 B1
6487578 Ranganathan Nov 2002 B1
6487663 Jaisimha et al. Nov 2002 B1
6490670 Collins et al. Dec 2002 B1
6496847 Bugnion et al. Dec 2002 B1
6499137 Hunt Dec 2002 B1
6529950 Lumelsky et al. Mar 2003 B1
6529985 Deianov et al. Mar 2003 B1
6542167 Darlet et al. Apr 2003 B1
6553413 Leighton et al. Apr 2003 B1
6578055 Hutchison et al. Jun 2003 B1
6578068 Bowman-Amuah Jun 2003 B1
6580721 Beshai Jun 2003 B1
6590588 Lincke et al. Jul 2003 B1
6622159 Chao et al. Sep 2003 B1
6647422 Wesinger et al. Nov 2003 B1
6658571 O'Brien et al. Dec 2003 B1
6691312 Sen et al. Feb 2004 B1
6725456 Bruno et al. Apr 2004 B1
6760775 Anerousis et al. Jul 2004 B1
6785728 Schneider et al. Aug 2004 B1
6820117 Johnson Nov 2004 B1
6859835 Hipp Feb 2005 B1
6912590 Lundback et al. Jun 2005 B1
20030061338 Stelliga Mar 2003 A1
Foreign Referenced Citations (2)
Number Date Country
64-002145 Jan 1989 JP
WO 9939261 Aug 1999 WO