The present invention relates to the field of automated proposal generation and response and more particularly to the dynamic generation of proposals and proposal responses.

Responding to received Request for Quote (RFQ) to provide a cost estimation necessary to fulfill the specification requirements is an extremely time consuming and labor intensive procedure that many companies must perform in order to obtain new business or maintain existing business.

Generally, a company receives a request for providing a cost estimate on a proposed configuration for a new design of a space (e.g., a floor plan, a building plan, etc.) or for a remodelling of the space. The company must then process the proposed configuration in terms of which components to choose, the cost of components, whether the chosen components satisfy the desired requirements, etc., in order to determine a cost to implement the chosen design. Further, the company may desire to select alternative components (if desired components were selected in the RFQ) in order to direct the design to a particular

manufacturer's components as the particular components may be preferred and/or well- known and/or alter the cost of the estimate to respond to the RFQ.

Companies expedient significant time, effort and money in providing a response to the received RFQ in order to compute a best cost estimate that would increase their chances of winning the project.

As only one bid is selected, typically based on the cost estimate, to implement the proposed design, the time, effort and money spent by the companies not being selected is a lost effort.

Currently, this process is done manually which is a very tedious, time-consuming and error-prone. Thus, there is a need in the industry for a method and system for automating the process of generating proposals and/or generating responses to received proposals.

In accordance with the principles of the invention a system and method for generating a response to a request for proposal (RFP) or request for quote (RFQ) in a timely manner is disclosed. The system comprising methods for evaluating specified elements of the proposal or quote, searching at least one database for the specified elements and alternative elements that match the specified elements. The system further provides tools for evaluating properties of the specified elements and the alternative elements to determine with regard to cost, quality and preferred settings. A response to the RFP or RFQ is then prepared based on selected ones of the evaluated specified and alternative elements.

In accordance with the principles of the invention, a system for responding to a request is disclosed. The system comprising a processor in communication with a memory, the memory including code, which when accessed by the processor causes the processor to execute receiving the request, the request including a plurality of elements, each of the elements containing at least one property; developing a search parameter criteria associated with at least one of the at least one property; searching at least one database containing the at least one of the at least one property for at least one matching element having a property within the search parameter criteria; determining whether a number of at least one matching element results from the search is greater than a minimum number; ranking each of the at least one matching element; and selecting one of the at least one matching element based on the ranking.

In another aspect of the invention, method, operable in a processor, is disclose, which causes the processor to receive a request for a cost to develop a lighting system, the request including a plurality of luminaires, each of the luminaires associated at least one lighting property; develop a search parameter criteria associated with the at least one lighting property; search at least one database for at least one matching luminaire containing a lighting property within the search parameter criteria; determine whether a number of at least one luminaire element results from the search is greater than a minimum number; rank each of the at least one matching luminaire with respect to the lighting property; and select one of the at least one matching element based on the ranking.

For a better understanding of exemplary embodiments and to show how the same may be carried into effect, reference is made to the accompanying drawings. It is stressed that the particulars shown are by way of example only and for purposes of illustrative discussion of the preferred embodiments of the present disclosure, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In the accompanying drawings: Figure 1 A illustrates an exemplary system configuration in accordance with the principles of the invention.

Figure IB illustrates an exemplary system configuration in accordance with the principles of the invention.

Figure 2 illustrates an exemplary process in accordance with the principles of the invention.

Figure 3 illustrates an exemplary spreadsheet regarding parameters associated with a conventional device.

Figure 4 illustrates an exemplary search process in accordance with the principles of the invention.

Figure 5 illustrates an exemplary spreadsheet output in accordance with the principles of the invention.

Figure 6 illustrates an exemplary process for creating a database in accordance with the principles of the invention.

Figure 7 illustrates an example of a parameter structure associated with third party software.

Figure 8 illustrates an example of a parameter structure associated with a particular component.

Figure 9 illustrates an exemplary database schema in accordance with the principles of the invention.

Figure 10 illustrates an exemplary database schema in accordance with the principles of the invention.

Figure 11 illustrates an exemplary data template in accordance with the principles of the invention.

Figure 12 illustrates an exemplary luminous intensity diagram.

Figure 13 illustrates an exemplary catalog definition.

It is to be understood that the figures and descriptions of the present invention described herein have been simplified to illustrate the elements that are relevant for a clear understanding of the present invention, while eliminating, for purposes of clarity many other elements. However, because these omitted elements are well-known in the art, and because they do not facilitate a better understanding of the present invention, a discussion of such elements is not provided herein. The disclosure herein is directed to also variations and modifications known to those skilled in the art.

Figure 1A illustrates an exemplary system configuration 100 in accordance with the principles of the invention.

In this illustrated system, a user may interface a set of requirements, (e.g., received RFQ, preferred configuration, cost, etc.) into the system using a user interface 110. As would be recognized, the user interface 110 may be a manual type interface (e.g., a keyboard, mouse, etc.) or may be a processing system that may "read" through optical character recognition (OCR) of hard-copy information or may be a processing system in

communication with one or more networks (wired or wireless) (not shown) that may be used to download information using well-known protocols (e.g., TCP/IP/HTTP) such that information may be provided directly to the user and the processing system described herein. As would be further recognized, the user interface may include a display (not shown), which displays to the user, the information that has been inputted through one or more of the manual type interface, the OCR, and/or the network configuration

