WO2008034163A1

WO2008034163A1 - Method and system for digital collectibles

Info

Publication number: WO2008034163A1
Application number: PCT/AU2007/000814
Authority: WO
Inventors: Danielle Louise Lehrer; Robert Jacob Karp
Original assignee: Danielle Louise Lehrer; Robert Jacob Karp
Priority date: 2006-09-21
Filing date: 2007-06-12
Publication date: 2008-03-27

Abstract

A method, and associated system and computer program product, of altering a condition of a digital collectible. The method includes retrieving the digital collectible in the condition, determining a circumstance, selecting a content modification module, and, applying the content modification module and the circumstance to the digital collectible in the condition. This produces a digital collectible in an altered condition. Generally, the altered condition is a deteriorated condition and different conditions are grouped into a plurality of levels. The condition is a measure of deviation of the digital collectible from the original form of the digital collectible. A digital collectible could be an image, audio, video, ringtone, game, song, etc. There is also provided the ability to modify a rarity value for a digital collectible. This allows a digital collectible, being digital material, to be traded or otherwise dealt with as a collectible and tradeable item.

Description

Method And System For Digital Collectibles

Technical Field

[001] The present invention relates to digital material or content that is collectible, and in particular, to the condition of digital collectibles and/or the rarity of digital collectibles.

Background Art

[002] "Digital material" as used herein refers to any digital or computerised data or information that may be stored and transferred between electronic devices or storage devices, such as any type of terminal as herein described.

[003] A "Digital Data Item" (DDI) as used herein is a single particular instance of digital material. A DDI is a uniquely identifiable item of digital material.

[004] A "Digital Collectible" (DC) as used herein is a DDI that can be considered as being, or as potentially being, collectible, tradeable or otherwise desirable to have, use or own.

[005] In a networked data communications system, users have access to terminals which are capable of requesting and receiving information from local or remote information sources. In such a system a terminal may be a type of processing system, computer or computerised device, a personal computer (PC), a mobile or cellular telephone, a mobile data terminal, a portable computer, a personal digital assistant (PDA), a pager, a thin client, a T.V., a set top box or any other similar type of electronic device. The capability of the terminal to request and/or receive information or data files, e.g. a DC or DDI, can be provided by an application program, hardware, firmware, etc.. A terminal may be provided with associated devices, for example a local storage device such as a hard disk drive or solid state drive or memory, a media card (for example CF or SD card), etc..

[006] An information source can be a server(s) or any other type of suitable terminal coupled to an information storage device. The exchange of information (i.e. the request and/or receipt of information or data, such as a DC or DDI) between the terminal and the information source, or other terminal(s), is facilitated by communication means. The communication means can be realised by physical cables, for example a metallic cable such as a telephone line, semi-conducting cables, electromagnetic signals, for example radio-frequency signals or infra-red signals, optical fibre cables, satellite links or any other such medium or combination thereof connected to a network infrastructure.

[007] The network infrastructure can include devices such as a telephone switch, a base station, a bridge, a router, or any other such specialised component, which facilitates the connection between the terminal and the information source. Collectively, an interconnected group of terminals, communication means, infrastructure and information sources is referred to as a network. The network itself may take a variety of forms. For example, it may be a computer network, telecommunications network, data communications network, Local Area Network (LAN), Wide Area Network (WAN), wireless network, Internetwork, Intranetwork, the Internet and developments thereof, transient or temporary networks, combinations of the above or any other type of network providing for communication between computerised, electronic or digital devices. A network as referenced in this specification should be taken to include any type of terminal or other similar type of electronic device, or part thereof, which is rendered such that it is capable of communicating with at least one other terminal.

[008] WO 2005/059758, also filed by the present applicants, discloses a method and system for downloading, tracking and/or monitoring digital material to prevent the proliferation of unauthorised copies and ensure that, if desired, revenues may be collected on a per-copy basis.

[009] It would be beneficial for digital material, such as images, audio, video, ringtones, games, songs, etc., to be able to be traded or otherwise dealt with as collectible items. Presently, DDIs are copied or transferred without any, or any substantial, degradation in their quality.

[010] It is known to use Digital Rights Management (DRM) systems, such as that disclosed in WO 2005/059758, to enhance the scarcity of digital material, as it is intended that the digital material cannot be completely freely copied or swapped. This approach is very limited and is presently the only known way of affecting the "collectibility" of digital material.

[011] Currently, there is no known means to provide a way of dealing with digital material that can be more completely treated as digital collectibles. Normally, in the real world, a collectible item, such as a photograph or artwork, degrades in condition over time. Also, a collectible item often becomes rarer over time if other similar collectible items are lost or destroyed. Presently, there is no known system for providing similar effects or considerations, for example condition or rarity, in digital material so that DDIs can be properly treated as digital collectibles.

[012] This identifies a need for a method, system and/or computer program product for providing, altering and/or dealing with aspects of digital collectibles.

[013] The reference in this specification to any prior publication (or information derived from the prior publication), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from the prior publication) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

Disclosure Of Invention

[014] In a broad form the present invention provides a method, system and/or computer program product for altering a condition of a digital collectible, such as an image, audio, video, ringtone, game, song, etc.

[015] In another broad form the present invention provides a method, system and/or computer program product for modifying a rarity value for a digital collectible.

