Title of Invention

METHOD OF FORMING SEARCHABLE STORE OF INFORMATION ABOUT PHYSICAL PRODUCTS

Abstract The present invention provides a method of forming a searchable store of information about physical products, the method comprising: (a.) providing data storage; (b.) providing a computer program product comprising: computer- readable medium; a reusable software unit stored on the computer-readable medium, the software unit comprising a plurality of product objects and a product manager for performing searches, each product object representing information for a generic product; a set of metadata rules stored on the computer-readable medium; and a set of search rules stored on the computer-readable medium; (c.) combining the software unit with other software to form a software application; (d.) creating product specifications for the specific physical products using the metadata Riles; (e.) storing the product specifications in the data storage using the product objects; (f.) creating a search configuration in accordance with the search rules; and (g.) wherein the product manager in the software application is operable to perform searches of the product specifications using the product objects, the searches being performed in accordance with the search configuration.
Full Text METHOD OF FORMING SEARCHABLE STORE OF INFORMATION
ABOUT PHYSICAL PRODUCTS
Background of the Invention
[0001] The field of the invention relates generally to data processing, and more
specifically to method of forming searchable store of information about physical.
[0002] Java 2 Platform, Enterprise Edition (J2EE) is a set of technologies and
specifications developed by Sun Microsystems and supported by many computer and
software vendors. J2EE is an. environment for developing and deploying enterprise
applications. The J2EE platform includes a set of services, application programming
interfaces and protocols that provide the functionality for developing multi-tiered, web-
based applications. :.
[0003] J2EE applications are made up of components. A J2EE component is a self-
contained, functional software unit that is assembled into a J2EE application with its
related classes and files and that communicates with other components. The J2EE
specification defines the following J2EE components: (1) application clients and applets
that run on the client; (2) Java Servlet and JavaServer Pages (JSP) technology
components that run on the server; and (3) Enterprise JavaBeans (EJB) components that
run on the server.
[0004] J2EE components are assembled into a J2EE application verified to be well-
formed (i.e., syntactically correct) and in compliance with the J2EE specification, and
deployed to production, where they are run and managed by the J2EE server.
Deployment is the process whereby software is installed into an operational environment.
Deployment descriptors (DDs) are XML files provided with each application that
describes how the application should be deployed. DDs are used by the J2EE runtime
execution environment to provide and enforce the quality of service attributes described
in the DD.
[0005] An enterprise bean is a component .that implements a business task or business
entity and resides in an EJB, container, either as an entity bean, a session bean, or a
message-driven bean. A container is a standardize runtime environment that provides
specific, component services. An entity bean represents persistent data maintained in a
database. An entity bean can manage its own persistence or delegate this function to its
container. An entity bean is identified by a primary key. A primary key in an EJB is the
subset of its .attributes that, are guaranteed to be unique..Persistence mechanisms in EJB
containers are closely tied to databases. Entity beans map cleanly to tables. Each column
maps to an attribute and each row maps to an entity. If the container hosting the entity
bean crashes, the entity bean, its primary key and any remote references survive the
crash. A message-driven bean is an asynchronous message consumer. A message-driven
bean has.no state for a.specific client,:but its.instance variables may contain state across
the handling of. client messages, including an open database connection and an object
reference to a EJB object. A client accesses a message-driven bean by sending messages
to the destination for which the bean is a message listener. A session bean is created by
the client and usually exists only for the duration of a single client-server session. A
session bean performs operations such as calculations or accessing a database for the
client. Although a session bean may be transactional, it is not recoverable should a
system crash occur. Session bean objects can be either stateless or can maintain
conversational state across methods and transactions. If a session bean manages state,
then the EJB container manages this state if the object must be removed from memory.
However, the session bean object itself must manage its own persistent data.
[0006] Extensible Markup Language,(XML) enables definition of the tags (markups)
needed to identify the content, data, and text in XML documents. It differs from HTML,
in that HTML has fixed tags that deal mainly with style or presentation. XML tags use
angle brackets as delimiters and identify the data rather than specifying how to display it.
The XML approach is to wrap each data item in start/end tags ; i.e., data
. XML documents are well-formed with every tag having an identical
closing tag, and with all tags completely nested. Attributes are bundled in with the start
tag and take the form attribute-name=" attribute-value". XML documents undergo a
transformation into a language with style tags under the control of a stylesheet before it
can be presented by a browser or other presentation mechanism. Typically, XML is
transformed into HTML for presentation. J2EE deployment descriptors are expressed in
XML with schemas defining allowed elements.
[0007] XML Schema Definition (XSD) specifies a formal description for the elements in
an XML document. An XML schema represents the interrelationship between the
attributes and elements of an XML object. The XSD description can be used to verify that
each item of content in a document adheres to the description of the element in which the
content is to be placed. XSD is written in XML and therefore does not require
intermediate processing by a parser. Elements are defined within a set of tags as in XML
or HTML. XSD is also self-documenting. XML schema provide two basic kinds of
datatypes: primitive and derived. A primitive datatype is not defined in terms of other
types. Examples of primitive datatypes are string, Boolean, float, double, decimal, binary,
ID, 1DREF. A derived datatype is defined in terms of existing datatypes. Examples of
derived datatypes built into the XML schema are language, integer, date, time.
[0008] An XML schema includes a preamble followed by declarations. The preamble is a
group of at least three attributes within the element. The different possible
attributes are name, ref, type, use, value, id and form. The declarations allow the
description of datatypes, element types, element attributes and content models. XML
schema provide two types of datatype definitions. Simple definitions are used to create
derived datatypes; complex definitions are used to describe content models. A simple
type definition is a set of constraints on the value space and lexical space of a datatype. A
complex type definition is a set of attribute declarations and a content type that pertain to
the attributes and children of the element that is being specified. An
declaration associates an attribute name with a specific simple datatype. An
declaration provides a description that can be used for validation, provides value
constraints, establishes coristraining relationships between related elements and attributes.
An element may contain annotation elements, datatype declarations (simple of complex),
and related child elements. An element has a number of different possible attributes
including name, ref, type, minOccurs, maxOccurs, default, fixed and id. The attributes
minOccurs and maxOccurs describe the cardinality of child elements. The attribute
minOccurs represents the minimum number of occurrences allowed; maxOccurs
represents the maximum number of occurrences allowed with the default value the same
as the value of mrnOccurs if no value is specified.
Summary of the Invention
[0009] The generic product finder system is a Java 2 Platform, Enterprise Edition (J2EE)
component that provides the capability of managing and performing searches on
configurable products. In the context of the present invention, configurable products
includes any type of product that can be described in a specification and stored
electronically in a computer database. Configurable products include any product that
has been configured using the techniques described herein. Internally, the product finder
represents products with a specification divided into parameters representing
characteristics and optional attributes. This specification exists in a generic state by the
use of Java objects.
The present invention provides a method of forming a searchable store of
information about physical products, the method comprising: (a.) providing data
storage; (b.) providing a computer program product comprising: computer-
readable medium; a reusable software unit stored on the computer-readable
medium, the software unit comprising a plurality of product objects and a product
manager for performing searches, each product object representing information for
a generic product; a set of metadata rules stored on the computer-readable
medium; and a set of search rules stored on the computer-readable medium; (c.)
combining the software unit with other software to form a software application;
(d.) creating product specifications for the specific physical products using the
metadata rules; (e.) storing the product specifications in the data storage using the
product objects; (f.) creating a search configuration in accordance with the search
rules; and (g.) wherein the product manager in the software application is operable
to perform searches of the product specifications using the product objects, the
searches being performed in accordance with the search configuration.
Description of Drawings
[00012] The invention is better understood by reading the following detailed description
of the invention in conjunction with the accompanying drawings, wherein:
[00013] Fig. 1 illustrates a system component diagram of the generic product finder
system in accordance with an exemplary embodiment of the present invention.
[00014] Figs. 2A - 2D illustrate the product schema definition for the generic product
finder in accordance with an exemplary embodiment of the present invention.
[00015] Figs. 3A - 3C illustrate the product search configuration XML schema definition
in accordance with an exemplary embodiment of the present invention.
[00016] Figs. 4A - 4C illustrate a sample product specification configuration in
accordance with an exemplary embodiment of the present invention.
[00017] Figs. 5A - 5B illustrate a default search configuration in accordance with an
exemplary embodiment of the present invention.
[00018] Figs. 6A - 6B illustrate a sample product search query in accordance with an
exemplary embodiment of the present invention.
Detailed Description of the Invention
[00019] The following description of the present invention is provided as an enabling
teaching of the invention in its best, currently known embodiment. Those skilled in the
relevant art will recognize that many changes can be made to the embodiment described,
while still obtaining the beneficial results of the present invention. It will also be
apparent that some of the desired benefits of the present invention can be obtained by
selecting some of the features of the present invention without using other features.
Accordingly, those who work in the art will recognize that many modifications and
adaptations to the present invention are possible and may even be desirable in certain
circumstances, and are a part of the present invention. Thus, the following description is
provided as illustrative of the principles of the present invention and not in limitation
thereof, since the scope of the present invention is defined by the claims.
[00020] Fig. 1 illustrates a system component diagram of the generic product finder
system in accordance with an exemplary embodiment of the present invention. The
generic product finder system 10 is a J2EE component that provides the capability for
performing and managing searches (manager component 20) on configurable products
that can be described via a software specification. The product's specification is in rum
defined by XML metadata (product metadata XML 50) that is configured when the
component is integrated with an application. Multiple product specifications may co-
exist and their information is persisted (data storage 30) by the use of entity beans. This
J2EE component also contains a session bean that acts as manager and single point-of-
entry to the product information. Since the products are maintained in a generic form,
search rules can be constructed (search configuration XML 40) and applied to the product
set 30 (as a whole) to perform complex queries (query XML specification 60). An
example of such a query would be to find the lowest cost-to-manufacture product, where
the product matches 90% of the specification provided in the query. The output from the
complex query is a fist of matching products 70.
[00021] The product finder system 10 represents products by a set of parameters (also
known as the "specification") that are divided into characteristics and optional attributes.
Internally, hashmaps are used to store the specification for a product instance as Java
objects (products 30). The product specification is a set of information whose type and
semantics are unknown. A separate set of product metadata 50 is to be configured in
XML. This XML metadata 50 is used by the product finder system 10 when inspecting
the contents of a product instance (products 30). The XML metadata 50 allows for
deciphering this generic information into something concrete to work with. Multiple
types of products may be defined in the XML and can co-exist in the persisted data 30. In
their natural state there is no distinction among persisted products 30.
[00022] Now that generic products 30 can be stored and maintained in the product
manager 20, complex queries need to be constructed for retrieving products. By complex
queries, it is meant that behavior other than a simple "is equal" on the entire product can
be initiated. The complex queries are determined by search rules, which may include any
of the following, alone or in combination:
(1) incomplete specifications;
(2) request for incomplete matches;
(3) ordering results based upon specific parameters;
(4) granularity of match behavior defined at parameter level (describe
below);
(5) ability to provide tolerances for determining matches per
parameter;
(6) matching parameters based upon strictly equal, within a supplied
tolerance (for numeric parameters), below a defined threshold (for
numeric parameters); or
(7) presence in a subset of equivalent objects.
[00023] In the above list of search rules, granularity of match behavior defined at a
parameter level refers to the fact that the search rules can be configured on the smallest
granularity of a parameter, as opposed to rough granularity on the entire search
specification. For example, one search configuration may indicate that a specific
parameter: (1) has irregular data normalized, (2) is required to be matched for inclusion
in partial match search results, (3) is given a default value to match if a value is not
specified in a search query, (4) is considered a match if the numeric value does not
exceed a threshold, and/or (5) has a low impact weight for intelligent ordering of partial
matches.
[00024] These complex search rules (search configuration 40) can be defined in XML, and
multiple sets of search rules can be applied at different times. The search rules combine
with the product metadata 50 to determine matches 70 between a query specification 60
(supplied by an external query to the product finder) and the set of persisted product
information 30.
[00025] The characteristics that distinguish the generic product finder system 10 are:
(1) A fully self-contained J2EE component that can be dropped into an
arbitrary J2EE application to provide concurrent multiple product
searches and management capabilities.
(2) Development of a self-contained reusable-J2EE component that
can manage and search on an arbitrary product. Such a
component can be distributed and incorporated into any number of
applications that need the capability to persist, retrieve, manipulate
and/or search on a product regardless of the problem domain.
[00026] Figs. 2A - 2D illustrate the product schema definition for the generic product
finder system in accordance with an exemplary embodiment of the present invention.
This XML schema definition defines the rules to be followed when creating product
metadata. In this specific example, the XML schema describes a transformer product that
was configured in the generic product finder system. All product metadata (described in
XML) in this exemplary embodiment must conform to this XML schema definition. The
product manager component 20 controls access to, and manipulation of, the products 30.
The product finder manager component 20 loads the product metadata XML 50 in order
to recognize how to translate generically persisted products 30 into specific products that
it has been configured to support. A default Simple Access Object Protocol (SOAP)
interface is used to access the generic product finder system 10, but the interface can just
as easily be integrated into a J2EE application through the product manager's remote
interface. The Simple Object Access Protocol (SOAP) is a minimal set of conventions for
invoking code using XML and Hypertext Transfer Protocol (HTTP).
[00027] The product schema definition in Fig. 2A includes an annotation element 200 that
describes the schema (e.g., Product Specification Schema) and comments 204 (delimited
by ) that indicate product characteristics are divided into parameters and
accessories. Parameters are used to define core characteristics of the product. Accessories
are used to define add-on optional items. Each attribute is defined by a series of three
space-separated values. The first element in each line is the name of the attribute; the
second element indicates the type of data; and the third element determines the attribute's
default value, if any, and indicates whether or not the attribute is required. A "required"
attribute value must be specified in the document; an "optional" value need not be
specified; a "default" value is the value to use if a value is not specified in the document.
The product specification schema for "parameter type" is indicated at 208 in Fig. 2B. It
includes descriptions of attributes 210 for the "parameter" element with a list of
enumeration values. Also provided in the schema for the "parameter" element are
restricted attributes 212 with a list of enumeration values. The product specification
schema for "accessory type" is indicated at 214 in Fig. 2C. It includes descriptions of
attributes 216 for the "accessory" element with a list of enumeration values. Also
provided in the schema for "accessory" element are restricted attributes 218 (Fig. 2D)
with a list of enumeration values.
[00028] Figs. 3A - 3C illustrate the product search configuration XML schema definition
in accordance with an exemplary embodiment of the present invention. This XSD file
defines the rules that must be followed in defining a set of product search behavior. The
product search, schema definition in Fig. 3A includes an annotation element 300 that
identifies the XML schema as "Product Search Configuration Schema". The comments
302 indicate that many search configurations are possible, with one configuration for
each type of product. Furthermore, product search configurations can be generated
dynamically. The search configuration schema includes a specification for
"requiredToMatch" elements 304 (Figs. 3A - 3B). Comments in this section of the listing
indicate that (1) product characteristics listed are required to be matched, no matter how
close a match is requested; (2) default values are to be used in searching for a
characteristic that has no defined value; (3) data is to be transformed to normalized
values; (4) the type of comparison to use on each characteristic is identified
("SearchGroupingType"); and (5) the weighting to assign each chart eristic in
deterniining how well a close match fits. The "SearchGroupingType" listing 306 (Fig.
3B) includes element declarations for parameters and accessories. The
"SearchParameterType" 308 (Fig. 3B) and "SearchAccesoryType" 310 (Figs. 3B - 3C)
listings specify the parameter and accessory element attributes, respectively. The
"RequiredParameterType" 312 and "RequiredAccessoryType" 314 listings (Fig. 3C)
specify the required parameter and required accessory element attributes, respectively.
[00029] Figs. 4A - 4C illustrate a sample product specification configuration for a
transformer in accordance with an exemplary embodiment of the present invention. It
identifies the product specification as "E_Transformer" 400. Parameter specifications are
provided in section 410 of the listing (Figs. 4A - 4B). Accessory specifications are
provided in section 420 of the listing (Figs. 4B - 4C). Defined parameters for the
transformer include rated power, primary voltage, secondary voltage, impedance voltage,
type of cooling, maximum ambient temperature, preliminary length, width and height
dimensions, frequency, load loss tolerance, etc. Defined accessories for the transformer
include conservator, Buchholz relay, silica gel breather, double contact thermometer,
safety valve, electrostatic screen, protection device, overpressure switch, etc.
[00030] Figs. 5A - 5B illustrate a default search configuration in accordance with an
exemplary embodiment of the present invention. Weight values are defined at the end of
the file. This is used in the intelligent selection process for eliminating partial matches
that are not appropriate in a particular context (i.e., if the match percentage is less than
100 for a particular search). The product search configuration in Fig. 5A identifies the
search configuration for "EJTransformer" 500. The percentage of supplied characteristics
to match has a default value of 100%. The required to match parameters are provided in
section 502 of the search configuration. Rated power (KVA) is listed as a parameter to
match in the product search. Default parameter values for the transformer are provided in
section 504 of the listing. Transformations (i.e., data normalizations) are provided in
section 506 of the listing. The types of comparison to use on different parameters are
listed in section 508 of the listing. The weighting values for various transformer
parameters are provided in section 510 of the listing as shown in Fig. 5B. For example,
rated power (KVA) is given a weighting value of 3. The default weighting value for
transformer parameters is 2.
[00031] Figs. 6A - 6B illustrate an exemplary product search query for transformers using
the invention. Exemplary parameters and corresponding search values are indicated at
610 in Figs. 6A - 6B. The parameters include rated power, primary voltage, secondary
voltage, type of cooling, insulation levels, prehminary dimensions, number of phases,
frequency, load loss tolerance, etc. Accessory descriptions are indicated at 620 in Fig. 6B.
The accessories include hermetically sealed tank, porcelain bushings, standard drain
valve, adhesive rating label, etc.
[000321] It is important to note that although the present invention has been described in
the context of a fully functioning data processing system, those skilled in the art will
appreciate that the mechanisms of the invention are capable of being distributed in the
form of computer program instructions in a variety of forms which when executed on the
data processing system perform the methods described herein. The present invention
applies regardless of the type of signal bearing medium used to carry out the distribution.
Examples of signal bearing mediums include nonvolatile hard-coded mediums such as
read-only memories, recordable type mediums such as floppy disks, hard disk drives and
CD-ROMS, and transmission type mediums such as digital and analog communication
links.
[00033] While the invention has been particularly shown and described with reference to a
preferred embodiment thereof, it will be understood by those skilled in the art that
various other changes in form and detail may be made without departing from the spirit
and scope of the invention.
We Claim :
1. A method of forming a searchable store of information about physical
products, the method comprising:
(a.) providing data storage;
(b.) providing a computer program product comprising:
computer-readable medium;
a reusable software unit stored on the computer-readable medium, the
software unit comprising a plurality of product objects and a product manager for
performing searches, each product object representing information for a generic
product;
a set of metadata rules stored on the computer-readable medium; and
a set of search rules stored on the computer-readable medium;
(c.) combining the software unit with other software to form a software
application;
(d.) creating product specifications for the specific physical products using the
metadata rules;
(e.) storing the product specifications in the data storage using the product objects;
(f.) creating a search configuration in accordance with the search rules; and
(g.) wherein the product manager in the software application is operable to
perform searches of the product specifications using the product objects, the searches
being performed in accordance with the search configuration.
2. The method as claimed in claim 1, wherein the product objects comprise Java
entity beans and the product manager comprises a Java session bean.
3. The method as claimed in claim 2, wherein the product objects represent
information for a generic product by a set of parameters comprising characteristics and
attributes.
4. The method as claimed in claim 3, wherein the parameters are stored using
hashmaps.
5. The method as claimed in claim 1, wherein the specific physical products
are transformers.
6. The method as claimed in claim 1, wherein the set of metadata rules is an
XML schema.
7. The method as claimed in claim 1, wherein the set of search rules is an XML
schema.
8. The method as claimed in claim 1, wherein the set of search rules comprise
weight values to apply to product specifications for ordering of partial matches to
identify specific physical products meeting the search configuration.