Further illustrated is calculation engine 120 receiving information from user interface

110 and further one or more databased 140. Calculation engine 120 further receives information from BIM (building information models) or building design software, or other building data models (e.g., IFC data model) 130. BIM software provides information regarding models associated with different types of building or space configurations or building objects (e.g. luminaires, doors, windows, tables, pipes, etc.) Examples of commercially available BIM software include ArchiCAD, Autodesk Revit, ARCHIBUS EIM with BIM 4.0, Bentley Architecture, IntelliCAD, CADSoft Envisioneer, Softtech Spirit, RhinoBIM, DesignBuilder, CypeCAD, Vela Field BIM and Tekla BIMSight. The RFQ may be based on a particular BIM and/or developed with one or more BIMs used as a template for the design in the RFQ.

Calculation engine 120 further provides an output 150 based on the received input data. For example, in the case of a RFQ, the output 150 may represent a cost estimate and schedule (i.e., bill of material) for implementing the design proposed in the RFQ. In addition, the output may include one or more alternative designs and costs, wherein the alternative design includes preferred components. In one aspect of the invention, the found elements may be incorporated into a spreadsheet application product as alternatives to the elements requested or required in the RFQ along with their costs. Figure IB illustrates an exemplary configuration of a configuration engine 120 for implementing the principles of the invention shown herein. In this exemplary configuration engine embodiment 120, input data is received from sources 105 (e.g. user interface 110, OCR documents, downloaded documents) over network 155 and is processed in accordance with one or more programs, either software or firmware, executed by processing system 122. The results of processing system 122 may then be transmitted over network 165 for viewing on display 170, reporting device 175 and/or a second processing system 180.

Processing system 122 includes one or more input/output devices 124 that receive data from the illustrated sources or devices 105 over network 155. The received data is then applied to processor 126, which is in communication with input/output device 124 and memory 128. Input/output devices 105, processor 126 and memory 128 may communicate over a communication medium 127. Communication medium 127 may represent a communication network, e.g., ISA, PCI, PCMCIA bus, one or more internal connections of a circuit, circuit card or other device, as well as portions and combinations of these and other communication media.

Processing system 122 and/or processor 124 may be representative of a handheld calculator, special purpose or general purpose processing system, desktop computer, laptop computer, palm computer, cell phone, smart phone or personal digital assistant (PDA) device, etc., as well as portions or combinations of these and other devices that can perform the operations illustrated.

Processor 124 may be a central processing unit (CPU) or dedicated

hardware/software, such as a PAL, ASIC, FGPA, operable to execute computer instruction code or a combination of code and logical operations. In one embodiment, processor 124 may include code which, when executed by the processor, performs the operations illustrated herein. The code may be contained in memory 128, may be read or downloaded from a memory medium such as a CD-ROM or floppy disk, represented as 183, may be provided by a manual input device 185, such as a keyboard or a keypad entry, or may be read from a magnetic or optical medium (not shown) or via a second I/O device 187 when needed.

Information items provided by devices 183, 185, 187 may be accessible to processor 122 through input/output device 124, as shown. Further, the data received by input/output device 124 may be immediately accessible by processor 126 or may be stored in memory 128.

Processor 122 may further provide the results of the processing to display 180, recording device 190 or a second processing unit 195.

As one skilled in the art would recognize, the terms processor, processing system, computer or computer system may represent one or more processing units in communication with one or more memory units and other devices, e.g., peripherals, connected electronically to, and communicating with, the at least one processing unit. Furthermore, the devices illustrated may be electronically connected to the one or more processing units via internal busses, e.g., serial, parallel, ISA bus, Micro Channel bus, PCI bus, PCMCIA bus, USB, etc., or one or more internal connections of a circuit, circuit card or other device, as well as portions and combinations of these and other communication media, or an external network, e.g., the Internet and Intranet. In other embodiments, hardware circuitry may be used in place of, or in combination with, software instructions to implement the invention. For example, the elements illustrated herein may also be implemented as discrete hardware elements or may be integrated into a single unit.

As would be understood, the operations illustrated may be performed sequentially or in parallel using different processors to determine specific values. Processing system 122 may also be in two-way communication with each of the sources 105. Processing system 122 may further receive or transmit data over one or more network connections from a server or servers over, e.g., a global computer communications network such as the Internet, Intranet, a wide area network (WAN), a metropolitan area network (MAN), a local area network (LAN), a terrestrial broadcast system, a cable network, a satellite network, a wireless network, or a telephone network (POTS), as well as portions or combinations of these and other types of networks. As will be appreciated, networks 155 and 165 may also be internal networks or one or more internal connections of a circuit, circuit card or other device, as well as portions and combinations of these and other communication media or an external network, e.g., the Internet and Intranet (wired and wirelessly).

Figure 2 illustrates an exemplary process for providing a response to a received RFQ in accordance with the principles of the invention. As illustrated, information may be obtained from a BIM model, wherein the BIM model provides information regarding a building geometry, physical properties, optical properties, layout, doors, windows, furniture, pipes, mechanical equipment, electrical equipment, luminaires, etc. The BIM information may include a desired (or required) number of luminaries, a placement of the luminaries in the building space etc. The received information may be incorporated into the RFQ or may be information that is required and not considered in the RFQ.