[016] In a first aspect, there is provided a method of altering a condition of a digital collectible, including the steps of: determining a circumstance associated with the digital collectible; selecting at least one modifier based on the determined circumstance; and, applying the at least one modifier to the digital collectible in the condition to modify the digital collectible to be in an altered condition.

[017] In a second aspect, there is provided a system for altering a condition of a digital collectible, including at least one processor configured to: determine a circumstance associated with the digital collectible; select at least one modifier based on the determined circumstance; and, apply the at least one modifier to the digital collectible in the condition to modify the digital collectible to be in an altered condition. - A -

[018] In a third aspect, there is provided a computer program product for altering a condition of a digital collectible, the computer program product stored on a computer readable medium of instructions and able to be executed on at least one processing system to: determine a circumstance associated with the digital collectible; select at least one modifier based on the determined circumstance; and, apply the at least one modifier to the digital collectible in the condition to modify the digital collectible to be in an altered condition.

[019] In a fourth aspect, there is provided a method of modifying a rarity value for a digital collectible, including the steps of: allocating an initial rarity value to the digital collectible; allocating a release ID to the digital collectible; calculating, after an elapsed period of time, an updated rarity value for the digital collectible by: (i) determining a circulation number of digital collectibles remaining in circulation and identified by the same release ID; and, (ii) determining a subscriber number; and, (iii) determining the updated rarity value as a function of the circulation number and the subscriber number; and, replacing the initial rarity value with the updated rarity value.

[020] Preferably, the altered condition is a deteriorated condition. In various example forms: different conditions are grouped into a plurality of levels; the condition is a measure of deviation of the digital collectible from the original form of the digital collectible; the measure of deviation is a percentage deviation used to define the plurality of levels; and/or the digital collectible is associated with a condition value representing the condition.

[021] According to a particular example aspect, the method further includes setting the digital collectible in the altered condition as the digital collectible in the condition for a subsequent altering of the condition of the digital collectible. Preferably, though not necessarily, the digital collectible is a representation of one or more of: an image; audio; video; a ringtone; a game; and/or a song. Also preferably, though not necessarily, the content modification module is selected from the group of: an imaging module; an audio module; and a video module.

[022] According to further various example forms: the content modification module includes at least one modifier to alter the condition of the digital collectible; the at least one modifier applies an algorithm to the digital collectible where the algorithm is associated with the determined circumstance; the circumstance is selected from a master circumstance list; the circumstance is representative of an environmental factor; the circumstance is determined based on a physical location of a terminal storing the digital collectible; and/or the circumstance is determined based on information submitted by a user.

[023] According to a particular example, the modifier is a filter. According to another example form, a tag can be associated with a digital collectible which chronicles or otherwise details at least part of the history of the digital collectible. According to a particular example, the method further includes a restoration step to apply the content modification module to produce a further altered condition, where the further altered condition is an improved condition. According to a further particular example, the rarity level is a function of the condition of the digital collectible.

[024] In further broad forms the present invention also provides a system and/or a computer program product for realising or embodying the aforementioned methods.

Brief Description Of Figures

[025] The present invention should become apparent from the following description, which is given by way of example only, of a preferred but non-limiting embodiment thereof, described in connection with the accompanying figures.

[026] Fig. 1 illustrates an example functional block diagram of a processing system embodiment of the present invention;

[027] Fig. 2 illustrates an example series of steps for effecting download of a DDI to a user terminal; [028] Fig. 3 illustrates an example handover protocol for transferring a DDI;

[029] Fig. 4 illustrates an example of the server-side system architecture;

[030] Fig. 5 illustrates an example of the user or client-side system architecture;

[031] Fig. 6 illustrates an example of the condition of a DC in relation to a circumstance;

[032] Fig. 7 illustrates an example of the restoration module operating on a DC; [033] Fig. 8 illustrates an example of a tag of a DC in relation to an event;

[034] Fig. 9 illustrates an example of a DC provided with an attribute.

Modes for Carrying Out The Invention

[035] The following modes are described in order to provide a more precise understanding of the subject matter of the present invention. In the figures, incorporated to illustrate the features of the present invention, like reference numerals are used to identify like parts throughout the figures.

[036] A particular embodiment of the present invention can be realised using a processing system, an example of which is shown in Fig. 1. In particular, the processing system 100 generally includes at least a processor or processing unit 102, a memory 104, an input/output device 106, coupled together via a bus or collection of buses 110. An interface 112 can also be provided for coupling the processing system 100 to a storage device 114 which houses a database 116. The memory 104 can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The input/output device 106 receives data input 118 and can include, for example, a network connection, etc.. The output device 106 produces data output 118. The storage device 114 can be any form of storage means, for example, volatile or nonvolatile memory, solid state storage devices, magnetic devices, etc..

[037] Input/output device 106 communicates using data input/output 118 with terminals or devices 122, 124 via communication networks or communication protocols 126, 128 (for example the Internet or a wireless network). As an illustrative, but non-limiting, example terminal 122 may be a remote Internet connected PC in communication with the processing system 100 embodied as a server, and terminal 124 may be a mobile telephone in wireless communication 128 with server system 10Q.

[038] In use, the processing system 100 is adapted to allow DDI's to be stored in and/or retrieved from the database 116. The processor 102 receives instructions via the input/output device 106, for example a download request, and if authenticated, the system 100 can transmit to the terminal 122 or 124 a requested DDI via the input/output device 106. It should be appreciated that the processing system 100 may be any form of processing system, computer terminal, server, specialised hardware, or the like.

