In Internet Protocol (IP) telephony, the path that the audio packets travel between endpoints generally varies. IP and switched Ethernet networks deliberately switch traffic onto specific routes, oftentimes making it difficult to use traditional passive tap techniques to record the telephony traffic. Generally speaking, as passive tap techniques access the packets somewhere between endpoints, along the route of the phone call, a passive tap has difficulty in that the data can be broken up into discrete packets, which may traverse different paths to reach the desired destination. As encryption of IP traffic becomes more widespread, passive tapping techniques become even more problematic.
Additionally, while some approaches have been implemented that use the duplication of media streams, these current techniques of creating exact (or almost exact) copies of the streams is not without drawbacks. More specifically, current techniques often require additional network capacity to facilitate communication of the duplicate streams. Additionally, the bandwidth utilized between the communications device and the recording device is often twice the bandwidth of the original call. Another drawback of the current techniques is that the packets sent to the recorder are often sent in a very inefficient manner, as echo and jitter reduction techniques are utilized, as in the original call. Further, the compression scheme in many current techniques is chosen on the basis of the network bandwidth and available bandwidth taken by the call, without regard to the path between the communications device and the recording device.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.
Included are methods for recording in an Internet Protocol (IP) environment. At least one embodiment of a method includes receiving data related to a communication, generating a copied version of at least a portion of the received data, and modifying the copied version of the received data. Other embodiments include sending at least a portion of the modified copied version of the received data to a recording device.
Also included are embodiments of a computer readable medium for recording in an Internet Protocol (IP) environment. At least one embodiment includes logic configured to receive data related to a communication, logic configured to generate a copied version of at least a portion of the received data, and logic configured to modify the copied version of the received data. Other embodiments include logic configured to send at least a portion of the modified copied version of the received data to a recording device.
Also included are embodiments of a communications device for facilitating a recording in an Internet Protocol (IP) environment. At least one embodiment includes logic configured to receive data related to a communication, logic configured to generate a copied version of at least a portion of the received data, and logic configured to modify the copied version of the received data. Other embodiments include logic configured to send at least a portion of the modified copied version of the received data to a recording device.
Other systems, methods, features, and advantages of this disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description and be within the scope of the present disclosure.
Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. While several embodiments are described in connection with these drawings, there is no intent to limit the disclosure to the embodiment or embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents.
One approach to overcome the above listed recording problems is to instruct a device that is party to the call (such as a Voice over Internet Protocol (VoIP) telephone, softphone, or other communications device) to forward copies of the data packets that the communications device is receiving and/or transmitting. In such a configuration, the communications device can send copies of the Real Time Protocol (RTP) packets associated with the call to a recorder. The destination addresses for this data are included in instructions from the recorder to the communications device.
Similarly, communications device 106b is coupled to communications network 100. Computing device 104b is also coupled to communications network 100. In this nonlimiting example, a direct connection between the communications device 106b and the computing device 104b is not utilized, as communication between these devices can be facilitated by communications network 100. In many embodiments, the implementation with communications device 106a and computing device 104a is similar in functionality as the configuration with communications device 106b and computing device 104b.
As illustrated in the nonlimiting example of
As also illustrated in
More specifically, in an exemplary embodiment, communications device 204a receives a voice communication, a visual communication, and/or a data communication (or any permutation of these and other types of communication) from a user operating communications device 204b. Communications device 204b converts the communication received from a user of communications device 204b into a plurality of packets, which generally include a header and a payload. The packets are sent individually to a destination address associated with communications device 204a, intermediate gateway, conference bridge, etc. The destination address is listed in each packet header. To increase the speed that this data is communicated to communications device 204a, each packet is configured to traverse a path of least resistance along the communications network. Because each packet traverses a path of least resistance, each packet can potentially take a different path between communications device 204b and communications device 204a.
When all (or a predetermined number) of the packets reach communications device 204a, the communications device 204a reads the packet headers to determine how to convert the payload data back to a format that is understandable to a user of communications device 204a. When a user associated with communications device 204a responds, a similar process is completed to communicate the voice to the user associated with communications device 204b. Because in such a configuration, packet data is communicated over a plurality of paths, a recording device coupled to a single path of the communications network can be problematic as a desired number of packets associated with the communication may not be received by recording device 108.
More recent attempts to implement a recording device remote from the endpoints (communications devices 204a, 204b) of a communication have included forwarding an exact duplicate of the communication to the recording device. More specifically, as packets are sent between endpoints of the communication at a predetermined rate (e.g., 20 milliseconds), an exact duplicate of this data is sent at the same rate to the recorder. Such a configuration, while overcoming many of the obstacles of passive tap recording is not without inefficiencies.
One should note that, while the nonlimiting examples of
One should also note that, depending on the particular configuration, data sent to the recorder(s) can be encrypted in any of a plurality of ways. More specifically, any of a plurality of protocols and/or any of a plurality of encryption techniques can be implemented to provide more secure data transfer.
The processor 482 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the device 106, 204, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions. Examples of suitable commercially available microprocessors are as follows: a PA-RISC series microprocessor from Hewlett-Packard® Company, an 80×86 or Pentium® series microprocessor from Intel® Corporation, a PowerPC® microprocessor from IBM®, a Sparc® microprocessor from Sun Microsystems®, Inc, or a 68xxx series microprocessor from Motorola® Corporation.
The volatile and nonvolatile memory 484 can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory 484 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the volatile and nonvolatile memory 484 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 482. Additionally, volatile and nonvolatile memory 484 can also include an operating system 486, as well as communications software 499.
The software in volatile and nonvolatile memory 484 may include one or more separate programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example of
Similarly, with respect to operating system 486, a nonexhaustive list of examples of suitable commercially available operating systems is as follows: (a) a Windows® operating system available from Microsoft® Corporation; (b) a Netware® operating system available from Novell®, Inc.; (c) a Macintosh® operating system available from Apple® Computer, Inc.; (d) a UNIX operating system, which is available for purchase from many vendors, such as the Hewlett-Packard® Company, Sun Microsystems®, Inc., and AT&T® Corporation; (e) a LINUX operating system, which is freeware that is readily available on the Internet 100; (f) a run time Vxworks® operating system from WindRiver® Systems, Inc.; or (g) an appliance-based operating system, such as that implemented in handheld computers or personal data assistants (PDAs) (e.g., PalmOS® available from Palm® Computing, Inc., and Windows CE® available from Microsoft® Corporation). The operating system 486 can be configured to control the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.
A system component embodied as software may also be construed as a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When constructed as a source program, the program is translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the volatile and nonvolatile memory 484, so as to operate properly in connection with the Operating System 486.
The Input/Output devices that may be coupled to system I/O Interface(s) 496 may include input devices, for example but not limited to, a keyboard, mouse, scanner, microphone, headset, handset, microphone, earphone, etc. Further, the Input/Output devices may also include output devices, for example but not limited to, a printer, display, etc. Finally, the Input/Output devices may further include devices that communicate both as inputs and outputs, for instance but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc.
If the communications device 106, 204 is a personal computer, workstation, or the like, the software in the volatile and nonvolatile memory 484 may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of software routines that initialize and test hardware at startup, start the Operating System, and support the transfer of data among the hardware devices. The BIOS is stored in ROM so that the BIOS can be executed when the communications device 106 is activated.
When the communications device 106 is in operation, the processor 482 is configured to execute software stored within the volatile and nonvolatile memory 484, to communicate data to and from the volatile and nonvolatile memory 484, and to generally control operations of the communications device 106 pursuant to the software. Software in memory, in whole or in part, are read by the processor 482, perhaps buffered within the processor 482, and then executed.
Once the communications device receives the recording instruction, the communications device can receive and/or create data for a communication (block 534). More specifically, this step includes the communications device receiving a voice communication (or other type, such as video, web chat, email, etc., as discussed above) from the user or data related to a voice communication from a third party (with whom the user is communicating). Once the data is created and/or received, the communications device sends a copy of the data to the third party (block 540). The communications device can then send the data to the recorder for recording (block 542).
Next, the communications device can strip the header from at least one packet (block 634). Upon stripping the header, the communications device can combine the payload from at least one stripped packet with at least one other packet (block 636). By combining two packet payloads into a single packet, the communication device can more efficiently send data to the recorder. As a nonlimiting example, if the received packet data is configured for transmission in 20 millisecond intervals, by combining two packets into one, the recorder can receive the data in roughly half the time that unrefined data would be communicated (one should note that depending on header size, the actual efficiency gains can vary).
Next, the communications device can store the refined data for subsequent communication (block 638). The data can be stored in a buffer such that payload data from a plurality of packets can be accumulated. When the buffer reaches maximum capacity, a single, larger packet can be created for subsequent transmission. The communications device can then copy the received data related to the communication (block 640). The communications device can then send unrefined data to a third party of the communications (block 642). More specifically, the communications device can further facilitate the communication by sending packetized voice data from the user to the third party, to whom the user is communicating. As one of ordinary skill in the art will understand, this step can be performed before, during, and/or after the other steps in this nonlimiting example. Next, the communications device can receive an indication of reduced network traffic (block 644). Upon receiving the indication of reduced network traffic, the communications device can send the refined data to the recorder (block 646).
One should note that other embodiments may provide that any component within the IP telephone network through which some or all of the audio content of a call passes is configured to process and record media streams. This can include trunk interface cards, conference bridges, voicemail and other servers, routing components trans-coding components etc. Additionally, in still other embodiments, the communications device can, if instructed, merge the two data streams (incoming and outgoing data streams) into a single data stream. This may be accomplished by encapsulating a pair of packets (such as RTP packets) inside a User Datagram Protocol (UDP) payload. Many techniques place two RTP packets in the payload of a UDP packet, preceded by two by 16 bit length fields indicating the length of each RTP packet. At least one embodiment of the present disclosure includes removing the redundant information in the RTP packet header (e.g., the source of one is the destination of the other).
Next, the communications device can compress the copied data (block 736). The compression can take the form of G729A, G711, or other compression format. Once the data is compressed, the communications device can store the compressed data (block 738) for subsequent delivery. The communications device can send the uncompressed data to the third party (to whom the user is communicating), as illustrated in block 740. Then, the communication device can receive an indication of reduced network traffic (block 742) and send the compressed data to the recorder (block 744).
One should note that since the recording device is generally a receive-only device, echo is generally not a concern when recording. Therefore, there is generally no hard real-time requirement on transmission time or jitter. Hence at least one embodiment of the communications device can be configured support an option to send traffic to the recorder as “data” rather than “real-time” packets (e.g. if using Quality of Service graded networks, the traffic to the recording device need not be marked as requiring rapid delivery). This allows the recorder traffic to co-exist on limited bandwidth networks with the real VoIP traffic and not degrade the service experienced by the VoIP calls. The communications device is configured to send traffic at times of reduced network traffic, thereby giving priority to the real-time voice traffic.
Additionally, embodiments of the communications device can, if instructed, forward packets containing mixed audio of the transmitted and received streams. As the communications device can be configured to decompress incoming packets and is responsible for any compression of outgoing packets, the communications device may already have access to the uncompressed audio and hence can mix these data streams (as the communications device does when applying side-tone to the received audio the communications device plays via the ear piece). Instead of forwarding the raw contents of the RTP packets, the communications device can be configured to take (a) audio that has been converted into linear form and ready for output to the handset/speaker and (b) audio the communications device has collected from the microphone and is in linear format prior to compression. The communications device can be configured to add (a) and (b) together to provide the mixed audio signal. The communications device can then compress this mixed data (using the compression format, if any, requested by the recorder) and place this in RTP packets for transmission to the recorder. Further, as communications devices generally support a range of compression formats, and with Digital Signal Processing (DSP) power increasing to the point where there is spare processing power available, the communications device can be instructed to compress the audio (whether split or mixed) before packetizing and sending the audio data to the recorder. As a lower quality of audio is often acceptable in a recording than in a live call, a more aggressive compression format is applied to the recorded stream than was applied to the original audio. This can result in reduced bandwidth consumption during recording.
One should also note that rather than forward RTP packets to the recorder, at least one embodiment of the communications device can be configured to support the establishment of a reliable connection to the recorder (e.g. full TCP/IP socket connection). This allows the packets being sent to the recorder (a) to be received reliably with retransmission being handled by the TCP stack (a critical requirement in some recording applications) and (b) allows this recording stream to traverse the network at a lower Quality of Service threshold than the VoIP calls. This means that the network does not have to be capable of supporting the sum of live plus recorded traffic at the same high quality generally utilized in VoIP calls. Additionally, embodiments of the communications device are configured to establish contact with the recorder and accept subsequent instructions (e.g. start/stop, mix, compress, buffer) directly from the recorder, rather than having these commands delivered via the other components of the telephone system. Still other embodiments of the communications device are configured to support multiple concurrent and independent requests for forwarding/copying/buffering of data from multiple recorders. This allows, as a nonlimiting example, live monitoring and recording concurrently. The communications device can be configured to perform the forwarding operation as many times and to as many different addresses as requested. This also works well for live backups (where recordings are sent to two different locations in real time) These techniques are often more secure than having one recorder store the data and then copy that data to another location.
This technique can usefully exploit the normally spare bandwidth that may be available between a satellite site and the backup parent site (i.e., WAN designed to have traffic communicated from A to B but has additional capacity to communicate data from A to C to allow continued operation in the event of failure of site B. This bandwidth is often otherwise unused and it may be desirable for A to send data to both B and C than to have the data copied from B to C at a later time.
In addition to sending audio content of the communication, embodiments of the communications device may also be configured to receive requests to forward details of the quality of the call, derived, for example, from the Real Time Control Protocol (RTCP) packets exchanged with the remote party on the call. In addition to sending the audio content of the communication, the communications device may also be forwarded details of the call. Information available to the communications device, whether made visible to the user or not, can be forwarded to the recorder. Additionally, embodiments of the communications device can be configured to forward details of the user's interaction with the communications device and the recorder. As a nonlimiting example, embodiments of the communications device can be configured to forward data such as speed of dialing, time when the communications device goes off-hook, etc. (i.e. events that do not form part of the normally recorded call).
Also included within the scope of this disclosure is packet loss detection and analysis. By analyzing the sequence numbers and timestamps of the RTP packets, one can determine the proportion of packets have been lost. Alarms can be raised should this exceed an acceptable threshold. Where two streams are sent from a device (those the device received and those the transmitted), it is possible to determine from the loss characteristics whether packet loss is occurring between the recorder and the device performing the duplication (in which case losses on the two streams should be comparable) or between the two devices engaged in the original communication (in which cases losses are heavier on one stream—that duplicating the packets received by the forwarding device—than on the other).
Additionally included within the scope of this disclosure is quantification of packet transmission statistics. In addition to forwarding the packets (such as RTP packets), if the forwarding device can also be configured to forward the RTCP packets sent that relate to the original RTP link. The recorder can analyze this data to determine the quality of transmission between the original parties on the call. If RTCP is exchanged between the recorder and the forwarding device, it can determine the quality of that link. An overall quality level for the recording can therefore be determined. Where RTCP packets are forwarded, these can be wrapped inside a protocol and buffered with the RTP streams so as not to use much additional bandwidth or sockets en route to the recorder.
One should also note that the flowcharts included herein show the architecture, functionality, and operation of a possible implementation of software. In this regard, each block can be interpreted to represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
One should note that any of the programs listed herein, which can include an ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a nonexhaustive list) of the computer-readable medium could include an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). In addition, the scope of the certain embodiments of this disclosure can include embodying the functionality described in logic embodied in hardware or software-configured mediums.
It should be emphasized that the above-described embodiments are merely possible examples of implementations, merely set forth for a clear understanding of the principles of this disclosure. Many variations and modifications may be made to the above-described embodiment(s) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure.
Number | Name | Date | Kind |
---|---|---|---|
3594919 | De Bell et al. | Jul 1971 | A |
3705271 | De Bell et al. | Dec 1972 | A |
4510351 | Costello et al. | Apr 1985 | A |
4684349 | Ferguson et al. | Aug 1987 | A |
4694483 | Cheung | Sep 1987 | A |
4763353 | Canale et al. | Aug 1988 | A |
4815120 | Kosich | Mar 1989 | A |
4924488 | Kosich | May 1990 | A |
4953159 | Hayden et al. | Aug 1990 | A |
5016272 | Stubbs et al. | May 1991 | A |
5101402 | Chiu et al. | Mar 1992 | A |
5117225 | Wang | May 1992 | A |
5210789 | Jeffus et al. | May 1993 | A |
5239460 | LaRoche | Aug 1993 | A |
5241625 | Epard et al. | Aug 1993 | A |
5267865 | Lee et al. | Dec 1993 | A |
5299260 | Shaio | Mar 1994 | A |
5311422 | Loftin et al. | May 1994 | A |
5315711 | Barone et al. | May 1994 | A |
5317628 | Misholi et al. | May 1994 | A |
5347306 | Nitta | Sep 1994 | A |
5388252 | Dreste et al. | Feb 1995 | A |
5396371 | Henits et al. | Mar 1995 | A |
5432715 | Shigematsu et al. | Jul 1995 | A |
5465286 | Clare et al. | Nov 1995 | A |
5475625 | Glaschick | Dec 1995 | A |
5485569 | Goldman et al. | Jan 1996 | A |
5491780 | Fyles et al. | Feb 1996 | A |
5499291 | Kepley | Mar 1996 | A |
5535256 | Maloney et al. | Jul 1996 | A |
5572652 | Robusto et al. | Nov 1996 | A |
5577112 | Cambray et al. | Nov 1996 | A |
5590171 | Howe et al. | Dec 1996 | A |
5597312 | Bloom et al. | Jan 1997 | A |
5619183 | Ziegra et al. | Apr 1997 | A |
5696906 | Peters et al. | Dec 1997 | A |
5717879 | Moran et al. | Feb 1998 | A |
5721842 | Beasley et al. | Feb 1998 | A |
5742670 | Bennett | Apr 1998 | A |
5748499 | Trueblood | May 1998 | A |
5778182 | Cathey et al. | Jul 1998 | A |
5784452 | Carney | Jul 1998 | A |
5790798 | Beckett, II et al. | Aug 1998 | A |
5796952 | Davis et al. | Aug 1998 | A |
5809247 | Richardson et al. | Sep 1998 | A |
5809250 | Kisor | Sep 1998 | A |
5825869 | Brooks et al. | Oct 1998 | A |
5835572 | Richardson, Jr. et al. | Nov 1998 | A |
5862330 | Anupam et al. | Jan 1999 | A |
5864772 | Alvarado et al. | Jan 1999 | A |
5884032 | Bateman et al. | Mar 1999 | A |
5907680 | Nielsen | May 1999 | A |
5918214 | Perkowski | Jun 1999 | A |
5923746 | Baker et al. | Jul 1999 | A |
5933811 | Angles et al. | Aug 1999 | A |
5944791 | Scherpbier | Aug 1999 | A |
5948061 | Merriman et al. | Sep 1999 | A |
5958016 | Chang et al. | Sep 1999 | A |
5964836 | Rowe et al. | Oct 1999 | A |
5978648 | George et al. | Nov 1999 | A |
5982857 | Brady | Nov 1999 | A |
5987466 | Greer et al. | Nov 1999 | A |
5990852 | Szamrej | Nov 1999 | A |
5991373 | Pattison et al. | Nov 1999 | A |
5991796 | Anupam et al. | Nov 1999 | A |
6005932 | Bloom | Dec 1999 | A |
6009429 | Greer et al. | Dec 1999 | A |
6014134 | Bell et al. | Jan 2000 | A |
6014647 | Nizzari et al. | Jan 2000 | A |
6018619 | Allard et al. | Jan 2000 | A |
6035332 | Ingrassia et al. | Mar 2000 | A |
6038544 | Machin et al. | Mar 2000 | A |
6039575 | L'Allier et al. | Mar 2000 | A |
6057841 | Thurlow et al. | May 2000 | A |
6058163 | Pattison et al. | May 2000 | A |
6061798 | Coley et al. | May 2000 | A |
6072860 | Kek et al. | Jun 2000 | A |
6076099 | Chen et al. | Jun 2000 | A |
6078894 | Clawson et al. | Jun 2000 | A |
6091712 | Pope et al. | Jul 2000 | A |
6108711 | Beck et al. | Aug 2000 | A |
6122665 | Bar et al. | Sep 2000 | A |
6122668 | Teng et al. | Sep 2000 | A |
6130668 | Stein | Oct 2000 | A |
6138139 | Beck et al. | Oct 2000 | A |
6144991 | England | Nov 2000 | A |
6146148 | Stuppy | Nov 2000 | A |
6151622 | Fraenkel et al. | Nov 2000 | A |
6154771 | Rangan et al. | Nov 2000 | A |
6157808 | Hollingsworth | Dec 2000 | A |
6171109 | Ohsuga | Jan 2001 | B1 |
6182094 | Humpleman et al. | Jan 2001 | B1 |
6195679 | Bauersfeld et al. | Feb 2001 | B1 |
6201948 | Cook et al. | Mar 2001 | B1 |
6211451 | Tohgi et al. | Apr 2001 | B1 |
6225993 | Lindblad et al. | May 2001 | B1 |
6229887 | Albers et al. | May 2001 | B1 |
6230197 | Beck et al. | May 2001 | B1 |
6236977 | Verba et al. | May 2001 | B1 |
6244758 | Solymar et al. | Jun 2001 | B1 |
6282548 | Burner et al. | Aug 2001 | B1 |
6286030 | Wenig et al. | Sep 2001 | B1 |
6286046 | Bryant | Sep 2001 | B1 |
6288753 | DeNicola et al. | Sep 2001 | B1 |
6289340 | Puram et al. | Sep 2001 | B1 |
6301462 | Freeman et al. | Oct 2001 | B1 |
6301573 | McIlwaine et al. | Oct 2001 | B1 |
6324282 | McIllwaine et al. | Nov 2001 | B1 |
6347374 | Drake et al. | Feb 2002 | B1 |
6351467 | Dillon | Feb 2002 | B1 |
6353851 | Anupam et al. | Mar 2002 | B1 |
6360250 | Anupam et al. | Mar 2002 | B1 |
6370574 | House et al. | Apr 2002 | B1 |
6404857 | Blair et al. | Jun 2002 | B1 |
6411989 | Anupam et al. | Jun 2002 | B1 |
6418471 | Shelton et al. | Jul 2002 | B1 |
6459787 | McIlwaine et al. | Oct 2002 | B2 |
6487195 | Choung et al. | Nov 2002 | B1 |
6493758 | McLain | Dec 2002 | B1 |
6502131 | Vaid et al. | Dec 2002 | B1 |
6510220 | Beckett, II et al. | Jan 2003 | B1 |
6535909 | Rust | Mar 2003 | B1 |
6542602 | Elazar | Apr 2003 | B1 |
6546405 | Gupta et al. | Apr 2003 | B2 |
6560328 | Bondarenko et al. | May 2003 | B1 |
6583806 | Ludwig et al. | Jun 2003 | B2 |
6606657 | Zilberstein et al. | Aug 2003 | B1 |
6665644 | Kanevsky et al. | Dec 2003 | B1 |
6668044 | Schwartz et al. | Dec 2003 | B1 |
6674447 | Chiang et al. | Jan 2004 | B1 |
6683633 | Holtzblatt et al. | Jan 2004 | B2 |
6697858 | Ezerzer et al. | Feb 2004 | B1 |
6724887 | Eilbacher et al. | Apr 2004 | B1 |
6738456 | Wrona et al. | May 2004 | B2 |
6757361 | Blair et al. | Jun 2004 | B2 |
6772396 | Cronin et al. | Aug 2004 | B1 |
6775377 | McIlwaine et al. | Aug 2004 | B2 |
6792575 | Samaniego et al. | Sep 2004 | B1 |
6810414 | Brittain | Oct 2004 | B1 |
6820083 | Nagy et al. | Nov 2004 | B1 |
6823384 | Wilson et al. | Nov 2004 | B1 |
6870916 | Henrikson et al. | Mar 2005 | B2 |
6901438 | Davis et al. | May 2005 | B1 |
6959078 | Eilbacher et al. | Oct 2005 | B1 |
6965886 | Govrin et al. | Nov 2005 | B2 |
6987849 | Ravishankar | Jan 2006 | B2 |
20010000962 | Rajan | May 2001 | A1 |
20010032335 | Jones | Oct 2001 | A1 |
20010043697 | Cox et al. | Nov 2001 | A1 |
20020038363 | MacLean | Mar 2002 | A1 |
20020052948 | Baudu et al. | May 2002 | A1 |
20020064149 | Elliott et al. | May 2002 | A1 |
20020065911 | Von Klopp et al. | May 2002 | A1 |
20020065912 | Catchpole et al. | May 2002 | A1 |
20020128925 | Angeles | Sep 2002 | A1 |
20020143925 | Pricer et al. | Oct 2002 | A1 |
20020165954 | Eshghi et al. | Nov 2002 | A1 |
20030055883 | Wiles et al. | Mar 2003 | A1 |
20030079020 | Gourraud et al. | Apr 2003 | A1 |
20030144900 | Whitmer | Jul 2003 | A1 |
20030154240 | Nygren et al. | Aug 2003 | A1 |
20040100507 | Hayner et al. | May 2004 | A1 |
20040165717 | Mcllwaine et al. | Aug 2004 | A1 |
20040208165 | Cai et al. | Oct 2004 | A1 |
20050138560 | Lee et al. | Jun 2005 | A1 |
20060227721 | Hirai et al. | Oct 2006 | A1 |
20070053373 | FitzGerald et al. | Mar 2007 | A1 |
20070091789 | Thukral | Apr 2007 | A1 |
20070104096 | Ribera | May 2007 | A1 |
20070180137 | Rajapakse | Aug 2007 | A1 |
20070183415 | Fischer et al. | Aug 2007 | A1 |
20080267140 | Lee et al. | Oct 2008 | A1 |
Number | Date | Country |
---|---|---|
0453128 | Oct 1991 | EP |
0773687 | May 1997 | EP |
0989720 | Mar 2000 | EP |
2369263 | May 2002 | GB |
WO 9843380 | Nov 1998 | WO |
WO 0016207 | Mar 2000 | WO |
Number | Date | Country | |
---|---|---|---|
20070258434 A1 | Nov 2007 | US |