Method for compiling and selecting data attributes

[0002] 1. Field of the Invention

[0003] The subject invention relates generally to the collection and verification of information or data and, more particularly, to a method and implementing system for the collection, verification and compilation of data that characterizes electronic equipment, including, but not limited to, a personal computer system or components thereof.

[0004] 2. Description of the Related Art

[0005] It is often the case that sophisticated purchasers of electronic systems, which systems may include, but are clearly not limited to, personal computer systems, prefer to acquire customized configurations of those systems in order to accommodate the purchasers' specific desires or requirements. With respect to customized personal computer system configurations, a large number of constituent components must be selected. System components include the system processor, memory, monitor, keyboard, mouse/trackball, disk drives, printers, internal or external modems, audio subsystems, and other peripheral devices, now existing or devised hereafter. Each of the aforementioned types of components may be acquired from a number of manufacturers who typically offer various models of such components. When confronted with the vast array of potential permutations and combinations of system components, the purchaser, or system designer, will inevitably be confounded by the complexity of the selections that must be made. This situation has been somewhat ameliorated by the relatively recent availability of software that automates the system configuration and design process.

[0006] Regardless, however, whether system configuration is done empirically by a human being, or with the assistance of configuration software, the likelihood of realizing desired system performance, and achieving compatibility among system components, is largely predicated on the availability of data that adequately and accurately characterizes the system components of the system.

[0007] It might be expected that the primary source of data characterizing personal computer components would be the manufacturers themselves. Although this is generally true, it has been found that manufacturers' published information is sometimes disappointing in its accuracy, comprehensiveness, and timeliness. Furthermore, it has been found that manufacturers tend to be idiosyncratic in their approaches to providing physical or performance data to characterize their products, resulting in data sheets that may be underinclusive in failing to provide data necessary to the configuration of a system or overinclusive in providing data that is irrelevant to system configuration.

[0008] Accordingly, what is desired is a solution that enables the collection, verification and compilation of data that facilitates the customized configuration of personal computer systems in a manner that realizes desired system performance and avoids incompatibilities among system components.

[0009] The above and other objects, advantages and capabilities are achieved in one aspect of the subject invention by a method for compiling data to specify an object, which object may include, but is clearly not confined to, a component to be included in a personal computer system. The method contemplates establishing a predefined array of attributes that characterize the object. A plurality of agents, acting independently, acquire respective values of the each predefined object attributes from a global source of such values. The values acquired by the agents are checked against values, or ranges of values, that have been predetermined to be accurate. The attribute values respectively acquired by the agents are then compared for situational equivalence. If the values are found to be situationally equivalent, they are written into, or retained in, a database. If not, a resolution process is invoked that results in retention in the database of a presumptively accurate value. As an enhancement, the global source of data is routinely examined to determine whether attribute values have been updated.

[0010] Another aspect of the invention inheres in a combined hardware/software system that enables the compilation of data in congruence with the inventive method summarized above. The system comprises acquisition means for acquiring values of attributes that have been preselected to characterize the object. The acquired values are applied to a difference means that determines the situational equivalence, or lack thereof, of at least two independently acquired values of the same attribute. A database coupled to the difference means retains attribute values that have been determined to be accurate.

[0011] A further aspect of the invention resides in a method of compiling data to specify an object, the method comprising, via a first agent, (i) accessing a global source of information that contains values characterizing attributes of the object, (ii) comparing the values accessed to a predetermined value, or range, that has been determined to be accurate, (iii) selecting a value of the attribute, and (iv) writing the value selected into a database. The operations indicated above are performed, independently and in tandem, via a second agent. Subsequently, a difference engine retrieves from the database values written for a particular attribute and determines whether the values are equivalent. If so, a value for the asset is retained in the database. If not, a resolution process is invoked, according to which a value may be empirically determined and written to the database.

