GB2349241A

GB2349241A - Computer-implementable trading exchange

Info

Publication number: GB2349241A
Application number: GB9908558A
Authority: GB
Inventors: Freddie Mcmahon
Original assignee: IQ PORT INTERNATIONAL Ltd
Current assignee: IQ PORT INTERNATIONAL Ltd
Priority date: 1999-04-14
Filing date: 1999-04-14
Publication date: 2000-10-25
Also published as: AU3980600A; WO2000062183A2; WO2000062183A8; GB9908558D0

Abstract

A computer-implementable trading exchange comprises one or more computer-implementable objects respectively representing assets for trading in the trading exchange. Each of the objects may include a modifiable property. The trading exchange includes an object management engine 126 configured to be responsive to a management control input to select an object and to modify a property of a selected object. Additionally, the trading exchange includes an object transaction engine 124 configured to be responsive to a first transaction control input to select an object and to conduct a transaction in respect of a selected object.

Description

2349241 SYSTEM, APPARATUS AND METHOD FOR A COMPUTER-IMPLEMENTABLE TRADING

EXCHANGE The present invention relates to a system, apparatus and method for a computer implementable, trading exchange. In particular, but not exclusively, the present invention relates to facilitating and conducting transactions in computer- implemented objects representing tradeable assets within an electronic environment.

A recent development in the business and working world is the emergence of so called "knowledge workers". Such workers are characterised by their need to obtain a large amount of different types of information or data, and to assimilate that information or data to produce some form of work product, for example a report. Additionally, such workers may require access to particular products or services in order to perforrn their tasks, such as computer programs or even consultancy services. It is in the nature of the task or work performed by a "knowledge worker" that the information, data, products or services necessary for the workers to perform their designated task is only required for a relatively short period of time, that is to say during and up to the completion of the task.

Once a current task has been completed, the "knowledge worker" is usually commissioned to perform another task, not necessarily related to the previous task, Thus a new set of information, data, products or services will be required.

Thus, such workers in particular, require a good level of accessibility to relevant information and data, products or services, in particular where it is time-sensitive. Thus, there is a need for the appropriate information, data, products and services, to be managed and organised in a way which provides good accessibility and identification of relevant information, data etc. The requirement for such good accessibility and identification is not limited to "knowledge workers", but is generally relevant to other types of people.

At the same time as the emergence of the "knowledge worker" there has been an enon-nous growth in the provision of telecommunication services and communications 1 2 systems, which has resulted in increased opportunities for people to communicate with each other. This is of evident benefit to "knowledge workers" since such communication provides a means by which they can obtain the information, data, products or services which they may require to perform their tasks. A particularly important and common 5 communication system is the internet.

The internet is a network of computer systems, each having a unique address. By appropriately identifying a destination computer system by its address, it is possible from a starting computer system to access information contained on the destination computer.

The internet is configured such that a route by which a destination computer system is reached may vary depending upon the availability of computer system resources within the internet. That is to say, it is possible to find one's communication routed via several different routes, depending upon which intermediate computer systems are available. Communication over the internet is restricted to a particular format in accordance with an Internet Protocol (IP), so that each computer system within the network can understand the data that is being sent to it. However, the actual communication system over which IP forinatted data or messages may be sent is varied, and may comprise ISDN communication links, Plain Old Telephone Systems (POTS), mobile telephone systems or other telecommunications networks. A number of different telecommunications networks may be used for any given routed message, and the systems used are transparent to the user.

A significant element of the communication traffic over the internet is related to the seeking and provision of information. Additionally, it is possible to purchase goods and services over the internet, for example books from the virtual book shop at WWW.AMAZON.COM. However, virtual stores such as AMAZON.COM operate as conventional retailers. That is to say they purchase products wholesale at an agreed price, and then set the retail price according to the profit they wish to make on the product. Customers of the virtual stores order goods over the internet and pay the retail price typically by providing their credit card details, or by being invoiced separately. The actual transfer of ftinds from the customer, or the customer's agent in the case of credit 3 card transactions, occurs by the appropriate reconciliation process. Optionally, regular or established customers may have an account with the virtual store, which may be a credit card account or a pool of funds lodged with the store. Other goods or services may be sold over the internet, for example film, video clips or music. Information is also sold.

However, the sale of goods is predominantly by the traditional retail model. An exception to this is the buyer-driven commerce model disclosed in US Patent No. 5,794,207, in which a buyer offers a fixed price for a service to a community of sellers. Members of the community of sellers have the option to accept the offer, such acceptance binding the buyer to a contract at the offer price. A particular example disclosed in the patent is the buying and selling of airline tickets. This system is implemented over the intemet for example.

However, known systems for providing information, data products or services within a virtual environment, such as the internet suffer from the drawback that they require the provider of the information, data, services or products to set up a virtual store by way of a web-site, for example, through which information etc. may be traded. Additionally, it is necessary to provide systems to arrange for the delivery of any hard goods, and for payment. Also, the information and products are restricted to tangible items, such as computer files or books.

Hitherto, trading on the intemet has required significant investment in both time and money for the trader, and it is not open nor easily accessible to ordinary individuals. Consequently, much of the information provided over the intemet is at the discretion of the companies running the stores. Furthermore, it may not be up-to-date, relevant or 25 credible. As mentioned above, within today's knowledge society a knowledge worker in particular requires access to a very wide variety of information, data, services or products, and may find that their need is not satisfied by the existing conventional trading stores or data bases provided in an environment such as the internet. Much knowledge is not accessible in any conventional sense, that is to say it resides with individuals or within 30 their organisations and is not generally made available to the public. Very often the reason why the information is not generally made available to public is because there is no 4 appropriate or suitable means for doing so, in particular a means which provides for the payment in return for the provision of such information etc. This is a significant drawback to business and commercial development.

There are significant technical challenges and problems in creating an environment in which individuals, as well as organisations, are able to provide information and other products, for example but not necessarily information and products represented by electronic signals such as digital signals, which can be traded and exchanged. Furthermore, such problems are further compounded when it is necessary to provide a system by which fees may be charged for the provision of such information and products. In particular, problems arise in providing such a signal exchange or trading system in which exchanges, transactions and payment may be made in "realtime", or at least appear to be made in real-time, or in a "live" environment.

The technical problem or challenges may be summarised as being the provision of an electronic system, such as a computer system for exchanging or trading a plurality of disparate assets (information, data, products and services) represented by electronic signals. The electronic signal exchange or trading system may be accessed via a plurality of other electronic systems, e.g. computer systems, preferably multi- platform systems, to exchange and conduct transactions for separate and individual assets within a live multiple access multi-user environment. Another problem is how to represent the assets such that they can be exchanged and traded within an electronic system such as a computer system, preferably networked to other computer systems. The combination, development and operation of such a trading system involves very significant challenges, in developing suitable apparatus, which may be program controlled, and electronically, preferably computer, -implementable representations of the assets which can be created, modified and exchanged, or at least accessed and read, and programs for performing those functions within a multi-access multi-user computer system. Furthermore, suitable apparatus for representing assets and manipulating them require development.

In accordance with a first aspect of the present invention, there is provided a computer-implementable trading exchange, the trading exchange comprising one or more computer-implemented objects respectively representing one or more tradeable assets for trading in the trading exchange. The objects may optionally have a modifiable property.

The trading exchange also comprises an object management engine which is configured to be responsive to a management control input to modify the property of a selected object. The trading exchange may also or optionally comprise an object transaction engine which is configured to be responsive to a transaction control input to conduct a transaction in a selected object. The object management engine and object transaction engine perform 10 independent functions and may be operated independently of each other.

In a preferred embodiment the trading exchange further comprises a user interface mechanism which is configured to display a property of an object for trading in the trading exchange, the user interface mechanism is responsive to a control input from a user to modify a displayed property and to communicate said control input to said object management engine for modifying the property of the selected object. Optionally, the user interface mechanism may be separately, or contemporaneously, configured to display a control button which when activated by the user communicates the second control input to the object transaction engine for conducting a transaction in the object.

Embodiments in accordance with the first aspect of the invention provide an electronic trading environment in which assets represented by computerimplemented objects may be traded and the object characteristics modified, for example depending upon the trading history of the asset represented by the object. For example, if a particular property were the price of viewing the contents of an object, i.e. the asset represented by the object, it may be possible to either increase or reduce the price accordingly depending upon whether users of the trading system were purchasing that asset. An object may comprise other properties, and the properties may be modified from time to time throughout the lifetime of the object. Additionally, it is possible to trade in shares in the objects within the virtual environment.

6 In accordance with a second aspect of the present invention there is provided a computer system for implementing a trading exchange, the computer system comprising a processor, a storage medium, an interface device and a program implemented trading exchange, the trading exchange comprising one or more computer-implementable objects representing one or more tradeable assets for trading in the trading exchange, each object optionally having a modifiable property. Additionally, the trading exchange comprises an object management engine configured to respond to a management control input to modify a property of a selected object, and an object transaction engine configured to respond to a transaction control input to conduct a transaction in respect of a selected object.

Embodiments in accordance with the first and second aspects of the invention enable experienced people with intellect of potential commercial value to allow access to their knowledge, and provide a mechanism for receiving payment for that knowledge, for example. Embodiments in accordance with the invention may allow individuals and organisations to realise the full value of their knowledge, competencies, skills, products and services for example, on a global scale by providing a mass market computer implemented distribution channel.

In a third aspect of the present invention, there is provided an object transaction engine for a computer-implementable trading exchange comprising one or more computer-implementable objects representing one or more tradeable assets, each object optionally including a modifiable property. The transaction engine is configured to respond to a first control to select an object, and to conduct a transaction in the selected object in accordance with that property. The property may be the price for that object, for example.

In accordance with a fourth aspect of the present invention, there is provided an object management engine for a computer-implementable trading exchange comprising one or more computer-implementable objects representative of one or more tradeable assets, each object including a modifiable property. The management engine is 7 configured to respond to a first control input to select an object, and to update the selected object with a modified property responsive to a second control input, thereby redefining the object character.

In accordance with a fifth aspect of the present invention, there is provided a computer system network for implementing a trading exchange, a computer system network comprising a server computer system linkable via a communications medium to client computer system. The server computer system includes a processor, a storage device and an interface device suitable for communicating via the communications medium. The server computer system further includes a program implemented trading exchange comprising one or computer-implementable objects representing one or more tradeable assets for trading in the trading exchange, each of which may optionally include a modifiable property. The trading exchange also comprises an object management engine configured to respond to a first control input to modify a property of a selected object, and an object transaction engine which is configured to respond to a second control input to conduct a transaction in a selected object. The client computer system includes a processor, a storage device and an interface device suitable for communicating via the communications medium. The client computer system is configured to provide an interface mechanism to the transaction and/or management engine for communicating a control input to select an object and to conduct a transaction and/or modify a property of the selected object.

In accordance with a sixth aspect of the present invention, there is provided a client computer system linkable via communications channel to a server computer system including a program implemented trading exchange comprising one or more compute implemented objects representing one or more assets for trading on the exchange, each of the objects may optionally include a modifiable property. The client computer system comprises a processor, a storage device, a display medium for displaying a property of an object, an interface mechanism for communicating with the server computer system, and an object transaction and/or management engine which is prograrn implemented by the processor. The object transaction engine is configured to respond to a first control input 8 to select an object in said trading exchange, to copy said selected object and to conduct a transaction in the selected object in accordance with that property. Additionally, the client computer system may also comprise an object management engine configured to respond to a first control input to select an object. The management input mechanism may be further configured to copy a selected object, and to modify a property of the copy in accordance with a second control input. The object management engine is yet further configured to update the selected object with the modified copy of the selected object, thereby re-defining the object character.

In a seventh aspect in accordance with the present invention, there is provided a computer program implemented object representative of an asset tradeable on a computer-implemented trading exchange, said object comprising:

an object property record file including one or more records for storing one or more properties of said object; and associated with a content file for storing content associated with said asset represented by said object. Optionally, the object may represent may an abstract entity such as a consultancy service, or a ticket booking service, in which case the content file for the corresponding object may be empty, or not included, and all the information be comprised in the object proprty record file.

In accordance with an eighth aspect of the present invention, there is provided a computer program for a computer-implemented trading exchange comprising one or more computer-implemented objects respectively representing one or more tradeable assets, each object including a modifiable property, the program comprising:

computer-implementable instructions for configuring a computer to be responsive to a first control input to modify a property of a said object; and computer-implementable instructions for configuring a computer to be responsive to a second control input to conduct a transaction in respect of a selected said object. Optionally, the computer program may also comprise instructions for defining an object representing a tradeable asset for the trading exchange, the instructions computer-implementable to form an object including a content file for storing content 9 associated with the asset represented by the object, and an object proprty record file including one or more records for one or more properties for the object.

Yet further optionally, the computer program may also comprise instructions for a user interface mechanism which is configured to display a property of a selected object on a computer display medium.

Yet further optionally, the computer program may comprise instructions for an object transaction engine for a computer-implementable trading exchange. The instructions are implementable to configure a computer to respond to a first control signal to select an object, to copy a selected object, and to conduct a transaction in respect of the selected object in accordance with at least one property.