Technology Platform Overview

[039] The following discussion provides an overview of a non-limiting example platform. It should be noted that, alternatively, any other type of Digital Rights Management system or platform could be utilised. Aspects or features of the DRM system or technology platform used are not essential features of the invention, but are provided herein by way of example. Reference to a DDI can also be read as a reference to a DC. [040] 1. An application, for example a Collector Applet, is installed on a user terminal. This may occur by a service provider transmitting the Collector Applet to the user terminal 122 or 124. This step only needs to be performed the first time the user uses the service. Alternatively the Collector Applet may be preinstalled on the user terminal.

[041] 2. A user, or equally a subscriber, is registered in order to utilise the service.

Registration requires the user to provide identification details to the service provider, for example by submission of information to a server. The subscription details are saved in a User Information Database (UID) and are also sent to the server. This registration step only needs to be completed the first time the user or subscriber uses the Collector Applet. By locating the UID on both the user terminal and the server the service can then perform a digest-based authentication process.

[042] 3. The Collector Applet is "bound" to a user terminal. Each user terminal should have its own Collector Applet. The Collector Applet encodes a unique identifier of the terminal so that the Collector Applet does not work on any other terminal. The unique identifier of the terminal may be a serial number (eg. MSISDN, IMSI, IMEI, etc.), or any other accessible identifier, number, code, etc., that uniquely identifies the terminal or part thereof. The unique identifier of the terminal is also saved into the UID on both the user terminal and the server. This step only needs to be performed the first time the user utilises the service.

[043] 4. The user is then authenticated. Using a secure mechanism such as SSL

(Secure Socket Layer) the user is identified to the server offering the service. When connecting to the server, the server can present a nonce. Both the Collector Applet and the server can calculate a cryptographic one-way hash over both the contents of the UID and the nonce. If they match, the user is authenticated.

[044] 5. The DDI, which can be a DC, is then identified. The DDI to be downloaded is identified via a unique serial number that is provided by the user.

[045] 6. The DDI is then downloaded to the user terminal. Preferably, it should be ensured that the DDI has successfully been downloaded to the user terminal, not that the download was merely initiated. [046] Referring to Fig, 2, a method 200 of ensuring successful downloading to the terminal is illustrated. At step 205 the Collector Applet requests downloading of the DDI from the server. At step 210 the server is required to authenticate the request. If the request is denied the transaction is aborted at step 215. If the transaction is aborted the server does not register the download and the user terminal or device removes, deletes or renders unusable any downloaded or partially downloaded DDL

[047] If the server authenticates the request at step 210 the server initiates the download of the DDI at step 220. At step 225 the Collector Applet checks whether it should accept the download of the DDL If the Collector Applet does not accept the download of the DDI the transaction is aborted at step 215. If the Collector Applet does accept the download of the DDI, then the DDI is sent from the server to the user terminal as illustrated at step 230. The Collector Applet checks whether the DDI has been completely downloaded at step 235, and if not the transaction is aborted at step 215.

[048] If the complete downloaded DDI is received then the Collector Applet informs the server of completion of the download of the DDI at step 240. The server checks at step 245 whether the download was completed within a preset timeframe, and if not the transaction is aborted at step 215. If the download was completed within the acceptable timeframe, at step 245, then the server acknowledges the completed download to the Collector Applet at step 250. The Collector Applet then verifies itself whether it received the complete downloaded DDI within the timeframe at step 255, which if positive ends the process at step 260, or if not, the transaction is aborted.

[049] Transferring the downloaded digital material embodied as a DDI (or equivalently as a DC) is now discussed. The present embodiment seeks to allow the transfer of protected material such that a recipient receives an originator's copy of the digital material and the originator's copy of the digital material is removed, deleted or rendered unusable.

[050] This is achieved by a client-server-client operation. That is, the two Collector Applets (a first Collector Applet residing on an originator terminal and a second Collector Applet residing on a recipient terminal) do not communicate directly with each other but rather send messages/information via the server(s). This can be achieved using any client- server network including WAP; SMS; TCP/IP (for example over GPRS or 3G); wireless or wireline Ethernet; or any other type of network. [051] Once the transfer is initiated the net effect is that the DDI is copied from the originator terminal to the recipient terminal and it is ensured that the DDI is: (A) successfully transferred to the recipient terminal; and (B) removed, deleted or rendered unusable from the originator terminal.

[052] In a particular example embodiment, this can be achieved using the process or protocol illustrated in Fig. 3. Referring to Fig. 3, the originator 300 initiates a transfer 305 to server 310. The recipient 315 accepts the download of the DDI from the server 310. Server 310 may send the message to recipient 315, as a result of server 310 receiving initiate transfer request 305, after some arbitrary or fixed time delay, or alternatively substantially instantaneously. Any such time delay, or absence thereof, may be inherently connected to the particular type of technology platform, for example GPRS or SMS. In Fig. 3, the terms 'msg', 'ack' and W refer to 'message', 'acknowledge' and 'time/out' respectively. The DDI is then deleted or rendered unusable 320 from the originator terminal, and the DDI is transmitted 325 to the recipient terminal. A unique key is also transmitted to the recipient terminal. At the server 310, records can be dated to identify that a particular DDI has been deleted or rendered unusable from the originator terminal and sent to the recipient terminal. If required, timing of these transactions can be monitored to attempt to identify invalid or incomplete transactions.

