WO2003081465A2

WO2003081465A2 - Object relationships

Info

Publication number: WO2003081465A2
Application number: PCT/GB2003/001290
Authority: WO
Inventors: Paul Lancefield
Original assignee: Infinite Reason Ltd
Priority date: 2002-03-21
Filing date: 2003-03-21
Publication date: 2003-10-02
Also published as: WO2003081465A3; AU2003217027A1

Abstract

Data processing apparatus arranged to process objects in accordance with stored dependency relationships between the objects, the data processing apparatus comprising: storage means for storing at least one property of each object, and an indication of whether the property is a mandatory or an optional property of the object, and for storing definitions of dependency relationship between the objects; and processing means arranged to process the objects in accordance with the stored relationships such that an object having a dependency relationship on another object is treated as having the or each mandatory property of the other object, and as having the or each optional property of the other object if the stored definition of the relationship between the objects indicates that the property is inherited by the object, and as not having the property otherwise.

Description

209497 OBJECT RELATIONSHIPS

This invention relates to object relationships, for example as implemented in a database, especially a database intended for analysing intellectual property data.

The number of patents that could form a threat to businesses' activities is increasing, especially in relation to technology that can be implemented in software. Now many software businesses file patent applications directed to relatively speculative new products and services as a matter of course, with the aim of acquiring additional market leverage and advantage. As a result many smaller or unprepared businesses are unaware of the risks that their products or services might infringe existing intellectual property.

A further problem is that software in particular is often extremely difficult to categorise. Consequently it is difficult for a researcher working on a given product to find prior art with confidence. Any list of IPC (international patent classification) categories sufficiently broad to catch all instances of prior art is likely to be so broad as to contain many irrelevant patents. On the other hand any list of IPC categories sufficiently narrow to limit lists of patents to a digestible size is likely to miss relevant patents.

Recently, consolidated internet-based patent database services have become commercially available, Micropatent (www.micropatent.com), Delphion (www.delphion.com) and M-CAM Doors (www.m-cam.com) are three examples. These databases allow a researcher to search for documents using Boolean search expressions. Boolean searches allow the selection of only the documents which matching user defined search criteria or logical expressions. When conducting a general search this usually involves searching for documents that contain certain words, and the search expression may be refined so that the documents returned are graded according to how close the words are together. (For example, many documents would contain the words "patent" and "database" but far fewer would contain the two immediately next to each other or very close together). These searches greatly improve the researcher's efficacy and if constructed properly will yield a far higher proportion of relevant results than a category search. Boolean searches increase the confidence in the validity of the research because they are not limited by category and a well formed Boolean search is more likely to pick up relevant documents from unexpected categories

However, even Boolean searches are not without problems. When constructing a Boolean search it is difficult to be sure in advance if the search, as it has been constructed, contains keywords that are representative of the kinds of documents the researcher will be interested in. Most such searches rely upon searching for documents that match certain key-words. If too few words are included important documents might be missed. If too many are included, many irrelevant documents are returned all of which need to be evaluated and consume the researcher's time (a precious resource).

In summary: Boolean searching or other forms of searching based on semantic content is deficient as a method for identifying related prior art for the simple reason that the relevance one patent holds to another is not a function of its semantic content. The IPC categorisation does not much improve matters because the category to which a patent should be assigned is very often ambiguous.

That the issues identified above are recognised as a problem within the innovation business is attested by the fact that technologies have been developed and marketed to address the problem.

On Delphion, for example, advanced technologies such as text-clustering are made available to the researcher at a premium charge. With text clustering a researcher may execute a broad based search and then look for similarities in phraseology or language use within documents in the result set, grouping documents together that appear to have a common structure. Using text clustering the researcher can quickly find related documents that are of interest to the subject searched for, but still the researcher cannot be entirely confident all relevant documents have been found. Text clustering is suitable for quickly finding interesting related material that may be prior art but not so useful for providing a comprehensive audit of all related material that may be prior art. Other technologies using semantic analysis for the searching of unstructured documents are available, but suffer similar limitations on their practical application.

Existing searching techniques present a number of problems:

• How to identify and track groups of artefacts possessing similar but complex technical dependencies, whilst limiting data duplication and maintaining classification integrity.

• How to enable a searcher to readily categorise documents in a meaningful way that aids the process of threat evaluation for companies or organisations.

• How to evaluate the patentability of an idea with relatively little search effort, preferably in a way that allows that evaluation work to be useful for research on other prior art in the same area.

• How to reduce time spent modelling solutions in a particular technical field, enable information on publications in that field to be captured easily and allow the relationship between an innovation proposal (e.g. invention) and prior art to be readily determined to avoid duplication and reduce the risk of infringement and reduce time spent preparing a patent application.

It would be desirable for there to be a data analysis tool and/or relationships to be defined and/or available between objects in a system so that some or all of these problems may be at least partially addressed

Object models may be used to identify the technological dependencies held by inventions. Object models provide a useful means to aid comprehension when executing software or hardware designs. It is an objective of many object modelling systems to allow the modelling of complex systems through the elaboration of a basic design until it defines a functionally complete solution. Inventions from the field of engineering may be partially described through identifying the technology dependencies they share with other inventions. Identification of shared technology dependencies provides a good way of classifying inventions likely to deal with similar subject matter. Shared technology dependencies may be modelled using existing software modelling solutions; however, as noted, it is an objective of most if not all of these solutions to allow elaboration of a design until it provides a functionally complete system.

If the technology dependencies an invention holds are modelled in too much detail, the number of inventions found to share the same dependencies will be minimal.

If, on the other hand, the technology dependencies an invention holds are only partially identified (e.g. with too little detail) then the number of related inventions is great. For example many inventions have a dependency on the services of a general processing unit. However if the technology dependency identified in a model is for e.g. a GPU and nothing more, millions of inventions will relate to the object.