In accordance with a ninth aspect of the present invention there is provided a carrier medium comprising computer implementable instructions according to a computer program as described in the foregoing paragraphs.

The carrier medium may be computer readable storage medium such as an optical disk, magnetic disk or tape, or may be a telecommunications medium such as a radio frequency carrier, optical carrier signal, broadcast signal, intemet protocol signal, or voice telephony carrier signal.

In accordance with a tenth aspect of the present invention there is provided an electronic signal representative of an object representing an asset tradeable on a computer-implemented trading exchange, said signal comprising: an electronic representation of a purchase price for the object; and an electronic representation of a description of content associated with said object.

In accordance with an eleventh aspect of the invention there is provided a method for conducting transactions in an asset represented by a computerimplemented object to including a modifiable property, in a computer implemented trading exchange, the method comprising; selecting said object from a plurality of objects in said exchange; making a copy of said object; and communicating object content associated with said object to a user of said exchange.

In accordance with a twelfth aspect of the invention there is providedA method for modifying a property of a computer-implemented object representing a tradeable asset, including a modifiable property, in a computer-implemented trading exchange, the method comprising:

selecting a said object from a plurality of objects in said exchange; making a copy of said object; modifying said property of said copy; and substituting said modified copy for said selected object.

Embodiments in accordance with the present invention will now be described, by way of example only, and with reference to the following drawings, in which:

Figure I is a schematic illustration of a network comprising a server and client computer; Figure 2 is a block diagram illustrating components of a computer system of Figure 1; Figure 3 is a schematic illustration of the concept of an object comprising at least one property and associated with a content; Figure 4 is a block diagram illustrating the function of components of a trading exchange in accordance with the invention; Figure 5 is a schematic illustration of an object property record file structure of an embodiment of the present invention; Figure 6 is a schematic illustration of updateable records for an object property record file of an embodiment of the invention; Figure 7 is a flow chart illustrating creation of an object property record file in accordance with an embodiment of the invention; Figure 8 is a flow chart illustrating the re-use of an object property record file in accordance with an embodiment of the invention; Figure 9 is a schematic illustration of a knowledge classification tree suitable for use with an embodiment of the invention; Figure 10 is a flow chart illustrating a search filter in accordance with an embodiment of the invention; Figure I I illustrates a flow chart of the steps in acquiring an asset represented by an object in accordance with an embodiment of the invention; Figure 12 illustrates a flow chart of the steps in paying for an asset represented by an object in accordance with an embodiment of the invention; Figure 13 illustrates a flow chart of the steps for calculating and distributing net royalties between share owners of an object in accordance with an embodiment of the invention; Figure 14 illustrates a flow chart of the steps for transferring funds from an exchange deposit account to a bank account in accordance with an embodiment of the invention; Figure 15 illustrates a flow chart of the steps for modifying proper-ties of an object property record file in accordance with an embodiment of the invention; Figure 16 illustrates a flow chart of the steps for object price instruction program modules in accordance with an embodiment of the invention; Figure 17 illustrates a flow chart of the steps for purchasing shares in an object in accordance with an embodiment of the invention; Figure 18 illustrates a flow chart of the steps for accreditation of an intellectual capital type object by a guild in accordance with an embodiment of the invention; Figure 19 illustrates a flow chart of the steps for endorsement of an intellectual capital type object by a guild in accordance with an embodiment of the invention; 12 Figure 20 illustrates a flow chart of the steps for accreditation of a human capital type object by a guild in accordance with an embodiment of the invention; Figure 21 illustrates a flow chart of the steps for creating an object property record file for a human capital type object in accordance with an embodiment of the invention; Figure 22 illustrates a flow chart of the steps for using an existing object property record file for a human capital type object to create a new object property record file in accordance with an embodiment of the invention; Figure 23 illustrates a flow chart of the steps for creating an object property record file for a service type object in accordance with an embodiment of the invention; and Figure 24 illustrates a flow chart of the steps for re-using an object property recon.

file of a service type object to create a new object property record file in accordance witil, an embodiment of the invention.

Referring now to Figure 1, there is illustrated a schematic representation of network of computer systems comprising a server computer system 10 and clier computer systems 11. The present invention may be implemented wholly on the serv, computer system 10, the client computer systems I I operating merely as "duml terminals for the server computer system 10, thereby forming a "thin" client systen Optionally, the present invention may be implemented partially on server compute system 10, and partially on a client computer system 11. The exact apportioning of th, present invention between the server computer system 10 and a client computer system I I would depend upon a number of factors, for example data band width available across the network, the cost of communication across the network and other technical or commercial considerations, and a skilled person would apportion the present invention between respective server and client computer systems accordingly. As shown in Figure 1, both the server computer system 10 and the client computer system I I comprise similar components, for example a system unit 12, a display device 18 with a display screen 20, and user input devices, including a keyboard 22 and a mouse 24. A printer 21 is also connected to the system. Each system unit 12 comprises media drives, including an optical disk drive 14, a floppy disk drive 16 and an internal hard disk drive not explicitly shown in Figure 1. A CD ROM 15 and a floppy disk 17 are also illustrated. Additionally, 13 server computer system 10 comprises high capacity storage media such as further magnetic hard disks 19 for example.

A program, comprising a sequence of computer implementable instructions and data, for implementing the invention may be supplied on media such as one or more CD ROMs and/or floppy disk, and installed on a hard disk, for example. The computer systems shown in Figure I are also connected 26 to a network 2, which in the illustrated embodiment is the internet, but may be a local or wide area dedicated or private network for example. A program for implementing the present invention could also be supplied on a telecommunications medium, for example over a telecommunications line via a network and/or the internet. For a client computer system I I operating as a mobile terminal over a radio telephone network, the telecommunications medium may be a radio frequency carrier wave carrying suitably encoded signals representing the computer program and data. For an implementation in which the invention is partially implemented on the server computer system 10, and partially implemented on a client computer system 11, parts of a program representing a part of the invention and/or suitably encoded signals representative of data formatted for use in the invention may also be supplied over a telecommunications medium.

-0 Referring now to Figure 2, there is shown schematic and simplified representation of an exemplary implementation of a computer system such as that referred to with reference to Figure 1. As shown in Figure 2, a processor (CPU) 30 is coupled to a bus structure 38. Also connected to the bus structure 38 are read only memory 32 and random access memory 34. A display adapter 36 connects a display device 18 to the bus structure 38. One or more user input device adapters 40 connect the user- input devices, including the keyboard 22 and the mouse 24, to the bus structure 38. An adapter 41 for the connection of the printer 21 may also be provided. One or more media drive adapters 42 can be provided for connecting the media drives, for example the optical disk drive 14, the floppy disk drive 16 and the hard disk drive 19, to the bus structure 38. One or more telecommunications adapters 44 can be provided for connecting the computersystem to 14 one or more networks. The communications adapters 44 could include a local area network adapter, a modem, and/or ISDN terminal adapter, etc., as required.

It will be appreciated that Figures I and 2 are schematic representations of one possible implementation of a computer system, suitable for either a server computer system 10 or a client server computer system 11. It will be appreciated, fron-i- the following description of embodiment of the invention, that a computer system in which the invention could be implemented may take many forms. For example, rather than the server computer system 10 comprising a display device 18 and printer 21, it may be merely necessary for the server computer system 10 to comprise a processing unit, and b, accessible by client computer systems 11. Optionally, the invention may be implemente, via more than one computer 10, or may be accessible to client computer systems I I via chain of one or more server computer systems 10. Furthermore, the client computer ma be a non-PC type of computer which is internet or network compatible.

Before describing the implementation of the present invention on a computt - system, for example such as one described with reference to Figure 1, in detail, a exemplary embodiment of the invention will be described at a conceptual level wit reference to Figure 3 of the drawings.

One embodiment in accordance with an aspect of the invention comprises a trading exchange operating within a virtual environment, for example a computer system or computer system network. The trading exchange is similar to conventional exchanges in that only members of the exchange can conduct business within the exchange, and members have to agree to rules etc. governing their behaviour on the exchange. However, there are many differences between a conventional exchange and a trading exchange in accordance with the invention. Exchange members can be individuals, business organisations or professional bodies. The professional bodies, for example, may set themselves up on the exchange as "guilds", and offer branding of objects to provide a level of credibility to the object. Within the virtual trading exchange, assets 70 may be traded. Each asset 70 may be conceptualised as comprising asset contents 74 and a wrapper 72, which may be viewed as an envelope for the asset contents 74 and displaying information about them as illustrated in Figure 3(b). In one implementation in accordance with the invention, the asset 70 is represented by an object comprising electronic signals, suitably digital signals, and preferably a computer-implemented object. The object is capable of being manipulated by a suitably programmed computer system 10, 11, and is structured or formatted in accordance with a computer program having instructions for defining the object. In the description of the implementation of an exemplary embodiment of the invention the asset 70 is represented as an object, thus the term object will be used hereafter when describing an implementation in preference to the term asset, and the reference 70 will be used to denote an object representing an asset 70. The properties of the object correspond to the information displayed about the contents, and may be conveniently embodied as a property record file. Thus, the term "object property record file" will be used instead of wrapper and will be denoted by reference 72.

In one embodiment the object 70 is associated with contents 74 such as information, an answer to a question or software. The type of information or product 74 associated with or represented by the object 70 deten-nines the object type. A description and details 76 of the object is provided on the object property record file 72. Additionally, the object 70 may merely comprise a object property record file 72 describing a service, such as a consultancy service, and having no contents.

The object property record file 72 may also include other information or properties of the object 70 The properties may include a price 78 for the asset represented by the object, share ownership 80 in the object, a guild brand 82 and further accreditations 84 from other guilds.

The object types may be categorised into three types as follows.

Firstly, there are Intellectual Capital type objects which typically have a digital content associated with the object property record file. Intellectual Capital is based upon the capabilities of individuals, whether independently or in groups such as in a business 16 organisation that can be captured in digital form and has commercial value. Software such as computer programs, audio and video are included within this definition.

Many organizations do not effectively leverage their corporate memory.

Therefore, there is typically a latency gap between actual and potential value generated by the organisation. Additionally, many experienced people do not realise the full value-of their own intellectual capital. There are many capable people that potentially have the same intellectual capabilities and knowledge as well-known business "gurus" for example, but lack the packaging and distribution channels by which they can disseminate their knowledge and skills, and receive payment.

Intellectual Capital objects include the following Object types:

I. I-Objects which basically consist of an object property record file that enables an exchange member to be notified of contextual information (digital content) that is potentially relevant to their needs and issues. For example, the digital content may contain contextual information such as rules relating to the application of a sales tax for goods brought for export. This enables third party information providers to repackage information or other products related to a Taxonomy Management System (a set of definitions for object types) and sell it through the new distribution channel of the exchange. These type of third parties need to be exchange members such as guilds and /or affinity businesses. Exchange members can also provide I-Objects; 2. K-Objects which basically consist of an object property record file that displays a question and knowledgeable answers (digital content) that is potentially relevant to the needs and issues of exchange members. The question may be "How may wives did Henry VIII have, and what were their names?", and the knowledgeable answer, presumably the correct answer, is contained in the contents. The knowledge object must always be based on a question instead of a title as used for other types of objects; 17 3. S-Objects basically consist of an object property record file that displays a description of a software program (digital content), such as a program, an applet (short piece of program code to perform a specific ftinction when loaded and run on a computer), audio such as music and even video, that is potentially relevant to the needs and issues of exchange members. This enables third party software providers to package software programs for sale through the new distribution channel of the exchange. These type of providers need to be members, guilds and /or affinity businesses. Exchange members can also provide S-Objects; 4. P-Object (practice or business) is an object which is aimed at practices which are tools to enable people to work smarter and faster. These tools can include check lists, templates, questionnaires, forms, instructions etc.

Secondly, there are Human Capital type objects which reflect a person's intellect in terms of tacit knowledge, competency, logical reasoning and emotive intelligence, for example.

There are a number of object types which encapsulate different types of human capital. The objects representing these types of objects do not have digital content as the object property record file contains the portfolio associated with the designated individual. The object property record file may point to a database which contains the portfolio of the person. The following are examples of types of human capital objects:

1. MEM-Object reflects that an individual's competency can be treated as an object and therefore it can increase or decrease in value. It comprises a persons general portfolio as a competency capability and may be a replacement for a CV. The rapid rate of change in knowledge and working environments naturally devalues a competency object if it is not updated. The dynamics of the employment market for example would force a competency gap that will rapidly deteriorate without continual corrective action. For example, intelligent and able people can now find themselves marginalized from the employment mainstream if they lose sight or are unaware that their competency is an object whose 18 value is always a variable. The MEM-Object is an object that is represented by the object property record file and the digital content of the member's portfolio. The object property record file represents the membership from a guild perspective. This object basically enables members to be notified of other members that have potentially common ground 5 that is relevant to their needs and issues; 2. CONS-Object represents the customized CV for a virtual consultant, and would typically include a price for a private consultation, and the Guild brand associated with the consultant; 3. MENT-Object is an object which is a customized CV for a mentor, and would typically include a price for a private consultation, and the Guild brand associated with the mentor; 4. EXP-Object is an object which represents members that have commercially valued knowledge and expertise which means they can be packaged as experts (such as gurus, famous people, leading practitioners) within a particular domain of knowledge. Although there is a huge number of persons expert in their respective fields embedded within many organizations, their knowledge and skills have not been realised because there has been a lack of packaging (the individual), a lack of incentive (revenue), and a lack of opportunity (as traditional approaches can only accommodate limited numbers such as business book authors, for example).