[053] Tracking of the pathway of each DDI can also be provided. This is possible as a user can be required to register with the server in order to participate in the service. The user may also only transfer a DDI to another user using a server offering the service. This allows the server (or servers) to gather and maintain information about: the popularity and collectable nature of each DDI; the profile of users participating in the DDI transfer service for different segments and types of DDIs; and the buying and transferring habits of users.

[054] Tracking of each DDI can also be associated with billing or accounting software to collect and/or distribute revenues or payments appropriate to each DDL Users may use the service by fixed subscription fees, charges per DDI or set of DDIs, or any other suitable payment method. In a particular embodiment, digital material content providers may or may not be charged a subscription fee, and it is possible that the service could distribute royalty fees to content providers.

[055] Illustrated in Fig. 4 is a particular server-side system architecture suitable for use in the present embodiment. Server(s) 400 includes Content Library Server (CLS) 405 housing Content Library Database (CLD) 410 and web server 415. User Information Server (UIS) 420 can house User Information Database (UID) 425 and web server 430. Web server 415 is responsible for digital material content management, such as uploading, removing, viewing and editing of content. Web server 430 is responsible for management of user information. The User Information Server 420 is also preferably in communication 435 with a billing system and network activation system. User requests for registration and content download 440 are received by User Information Server 420 which also provides a response 445 to the user terminal as per the previously mentioned methods.

[056] Fig. 5 illustrates the user or client-side system architecture according to a particular embodiment. The server 400 (or servers) are part of a service provider network 505, although this is not an essential feature. Communication of content download requests 510, licensed content transmission 515 and tracking infoπnation 520 can occur via base station 525 in the case of a GSM/GPRS network 530. User terminal 535 (in this case a mobile telephone) initiates content download requests 510, receives content downloads 515 and offers tracking information 520 to the server 400. Content downloads 515 in the embodiment illustrated can be via different methods including: SMS, WAP, WiFi/802.11, or any other suitable means. A DDI 540 can be transferred with another user terminal 550 via any suitable means, such as infra-red, bluetooth, or WiFi, etc.. Tracking information 570 is transmitted/received from terminals 550 to/from the server 400 via network 530.

Operation of the Collector Applet:

[057] In a particular embodiment, the Collector Applet initialises and checks that a user (i.e. subscriber) has valid continued access to the service. The Collector Applet can then display the collection(s) of digital material that is available. A user can add, remove/delete/render unusable and/or transfer DDIs. The Collector Applet contacts the server 400 to verify that transfers and additions are allowed, and, if appropriate, commence download of a DDL

[058] As used herein, a token may be composed of one of many serial numbers and/or unique identifiers. Users may also "interact" with a DDL The form of the interaction is DDI specific. As some illustrative examples: for a mobile telephone ringtone, a user may interact with the DDI itself to set the ringtone as active on the mobile telephone; for a picture or graphic, the DDI may be to set as the wallpaper or screen background; or for a game, the user may select to play the game. The nature of the DDI specific option is encoded within the DDI itself. Operation of the Server-Side:

[059] In a particular embodiment, the server-side of the present system has a number of functions, including, but not necessarily limited to: content uploading, reviewing and indexing; billing and user services.

Responses:

[060] The client terminal and server both know about a number of responses and requests. These include:

[061] Registration Requests: are sent by the Collector Applet to notify the server of its presence. This allows the server to authorise (or not) the Collector Applet. Valid responses can include:

'valid': returned if the Collector Applet is authorised. 'invalid': returned if there is a problem with any part of the unique token, authorisation details, the hash, or any other reason.

[062] Transfer Requests: are sent by the Collector Applet when the user wishes to give/transfer a DDI to another user. The server can respond with the following: 'invalid': returned if the any of the authorisation parameters are deemed incorrect,

'not-allowed': returned if the DDI can not be transferred, 'valid-direct': returned if the DDI can be transferred directly to the other user.

Valid': returned if the DDI can be transferred and is to be performed by the server.

[063] Download Requests: the Collector Applet sends this when a user requests a specific DDI, or has received a DDI via a transfer. The server can respond with the following:

'invalid': returned if the any of the authorisation parameters are deemed incorrect, 'valid-but-gone': the DDI token is valid but the DDI is no longer downloadable. 'valid': the DDI is valid and the server may either send the DDI itself or location details to the Collector Applet as to where to obtain the DDL [064] Although the foregoing description of an example platform requires a central server to be involved in the process, it is possible to allow arbitrary users/subscribers to transfer DDIs amongst themselves.

Digital Collectibles

[065] The concept of digital collectibles relates to virtualisation of real world collecting, trading and associated concepts, such as the condition and rarity of an item. In the real world, collectors take great care of their collectibles, seeking to ensure collectibles remain in "mint" condition or as close to mint condition as possible. In the real world, collectibles that are not in mint condition are worth less.

[066] As an example applied to digital material, for example an image, use of the image can be considered to be when the image has been downloaded and applied on a terminal, for example as wallpaper on a mobile telephone. In the case of a mobile telephone ringtone, use of the ringtone can be considered to have occurred when the ringtone has been downloaded and installed on a mobile telephone as a ringtone.