One solution is to allow the identification of groups of technology dependencies using objects in a hierarchy. This may be a class hierarchy as understood in the field of software engineering and object oriented programming, or another form of hierarchy. Objects "further-down" the hierarchy through having relationships with objects "higher-up" in the hierarchy represent ever more specific combinations of technical dependency. Through a process of researching documented inventions, objects representing the inventions are related to the hierarchy objects with which they have the most technical dependencies in common. If, over time, very many inventions come to be related to a first object, its value for the purpose of identifying similar inventions may lessen, or at least, the value of the hierarchy may be improved by seeking to define new hierarchy objects representing more specific sets of shared dependencies.

In this event the researcher looks across all the inventions related to the first object, identifies those which share more specific technical features or dependencies than the current parent object represents, creates a second, more specific object related to the first object (further "down" the hierarchy) and makes the subset of inventions children of the second more specific object.

A difficulty faced when adopting this solution is that there may be a trade-off between over complexity and ambiguous classification. If the hierarchy is too simple, there may be multiple objects an invention can be interpreted to share dependencies with, which means, strictly speaking, it should be related to more than one object. This introduces a form of ambiguity already found in the library style classification systems the hierarchy is supposed to improve upon. However, if the hierarchy is too complex, it may then be difficult to navigate and cognition of the technology dependencies identified by the hierarchy objects can be undermined. A further problem is that the differences between objects may be unobvious from the name or title given to the object alone and it can be difficult to remember the detailed description of the dependencies the object defines or holds by virtue of the other objects it is related to.

Similar problems can be met in modelling relationships in other fields.

It would be desirable to be able to address these problems, preferably by means of the relationships defined and/or available between objects in a system.

According to one aspect of the present invention there is provided Data processing apparatus arranged to process objects in accordance with stored dependency relationships between the objects, the data processing apparatus comprising: storage means for storing at least one property of each object, and an indication of whether the property is a mandatory or an optional property of the object, and for storing definitions of dependency relationships between the objects; and processing means arranged to process the objects in accordance with the stored relationships such that an object having a dependency relationship on another object is treated as having the or each mandatory property of the other object, and as having the or each optional property of the other object if the stored definition of the relationship between the objects indicates that the property is inherited by the object, and as not having the property otherwise.

The stored definition may implicitly indicate either that the property is inherited by the object, or that the object does not have the property, for example by the absence of information explicitly indicating the other state.

According to a second aspect of the present invention there is provided a database system arranged to store data objects, the objects comprising: a first type of object for representing subjects consisting of patents or patent applications and/or instances of technical disclosures and/or instances of actual technology; and a second type of object for characterising relationships between the subjects of objects of the first type.

According to a third aspect of the present invention there is provided a method for forming a database of data objects, the method comprising defining objects comprising: a first type of object representing subjects consisting of patents or patent applications and /or instances of technical disclosures; and a second type of object characterising relationships between the subjects of objects of the first type.

Preferred features of the present invention are defined in the accompanying claims.

The present invention will now be described by way of example with reference to the accompanying drawings.

In the drawings:

figure 1 is an example of a hierarchical database structure; figure 2 shows schematically the architecture of a database system; figure 3 illustrates simple polymorphism; figure 4 illustrates representational polymorphism - inheritance; figure 5 shows a user interface for a cognitive object model apparatus; and figure 6 shows an application architecture of the preferred embodiment. figure 7 shows an application architecture of an alternative embodiment, delivered as a web service. figure 8 shows an examplary Information Panel display figure 9 shows an optional behaviours and attributes truth table figure 10 shows an examplary additional information form, displaying additional information about patent classes or archetype classes. figure 11 shows data fields with type and length definitions

In the description, where reference numerals are referred to they relate only to the figure being discussed.

In the present specification the term "archetype" refers to an abstract generalised reference to a kind of technology (for example a CPU), whereas an "artefact" refers to an actual instantiation of a technology (for example an Intel Pentium III 266mhz CPU). Technology artefacts can include (but are not limited to) actual inventions, the specific embodiment or article described by a document but which has not yet been built, innovation proposals (proposed inventions as yet to be registered) or actual technical hardware/software systems fulfilling a specifiable function. Archetypes represent abstract systems and usually lack implementation detail, whereas artefacts represent either actual systems or documented systems that have been fully described such that the system can be built by someone skilled in the art.

The present system can store, track and analyse information about intellectual property archetypes/artefacts that have many complex but similar technical dependencies on other technology artefacts/archetypes. The system comprises an engine, which can most conveniently be embodied in software, arranged to interrelate data in the form of a recombinant object hierarchy ("the hierarchy"), which contains objects denoting actual archetypes and artefacts and combinations of archetypes and artefacts. The engine ensures that the information stored representing relationships between artefacts and archetypes is logically consistent. The engine is a tool for intellectual property research that can be used in the context of e.g. an object-relational database to establish an intelligent store for records about intellectual property artefacts/archetypes. Once the store has been established and a comprehensive set of objects entered in the system, a database utilising the engine can be used to quickly identify prior art that is relevant to a given archetype or artefact. By using an object design consistent with polymorphism the engine minimises the duplication of data, reduces the time a user requires to enter data and reduces the complexity of user searches. The engine has been designed specifically but not exclusively for tracking intellectual property related to digital technologies and can be integrated into a standard relational database, or an object-relational database which provides additional database functionality. It can also be integrated to great effect with object modelling tools.

A recombinant object hierarchy is a hierarchy of diverse object types united by a primary key (in this case an object ID).

In the context of the present system the term "object" may refer to a software object or class as understood in the art of object oriented programming, a record object in an object-relational based database or, if certain additional methods described below are implemented, a record in a standard relational database. Objects are entities that can be generated by a user (which can be a person or another system) but structured in accordance with a preset template or design (their "type"). In the engine a variety of object types are used to denote a variety of technology archetypes and artefacts. Objects of a type are instantiated by a user (which may be a person or external system), and as defined by a specified object type can contain certain kinds of data about the archetype/artefact denoted. The objects within the hierarchy can be used to track the kind of technical dependency or logical relationship a specific archetype or artefact may have on another technology archetype or artefact.