Additionally, people may have expertise that is not necessarily highly valued locally, but could be of high demand on a global basis. Finding the best people regardless of their current position (such as whether they are hidden within the depths of a large organization or they have set-up their own small business) associated with a knowledge domain provides the opportunity to attract many experts from throughout the World and allow them to exploit their abilities. Members can be assigned Expert status by a guild.

However, this does not mean the status can be used within other Guilds as this is dependent upon the subject matter and the judgment of the guild management.

I - 19 Thirdly, there are Service type objects. These are types of objects representing assets which do not necessarily have content and are related to services such as for:

1. Affinity Businesses, which could have digital content for example the organization's brochure; 2. Communities of Interest (COT), which are facilities within a Guild operating as a debating forum that attracts any exchange members that have a direct or indirect interest in the subject matter being debated.

In the present example there are no proprietary rights over the content generated from discussions within the COT. However, the Guild Management may be given, under the exchange rules, the rights to capture the content and commoditise it for selling within the exchange. A knowledge acquirer can receive details of Communities of Interest when receiving responses to their needs and issues. The discussion capabilities initially will be based upon threaded discussions. Members of a COT may set-up a Community Of Practice (COP) if approval is obtained from their Guild Management. Alternatively, they may set-up their own Guild orjoin another Guild in order to achieve using the COP facility. Preferably, there is a limit to the number of COIs the Guild Management Team can create as part of the standard franchise. However, franchise extensions can be sought or the Guild Management can replace the least effective COT within their remit; and 3. Guilds, which may be likened to a virtual business that is community centric. The guild is based upon members and their needs. The members will have their own digital passports such as digital certificates that are extended to support the membership of the Guild. The guild can also address needs and issues of its members and members elsewhere in the exchange. The guild has its own management team that need keep within the framework of the exchange charter.

There are many types of guilds, for example:

1. Membership to the exchange may be represented by a guild; 2. External Organizations aimed at best practices within a knowledge domain. This can cover existing organizations such as Institutes or new organizations that believe there is a gap in the market; 3. Private guilds that are an internal representation of part or all of an organization. Thus, a small business that has its people spread across locations may want to improve their performance. Alternatively, a large corporate entity may have multiple guilds to represent the internal needs, this is likened to intranets. In essence, this type of guild is an enabler for capturing corporate memory, 4. Private guilds that are a combination of internal and external representation of part or all of two or more organizations. Thus, a supply chain can be regarded as a guild that has a major customer that is reliant on many suppliers, that in turn are dependent upon other suppliers. The total set of connected organizations potentially can perform at higher standards and lower costs if part of a well managed guild. This can be likened to extranets. Other applicable considerations are Buying clubs that involve two or more organizations Co-sourcing and sourcing deals Government and local authority initiatives that involve multiple organizations External organizations that are made up multiple organizations such as the United Nations Geographical regions both at an intra and inter level Links between organizations that have common interests such as achieved by SWIFT Links with intermediaries and agents o Large projects Trouble shooting and complex problem resolution Major strategic initiatives that involve two or more organizations such as those associated with an environmental problem 5. A guild can be represented as an organization that uses the exchange as a new distribution and support channel for its products and services. This becomes relevant in the following situations 21 The organization's products and services are reliant upon imparting knowledge and contextual information.

Exploring new market opportunities, including from a national, international and global perspective.

Reducing sales cycle time especially when it is reliant upon the target customers having a base line of understanding before they can understand the value of the offering.

Reducing production cycle times and lower production costs. Thus, a book publisher can achieve these aims by treating each potential chapter as an object.

6. New business start-ups formed as a guild provides a potential quick and low cost start especially when involving Intellectual Capital and / or needs global reach.

7. A taxonomy management guild that covers the language of object definition.

8. Business schools, universities and other types of learning establishments.

In the present example, a guild is the object manager of all objects that are managed under the guild brand. This enables the guild to achieve recursive revenues because it will have object shares for each object sold. Additionally, the guild can achieve recursive revenues for objects it has endorsed that are owned by other parties. When the guild is a Object Manager it is responsible for determining the strategy and tactics for pricing of its objects. This includes auction and a range of pricing instruments.

Within the guild there are two community centric instruments that generate value added benefits 9 Community of Interest for testing new opportunities 9 Communities of Practice for delivering new knowledge based objects The guild management team can assign different roles to its members. This includes support for the notion of 1. Virtual Consultancy 2. Virtual Mentoring 22 3. Virtual Expert The guild also provides the enablers for supporting human behaviour such as 1. Decision Making 2. Discussions 3. Collaboration 4. Negotiations 5. Consensus (voting) 6. Feedback 7. Virtual Working (ANY3) 8. Virtual Team (Global Village concept) The guild will have its own electronic account (wallet) that enables it to make purchases and receive payments for objects sold.

A guild can also be treated as an object and therefore it will have its own shares.

Other capabilities that the guild can provide are 1. Adverts 20 2. Infornediary Agents 3. Agent for Virtual Conferences 4. Taxonomy Management related to their guild A guild can have reciprocal arrangements with other guilds that includes cross- fertilization between objects, that can be reinforced by object share swaps.

Finally, the guild can have its own version of a Knowledge Balanced Scorecard for its management information needs.

4. Virtual Conference fees or booking may be another type of object. Typically, the 30 object comprises a object property record file, but could have digital content say for the 23 conference programme. The virtual conference model is likened to a real conference with the only difference is that it is a rietworked service.

Suitably, guilds are the place to support the virtual conference. Members, in particular guilds, can hire the facility that includes, in the present example, 1. a maximum number of seats 2. live presentation facilities 3. white board and other real time notation tools 4. audio conferencing 5. multiple screen displays It can be used for a multiple purposes such as 1. presentations 2. virtual consultancy 3. virtual mentoring This is a fee based service whereby it is at the discretion to the conference organizers to determine the seat charge that needs to typically cover all the expenses.

The object property record file is used to set the seat fee and the instructions for pro-rata split of the payment amongst the conference organizers and any of the paid presenters. The conference facility supports synchronized electronic collaboration.

5. Virtual Exhibitions may also be objects in which exhibitors may book virtual space to display their products or services.

Assets represented by other types of objects may be traded, for example a seat reservation service for a theatre, or airline, or any other suitable product or services.

Providing the asset, or the asset details may be represented as an object within a computer 24 system then the only limit on what can be traded is the imagination of users of the trading system.

In the present example, in order to trade within the trading exchange one must be a member of the exchange. As is the case with conventional trading exchanges such as the London Stock Exchange, members are bound by rules, ethics and a code of conduct governing their behaviour within the exchange.

Additionally, members should provide bank account details, credit card details or set up a deposit account, for example, to the exchange in order that they have funds with which to trade on the exchange, or any fees earned by trading in assets represented by objects owned by them can be paid into their bank account. In a preferred embodiment in accordance with the invention, only members may create and place objects representing assets for trading in the trading exchange. Each object has an object manager who determines the properties of the object by setting various details on the object property record file 72. Typically, the member creating the object is the object manager, although this is not always the case. Typical properties characterising the object may be the price for access to the object contents associated with the object and corresponding to the asset, or the general availability of the object, that is to say limited access per time period, for example only one access per day or per week etc, for example. Additionally, an object manager can finalise a draft of the contents associated with an object or details of an object and change its status from draft to tradeable and place it on the trading floor of the exchange. Additionally, the object manager can withdraw the object, including associated contents, from the exchange, either to update it, or to withdraw it entirely. Typically, the trading exchange managers would set a minimum price at which the asset represented by the object has to be traded, but the price may be changed at any time by the object manager providing it does not go below the minimum threshold price.

A member who wishes to access an asset represented by a particular object will be required to pay a royalty as determined by the price 78 displayed on the object property record file 72. This royalty is then transferred from the purchasing member's account to the object owner's account. An object may be owned by more than one person, and shares 80 may be distributed throughout the ownership of that object. Preferably, only a limited number of shareholders may exist for each object, for example 10, to simplify the accounting processes within the exchange. Additionally, it is preferable that only whole numbers of shares are apportioned in order to simplify the accounting processes also. The trading exchange comprises an object transaction engine or module which calculates the royalty shares between the object owners dependent on their ownership in the object and transfers the appropriate percentage of the royalty from the purchasing members account to the various shareowner's accounts.

A particularly, useful feature of an embodiment in accordance with the present invention is the fact that object property record files 72 may be branded 82, hereby effectively branding the object, by a professional organisation or group, a so called guild, having a particular expertise in a particular knowledge, skill or product area, for example the British Computer Society. By applying a brand 82, the relevant guild provides the asset represented by the object with a level of credibility as to its contents. The brand 82 may be tiered and have different levels, for example a platinum, gold, silver or bronze level indicating the value or credibility that the branding organisation, guild, attributes to the asset. In a particular embodiment in accordance with the present invention, only guilds are permitted to provide human capital which can be offered on the exchange. Thus, the level or service or consultancy provided by the individual the subject of the human capital can be validated by the appropriate guild. However, this need not necessarily be the case. Additionally, the object property record file 72 may carry a number of accreditations 84, from other guilds, indicating a level of credibility according to the respective guild.

Preferably, if a guild is to brand an object, then that guild becomes the object manager and determines its various properties.

A trading exchange in accordance with the invention as described above provides a convenient forum in which individuals or organisations may place suitable objects 26 representing assets for purchase by other members. The virtual trading exchange does not require members to set up their own systems for trading, and therefore facilitates the provision of suitable assets such as information or software, or consultancy services, for example, conveniently represented as objects and at a competitive price. Additionally, it is very easy to update objects or their associated contents, or to withdraw out-of-date objects and contents and replace them with more up- to-date objects and contents. Furthermore, by providing suitably drafted descriptions, it is possible to allow an exchange member to quickly identify objects representing assets which are likely to be of interest to them. Thus, such an exchange solves the technical problems encountered with conventional virtual trading systems such as currently provided via the internet, and promotes and enhances the "knowledge society", facilitates "knowledge workers" and others in business, commerce, academic or private pursuits to access or sell information and other products.

Referring now to Figure 4, there is schematically illustrated an embodiment in accordance with the present invention implemented on a server computer system 10 coupled to the intemet 2. The trading exchange 100 comprises a number of functional modules or units suitably linked together either by hardware or software links within the server computer system. The embodiment illustrated in Figure 4 comprises both a "front office" function 102, and a "back office" function 104. Optionally, the "front office" and "back office" functions may be combined within an overall single functional unit.

The front office 102 comprises a Graphical User Interface (GUI) 106 configured to display various screens of information concerning trading or managing objects in the exchange. For example, when first accessing the exchange 100, a welcome screen is displayed providing information regarding the exchange 100, and how to become a member. If a user is already a member, they may enter a command or press a displayed button which, when activated, would display a further screen, which would typically provide options for viewing objects which are being traded on the exchange 100, or for creating an object for trading on the exchange 100. The GUI 106 is typically provided with a suitable user interface mechanism implemented by a program running on the 27 computer system 10, and which provides control buttons which, when activated by user, perform a particular function within the exchange. Data or information may be entered via the GUT 106 for communication to the exchange by activating a control button displayed by the GUT 106. The GUT may be solely based on the server computer system 10, in which case a client computer system I I acts merely as a dumb terminal for the server computer system and access to the GUT is directly over the network 2. Optionally, the program implementing the GUT may be wholly or partially communicated over the network 2 to a client computer system 11, to be stored at least temporarily on the client computer system thereby providing a GUT which would operate quickly on the client system. Activation of control buttons displayed on the GUT, or data information input via the GUT can then be communicated up over network 2 to the exchange 100 located on server system 10.

On the server side of the GUT there exists an interface system 108, which provides access to a database I 10 upon which are stored the objects, including their associated obJect property record files, information about which guilds are members of the exchange 100, as well as information about Communities Of Interest (COT) and Communities Of Practice (COP) which are associated with respective guilds. The interface mechanism 108 communicates with the database I 10 via a suitable communications link 112, which may be an internal connection within the computer system 10 to a hard disk, or may be via an extemal connection to another form of high capacity storage device.