[0012] Yet another aspect of the invention is represented in a data compiler for a system that utilizes a number of acquisition agents for independently acquiring values of one or more attributes that characterize an object. The data compiler comprises a database and a difference engine. The database has one or more inputs for coupling to the agents to select attributes with reference to predetermined permissible values of the attributes. The difference engine is coupled to the database for (i) reading two or more values of the attribute that have been selected by agents and are stored in the database, (ii) comparing the two or more values, and (iii) if the values that are compared are equivalent, causing a value to be retained by the database, and(iv) if the values that are compared are not equivalent, causing a resolution process to be invoked.

[0013] Another aspect of the invention is realized by a data collection and compilation system for creating, storing, and distributing a record that characterizes an object, the record containing values of a predetermined array of attributes that characterize the object. The system comprises a first database for storing the record and a processor coupling a first research analyst to a global source of information containing candidate values of the attributes and coupling the first research analyst to the database for entering into the record values selected by the first research analyst, as well as a processor coupling a second research analyst to a global source of information containing candidate values of the attributes and coupling the second research analyst to the database for entering into the record values selected by the second research analyst.

[0014] A difference engine is coupled to the first database for (i) reading and comparing the respective values entered by the first and the second research analysts, (ii) for comparing those values, and (iii) for causing to be inserted into the record status information that indicates whether the values compared are equivalent or not equivalent. A processor is included for coupling a reconciliation agent to the first database for enabling the agent to read a record that contains status information that indicates that values compared by the difference engine were not equivalent and-for enabling the reconciliation agent to enter a reconciled value for the attribute.

[0015] An aspect of the invention is also realized in a system that utilizes a plurality of acquisition agents for respectively and independently acquiring values of an attribute for characterizing an object, wherein each of the agents acquires a value by searching a source of information regarding the object and, as a result of the search, selects and enters into a database a value of the attribute. This aspect includes a difference engine coupled to the database for (i) reading two or more values of the attributes that have been selected by agents and are stored in the database, (ii) comparing the two or more values, and (iii) if the values that are compared are determined by the difference engine to be equivalent, causing a value to be retained by the database, and (iv) if the values that are compared are determined by the difference engine not to be equivalent, causing a reconciliation process to be invoked.

[0016] A specific aspect of the invention is practiced in a method of compiling data to specify an object. The method comprises the steps: (a) establishing a predetermined array of attributes to characterize the object, which array includes at least one attribute that is constituted from an undefined number of subattributes of the same type; (b)(i) by virtue of a first acquisition agent, determining the undefined number of subattributes and acquiring a first set of values for the number of subattributes determined by the first acquisition agent; and (b)(ii) by virtue of a second acquisition agent, and substantially independent of the first acquisition agent, determining the undefined number of subattributes and acquiring a second set of values for the number of subattributes determined by the second acquisition agent, wherein the undefined number of subattributes is respectively, and independently, determined by the first and by the second acquisition agents upon acquisition of the values.

[0017] The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

[0018] FIG. 1 is a system diagram of a preferred embodiment of a data compilation system in accordance with the subject invention.

[0019] FIG. 2A represents a screen that is operative when the research analyst is prompted to enter a numeric value for an attribute value.

[0020] FIG. 2B represents a screen that is operative when a research analyst is prompted to enter only one value from a finite number of discrete permissible values;

[0021] FIG. 2C represents a screen that is operative when a research analyst is prompted to enter one or more values, either numeric or literal, from a finite number of permissible values;

[0022] FIG. 2D represents a screen that is operative when the research analyst is prompted to enter a value that is textual in nature.

[0023] FIG. 2E represents a screen that is operative when a research analyst is enable to add a number of subattributes determined by the analyst at the time of data collection.

[0024] FIG. 3 is a representation of a typical screen display presented in a reconciliation process invoked in accordance with the invention. The use of the same reference symbols in different drawings indicates similar or identical items.

[0025] For a thorough understanding of the subject invention, reference is made to the following Description, which incorporates the above-described Drawings and the appended Claims.