In the present system a record may for example be a database record, which adheres to a database schema, or a flat file capable of being supplied with a definition, a computer file, or a marked up file such as an XML document. In the preferred embodiment of the system the hierarchy is composed of objects matching at least the following object types:

Patent Class An object denoting an archetype defined by a patent or patent application document. The patent object includes an identifier that uniquely identifies the document, for example its publication number. The object may include a description of the document and/or its contents. The object may also include attributes denoting behaviours and or variables as understood in the art of object oriented programming.

Archetype Class An object denoting an archetypical technology system solution or service (in contradistinction to an artefact). The class object is reserved for describing systems at a high level and where there is no intention or requirement for providing specific implementation details for the technology described. Archetype classes can be said to characterise a technology. The object may include a description of the technology solution or service. The object may also include attributes denoting behaviours and or variables as understood in the art of object oriented programming.

Link Object An object containing information linking one object to another (an object-object link) or linking one object to an attribute of another object, (an object-attribute link) and providing additional information about the nature of the relationship between the objects. The object includes the identities of the objects that are linked for object-object links or the identity of the object and the identity of the attribute that are linked for object-attribute links, and an indication of the type of relationship that it defines. Classification Object A classification object could represent a category of a subject matter classification such as the IPC, and links from this type of object to other objects could be used to indicate they fall within the category.

Each object includes a unique identification field (object ID) by which it can be unambiguously identified for the purpose of searching, storing search results or other lists of objects, and defining links between objects. Each attribute also contains a unique identification field by which it can be unambiguously identified for the purpose of searching, storing search results or lists of attributes, and for defining links between objects and attributes.

The patent class and the archetype class could be combined to a single type of object. This could be a polymorphic object including an attribute that can be set to indicate whether the subject of the object is an artefact or not or provided with an interface to an artefact object type. Thus the polymorphic type of object could take two or more forms.

In the preferred embodiment objects may optionally include an artefact attribute which can be set to true or false to indicate whether or not the object is an artefact..

The availability of link objects provides a means for a user to define relationships between objects (object-object links) and so to establish a hierarchy between them. The link object allows the following relationships to be denoted by object-object links:

"contains" If object y contains an object z, z inherits at least the mandatory attributes (whether behaviours and variables) of y. In the preferred embodiment object z then does not require object-attribute links to each of object y's mandatory attributes to be treated as having the attributes. uses When an object y uses an object x, object y does not make any of object x's mandatory or optional attributes available available to its child objects (e.g. any objects it contains). For this kind of object-object link, object y would typically be an artefact.

"holds" The holds link type is used to indicate non-technical object-object relationships such that an object x could be used to group objects y and z.

"of interest to" The "of interest to" type is used to indicate non-technical object-object relationships such that a child object y could be interesting in relation to a parent object y.

Relationships between objects can be characterised as "fully descnbable" or "loosely described". A relationship between artefacts/archetypes is fully describable when it conforms in every respect with one of a number of logical statements about the entities. The link object allows the following fully describable relationships to be denoted:

"contains" (as described above)

"is-a-kind-of more specific" As in "is-a-kind-of more specific y"; an object x can only hold the relationship "is-a-kind-of more specific" with y if y denotes an archetype (as distinct from an artefact). In a preferred embodiment of the invention the system knows the object denotes an archetype when its archetype attribute is set to true.

uses (as described above)

Loosely described relationships can be used when the object is known to relate to other objects but when the logic of relationship is not yet certain or fully investigated by the user. Loosely described relationships include:

"is-a-kind-of unspecific"

"typically uses"

"is an archetypal"

The link object allows the following relationships to be denoted for object-attribute links:

"mandatory" When an object x is linked to an attribute z of object y with a mandatory link, it inherits the attribute and represents it as mandatory.

"optional" When an object x is linked to an attribute z of object y with an optional link, it represents the attribute z as an optional attribute and the object x is said to represent variants.

The nomenclature of the objects and the relationships that are available is arbitrary, and other names could be used.

When a hierarchy between objects is being defined the system provides a means for checking the hierarchy so as to maintain its logical integrity, either through allowing only relationships consistent with the logical rules of the hierarchy or through warning/indicating to a user (e.g. a human or an external system) that those rules will be violated if they proceed with defining the relationship. The rules apply to fully describable relationships. The logical rules include:

1. If an object x is said to contain an object y and y is said to contain an object z, the system will not allow z to contain a y or z to contain an x - the system may automatically provide a warning to a user that relationship rules will be violated if the user attempts to define a relationship such that z is said to contain a y or if z is said to contain an x.

2. Any object which is said to contain an archetype object must itself be an an archetype.

3. If an object y uses, is held-by or is of interest to an object x, y is not allowed to inherit object x's optional attributes. In other words y is not allowed an object- attribute link with an attribute of x.

4. An object x can only be defined as being an is-a-kind-of more specific object y if y is an archetype.

If the system detects an attempt to define a relationship that violates one or more of these rules then it may issue a warning, but allow the user to override the rule and define the relationship anyway, or it may prevent the relationship from being defined. Instead of (or in addition to) checking the hierarchy at the time when relationships are entered, the system may provide a facility for checking the whole or a part of a previously defined hierarchy for consistency with the rules.

Figure 1 illustrates an example of an object hierarchy.

The system provides a means for definitions of the objects to be entered. It should be noted that the standardised nature of the objects means that the data can readily be entered by a non-technical user. After any verification, the objects are stored in a database as a recombinant object hierarchy.

The system further provides a means for a user to query the database and to selectively retrieve and display information based on the stored hierarchy. Non- limiting examples of the types of query that may be performed are as follows: 1. The system allows a user to selectively output or display all child object members of the hierarchy that have a relationship of a specified type with a specified member of the hierarchy.

2. The system allows a user to select an object and to then retrieve the details of that object and its immediate relations.

Object hierarchies may become extremely large, where an object y may be directly and indirectly used by (as defined above) or contained by a potentially unlimited number of other objects (e.g. if y is used by b and b is used by x then y is used by x but this fact is determined indirectly by the relationships that pertain between y,b and x and any objects that may contain y.b and x). The system may also provide a means to constrain the results to those that are less than a given number of steps from the object that is the subject of the search.

