Patent Grant
7818282
The present invention relates generally to the support of locales in business intelligence systems, and more particularly to a method and system for supporting a plurality of locales in a computer application.
Multinational corporations deploying and using business intelligence or decision support systems today incur significant costs and time delays in developing report templates and in writing programs to meet their needs. As corporations expand their requirements for tracking performance, they are faced with a growing requirement to take account, not only of language, but of the location where reports will be used—the combination being known as a locale. There are many aspects to the problem, all of which must be managed in order to have a successful solution. These include:
Many business intelligence applications rely on the proper identification of the locale and use the locale information to determine language and other location specific parameters for the production of reports. The locale is also used to customize application behavior. For example, when the locale-sensitive date format function needs to format a date, it uses the convention appropriate to the current locale. If the locale is English, it uses the word “Monday” and if it is French, it uses the word “Lundi”. Thus a locale identifies a language used in a particular region for the purposes of localization. A locale also identifies a group of users who have similar cultural and linguistic expectations for user interfaces (and the kinds of data they process).
In the past many of the issues related to the preparation of reports in multiple languages have been ignored or in some cases have been addressed through the expensive option of custom application programming. Therefore, the preparation of reports in multiple locales remains problematic and expensive.
For the foregoing reasons, there is a need for improved support for multiple languages for multinational corporations requiring a standardized reporting solution.
The invention provides a method for producing reports in a computer-based business intelligence application using client-server technology, having at least one client, and employing a data access language to retrieve business data from one or more data sources.
The present invention comprises the steps of presenting a user with a list of valid product locales, accepting from the report author user a selected product locale, thereby determining the localized user interface at a client for authoring and using report specifications, presenting a localized user interface to the report author user, thereby allowing the report author user to work in the language of their choice, generating a report specification, deploying the report specification, presenting a consumer user with a list of valid content locales, accepting from the consumer user a selected content locale, thereby determining the data in the one or more data sources to be used in the report resulting from applying the report specification and the format of the resulting report, running the report using the report specification, the selected content locale, and the one or more data sources to produce a report output and displaying the report output.
The present invention provides an effective and commercial solution to these issues through configuration and feature options, that is a complete application for producing business reports. The required support is supplied as ‘out of the box’ features that are not available in other known products.
An embodiment of the invention provides for defining locale mappings and mapping a locale from an unsupported locale to supported locale.
A further embodiment of the invention provides for defaulting to a valid locale for users with incomplete or invalid locale specifications, and for specifying object names, descriptions, and tips in multiple languages.
An embodiment of the present invention provides for multilingual (i.e. multi-locale) objects such as report titles, column titles, and column descriptions to be specified in the metadata model such that users automatically see them in their own language. A report is produced in the language preferred by the consumer with no authoring effort.
Embodiment of the present invention thus provides a true multilingual reporting environment supporting both report authoring, and query and usage by users, operating concurrently in different languages. The locale mechanism does not require an application to know in advance which locale is to be used and this makes the job of report authors simpler. The above objectives are achieved without the need for custom programming thereby simplifying the widespread adoption of corporate standards of reporting across large organizations.
Embodiments of the invention are described with reference to the following drawings.
The following glossary of terms will assist in understanding the present invention. It includes specific information about embodiments of the invention.
Locale:
A locale is generally defined as the combination of a language and an optional region. For the purposes of this discussion locale consists of one or more pieces of ordered information, although other information may be added. IETF RFC 3066 recommends using the ISO standard language abbreviations (ISO 639) and ISO standard region abbreviations (ISO 3166). Examples of locale names are fr (French), de-ch (German spoken in Switzerland), or en-us (English spoken in the United States of America).
Language code: The languages are specified using a two- or three-letter lowercase code for a particular language. For example, Spanish is “es”, English is “en” and French is “fr”. The various language codes that are used are defined according to ISO639.
Country code: There are often different spellings within the same language; for example, colour vs. color, neighbour vs. neighbor, in the UK and US respectively. A country code is used to specify the one to use. The various country codes that are used are also defined according to ISO3166.
Embodiments of the invention allow both report authors and consumers (users of reports) operating in their choice of interface language to have full access to content (data) in that language, or in any one of a number of languages. Embodiments of the invention allow for two or more locales. One, a product locale, affects the user interface that is supplied by the product vendor and used by report authors to develop report specifications, and another, a content locale, affects the content (business data) that is supplied by the customer and employed by consumers to produce particular reports. In some embodiments a run locale is also defined: This is a validated content locale (see later). Administrators are able to configure various languages and default options. In embodiments of the invention, the different locales are recorded (in a cache) as a user preference.
Some embodiments ensure that each locale preference is assigned a default locale. In some of these embodiments the default for the appropriate locale is the user's preference for locale as set in their browser or client environment. For example, in Microsoft Internet Explorer™, the browser locale is found in the menu: Tools—>Internet Options—>Languages. In these embodiments, in the event that the browser locale is not valid, means are provided to allow an administrator to define mappings from arbitrary locales to supported product and content locales.
Product Locale:
A product locale defines the appearance (language, layout, data format, etc) of the product user interface. A user can only select from a list of valid locales. In some embodiments, if no selection is made, the system applies a default.
Embodiments of the invention support multiple product locales allowing the creation of different report author user interfaces for different languages such as English and Japanese. Other embodiments use the locale to handle any spelling differences in dialects, such as between US English and UK English.
Framework manager is the tool used to build the metadata model, define its objects, and publish the metadata model to the content manager. In some embodiments of the invention, the product locale, in addition, affects the appearance (language) and format of the names, description, tips, and like objects of the content manager and the framework manager.
Content Locale:
A content locale is used to modify the appearance and format of the content of reports as well as to ensure the right data is extracted from the data source. Formatting (rendering) of data occurs once the appropriate data has been retrieved from the data source. Embodiments of the invention support multiple content locales allowing the creation of reports that are locale dependent.
Report authors or consumers (either directly or via client environment settings) may inadvertently choose locales that are either invalid or unusable. Some embodiments therefore provide the ability to map arbitrary locale values to locale values that are supported/valid in the environment, either in the user Interface of the user (product locale) or with respect to the customer's data (content locale). The content locale, once validated, is sometimes known as the run locale. The configuration section below discusses other aspects of locale configuration.
An appropriate multilingual framework manager and metadata model permit extraction of multilingual data from the data source. One such suitable environment is provided by a modified version of that described in U.S. Pat. No. 6,609,123 “Query engine and method for querying data using metadata model”—Cazemier, et al, hereinafter “Cazemier.”, “Cazemier” provides a query engine for formulating a query to obtain data from one or more data sources using a client application receiving user inputs and a metadata model, which contains model objects that represent the data sources. The query engine comprises a query specification interface for allowing the client application to generate a query specification based on a user input, and receiving the generated query specification. The query engine also comprises a query engine component for translating the query specification into a data source query that is applicable to the data sources, based on model objects in the metadata model having business intelligence. “Cazemier” also provides a method for formulating a query to obtain data from one or more data sources using a client application receiving user inputs and a metadata model containing model objects that represent the data sources. This method includes generating a query specification based on a user input using the client application; receiving the generated query specification; and translating the query specification into a data source query that is applicable to the data sources, based on model objects in the metadata model having business intelligence.
Turning now to
We next briefly described, with reference to
Embodiments of the invention introduce prompts and other mechanisms to allow the user to select or establish run-time parameters. These embodiments allow the selection of database elements that are to be driven from the run-time parameters using mapping rules in the model. In this way a single model or report can handle any variability that might be determined (or defined) using run-time or user-selected parameters. The variable factors include, but are not limited to, user selected prompt responses, report language, database instance, and test environments. The parameters are incorporated into the model (encapsulated) during the model development phase. The report authors produce report templates suitable for a variety of audiences, for example where they all have a common theme. The report authors need know nothing about run-time parameters in producing report templates.
In embodiments of the invention, a number of forms of “macro” style text substitution are introduced into objects of the metadata model on which report authoring is based: in particular, session parameters, and parameter maps. These macro elements are expressed in a syntax that can be detected and acted upon appropriately by the query (generation) engine, which incorporates a macro-expanding pre-processor.
In the resultant syntax, the expressions, or rather partial expressions, to be substituted in the so-called “macrotized” SQL expressions are distinguished by special symbols bracketing the partial expressions. These symbols are carefully chosen to allow the pre-processor to unambiguously identify the partial expressions. In one embodiment, the chosen special symbols are “#”. For example:
#<expression_to_be_substituted>#.
Alternative special symbols may be used, providing they are compatible with the syntax of the database language. In other words, such symbols should not be part of the original database language nor should they be in its reserved symbol dictionary. In some embodiments, partial expressions may be nested, in which case it has been found convenient to introduce the inner levels of macro using one or more other special symbols. For convenience these symbols may also be required to be compatible with the database language syntax, although, with careful design of the parser within the pre-processor this may not be necessary. This nesting is also known as de-referencing and is useful in situations where a session-parameter may point to a parameter-map-entry and vice versa.
All embodiments of the invention given here are described in terms of SQL and relational databases using simple examples of situations where use of the invention is advantageous. However, it will be apparent to those appropriately skilled in the art that the invention is applicable to more complex environments, to databases other than relational ones, and to programming languages other than SQL.
In one example embodiment, the user is able to select a language code (say English, German, or French: en, de, or fr) at run time; that is, when an actual business report is generated. The selection of the language code allows the name of an item in a sales catalogue to be expressed in the chosen language, viz.: dishwasher, Spülmaschine or lave-vaisselle, respectively.
To achieve this result, that part of the SQL expression describing the projection list (or derived column list) for a database query results in a parameter map lookup based on a language code selected at run time. This parameter map defines the relationship between the language codes (designating for example English, German, or French: en, de or fr) and the columns containing the required data for that language. Thus, the name of an item in a sales catalogue is expressed as a literal string in a particular language: that is “dishwasher”,“Spülmaschine”, or “lave-vaisselle” as appropriate for English, German, or French. At run time, the language code is mapped to the column name, which is then substituted in to the SQL statement before the query is run.
In this embodiment, string processing is performed on the macrotized SQL expressions using an SQL pre-processor. The resultant valid SQL expressions are then passed, via the main query engine function, to the database engine.
In this simple embodiment, the macrotized SQL expression as generated by the report author looks like this code fragment:
A table of locales provides a translation for the #$locale# string to substitute in the macrotized SQL expression to produce a valid expression.
The macrotized SQL expressions, and associated tables may be retained in a report outline for later use.
The particular entry used from this table is based on one of a number of parameters that are set for this environment/session, as described below. In this case, when the SQL pre-processor is invoked with locale =“_en”, the result is the following fragment of the SQL statement:
The selection of the appropriate locale string is achieved using techniques such as indexing into the table of locales, the index value being that appropriate to the language chosen for the session, although other equivalent mechanisms may be used. In this way, other languages may be selected during execution of a report depending on the user's locale without the user being involved in manipulating the syntax of the database access language. However, this particular embodiment requires that each of the columns defined by partname#$locale# be constructed with a strict syntax, which provides scope for error.
The flowchart of
In other embodiments, to overcome some of the restrictions of the earlier embodiment, the fragment of the macrotized SQL expression looks like:
Here, the table used to replace the #$part_locale{$locale}# partial expression contains the complete translation of the field name, keyed on the locale, thereby allowing more flexibility in the assignment of the field names. This is shown clearly in the
The parameter map function effectively introduces another level of ‘indirection’. It has the advantage that the entire expression is defined within a single parameter map (or table). A session parameter, established for each session, is used to determine the appropriate entry (Key and Value) in the table. The resultant SQL expression is the same as the previous example:
In all embodiments, the table or tables determined by the partial expression between the special symbols, e.g. #$part_locale {$locale}#, must contain syntactically correct partial expressions and field names for substitution into the SQL statements as required.
The above example embodiment of the invention allows a single report and model to handle many user languages.
In a further embodiment, the model element that describes the connection to the database is formed from a parameter map lookup based on a session variable that selects between test mode and production mode. This map defines the database connection for each mode. At run time, the mode is mapped to the database connection information, which is used to connect to the appropriate database.
For example the fragment of the macrotized SQL expression is:
where $part_source is a session parameter that should contain the name of a table, which is then substituted during pre-processing. In these embodiments it is required that all of the alternative databases contained in the sources table be compatible.
In this example the method described allows report authors to produce a single report and model to handle both the test and production models. Subsequently, no effort is required on the part of the report users who rely on their locale to insulate them from the underlying substitutions and conversions.
In the following embodiment of the invention the user is prompted to supply more information than can be ascertained from the data already available.
The first code snippet is the definition of an element requiring user input. gcol defined as:
At run time, this results in the following snippet of code. Here the user must provide at least some of the information required.
In further embodiments, the system provides default input if the user chooses not to provide any.
For convenience, the following sections describe some more interesting aspects of a Macro syntax used in one embodiment of the macro specification. In practice, many variations are possible. The macros are used to create runtime driven fragments of query code and provide a means to manipulate strings and string expressions.
Session Parameters (or Model Parameters)
Parameter Map Entries
These fragments rely on the existence of a table like the following:
In the second fragment, the parameter used is an assumed global variable, $runLocale, previously initialised appropriately.
Parameter Map
% map Evaluates to a reference to the specified map, not just a single entry.
This provides all roles of the current user as a comma-separated list.
It makes reference to a table, like the following:
Complex Functions
CSVIdentityName returns a comma separated values list of the identity information remapped through the specified table.
In use this might result in:
The Macros defined in embodiments of the invention provide partial expressions that can be used directly within database languages expressions, or within related Filters and Calculations.
Some functions take in a whole parameter map as an argument. This is expressed using the ‘%’ character instead of the ‘$’ character to precede the name of the map
For example:
As with many macro languages, additional control structures such as if-then-else, for-loop and do-while-loop, can be added, as well as array structures. Users (designers) are able to define and provide additional functions, which can also be extended to be more than a single statement.
As illustrated in
It should be noted that a user might be an administrator, a report author, or a consumer, or any combination. It is only the user's competence that restricts their role. Hence the generic term user may replace the specific role titles.
We now further describe the embodiments of the invention with reference to
In the second step 520 a consumer simply requests that the report be run. Finally, the data, as defined by the report specification, is extracted 530 and a report produced 540 that meets both the corporate reporting requirements and the consumer's needs as specified by the content locale, and the sequence ends 550. In most situations, the steps 520, 530 and 540 may be repeated as required.
In some embodiments, a simplified user interface is provided at the second step to allow the consumer some degree of control over what particular data should be displayed (e.g. the products selected, or the time period covered).
Examples of each of these steps will now be described in more detail with reference to a practical example. Consider two collaborating report authors working in different languages, but charged with producing a corporate report format. Each author is able to logon and work independently.
The report authors each choose to work in one of a number of languages supported by the report authoring part of the multilingual business intelligence system. The language selection is made according to their individual preference, based on such things as skill level, or familiarity. This language is used as the product locale for that report author. During this development phase, the report authors may exchange the report specification as a work-in-progress. Using the same data source with its associated metadata model and a report server with its extended SQL capabilities, the collaborators will see the same report format, but rendered in their choice of language as selected at logon or as selected during the work session. In some cases, as a default, the browser or client environment locale is used. Note that, were the report authors to run the report specification with test cases against a test data source, they would see the resultant report according to their selected (or preferred) content locale.
When the report authors have finished their collaborative development a report specification is generated ready for deployment. Consumers using this report specification in any of the corporation's locations can, by selecting one of the supported content locales, view that report in their language of choice, again using the same data source (although in this case, it would be a production source, rather than some test/development source). Consumers need not be concerned with which locale is used during selection of data, and can produce reports in any of the supported locales with ease. The consumers carry out the same (or equivalent) operations as in previous products, but the resulting reports are made available or usable in any of the supported locales.
Embodiments of the invention provide for multilingual (multi-locale) columns. This is allows for report-specific data items that require calculations. These items are not part of the metadata model.
Application strings include information such as titles of reports that are not derived from the business data source directly. These strings must ultimately be provided by literal translation. In embodiments of the invention, they are supported so that when the report is run, the content locale ensures that the correct language is used, i.e. that of the consumer's preference. This remains true no matter where the report was authored (as defined by the product locale).
In various places in this description expressions like ‘A is mapped to B’ are used. These are to be treated as shorthand for ‘Locale value A is replaced by locale value B based on an algorithm and any configuration data required by that algorithm’. Embodiments of the present invention use an algorithm that performs a lookup on a key/value table, using A as the key for the search. Other mechanisms are possible.
Configuration
In embodiments of the invention the various languages or locales and their defaults are configurable in the user interface, usually by an administrator.
Some examples of configuration options are listed below.
Product Locale:
Embodiments of the invention allow the removal of one or more of the installed product locales from the user interface. This permits simplification of the user interface in cases where users are known to require only a subset of the available user interface locales.
Content Locales:
Embodiments of the invention allow the removal of content locales in the user interface. This permits simplification of the user interface in cases where users are known to require only a subset of the available content locales. In other embodiments the addition of new content locales is supported so that users may customize the product, although in such cases, the language support is the customers responsibility.
Product Locale Mappings:
Embodiments of the invention allow mapping of full product locales to an available product locale, that is one for which some degree of support is provided. For example, if it was known that Vietnamese users generally preferred French as their default, Vietnamese can be mapped to French. An individual user can still select a specific product locale of Vietnamese in the user preferences if French is not desired.
Content Locale Mappings:
Embodiments of the invention allow various mappings of full content locales. Full content locales may be mapped to language-only locales (e.g. en) to permit access to content which is language sensitive but not locale sensitive. Note that, names and descriptions within the data source are generally specified by language (e.g. en English, fr French, etc.) not locale (e.g. en-ca English Canada, en-us English USA).
Some embodiments of the invention include data formatters that render appropriate formats for dates, times, numbers, etc., inferred from the content locale. In some of these embodiments, language-only content locales (e.g. en) may be mapped to a default complete locale (ex. en-us) to improve access to content that is locale sensitive. For example, data format of dates and numbers requires a full locale as the data formatting is derived or inferred from the combination of language and region. This permits reports formatted in one locale to be easily ported to another where the formatting of certain data differs, but otherwise there is a high degree of commonality. The format depends on the content locale that is selected prior to running (or generating) a report.
In some embodiments, unsupported content locales are mapped to supported content locales.
The following example further illustrates embodiments of the invention. Consider an international company that stores its Product and Customer information in both French and English tables. The company stores its Order information only in an English table. Parameters are used to create conditional query subjects that allow for substitutions at report run time. Parameter maps that are similar to data source look-up tables are provided. Each parameter map has two columns, one for the key and one for the value that the key represents. Keys and values can be manually entered, imported from a file, or based on existing query items in the model. All parameter map keys must be unique so that the framework manager can consistently retrieve the correct value. In some embodiments the value of a parameter can be another parameter. By creating and using the following parameter maps, the administrators and report authors ensure that consumers can retrieve data that matches the information they require.
The following intermediate code fragment (with macro-like elements) results in the retrieval of the code and description data that matches the defined parameter values:
If the value of the contentLocale parameter is fr, after substitutions this expression results in this code fragment:
In embodiments of the invention, multilingual data is accessed by the query engine by modifying the SQL used to access the data source query subjects (tables). In preferred embodiments, the modifications are in the form of macro-like extensions to the syntax as described earlier. These extensions cause the resultant SQL queries to access the data appropriate to the content locale/language. Other equivalent mechanisms may be used.
Any hardware, software or a combination of hardware and software having the above-described functions may implement the multi-lingual capabilities according to the present invention and methods described above. The software code, either in its entirety or a part thereof, may be in the form of a computer program product such as a computer-readable memory having the system and/or method stored therein.
Furthermore, a computer data signal representation of that software code may be embedded in a carrier wave for transmission via communications network infrastructure. Such a computer program product and a computer data signal are also within the scope of the present invention, as well as the hardware, software and combination thereof.
Although the present invention has been described in considerable detail with reference to certain preferred embodiments thereof, other versions are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred embodiments contained herein.
Implementation Notes
Multilingual Databases
Any of several techniques may be used to manage multilingual information in databases. The normal case is that textual information associated with a code, for example a product description, is recorded in several different languages. Two such general techniques are ‘coded row’ and ‘separate columns’.
In the ‘coded row’ technique illustrated in the following table each different language is assigned a separate row, in this case three such rows are shown and effectively a table row relating to a part number entry is replicated accordingly. A expression filtering on the query item Locale Language can then be used to extract the appropriate description.
In
the ‘separate columns’ technique illustrated in the next table, each of the three languages is assigned a separate query item (or column), which is known. In this case, only one table row is required per part number entry.
Other equivalent techniques are well known and may be used. The metadata model used with embodiments of the present invention must support the chosen technique so that a user running the same report sees the product description in their own language, with no work or intervention required by either the report author or the consumer. The use of distinct content locales also allows for a product description seen in England (e.g. en-gb (Great Britain) to differ from that seen in the USA (e.g. en-us) for a report resulting from the same report format.
Query Subjects and Query Items
Query subjects and query items are defined within the metadata model in terms of references to tables and columns in the data source (database). In some respects the terms may be considered synonymous with tables and columns, but in fact the metadata model and its associated framework manager hides from the user the translation of the underlying references into the objects used in populating reports with data.
Data Formats
Embodiments of the invention make use of well-known data formatting libraries (such as the International Components for Unicode (ICU) libraries) to provide a wide-ranging set of locale default formats for numbers, dates (short, long, complete and abbreviated), times, intervals, etc as well as allowing customized complete data formatting patterns.
Embodiments of the invention provide HTML Form controls that automatically adjust to accept numbers, dates, times, intervals and other measures in the user's locale format.
Configuration Implementation Details
The following procedures are available in some embodiments:
normalizeLocale( ):
Performs text manipulations on the locale string:
Returns true if the specified locale string is in the list of supported content locales/product locales, respectively. mapContentLocale( )/mapProductLocale( )
Maps the specified locale to a new locale, based on the map in the configuration.
In summary, configuration parameters include the following Site Locale Tables:
The configuration tool manages these entries, giving the customer the ability to extend or modify these lists. The configuration tool can validate any target locale against ICU to ensure that they are valid locales.
The Configuration API provides the following functions:
The Configuration is initialized with these tables plus the server locale at the same time it retrieves other runtime parameters. Note that unlike runtime parameters these do not have to be refreshed, as they do not change for the life of the process. Each process level service will receive these along with runtime parameters and initialize Configuration API accordingly.
Session Initialization
Content Manager populates the product locale and content locale for a user session by:
All “allowable” locale values are mapped using the Content Locale Mapping Table.
In case the locale configuration settings were updated after values were previously persisted in Content Manager, Content Manager normalizes the product locale and content locale values each time they are retrieved from the account object within the content store, and then maps the values using the Product Locale Mapping Table or the Content Locale Mapping Table as appropriate. Similarly, values retrieved from an external authentication (third party directory) provider are normalized and mapped each time they are retrieved.
User Preferences
The user interface logic:
The Content Manager updates the session values for product locale, content locale, format, and time zone whenever it receives a request to update these settings.
User Interfaces
The user interface specification for ReportNet include tags to indicate which UI elements are driven by product locale, and which are driven by content locale.
Report Layout
The current report layout specification allows for:
All messages returned to users are in the user's product locale.
Matching Rules for Locales
In all contexts, once a locale preference has been determined, the locale to be selected from the list of available locales in that context is determined as follows:
In some embodiments, various mechanisms are used for locale initialization:
These mechanisms are described in more detail below.
Content locale and product locale are treated as two independent values—one is not derived from the other.
Pre-Authentication
The user's locale settings are determined using the following steps:
The user's locale settings are determined using the following steps:
Once the normalized (not the mapped) values of the user's product and content locales are determined, they are used throughout the session.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5301109 | Landauer et al. | Apr 1994 | A |
| 5530861 | Diamant et al. | Jun 1996 | A |
| 5551055 | Matheny et al. | Aug 1996 | A |
| 5579444 | Dalziel et al. | Nov 1996 | A |
| 5652884 | Palevich | Jul 1997 | A |
| 5687366 | Harvey et al. | Nov 1997 | A |
| 5758355 | Buchanan | May 1998 | A |
| 5767854 | Anwar | Jun 1998 | A |
| 5787452 | McKenna | Jul 1998 | A |
| 5794246 | Sankaran et al. | Aug 1998 | A |
| 5802352 | Chow et al. | Sep 1998 | A |
| 5870746 | Knutson et al. | Feb 1999 | A |
| 5873111 | Edberg | Feb 1999 | A |
| 5907326 | Atkin et al. | May 1999 | A |
| 5917484 | Mullaney | Jun 1999 | A |
| 5937155 | Kennedy et al. | Aug 1999 | A |
| 6018742 | Herbert, III | Jan 2000 | A |
| 6067548 | Cheng | May 2000 | A |
| 6160549 | Touma et al. | Dec 2000 | A |
| 6195653 | Bleizeffer et al. | Feb 2001 | B1 |
| 6260050 | Yost et al. | Jul 2001 | B1 |
| 6341286 | Kawano | Jan 2002 | B1 |
| 6349275 | Schumacher et al. | Feb 2002 | B1 |
| 6430584 | Comer et al. | Aug 2002 | B1 |
| 6457008 | Rhee et al. | Sep 2002 | B1 |
| 6460031 | Wilson et al. | Oct 2002 | B1 |
| 6469713 | Hetherington et al. | Oct 2002 | B2 |
| 6487546 | Witkowski | Nov 2002 | B1 |
| 6496793 | Veditz et al. | Dec 2002 | B1 |
| 6542515 | Kumar et al. | Apr 2003 | B1 |
| 6567814 | Bankier et al. | May 2003 | B1 |
| 6581068 | Bensoussan et al. | Jun 2003 | B1 |
| 6697999 | Breuer et al. | Feb 2004 | B1 |
| 6768994 | Howard et al. | Jul 2004 | B1 |
| 6785689 | Daniel et al. | Aug 2004 | B1 |
| 6845367 | Bendel et al. | Jan 2005 | B2 |
| 6871319 | Taboada et al. | Mar 2005 | B2 |
| 6882353 | Nettles et al. | Apr 2005 | B2 |
| 6892348 | Truelove et al. | May 2005 | B1 |
| 6980963 | Hanzek | Dec 2005 | B1 |
| 7015911 | Shaughnessy et al. | Mar 2006 | B2 |
| 7139686 | Critz et al. | Nov 2006 | B1 |
| 7140001 | Natori et al. | Nov 2006 | B1 |
| 7177859 | Pather et al. | Feb 2007 | B2 |
| 7207005 | Lakritz | Apr 2007 | B2 |
| 7213202 | Kagle | May 2007 | B1 |
| 7228353 | Franceschelli et al. | Jun 2007 | B1 |
| 7240073 | Benson et al. | Jul 2007 | B2 |
| 7356758 | Bedell et al. | Apr 2008 | B1 |
| 20020069230 | Schubert et al. | Jun 2002 | A1 |
| 20020073080 | Lipkin | Jun 2002 | A1 |
| 20020099743 | Workman et al. | Jul 2002 | A1 |
| 20020143831 | Bennett | Oct 2002 | A1 |
| 20020174000 | Katz et al. | Nov 2002 | A1 |
| 20020174196 | Donohoe et al. | Nov 2002 | A1 |
| 20020175937 | Blakely et al. | Nov 2002 | A1 |
| 20020184308 | Levy et al. | Dec 2002 | A1 |
| 20020188896 | Filteau et al. | Dec 2002 | A1 |
| 20030046527 | Musuchenborn | Mar 2003 | A1 |
| 20030084053 | Govrin et al. | May 2003 | A1 |
| 20030088447 | Desbiens et al. | May 2003 | A1 |
| 20030088540 | Edmunds et al. | May 2003 | A1 |
| 20030088565 | Walter et al. | May 2003 | A1 |
| 20030140316 | Lakritz | Jul 2003 | A1 |
| 20030144922 | Schrantz | Jul 2003 | A1 |
| 20030172168 | Mak et al. | Sep 2003 | A1 |
| 20030217063 | Tomic et al. | Nov 2003 | A1 |
| 20040002972 | Pather et al. | Jan 2004 | A1 |
| 20040030781 | Etesse et al. | Feb 2004 | A1 |
| 20040060001 | Coffen et al. | Mar 2004 | A1 |
| 20040088650 | Killen et al. | May 2004 | A1 |
| 20040139102 | Vierich et al. | Jul 2004 | A1 |
| 20040139426 | Wu | Jul 2004 | A1 |
| 20040221233 | Thielen | Nov 2004 | A1 |
| 20040236738 | Thier et al. | Nov 2004 | A1 |
| 20040243593 | Stolte et al. | Dec 2004 | A1 |
| 20050010550 | Potter et al. | Jan 2005 | A1 |
| 20050033600 | Geddes et al. | Feb 2005 | A1 |
| 20050131924 | Jones | Jun 2005 | A1 |
| 20050177532 | Desbiens | Aug 2005 | A1 |
| 20050198042 | Davis | Sep 2005 | A1 |
| 20050228815 | Carus et al. | Oct 2005 | A1 |
| 20060004745 | Kuhn et al. | Jan 2006 | A1 |
| 20060080082 | Ravindra et al. | Apr 2006 | A1 |
| 20060200448 | Edmunds et al. | Sep 2006 | A1 |
| 20060259509 | Stolte et al. | Nov 2006 | A1 |
| 20070130503 | Voshell | Jun 2007 | A1 |
| 20070150241 | Critz et al. | Jun 2007 | A1 |
| 20070225966 | Suen et al. | Sep 2007 | A1 |
| Number | Date | Country |
|---|---|---|
| 2 410 277 | Nov 2001 | CA |
| 2361176 | May 2003 | CA |
| 0042553 | Jul 2000 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20060004738 A1 | Jan 2006 | US |