[067] Consequently, digital material can be considered unused when the digital material has not been applied in a terminal. In a particular example, it can be considered that downloading of digital material is not use of the digital material as the digital material has not been applied in a terminal. This provides an example of how one can differentiate between digital material in mint condition and digital material in some level of used condition. A collectible marketplace can then apply a valuation of mint or used condition digital material accordingly.

[068] Thus, a Digital Collectible (DC) is a DDI that can be considered as being, or as potentially being, collectible, tradeable or desirable to have or own, where the DC has an associated condition and/or rarity. In the real world, the more often a collectible is handled (i.e. applied) the more damaged the collectible becomes. Generally, the more the collectible is used, the worse, and sometimes more quickly, the condition of the collectible deteriorates.

[069] All types of digital material can be altered in some manner to reflect a deteriorating condition of the digital material. For example, in the case of images, coloured tints can be applied and pixels lost. In the case of sounds or audio, skips can be introduced and other arbitrary sounds, such as whistles and pops, can be added. In the case of games, game levels can be missing. The length of time over which such deterioration occurs can be variable.

[070] In the real world, a collector can seek to restore a collectible. Similarly, in relation to a DC, the ability can be provided to restore a DC of which the condition has deteriorated. Also, it can provided that a DC that has been restored can subsequently deteriorate more quickly than the DC did when in original condition. Such factors can affect the market value of a DC.

[071] The concept of rarity of a DC can also be provided. Initially, the rarity, or a rarity level or value, of a DC can be nominated, calculated or determined. The number of DCs available for download can be limited to correspond to a particular rarity value which may be pre-set rather than being calculated. There would be required to be a limited supply of particular digital content for rarity to apply.

Condition of a Digital Collectible

[072] A method, and associated system, of altering a condition of a DC is provided that includes the steps of retrieving the DC in the condition, determining a circumstance, selecting a content modification module, and applying the content modification module and the circumstance to the DC in the condition, to then produce a DC in an altered condition. When a DC is first introduced or used in the method or system the condition of that DC is set or defined to be a particular condition, for example mint condition. Any other arbitrary descriptor of the condition, for example numerical levels, could also be utilised. Subsequently, from that time on, the condition of the DC is preferably calculated as a deviation from this original condition, for example the deviation from a mint or original condition.

[073] Different conditions, that is different levels of deviation of condition, can be grouped into a plurality of levels. For example, the plurality of levels can be associated with representative names such as mint, near mint, fine, very good, good, fair and poor.

[074] The actual condition of a DC can be determined as a measurement of a percentage deviation from the original condition of the DC (i.e. mint condition). This percentage deviation, or other form of deviation calculation such as one of various statistical deviation measures, can be used to obtain a condition value. The condition value represents the present condition of a DC, and as the condition value changes the condition level may also change.

[075] As a non-limiting example, condition levels may correspond to the following condition values representing a percentage deviation from the original condition of a DC:

Table 1: The Condition Value Table

[076] The condition of a DC can be modified by different server-based or client terminal- based modules, herein termed Content Modification Modules (CMM). For example, simple content types, such as an image, can be modified by an imaging content modification module, while a ringtone, music or audio can be modified by a different audio content modification module.

[077] The CMM operates on a logical level that is above raw bit manipulation. A CMM uses possible modifiers, such as filters or conversions that can be selected and applied to a DC. Such modifiers should generally be thought of as introducing some form of effect, for example a visual or audio effect, by adding to and/or removing from the DC.

[078] For example, in the imaging content modification module the following example modifiers (e.g. filters) might be utilised:

Drop pixels - a percentage of pixels are lost (set to black or white) in the image.

Fade - a percentage of the image has saturation values decreased. Warp - a percentage of the image is passed through a transformation formula. [079] Alternatively or additionally, the CMM might utilise a modifier that introduces one or more special effects as an additional visual or audio layer or component. As a specific example, in colder climates an image might appear to "ice up" or be laying in water, or an audio file might be overlaid with "windy" or "ice tinkly" sounds. In warmer climates an image might collect sand grains and look scratchy or sand-blasted, or an audio file might acquire a gritty, crunchy sound.

[080] A CMM that affects the condition of a DC can define a list of modifiers, e.g. filters, that transforms the DC in some manner, which manifests itself as a change in condition of the DC. Each modifier can be provided with a name and an associated formula or algorithm that is used to calculate the next iteration of a condition change of a DC and modify the DC accordingly (e.g. by adding, removing or altering pixels in an image).

Changes in the condition of a DC can be saved centrally in a content version control system.

[081] It is desirable, for the purposes of simplicity as well as automation, that the interface to services affecting the condition of a DC be consistent, regardless of the underlying content type of DC. Preferably, a plugin system is used that defines an Application Programming Interface (API) that is implemented for each type of plugin. A plugin architecture can be designed for a condition module to be used by each CMM working with the condition module. The plugin architecture can define an API to be implemented by each plugin. A plugin API can provide methods to list the available condition changing services and utilise this service as listed, for example specifying a percentage of condition change.

[082] In the real world, if a physical object is subjected to harsh conditions, one would expect that the physical object deteriorates at a different rate to the same object if it were well looked after. The surrounding environment affects both the rate at which the object changes condition and the type of change. For example, paper left outside will fade. Paper left in a very hot sunny place for a lengthy period of time will fade faster than the same piece of paper that is sometimes left in a shady place rather than a hot sunny place.