The results of such queries may be filtered according to filter definitions made by a user. The available filter definitions could include:

• The system allows any output data to be filtered by object type. A user may select which types of object should be included in the output.

The system is preferably arranged to allow for graphical display of the hierarchical relationship between selected objects, for example as shown in figure 1. This can permit a user to easily understand the relationships between them.

Additional objects may be accommodated, which can add additional functionality to the database. These objects may include:

Innovation Proposal (InP) Objects These are objects denoting the artefact described by a design proposal or description of a technical invention. The object preferably includes a description of the proposal or description, or a link to such a description.

Artefact Objects An object denoting an existing technology artefact that has not been subject to a patent or innovation proposal. The object preferably includes a description of the artefact, or a link to such a description.

Figure 2 shows an example of the architecture of a separate embodiment of a database system.

In the system of figure 2, reference 1 denotes a database computer comprising a processing section 7 and a storage unit 3. A user interface 2 is provided whereby a user can provide data to the system computer and view output data. The user interface is linked to an input processor 4, which receives input data intended as entries in the database. The input processor forms the input data into database records of the correct format and performs error checks to ensure that the input data obeys the rules set out above. If the input data complies with the rules the input processor enters it into the database, which is stored in storage unit 3. When a query is to be performed the user enters the query using the user interface 2 and the query passes to a query engine 5. The query engine applies the query to the database and passes the results of the query back to the user interface for display. A control unit 6 is provided to supervise the operation of the input processor 4 and the query unit 5, for example to ensure consistency in the use of the database.

References herein to patents should be interpreted as including patent applications and other similar forms of intellectual property protection. References to documents include references to computer-stored documents and web pages or XML documents (either of which could in turn reference further documents).

An arrangement for providing relationships between objects that can help to model the relationships between related entities will now be described. Such an arrangement may be used in the system described above, or in another type of system.

Software languages implementing the object-oriented paradigm support the definition of software objects (components) through classes (or object templates) which may have behaviours (sometimes called functions or methods) and attributes (sometimes called variables). Moreover in the object-oriented paradigm objects implement inheritance such that any given object may be a parent to, or the child of another object. In general, a child object inherits the behaviours and attributes of its parent object, and may define one or more of its own more specific behaviours and attributes that are either additional to those of the parent, or a modification of those of the parent. In the latter case the child object behaviours are said to override the corresponding parent object behaviours and any child object of this first child object will inherit the overridden behaviour and not the original parent behaviour (though in most object oriented systems it is still possible for other objects using a child object to access parent behaviour that has been overridden by the child).

A great benefit of object-oriented programming languages is that when other code or another system utilise the services provided by a software object, it doesn't have to be concerned with the internal design or logical procedures within the object, rather (provided the object is well designed) all an external system needs to understand is the behaviour (and sometimes the attributes) of the object (as defined by the class).

The object-oriented paradigm therefore hides unnecessary complexity inside component objects and this aids high-level understanding of how a given system (or architecture) works; the significant factors being the object behaviours (methods or functions) that might be initiated or controlled. This helps the analyst to "see the forest for the trees."

Object modelling systems allow the presentation of such object relationships without requiring the writing of actual code (i.e. a functional object). Moreover object modelling systems can be used to analyse all manner of technical artefacts, whether or not they use components designed using the object-oriented paradigm. In an object model, whether an object is said to have inherited behaviours may not be evident by inspecting the immediate properties of the object but may require looking to see if the parent has a parent containing those behaviours. By default, through the representation of an inheritance relationship, a child class would be seen to inherit all the behaviours of a parent class.

The present arrangement is especially but not exclusively suitable for an object modelling apparatus, supporting a novel form of object modelling that is particularly appropriate for the rapid modelling of a large number of diverse systems at a high level. The apparatus implements novel features supporting the modelling of technology systems, allowing the high level identification of e.g. enabling technologies, using classes, behaviours (and optionally attributes) where those dependencies might be shared by a large number of technology artefacts. The arrangement has particular advantages in helping users to identify technology artefacts dealing with similar subject matter out of large numbers of technology artefacts.

The present arrangement/apparatus allows a child class - which might be representative of a technology artefact such as an invention - to be linked to a parent class situated in an inheritance hierarchy. The parent class represents behaviours and (optionally) attributes that on analysis (a) must be present in any system instantiating the artefact/invention and (b) are likely to be common to more than one artefact/invention. In accordance with the object-oriented paradigm the parent class represents behaviours and may be a child of other classes higher-up the inheritance hierarchy. However the apparatus supports a novel representation of an object model where a single class in the model can represent variable groups of behaviours. Each class in the hierarchy represents at least a base or mandatory set of behaviours however each class may also represent optional behaviours. In this way a single class in the hierarchy may be representative of multiple possible real- world implementations of a technology (henceforth, such classes will be said to support representational polymorphism and the distinct classes that can be represented by a representation polymorphic object called variants). All children of an class with mandatory and optional behaviours inherit the classes mandatory behaviours; however any given child-class may also selectively inherit the optional behaviours and selectively determine whether the behaviour should be represented (to classes "below" it in the inheritance hierarchy) as mandatory or optional. Using the apparatus a single identifiable parent class can be representative of multiple systems, archetypes, artefacts, configurations or sets of technology dependencies (variants).

To re-iterate: under the rules of the cognitive-object paradigm a second class that is a child of a first class does not automatically inherit the optional behaviours of the first class. So for example if a first class presents a single optional behaviour - and consequently is representative of two variant classes - the second child class presenting no optional behaviours does not automatically represent two variants by virtue of being a child of the first parent class. The second class may however selectively inherit the first class optional behaviour and present it as either optional (in which case it does then represent two variants) or mandatory.