In order to best describe the principles of the invention, a specific example with regard to lighting is presented. In this illustrative example of the invention claimed, elements regarding lighting, such a luminaires, are evaluated in response to the RFQ. Although the processing described herein is selected with regard to the specific example of luminaires, it would be recognized that the principles of the invention presented herein may be applicable to other types of elements within the RFQ.

Referring now to Figure 2, a brief introduction of each step is shown below.

The BIM model of the entire building is loaded in the software at step 210. The software reads the building model to identify the embedded objects and their properties. From all the objects embedded in the building model, filter the objects of interest, i.e. identify the objects representing luminaires manufactured by competitors based on the object type and/or manufacturer name properties at step 220.

Based on those properties, search criteria are defined to retrieve similar luminaires from at least one library/database of luminaires. Search criteria is augmented based on predefined or user defined parameters. Users are allowed to update the search criteria. For example, if the reference luminaire has known illumination characteristic, then the search criteria may be comprised of tolerance values based on the known illumination characteristic.

The engine defines a command execution sequence, based in part on user inputs provided at step 245. The command execution sequence is used to search the database(s) at step 240 to find matching luminaires. The search criteria tolerance values may be

dynamically expanded/contracted until a desired number of matching luminaires are found or a pre-defined number of searches have been completed.

The search finds the predefined number of best match luminaires based on a predefined ranking function at step 255. The results are displayed to the user in order of their rank so that the user may identify the most suited match. In one aspect of the invention, the found elements may be outputted in the form of a spreadsheet (e.g., EXCEL) in which the specified elements and alternative elements are jointly presented.

Update the building model by replacing all the instances of the reference luminaire with the most suited luminaire at step 275.

Figure 2 is now described with further specificity:

Step 210: Identify the embedded objects and their properties, and filter the objects of interest (e.g., luminaires) from all objects.

The building model is loaded into the BIM or similar design software, and then programmatically identify the embedded objects in the building model and their properties. Filter the object of interested stored in the building model by scanning all the objects and their properties in the building model. The outcome of this step is a list of objects of interest that have been shortlisted for replacement.

Step 220: Retrieve properties of objects of interest (e.g., luminaires) in the building model.

The luminaire objects retrieved from the building models contain properties that may be accessible by API of the BIM software. The properties of a luminaire may include manufacturer, model, efficacy, lumen output, IES lighting distribution file, and catalogue number information, etc. For example, in a Revit family file, the retrieved properties in "identity" category (see Fig. 3) include manufacturer name, catalog number, description, etc. The properties in the "photometries" include color, luminaire intensity, efficacy etc.

Step 240: Search a luminaire product database based on defined search criteria.

The workflow of the searching a product database is shown in Fig. 4.

With reference to Fig. 4, there are four major steps.

At step 410 a parameter search range is defined to search for alternative luminaires. The process starts with list of parameters and their values read in the previous step 240. For each parameter of interest, a search criterion is defined based on its relevance for finding similar luminaires. These parameters can be classified into numeric parameters, descriptive parameters and static parameters. Fig. 5 provides an example of user interface 500 for defining search parameters and search range, wherein a list of properties (which may be predefined or user selectable) 510 are displayed. The current value 520 of a corresponding parameter shows the parameter values of a currently selected luminaire type in a building model. The search range 530 defines the range that is used to search luminaire product database. Default values for search parameters may be automatically generated. For example, the value for manufacturer name search parameter is set to "Philips" replacing the competitor name. The default value for voltage parameters may be set the same as in the reference luminaire property. A user can select parameters by clicking the checkbox, and adjust the search range. Alternatively, the user may set tolerance values around nominal values. The parameters presented may be of a class of:

a. Static parameter: this class of parameters are those whose values are fixed. For example, for the dimensions of the luminaire (e.g. length and width), the search criteria are set so as to find matching luminaires with the same exact dimensions as the reference luminaire. Similarly, for voltage - the search criterion is set to find matching luminaries with the same Voltage as the reference. Static parameter may be numerical or string type.

b. Descriptive parameters: this class of parameters includes text/string, non-scalar parameters (e.g., IES file), or discrete numeric variables. Examples of these parameters include: manufacturer name, model type, interior surface color, material type etc.

Users may modify the default values of the search parameters as:

b.1. Using a list of options: for example, the search range of "Model Type" parameter can be A, B, C or D type. These options can be provided by the user using checkboxes.

b.2. Using partial text string value: For example, "Luminaire

Description" parameter can have a text box to allow users to input keywords that describe the additional properties of the luminaire. User can define a few keywords using logical operators such as "And", "Or", "Not", "wildcard" to express the search text.

c. Numeric parameters: There are many ways to define the search range for numeric search parameters:

c.1 . Using the upper and lower bound of search range. For example, for the search parameter "Lumen Output", the search range can be ± 100 of the reference luminaire value. Thus if the reference luminaire has the lumen output of 1000 lumens then the search range will be greater than 900 lumens and lower than 1100 lumens. For

"efficacy", the search criterion is set to find luminaires with the same or higher efficacy than the reference luminaire.

c.2 . For luminous flux, the search criterion may be set to find luminaires which have luminous flux within, for example, +15 and -15 percent (%) of the reference value.