[083] A similar concept is applied in the present method and system and is termed circumstance. A circumstance is representative of one or more of a set of environmental factors that can affect the condition of a DC. The circumstance works with at least one CMM across one or more content types to affect the condition of a DC. For example, a Master Condition List (MCL) may define circumstances HOT_WEATHER and COLD_WEATHER. To achieve this, at the CMM level, the imaging content modification module might be invoked by an instruction to affect the condition of the given DC by dropping pixels and fading the image of the DC.

[084] A large variety of applications of circumstance can be envisaged. As an illustrative example, a circumstance may be obtained by being linked to seasonal changes in a particular country. A user, i.e. a subscriber, may have been required to list a country of residence when registering. Based on this country information, seasonal information, such as temperature, humidity, etc., can be obtained and used as a basis for selecting a circumstance which can be applied to a DC.

[085] As another example, many mobile telephones are now equipped with GPS, which can be used to physically locate the mobile telephone. This physical location can be retrieved, for example by an application on the telephone accessing the GPS information, and weather conditions can be obtained at a particular time for that physical location. A circumstance can then be determined and applied to the DC to affect the condition of the DC.

[086] Use of circumstance is further illustrated in Fig. 6. Referring to Fig. 6, there is illustrated a system 600 in which the DC 610 has a condition 620 and interacts with a master circumstance list 630. An example circumstance is shown as "hot weather" 640. Circumstance 640 may invoke imaging CMM 650 and/or audio CMM 660.

[087] Imaging CMM 650 includes modifiers or filters to alter the condition of the DC, for example modifiers may include, amongst others, drop pixels filter 652, fade filter 654, tear filter 656 and warp filter 658. Audio CMM 660 also includes modifiers or filters to alter the condition of a DC, for example, skip filter 662, warp filter 664 and octave change filter 666. Each of the modifiers or filters applies a particular algorithm or formula to the DC 610 where the algorithm or formula can be associated with a particular circumstance, for example hot weather circumstance 640. A particular circumstance is selected from the master circumstance list 630. A particular circumstance can be representative of particular environmental factors. The particular circumstance can also be determined based on a physical location of a terminal storing the DC 610. Also, the particular circumstance can be determined or selected from master circumstance list 630 based on information submitted by a user or subscriber.

[088] So that circumstances can be applied consistently and coordinated from one particular CMM to another, it is preferable to use a defining list of circumstances such as the Master Circumstance List (MCL) 630. Each particular circumstance, for example hot weather circumstance 640, preferably includes a name and an algorithm or formula that is used to calculate the next iteration of a change in condition of DC 610 so that the condition of DC 610 can be modified accordingly.

[089] The condition of a DC is affected by an application of the DC. A DC that is considered to be in mint condition is a new DC. To utilise the content contained in the DC a user must apply the DC. For example, in the context of a DC for a mobile telephone, the user sets or installs the DC as the mobile telephone's wallpaper, Screensaver, logo, ringtone, etc.. Once a DC has been applied it is no longer considered to be in mint or original condition. Application of a mint condition DC can cause its condition to change, for example after the first application the mint condition can be changed to fine condition. Subsequent applications of the DC also cause its condition level to be changed by a certain amount defined by a particular algorithm or formula, for example by an exponential amount of its current deviation from mint condition.

[090] In the real world a collectible can be restored, for example an artwork can be restored. Similarly, and referring to Fig. 7 illustrating method 700, a DC 610 that has a deteriorated condition 620a can have the condition 620a improved by a restoration process 700. In a particular example, as in the real world, it can be provided that a DC can never again attain a mint condition once the condition of the DC has deteriorated from mint condition. For example, the best condition a DC might attain, once no longer in mint condition, could be near mint condition.

[091] Thus, it is possible to restore a DC 610 that is not in mint or original condition such that the condition 620a of the DC 610 improves. Different levels of restoration can be provided to a user, which may, for example, be linked to a level of payment in some form made by the user. Different levels of restoration can correspond to degrees of restoration of the condition 620a of a DC 610. A restoration module 710 or process is preferably linked to the central content version control system. Restoration module 710 acts on DC 610 in condition 620a to restore DC 610 to an improved (or otherwise restored) condition 620b. All changes in the condition of a DC are preferably saved in the central content version control system.

[092] According to another example form, a tag can be associated with a digital collectible which chronicles or otherwise details at least part of the history of the digital collectible. The tag might be in the form of an icon, text or image for an image digital collectible, or audio, sound or a voice-over for an audio digital collectible. For example, a tag can be added to a digital collectible so as to record use of the digital collectible at a location and/or time of a significant social, cultural or historical event.

[093] A tag may or may not alter the condition of a digital collectible (e.g. by adding a layered effect), and a tag may or may not record an occurrence of use in the digital collectible's unique ID data. In a further example, the tag may be in the form of text, an image or indicia that is overlayed on the digital collectible to evidence use of the digital collectible at a social, cultural or historical event. The tag may be indicative in some form of the nature of the event. Thus, it is also possible to overlay a digital collectible with an image layer that is not connected to an environmental circumstance, but is rather associated with an event. It should be understood that an 'event' may be treated as a specific type of circumstance having one or more associated modification modules.