Another feature in the preferred embodiment of the apparatus is simplified polymorphism as the term is understood in the object-oriented paradigm (and not to be confused with "representational polymorphism" defined above). In object-oriented design an object is said to be polymorphic when it can implement behaviours and/or attributes from more than one parent object. In many current object oriented systems an object may only inherit from more than one parent through implementing an interface class, a template defining a standard interface design through which the (second or more) parent objects and child object can communicate. However the cognitive-object model embodied by the invention allows a class definition to inherit behaviours and attributes directly from more than one parent, without requiring the definition or representation of an intermediating interface (though the possibility of defining such a class is not excluded).

Figure 3 shows simple polymorphism. ARC1012 has two parent classes and inherits behaviours from both (ARC1015 and ARC1019). When a first class meets certain criterion, it can be represented as one amongst a number of family variants. A family variant is determined to exist when a second class has an inheritance relationship such that it inherits mandatory behaviours from the same number of classes as the first class and where those classes have the same lineage as the first class and where that class is not itself a parent or a child of the second class. The default inherited behaviours however will vary in so far as some of the behaviours between the two classes will be an adapted or overridden form of the behaviours contained in the other class (a variant is then most usually a more or less specific form of the first class - we can only say "most usually" because it is always possible to override a defined behaviour with some wholly unrelated piece of functionality, though for the purposes of the cognitive-object model this would most usually provide an indication of bad design). In the preferred embodiment, inheritance is only supported by the contains link type. For the purpose of determining variants, all objects linked by link types other than contains are ignored.

Figure 4 provides a view of a class hierarchy implementing representational polymorphism and also shows family variants. Note ARC1059 and ARC1012 are not family variants of each other because they do not share the same lineage. ARC1012 inherits from ARC1019 whereas ARC1059 does not. In the preferred embodiment even if ARC1019 did not contain any behaviours and attributes for ARC1012 to inherit, ARC1012 would still be deemed to inherit from ARC1019 and therefore to have a different lineage to ARC1059 and ARC1015. Whether the lineage a first class has is the same as that held by a second class may be determined by tracing each object's inheritance to the highest related parent classes each class inherits from and verifying if those parent classes are the same. Figure 4 also provides illustration of the selective inheritance of optional behaviours. Class ARC1059 selectively inherits the behaviour "decode and output widescreen aspect ratio" from the parent class ARC1048.

Using the apparatus supporting the representation of variants, a class hierarchy with inheritance can typically represent a greater range of technical systems and functionality with fewer classes than object modelling tools utilising the standard representations of the object-oriented paradigm. When working at a high level (e.g. when surveying an entire technology sector) the representation of fewer classes helps to improve cognition of the salient behaviours and optional configurations.

However, in an important regard, the representation the apparatus provides is wholly consistent with the object-oriented paradigm. As such transformational rules could be applied to translate a model represented by the cognitive-object paradigm into a model in the object-oriented paradigm and visa versa.

In the preferred embodiment the apparatus provides a database (relational, object- relational or otherwise) for storing the class objects and the relationships between the classes of a model in the cognitive-object paradigm. The apparatus supports in data, the representation of inheritance and polymorphism. It additionally supports the representation in data, of variant classes through supporting the definition and presentation of mandatory and optional behaviours. In the preferred embodiment the apparatus allows a user to browse classes in an inheritance hierarchy, see parent and child relationships for each class, view the details related to those classes, add new classes, delete existing classes and amend classes.

The apparatus enforces a logic when dealing with the representations in data. In the preferred embodiment the logic allows a child object to be directly related to one or more parent objects. Unlike most software object oriented languages the representation of polymorphism doesn't require the formal user definition and implementation of an interface class to intermediate relationships between the second or more parent classes. In the preferred embodiment the apparatus enforces a further logic on the representation of inheritance where a child class always inherits at least the mandatory behaviours of its parent class and can further inherit none, some or all it's parent's optional behaviours (e.g. on a selective basis). Further, for each optional behaviour selectively a child class inherits from its parent, it can be determined on a selective basis whether the behaviour will be represented by that class as mandatory or optional. If it is represented as mandatory, that behaviour no longer provides an optional variant to any children of the child object (i.e. the determination that the behaviour is mandatory overrides any parent classes representation of the behaviour as optional).

The apparatus provides a procedural logic to determine the identity of directly related child-classes for any first given class, according to a number of criteria: a. Each child class inheriting at least the first classes' mandatory behaviours regardless of if the child object inherits the additional optional behaviours as mandatory or as optional. This will return any class that is a direct child of any and all the variants of the first given class. b. Each child class inheriting the first given classes' mandatory behaviours and one or more specified behaviours from the first given classes' optional behaviours to be represented as either mandatory or optional by the child class for at least a select specific list of the first given classes' optional behaviours. c. Each child object inheriting the first given classes' mandatory behaviours and that inherits optional behaviours from the first class to be represented as mandatory by the child for at least a select specific list of the first given classes' optional behaviours. d. Each child class inheriting the first given classes' mandatory behaviours only and that does not inherit any additional optional behaviours. e. Each child class inheriting the first given classes' mandatory behaviours only and that does not inherit any additional optional behaviours as mandatory. f. Each child class inheriting the first given classes' mandatory behaviours and one or more specified behaviours from the first given classes' optional behaviours to be represented as either mandatory or optional by the child class but that inherits no more behaviours than those specified. g. Each child class inheriting the first given classes' mandatory behaviours and one or more specified behaviours from the first given classes' optional behaviours but that inherits no more optional behaviours to be presented as mandatory than those specified.

Other options may also be available.

In the preferred embodiment the apparatus contains a procedural logic for determining the inherited behaviours (and optionally attributes) of a class through inspecting the defined behaviours (and attributes) of each of its parent class, aggregating those behaviours (and attributes) but ignoring any overridden behaviours (or attributes). In the preferred embodiment some of the classes are representative of inventions described by patent documents (known henceforth as invention classes).

In the preferred embodiment, the apparatus contains a procedural logic to determine if any given class has children.

In the preferred embodiment the apparatus has an interface for obtaining patent data from a database of patent data.