The database 110 may be held on a hard disk 19 associated with the server computer system 10 as illustrated in Figure 1. The hard disk or other form of high storage capacity medium may be internal to the server computer system 10, or may be a separate unit, and the communications link 112 is adapted to be suitable for any suitable configuration. In the example illustrated in Figure 4, the database 110 stores objects 70 comprising property record computer files representing object property record files 72 and any associated content 74. Optionally, only the object property record files 72 are stored on the database 110 and the associated content 74 is stored on database 130 disposed in the "back office" 104. Theinterface mechanism 108 provides a suitable front end 28 application for database I 10, for example a proprietary application, for accessing items contained in the database I 10. Through the medium of the GUI 106, a member may instruct the interface mechanism 108 to find objects contained on database I 10, and to display them to the member. The database may be of any suitable form, and may be configured as an indexed database using any suitable index or indexes based on properties of the object for example brand, top level description, price, length of time on the exchange etc., or combinations of such properties. In the example illustrated in Figure 4, database I 10 contains only those object properties necessary for a member to view an object in order to determine whether or not they wish to purchase that object. Other information regarding guilds, COls and COPs would also be contained in the database 110. It should be noted that when a member wishes to view what objects are available on the exchange all that is provided to the member are the relevant property records representing object property record file details, which is typically the price of the object and any branding or accreditation information. A description of the asset represented by the object is often also provided. Share information need not be provided to a member since it is irrelevant to a member as to whom any payment will be made for the member's acquisition of the asset. Other properties or information may be made available to members for viewing and review, depending on the particular implementation of embodiments of the invention.

Should a member decide to acquire an asset represented by an object, then appropriate instructions are input via the GUI 106 to the interface mechanism 108, which responds by initiating an appropriate request to the back-office 104. In the example illustrated in Figure 4, a proprietary program implemented queuing system known as MQ series (MQS) produced by IBM is used for handling requests between the "front-office" 102 and the "back-office" 104. Other suitable message systems or configurations may be utilised.

In the preferred embodiment as illustrated in Figure 4, the exchange is split into "front-office" 102 and "back-office" 104 functions in order to provide an efficient architecture. Information which typically needs to be browsed, such as object property 29 records (object property record files) and information about guilds etc., is kept on the "front-office" 102 database 110. Whilst information involved in the processing of transactions, management of objects including the creation and withdrawal of objects is handled in the "back-office" 104, and the relevant information stored on database 130.

The MQS provides secure asynchronous communications links with respective "back-office" 104 functions. These ftinctions comprise program modules which when activated in response to an appropriate request process information residing on the database 130 in order to conduct transactions, or manage objects for example. The MQS provides a link to the different program functions. The link may comprise a physical link, or may be a logical link configured within the program instructions comprising the exchange.

The MQS can provide fast access for individual requests to the backoffice 104, as well as being easily scaleable. Optionally, a conventional link between the front-office 102 and back-office 104 may be provided. Each link in the MQS is dedicated to a particular type of request. If certain types of requests are likely of occur more often than other types, then more links will be provided for the more likely request types. All that the transmitting part of the MQS 114 does is to place a polling signal and any associated data on a link corresponding to the request type received via the user interface mechanism 108, which is forwarded to the receiving part of the MQS 118. Each link has a request processing function 120 associated with it at the receiving MQS part 118. The request processing function 120 receives the signal across its associated link, and any data, and initiates a response to that request by the database manager 122.

The database manager 122 comprises a number of processing engines, for example an object transaction engine 124, and an object management engine 126. For a transaction request initiated over the MQS, the relevant information sent over the serial link is input to the transaction engine 124, such as the identity of the object representing the asset which is wished to be acquired, and the identity of the member wishing to make the purchase. The transaction engine then accesses the relevant information about that object, and member in database 130, over communications link 128. The transaction engine 124 processes the relevant information and performs appropriate functions such as debiting the members account, and crediting the respective shareholders accounts, and sends a signal back to the front-office 102 that the member may have access to the object contents corresponding to the asset, Similarly, if the request type is one which wishes to perform a management function, such as changing the price of an asset represented by an object, then the database manager 122 initiates the management engine 126 which performs the appropriate functions on the information stored on database 130. With regard to object management functions, should any property of the object be changed, then the details of the object such as its property records file kept on the databases 110, 13 0 are updated.

Further details of the operation and implementation of the various functions of the trading exchange 100 illustrated in Figure 4, will be provided later.

An exemplary embodiment of an object property record file representing an object property record file in accordance with the present invention will now be described with reference to the schematic illustration of Figure 5.

In the present example the object property record is a computer file, which acts as a form of header for the object contents or comprises a pointer or address to the storage location for the object contents. Access to the object contents are not permitted until a payment has been made or agreed.

The format of an example of an object property record computer file for a knowledge object (K-object) is shown in Figure 5. It should be noted that the illustration in Figure 5 is a schematic illustration only, and the properties of the object as detailed on the record file need not be displayed or provided to a member in this format. Any suitable presentation providing a member with a clear indication or view of the necessary parts of the property record file would be suitable for embodiments of the present invention. The object record file has a name "WRAP" 148 which serves to identify the object. The first 31 property shown on the record file is the object manager 150. The object manager is the person or guild who is responsible for the object record file, and defining the character of the object by virtue of the properties ascribed to it in the property record file. The object manager has the right to change the properties in the property record file including the object price for the asset represented by the object and to withdraw an object from the exchange trading floor. An object manager may have shares in the object, but this is not mandatory. If the object manager is a guild, their responsibilities would also include determining any request for accreditation with other guilds for their endorsement. The object manager is also responsible for the bartering and selling of shares including the setting of share prices in the object. In accordance with a preferred embodiment of the invention, the object manager status cannot be changed once the status of the object has been finalised. However, if the object status is draft, or has been set to draft and temporarily removed from the trading floor, then the object manager function can be transferred to a guild or to another individual, for example.

The object type 152 is also indicated in the property record file and may be either intellectual capital or human capital, and be one or other of the object types described above, for example. The property record file also includes an object code 154 which is a collection of pre-defined "fields" on the property record file which prompts a member providing the object to the exchange to provide one or more of the following information or data relating to the asset represented by the object:

Question or Title; Secondary Question or Sub-title; Author (s); Keywords; a Summary; Location within Topics; Terms and Conditions for purchasing the asset; Language of the asset; National & International Reference Numbers; Content Structure;

Target Audience; Benefits and Objectives; Pre-requisite Competence; Date object Created; Life Expectancy (of the object); Version Description; Duration; Media Type; Quality Standards, etc.

The object property record file also includes an object brochure 156 which is a facility for providing artwork, advertising, affinities, accreditation and links to other objects in order to enhance the attractiveness and commercial exploitation of the objects.

32 Another use for the brochure is to provide a description of the contents of the object, a question the answer to which forms the object contents, a contract, terms and conditions etc.

An object route map 158 is also included in the property record file, and is designed to allow a network of related objects to be created by the object manager. Thus relationships between different objects may be built up, thereby enhancing the utility of the object to would be acquirers.

The object price instruction 160 is also included in the property record file, and in a preferred embodiment is only one price. The price is set in digital tokens, which are fixed to a suitable currency such as US dollars. The object price instruction 160 can be controlled by a trading instrument basic pricing that can be changed at any time by the object manager. There are a number of different trading instruments for the selling of assets and also object shares. They include:

Basic pricing that can be changed at anytime by the object manager; Dynamic pricing that automatically fluctuates the price according to patterns of supply and demand. The degree of sensitivity can be directed by three settings, namely high, medium or low; Scarcity pricing by limiting the number of purchases such as for a virtual conference. This can also be combined with an auction mechanism to stimulate creating higher prices; Scheduled pricing whereby the price is set according to the time period. Thus, the price could be set for a given period, then it is automatically set at a price for the next scheduled period and then the sequence is repeated, as deemed appropriate; Auction pricing based on different techniques for placing the bids; and Restricting bids to selective members based upon a pre-set criteria.

These trading instruments can be used for objects that are already available on the exchange or for objects which are to be placed on the exchange in the future. This includes ftiture conferences or future potential earnings when selling shares in an object.

33 Associated with the object price instruction is the object price history 162, which is a full, or time limited, history of object price changes and may be utilised either by the object manager or by an automated trading instrument to influence future object pricing.

The object share ownership 164 and share ownership history 166 is also indicated in the property record file. It is a feature of a preferred embodiment of the invention that more than one member can own shares in an object, and the current share ownership is displayed as item 164. Additionally, the share ownership history is also displayed as item 166.

An important item in the property record file is the trading status 168. It has the following states in terms of the functional capability of the object, i.e. what can be done with the object:

Draft, i.e. not on the trading floor of the exchange; Trading, i.e. on the trading floor of the exchange; Archive, i.e. on the trading floor, but the content is stored in a low priority storage device since few accesses to it are expected due to its age; Suspension, i.e. not on the trading floor; and Withdrawal, i.e. not on the trading floor.

As mentioned above, a object property record file may include an accreditation 170, and the object property record file representing the object property record file includes an accreditation item. The notion of accreditation enables an electronic "badging" of anything that has an associated property record file. This includes all types of objects such as: Communities of Interest; Communities of Practice; Guilds; Virtual Conferences; Virtual Consultancy; Virtual Mentoring, for example.

There are two types of accreditation, branding and endorsement. Within each type of accreditation there are associated levels such as Platinum, Gold, Silver and Bronze, for example.

34 An absence of accreditation may result in the object "sinking" to the equivalent of a junk market.

The accreditation principle enables the free market to determine quality and value as opposed to the traditional model of using command and control techniques for qualitymanagement.

In the present example illustrated in Figure 5, the last object property record field is for object feedback 172, which is typically based upon quantifiable data such as rating values and qualitative data such as commentary text. The quantifiable feedback may be fed into a Knowledge Balanced Scorecard that provides a management information framework for a business model representing the object Certain properties of the object property record may be updated at any time, by the object manager, and the object re-launched onto the trading floor of the exchange. Typical properties of the object that may be updated are schematically illustrated in Figure 6. As can be seen from Figure 6, typically the object codification 154 may be updated, which is particularly useful should a previously used code either become deftirict, or be split into more than one knowledge area. Additionally, the object brochure 156 may also be updated, to reflect changes in the object manager's brand image for example. Additionally, the object route mapping may be modified by the object manager, in order to enhance the value of the object by providing suitable links and relationships to related objects. Optionally, object route mapping modification may be done automatically, by a suitable control function which identifies related objects. However, such an automated furiction may not be attractive to an object manager, since they would wish to ensure that any related object pointed to in their object route map were of an appropriate quality. The object pricing instruction 160 may also be modified, and the object share ownership 164. The object trading status 168 may also be modified, in order to reflect the appropriate status of the object. In addition, the object accreditation 170 may also be modified during the life of the object on the exchange 100.

The operation of an object management engine 126 in accordance with an embodiment of the invention for the creation of an object representing an intellectual capital object will now be described with reference to the flow chart in Figure 7 of the drawings. In the present example, the object management engine is located on the server computer system 10, and may be utilised as an object "tool-kit" online via the intemet, for example. Optionally, program instructions for configuring a client computer system I I as an object management engine may be communicated from the server computer system I I to the client computer system 11. Thus, objects may be created "off- line", and communicated back to the trading exchange 100 once they are completed. Before the object management engine facility can be used potential object providers need to become members of the trading exchange and adhere to the rules, regulations and ethics which govern conduct on the exchange as part of the membership contract. Therefore, a potential provider/member will need to have passed an authentication check before they can proceed with the provision of an object to the trading exchange 100. Subsequent references in the following to member or provider is also a reference to guilds if they are the object provider.

Figure 7 summarises the processes and steps involved in an object provider controlling and instructing the object management engine to create an object. The first step of providing an object involves the construction of an object property record file, and the object management engine 126 is initialised, step 200, to provide a template record file, for example having the object property details described above with reference to Figure 5. Optionally, if the provider has previously created objects, then a copy of an earlier property record file may be made, and initialised for a new record file. A part of the initialisation process is the setting of the object trading status 168 of the property record file to "draft". Next, an object manager 150 is assigned to the record file at step 202 by the provider, which may be an individual member or a guild, and the object is assigned a name "WRAP" 148. Next, step 204, the provider instructs the object management engine 126 to set an object type 152 (K, I, P or S for intellectual capital object).

36 Next, the management engine prompts the provider, at step 206, as to whether or not object codes 154 have been assigned to the object property record file. Mandatory codes have to be completed, and the management engine repeats step 206 and 208 until all the mandatory codes have been completed and until the provider indicates that no further optional codes, if any, are to be completed. If the mandatory codes and- any further desired codes are completed, then the result of the decision at step 206 is YES, and the process control flow for the management engine proceeds to step 210, where the provider is prompted to assign or enter a brochure 156 for the object if they wish. Next, step 212 the provider is prompted with the option to complete the object route map 158 for the object, and at step 214 the provider is prompted to enter the object price instruction 160.

At step 216, the management engine prompts the provider as to whether there are any more share owners 164 in the object. If YES, then process control flows to step 218 where the provider is prompted to enter the other share owners and their respective shares, and if NO then the control flows to step 220 where the provider assigns themselves as the sole object share owner. The provider is then prompted at step 222 to attach the object contents to the object property record file. The object creation process then terminates at step 224 where the provider sets the object trading status 168 to "trading" and the object is then released to the trading floor. Optionally, validation checks may be performed by the management engine to ensure that all the mandatory parts of the object property record file have been completed, and the trading status automatically set to "trading" if the checks are satisfied.