[094] Referring to Fig. 8, there is illustrated method 800 for applying a tag to digital collectible 610. Events module 830 includes, stores or accesses one or more specific event modules, for example a 2008 Olympics event module 840. Use of digital collectible 610 at and/or during the 2008 Olympics results in one or more modifiers being selected and applied to digital collectible 610, which may or may not alter condition 620. For example, modifiers may include add tag 852, add icon 854, add text 856 and add image 858 belonging to imaging event module 850. Modifiers may also include add audio 862, add sound 864 and add voice-over 866 belonging to audio event module 860. Imaging event module 850 can store or obtain tags, icons, text, images, etc., relating to or associated with Olympics event 840. For example, add tag 852 may add an Olympics-related logo and/or text to digital collectible 610. Olympics event 840 can contain rules defining which modifiers, e.g. one or more modifiers from imaging event module 850, are to be applied to, for example as an image overlay, digital collectible 610.

Rarity of a Digital Collectible [095] The concept of a rare item has meaning only if rarity can be measured and compared. DCs can be associated with attributes in addition to a condition of the DC. Referring to Fig. 9, DC 610 has an associated condition 620 as well as an associated attribute 920. One such attribute is rarity of the DC. Users or subscribers are then able to make an informed decision regarding the value of a DC by having regard to attributes such as condition and/or rarity. A rarity value 920a is an example measure of attribute 920 that can be associated with DC 610 to represent the rarity of the DC 610.

[096] The rarity value, being a measure of the rarity of a DC, is measure of the availability of the DC within the digital collectible marketplace. The rarity of a DC is a measure of the availability of the DC. Preferably, a rarity value is only assigned and modified by a central or controlling server, not a user terminal. A rarity value is initially assigned to a DC when the DC is introduced into the digital collectible marketplace. The rarity value is preferably a factor of the number of copies of that particular DC available for download by users or subscribers. The rarity value of a DC can change over the lifetime of the DC according to many factors.

[097] The rarity value can be grouped into a plurality of rarity levels. Rarity values can be arbitrarily named, for example rarity values can be represented by a number between 1 and 100. These rarity values can be grouped into rarity levels. The rarity levels can have representative names that incorporate a range of rarity values. For example, rarity levels could include: "no way" - rarity value 0-5; "hard to find" - rarity value 6-15; "unlikely" - rarity value 16-40; "I've seen it" - rarity value 41-60; "vanilla" - rarity value 61-85.

[098] A method of calculating an initial rarity value is employed which is indicative of the availability of a particular DC at the time the DC is introduced. The initial rarity value of a DC is preferably, though not necessarily, linked with the number of subscribers and potential subscribers at the time of introduction of the DC. The number of potential subscribers in a given region combined with the number of actual subscribers at any given time can be calculated and termed the adjusted subscriber base. When the rarity value, and consequently the rarity level, is first assigned to a DC the rarity value can be representative of a percentage of the adjusted subscriber base at that particular time of introduction of the DC. A range of percentages can be assigned to each rarity level, for example as indicated below:

Table 2: Example Rarity Percentage Table

[099] Subsequently, the rarity value of a DC can be calculated by dividing the number of DCs in a particular release (DC release count) by the current adjusted subscriber base and comparing the result to the Rarity Percentage Table 2. It should be noted that an adjusted subscriber base is not essential and any other measure of the subscriber base, for example an actual subscriber base or a subscriber base limited geographically, may be used.

[0100] The introduction of a DC into the digital collectible marketplace is a unique event. If the same DC is introduced again, at a later date, this is treated as another unique event. The two events are differentiated as different releases of the DC, somewhat similar to different print runs of a book. The introduction of a DC is termed a release of that DC. When a DC is introduced a unique release ID is assigned to the DC. The release ID can be generated by a server. All copies of a DC that are introduced at the same time are part of the same release and are preferably assigned the same release ID.

[0101] When a DC is introduced into the digital collectible marketplace, the actual number of copies of the new DC that become available to users or subscribers may be determined by multiplying the adjusted subscriber base at the time of introduction with a pre-set percentage assigned to that DCs chosen rarity level.

[0102] Like any collectible in the real world, the rarity, and hence the rarity value, of a DC can, and preferably does, change over time. The rarity of an entire DC release is dependent upon the number of DCs with the same release ID currently in circulation, and the rarity value changes if the number of DCs currently in circulation changes.

[0103] Furthermore, in a particular embodiment, the rarity of a single DC can be dependent upon the condition of the DC. If the condition of the DC changes then the rarity of the DC may also change. Subsequently, the rarity of all DCs with the same release ID would also change. [0104] The rarity value of each DC can be periodically re-calculated. For example, the frequency of re-calculation could be quarterly. In order to prevent any circular dependencies in the rarity calculation process, the DCs could be processed in a single pass- through batch.

[0105] In certain circumstances, assumptions can be made about the availability of a DC and rules implemented in a server. For example, consider the case where a subscriber loses his or her mobile telephone and does not report the loss, or if the subscriber ceases to use an old mobile telephone with DC content. In such cases, rules implemented at a server can deem the DCs associated with a particular mobile telephone to be out of circulation after a given period of time.

[0106] When a DC is removed or deleted from circulation, or rendered unusable, the rarity of other DCs with the same release ID changes. When a DC is removed or deleted from circulation, or rendered unusable, the rarity of the other DCs with the same release ID can be re-calculated at the next periodic re-calculation time. Alternatively, re-calculation might be triggered when a set number of DCs are removed or deleted from circulation, or rendered unusable. Preferably, removing or deleting a DC from circulation, or rendering the DC unusable, is a permanent action.