In the preferred embodiment, all object types contain the fields shown in Figure 11 table (A). The data types and lengths shown are practical examples only and are not mandatory nor essential to the invention. The lengths shown represent the maximum number of characters that can be stored for each field. A person skilled in the art of database design and programming would be able to select alternative equally appropriate data types and field sizes for implementing the invention. Nor are the fields exhaustive of all the fields, types or tables required to construct e.g. a relational database implementing the invention. Again a person skilled in the art of database design and programming would be able to construct an appropriate data schema for supporting the implementation of the apparatus.

Not all object types support behaviours and attributes. In the preferred embodiment only patent objects and archetype objects support the definition of behaviours and attributes.

In the preferred embodiment patent objects also support the additional data fields identified in Figure 11 table (B).

In the preferred embodiment the output may be directed to a VDU and incorporated within a user interface.

Figure 5 shows the user interface arrangement of the preferred embodiment. The user interface window (1 ) shows a graphical Object Browser allowing a user to navigate a graphical representation of an inheritance hierarchy in the cognitive-object paradigm. The browser may be used as part of a larger application and on being invoked may be passed an initial object identifier to determine the currently selected object (the diagram illustrates (4) an Archetype Class object ARC1012 TV device + schedule data). In other embodiments the interface may also provide access to additional user interfaces, such as pop-up window forms, for allowing the user to add new classes, edit classes, and find classes. Any object may be designated as the currently selected object, in which case it will be shown at the position occupied by (4) under the current object title.

If the current object has one or more parent object, they will be shown to the left. Figure 5. provides illustration of three such parent objects indicated by (3) and (19).

If the current object has one or more child objects, they will be shown to the right (10) under the heading "children". It can be seen that the current object has many such child objects. For convenience of browsing the presentation of parent objects, the current object and child objects is different. Parent objects display only the ObjectlD and Title field. The current object displays an ObjectlD, Title, and Description field and, if the object type supports them, any defined behaviours and attributes in their respective panels.

The child objects show only the child object Unique Identifier and Title displayed in a format designed to ease browsing if there is a long list of child objects.

In addition to a currently selected object, any object whether in the parents position on the left of the interface, the current object position in the middle of the interface or the children position on the right of the interface, may be highlighted by clicking it with a mouse pointer, in which case it becomes the target object for buttons (13), (14) and (15) to act upon. The effect these buttons have is described later in this document.

Typically the fact that a class object is highlighted would be designated through applying a colour effect to the currently highlighted object. The dotted line around the patent class object (invention class) (11 ) in this diagram is indicative of an applied highlight. Another consequence of highlighting a class object is that panel (12) is updated to display additional more detailed information associated with the class. The information shown in this panel is information associated with the object type, but may show different data fields for different object types (e.g. for objects other than classes).

In the preferred embodiment the object types include patent classes (which can represent patents or patent applications), archetype classes and classification objects.

In the preferred embodiment, when an patent class is highlighted, the panel information shows the patent application or granted patent number (ObjectlD), Title, Novelty, Application and Benefit. If the panel does not provide enough space for the display of all the information associated with the current object, the additional information can be scrolled into view by use of the scroll bar (17).

In the preferred embodiment when an Archetype Class is highlighted, the panel information shows the ObjectlD of the Archetype Class, the Title, the Description, mandatory behaviours and attributes and optional behaviours and attributes. Figure 8 provides an example of the panel display when an archetype object is highlighted.

The area underneath the parents title is used to display the parents of the current object (4), in this case ARC1016 and ARC1019 are illustrated (3). The user may double click any of these with a mouse pointer to designate the object as the current object or first highlight it and then select the "make current" button (14) to achieve the same result. In this event, the object is shown in the current object position and any parents it has shown under the parents position and any children it has under the "children" position. If there are more child objcts than can be displayed in the space available, the content of area (18) becomes scrollable by use of the scroll bars (16) on the right hand side of the panel and the scrolling action allows access to the additional data.

The children list (10) provides a list of objects that are children of the current object. These may include (but are not limited to) Archetype Classes and Patent Classes. Like the parents list the user may double click any of these with a mouse pointer to designate the object as the current object, in which case the object is shown in the position of (4). The parents and children objects are updated to reflect the parents and children of the new current object. If there are more child classes than can be displayed in the space available, the list becomes scrollable by use of the scroll bars (16) on the right hand side of the panel.

New classes can also be selected by using the mouse pointer to first highlight the class in the class list and clicking the "make current" button (14) with the mouse pointer. Each class object, including invention class objects, may have more detailed data associated with it than window (1 ) (including panel 12) can display. In the preferred embodiment the more detailed data may be accessed through activating the "View Detail" button (Figure 10 shows the resulting pop-up form and further description regarding this form is given below, though access to and display of this form is not essential to the invention claimed here).

Additionally the panel (12) is used to display a selection of additional data associated with the currently highlighted object. If the user highlights a new object through clicking it with the mouse pointer, behaviours defined by the currently selected class are shown at (6) and (7) in the panel labelled behaviours. Behaviours, if present, may be mandatory or optional.

Mandatory behaviours (6) are indicated with a square black bullet point next to them. In the preferred embodiment mandatory behaviours are associated with a class (and displayed for the current class), either because a mandatory behaviour has been defined as part of that class, or because one has been inherited as mandatory from an optional attribute included in one of the immediate parents of the class.

Optional behaviours (7) are indicated with a square selection box containing an asterisk next to them. The operation of this selection box is similar for both optional behaviours and optional attributes and is described below.

The panel labelled "attributes" is similar to the behaviours panel but displays attributes of the class if any are present. Attribute (8) is mandatory, and attribute (9) is optional. The scroll bars (16) can be used in the event the list of behaviours and/or attributes is greater than can be displayed in the available screen space (18).

Selection boxes (7 and 9) are displayed to the left of optional behaviours and attributes if the current class object has them. In the preferred embodiment a class has optional behaviours and attributes if they have been defined for that class or if it has been defined to inherit the optional attributes of a parent class as optional.