[0026] Referring now to FIG. 1, the subject invention may be seen to include a data compilation system (or data compiler) 1 that includes desktop computers 11 operated by respective research analysts A and B. In a specific implementation of the invention, only two research analysts are required; however, the invention contemplates the use of two or more research analysts, inasmuch as the accuracy of the data collected can expected to improve with the number of research analysts that operate to collect that data.

[0027] As indicated above, significant application of the data compilation system is the collection of data that characterizes electronic equipment, such as personal computer systems, and for pedagogical purpose, the invention will be described in that context.

[0028] In a manner that will be more fully described below, each of the analysts is presented, on a screen display associated with desktop computer 11, with a predefined array of attributes that characterizes the equipment at hand. (Notwithstanding the above, in some instances the nature of the attributes requires that the RAs be enabled to define limited aspects of the attributes. The subject invention provides this enhancement in a manner described below.) As a simple example, nearly every type of electronic component or assembly will be characterized by its physical dimensions. Accordingly, one of the attributes of that component will be presented as, for example, “Dimensions,” and the constituent subattributes of the attribute Dimension might be Height, Width, Depth, and Weight.

[0029] The analysts then independently search a global source of information related to the component in order to collect data that comprises values for the attributes or subattributes. A convenient source of relevant data is the worldwide web (WWW), which will likely contain websites comprising manufacturers data sheets in electronic form. Other sources may include, but are not limited to, paper catalogues, CDROMs, and so forth. Accordingly desktops 11 are installed with web browsers and are connected, as shown in FIG. 1, to the internet.

[0030] Each of the analysts independently searches the WWW to collect data representing the values of all the subattributes that constitute an attribute. When an attribute value, or subattribute value, is found, the respective analyst enters that value in the appropriate field of a record that completely characterizes the component. The record will comprise the array of attributes that characterizes the component and, when completed by the analyst, will contain values for all the subattributes that constitute the attribute, the records are stored in a database 13, as depicted in FIG. 1. In accordance with the invention, the essence of the task performed by the analysts is to access from database 13 records that define attributes that completely characterize a component. The analysts then search the WWW for the data necessary to provide values for all attributes in the array, or for all the subattributes if the attribute consists of a number of subattributes.

[0031] In the context in which the present invention is now described, the records themselves are identified as “SKU”s, wherein an SKU for a particular electronic component will consist of a manufacture's identification, such as “IBM,” followed by an alphanumeric string, so that the SKU “IBM 26441AU” identifies a particular product, specifically a think pad, manufactured by IBM. The record in database 13 that characterizes that component will similarly be identified by that SKU.

[0032] Once a research analyst has completely entered values for all the attributes and subattributes, if any, required to specify an SKU, the SKU is deemed to be in a “Ready for Diff” state (SKU states will be more fully explicated below.), and the SKU record will contain a field that announces the RFD state. When both research analysts (or when all research analysts, when more than two are used) have completed data entry for a particular SKU, this condition is detected by a Diff Engine 14.

[0033] This occurs because Diff Engine 14 continually monitors the states of SKUs in database 13 and extracts and, in the manner described below, compares the values entered in the SKUs. The essence of the operation of Diff Engine 14 is to compare the values collected and entered independently by the respective research analysts. Operation of the Diff Engine is fully explicated immediately below. Understanding of Diff Engine operation is facilitated by comprehension of the significance of the various SKU states. Accordingly, the SKU states are defined:

[0034] The following SKU states may be encountered and attributed to SKUs in working database:

[0035] “Available” (AV): the SKU is available for entry of values by an RA.

[0036] “Ready For Process” (RFP): an RA has captured the SKU and has begun, but not completed, entry of attribute values.

[0037] “Ready for Diff” (RFD): all RAs have completed entry of all attribute values for the SKU.

[0038] “Passed Diff” (PD): the Diff Engine has determined that all corresponding values in respective matched sets of SKUs, that have been completed by the RAs are equivalent.

[0039] “Ready For QA” (RFQA): the Diff Engine has determined that not all corresponding values in respective matched sets of SKUs completed by the RAs are equivalent, necessarily implying that reconciliation by a QA rep is required.