With reference to Figure 4, the management engine 126 may create the object separately from the database 130 or 110, or within them. In the present example, the object including its object property record file and contents are stored on database 110 in the front-office 102 and comprises that information which prospective purchasers would wish to see, once the status has been set to "trading". Other information in the object property record file relating to, back-office 104 functions is stored on database 130.

37 The first time a provider sets-up an object they also need to set up an electronic wallet for use in the exchange. Initially, they only need to set-up an electronic deposit account into which revenue derived from the object or future objects can be deposited. In a preferred embodiment of the invention, one of the validation checks performed at step 224 by the management engine 126 before the object trading status can be changed from "draft" to "trading" is to ensure that an electronic deposit account is available. If not, the member is prompted by the management engine to provide the banking details of an account which is to receive any revenue ftom the sale of the object. Once sufficient funds have been deposited in that account and a funds transfer instruction has been received from the member, the funds can be transferred to the members bank account. In a preferred embodiment, the electronic deposit account is merely a computer file corresponding to the members bank account details into which revenue in the form of exchange digital tokens are placed. The computer file may include a calculating engine which sums the revenue input to it to provide a total of the funds in the electronic deposit account.

If a member has a previous object property record file then that can be reused to form a template for a new property record file. The record file is retrieved or copied from the relevant database or databases 110/130 and acts as a base-line for creating a new object. The control process for the management engine 126 when using a previous property record file is similar to that described above with reference to Figure 7, and is illustrated in Figure 8 by way of a flow chart. The difference between creating an object property record file from start and using an existing record file is that the initialisation step 200 of Figure 7 is not required, and instead retrieval of the object takes place and the object re-named, step 230 of Figure 8. Next, step 232, the object type represented by the object is re-stated and then at step 206 the management engine 126 determines whether or not all the mandatory codes have been completed. If NO, the process control flows to step 234 where the object codes are re-stated or initialised. If YES, then process control flows to steps 236, 238, 240 where the object brochure, object route map and object price instruction are re-stated respectively.

38 At step 216, the provider is asked if there are any other share owners of the object. If answered YES, then the provider is prompted to input the share owners and respective shares at step 218, otherwise the share ownership is re-stated to be the provider at step 5 242. The contents of the object are then attached to the object property record file at step 222, and the process terminated at step 224.

Again, before the object trading status can be changed from "draft" to "trading" there is a validation check to ensure the mandatory parts of the property record file have been completed. Preferably, the mandatory parts of the record file are kept to a minimum set. Once the validation checks have been passed at step 224, the member may release the object to the trading floor. This automatically leads to the object trading status being set to "trading" which now means the object is available for purchase. Optionally, once the validation checks are satisfied the management engine may automatically set the trading status to "trading".

The control process for creating an object representing a human capital asset, or a services asset is very similar to the control processes described with the aid of the flowcharts illustrated in Figures 7 and 8. However, objects representing human capital or services assets do not comprise any contents, and therefore step 222 of the flowcharts illustrated in Figures 7 and 8 is not implemented. The different types of human capital and services objects are described above.

The object brochure 156 in the object property record file for a human capital or services type object may act as the description of the services, guild or business, or event or other entity which the object represents. For example, in the case of an object representing a consultancy asset, the object brochure 156 created at step 210 or 236 in the flowcharts illustrated in Figure 7 and Figure 8, respectively, may comprise a curriculum vitae for the individual whose consultancy services are being offered on the exchange. In another example, an object may represent a services object offering attendance at a virtual conference, for example. The object brochure 156 may then comprise, and even be 39 presented on a suitable display medium such as a computer display screen, in the form of a typical brochure or "flyer" as produced for conventional advertising for conferences and the like.

Additionally, the brochure may also contain terms and conditions for hiring the consultancy services, or purchasing a ticket for a virtual conference, for example, and define any contractual arrangements between the provider of the object to the exchange, and the acquirer. In this respect, it may be possible to determine the law governing the agreement between the provider and the acquirer.

Common to all object property record files, is an object codification item 154.

The opportunity to enter object codification terms into the object property record file exists for objects regardless of the nature of the asset which they represent. At step 206 of the flowcharts illustrated in Figures 7 and 8, a sequence of program instr-uctions may be executed which automatically scans the content associated with the object for any words which match a database of codification "key" words or the trading exchange. The database of codification key words may be kept on database I 10 or 130, however since the creation of an object and its associated property record file may be considered to be a back-office function, then the codification key word database would reside on database 130. Any words in the content matching a word in the keyword database can automatically be included in the object codification field 156 of the proper-ty record file.

Optionally, an object provider may obtain suitable entries for the object codification field

154 from a knowledge classification tree. An example of branching through such a knowledge classification tree will now be described with reference to Figure 9.

The knowledge classification tree represents a classification repository forinatted and adapted to match contextual supply and demand for different areas of knowledge.

The knowledge classification tree need not be restricted to pure knowledge, but may be applied to other suitable things such as services, for example. In the example illustrated in Figure 9, the knowledge classification tree comprises, at its topmost level, a number of knowledge provinces 250 including commerce, finance, health, human resources, IT, legal, sales and marketing, etc. At a lower level in the knowledge classification tree, there are provided a number of knowledge domains 252 and below that there comprises knowledge sectors 254, and within the knowledge sectors are different categories which may be termed hot questions 256, for example. The knowledge classification tree is structured within a suitable database such that each higher level points to a lower level having a number of items within it. Thus, in the example illustrated in Figure 9, an object provider utilising the knowledge classification tree may choose human resources as their knowledge province for entry in the object codification field 154. By choosing human resources, the knowledge classification tree execution unit provides to the object provider, a list of knowledge domains falling within the knowledge province human resources, from which the object provider may choose. If the object provider chooses human capital 260, then a further level within the knowledge classification tree is opened up comprising a plurality of knowledge sectors. By selecting a particular knowledge sector, in the illustrated example "HC" (human capital) for the individual 262, the object provider is presented with a list of hot questions 256 relating to a individual's human capital. In a suitable embodiment in accordance with the invention, each of the knowledge provinces 250,knowledge domains 252, knowledge sectors 254 and hot questions 256 may be respectively displayed on a suitable display device, such as a computer display screen, in order that an object provider may make a suitable choice from the classifications presented to them. In this manner, it is possible to provide a logical, ordered, structured and formatted object codification, in which an object provider is automatically directed to a limited set of suitable codifications depending upon a choice of code at an earlier, broader, concept level. Such a knowledge classification tree, and program instructions for executing a selection of subsequent levels of data within the knowledge classification tree, provides for a codification structure allowing for efficient searching for objects within the exchange. This, advantageously, reduces the processing power necessary for implementing the exchange as well as reducing the time a member has to remain on-line or active within the exchange whilst searching particular types of object.

An important feature of the training exchange 100 is the ability to conduct transactions in assets represented by objects placed on the trading floor of the exchange.

41 Exchange members may acquire object contents in order to view the information contained therein, find the answer contained to a question within the object brochure field 156 of the associated object property record file, arrange the use of the consultancy services of an individual represented by an object, and purchase tickets for and attend virtual conferences represented by objects on the trading exchange. However, a potential acquirer would wish to view the properties of the objects placed on the trading floor of the exchange in order to determine which objects they may wish to purchase, and they would wish that such review or searching to be done at modest cost, even for free. Additionally, potential members of the exchange may also be potentially acquirers. That is to say, first time customers or users of the exchange should be able to view the objects on the trading floor, and utilise any search facility available within the trading exchange. However, potential acquirers which are not yet members will have to become members of the exchange if they wish to purchase any objects traded on the exchange, and set up appropriate bank or credit card accounts in order to provide funds for their purchase.

In order to provide an efficient and effective review of the objects on the trading floor, the trading exchange 100 includes a search engine, which may be utillsed by potential enquirers, including non-members. In general, the search engine operates as a form of filter, each element of the filter being selectable and corresponding to one of the fields in the object property record file. The search engine is implemented as a computer program having computer-implementable instructions which, in a preferred embodiment, are executed within database 110, that is to say the front-office 102 database of the exchange 100. Optionally, the search engine may be located on database 130 in the backoffice, but this would require access through the front- office to the back-office and would not necessarily be the most efficient architecture, though dependent on the location of the object contents corresponding to the assets.

An example of an embodiment of the search engine will now be described with reference to Figure 10, which illustrates the steps performed by the search engine in accordance with executed program code, for example. Operation of the search engine 300 starts at step 302 in which a potential acquirer inputs the object type or types which they 42 are interested in reviewing, next the search engine proceeds to step 304 in which the potential acquirer is prompted to enter any object codes defining the object types they wish to review. At step 306, the user is prompted to enter appropriate data for searching an object brochure field 156, and then the process flows to step 308 where the potential acquirer may define whether or not an object is to have a link or not have a link. Next, at step 310, an object price filter may be set up, based on the pricing instruction field -160. Such a filter may set a maximum price for an object, or set only certain types of object price instruction to be accepted, for example those having a fixed price and not subject to an auction price instruction. In the illustrated example, the search engine process then proceeds to step 312 in which a potential enquirer can enter the object trading status, of which, in the preferred embodiment, only two are relevant. That is to say, status of "trading" or "archive". For example, a potential acquirer may wish to use just the "trading" status in order to get relatively up-to-date objects. At the next step, 314, a potential acquirer may input the identity of any guilds, for the objects they wish to review, and any endorsement or branding levels that they wish to review. Next, the process flows to step 316 in which a search engine may be set to only identify objects comprising an element of feedback. The process terminates at step 318. Having been suitable programmed, the search engine 300 then searches through the databases in order to identify relevant objects in accordance with its configuration.

A search engine 300, which is described with reference to Figure 10, is merely one way for a potential acquirer to search the objects on the exchange trading floor. Further options for searching may include a keyword search in which a potential acquirer may enter a word or string of words into a search argument corresponding to a field in the object property record file, and use straightforward boolean logic to obtain matches with that keyword or string of words.

Optionally, the search engine 300 may be personalised such that a potential acquirer may save the search profile in order to reuse it. Preferably, the search profile will be saved in an appropriate search file which may be stored within the exchange on the appropriate database 110 or interface application 108. Such saved search files should be 43 capable of retrieval, renaming and modification in order to optimise and improve a potential acquirer's search profile. Additionally, a potential acquirer should be able to navigate through a knowledge classification tree as illustrated in Figure 9, and conduct a search from any of the tree nodes or string of nodes, that is to say the respective knowledge provinces, knowledge domains, knowledge sectors or hot questions, for example as illustrated in Figure 9. Optionally, the search engine would provide, the opportunity to navigate through an object route map as defined by the object route map field 158 of the object property record file.

Other methods of reviewing and identifying objects on the trading floor of the exchange may be by means of an editorial service provided by the operator of the trading exchange. Additionally, guilds may operate an editorial service and objects may be directly retrieved from such a service. Other methods may include an object "top ten" comprising a list of the top ten selling objects. The top ten list may be limited to certain domains, for example a certain knowledge domain or even knowledge sector as illustrated in Figure 9.

An additional feature is an alert which is provided by an agent for a member which sends an alert to the member when an object of interest comes to the agent's attention. The agent may be set up in a similar fashion to the search engine 300 illustrated in Figure 10. In the present example, it may be assumed that the agent is set up in a similar fashion as the search engine 300. Thus, the agent comprises a set of filters. The agent may act in a similar fashion to a web crawler, and search through the relevant databases at quiet periods for the trading exchange 100. In this way, relevant objects may be identified for individual members, at times when the exchange is less busy than other times, thereby reducing the trading exchange processing overhead. The agent may be set up to send alerts to members as and when it identifies relevant objects, or may be set up to send alerts on a daily or weekly basis, for example.

A potential acquirer may view object property record file fields which have been identified to them as being of interest by the search engine 300. In particular, members 44 may view the object price history 162. Additionally, the object property record file may include a further field, not illustrated in Figure 5 or Figure 6, comprising a list of the members who have previously purchased the object. Additionally, the potential acquirer may view the object feedback field 172.

- The acquisition of right to view an object content is performed by an object transaction engine 124, which is implemented by computer program instructions executed in database 130 of the back-office 104 of the trading exchange 100. Referring now to the flowchart illustrated in Figure 11, a potential acquirer places a request to purchase or view the contents of an object on the trading exchange via the GUI 106, at step 340. An appropriate request is sent via the MQS transmission module 114 over the serial connection 116 to the MQS reception module 118. The relevant request is processed in module 120 and the transaction engine 124 initiated to perform the transaction in accordance with the request. As mentioned above, the request signal not only includes a polling signal on the request line, but also includes relevant data, such as the identity of the object which it is wished to purchase, and the identity of the potential acquirer.