The selection box associated with an optional behaviour or attribute can be toggled between three states. The toggle action is used to select between different filter states applicable to the list of child objects. In the preferred embodiment, the first and default state of the optional behaviour or attribute selection box displays an asterisk. When in this state the optional attribute has no effect on the list of child objects. All child objects will be shown regardless of whether they inherit the behaviour or attribute.

The second state is accessed by clicking the selection box once with the mouse pointer. In the second state the selection box displays a "+" sign. In this state a filter is applied to the list of child objects (10) and the display of the list is updated to reflect the filtered set. In this state a child object is only selected by the filter if it inherits the selected attribute (either as optional or as mandatory).

The third state is accessed by clicking the selection box a further time with the mouse pointer. In the third state the selection box displays a "-" sign. When this state is selected, a filter is again applied to the list of child classes (10) and the display of the list is updated to reflect the filtered set. This time a child class is only selected by the filter if it does not inherit (i.e. has not been defined as having inherited) the optional attribute as either an optional or a mandatory behaviour or attribute.

When an object contains multiple optional behaviours and/or attributes in multiple states of selection, the filter applied to the selection of the children is a logical AND between displayed classes. The effect the application of a logical AND has on the display is illustrated by the truth table shown in figure 9.

Figure 9 refers to a hierarchy containing objects a, b, c, d, e and f where:

a is a parent class with optional behaviour b1 and optional behaviour b2 b is a child of a and does not inherit either b1 or b2 as either mandatory or optional c is a child of a that inherits b1 only d is a child of a that inherits 62 only e is a child of a that inherits both b1 (as optional) and b2 (as mandatory) f is a child of a where the link between a and f is a link type that does not support inheritance (e.g. as is the case for the of interest to link type)

The rows under columns b1 and b2 in figure 9 show the total number of states it is possible to select. The asterisks, plus signs and minus signs in columns b1 and b2 indicate each of the selection states identified by the same symbol used in the selection box of optional behaviours and/or attributes (shown at (7) and (9) in Figure 5)

Note: class object e inherits b1 as optional and b2 as mandatory, but this has no effect on the logic for selective display. In both cases e is treated as inheriting the optional attribute.

Returning to Figure 5, in the preferred embodiment, clicking the selection box a third time returns it to the default state, the default selection criteria are applied to the displayed list of child classes.

Whenever any changes are made to the data content of any of the classes, or the structure of the class hierarchy, the contents of the graphical object hierarchy display panel (18) and the additional information panel (12) are updated to reflect the changes.

In the preferred embodiment a Circle (20) is used to denote that a holds relationship type pertains between the parent and child object. Similarly a dotted line (21 ) indicates an of interest too link pertains between the parent and child object. Other symbols and indicators can be used for other link types. A solid black line leading into the parent or child object indicates a contains relationship type. Figure 6 shows the architecture of the apparatus in the preferred embodiment, implemented as a local client/server application, built as a Windows PC program connecting to a relational database server.

(1 ) is a standard Windows PC client, running a 32-bit version of the Windows OS (7) such as Microsoft Windows XP, and loaded with the Microsoft .Net framework (6). The application (2) is deployed as a stand-alone executable program, logically structured in a conventional 3-tier architecture comprising a User Interface (3), Business Services (4) and Data Access (5). The database (9) will typically reside on a separate server which hosts a relational database management system, such as Microsoft SQL Server, or Oracle. Access by the program application to the data in the server is made via a local network connection (8) using a standard data access application programming interface (such as OLE-DB or ODBC).

This embodiment of the system would typically be deployed as an in-house solution for maintenance of the database, entry of new data, and general research and analysis.

Although the preferred architecture for implementing the apparatus is shown, the claimed invention may form a component part of an application containing additional features.

In Figure 7. the apparatus is implemented in an architecture for users to access the database over a remote link (7) - typically the Internet. In its design it shares many of the component assemblies described for Figure 6 above.

In this embodiment the client PC (1 ) can be any general computer device able to provide Internet browsing facilities (5). All access to data on the database (16) is provided by use of standard TCP-IP, HTTP and SOAP protocols, connecting the client application (2) including a user interface (3) and Web Services access layer (4), to a Web Services Application (9) via Web Service facades (10) running on the remote server (8). In the preferred embodiment the Web Services have been implemented as Microsoft ASP. Net applications running on the Microsoft .Net Framework (14) running in Microsoft Internet Information Server (13) on a Windows 2000 server (15), but since web services in general are an industry standard, the specific details of the implementation are not material to the features and functionality of the apparatus as described.

Figure 10 shows an example of the pop-up additional information form shown when the user in two different modes. Mode (A) shows the mode of the form when the currently highlighted class in Cognitive Object Model Browser (as shown in Figure 5), is an invention class representing a patent or patent application. It will be evident to someone skilled in the art that the data fields shown though advisable are neither mandatory nor limiting. (2) shows a cluster of industry standard window controls commonly found in an operating system such as MS Windows. If the data occupies mores space than is available in the information panel area (1 ) scroll bars 3 allow the user to scroll the additional information into view. When the user has finished browsing the information on this form, selecting the done button (4) with the mouse pointer will dismiss the form.

Mode (B) shows the form in a different mode, reflecting the fact the additional information form pertains to an archetype class. In this case the fields shown in the information panel (5) reflect the data and properties associated with an archetype class.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. Data processing apparatus arranged to process objects in accordance with stored dependency relationships between the objects, the data processing apparatus comprising: storage means for storing at least one property of each object, and an indication of whether the property is a mandatory or an optional property of the object, and for storing definitions of dependency relationships between the objects; and processing means arranged to process the objects in accordance with the stored relationships such that an object having a dependency relationship on another object is treated as having the or each mandatory property of the other object, and as having the or each optional property of the other object if the stored definition of the relationship between the objects indicates that the property is inherited by the object, and as not having the property otherwise.

2. Data processing apparatus as claimed in claim 1 , wherein the processing means is arranged to process the objects in accordance with the stored relationships such that an object having a dependency relationship on another object is treated as having the or each mandatory property of the other object, and as having the or each optional property of the other object: as an optional property if the stored definition of the relationship between the objects indicates that the property is inherited as an optional property by the object; as a mandatory property if the stored definition of the relationship between the objects indicates that the property is inherited as an mandatory property by the object; and as not having the property otherwise.