[0040] “Reconciled” (R): initially discrepant SKUs have been reconciled by a QA rep.

[0041] The Diff Engine operates to automatically locate, compare, and administrate multiple copies of data sets. In the context of the subject invention, the data sets are the SKUs. After comparison, there are two potential outcomes: The copies compared are “acceptably identical”, in which case the SKU is assigned the state Passed Diff and will ultimately be made available for consumption by the client or consumer. Alternatively, the SKUs will be found not “acceptably identical”, in which case the SKUs assigned the state “Ready for QA” and are referred to a QA representative for reconciliation.

[0042] For some definitions:

[0043] A group of data sets are “strictly identical” if:

[0044] a) Each SKU contains exactly the same attributes, for example, each has a single “color” attribute, and

[0045] b) Each attribute of each data set contains the same value as the corresponding attribute in every other corresponding SKU.

[0046] The concept of “acceptably identical” data sets derives from the fact that there can be an arbitrary number of SKUs to compare, depending on the number of RAs used to collect data for the SKU. With respect to double entry, it is relatively easy to detect when the attribute values of paired SKUs match. However, triple, quadruple, or ten-fold data entry might be employed, depending on the level of accuracy desired. And, as is easily understood, the complexity of SKU comparison increases, perhaps geometrically, with the number of SKUs that must be compared. At this point terms will be introduced, that will be central to an understanding of Diff

[0047] Engine operation:

[0048] 1) Attribute Threshold (T_a)

[0049] 2) Attribute Uncertainty Interval (AUI)

[0050] 3) Value Threshold (T_v)

[0051] 4) Minimum Threshold (T_m)

[0052] Assume, for instance, that an SKU entry team is using ten-fold data entry; that is, every subattribute value is entered ten different times, independently by ten RAs, and that all ten values are compared against each other. Let us further assume that all RAs agree that “color” is a valid attribute. In this case, the question is how many of the ten RAs must agree on the color for that value to be considered to have “Passed Diff”. In the extreme case, one might assume ten. That is, if nine RAs select “blue” and one RA selects “red”, the value is deemed to have failed processing by the Diff Engine, is assigned “Ready for QA” status, and therefore must be resolved by QA. In this case, T_vmight be said to be 100%. That is, if there is not 100% agreement among the RAs, the value is declared suspect. Obviously, T_vmay be set less than 100%. For example, a T_vof 80% would require only eight of ten RAs to agree on a value. T_v's relative setting would drive the frequency with which data entries had to be manually reviewed by a QA team.

[0053] T_aaddresses with the same issue, but from the perspective of the validity of the attribute itself. Let us assume that T_ais 80%. That is, if eight of ten RAs believe an attribute belongs in the SKU, then it is included in the “canon” of valid attributes. Conversely, if only two of the RAs believe that the attribute belongs, then the attribute is not included in the canon of accepted attributes. However, if seven RAs agree that the attribute belongs, and three do not, then a judgment must be made. Specifically, seven is less than 80% of ten, so the attribute should not be included in the array. However, from another perspective, only 30% agreed that the attribute should not be included. Even thought the RAs voting inclusion outnumbered the RAs voting not to include, the attribute is not included in the SKU. For this reason, there exists an “Existence Uncertainty Interval” in the selection of an attribute for inclusion in an SKU. If more than 100%−T_a%, but fewer than T_a%, RAs believe an attribute should be included, then the validity of the attribute itself is in dispute. This situation is resolved by the QA rep in the same way that attribute values are resolved.

[0054] As an example, assume a T_aof 80% and a T_vof 70%. In this case, the AUI is 20-80%. If no more than 20% of the RAs claim the attribute is relevant, then the attribute is not included (since at least 80% believe it is irrelevant). If at least 80% claim it is relevant, then it is included. If more than 20%, but fewer than 80%, claim it is relevant, then it is in dispute, or “uncertain”. In this example, seven of the RAs claim “color” is relevant. It falls into the uncertainty interval, and the attribute is flagged for QA reconciliation. QA decides it is relevant, and the Diff Engine then compares the values. Two of the nine RAs select the color “blue” and seven, select “red”. 70% of seven is 4.9, so at least five RAs are required to agree on the value for it to be automatically accepted. In this case, once QA has determined that “color” is an appropriate attribute, the Diff Engine would consider the agreement of the five RAs adequate to substantiate that the color is “blue”.