Once the transaction engine 124 is initiated, and the request to acquire at step 340 set up, the flow chart proceeds to step 342 where a copy of the object whose contents are to be acquired is made within a working space of the database 130, for example. Next, step 344, the transaction engine checks whether or not the potential acquirer has already purchased the identified object. If the answer to this is yes, then the process control flows to step 346 where program code is executed to determine whether or not access to the object by the potential acquirer is still permitted. If the answer is yes, then the transaction engine 124 process control flows to step 348 where a program code is executed to prompt the potential enquirer to indicate whether or not they still wish to purchase the object. If the answer to step 348 is "no", then process control flows to step 358. For example, a potential acquirer may wish to make further purchase of the object contents in order to obtain a further licence for its use, for example if the contents are a computer program.

Turning now to step 344, if the check performed by the transaction engine 124 indicates that the object has not already been purchased, then process control flows to 352 where a program module is executed to implement the actual purchase of the object, as described with reference to Figure 12. Process flow returns from the object purchase program module to step 354 in which the transaction engine confirms whether or not a royalty has been paid. The transaction engine 124 then proceeds to step 356 where any contents associated with the acquired object are made available to the acquirer, typically by downloading the contents over a suitable network, such as the internet, to the acquirer's client computer system. Optionally, if the acquired object represents a human capital or services asset, then details are forwarded to the acquirer in order to allow them to make access to the individual or service. Next, step 358, the transaction engine deletes the copy of the object that it has made in order to perform the transaction, or optionally does not save it, and the process flows to step 360, where it is terminated. Optionally, the copy of the object may be saved or archived, together with transaction details, step 358 to provide a transaction audit trail.

An advantage of the object representing the potential acquired asset being copied at step 342, is that during the transaction process, the properties of that object are "frozen". For example, the price cannot change. Whilst a particular transaction is being conducted by the transaction engine 124 in respect of a particular object, that object is still available on the trading floor of the exchange 100. Further, its properties may still be modified by the relevant object manager. Thus, during a particular transaction in respect of that object, the properties of the object may be modified and a further transaction initiated by taking a copy of the modified object. In this way, a multiple access/multiple user system, including multiple access and multiple use to and of a single object is provided.

After a certain time period, the knowledge exchange 100 requests feedback from the acquirer on the asset represented by the object that they have purchased. The provision of feedback is not mandatory, and a reminder as to the code of conduct to be adhered to by members would also accompany the request for feedback.

46 The transaction engine 124 payment process referred to in step 352 of Figure I I will now be described with reference to flowchart illustrated in Figure 12. The payment process for the transaction engine 124 starts at step 380 where it is established by the transaction engine 124 that the member has provided either bank account details or details of a credit card account. If no such details are available, then the transaction engine 124 prompts the user to provide such details, and set up suitable accounts. If a suitable account needs to be set up, then process control drops out of the flowchart illustrated in Figure 12, and enters an appropriate program controlled module to perform the function of setting up appropriate bank account details or credit card account details. In a preferred embodiment of the invention, transactions are performed using digital tokens, which are tied to a suitable currency such as US dollars.

At step 382, the transaction engine determines whether there are sufficient tokens in a potential acquirer's credit card account, referred to as "E-WALLET-CRED" in Figure 12. If there are sufficient tokens, then process control flows to step 384 where the value corresponding to the object price instruction is deducted from the credit card account and, the transaction process terminated at step 386 where process control flow returns to the flowchart illustrated in Figure I I and to step 354. If the result of the investigation at step 382 is "no", then the process control flows to step 388 where it is determined whether or not there are sufficient tokens in an electronic bank account, referred to as "E-WALLETDEPOS" in Figure 12. If the result of step 388 is "yes", then the value corresponding to the object price instruction is deducted from the bank account at step 390 and process control flows to 386 where it is terminated. If the result of step 388 is "no", then at step 392, it is determined whether or not there are sufficient tokens for the purchase if the tokens in both the bank account and the credit card account are added together. If the result at step 392 is "yes", then at step 394, the value corresponding to the object price instruction is deducted from the bank account and credit card account and the process proceeds to step 386 where it is terminated. However, if the result of step 392 is "no", then process control flows to step 396 where the member is requested to provide credit card details or confirm the use of a previously-used credit card in order to provide enough tokens in their credit card account to purchase the object. It should be noted that the 47 setting up of a credit card account necessary if step 380 determines that there is no such account, may be performed by step 396.

Returning now to the main process flow control illustrated in Figure 12, a member replies to the request for credit card details at step 396 by providing such details and stating the number of digital tokens that they wish to be purchased for their credit-zard account within the trading exchange 100. Once step 398 has been completed, process contro I flow returns to step 3 82.

In the present example, as far as the object acquirer is concerned the acquisition of an object takes place entirely within the flow control processes as illustrated in Figures I I and 12. However, there are further transaction processes which occur, of which the acquirer is not, nor need not be, aware. Such a process may be termed "income disbursement". Once the purchase control process illustrated in Figure 12 has been terminated at step 386, then contemporaneously with the remainder of the process control flow illustrated in Figure 11, or subsequent thereto, the transaction engine may be configured to disperse income from the purchase of the asset represented by the object between one or more share owners of the object. The process control for dispersing the income will now be described with reference to the flowchart illustrated in Figure 13.

At step 402, the purchase value in digital tokens is input to the income disbursement process and any tax deducted from the gross purchase amount. Next, at step 404, the exchange tariff is deducted for that purchase, which provides the operators of the exchange with an income. Next, at step 406, the object property record file share ownership field 164 is inspected to determine how many share owners there are in the object. The net purchase value, that is to say the value after tax and tariff have been deducted, is then distributed between the current object share owners on a pro-rated basis. The pro-rated amounts are then paid directly into the share owners deposit accounts at step 408.

At this point, it would be useful to describe the process by which share owners 48 may have digital tokens in their deposit accounts transferred to their actual bank accounts.

Such a process is undertaken by a suitable management engine typically residing in the back-office 104 of the exchange. Such a management engine may be a sub- function module of the database manager 122, the transaction engine 124 or management engine 126, depending upon the architecture of a particular implementation of the trading exchange 100. A share owner, who is also a member, makes a request for transfer of value represented by digital tokens in their deposit account to their actual bank account by way of the GUT 106 and interface mechanism 128 to the MQS transmitter 144. An appropriate request is polled on serial communication lines 116 and the MQS 118 receiver sends the request to the appropriate request processing module 120. At step 422, the request is processed and a value corresponding to the number of additional tokens, is transferred to the relevant bank account in step 424.

Each object 70 is capable of having its properties modified by the appropriate object manager. Modification of object properties is one of the functions performed by the object management engine 126. An example of the operation of an object management engine 126 in accordance with an embodiment of the invention will now be described with reference to the flowchart illustrated in Figure 15.

The object management engine 126 is implemented by program instruction code typically executed in the back-office 104 of the trading exchange 100, and generally within database 130. However, this need not necessarily be the case, in particular if the front-office and back-office functions were to be combined into a single functional module including a single database on which the objects will be stored. Referring now to Figure 15, at step 450, the object management engine 126 selects an object in response to an object manager's request input via the GUI 106. The object manager's control input to the GUI 106 generates an appropriate polling signal on a relevant MQS 114 serial connection 116 to the receive part of the MQS 118. The appropriate request is processed, including any data identifying the object manager and the selected object. Next, step 452, the object management engine makes a copy of the selected object in a working space on the relevant database, for instance database 130. Next, step 454, the object management 49 engine then may prompt the object manager to select one of the fields in the object property record file which they wish to modify, by setting an appropriate request and sending it from MQS 118 over the appropriate serial communication line 116 to MQS 114 for display or presentation to the user via the GUI 106. Optionally, the object management engine 126 may be configured to receive requests which include the object property record file fields to be modified, including the appropriate modification. In such an instance, the object management engine 126 would automatically select the field indicated by the object manager at step 454. Next, at step 456, the object management engine modifies the selected field in accordance with the object manager's control input instructions. This is the case, regardless of whether the object manager sends instructions regarding all the selected fields and modifications to, or is individually prompted for, their selected field and modification at step 454.

At step 458, the object management engine determines whether or not further fields are to be modified. In the case of individual control input instructions being received from the object manager during the process, an appropriate request is sent by MQS 118 across the appropriate serial connection line 116 to MQS 114 and thence to the GUI 106 for presentation to the object manager. If the response from the object manager is a request for modifying more fields, or there are further fields within the original request from the object manager which require modification, then the result of the decision at 458 is "yes" and process control flow returns to step 454. Otherwise, if the result at step 454 is "no" and the process control flows to step 460 the object management engine is configured to replace the selected object with the modified copy of the selected object. Thus, the modified copy of the selected object becomes the current object on the trading exchange 100. The process then terminates at step 462.

An example of an object property which may be modified by an object manager is the object pricing instruction, field 160 in the object property record file. The object management engine 126 is operated in accordance with the flowchart illustrated in Figure

15, in order to allow the object manager to modify the price. Once the modified copy of the selected object, with the modified pricing instruction, replaces the selected object at step 460, the modification process is complete. The new pricing instruction takes effect immediately step 460 has been completed.

An option for a particular implementation of the trading exchange 100 is the provision of a "shopping cart" into which a potential acquirer may place objects representing assets which they are interested in purchasing. Such a process would be-part of the object transaction engine 124. Once the object has been placed in the "shopping cart" then its price, and other properties, are fixed. In terms of the object transaction engine 124 process control, placing an object into a "shopping cart" is achieved by the object transaction engine 124 copying the selected object at step 342 into a working space of an appropriate database. If, whilst an object is in a potential acquirer's "shopping cart", the relevant object manager modifies a property of the relevant object, in particular the price, the properties of the object in the "shopping cart" do not change. However, if the potential acquirer should halt the transaction process, then their "shopping cart" is emptied, and if they should go back at a later time to view the objects, they will find that the object properties, particularly the price, may have changed. Preferably, the trading exchange also sets a time limit for keeping objects in a "shopping cart" to avoid abuse and misuse.

The object management engine 126, may be operated automatically, in order to modify certain properties, for example the object price history 162. Such automatic modification may take place in step 456 since as soon as the object price is modified, which will take place in step 456, then the object price history may be updated.

A particularly useful feature of the trading exchange 100 is the fact that one of the object properties is the object pricing instruction 160. This field can be set to a number of different pricing instructions in order to determine the price at which an asset is traded.

Referring now to Figures I I and 12, a further functional module may be inserted in the flowchart illustrated to set the price of an asset, depending upon the object price instruction 160. This additional program module is shown in dotted outline and labelled reference 370 in Figures I I and 12.

51 Referring now to Figure 17, the functioning of the price setting program module 370 in accordance with an embodiment of the invention will now be described. Initially, at step 372, the object pricing instruction field 160 of the relevant object is interrogated.

Depending upon which pricing instruction is included which, in the present example includes a fixed pricing instruction 374, a scarcity pricing instruction 376, a scheduled pricing instruction 378, a dynamic pricing instruction 390 and an auction pricing instruction 392, the object transaction engine 124 initiates a program sub-routine module according to respective object pricing instruction.

For a fixed pricing instruction 374, the program control flow proceeds to step 394 where the set fixed price is established for the current transaction. Operation of the object management engine 124 will then return to respective flowcharts illustrated in Figures I I and 12.

- If the object pricing instruction is set to scarcity, 376, then the program subroutine executes a module which determines the price of the asset represented by the object in accordance with some form of restriction. For example, it may be the case that only a certain number of copies can be sold for any given time period. The object price may be fixed for all copies, or may be varied depending upon which portion of the time period the object is purchased. For example, for a scarcity object pricing instruction 376, the object management engine 124 is configured to establish the time period at step 396, and to deten-nine how many copies of the asset (object contents) have been sold at step 398. At step 400, the current object price is then set in accordance with the scarcity rules set up by the object manager.

A variation of the scarcity object pricing instruction is the scheduled object pricing instruction 378, in which a pre-determined number of asset copies is made available during given time periods at a fixed price. For example, for the first hour that an object representing and asset is available on the trading exchange 100, only one copy of the asset (object contents) is available, for the next three hours, two copies are available, and for 52 the following twenty hours, eight copies are available. Subsequent time periods with subsequent numbers of copies may be included or after a fixed time period as many copies as necessary may be provided. To implement a scarcity object pricing instruction 378, the object transaction engine 124 first of all checks the current time period at step 402 and then checks how many copies have been stored at step 404. Depending upon the rules set up by the object manager for the scheduled object pricing instruction, a set fixed price is established or purchase of an object is inhibited at step 406.

If the object pricing instruction is a dynamic pricing instruction 390, then the object transaction engine 124 is configured at step 408 to set a price according to a dynamic pricing algorithm. In general, dynamic pricing algorithms are known, and depend upon various factors, such as the volatility of the current market place, the activity within the market place, etc.

Finally, in the present example, the auction pricing instruction 392 may be set. For the auction pricing instruction 392, the object transaction engine 124

is configured at step 410 to apply a set of bidding rules for access to the particular object. Such bidding rules will determine how potential acquirers place their bids. For example, a certain period of time may be set in which potential acquirers may place bids made in a "sealed bid" manner, such that when the time period expires the person placing the highest bid gains access to the asset represented by the object.