Documents:

001083-kolnp-2006 abstract.pdf

001083-kolnp-2006 claims.pdf

001083-kolnp-2006 correspondence others.pdf

001083-kolnp-2006 description (complete).pdf

001083-kolnp-2006 drawings.pdf

001083-kolnp-2006 form-1.pdf

001083-kolnp-2006 form-3.pdf

001083-kolnp-2006 form-5.pdf

001083-kolnp-2006 international publication.pdf

001083-kolnp-2006 international search authority report.pdf

001083-kolnp-2006 pct form.pdf

001083-kolnp-2006 priority document.pdf

01083-kolnp-2006-correspondence-1.1.pdf

01083-kolnp-2006-form-3-1.1.pdf

1083-KOLNP-2006-ABSTRACT-1.1.pdf

1083-KOLNP-2006-ABSTRACT.pdf

1083-kolnp-2006-assignment.1.1.pdf

1083-KOLNP-2006-ASSIGNMENT.pdf

1083-KOLNP-2006-CANCELLED DOCOMENT.pdf

1083-KOLNP-2006-CLAIMS-1.1.pdf

1083-KOLNP-2006-CLAIMS.pdf

1083-kolnp-2006-correspondence 1.1.pdf

1083-kolnp-2006-correspondence.pdf

1083-KOLNP-2006-DESCRIPTION COMPLATE.pdf