[0107] A change in the condition of a DC can affect both the DCs value and the value of the other DCs in the same release. Because condition deterioration is mostly a one-way operation, i.e. once the DC is no longer in mint condition the DC can never return to mint condition again, DCs that change condition preferably cause other DCs with the same release ID that are still in mint condition to become more rare, thus changing the rarity value of these other DCs.

[0108] In a particular example, the rarity of a DC is calculated for DCs in mint condition. If two or more DCs with the same release ID have a different condition then those DCs can also have a different rarity. Within a release of DCs there may be at least one, and for example up to five different rarity levels, one for each condition. A different upper limit of rarity levels could be selected. If the condition of a DC is mint then the condition of that DC could be shown to a subscriber. If a condition of a DC is no longer mint then both the rarity level and the condition of that DC could be shown to the subscriber. [0109] A rarity module may utilise one or more databases, for example a DC database to access and update a rarity field, the DC database to access the release count field of a particular release, and a subscriber database to access the total number of subscribers. An interface module can also be provided, with instructions to update the rarity value as required.

[0110] According to a further example aspect, a DC may, but does not necessarily need to, include or be associated with additional information, which could be termed a "fact file". A fact file can include the rarity level/value, condition level/value, other transaction data, special interest data and/or other data specific to a DC, for display to a user/subscriber. A fact file might take the form of a table with content or information in table fields, and may be displayed as an additional feature of a DC or associated in some manner with a DC.

[0111] The present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, firmware, or an embodiment combining software and hardware aspects.

[0112] The invention may also be said to broadly consist in the parts, elements and features referred to or indicated herein, individually or collectively, in any or all combinations of two or more of the parts, elements or features, and wherein specific integers are mentioned herein which have known equivalents in the art to which the invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth.

[0113] Although the preferred embodiment has been described in detail, it should be understood that various changes, substitutions, and alterations can be made by one of ordinary skill in the art without departing from the scope of the present invention.

Claims

The claims:

1. A method of altering a condition of a digital collectible, including the steps of: determining a circumstance associated with the digital collectible; selecting at least one modifier based on the determined circumstance; and, applying the at least one modifier to the digital collectible in the condition to modify the digital collectible to be in an altered condition.

2. The method as claimed in claim 1, wherein the altered condition is a deteriorated condition.

3. The method as claimed in either claim 1 or 2, wherein different conditions are grouped into a plurality of condition levels.

4. The method as claimed in any one of the claims 1 to 3, wherein the condition is a measure of deviation of the digital collectible from an original form of the digital collectible.

5. The method as claimed in any one of the claims 1 to 4, wherein the digital collectible is associated with a condition value representing the condition.

6. The method as claimed in any one of the claims 1 to 5, further including the step of: setting the digital collectible in the altered condition to be the digital collectible in the condition for any subsequent application of the method.

7. The method as claimed in any one of the claims 1 to 6, wherein the digital collectible is one or more of: an image file; an audio file; a video file; a ring tone; a game; and a song recording.

8. The method as claimed in any one of the claims 1 to 7, wherein the at least one modifier is associated with an imaging content modification module, an audio content modification module, a game content modification module, or a video content modification module.

9. The method as claimed in any one of the claims 1 to 8, wherein the at least one modifier applies an algorithm to the digital collectible.

10. The method as claimed in any one of the claims 1 to 9, wherein the circumstance is selected from a master circumstance list.

11. The method as claimed in any one of the claims 1 to 10, wherein the circumstance is representative of an environmental factor.

12. The method as claimed in any one of the claims 1 to 10, wherein the circumstance is determined based on a physical location of a terminal storing the digital collectible.

13. The method as claimed in any one of the claims 1 to 10, wherein the circumstance is determined based on information submitted by a user.

14. The method as claimed in claim 1, further including subsequently applying a restoration module to the digital collectible in the altered condition to modify the digital collectible to be in an improved condition.

15. The method as claimed in any one of the claims 1 to 14, wherein the digital collectible is associated with a fact file.

16. The method as claimed in any one of the claims 1 to 15, wherein the digital collectible is modified to include a tag associated with an event.

17. The method as claimed in any one of the claims 1 to 16, wherein the digital collectible is associated with a rarity value.

18. A system for altering a condition of a digital collectible, the system including at least one processor configured to: determine a circumstance associated with the digital collectible; select at least one modifier based on the determined circumstance; and, apply the at least one modifier to the digital collectible in the condition to modify the digital collectible to be in an altered condition.

19. A computer program product for altering a condition of a digital collectible, the computer program product stored on a computer readable medium of instructions and able to be executed on at least one processing system to: determine a circumstance associated with the digital collectible; select at least one modifier based on the determined circumstance; and, apply the at least one modifier to the digital collectible in the condition to modify the digital collectible to be in an altered condition.

20. A method of modifying a rarity value for a digital collectible, including the steps of: allocating an initial rarity value to the digital collectible; allocating a release ID to the digital collectible; calculating, after an elapsed period of time, an updated rarity value for the digital collectible by:

(i) determining a circulation number of digital collectibles remaining in circulation and identified by the same release ID;

(ii) determining a subscriber number; and, (iii) determining the updated rarity value as a function of the circulation number and the subscriber number; and, replacing the initial rarity value with the updated rarity value.