3. Data processing apparatus as claimed in claim 1 or 2, wherein the data processing apparatus is an object oriented data processing apparatus and each of the said objects is a class or representative of a class.

4. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is an object oriented data processing apparatus and one or more of the said properties is a behaviour.

5. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is an object oriented data processing apparatus and one or more of the said properties is a variable.

6. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects having a specified property as a mandatory property.

7. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects having a specified property as an optional property.

8. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects having a specified property as a mandatory or an optional property.

9. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects directly related to a specified object and having one or more specified optional or mandatory properties in common with that specified object.

10. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects directly related by a dependency relationship to a specified object and having one or more specified optional properties in common with that specified object.

11. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects directly related by a dependency relationship to a specified object and having one or more specified mandatory properties in common with that specified object.

12. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects directly related to a specified object and having one or more specified optional or mandatory properties in common with that specified object, and having no other properties.

13. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects directly related by a dependency relationship to a specified object and having one or more specified optional properties in common with that specified object, and having no other properties.

14. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects directly related by a dependency relationship to a specified object and having one or more specified mandatory properties in common with that specified object, and having no other properties.

15. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having one or more specified optional or mandatory properties in common with that specified object.

16. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having one or more specified optional properties in common with that specified object.

17. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having one or more specified mandatory properties in common with that specified object.

18. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having one or more specified optional or mandatory properties in common with that specified object, and having no other properties.

19. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having one or more specified optional properties in common with that specified object, and having no other properties.

20. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having one or more specified mandatory properties in common with that specified object, and having no other properties.

21. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having only one or more specified optional or mandatory properties in common with that specified object.

22. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects directly or indirectly related by a dependency relationship to a specified object and having only one or more specified optional properties in common with that specified object.

23. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects indirectly related by a dependency relationship to a specified object and having only one or more specified mandatory properties in common with that specified object.

24. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects for which there is another object that has a dependency relationship thereon.

25. Data processing apparatus as claimed in any preceding claim, wherein the data processing apparatus is capable of processing the objects to select all objects that are indirectly related by a dependency relationship to both of two other objects.

26. Data processing apparatus as claimed in any of claims 6 to 25, wherein the data processing apparatus is capable of forming a list consisting of all the selected objects and outputting that list to a user.

27. Data processing apparatus as claimed in any preceding claim, wherein at least some of the objects represent inventions, the subject of patents or patent applications.

28. Data processing apparatus as claimed in any preceding claim, comprising a data transfer interface for querying a database and automatically populating the storage means with objects and attributes thereof in dependence on the content of the database.

29. Data processing apparatus as claimed in claim 28, wherein the database is a database of data concerning patents and patent applications.

30. Data processing apparatus as claimed in claim 28 or 29, wherein each object represents an item of intellectual property or a technical disclosure.

31. A database system arranged to store data objects, the objects comprising: a first type of object for representing subjects consisting of patents or patent applications and /or instances of technical disclosures and/or instances of actual technology; and a second type of object for characterising relationships between the subjects of objects of the first type.

32. A database system as claimed in claim 31 , wherein the first type of object can take one of two forms: a first, patent form representing a patent or patent application; and a second, archetype form representing a specific instance of a technical disclosure or an instance of actual technology.

33. A database system as claimed in claim 31 or 32, wherein each object of the second type includes an indication of the identities of the objects of the first type between whose subjects it characterises a relationship, and an indication of the type of the relationship.

34. A database system as claimed in claim 33, wherein the relationship can only be one of a set of predetermined types of relationship.

35. A database system as claimed in claim 34, wherein the predetermined types of relationship include the relationship wherein the subject of one object of the first type contains the subject of another object of the first type.

36. A database system as claimed in claim 35, wherein the system is arranged to perform an error-checking routine to determine whether if a first object is defined as containing a second object, the second object or any object defined as being contained by it is defined as containing the first object.

37. A database system as claimed in claim 35 or 36 as dependent on claim 32, wherein the system is arranged to perform an error-checking routine to determine whether a first object of the second, archetype form is defined as containing a second object not of the second, archetype form.

38. A database system as claimed in any of claims 33 to 37, wherein the predetermined types of relationship include the relationship wherein the subject of one object of the first type is-a-kind-of-more-specific subject with respect to the subject of another object of the first type.

39. A database system as claimed in claim 35 or 36 as dependent on claim 32, wherein the system is arranged to perform an error-checking routine to determine whether a first object is defined as being a-kind-of-more-specific with respect to an object of the second, archetype form.

40. A database system as claimed in any of claims 36, 37 or 39, wherein the system is arranged to, if the said determination is positive, prevent the said definition or require user confirmation of the said definition.

41. A database system as claimed in any of claims 31 to 40, wherein the objects are stored as classes in an object oriented programming language, classes in an object- relational database, or records in relational database schema.

42. A database system as claimed in any of claims 31 to 41 , comprising a user interface whereby a user or another system may enter definitions of objects for storage in the database.

43. A database system as claimed in any of claims 31 to 42, wherein each object has a unique identifier.

44. A database system as claimed in any of claims 31 to 43, comprising a search unit capable of selectively outputting all objects that are defined as having a uses relationship with a specified object.

45. A database system as claimed in any of claims 31 to 44, comprising a search unit capable of selectively outputting all objects that are defined as having a uses relationship with a specified object or a uses relationship with any other object that is defined as having a contains relationship with that specified object.

46. A database system as claimed in claim 44 or 45, wherein the search unit is capable of limiting the object that it outputs to those linked directly to a specified object or indirectly to that object via a predetermined number of steps or fewer.

47. A method for forming a database of data objects, the method comprising defining objects comprising: a first type of object representing subjects consisting of patents or patent applications and /or instances of technical disclosures; and a second type of object characterising relationships between the subjects of objects of the first type.