[0055] However, if T_aand T_vare inappropriately chosen, it is possible to generate undesirable results. First, none should ever be 50% or lower. If T_ais 50% or less, than there is no AUI, because 100%−T_a% is in fact greater than T_a%. If T_vis 50% or less, it is possible that two different values both have enough “votes” to be considered correct. For instance, if T_vis 50%, and half the RAs select “blue”, and the other half select “red”. The Diff Engine would be constrained to consider both correct under the rules stated above.

[0056] However, more subtle examples are possible. For instance, with a relatively high T_a(say 80%), and relatively low T_v(e.g. 60%), it could happen that three RAs select “color” as a valid attribute, but disagree on the “value” of the color, with two selecting “blue” and one selecting “red”. Since three falls into the Uncertainty Interval, then QA would be required to resolve the very existence of the attribute. Assuming they agree it is relevant, then the Diff Engine would automatically assume that the color is “blue”, since 67% of the RAs that claimed the attribute “color” was relevant selected the value as “blue”. In this case, only two of ten RAs teams picked “color”/“blue” as an attribute/value pair. Nevertheless, the value was selected automatically, once “color” was verified as relevant. For this reason, the definition of “acceptably identical” can be designed to include a T_m(Minimum Threshold), the lowest percentage of all RAs required to agree on the validity of an attribute before allowing automatic acceptance. If T_mis 0%, then it has no effect. If T_m=T_v, then there is no “lessening” of the standard for an attribute that fails to receive a 100% relevance vote. If T_m>T_v, then obviously T_vbecomes irrelevant. In either of the latter two cases, item (b) of the following definition is superseded by item (c).

[0057] A group of SKUs are “acceptably identical” if:

[0058] a) No attribute in any SKU falls into the Uncertainty Interval;

[0059] b) For each attribute in the “canon”, the attribute value is agreed upon by at least T_v% of the RAs that claimed the attribute was relevant.

[0060] c) For each attribute in the “canon”, its value is agreed upon by at least T_m% of all RAs.

[0061] There are several ways to effectively implement the process algorithm described above. Two such methods follow:

[0062] The first method requires that the Diff Engine run a database query either continuously or on a fixed schedule. This query returns groups of SKUs that refer to the same item. For instance, the Diff Engine may search for identical manufacturer/manufacturer SKU tuples, or may search for identical UPC codes, or some other unique product identifier. When the Diff Engine finds a sufficient number of items (e.g. two for double-entry, three for triple-entry, etc.), that exhibit the appropriate state, i.e. “Ready for Diff”, the Diff Engine initially determines that there are no attributes that fall into the Uncertainty Interval. If there are, the SKUs are flagged for QA for reconciliation. If not, or when returned from QA, the Diff Engine checks to make sure that each attribute in the canon is agreed upon by at least T_v% of the RAs that claimed the attribute was relevant, and at least T_m% of the RAs in total. If so, a new copy of the entry is made in the production database, with the appropriate attributes and attribute values populated. If not, the Diff Engine flags the SKUs in question to QA for reconciliation. The QA representative reconciles those values, and the completed entry is made in the production database.

[0063] The second method involves a more “Object Oriented” approach. Upon receipt of an item to enter, N+1 objects are created, where N is the number of RAs employed to select values for an SKU. One object is assigned as the “parent” object, and the other N are assigned, one to each data entry RA. As each “child” is completed, it notifies the parent of its new status. When the parent object has received N notifications, it calls out to the Diff Engine to perform a comparison of its “children”. The Diff Engine (and QA rep, as applicable) write information to the parent object. When it has been completely differenced and/or reconciled, the parent object is promoted itself into the production database.