As previously mentioned above, each object has one or more share owners.

Royalties from sales of the object are shared out between share owners on a pro-rata basis.

A feature of a preferred embodiment of the invention is that shares in objects may be traded on the exchange 100. The share price may be indicated as a separate field in the object property record file, or as a part of the object share ownership field 164.

Preferably, the share price is valued in the same digital tokens as the object price which simplifies transactions in the shares as they can utilise the same accounting 53 processes as transactions in objects. The share owner, or a nominated share owner if more than one owner, sets the price. Usually, the object manager is the person or entity that has access to set the price. However, as a derogation from the principle that only object managers can change properties, a share owner not an object manager may be nominated to set the share price. It is implicit that if an object property record file indicates a share price, that shares are available for sale. However, it may be that not all the shares held in the object are for sale, but merely a subset. The object manager, or nominated share owner, will also have rights to set how many shares are for sale.

Members can trade shares on the exchange, and the object transaction engine may be programmed in order to conduct share transactions on members' behalf The share transaction process is illustrated in the flowcharts of Figures I I and 12. The share transaction process for a suitably configured object transaction engine 124 will now be described with reference to the flowchart illustrated in Figure 17. At step 500, a member initiates a request to purchase shares. The request may come via the GUI 106 and through to the MQS 114 of the front-office. The appropriate serial communication line 116 is polled, along with any necessary data identifying the object whose shares wish to be purchased, and the number of shares. The MQS 118 in the back-office receives the appropriate request and processes it to initiate a share purchase process at step 502, which may be illustrated with reference to the flowchart in Figure 12 with appropriate modification.

Referring now to Figure 12, the transaction engine performs the same processes when conducting the purchase of shares, as it does when a member purchases an object.

* The only difference when purchasing shares is that the reference to "object-price" in Figure 12 should be replaced with a reference to "share-price".

As with an object transaction, a member may place shares which he intends to purchase into a "shopping cart" and the share price will be fixed for the period that the shares are in the "shopping cart". However, the exchange 100 sets a time limit for which shares may be placed in a "shopping cart" in order to avoid a situation where a member 54 places shares in their "shopping cart" and monitors the share price via another system, in order to purchase the shares when they know that the share price has increased. Such benefit by using the "shopping cart" as a price shelter would not be permitted.

Within the exchange 100, shares may also be bartered, that is exchanged, for other shares or in return for some other service such as guild branding or endorsement. Shares may also be swapped.

On completion of a share transaction, the flowchart illustrated in Figure 12 returns to the flowchart illustrated in Figure 17 and proceeds to step 504. At step 504, the object transaction engine 124 can instruct the object manager to modify the share ownership, to reflect the change. Preferably, the object transaction engine 124 can instruct the object management engine 126 to automatically modify the share ownership field 160 in order to reflect the change in share ownership. Additionally, at step 504, the object share transaction history will also be automatically be updated, or directly updated by the object manager.

The share price may be in the form of a share price instruction analogous to the object price instruction described above with reference to Figure 16. In a similar fashion, the share price may be set by a similar selection of share price instruction program control module 370 as illustrated in Figure 16. However, when setting a share price, in a scheduling mode 278, it is groups of shares that can be released from time-to-time. When in the scarcity mode 376, groups of shares may also be released instead of numbers of copies of an object.

Guilds may also be share owners, which allows for them to provide, and operate, as a virtual business unit.

In another aspect of the invention, as mentioned above, the trading exchange 100 provides for a guild to accredit an object by branding or endorsing it. Preferably, the knowledge exchange permits only guilds to brand or endorse an object since they generally represent professional organisations and will have sufficient credibility to add value to the object. However, the exchange rules may be relaxed to allow other members of the exchange to endorse objects. In the preferred embodiment, there is one badge space within the object for an accreditation brand, and up to four spaces for accreditation endorsements. The accreditations, branding and endorsement, are entered into the object accreditation field 170 of the object property record file.

The branding or endorsement process comprises two different parts. The first part is a negotiation between the object manager and the guild when they wish to brand the object. The second part is the functioning of the object manager and engine to modify the object accreditation field 170 to reflect agreed brandings or endorsements. An example of the branding of an object in accordance with an embodiment of the present invention will now be described with reference to the flowchart illustrated in Figure 18.

Initially, step 520, the object manager opens negotiations with the guild who may wish to brand the object. The negotiations should be entered into with a guild manager for the guild who has the authority to transact on behalf of the guild. The negotiations may be electronic negotiations carried out within the trading exchange 100 by any suitable e-mail process that may be configured or set up within it. For example, many proprietary database applications or management applications include e- mail features. Optionally, the negotiations may be conducted by more conventional means such as faceto-face, by telephone, letter or fax. Once the guild manager has agreed to at least investigate the possibility of branding the object, the process proceeds to step 522 where the guild manager reviews the asset represented by the object to determine its worth or value, and whether it is something that the guild would wish to brand. Next, step 524, the guild determines whether or not it is interested to brand the object. If the result at step 524 is "no", then the accreditation process stops at step 526. However, if the answer is "yes", then the branding process proceeds to step 534 where the guild manager indicates which branding level they are prepared to attach to the object, and the number of shares in the object that the guild requires in return for the branding. It should be noted that branding may be time-limited, for example a year or even a few months, and the object 56 branding process being described may also relate to a re-branding or re- stating of a brand. Of course, as time progresses re-branding may result in branding at a lower level of accreditation, i.e. a reduction from platinum to gold.

As step 536, the object manager either agrees to the guild manager's level of branding and the object shares required, in which case process control flows to step 538, or disagrees, in which case the process flows to step 534, where the guild has to reconsider whether or not it is still interested in branding the object in light of the object manager's response at step 536, Optionally, a guild manager may require some form of payment which could be in the form of digital tokens, for branding the object. However, the transfer of some shares in the object is a suitable "bartering" process within the trading exchange 100. At step 538, the object management engine 126 is initiated and configured to handle updating of the object property record file to reflect the change in the object properties brought about by the branding. In this respect, the object manager status and a percentage of the object share ownership are passed to the guild manager. This may be evidenced by an electronic form or some other form of contract. The object management engine 126 operating in accordance with the flowchart illustrated in Figure updates the object manager field 150 and share ownership field 150 and share ownership field history field 166 to reflect the relevant changes. Optionally, the object may have to be withdrawn from the trading floor and reset by configuring the object management engine 126 to operate in accordance with the flowchart illustrated in Figure 8. That is to say, the object is withdrawn from the trading exchange floor and the relevant fields such as the object manager field 150, set to be the guild manager. The particular implementation of this process will be determined by the architecture of the particular embodiment of the trading exchange in accordance with their particular requirements and any limitations that may exist due to the technology used, for example.

At step 540 and step 532, the guild manager updates the object property record file field 164 with the guild's accreditation brand. This modification process can take place in accordance with the modification process illustrated in Figure 15. The control process then flows to step 530 where it is considered whether or not any endorsement by other 57 guilds is required, and if no, the process terminates at step 526. However, if the guild manager decides that they would like to have accreditation endorsements from other guilds, then process control flows to step 528, where accreditation endorsement may take place in accordance with the flowchart illustrated in Figure 19.

- The process for accreditation endorsement will now be described, with reference to the flowchart illustrated in Figure 19. At step 550, the guild manager (A) of an object to which the guild has applied an accreditation brand opens negotiations with another guild manager (B) of a guild whom they would wish to endorse the object. As before, these negotiations may take many forms and be conducted by different types of media. At step 552, guild manager (B) reviews the asset represented by the object, and if shows interest at step 554, states or re-states the accreditation endorsement level and the number of shares in the object that they would require for such endorsement at step 556. If guild manager (A) does not agree to the offer made by guild manager (B) at step 558, then the process returns to step 554 where the guild manager (B) considers whether or not they are still interested in an accreditation endorsement of the object. If the guild is not interested at step 554, then the process terminates at step 560. However, the guild manager (A) agrees at step 558 to the terms offered by the guild manager (B) at step 556, then the control flows to step 560. At step 560, the guild manager (A) initiates the object management engine 126 to perform a modification in accordance with the flowchart illustrated in Figure 15 to change the share ownership 164, and to add the guild B endorsement to the object accreditation field 170, Optionally, guild manager (A) may be able to provide access to the object property record via field 170 in order for object manager (B) to enter their accreditation endorsement. However the implementation of the actual accreditation endorsement process, the trading exchange 100 within its rules, codes of conduct, etc, will prohibit the fraudulent accreditation by branding or endorsement of any object.

Optionally, a member may enter negotiations with a guild manager to obtain guild 30 accreditation endorsement. The process for a member obtaining such guild accreditation endorsement is the same as that illustrated with respect to Figure 19 for a guild requesting 58 such guild accreditation endorsement. With reference to Figure 19, for a member requesting guild endorsement, the references in the flowchart of Figure 19 to guild manager (A), may be replaced by the member object manager. In such a scenario, it is the member who retains the object manager status, since it is accreditation endorsement which is being sought, not accreditation branding. A member of a guild may request or be offered to act on behalf of the guild as a paid adviser. As discussed above, such an adviser may be considered to comprise a human capital type object, and be capable of offering consultancy, mentoring or expert services under the auspices of the guild.

Effectively, the human capital object, as represented by an object within the trading exchange, is branded by the guild. The process for accreditation branding an individual who is a guild member, and whose services are offered via the trading exchange 100 will now be described with reference to the flowchart illustrated in Figure 20. At step 580 of the flowchart illustrated in Figure 20, a guild manager, or the guild member opens negotiations with each other. Negotiations will be based upon the opportunity for the guild member's services to be branded by the guild. At step 582, the guild manager states the type of advisory role that the guild member is to offer. This goes to the heart of the fact that it is the guild which controls the human capital that is offered by the trading exchange under their branding. At step 584, the member determines whether or not they are interested in the advisory role as stated by the guild manager. If not, they the process proceeds to step 592 where it is terminated. However, if the answer at step 584 is "yes", then the process continues to step 586 where the guild manager will provide details regarding the contractual relationship between the guild member, in particular the distribution of share ownership in the object representing a guild member's services.

If the guild member does not agree, at step 588, to the proposals put forward by the guild manager at step 586 then the process control flows to step 548 where the member determines whether or not they are still interested and if not, the process terminates at step 592. If the member is still interested, they go back to the guild manager to step 586 to either continue negotiations regarding the contract or to reconsider the proposal.

59 If the guild member agrees at step 588, to the guild manager's proposals, then the process proceeds to step 590. At step 590, it is necessary to first create the object representing the human capital of the guild member since, hitherto, there has been no such object. The object type is one of guild member, consultant, mentor or expert at step 204, and the distribution of share ownerships at step 216 to 220, and 242 (for re-use of an object) is determined by negotiation between the guild manager and the guild member.

Once the object representing the guild member services has been created, the process flow terminates at step 592.

Referring now to Figure 21, the process steps for a suitably configured or programmed object management engine 126 suitably configured or programmed to create an object representing a human capital asset. At step 600, the object management engine 126 is initialised to provide a template object property record file, for example having the object property details described with reference to Figure 5 above. A part of the initialisation process is the setting of the object trading status 168 to draft, and assigning the object manager to be the guild manager. Additionally, a name is assigned to the object. Next, step 602, the management engine 126 receives instructions to set the object type 152 to either a consultancy, expert or mentor object type.

Process control now proceeds to decision block 604, at which point the management engine 126 determines whether the mandatory fields of the object codes 154 have been completed. If the answer is "no", then process control flows to step 606 where the guild manager acting as the object provider is prompted to complete the mandatory object code entries. If the result at step 604 is "yes", then process control may flow to step 608. However, decision block 604 may also configure the object management engine 126 to prompt the object provider to indicate if they have completed the optional object codes and if the answer is "yes" then proceed to step 608. At step 608, the object provider is given the option to prepare an object brochure and at step 610, the option to enter an object route map. At step 612, an object price instruction is entered, and then the process control flows to step 614 in which object share owners are assigned. The process then continues to step 616, where it is terminated.

Optionally, if the object provider has previously created human capital type objects, then a copy of an earlier property record file for such objects may be made, and initialised for a new record file. Figure 22 illustrates a flowchart for such a process, in which, at step 630, the previously-created object is retrieved and the object property record file re-named with the name of the new object. At step 632, the object type is amended if necessary, and at step 634 it is deten-nined whether or not the mandatory object codes have been completed, and if not completing them and optional codes at step 636. As described with reference to Figure 21, it is also determined at step 634 whether the object provider has completed the optional object codes. Process control then flows to step 638 where the object brochure is amended, and then onto step 640 where the object route map is amended. At step 642, the object price instruction is amended and the object share ownership updated at step 644. The process then terminates at step 646.

A guild member's services may be accreditation endorsed by other guilds, in which the process is performed in accordance with the flowchart illustrated in Figure 19.

