Patent Grant
7516435
A portion of the disclosure of this patent document may contain material which is subject to copyright protection. To the extent that it does, the copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright © 2003–2004, Mentor Graphics Corp., All Rights Reserved.
This invention relates to the field of electronic design automation tools, and more specifically, to a mechanism for facilitating ease of use and conflict avoidance in a shared environment for parallel printed circuit board (PCB) design.
A printed circuit board (“PCB”) often begins as a schematic diagram by which an electrical engineer describes an electronic circuit as a logical diagram of symbolic representations. The schematic may then be used to lay out various electronic components, and the connections (e.g., netlines, routes, traces) between those components may be routed. Ultimately, a PCB design is created and data for the PCB design can be electronically stored. That data can be used to generate artwork corresponding to a pattern of components and connections between those components. The artwork, in turn, can be used with photographic imaging techniques to manufacture the PCB.
Many users may be involved during the layout process. Traditionally, this has been accomplished via a design splitting mechanism whereby each user can check out a corresponding (assigned) piece of the design to make edits to the PCB layout.
Using the above-described approach, a user is limited to viewing only areas of the design that are opened by that user. Consequently, the user cannot see edits that are made to the rest of the board while the user's edits are being made. There remains a need for systems and methods whereby multiple users can simultaneously edit the same portions of a PCB design, but can also prevent conflicts between the users.
Embodiments of the invention include methods for simultaneous editing of at least a portion of a printed circuit board (PCB) design by multiple users. Such methods include receiving design data at each of first and second clients. The design data includes graphically displayable information regarding a pattern of electronic components and connections between those components for at least a portion of the design. The design data also includes data corresponding to at least a portion of a shared area of the design, and the shared area is simultaneously editable by both of the clients. The method further includes generating a first boundary associated with a part of the shared area being edited at the first client, displaying the first boundary at the second client, and preventing the second client from editing parts of the shared area within the first boundary. In some embodiments, the protection boundary surrounds a user's cursor. The size of the boundary may increase based on editing activity by the user in an area of a PCB design. Additional embodiments of the invention include computer readable media having instructions for performing steps of various method embodiments of the invention.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
One aspect of the invention relates to a method for allowing a user to edit a PCB design concurrently with allowing the user to view edits to the PCB design by other users. Generally, the method displays a PCB design to a plurality of users. While a first user makes edits to an arbitrary section of the PCB design, a second user makes edits to an arbitrary section of the PCB design while preserving the integrity of the master design. In one embodiment of the invention, arbitrary sections may overlap, allowing each user to edit shared areas of the master design. In another embodiment of the invention, arbitrary sections are mutually exclusive, such that each user edits unshared, exclusive areas of the master design.
The present invention includes various operations, which will be described below. The operations of the present invention may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the operations. Alternatively, the operations may be performed by a combination of hardware and software.
The present invention may be provided as a computer program product which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic devices) to perform a process according to the present invention. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs (Compact Disc-Read Only Memories), magneto-optical disks, ROMs (Read Only Memories), RAMs (Random Access Memories), EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electromagnetic Erasable Programmable Read Only Memories), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.
Moreover, the present invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection). Accordingly, herein, a carrier wave shall be regarded as comprising a machine-readable medium.
Each client 202, 204, 206 enables users to request edits to the master design 116 in parallel with one another while viewing edits made to the master design 116 by other users. Master design 116 comprises the version on the server 200 database 208 which incorporates edit requests from clients that are accepted by the server 200, and may also be referred to as the compiled master design. Master design 216 comprises the version that is edited by a user on a given client 202, 204, 206.
When a PCB design is displayed (i.e., master design 216), it may comprise the entire PCB design, or it may comprise a partial PCB design. For instance, the master design 116 may be distributed amongst several user groups, and embodiments of the invention may be applicable to each user group, such that for a given user group, only their sections are displayed, thereby displaying only a partial PCB design. However, the sections displayed for that user group may comprise shared and exclusive areas as described herein.
A user on client 206, for example, may request edits to the master design 116, and the edit requests are submitted to the server 200. The server 200 processes the edit requests and either accepts the edit requests or rejects them. Rejected edit requests are reported back to the requesting client 206. Accepted edit requests are applied to the master design 116. Clients 202, 204, 206 can then be synchronized with master design 116.
In embodiments of the invention, parallel PCB design gives users the ability to view a compiled master design 116 while requesting edits to the master design 116. In one embodiment, one user may simultaneously edit shared areas of the master design with another user while viewing the master design 116 (shared PCB design). In another embodiment, one user may simultaneously edit unshared, exclusive areas of the master design 116 (distributed PCB design) with another user while viewing the master design 116.
An edit request may comprise a list of one or more objects and corresponding commands made by the particular user. Objects include routes, components, traces, vias, text, and drawing objects, for example; and commands include move left, move right, delete, or add, for example.
Once an edit request 300 is submitted to the server 304, the edit request 300 is placed in a request queue 306 of the server. The request queue may comprise a FIFO (first-in-first-out) queue where edit requests submitted first are processed first; or a priority queue, where certain edit requests (i.e., types of requests, or requests from certain clients) are given priority over other edit requests, for example. When the edit request is eventually taken off the request queue, server conflict checking and resolution 308 (to be discussed) are performed on the edit request. If server conflict checking and resolution passes, then the edit is accepted and the master design is updated 310. The clients can then be synchronized with the master design 312.
The following comprise examples of how edits can be detected:
In one embodiment of the invention is a shared editing system, as illustrated in
For purposes of illustration, it is assumed that the entire board comprises shared areas such that each of the users on the clients 202, 204, 206 can simultaneously edit and view objects in the entire master design 116, subject to access rights, discussed below. It is also contemplated that shared areas may comprise a subset of areas on a master design 116, such that the master design 116 comprises both shared and exclusive areas. In this latter scenario, edits to the master design 116 in exclusive areas are validated by a corresponding client conflict checking and resolution module; and edits to the master design 116 in shared areas may be validated by a corresponding client conflict checking and resolution module, a server conflict checking and resolution module, or both.
In
In one embodiment, the master design 216 comprises master design 116 on a client, such as on a thin client (i.e., client having minimal processing resources), where all edit requests are submitted to the server 200. In this embodiment, the server 200 performs all conflict checking and resolution operations to determine whether the edit requests are acceptable, to be discussed.
In another embodiment, master design 216 comprises a copy of the master design 116 in a client's memory space. In this embodiment, conflict checking and resolution operations may be performed by a processor 504 on the server 200 alone, on a processor 500 by the client 202 alone, or may be distributed in various proportions between the respective processors of a given client 202, 204, 206, and the server 200. These are described in more detail below.
Access Rights
In general embodiments of the invention, each user has access to the same aspects of the master design as any other user, subject to assignment restrictions (discussed below in “Distributed PCB Design”). In one embodiment, all users have the same access rights. For example, a first user may request edits to the same objects and commands as a second user. In another embodiment, access rights of each user may differ. For example, a first user may only request edits to components, and a second user may only request edits to routes.
Conflict Checking and Resolution
When an edit request is received, conflict checking and resolution operations are performed. Conflict checking comprises checking to prevent edits that violate one or more design rules. Design rules ensure that the design adheres to a predetermined set of rules in order to minimize the probability of fabrication defects. A design rule checker may check for spacing violations, geometry violations, and connectivity violations, for example. For example, when two traces are placed next to each other that are closer than a spacing rule, a design rule violation occurs.
Conflict resolution comprises detecting edits that may conflict, but which may be resolved. For example, if two traces are too close and violate a design rule, then one trace can be moved to resolve the conflict.
As illustrated in
If the conflict can be resolved, or if there are no conflicts, then the client conflict checker and resolution module 600 sends the edit request to the server conflict checker and resolution module 602 of the server 200 to determine if any conflicts exist with the master design 116 on the server.
If conflicts exist, then the server conflict resolution module 602 may determine if the conflicts may be resolved. If no conflicts exist, then the edit requests are accepted, and a merger unit 604 of the server 100 applies the edit requests into the master design data structure.
A synchronizer 606 of the server 200 then synchronizes the one or more clients 202, 204, 206 with the compiled master design 116. Synchronizing may comprise, for example, sending master design 116 to a single client upon request from the client; broadcasting master design 116 to all or multiple clients upon request from multiple clients; automatically swapping out a client copy of the master design data structure 216 on each of the clients 202, 204, 206 for the updated master design data structure 116 on the server 200 upon updating the master design; or automatically updating the clients' 202, 204, 206 displays upon updating the master design 116. Of course, these examples do not comprise an exhaustive list.
When conflict checking and resolution exist in isolation, either the server performs all conflict checking and resolution; or each client performs all conflict checking and resolution. The server may perform all conflict checking and resolution operations when, for example, clients are thin clients (i.e., clients having minimal processing resources), and the master design 216 on client comprises master design 116, where edit requests are submitted to the server 200. Clients may perform all conflict checking and resolution when, for example, a master design is partitioned and assigned to individual users such that no inter-client conflicts arise during editing (to be discussed in Distributed PCB Design). In this latter scenario, where edits are made in their respective exclusive areas, if any conflicts still exist after those edits are made (residual conflicts), the server may perform conflict checking and resolution operations. However, this is not necessary, as the residual conflicts may be taken care of after the edits have been applied.
When a server performs conflict checking and resolution, in cooperation with the client, or in isolation, the server may implement optimization functions to minimize its workload. For example, it may keep track of which client made the previous edit request that was merged so that if the next edit request comes from the same client, the server knows that it can eliminate certain conflict checking and resolution functions.
Example Shared PCB Editing Environment
Each printed circuit board design may have an associated design team. Members of the team are given access permission to the design data. A team member can start a design session on the server from a single client. Additional clients can then join the session. After the design is initially loaded on the server, each client is initialized and synchronized when joining the session. In particular, the current state of the design is downloaded from the server into the client memory. Once a client has joined the design session, a client user may request edits to the design using standard editing tools available in an application executing on the client.
Processing by the server is based upon edit events. An edit event is a discrete action by a client that is captured at the client and sent to the server as an edit request. For example, moving a component from point A to point B could constitute an edit event. In some embodiments, such an event automatically begins with the selection of a component and ends with a mouse click, mouse button release, coordinate entry indicating a new component location, or other design action using an editing tool in a client application. The client sends the edit request to the server as a transaction describing what is to be deleted, added and/or otherwise modified in the master design. As previously described, the client may perform a local design rule check (DRC) before transmitting an edit request to the server.
Upon transmission of the edit request to the server, and as shown in
The client making an edit request does not treat the edit event as completed until the server broadcasts the synchronization message to all clients. This means that when, e.g., the original client clicks the mouse to complete an edit event, the edit is not confirmed graphically or otherwise until the confirmation notification and data update is sent to all clients to synchronize the clients with the server database. For example, the edit may be shown in a different color on the requesting user's display until confirmation notification is received.
In at least some embodiments, most computer processing occurs at clients. Objects are added, edited and deleted at the clients, and any automation associated with those edits is performed, such as push and shove (i.e., automatically moving objects or groups of objects), glossing (eliminating superfluous routes and other objects), etc. The server has a relatively light load compared to the clients and is unlikely to cause delays and/or other performance problems.
Conflict Prevention
To avoid conflicts from occurring in the first place, a number of conflict prevention mechanisms may be employed. One mechanism that can be used to prevent conflicts is the use of protection boundaries as illustrated in
As illustrated in
The current location within design 1700 of the cursor controlled by User A is represented as a “+” symbol labeled “User A.” A circle around the User A cursor represents the force field width for User A. In other words, the region (or zone) inside the User A circle represents a portion of design 1700 that is protected from editing by other users having a lower priority than User A (user priority is described below). If a lower priority user attempts to edit within the protected zone of User A, that lower priority user receives a message indicating the edit is not permitted (e.g., a text message, a flashing cursor and/or other graphical indicator, etc.). Alternatively, in some embodiments, User A could be informed that a lower priority user is attempting to edit within the protected zone; User A could then be provided an opportunity to accept or reject that specific edit and/or an opportunity to accept or reject other edits from that user. The current location within design 1700 of the User B cursor is similarly shown as another “+” symbol labeled “User B,” with a corresponding circle indicating the extent of the protected zone for User B. In at least some embodiments, each user's cursor and protected zone is shown in a different color.
As seen in
At multiple times during an editing session, the client uses the cell weights to calculate the priority and protected zone size for the user based on the current position of the user's cursor. An example calculation is demonstrated in
In particular, the client first calculates weight sums for each of the four corners of the cell containing the cursor location (cell 1900 in the current example). As seen in
P(x, y)=(1−q)(1−r)Wcorner 1+(q)(1−r)(Wcorner 2)+(q)(r)(Wcorner 3)+(1q)(r)(Wcorner 4),
where P(x, y) is the priority at cursor location (x, y),
Wcorner 1 is the sum of cell weights for the twelve cells closest to corner 1,
corner 1 is the lower left corner of the cell containing location (x, y) and has coordinates (x1,y1),
Wcorner 2 is the sum of cell weights for the twelve cells closest to corner 2,
corner 2 is the lower right corner of the cell containing location (x, y) and has coordinates (x2,y2),
Wcorner 3 is the sum of cell weights for the twelve cells closest to corner 3,
corner 3 is the upper right corner of the cell containing location (x, y) and has coordinates (x2,y2),
Wcorner 4 is the sum of cell weights for the twelve cells closest to corner 4,
corner 4 is the upper left corner of the cell containing location (x, y) and has coordinates (x1,y2),
q=(x−x1)/(x2−x1), and
r=(y−y1)/(y2−y1).
Using Equation 1, the priority value P(4.9,5.7) for the current cursor location is 24.55.
Priority values also may be used to resolve conflicts between protected zones. If the protected zones of two or more users overlap, the user with lower priority is not allowed to edit within the higher-priority user's protected zone. For example, and as shown in
Each client calculates its priority and protected zone size, and periodically transmits these values to the server with the current cursor location on that client. The server monitors the cursor location, priority and protected zone size for each client. If a user at one client attempts to edit a portion of the design inside the protected zone of a user at another client, the server determines the relative priorities and decides whether the edit is permitted. If permitted, the edit request is processed as described above (e.g., check for design rule violations, accepted or rejected, etc.). If rejected, the user attempting the edit is notified.
So as to provide a clearer explanation of priority and protected zone size calculations, the example of
Although the preceding description provides several examples of manners by which user protected zones may be implemented, numerous variations are within the scope of the invention. As indicated above, cell weights can be increased whenever a user selects an object (or location) in a PCB design by clicking or double-clicking a mouse button. Thus, in addition to adding a new design object to a location, selecting an object for deletion, moving an object or selecting an object (without further action) can likewise increase cell weight. The triggering events for increasing cell weight can be defined in other ways (e.g., only when a new object added, only when an object added or moved, etc.). In the above-described embodiments, each client associates a cell array with the PCB design and tracks cell weights based on the activity of the user working at that client. However, the cells and cell weights for each user could be maintained by the server, or by one client for several other clients. Similarly, the priority and protected zone calculations could be performed by the server or by one client for several clients. The priority and protected zone for a cursor location could apply to all layers of a design or to less than all layers. For example, a first user could have highest priority in an (x, y) location on a first layer, and another user could have highest priority in the same (x, y) location within a second layer. In at least one embodiment, the weight for each cell is limited to 255 so that a single byte may contain the weight value. If there is activity inside the cell that would otherwise result in a weight value exceeding 255, the weight value is capped at 255. Of course, different size memory locations could be used to store weight values.
In the previous examples, the server tracks cursor location, protected zone size and priority for each user based on information received from the clients. Using this information, the server then permits or refuses edit requests within a protected zone. In other embodiments, one or more clients permit or refuse edit requests within a protected zone. When a user working at a client attempts to edit inside the protected zone of another user (working at another client), the client refuses (i.e., does not permit) the edit. In this manner, the client need not transmit an edit request to the server.
Various parameters and other aspects could also be modified. For example, each cell could be incremented by 5 or some other value for every object selection or other triggering event within the cell. Moreover, cell weights could be increased by different amounts for different types of actions, for actions by certain users and/or for actions when performing certain types of design tasks. Similarly, cell weights can be decreased using other decay rates or using other decay algorithms. In some embodiments, the protected zone for a user having a higher priority than another user who drew a protection border (
As indicated above, object locking is another mechanism that can be used for conflict prevention. Object locking entails marking one or more discrete design objects as reserved for the client that performs the locking operation and not editable by other clients. In some embodiments, the user setting the lock can give access permissions to other users. Still another mechanism that can be used for conflict prevention is the assignment of netlines to autorouters. Assigning netlines to autorouters prevents one autorouter from routing the same netline differently.
Distributed PCB Design
Like prior art systems, each user is assigned a unique piece 910, 912, 914 of the master design 116 to work on. However, unlike prior art systems, a user can view the edits to the other pieces of the design being performed by other users concurrently with the user's editing session. For example, exclusive area 910 may correspond to a user on client 202, such that user on client 202 may edit exclusive area 910. User on client 202 is able to edit exclusive area 910, and is also able to view exclusive areas 912, 914 to view the compiled master design.
Partitioning
Partitioning is the process whereby a design is segregated into a plurality of areas. Partitioned areas may then be assigned to users, such that only an assigned user may edit that area. An exclusive area, with respect to a given user who is assigned to the exclusive area, can only be edited by the given user. The exclusive area with respect to any other user can only be viewed (i.e., is read-only) by other users. In certain embodiments, access rights can be defined so that a portion of a design is exclusive as to a group of users (e.g., the exclusive area is a shared area as to that user group). In other words, certain users may edit within that portion and other users may not.
The area boundaries may be arbitrary, and are not bound to the schematic boundaries. Partitioning may be performed by specific drawing tools that create polygons and can assign attributes such as a name, an owner, etc. to each exclusive area.
In embodiments of the invention, an owner of a design partitions a design into a plurality of sections. For example, as illustrated in
When a section is assigned to a user or group of users, the section becomes an exclusive area. An exclusive area is not available for editing by other users not within the assignee group, but is available for viewing by those non-assignee users. An exclusive area may be explicitly assigned whereby the owner of the design specifically assigns a given area to a specific user, or an exclusive area may be implicitly assigned whereby any area that is not explicitly assigned is assigned to the owner of the design by default. Alternatively, each area may be assigned an arbitrary name, and users may reserve areas by checking out exclusive areas on demand.
For purposes of illustration, it is assumed that the whole board is exclusive such that users on the clients 202, 204, 206 can simultaneously edit in assigned areas while viewing the compiled master design 116, subject to access rights, discussed supra. It is also contemplated that exclusive areas may comprise a subset of areas on a master design 116, such that the master design 116 comprises shared and exclusive areas. In this latter scenario, edits to the master design 116 in exclusive areas are validated by a corresponding client conflict checking and resolution module; and edits to the master design 116 in shared areas may be validated by a corresponding client conflict checking and resolution module, a server conflict checking and resolution module, or both.
Editing
As illustrated in
Any objects inside a corresponding exclusive area are available for editing, and any objects outside of a corresponding exclusive area are locked and not available for editing, but are read-only. Objects include but are not limited to routes, components, traces, vias, text, and drawing objects, for example.
Placement Rules
Placement and clearance rules help prevent conflicts that may arise during design of a section. For example, since exclusive areas may have layer restrictions, it is possible for a component, a via, a thruhole pin, or a part to exist in multiple exclusive areas. Any object that exists in multiple areas should be locked. An object that would traverse multiple areas (by existing on multiple layers that are assigned to different users) should be prevented from being added.
Furthermore, as illustrated in
Spacing violations may occur when traces are placed too closely to one another. (See Conflict Checking and Resolution, discussed supra.) Spacing violations are likely to occur along the boundary of two sections, or within an exclusive area. As illustrated in
There are various other possibilities for placement and clearance rules that are well known in the art and are not further discussed herein. The examples provided are for illustrative purposes only and are not intended to be limiting on embodiments of the invention.
Flowcharts
At block 1404, one or more edit requests are received from multiple users. At block 1406, a given edit request is processed. In one embodiment, an edit request is processed by subjecting the edit request to client conflict checking and resolution, prior to submitting the edit request to the server for server conflict checking and resolution, if needed. In another embodiment, the edit request is directly submitted to the server for server conflict checking and resolution.
At block 1408, it is determined if the edit request has been accepted. If the edit request passes conflict checking and resolution, then it is accepted. Otherwise, the edit request is rejected. If the edit request is accepted, then at block 1412, the master design is updated, and clients are synchronized with master design at block 1414. If the edit request is rejected, it is reported as an error to the appropriate client at block 1410. The method ends at block 1416.
Conclusion
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
For example, a master design 116 may be partitioned into areas, and the areas may then be designated as shared or exclusive, such that both shared and exclusive areas comprise sections. The protected zones described in connection with
This application is a continuation-in-part of U.S. patent application Ser. No. 10/780,902, filed Feb. 19, 2004 and titled “Parallel Electronic Design Automation: Shared Simultaneous Editing,” which application is a continuation of U.S. patent application Ser. No. 10/269,614, filed Oct. 10, 2002 and titled “Parallel Electronic Design Automation: Shared Simultaneous Editing” (now U.S. Pat. No. 6,708,313), which application claims the benefit of U.S. Provisional Application Ser. No. 60/341,037, filed Dec. 10, 2001. This application also claims the benefit of U.S. Provisional Application Ser. No. 60/523,697, filed Nov. 21, 2003, titled “A Revolutionary Design Technology.” All of said applications are hereby incorporated by reference in their entireties.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5107443 | Smith | Apr 1992 | A |
| 5258920 | Haller et al. | Nov 1993 | A |
| 5333312 | Wang | Jul 1994 | A |
| 5333315 | Saether et al. | Jul 1994 | A |
| 5333316 | Champagne et al. | Jul 1994 | A |
| 5392400 | Berkowitz | Feb 1995 | A |
| 5452218 | Tucker et al. | Sep 1995 | A |
| 5544067 | Rostoker et al. | Aug 1996 | A |
| 5555388 | Shaughnessy | Sep 1996 | A |
| 5583993 | Foster et al. | Dec 1996 | A |
| 5604680 | Bamji et al. | Feb 1997 | A |
| 5745747 | Chang et al. | Apr 1998 | A |
| 5806058 | Mori et al. | Sep 1998 | A |
| 5809240 | Kumagai | Sep 1998 | A |
| 5826265 | Van Huben et al. | Oct 1998 | A |
| 5892900 | Ginter et al. | Apr 1999 | A |
| 5950201 | Van Huben et al. | Sep 1999 | A |
| 5966707 | Van Huben et al. | Oct 1999 | A |
| 5983277 | Heile et al. | Nov 1999 | A |
| 6023565 | Lawman et al. | Feb 2000 | A |
| 6026230 | Lin et al. | Feb 2000 | A |
| 6094654 | Van Huben et al. | Jul 2000 | A |
| 6094658 | Araki | Jul 2000 | A |
| 6110213 | Vinciarelli et al. | Aug 2000 | A |
| 6110223 | Southgate et al. | Aug 2000 | A |
| 6134705 | Pedersen et al. | Oct 2000 | A |
| 6182115 | Cuomo et al. | Jan 2001 | B1 |
| 6289254 | Shimizu et al. | Sep 2001 | B1 |
| 6327594 | Van Huben et al. | Dec 2001 | B1 |
| 6356796 | Spruiell et al. | Mar 2002 | B1 |
| 6424959 | Bennett et al. | Jul 2002 | B1 |
| 6484177 | Van Huben et al. | Nov 2002 | B1 |
| 6530065 | McDonald et al. | Mar 2003 | B1 |
| 6578174 | Zizzo | Jun 2003 | B2 |
| 6594799 | Robertson et al. | Jul 2003 | B1 |
| 6654747 | Van Huben et al. | Nov 2003 | B1 |
| 6671699 | Black et al. | Dec 2003 | B1 |
| 6678871 | Takeyama et al. | Jan 2004 | B2 |
| 6678876 | Stevens et al. | Jan 2004 | B2 |
| 6678877 | Perry et al. | Jan 2004 | B1 |
| 6687710 | Dey | Feb 2004 | B1 |
| 6708313 | Pfeil et al. | Mar 2004 | B2 |
| 6717718 | Kelsoe et al. | Apr 2004 | B1 |
| 6721922 | Walters et al. | Apr 2004 | B1 |
| 6751781 | Lin et al. | Jun 2004 | B2 |
| 6782511 | Frank et al. | Aug 2004 | B1 |
| 6851094 | Robertson et al. | Feb 2005 | B1 |
| 6851100 | You et al. | Feb 2005 | B1 |
| 6931369 | Perry et al. | Aug 2005 | B1 |
| 6983434 | Frank et al. | Jan 2006 | B1 |
| 7024433 | Arai et al. | Apr 2006 | B2 |
| 7036101 | He et al. | Apr 2006 | B2 |
| 7039892 | Mantey et al. | May 2006 | B2 |
| 7076491 | Tsao | Jul 2006 | B2 |
| 7103434 | Chernyak et al. | Sep 2006 | B2 |
| 7134096 | Brathwaite et al. | Nov 2006 | B2 |
| 7143134 | Petrie et al. | Nov 2006 | B2 |
| 7143341 | Kohli | Nov 2006 | B1 |
| 7219311 | Koga et al. | May 2007 | B2 |
| 7240309 | Saito et al. | Jul 2007 | B2 |
| 7246055 | Singh | Jul 2007 | B1 |
| 20020059054 | Bade et al. | May 2002 | A1 |
| 20020069220 | Tran | Jun 2002 | A1 |
| 20020120858 | Porter et al. | Aug 2002 | A1 |
| 20020144212 | Lev et al. | Oct 2002 | A1 |
| 20020188910 | Zizzo | Dec 2002 | A1 |
| 20030009727 | Takeyama et al. | Jan 2003 | A1 |
| 20030101425 | Makinen | May 2003 | A1 |
| 20030131332 | Pfeil et al. | Jul 2003 | A1 |
| 20040093397 | Chiroglazov et al. | May 2004 | A1 |
| 20040199891 | Bentley et al. | Oct 2004 | A1 |
| 20040210854 | Pfeil et al. | Oct 2004 | A1 |
| 20040225988 | Petunin et al. | Nov 2004 | A1 |
| 20040268283 | Perry et al. | Dec 2004 | A1 |
| 20050080502 | Chernyak et al. | Apr 2005 | A1 |
| 20050108663 | Bentley et al. | May 2005 | A1 |
| 20050114821 | Petunin et al. | May 2005 | A1 |
| 20050125763 | Lin et al. | Jun 2005 | A1 |
| 20050131783 | Jin | Jun 2005 | A1 |
| 20050160396 | Chadzynski | Jul 2005 | A1 |
| 20050237776 | Gropper et al. | Oct 2005 | A1 |
| 20050246672 | Bois et al. | Nov 2005 | A1 |
| Number | Date | Country |
|---|---|---|
| 0750267 | Jun 1995 | EP |
| 02-048774 | Feb 1990 | JP |
| 02-056070 | Feb 1990 | JP |
| 02-245865 | Oct 1990 | JP |
| 04-068470 | Mar 1992 | JP |
| 04-362783 | Dec 1992 | JP |
| 05-073630 | Mar 1993 | JP |
| 05-74942 | Mar 1993 | JP |
| 05-242174 | Sep 1993 | JP |
| 06203108 | Jul 1994 | JP |
| 07-175842 | Jul 1995 | JP |
| 08-235233 | Sep 1996 | JP |
| 09-62726 | Mar 1997 | JP |
| 09-212530 | Aug 1997 | JP |
| 09-288690 | Nov 1997 | JP |
| 10-105586 | Apr 1998 | JP |
| 10-307855 | Nov 1998 | JP |
| 11-288428 | Oct 1999 | JP |
| 2003-186914 | Jul 2003 | JP |
| 03050726 | Jun 2003 | WO |
| 03050751 | Jun 2003 | WO |
| WO 03050726 | Jun 2003 | WO |
| 2003088095 | Oct 2003 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20050044518 A1 | Feb 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60523697 | Nov 2003 | US | |
| 60341037 | Dec 2001 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10269614 | Oct 2002 | US |
| Child | 10780902 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10780902 | Feb 2004 | US |
| Child | 10870497 | US |