[0064] A slight alteration on the above schemes has the QA rep doing reconciliation of Attributes and Attribute Values simultaneously. That is, the Diff Engine knows, at the time it determines that an attribute is uncertain, whether or not it will need reconciliation if it is included in the canon. If it will, the QA rep is then notified to not only reconcile the attribute, but reconcile the attribute value at the same time, thus preventing QA from having to revisit an attribute.

[0065] Accordingly, and in summary, when the SKU values entered by both RAs are equivalent, the Diff Engine causes the SKU state to be indicated as “Passed Diif”. SKUs with PD status are then extracted and retained in production database 15. However, when Diff Engine 14 determines that the values of the SKUs are not equivalent, the Diff Engine causes the SKU state to read “Reconcile”. SKUs with a Reconcile state are identified by a Quality Assurance representative and processed as follows.

[0066] In essence, it is the task of QA, operating from desktop computer 12, to continually search database 13 for SKUs that are in the Reconcile state. Software included as part of the subject invention causes the discrepant SKUs to be simultaneously displayed on the monitor or desktop computer 12. Discrepancies in values entered by the RAs are highlighted, and if the QA rep so desires, the display can be collapsed so that only discrepant SKU values are presented to the QA rep. After identifying the discrepant SKU values, the QA rep has the option of selecting the values collected by either RA, or imposing a value of his own selection. This is accomplished, in the former situation by clicking on the values selected, and in the latter by manually entering a value at the keyboard of desktop 12. A representation of a screen display presented to the QA rep in the course of a reconciliation process is depicted in FIG. 3.

[0067] In the present embodiment of the invention, the significant features of the QA screen, as evident from FIG. 3, is that the screen is partitioned into (at least) three vertical partitions. The leftmost two partitions display attribute, or subattribute, descriptor and the values selected by the respective RAs. If the screen is not collapsed by the QA rep to display only discrepant attributes or subattributes, then the discrepant attributes are highlighted. The third, rightmost, partition (or column) displays the reconciled values imposed by the QA rep.

[0068] To this point, there has been described the salient features of data compilation system that effects dramatic improvements in the accuracy of the data that is collected and compiled in order to characterize electronic equipment, or components of electronic equipment. The improved accuracy results from establishing a predefined array of attributes, and subattributes, to characterize an equipment or a component of a system. RAs then search a global source of information regarding the equipment or component to acquire values for the respectively independently attributes and subattributes. The values are then compiled to create records (SKUs) retained in a database. The values indicated in the SKUs are then compared in a Diff Engine, If the attribute values are equal, the SKU is indicated as having Passed Diff and is thereby caused to be retained in a production database. If the Diff Engine indicates a lack of equivalence between paired SKUs, a reconciliation process is invoked which ultimately results in a reconciled SKU being retained in the production database.

[0069] Although the subject invention, insofar as described above,.has proved to promote a significant enhancement in the accuracy with which personal computer equipment, peripherals or components may be specified, further enhancements have been realized in specifically tailoring the manner in which data collection and entry is accomplished by the RAs. Arguably, this is the critical step in the data compilation system. Specifically, the data compilation system permits the RAs to enter value data in only one of a limited number of available modes, depending on the nature of the attributes and the universe of permissible values that may be correctly assigned to the attribute. In the present instantiation of the invention, the RAs are able to enter attribute values in one of four modes, depending on the nature of the attribute or subattribute. The four modes are: (1) entry of a numeric value; (2) selection of one value from a number of values presented to the RA; (3) selection of more than one value from a set of permissible values, or (4) entry of text. FIG. 2 illustrates examples of the screen displays that are presented to the RAs during the course of operation in each of the aforementioned modes of data entry. The illustrated screens arise during the course of data entry, which data as will soon be seen, may be numerical or textual, that characterizes a think pad distributed by IBM. The think pad has been assigned the SKU “IBM26441AU”.