1083-KOLNP-2006-DRAWINGS.pdf

1083-kolnp-2006-examination report.pdf

1083-KOLNP-2006-FORM 1.pdf

1083-kolnp-2006-form 13.1.1.pdf

1083-KOLNP-2006-FORM 13.pdf

1083-kolnp-2006-form 18.pdf

1083-kolnp-2006-form 3.1.1.pdf

1083-KOLNP-2006-FORM 3.pdf

1083-kolnp-2006-form 5.1.1.pdf

1083-KOLNP-2006-FORM 5.pdf

1083-kolnp-2006-gpa.1.1.pdf

1083-KOLNP-2006-GPA.pdf

1083-kolnp-2006-granted-abstract.pdf

1083-kolnp-2006-granted-claims.pdf

1083-kolnp-2006-granted-description (complete).pdf

1083-kolnp-2006-granted-drawings.pdf

1083-kolnp-2006-granted-form 1.pdf

1083-kolnp-2006-granted-form 2.pdf

1083-kolnp-2006-granted-specification.pdf

1083-KOLNP-2006-INTENATIONAL PUBLICATION.pdf

1083-KOLNP-2006-OTHERS-1.1.pdf

1083-KOLNP-2006-OTHERS.pdf

1083-KOLNP-2006-PETITION UNDER RULE 137.pdf

1083-KOLNP-2006-REPLY TO EXAMINATION REPORT-1.1.pdf

1083-KOLNP-2006-REPLY TO EXAMINATION REPORT.pdf

abstract-01083-kolnp-2006.jpg


Patent Number 248312
Indian Patent Application Number 1083/KOLNP/2006
PG Journal Number 27/2011
Publication Date 08-Jul-2011
Grant Date 04-Jul-2011
Date of Filing 26-Apr-2006
Name of Patentee ABB TECHNOLOGY AG, a Swiss company
Applicant Address AFFOLTERNSTRASSE 14, CH-8050 ZURICH
Inventors:
# Inventor's Name Inventor's Address
1 LONG, THOMAS EDWIN 1500 RIVER MILL DRIVE, UNIT 301, WAKE FOREST, NC 27587
PCT International Classification Number G06F 17/30
PCT International Application Number PCT/IB2004/004409
PCT International Filing date 2004-11-09
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 10/721,141 2003-11-25 U.S.A.