Patent Grant
9192008
The use of LEDs in the production of wash lighting units provide the capabilities to create a wide range of colors that can be controlled by a centralized control system. However, if a wide range of colors are not needed, cost can be reduced based on providing modules that have a more limited range of colors.
A small and efficient modular light-emitting diode (LED) washlight component that is usable in, e.g., a vehicle, such as an aircraft is provided comprising a direct DC power input. This design relates to designs disclosed in the following U.S. patent applications, all of which are incorporated herein by reference:
The following is a table of acronyms which may be used in the discussion below.
As described in more detail below, a light-emitting diode (LED) light module is provided, comprising: a single-piece printed circuit board (PCB) comprising the following integrated on the PCB: a plurality of LEDs in each of a plurality of LED groups; a power supply converter; a controller module comprising a processor, memory, operational program stored in the memory and executable by the processor; input/output (I/O) circuitry, and an LED driver that drives the LEDs; the module further comprising: a single metallic housing that contains the PCB; a heat sink that conducts heat from components on the PCB to the housing; and a lens for diffusing or directing lights from the LEDs.
The invention is explained below according to various embodiments illustrated in the drawing figures and discussed in the Detailed Description section:
Referring to
The component module comprises one or more printed circuit boards (PCB) 14 that includes a power supply 20, module controller 32, and LEDs 40. In an embodiment, the LEDs 40 are arranged in a linear array across the PCB(s), and, e.g., in a red, green, blue (RGB)+white configuration. The power supply 20 and module controller 32 can be integrated together. The power supply 20 can be designed to run based on 28 VDC, but should be able to operate over a range, e.g., from 18 VDC to 30.3 VDC. Since the input to the module is DC, there need only be a single power supply, a single DC switch, and it is not necessary to have an isolated design—the power supply can be referenced to the aircraft chassis. The system is designed to consume approximately 6 Watts per foot. Appropriate filtering 35 (
The module 10 may comprise a thermal management system coupled with a thermal heat sinking design. The module 10 may comprise a temperature sensor that monitors the internal temperature of the module 10 and regulates LED PWM duty cycles to maintain an optimal operating temperature and calibrated light output within LRU temperature specifications.
In addition, this module may have a lens 50 that can be used to direct or diffuse the light. In one embodiment, the lens is made in a manner, such as a using micro-structured features, that direct the light in a single direction.
The lighting LRUs 10 may utilize a building block architecture approach where like components are utilized across cabin applications to minimize part count and maintain functionality within the system. The integrated LED, power supply and control (ILDC) board 30 may be mounted within a single aluminum extrusion. This architecture is capable of being built upon to utilize multiple ILDC PCBs 40 within a single housing 12, passing 28VDC through jumper boards 15 (
This architecture is designed to adapt various, custom optics to specific airplane applications. This allows optimization of mixing and beam patterns as well as lumen output. Conceptually, application specific LRUs and lighting assemblies 10 are able to utilize a host of extruded lens types 50 from collimator to asymmetric in order to meet system photometric requirements. Wash light LRU's 10 may be equipped with end-caps/connectors optimized for this application and can include harnessing/connector options as required by a particular application.
The ILDC 30 electrical hardware may comprise a power supply section 20, logic and control section 32 and LED modules 40. The power supply section 20, control and logic section 32, may comprise two main building blocks and seven sub blocks. The two main blocks, as illustrated in
The power conversion/supply section 20 incorporates DC to DC conversion 37 and filtering 35 that fits in a streamlined form factor and housing.
The DC to DC power supply 37 design utilizes a buck converter topology, capable of maintaining LRU operation within the 18 to 32 VDC range. The purpose of the power supply is to provide the output voltages for driving and controlling LED's, logic/memory 42 and I/O 44 for communications and addressing.
There are four main logic blocks required in the ILDC 30. The CPU (microcontroller & memory) 42, I/O (token and RS-485) 44, LED control/driver 46, and Self test/control are the four blocks and are shown in
The CPU block 42 may comprise a precision oscillator, a low dropout regulator and a microcontroller that has the necessary memory/code space for a boot sector, operational firmware, configuration data (such as address and zone), and calibration data unique to a particular Lighting LRU, such as color points, LRU type and board length. The microcontroller is essentially the brain used to run all the functions of the IPSC board and other I/O functions.
One of the primary tasks of the microcontroller (MCU) 42 is to control the LED's. Their drive current, duty cycle and color mixing algorithms are all processed in real time within the MCU. The secondary function is to interface with the cabin management system (CMS) via RS-485. RS485 communication is processed and scene requests are decoded within the MCU via an RS-485 transceiver. This scene information may be used to extract the correct PWM values from memory, which are processed via algorithms that calculate LED pulse width based on temperature compensation, transition interval, calibration constants, and aging compensation.
The I/O “Input/Output” block 44 illustrates how the unit may connect to the outside world. RS-485 is an exemplary communication protocol and physical layer interface to the Lighting LRU 10. These commands are received from the CMS. The RS-485 transceiver may have numerous protection devices such as ESD protection and failsafe “float when damaged” operation. Each wash light LRU 10 has its own logical address which is configured by a Token In/Out scheme. The token may be an isolated pull down that is used during system configuration. This advantage gives each wash LRU 10 its address based on position within the aircraft rather than serial number.
The LED driver 46 chosen has high pulse width resolution, low temperature drift and stable current drive vs. voltage. Preferably, an LED driver 46 that is fully configurable in software is used. This enables the use of a single ILDC part number which can support multiple board lengths and configurations.
The last block in the logic section of the ILDC is the self-test and control 48. In this block 48, the power supply voltage and temperature are monitored. The temperature data may be used to either control LED duty cycle for flux compensation or shutdown the unit in a safe manner if there is a failure causing overheating. The voltage data lets the unit disable the LEDs 40 during a temporary power drop. The advantage of this is that the CPU block has enough power to store current scene selection data and recover rapidly when the power returns. This allows lighting control units time to reboot and reset the scene or transition to a new scene if needed.
An RGB+W wash light 10 may conform to the following specifications and use the following exemplary components:
Table 2 below presents the estimated power and weight for the baseline lighting system. The exact configuration and quantity of LRUs can be refined in order to accurately address weight and power.
Each wash light LRU 10 may include the necessary power supply(s), control/address circuitry, LEDs, connectors, optics/lens, mounting hardware, software/firmware, and interface wiring/connectors for each application type, requiring no additional external controller or power supply. The lights can be powered by 28VDC, optimal, with an operational range of 18 to 32 VDC.
Wash lighting LRUs 10 may be comprised of dual sided PCB-Integrated LED and digital control boards, metal extrusions, harnesses (wiring and connectors), end caps and optical elements, as described above. The wash light LED drive scheme may include control, feedback and over temperature protection. To produce the desired color gamut, intensity and consistency of light required, a red, green, blue and white LED configuration may be used for indirect wash lighting assemblies.
LEDs 40 may be arranged in linear clusters to minimize color shadows and enhance near field mixing. The boards may be thermally coupled to aluminum housings for maximum heat transfer and dissipation. Carefully managing of the thermal loading on the LEDs improves the efficiency and maximizes the lifespan. As part of the thermal management, the LEDs may be run at less than their rated capacity. This drive current de-rating promotes life spans far exceeding those projected at manufacturer rated LED power levels.
The ILDC boards 30 may be designed with LEDs on the topside and power and control components on the bottom, in an effort to reduce size and weight. The LEDs 40 may receive a constant current pulse width source to set brightness and color points, with PWM operating frequencies of equal to or greater than 250 Hz to minimize perceived flicker. There is available headroom in the PWM drive that can be utilized as required.
Each Lighting LRU 10 may be a member of a group of multi-dropped RS-485 based units on a serial bus (
The location of the CMS should be optimized with regard to the RS-485 serial buses for both wire length and bus loading. Such a scheme will help reduce wire weight while also reducing the possibility of noise on the bus. There exists an upper limit for the number of RS-485 nodes per bus, which is, e.g., 256 nodes, as each transceiver has a ⅛ unit load on the RS-485 bus. A single wash light LRU may have multiple RS-485 transceivers.
The amount of time required to transmit a scene message is largely a function of the number of zones on a line, where buses with multiple zones require a proportional increasing in messages to maintain the light LRUs.
All Lighting LRUs 10 may be dynamically addressable utilizing the RS-485 serial bus and token line, with any LRU capable of being placed in any position in the aircraft. Each RS-485 port of the CMS should be capable of controlling multiple wash lighting LRUs 10 in a column, with LRUs on each port in a daisy-chained series. To address all wash lighting LRUs on a port, the CMS initiates the addressing sequence by asserting a token out line and transmitting the starting address over RS-485 to the first connected Lighting LRU. Once the first LRU successfully addresses and responds as such to the CMS, the CMS can de-assert the token line. This same method of addressing propagates down the column, where each previous LRU then takes the role of the CMS by asserting its token out line and generating the next address message on the bus.
The RGB+W wash lighting LRUs 10 may be field loadable, with software loading capability being controlled via a software load application. Upon power up, the lighting LRUs 10 may start operation in boot mode, which may determine if the currently stored operational software is valid before commencing normal operation. Loading of operational software is preferably only be initiated over RS-485 by the software load application.
The downloadable data deliverable to the wash light LRUs 10 preferably includes the lighting database and configuration information. Lighting database entries should define all the possible scenes criteria, including color point, transition times, and intensity. The configuration information contains aircraft configuration and zone information, which identify how lights will interpret scene messages.
It is assumed that for easier aircraft configuration and maintenance that the lighting database, created using a lighting database creation tool, may be downloaded to the CMS for storage and subsequent download to the specified lighting LRUs as required.
The wash lighting LRU operational program may run on the microcontroller 42 on each ILDC board 30, regardless of how many ILDC boards may be in a particular wash light. Each wash light may be an addressable unit via tokening, as described above. The memory on the microcontroller 42 to support the software and embedded firmware may be segmented into several distinct areas: operational program, configuration data and calibration data.
The operational portion may control all aspects of the wash light LRU 10, including power up tests, communication handling, LED output, continuous tests, and any data logging. Power up tests may include determining if the unit is restarting from a commanded reset after data load, if the unit is restarting from a watchdog timer fault, RAM and Flash integrity checks, and verifying stored configuration and calibration data.
LED 40 output may be controlled using stored calibration values as a base. When the wash light LRU 10 is manufactured, it may be calibrated to attain the best possible LED pulse width modulation (PWM) values to achieve the desired color points. The calibrated values may be stored in flash memory on the microcontroller 42 to be retrieved by the operational program 49 during runtime.
The stored LED PWM calibration values may be read by the operational program 49 as required when a scene is selected. The program uses the PWM values for the selected state as a base and calculates actual PWM values depending on the current measured temperature, the accumulated “on” time of the LEDs, and the summed PWM values for each of the LEDs used for the particular state. The final, calculated PWM values may be sent to the LED drivers to update the actual output.
Communication from the CMS may be handled on the ILDC via an RS-485 transceiver to an integrated UART on the microcontroller. The UART is an interrupt driven receiver coupled with a custom driver that caches received data from the bus to be handled in a separate routine. The message handling routine processes command messages from the CMS while maintaining all state control for a received message. Once a message has been successfully parsed, necessary data may be passed to dedicated functions to perform the actions required by the command. These individual routines can determine, based on the received data, whether a response is required and will then prepare one accordingly to be returned within a specified timeframe.
Continuous tests and data logging are operations that may happen at regularly scheduled intervals. During runtime, the operational program may periodically check the current temperature to ensure it has not increased beyond acceptable limits and check the voltage level on the ILDC board to verify it has not dropped below safe operational range. Any noted limit violation will result in the program performing safety related actions, such as reducing or shutting down LED output to reduce heat. The operational program may also periodically store LED time, accruing runtime values based on whether a particular LED is on or off.
Each ILDC 30 can store in flash memory the unique identifiers that enable the CMS to control each lighting LRU 10. Configuration data may be updated in flash memory as required when the CMS commands a configuration change or data load. This may be a zone re-assignment, lighting database reload, or re-addressing.
Photometric and calibration algorithms and chambers described in the related patent applications may be used to verify that the wash light LRU 10 chromaticity and flux characteristics are met. This calibration process takes core LED measurements correlated to operating temperature and provides specific drive parameters to lighting elements resulting in repeatable light output from wash light to wash light.
In the lighting system design, each washlight can be configured to display a defined set of color points, each of which is defined as a flux value and a set of target color coordinates. For a wash light to emit light that complies with a specified color point, the color mixing, temperature and aging characteristics of the LEDs may be used to calculate the required PWM that will drive the LEDs.
When calibrating a wash light, each specified color point may utilize a white LED plus two of either the red, green or blue LEDs to generate the desired output. This determination will be made at calibration time based on the chromaticity coordinates of the LEDs. The two RGB colors used depend on the position of the target color coordinates on a chromaticity diagram.
A wash light 10 may calculate temperature correction internally by comparing the temperature recorded during calibration to the temperature measured on the Lighting LRU during operation and deriving a correction factor based on the temperature delta from the recorded calibration temperature and compensation values determined at calibration. The temperature ranges that affect the output can be characterized as minimum, nominal and maximum operating temperature and mixing zone crossing temperature.
LED technology that features consistent light output over the rated life of the LED, custom LED binning, and calibration may be utilized to ensure a product that provides consistent light output over the life of the product.
To minimize the visual color shift during the life of the LED, the lighting LRU 10 may use control circuitry that ensures the LED is always operating within the published specifications of the manufacturer in order to maximize light output over its expected life. Wash lights 10 may also compensate for LED aging using a pre-defined table of values derived from the manufacturer specified change in output over time.
A lighting mode (scene) is defined as a specific configuration of cabin lighting LRUs so that their output creates the desired lighting. Scene development is the method of configuring cabin lighting LRUs to achieve that result on the airplane. This configuration data is typically stored as a loadable database or binary file containing configuration parameters such as color point, intensity, and scene transition times.
For most applications, the airplane lighting database may be developed off-site on a PC/Laptop and is uploaded to the airplane after configuration. The database format and method for loading the database can be defined according to a predefined standard. Tools may be used to generate lighting scene data to be loaded to the lighting LRUs 10. The following list details information that may be utilized to create a lighting database:
The aircraft configuration database may be a graphical representation of all the lighting units on board the airplane. It can identify both the location and the associated logical address of each lighting LRU 10. This is required to correctly segment the lighting LRUs into zones which match the various sections of the cabin, allowing lighting zones to be changed without changing airplane wiring or lighting hardware.
A cabin management may be used to maintain the lighting database for the RGB cabin lighting system, with the lighting database downloaded to the CMS as required. Scene change messages can be initiated from the CMS using the stored lighting database, and are sent to the lighting LRUs to generate the selected scene.
Light intensity on the RGB cabin lighting system may be controlled by algorithms that ensure the best possible light quality and consistency. All scene information, which includes color point, intensity and transition time, may be stored in the lighting database resident in the CMS. When a scene is invoked, the CMS can transmit the scene information to the lighting LRU 10 over an RS-485 communication bus. Each lighting LRU 10 can use the scene information as inputs to their dimming algorithm to create smooth and controlled output as required.
Actual dimming may be performed using pulse width modulation. Wash light LRUs 10 used for general cabin use a linear constant current source to drive each string of LED's to ensure that there are no intrinsic LED current fluctuations. Duty cycle is a function of required light intensity level, calibration derived compensation values, temperature and accumulated running hours. When changing from one light level to another, a logarithmic intensity curve can be applied to provide a visually smooth transition. All functions that affect dimming levels such as temperature, aging and calibration will also follow the same logarithmic curve.
The log function is essentially a high resolution interpolation function that joins the start state and the end state within a scene transition. When dimming from an arbitrary intensity state to a different intensity state of the same color, the log function can maintain the same LED to LED intensity ratio throughout the transition. This in turn minimizes color shifts within the transition. The LED pulse width frequency should be greater than 250 Hz, eliminating flicker associated with led motion/vibration with respect to the observer. All LED's within a light strip can follow the same PWM clock source to prevent aliasing.
Scenes transition times, defined as the time required when changing from one scene to another, may be variable and are controlled through the CMS via the lighting database. Non-zero transition intervals cause the lighting LRU 10 to transition gradually until the desired state is reached within the specified time. In this case, the lighting LRU 10 transitions utilizing a higher time resolution (smaller time quantization) and follows a logarithmic path to avoid illumination flicker. The lighting LRUs 10 can transition between color points based on downloaded scene information. Scene related message transmissions may be repeated to reduce the probability of lost data. In such a case, the lighting LRU 10 may ignore repeated messages.
The lighting LRUs 10 may run internal power up tests, internal continuous monitoring and manually initiated tests in support of the diagnostic model of each LRU. The lighting LRUs can report all stored configuration information and unique identification data, such as device part number, serial number, software part numbers and database part numbers.
Power on tests for the lighting LRUs 10 can include, but may not be limited to, memory integrity checks, stored operational program and configuration data CRC verification and hardware watchdog restart events. Memory checks comprise RAM and flash memory read/write sequences to verify memory integrity. CRC checks can verify that specific data loaded from flash memory is correct. An integrated hardware watchdog timer can be utilized on all lighting LRUs to improve robustness.
Internal continuous testing may include temperature monitoring, low voltage conditions, bus errors or faults and addressing faults. Other fault or health data can be addressed as well. An LED lighting test can also be included as an initiated test. From the CMS, the operator can be able to select a predefined lighting state. This functionality can rely on the CMS limiting access to lighting test controls to maintenance mode only.
As part functional testing, protocol generators may be developed to enable testing of all communication to and from the lighting LRUs 10. Functionality may include loading of lighting databases and configuration databases as required. These protocol generators can be designed to test message formatting and sequence for accuracy and completeness. The protocol generators may be used during software development, hardware/software integration and software verification, and may be used during hardware qualification for system stimulation.
Table 3 through Table 6 below correspond to
Table 3 and
However, if the green LED is omitted (RBW), a relatively wide range of colors can still be provided that, e.g., in an aircraft cabin environment, replicates a sunrise, sunset, daylight, and night sky. This can be seen in Table 4 and
A further combination can be provided in which nighttime colors are omitted—such a design is illustrated in Table 5 and
A final combination can be provided utilizing only a WWW (white, white, white) or limited WWA combination, as illustrated in Table 6 and
The chromaticity tolerances identified/specified in
Duv ± 0.006
Although the SAE Aerospace Recommended Practice ARP5873 LED Passenger Reading Light Assembly, Issued 2007-03, Page 7, Paragraph 3.1.3 White Light Color Definition allows for approximately a seven-step MacAdam ellipse variance, it states that the majority of the population can discern a color difference.
Thus, the Lighting Research Center, Final Report: Developing Color Tolerance Criteria for White LEDs, dated Jan. 26, 2004, Page 2, Summary recommends use of a two-step MacAdam Ellipse binning of white LEDs for applications where the white LEDs are placed side-by-side and are directly visible.
Table 7 illustrates a nominal CCT color chart table. US DOE Energy Star recognizes CCTs of 2700° K, 3000° K, 3500° K, 4000° K, 4500° K, 5000° K, 5700° K, and 6500° K for indoor LED Luminaries for Residential and Commercial applications. The ANSI_NEMA_ANSLG C78.377-2008 Specification for the Chromaticity of Solid State Lighting (SSL) Products is a further source. For lighting products that provide white light, the color temperature range is typically specified from nominal CCT categories 2700° K to 6500° K.
It is preferable in an embodiment of the present design to maintain a color consistency within a light module 10 of a four-step MacAdam Ellipse, although tighter control can be maintained through a refined and accurate bin sorting, and premeasurement and matching of individual LED characteristics.
The system or systems described herein may be implemented on any form of computer or computers and the components may be implemented as dedicated applications or in client-server architectures, including a web-based architecture, and can include functional programs, codes, and code segments. Any of the computers may comprise a processor, a memory for storing program data and executing it, a permanent storage such as a disk drive, a communications port for handling communications with external devices, and user interface devices, including a display, keyboard, mouse, etc. When software modules are involved, these software modules may be stored as program instructions or computer readable codes executable on the processor on a computer-readable media such as read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, and optical data storage devices. The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. This media is readable by the computer, stored in the memory, and executed by the processor.
All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated as incorporated by reference and were set forth in its entirety herein.
For the purposes of promoting an understanding of the principles of the invention, reference has been made to the preferred embodiments illustrated in the drawings, and specific language has been used to describe these embodiments. However, no limitation of the scope of the invention is intended by this specific language, and the invention should be construed to encompass all embodiments that would normally occur to one of ordinary skill in the art.
The embodiments herein may be described in terms of functional block components and various processing steps. Such functional blocks may be realized by any number of hardware and/or software components that perform the specified functions. For example, the described embodiments may employ various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, and the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. Similarly, where the elements of the described embodiments are implemented using software programming or software elements the invention may be implemented with any programming or scripting language such as C, C++, Java, assembler, or the like, with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Functional aspects may be implemented in algorithms that execute on one or more processors. Furthermore, the embodiments of the invention could employ any number of conventional techniques for electronics configuration, signal processing and/or control, data processing and the like. The words “mechanism” and “element” are used broadly and are not limited to mechanical or physical embodiments, but can include software routines in conjunction with processors, etc.
The particular implementations shown and described herein are illustrative examples of the invention and are not intended to otherwise limit the scope of the invention in any way. For the sake of brevity, conventional electronics, control systems, software development and other functional aspects of the systems (and components of the individual operating components of the systems) may not be described in detail. Furthermore, the connecting lines, or connectors shown in the various figures presented are intended to represent exemplary functional relationships and/or physical or logical couplings between the various elements. It should be noted that many alternative or additional functional relationships, physical connections or logical connections may be present in a practical device. Moreover, no item or component is essential to the practice of the invention unless the element is specifically described as “essential” or “critical”.
The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “supported,” and “coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings. Further, “connected” and “coupled” are not restricted to physical or mechanical connections or couplings. Expressions such as “at least one of,” when preceding a list of elements, modify the entire list of elements and do not modify the individual elements of the list.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the invention (especially in the context of the following claims) should be construed to cover both the singular and the plural. Furthermore, recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Finally, the steps of all methods described herein are performable in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. Numerous modifications and adaptations will be readily apparent to those skilled in this art without departing from the spirit and scope of the invention.
The present application claims the benefit of U.S. Provisional Application No. 61/615,495, filed Mar. 26, 2012, entitled, “Reduced-Size Modular LED Washlight Component”, and U.S. Provisional Application No. 61/726,010, filed Nov. 13, 2012, entitled, “Modular LED Washlight Component”, both herein incorporated by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4729742 | Onishi et al. | Mar 1988 | A |
| 5003432 | Mandy | Mar 1991 | A |
| 5490048 | Brassier et al. | Feb 1996 | A |
| 5677603 | Speirs et al. | Oct 1997 | A |
| 5825135 | Chang | Oct 1998 | A |
| 6016038 | Mueller et al. | Jan 2000 | A |
| 6211626 | Lys et al. | Apr 2001 | B1 |
| 6220721 | Chan et al. | Apr 2001 | B1 |
| 6366469 | Odenberg et al. | Apr 2002 | B1 |
| 6815842 | Fehd et al. | Nov 2004 | B2 |
| 7114827 | Halter | Oct 2006 | B2 |
| 7161556 | Morgan et al. | Jan 2007 | B2 |
| 7173383 | Vornsand et al. | Feb 2007 | B2 |
| 7198387 | Gloisten et al. | Apr 2007 | B1 |
| 7266315 | Sato | Sep 2007 | B2 |
| 7494255 | Bryan et al. | Feb 2009 | B2 |
| 7658506 | Dowling | Feb 2010 | B2 |
| 7717593 | Clark | May 2010 | B2 |
| 7717594 | Clark | May 2010 | B2 |
| 8111968 | Chakmakjian et al. | Feb 2012 | B2 |
| 8299716 | Melzner et al. | Oct 2012 | B2 |
| 8491151 | Spartano | Jul 2013 | B2 |
| 20020172052 | Perlo et al. | Nov 2002 | A1 |
| 20030208764 | Galipeau et al. | Nov 2003 | A1 |
| 20040183480 | Halter | Sep 2004 | A1 |
| 20040240211 | Rodgers et al. | Dec 2004 | A1 |
| 20050174309 | Bouwens et al. | Aug 2005 | A1 |
| 20050202785 | Meyer | Sep 2005 | A1 |
| 20050275912 | Chen et al. | Dec 2005 | A1 |
| 20060146553 | Zeng et al. | Jul 2006 | A1 |
| 20060187081 | Gloisten et al. | Aug 2006 | A1 |
| 20070034775 | Cheng et al. | Feb 2007 | A1 |
| 20070097675 | Koren et al. | May 2007 | A1 |
| 20070103646 | Young | May 2007 | A1 |
| 20070139941 | Bryan et al. | Jun 2007 | A1 |
| 20070236423 | Chiou et al. | Oct 2007 | A1 |
| 20070274084 | Kan et al. | Nov 2007 | A1 |
| 20070291483 | Lys | Dec 2007 | A1 |
| 20080089071 | Wang et al. | Apr 2008 | A1 |
| 20080136334 | Robinson et al. | Jun 2008 | A1 |
| 20080197788 | Conover et al. | Aug 2008 | A1 |
| 20080215279 | Salsbury et al. | Sep 2008 | A1 |
| 20080238339 | Deurenberg et al. | Oct 2008 | A1 |
| 20080253122 | Hancock et al. | Oct 2008 | A1 |
| 20080266887 | Wentland et al. | Oct 2008 | A1 |
| 20090001251 | Ng et al. | Jan 2009 | A1 |
| 20090059610 | Marshall et al. | Mar 2009 | A1 |
| 20090140630 | Kijima et al. | Jun 2009 | A1 |
| 20090237943 | Eckel et al. | Sep 2009 | A1 |
| 20090251898 | Kinnune et al. | Oct 2009 | A1 |
| 20100007588 | Zygmunt et al. | Jan 2010 | A1 |
| 20120019164 | Gambeski et al. | Jan 2012 | A1 |
| 20120307487 | Eckel | Dec 2012 | A1 |
| 20130082616 | Bradford et al. | Apr 2013 | A1 |
| Number | Date | Country |
|---|---|---|
| 1901587 | Mar 2008 | EP |
| 20030524284 | Aug 2003 | JP |
| 2004-006253 | Jan 2004 | JP |
| 2004-158370 | Jun 2004 | JP |
| 2005-517278 | Jun 2005 | JP |
| 2007-109584 | Apr 2007 | JP |
| 2007-249647 | Sep 2007 | JP |
| 2008-109514 | May 2008 | JP |
| 2008-135224 | Jun 2008 | JP |
| 03067934 | Aug 2003 | WO |
| 2008-047335 | Apr 2008 | WO |
| 2009-035493 | May 2009 | WO |
| Entry |
|---|
| U.S. Appl. No. 13/035,329, filed Feb. 25, 2011, Gambeski et al. |
| U.S. Appl. No. 13/034,983, filed Feb. 25, 2011, Eckel et al. |
| U.S. Appl. No. 13/035,626, filed Feb. 25, 2011, Greenfield. |
| Supplemental Search Report issued in related application EP09816872.7, dated Aug. 22, 2012, 6 pages. |
| Office Action issued in related application JP2011-528100 with English translation, dated Jan. 10, 2013, 7 pages. |
| International Search Report and Written Opinion issued in related application PCT/US2013/0033756, Jun. 18, 2013, 13 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20130249404 A1 | Sep 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61615495 | Mar 2012 | US | |
| 61726010 | Nov 2012 | US |