For objects representing service-based assets, the branding process may be nothing more than the guild manager using the object management engine 126 in accordance with the flowchart illustrated in Figure 15, to modify the object accreditation field 170 in the object property record file to show the relevant branding. Again, such objects may be accreditation endorsed by the guilds utilising the process illustrated in the flowchart of Figure 19.

The creation of a service-type object will now be described with reference to the flowchart illustrated in Figure 23. At step 650, a template for a service- type object is initialised by assigning the object manager, as the guild manager, a name, and setting the object trading status 168 to draft. Next, step 652, an object type is assigned which, in a particular embodiment, may be one of a guild, affinity business, conference, community of interest or community of practice, for example. At step 654, it is determined whether a mandatory and optional object code fields is to be completed, and if not process control

61 flows to step 656 and then back to 654. If the object code fields have been completed, process control flows to step 658 in which an object brochure may be created, and then to step 660 at which an object route map may be completed. At step 662, it is deten-nined whether the object type is either a community of interest or community of practice, and if the result is "yes", then the process proceeds to step 664 where it is terminated. If the result of step 662 is known, then process control flows to step 666 where the object price instruction is set up, and then to step 668 where any shares in the object are assigned.

Optionally, an existing service-type object may be utilised as a template, and appropriately amended. Such a process will now be described with reference to the flowchart illustrated in Figure 24. At step 680, the copy of the existing service-type object is amended if necessary to show a new guild manager, amended to have a new name, and amended to have the trading status set to draft. Next, at step 682, the object type is amended, and at step 684 it is determined whether the object codes have been completed, and if not process control flows to step 686, where object code entries may be made. At step 688, the object brochure is amended and at step 670, the object route map is amended. At step 672, it is detennined whether the object is a community of interest or a community of practice type, and if the result is "yes", process control flows to step 674, where it is terminated. If the result at step 672 is "no", then control flows to step 676 where an object price instruction is entered and then to step 678 where the share ownership is amended.

In accordance with a further aspect of the invention, objects may be withdrawn from the trading floor of the exchange. As described above, in the object property record file, there is a field reflecting the trading status, field 168, which may be modified to reflect the current trading status. If the object trading status field 168 is set to "suspend" and/or "withdraw" then the object is unavailable to users of the trading exchange and effectively removed from the trading exchange trading floor. If the trading status is set to "suspend" then the object will be unable to be purchased from the trading floor. The object manager is entitled to modify the trading status from "suspend" to "trading", "withdraw" or "archive" at any subsequent stage.

62 If the trading status is set to "withdraw" then it cannot be purchased from the exchange trading floor and the object is deleted from the exchange. Thus, the object manager cannot alter the trading status.

- If the trading status is set to "archive" then, although the object can stiH be purchased from the trading floor of the exchange, there is a delayed service level as the object content is stored in a low priority storage facility. The object manager may change the "archive" status to "trading", "suspend" or "withdraw" at any subsequent stage.

In general, it is only the object manager which may change the trading status of an object. However, the trading exchange 100, in accordance with its rules, ethics and code of conduct, may change the trading status of an object to "archive", "suspend" or "withdraw" at any time in accordance with the terms and conditions in the membership contract for individual member, guilds, etc. In a preferred embodiment, when the trading status is set to "archive", it is only the contents of the object which are stored in a low priority storage area, the object property record file is still maintained on the trading floor of the exchange for review by potential acquirers.

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. The scope of the present disclosure includes any novel feature or combination of features disclosed therein either explicitly or implicitly or any generalisation thereof irrespective of whether or not it relates to the claimed invention or mitigates any or all of the problems addressed by the present invention. The applicant hereby gives notice that new claims may be formulated to such features during the prosecution of this application or of any such further application derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

63

Claims

1 A computer- implemented trading exchange, the trading exchange comprising: one or more computer-implemented objects respectively representing one or more tradeable assets for trading in said trading exchange, each object optionally including a modifiable property; an object management engine configured to be responsive to a management control input to select a said object and to modify said property of said selected object; and an object transaction engine configured to be responsive to a transaction control input to select a said object and to conduct a transaction in respect of said selected object.

2. A trading exchange according to Claim 1, further configured to be responsive to said management control input to copy said selected object.

3. A trading exchange according to Claim 2, further configured to be responsive to said management control input to modify a property of said copied object thereby forming a modified copy of said selected object.

4. A trading exchange according to Claim 3, further configured to be responsive to said management control input to replace said selected object with said modified copy of said selected object.

5. A trading exchange according to Claim 4, further configured to be responsive to said management control input to archive said replaced object for providing a modification audit trail.

6. A trading exchange according to any preceding Claim, ftirther configured to be responsive to said management control input to modify more than one property of said object.

64

7. A trading exchange according to any preceding Claim, said management control input comprising an object select instruction and an object modify instruction.

8. A trading exchange according to any preceding Claim, further configured to be responsive to said transaction control input to copy said selected object.

9. A trading exchange according to Claim 8, said object associated with object content.

10. A trading exchange according to Claim 9, said object content stored separately from said object.

11. A trading exchange according to Claim 9 or Claim 10, said object content 15 comprising a computer file.

12 A trading exchange according to any one of Claims 9 to 11, further configured to be responsive to said transaction control input to copy said object content.

13. A trading exchange according to Claim 12, further configured to communicate said copy of said content to a user of said trading exchange.

14. A trading exchange according to Claim 13, wherein said user is responsible for said transaction control input.

15. A trading exchange according to any preceding Claim, further comprising an user interface mechanism configured to display a property of at least one selected object on a computer display medium.

16. A trading exchange according to Claim 15, said user interface mechanism further configured to receive a control input from an user and to communicate said control input to said object management and/or object transaction engine.

17. A trading exchange according to Claim 16, said user interface mechanism comprising a communications device for communicating said control input to said object management and/or object transaction engine.

18. A trading exchange according to Claim 16 or 17, said user interface mechanism further configured to display a button on said computer display mechanism actuable by a user to initiate a control input to said object management and/or object transaction engine.

19. A computer system for implementing a trading exchange, the computer system comprising:

a processor; a storage medium; an interface device; and a program implemented trading exchange, the trading exchange comprising; one or more computer-implementable objects respectively representing one or more tradeable assets for trading in the trading exchange, each object optionally including a modifiable property, an object management engine configured to be responsive to a management control input to select a said object and to modify a property of a selected said object, and an object transaction engine configured to be responsive to a transaction control input to select a said object and to conduct a transaction in respect of a selected said object.

20. A computer system according to Claim 19 further comprising:

a computer display medium; and 66 a user interface mechanism configured to display a property of at least one object on said computer display medium.

21. An object transaction engine for a computer-implementable trading exchange comprising one or more computer-implemented objects respectively representing one or more tradeable assets, each object optionally including a modifiable property, the transaction engine being configured to be responsive to a first control input to select a said object, and further configured to be responsive to a second control input to conduct a transaction in respect of said selected object in accordance with at least one property of said object.

22. An object transaction engine according to Claim 21, further configured to copy said selected object responsive to said first control input, and to conduct said transaction in accordance with at least one property of said copied object.

23. An object transaction engine according to Claim 21 or Claim 22, wherein said at least one property is representative of a purchase price for said asset represented by said selected object.

24. An object transaction engine according to any one of Claims 221 to 23, wherein said at least one property is a modifiable property.

25. An object management engine for a computer-implementable trading exchange comprising one or more computer-implemented objects respectively representing one or 25 more tradeable assets, each object including a modifiable property, the management engine being configured to be responsive to a first control input to select a said object, and further configured to update said selected object with a modified property responsive to a second control input.

67

26. An object management engine according to Claim 25, further configured to copy said selected object, and to modify a property of said copied object responsive to said second control input thereby forming a modified copy of said selected object,

27. An object management engine according to Claim 26, the object management engine further configured to replace said selected object with said modified copy of said selected object.

28. A computer system network for implementing a trading exchange, the computer system network comprising a server computer system linkable via a communications medium to a client computer system, the server computer system including:

a processor; a storage device; and an interface device suitable for communicating with said client computer system via the communications medium; the server computer system ftirther including a program implemented trading exchange comprising one or more computer- implemented objects respectively representing of one or more tradeable assets for trading in the trading exchange, each object optionally including a modifiable property; the trading exchange further comprising an object management engine configured to be responsive to a first control input to modify a property of a selected said object, and an object transaction engine configured to be responsive to a second control input to conduct a transaction in respect of a selected said object; the client computer system including:

a processor; a storage device and; an interface device suitable for communicating via the communications medium with said server computer system; the client computer system being configured to provide an user interface mechanism for receiving and communicating a control input to said transaction and/or 68 management engine to select a said object and to conduct a transaction and/or modify a property of said selected object.

29. A client computer system linkable via a communications medium to a server computer system including a computer-implemented trading exchange comprising one or more computer-implemented objects respectively representing one or more tradeable assets, each object optionally including a modifiable property, the client computer system comprising:

a processor; a storage device; a display medium for displaying a property of an object; an interface mechanism for communicating with the server computer system; and an object transaction and/or management engine which is program implemented by said processor; said object transaction engine configured to be responsive to a first transaction control input to select a said object in said trading exchange, and further configured to copy said selected object and to conduct a transaction in respect of the selected object in accordance with at least one property; and/or said object management engine being configured to be responsive to a first management control input to select and copy a said object, and to a second management control input modify a property of said copy; the object management engine further configured to replace said selected object with the modified copy of said selected object.

30. A computer program implemented object representative of an asset tradeable on a computer-implemented trading exchange, said object comprising: an object property record file including one or more records for storing one or more properties of said object; and associated with a content file for storing content associated with said asset represented by said object.

69

31. A computer program for a computer-implemented trading exchange comprising one or more computer-implemented objects respectively representing one or more tradeable assets, each object optionally including a modifiable property, the program comprising:

computer-implementable instructions for configuring a computer to be responsive to a first control input to modify a property of a said object; and computer-implementable instructions for configuring a computer to be responsive to a second control input to conduct a transaction in respect of a selected said object.

32. A computer program according to Claim 31, further comprising computer implementable instructions to select a said object for modification of a property thereof and/or conducting a transaction in respect thereof.

33. A computer program according to any one of Claims 30 to 32, further comprising computer-implementable instructions for defining a said object for said trading exchange, said instructions implementable to form an object including a modifiable property.

34. A computer program according to any one of Claims 30 to 33, further comprising computer-implementable instructions for configuring a user interface mechanism for displaying a property of a selected object on a computer display medium.

35. An electronic signal representative of an object representing an asset tradeable on a computer-implemented trading exchange, said signal comprising:

an electronic representation of a purchase price for the object; and an electronic representation of a description of content associated with said object.

36. An electronic signal according to Claim 35, further comprising an electronic representation of said content.

37. An electronic signal according to Claim 35 or Claim 36, wherein said electronic 5 signal is a digital signal.

38. An electronic signal accordng to any one of Claims 35 to 37, said signal being a light or radio signal.

39. A carrier medium comprising computer-implementable instructions for a computer program according to any one of Claims 30 to 34 or a signal according to any one of Claims 35 to 38.

40. A carrier medium according to Claim 39, comprising a computer readable 15 storage medium.

41. A carrier medium according to claim 40, wherein the computer readable storage medium comprises an optical disk or magnetic disk or tape.

42, A carrier medium according to Claim 39, comprising a telecommunications medium.

43. A carrier medium according to Claim 42, wherein said telecommunications medium comprises a radio frequency carrier signal, or an optical carrier signal, or a 25 broadcast signal or an internet protocol signal, or a voice telephony carrier signal.

44. An article of manufacture comprising a carrier medium according to any one of Claims 39 to 43.

45. A method for conducting transactions in an asset represented by a computerimplemented object optionally including a modifiable property, in a computer 71 implemented trading exchange, the method comprising; selecting said object from a plurality of objects in said exchange; making a copy of said object; and communicating object content associated with said object to a user of said exchange.

46. A method according to Claim 45, further comprising making a copy of an object content associated with said object, and communicating said copy to said user of said exchange.

47. A method for modifying a property of a computer-implemented object representing a tradeable asset, including a modifiable property, in a computerimplemented trading exchange, the method comprising:

48. A trading exchange substantially as hereinbefore described, and with reference to the drawings.

49. A computer system substantially as hereinbefore described, and with reference to the drawings.

50. An object transaction engine substantially as hereinbefore described, and with reference to the drawings.

51. An object management engine substantially as hereinbefore described, and with reference to the drawings.

52. A computer system network substantially as hereinbefore described, and with 72 reference to the drawings.

53. A client computer system substantially as hereinbefore described, and with reference to the drawings. 5

54. A computer implemented object substantially as hereinbefore described, and with reference to the drawings.

55. A computer program for a computer-implemented trading exchange substantially 10 as hereinbefore described, and with reference to the drawings.

56. An electronic signal substantially as hereinbefore described, and with reference to the drawings.

57. A carrier medium substantially as hereinbefore described, and with reference to the drawings.

58, A method for conducting transactions substantially as hereinbefore described, and with reference to the drawings. 20 59. A method for modifying objects substantially as hereinbefore described, and with reference to the drawings.