d. Some of the parameters of interest may not be directly searchable as they are not stored in the database. In that case the given parameter is translated into another parameter that is available in the database and can be searched. An example of this type of indirect search is: assume the search parameter of interest is total lumen. However, this parameter is not stored in the database. The total lumen is the product of coefficient of utilization, lumen per luminaire and lighting loss factor. Suppose these three parameters are stored in the database. In this case the total lumen can be derived using the formula: Total lumen = coefficient of utilization * lumen per luminaire * lighting loss factor

In this case the search query will be formulated using factors such as: coefficient of utilization, lumen per luminaire and lighting loss factor, which are available in the database.

In accordance with the principles of the invention, additional search criteria, such as luminaire availability, lead time for procurement, warranty, price, origin (e.g., US, China,..), brand, application segment (office, industry, retail,...), product type (recessed, troffer, outdoor), dimming type (DALI, 0-10), emergency lighting (yes/no), integrated sensors (Occupancy, daylight, ...), wiring type (e.g. flex wiring), mounting arrangements, driver options, accessories, vandal resistance (Yes/No), clean room/surgical/MRI (Yes/No), etc. may be as inputted by the users.

Returning to Figure 4 and at step 420 the database is searched using the search criteria derived by applying logical operations (e.g., 'AND', OR', and 'NOT') among individual search parameters. The engine construct SQL (SearcfiQueryLanguage) queries to be executed on the database and defines the command execution sequence. SQL is a well- known search program in the art and the details of converting the search criteria into SQL search criteria need not be disclosed in detail herein. In addition, while SQL is referred to herein to describe the principles of the invention, it would be recognized that other searching tools may be implemented without altering the scope of the invention described herein.

As the search range of the search parameters has been defined, the search query can be executed to search a database.

At step 432 a determination is made whether the number of the search results is larger than a pre-defined maximum value, Tmax, if not, then the search results can be reduced by narrowing the search range for some of the search parameters at step 430. A range reducing method is used to reduce the range of selected parameters. For example, the tolerances around a nominal value may be reduced in order to reduce the number of search results.

The method for reeducation is mainly applied to numeric parameters as static parameters remain the same during the search process. An exemplary reduction may be performed as:

c.1 Define a weight for numeric parameter: For example, there is numeric parameter "A" (search range is defined as -10% to +30%) and assign the weight of "A" as "2", and the maximum weight is set to "10",

c.2 In the next step, calculate the reducing factor by dividing the weight of the parameter by the maximum weight value. For the example above, the reducing factor of parameter "A" is 20% calculated by dividing the weight of "A" (i.e., 2) by the maximum weight value (i.e., 10).

c.3 In the next step, calculate the new search range: the new search range of the parameter "A" is changed to -8% (i.e., 10% - (10% * 20%)) to 24% (i.e., 30% - (30%*20%)) using formula:

search range bound * (1 -reducing factor).

A new search is then begun with the modified search parameters at step 420.

At step 442, a determination is made whether a number of results is greater than a minimum number T _min . If not, then the search range may be expanded at step 440. The expanding search range can be done manually or automatically. For example, a method for expanding the search range of numeric parameter may be similar to narrowing method described above wherein:

search range bound * (1 + reducing factor).

At step 450, the obtained results are available by displaying the results or

electronically transferring the results into one or more databases, as will be discussed.

Although not shown, it would be recognized that a limit on the number of searches may also be incorporated without altering the scope of the invention. For example, a criterion may be that a limit of 10 searches, in total may be performed such that after the tenth search the obtained results of the tenth search are used for subsequent process.

Alternative, searching may be ended when then number of results obtained in an nth search is not significantly greater or less than the number of results obtained in the previous (i.e., (n- 1 ^st ) search. For example, searching may be concluded in the number of results obtained in the current search is less than two different than the number of results obtained in the immediately previous search. As would be recognized, the number that may be used to end the search may be predetermined or received as a user input. Now returning to the processing shown in Figure 2:

Step 255: Identify the most suitable luminaires from the top ranked luminaires From the results of step 240, the search results are retrieved from the database. The search results are ranked using a ranking algorithm.

An exemplary ranking algorithm is shown in Fig. 6.

At step 610: a set of reference values for a subset of the parameters are defined.

The reference value can be obtained from:

d.1 Directly from the reference luminaire model. For example, it may be desirable to find a replacement luminaire that has the same lumen output as defined in the luminaire being replaced.

d.2 User-defined value: this reference value is defined by user

At step 620: a distance for each parameter is calculated after defining the reference value. A simple example is distance defined in Euclidean space. Other methods can also be used to define distance.

If the reference value and the value of the parameter of a model in the database are identical then the distance is zero. If the database value is more favorable compared to reference value then the distance is negative. For example, if the reference value for efficacy is 50 lumens/watt and the matching luminaire family has efficacy 70 lumens/watt then the distance is negative 20 because the higher efficacy is better.

If the value of a parameter in the database is unfavorable compared to the reference value then distance is positive. For example, if reference value for efficacy is 50 lumens/watt and the matching luminaire family has efficacy 27 lumens/watt then the distance is positive 23. In this case lower efficacy is worse which is captured by assigning it a positive distance. As mentioned, negative distance indicates better solution.

Among all the matching luminaires found, the lowest cost luminaire is assigned a distance zero. All the other luminaires are assigned positive distances with respect to the lowest cost matching luminaire.

At step 630 a cluster analysis is performed based on the calculated distance, wherein clustering analysis can be conducted to provide hierarchical levels of the retrieved luminaires. The purpose of the cluster analysis is to provide a hierchical view of the luminiare search results and group similar luminaires. Alteratively, a historgram analysis may be performed that captures most likely values. At step 640 the results are ranked for each group provided by the cluster analysis as well as the total results using Pareto or weighted sum method, for example.

Thus, in one aspect of the invention, instead of selecting the overall top ranked luminaire, users may select top ranked luminaires from different groups. See the Figure 7, which illustrates a hierchical view of luminaries A through C based on cluster analysis. In one cass, for example, in the middle group, the user can select top ranked luminaire only from luminaire Bl, B2 and B3.

In one aspect of the invention, a user can select the top ranked luminaire based on a weighted sum or Pareto methods.

When using weighted sum method, weights should be assigned to different parameters (e.g., using AHP (Analytic Hierarchy Process)). Total distance for a matching luminaire family is computed as a weighted sum of distances for the properties of interest. The weights may be assigned based on relevance of the property for the cross-over.

When using a Pareto method, a Pareto front is be calculated. Among the luminaires falling on the Paroto front curve, select the sutiable one bsaed on user experience.

Return again to the processing shown in Figure 2:

In an optional step, (not shown), the API of BIM software provides capability of automating the deployment of luminaires. After a user selects a replacement luminaire, a new luminaire model can be automatically deployed into the building model at the original luminaire locations (or new locations defined by users). Specifically, the coordinates of original luminair location and origirnal luminaire orientation are used to place the replacment luminair at the same location in idential orientation. This process is repeated until all the luminare types shortlisted in step 220 are replaced with new models.

In addition, alternative components may also be illustrated. The alternative components may also be ranked based on one or more ranking factors. For example, the ranking may be based one or more of a cost, warranty, availability, origin, a level of matching to the desired component, a manufacturer, or generated from the complex ranking algorithm etc.

From the listing of alternative components, one or more alternative components may be selected in preparation of a response to the RFQ. The components in the response to the RFQ may then be determined based on one or more of a cost, warranty, availability, origin, a preferred manufacturer, or generated from the complex ranking algorithm etc. In one aspect of the invention, determination of elements that are alternative or equivalent to required elements is expedited by the construction of a database of elements having a common format.

In one aspect of the invention, database (140, see Figure 1) may be formulated in a manner to provide common entries associated with characteristics of the elements populating the database.

As information regarding current luminaire properties may be found in one or more different formats, it is important to transform the information to a common form before storing in the database.

For example, information regarding elements or components (e.g., luminaries) of one or more manufactures may be obtained from BIM family files, component data sheets, instruction manuals utilizing the component, product catalogues, design documents, regulatory filings and/or the Internet. For example, information regarding luminaries may be composed of voltage, wattage, configuration, type (LED, CFL, florescent, etc.), physical dimensions, lumen outputs, efficacy, etc.

However, creating a database containing competitors' luminaire properties is not a trivial task. Different competitors have different file formats for their luminaire

datasheets/specification and those datasheets/specifications are not machine readable.

Collecting and inputting data for different elements from different manufactures or suppliers that may be used by designers in preparing design RFQs is time consuming and labor intensive, as the characteristics of each of the elements or components typically is entered by hand. Given the large number of competitors and sheer variety of their luminaire portfolio, manually creating a database of competitor luminaire properties is practically impossible.

Hence, there is a need to automate the data collection and storage in a known format.

Advent of BIM technology provides the opportunity to gather the data in a known format.

We developed a method for automatically creating a database that contains comprehensive luminaire properties data by reading the BIM models of luminaire published by their manufactures on the internet.

Figure 8 illustrates an exemplary process for automating the database construction in accordance with the principles of the invention.

At step 810, luminaire family files (e.g., BIM models) are obtained to define luminaire geometry shape, electrical, photometric, catalog number, and manufacturer defined properties. One of the commonly used luminaire family files is Autodesk Revit luminaire family files, which include generally accepted properties used in lighting industry.

The luminaire family files can be obtained from manufacturer websites (e.g., many lighting companies provide dedicated websites for BIM family file downloading). For example, Philips' BIM family file link is:

http://www.lighting.philips.co m/main/connect/tools_literature/revit-library.wpd).

Another method of obtaining the family files is through a dedicated public repository hosted by third-parties. For example, Autodesk provides a central repository (i.e., SEEK database) allowing Revit and AutoCAD users to search and download thousands of BIM family files (not limited to lighting product but also includes many different types of products).

The luminaire family file may be periodically visited and checked for updates or revisions or deletions to a file previously processed. If the file has been updated or revised (known from its timestamp or revision number) then it is downloaded again for re-processing. The information obtained from the previous file is marked as out-of-date in the database. If a file is deleted then the information obtained from the file is marked as discontinued in the database.

In accordance with the principles of the invention, information associated with the entries within the database are periodically reviewed to determine whether new or updated information is available. The new and/or updated information is then accessed in view of the components or parameters specified in a received RFQ.

In addition to luminaire family files, other data source files and predefined data format can also be leveraged. For example, IFC (Industry Foundation Class) and gbXML (green building XML), which may be exported from building design software (e.g., Autodesk Revit), contains building component (e.g., luminaire) property information. CIBSE (Charted Institute of Building Services Engineers) developed a luminaire data template, which specifies parameters in different categories: manufacturer data, application, light source data, dimensional data, construction & finishes data, photometric performance data, electric data, sustainability, and operations & maintenance (see Fig. 11). In addition, photometric data files (e.g., IES file) also contains luminaire lumen output, manufacturer and lighting angular intensity data. At step 820 Identify built-in property and manufacture-defined property definitions, export properties of luminaires and create parameter mapping files.

Different data source files can be used to extract luminaire properties. For example, the CIBSE luminaire data template, IFC, gbXML, and IES files define data format and property values which may be parsed and extracted to obtain luminaire properties. In an IFC file, luminaire properties are defined in different objects such as ifcLamps, ifcLightFixture, ifcLightSource, and ifcLightDistributionData. By parsing the IFC files, the light related data can be extracted. Luminaire properties are also extracted from a photometric data file (e.g., IES file) using the following steps:

(a) Create a photometric distribution image using the data file. The image can be loaded into the database in later step. For example, Fig. 12 shows a light intensity distribution diagram created from an IES file.

(b) Extract individual parameters of the photometric file and then export these parameters into the database for searching.

(c) Any other information that can be derived from the photometric file.

Luminaire properties can also be extracted from manufacturers' catalogue number or naming convention. For example, Fig. 13 shows an example of the numbering convention of catalogue number for Philips Day-brite luminaires. By parsing these numbers, the luminaire properties are extracted.

In a luminaire family file, the properties are divided into built-in and manufacturer- defined properties. The family files are loaded in a database file. Family files have built-in properties whose values are assigned by the product manufacturer. For example, in Autodesk Revit family files, some of the following parameters are used as built-in properties (Table 1). Using Revit software, the properties embedded in the family files can be read and exported.

Table 1 Built-in parameters defined by Revit family file

Apparent Load OmniClass Title

Assembly Code Photometric Web File

Assembly Description Surface Depreciation Loss

Ballast Loss Temperature Color

Color Filter Temperature Loss Description Tilt Angle

Dimming Lamp Color Temperature Shift Total Light Loss Factor

Efficacy Type Comments

Emit from Rectangle Length Type Name

Emit from Rectangle Width URL

Emit Shape Visible in Rendering Voltage Loss

Family Name Wattage

Illuminance Light Loss Input

Initial Color Light Source Definition (family)

Initial Color Temperature Luminaire Dirt Depreciation

Initial Intensity Luminous Flux

Initial Light Intensity Input Method Luminous Intensity

Lamp Manufacturer

Lamp Lumen Depreciation Model

Lamp Tilt Loss OmniClass Number

Light Loss Factor

Besides the built-in parameters provided by family files, other parameters specific to the manufacturers are also included in the family files. These parameters and their values are defined by the manufacturer. Table 2 shows some of the parameters defined by Philips Daybrite luminaires, for example.

Table 2 Manufacturer defined parameters (Philips Daybrite luminaire)

Apparent Load Comments Fixture Radius

Ballast Configuration Glass Material

Ballast Number of Poles Glass Radius

Ballast Type Housing Material Finish

Ballast Voltage Lamp Comments

Catalog Number Lamp Position

Ceiling Mount Material Length

CIE Type LER Luminaire Efficacy Rating Depth Load Classification

Diffuser Shielding NEMA Type

Diffuser Shielding Material Finish Number of Lamps or LEDs

Distribution Options

Drop From Ceiling Photometry Comments

Fixture Efficiency Product Family

Fixture Material Product Page URL

Radial Louver

At step 830 the properties are analyzed and parameter-mapping are created to normalize the data. For example, manufacturers can add their own luminaire properties in luminaire family files. Even for the same manufacturer, different brands of luminaires define different property naming style. In order to understand and compare property values across different manufacturers they must be normalized. Another example is that different parameter names are used in different data source files such as IFC, gbXML, product data template, catalogue number, and manufacturer-defined luminaire naming convention. Thus, the luminaire properties should be normalized to map parameters from different data sources into a standardized parameter schema.

In one aspect of the invention, one way to normalize the properties is to map properties specified by manufacturers- and different data source files to a standardized property built-in our system. A simple mapping file is show in Table 3. The first column represents parameters defined by manufacturer and the second column represents the equivalent parameter (e.g., standardized parameter) that corresponds to (or maps to) the manufacturer-defined parameters. In this illustrated example, Al and B2 are mapped to the same standardized property even though the naming is different.

Table 3 A sample mapping file

Parameter name from Mapping parameters

Manufacturers and external data source

Al (from manufacturer A) PI

A2 (from manufacturer A) P2

A3 (from manufacturer A) P5 Bl (from manufacturer B) P2

B2 (from manufacturer B) PI

B3 (from manufacturer B) P5

Several methods, in accordance with the principles of the invention, can be used to map the manufacturer specific parameters to a standardized parameters. For example:

(1) Manually map the parameters by reading the luminaire specification/datasheet. A GUI is developed to allow user to map the manufacturer specific parameter to an equivalent standardized parameter. The mapping will be stored in the persistent memory. Typically, the manufacturers consistently use the same naming convention for their luminaires. Therefore, the mapping is done once for a given manufacturer and reused for all the luminaires from that manufacturer. If an unknown parameter is encountered then user is prompted to define the mapping.

(2) Second approach is to automatically map manufacturer specific properties to

equivalent standardized properties. We perform correlation analysis and natural language processing (NLP) of the parameter names to find matching parameters. For example, manufacture specific parameter named "length" can be automatically mapped to a standardized parameter named "length". More complex analysis using NLP can be used to determine whether two terms denotes the same meaning or not.

Fig. 9 shows a software tool 900 in accordance with the principles of the invention to create mapping files. In the left panel, 910, the parameters are selected, and then the standardized parameter is shown in the right panel 920 to map the manufacturer-defined parameters into the standardized parameters.

Manufacturer specific parameters from different manufacturers may use different units, for example, some manufacturer uses for example "meter" while some use "foot" or "inch". Thus, the mapping of manufacture specific parameters to standardized parameters may require processing and normalization.

In accordance with the principles of the invention, the units from different manufacturers may be translated or transformed into a common set of unit. For example, (1) determine the unit through the parameter value and luminaire type. "Length" has a lower and upper bound values. If using a unit results in significantly exceeding the current bound, then this unit is not used for this parameter. For example, if the value of the parameter "length" is 24, it cannot be meter nor foot because it obviously exceeds the normal range of luminaire size for other units.

(2) the unit can be determined by analysing which range the parameter value falls into.

For example, if using feet, the value range is from 8-10, if using centimetre, the value range is from 4-7, then the unit is centimetre if the actual value is 6.5.

(3) the third method is to estimate the unit based on the parameter unit used within this luminaire parameter list, because within a single luminaire type, the unit is normally consistent, using either SI unit or imperial. Similarly, the units are also determined based on the target market for the product. For example, length is typically specified in meters in Europe whereas length is specified in feet in the US.

Returning to processing shown in Figure 8, at step 840, the database schema may be formulated based on:

derived parameter which represent parameters that are not directly defined in a luminaire family file but defined and stored in the database for more advanced searches. The derived parameter may be calculated based on other parameters and user inputs.

For example the total lumen output is a derived parameter that is calculated using the equation:

total lumen= coefficient of utilization * lumen per luminaire * lighting loss factor.

Schema creation is a one-time effort. In accordance with the principles of the invention there are six types of data tables that can be created:

(a) data tables of built-in parameters;

(b) data tables of manufacturer specific parameters

(c) data tables for standardized parameters

(d) data table of derived parameters

(e) data table of other relevant information which is not listed in tables (a) to (e). For example, luminaire availability, lead time for procurement, warranty, price, origin (E.g. US, China,..), brand, application segment (office, industry, retail,...), product type (recessed, troffer, outdoor), dimming type (DALI, 0-10), emergency lighting (yes/no), integrated sensors (Occupancy, daylight, ...), wiring type (e.g. flex wiring), mounting arrangements, driver options, accessories, vandal resistance (Yes/No), clean room/surgical/MRI (Yes/No), etc.

Fig. 10 shows a screenshot of an exemplary database schema diagram developed in accordance with the principles of the invention. The tables shown in Figure 10 include a photometric file, a material properties, and a lighting related properties file. In addition, the inter-relationships among the illustrated files is illustrated. In this matter, parameters associated with a characteristic may be accessed through a number of data files. Relational databases are known in the art.

Returning to Figure 8, at step 850, the luminaire properties are inserted into the database. After parameter and values are defined, the next step is to import the data into database based on the schema. The data can be inserted into database automatically once the database schema is defined. In the tool we developed, the luminaire family file property data can be exported automatically from the building model and then imported into database(s) automatically. This process is repeated when new family files are found on the internet or existing family files are updated.

As mentioned before when an existing family file is revised by manufacturer, the old information is marked out-of-date and new information is inserted in the database. Similarly, when the existing family file is deleted and/or removed by the manufacturer, the old information linked to that family file is marked as discontinued.

When exact components are specified, then alternative components are presented, in a ranking format, as previously discussed and the desired component and one or more of the alternative components may be compared to determine a best selection for the desired component. As would be appreciated, the best selection may be determined based on at least one of ranking, cost and preferred manufacture.

Alternatively, when desired operating characteristics are specified, then the one or more components may be determined that satisfy the desired operating characteristics (within tolerances) may be determined based on at least one of ranking, cost and preferred manufacturer.

Figure 11 illustrates an exemplary data template in accordance with the principles of the invention. In this exemplary embodiment, a template for construction of a database file structure, wherein elements and characteristics associated with, in this illustrated example, luminaire. In this illustrative example characteristics associated with the manufacturer and associated data are collected and stored. Operating characteristics associated with the luminaire are further collected and stored. In one aspect of the invention, the units of each of the operating characteristics may be normalized so as to provide a common reference for each of the characteristics. For example, florescent lighting fixtures may be specified in units of feet or meters depending upon the source of the manufacturing of the lighting fixture. That is, one manufacture may specify fixtures in feet, while other manufactures may specify fixtures in meters. Similarly, the energy usage may be specified by one manufacturer may be different than the energy usage by other manufactures. A normalized or common unit definition provides for easy of comparing different luminaires for selecting different luminaires in response to a Request for Quote.

In one aspect of the invention, two types of database may be created: (a) data tables of built-in parameters; and (b) data tables of manufacturer-defined parameters. The data types include numeric, text, color, image and binary file. The databases may further include photometric file, material properties, and lighting related properties. The data can be inserted into each of the databases automatically once the database schema is defined. In addition, the luminaire family file property data can be exported automatically from a building model and then imported into one or both of the databases automatically. This process is repeated when new family files are found on the internet or existing family files are updated.

As would be appreciated, an existing family file that is revised by a manufacturer may be updated by removing or marking older information and new information is inserted in the database. Similarly, when the existing family file is deleted/removed by the manufacturer the old information linked to that family file is marked as discontinued.

Figure 12 illustrates an exemplary luminous intensity diagram associated with an exemplary luminaire. The intensity diagram presents an operational characteristic of a luminaire that is further stored, in digitized or coded form, in the database.

Figure 13 illustrates an exemplary catalog definition in accordance with the principles of the invention, in which an item may be cataloged using a multi-part identification number.

In this illustrative example, an item may be described or represented by elements such as a Fixture family (e.g., D-designer, CD CSA Certified Model), a Ceiling type (e.g., F- flange, G-grid, Z-Zspline), a number of lamps (NA, 1, 2, ...), a lamp type/wattage (e.g., 32- 32wT8, 40-40wT12, etc.), a frame type (e.g., TFS-Tamper Resistant), Lens type (e.g., 56, DR Acrylic lens), Voltage (i.e., 120, 277, 347, etc.) and Options (e.g., specific installation instructions, fire safety instructions, etc.). While Figure 13 illustrates exemplary fields of the multi-part identification number, we would be recognized that the multi-part identification number may be expanded to include further characteristics of items within the database so that these further characteristics may be used to determine whether an item matches the search criteria.

With the identification of each item in the database with a common multi-part identification numbers provides a means for implementing rules for developing search criteria that enable the database to be searched.

As discussed previously, the use of normalized entries in the databased provides for a common development of search parameters regardless of the form of the elements presented in the Request for Quote. .

Although, the invention has been described with regard to luminaire family files as an example, if would be recognized that the invention can be applied to any product family file, without altering the scope of the invention. There are a plurality of different types of family files of a variety of products available. The method disclosed herein can be applied to all different varieties of family files (i.e., lighting and non- lighting). Thus, the database described herein can be used in many different ways. For example, the database can be connected to building information modelling software or web-based tool to enable luminaire cross-over, competitor portfolio analysis and product gap analysis.

The above-described methods according to the present invention can be implemented in hardware, firmware or as software or computer code that can be stored in a recording medium such as a CD ROM, an RAM, a floppy disk, a hard disk, or a magneto-optical disk or computer code downloaded over a network originally stored on a remote recording medium or a non-transitory machine readable medium and to be stored on a local recording medium, so that the methods described herein can be rendered in such software that is stored on the recording medium using a general purpose computer, or a special processor or in programmable or dedicated hardware, such as an ASIC or FPGA. As would be understood in the art, the computer, the processor, microprocessor controller or the programmable hardware include memory components, e.g., RAM, ROM, Flash, etc. that may store or receive software or computer code that when accessed and executed by the computer, processor or hardware implement the processing methods described herein. In addition, it would be recognized that when a general purpose computer accesses code for implementing the processing shown herein, the execution of the code transforms the general purpose computer into a special purpose computer for executing the processing shown herein.

Furthermore, a computer, a processor and/or dedicated hardware/software are described herein as being capable of performing the processing described herein, and it would be recognized that a computer, a processor and/or dedicated hardware/software are well- known elements in the art of signal processing and, thus, a detailed description of the elements of the processor need not be provided in order for one skilled in the art to practice the invention described, herein.

The invention has been described with reference to specific embodiments. One of ordinary skill in the art, however, appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims.

Accordingly, the specification is to be regarded in an illustrative manner, rather than with a restrictive view, and all such modifications are intended to be included within the scope of the invention.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. The benefits, advantages, and solutions to problems, and any element(s) that may cause any benefits, advantages, or solutions to occur or become more pronounced, are not to be construed as a critical, required, or an essential feature or element of any or all of the claims.

As used herein, the terms "comprises", "comprising", "includes", "including", "has", "having", or any other variation thereof, are intended to cover non-exclusive inclusions. For example, a process, method, article or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. In addition, unless expressly stated to the contrary, the term "of refers to an inclusive "or" and not to an exclusive "or". For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present); A is false (or not present) and B is true (or present); and both A and B are true (or present).

The terms "a" or "an" as used herein are to describe elements and components of the invention. This is done for convenience to the reader and to provide a general sense of the invention. The use of these terms in the description herein should be read and understood to include one or at least one. In addition, the singular also includes the plural unless indicated to the contrary. For example, reference to a composition containing "a compound" includes one or more compounds. As used in this specification and the appended claims, the term "or" is generally employed in its sense including "and/or" unless the content clearly dictates otherwise.

All numeric values are herein assumed to be modified by the term "about," whether or not explicitly indicated. The term "about" generally refers to a range of numbers that one of skill in the art would consider equivalent to the recited value (i.e., having the same function or result). In any instances, the terms "about" may include numbers that are rounded (or lowered) to the nearest significant figure.

It is expressly intended that all combinations of those elements that perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Substitutions of elements from one described embodiment to another are also fully intended and contemplated.