[0070] Referring now to FIG. 2A, the RA elected to enter values for the subattribute “Installed Video Memory (MB)”, which is a subattribute of the attribute “Display” (not shown in FIG. 2A). As shown in the right partition of the display, the RA had been provided a prompt 211 to “Enter Numeric Value”. In response, the RA is shown to have entered the numeric value “2.5”. The value entered was found not to conform to the set of discrete permissible values, or within the range of permissible values, and consequently an error message, “Not a valid value” appears. This aspect of the invention may be perceived as an error check, inasmuch as the error message prompted by the attempt to enter an impermissible value will incent the RA to reconsider, and correct, the value entered.

[0071] In FIG. 2B, it can be seen that the RA is entering a value for the “Display” subattribute “Native Display Resolution”. In this instance, the RA is presented in window 221 with a plurality of permissible values, from which he is able to choose one. With respect to the IBM 26441AU, the system recognizes “1024X768(XGA)” as a correct selection.

[0072] In FIG. 2C, the RA is provided in window 231 with a menu of “Additional Features” from which to select, and the RA is free to select the values (which in this case are not numeric) that his research has indicated as available with the IBM 26441AU.

[0073] Behind the screen displayed in FIG. 2D, the RA is characterizing the attribute “Technical Support” and, in particular, the subattribute “Technical Support URL”. Here the RA has been provided a prompt 241 to enter a value in the form of (text, that is, the Internet address “http://www.ibm.com/support/wwwsup30e.msf” at which web based technical support me be obtained.

[0074] A further elaboration of the invention allows the RA to define additional attributes at the time of data collection For example, if it is assumed that the RA is in the process of characterizing a system for a desktop computer, then one of the defining attributes of that system board is its “Expansion Slots”. However, system boards may have an unpredictable number of expansion slots, and, moreover, it is impracticable to even predict the maximum number of expansion slots. This difficulty is resolved by enabling the RA to, at the time of acquisition of data specifying the system board, determine the number of expansion slots available. So that under the attribute “Expansion Slot”, the RA can create Expansion Slot 1, Expansion Slot 2, . . . , Expansion Slot N. Each of the N expansion slots will be characterized by its own subattributes such as “Length”, “Number of Connections”, “Bus Standard Supported”, “Data Type”, etc.

[0075] An example of this capability is presented in FIG. 2E, which depicts an example of a screen that enables the RA to define a number of “Warranty” attributes applicable to the IBM 26441AU Think Pad. As seen from FIG. 2E, the RA has completed the specification of “Warranty 1”, which is seen to be a 3-year base warranty, and is in the process of specifying “Warranty 2”. Upon completion of the specification of Warranty 2, the RA is able to exercise the option of entering additional warranty attributes simply by clicking on the “Add” bar highlighted on FIG. 2E.

[0076] By virtue of the above, the narrative, an appreciation of the long sought advantages realized by the subject invention is deemed to have been conveyed. As an embellishment, however, that assures the freshness of the data retained in database 15, as preferred embodiment of the invention also includes a web analyzer 16 that is coupled to database 15, as well as to the WWW.

[0077] Web analyzer 16 operates to periodically scan the WWW for the then-current data regarding the SKUs stored in database 15. If the current data available has been updated, changed refreshed since the creation of the respective SKU record in database 15, then the status of the record is indicated to be “Update”, which will indicate that the SKU requires updating in accordance with the methods described above.

[0078] Although the subject invention has been described above with reference to a particular, preferred, embodiment, it is to be understood that various additions, deletions and modifications to the embodiment described may be implemented by those with ordinary skill in the art, and such additions, deletions, and modifications will not depart from the scope of the invention, as defined by the appended claims. In particular, it may be reasonably anticipated that the processor partitioning, specifically, the allocation of separate processors to the RAs, QA representative and Diff Engine may, depending on processor bandwidth, be combined in whole or in part. Moreover, it may be, or may become, practicable to automate the RA and QA functions with software applications. Furthermore, the segregation of the working database and production database is not considered a limitation of the invention.