The InnovationQ application will be updated on Sunday, May 31st from 10am-noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

System Resource Attribute Sets and Attribute Set Extensions

IP.com Disclosure Number: IPCOM000033026D
Original Publication Date: 2004-Nov-22
Included in the Prior Art Database: 2004-Nov-22

Publishing Venue



Operating Systems and Application software often have requirements for the notion of a named resource, along with a set of one or more characteristics or attributes associated with the resource -- for example, a disk device with a name like disk1 with attributes such as hardware address, the name of a specialized software "device driver" needed to access the device, or the name of a "parent" resource upon which access to the device depends. In the simplest cases, there is a fixed set of defined attributes for each unique type of resource (e.g. address, driver, parent), and for each instance of the resource, a set of specific assigned values for those attributes (e.g. 0001, mydriver1, control_unit1) which are conceptually stored together as a "resource profile" record in a file or database and accessed via a "search key" equal to the resource name. Increasingly, however, a given resource type does not have a fixed set of attributes, but multiple -- sometimes overlapping, sometimes mutually exclusive -- attributes that render the simple "resource profile" construct confusing in concept and inefficient in implementation because it might require the superset of all possible attributes. Attribute Sets and Attribute Set Extensions build upon the basic notion that a resource of a given type may have a set of characteristics or attributes associated with it (an "attribute set"), but that one or more of the attributes in this set may in fact identify yet another attribute set -- an "extension" to the base set, with potentially a different set of defined attributes in each unique attribute set extension. This is conceptually easier to understand than the "superset" approach described above, and may be more efficient in both space utilization to store the attribute information and in program access to that information.