Method and apparatus for trading digital items in a network data processing system

CROSS REFERENCE TO RELATED APPLICATION

p-0002The present invention is related to the following application entitled: “Method and Apparatus for Temporary Ownership of Digital Items in a Network Data Processing System,” Ser. No. 10/615,717, filed even date hereof, assigned to the same assignee, and incorporated herein by reference.

BACKGROUND OF THE INVENTION

p-00031. Technical Field:

p-0004The present invention relates generally to an improved data processing system and in particular, to an improved method, apparatus, and computer instructions for transferring data. Still more particularly, the present invention provides an improved method, apparatus, and computer instructions for exchanging digital items.

p-00052. Description of Related Art:

p-0006The Internet, also referred to as an “internetwork”, is a set of computer networks, possibly dissimilar, joined together by means of gateways that handle data transfer and the conversion of messages from a protocol of the sending network to a protocol used by the receiving network. When capitalized, the term “Internet” refers to the collection of networks and gateways that use the TCP/IP suite of protocols.

p-0007The Internet has become a cultural fixture as a source of both information and entertainment. Many businesses are creating Internet sites as an integral part of their marketing efforts, informing consumers of the products or services offered by the business or providing other information seeking to engender brand loyalty. Many federal, state, and local government agencies are also employing Internet sites for informational purposes, particularly agencies which must interact with virtually all segments of society such as the Internal Revenue Service and secretaries of state. Providing informational guides and/or searchable databases of online public records may reduce operating costs. Further, the Internet is becoming increasingly popular as a medium for commercial transactions.

p-0008Currently, the most commonly employed method of transferring data over the Internet is to employ the World Wide Web environment, also called simply “the Web”. Other Internet resources exist for transferring information, such as File Transfer Protocol (FTP) and Gopher, but have not achieved the popularity of the Web. In the Web environment, servers and clients effect data transaction using the Hypertext Transfer Protocol (HTTP), a known protocol for handling the transfer of various data files (e.g., text, still graphic images, audio, motion video, etc.). The information in various data files is formatted for presentation to a user by a standard page description language, the Hypertext Markup Language (HTML). In addition to basic presentation formatting, HTML allows developers to specify “links” to other Web resources identified by a Uniform Resource Locator (URL). A URL is a special syntax identifier defining a communications path to specific information. Each logical block of information accessible to a client, called a “page” or a “Web page”, is identified by a URL. The URL provides a universal, consistent method for finding and accessing this information, not necessarily for the user, but mostly for the user's Web “browser”. A browser is a program capable of submitting a request for information identified by an identifier, such as, for example, a URL. A user may enter a domain name through a graphical user interface (GUI) for the browser to access a source of content. The domain name is automatically converted to the Internet Protocol (IP) address by a domain name system (DNS), which is a service that translates the symbolic name entered by the user into an IP address by looking up the domain name in a database.

p-0009While the Internet is commonly used to sell the types of goods typically offered in a so-called “brick and mortar” business, the Internet also is used to transfer digital goods, which may exist nowhere else. The Internet also is widely used to transfer applications to users using browsers. With respect to commerce on the Web, individual consumers and businesses use the Web to purchase various goods and services. In offering goods and services, some companies offer goods and services solely on the Web while others use the Web to extend their reach. Many items exist only on servers on the Web. In the digital world, money may be manifested as “e-money” or “digital cash”. With e-money, a digitally signed and encrypted block of data representing a money order on a bank is used. Another example of digital property is music, which may be purchased and possessed. The popularity of online gaming communities is a growing trend. In many of these gaming environments, digital items or properties may be traded between different players. For example, armors, rings, weapons, characters, and even castles may be traded between different players. Some of these items have even been auctioned on auctioning websites. All of these are examples of the rapid acceptance of digital property.

p-0010With many of these applications, interfaces are present for trading property within the same application. The present invention recognizes that a secure system for trading property between different applications and different users is absent. With the insecure mechanisms presently used, a multitude of scams and fraudulent transfers have occurred.

p-0011Therefore, it would be advantageous to have an improved method, apparatus, and computer instructions for exchanging digital items.

SUMMARY OF THE INVENTION

p-0012The present invention provides a method, apparatus, and computer instructions for transferring a unique digital item between a first party and a second party in a network data processing system. A request to transfer a unique digital item in an account of the first party is received. Responsive to receiving the request, a retrieval tag is associated with the unique digital item. The retrieval tag is generated by a server process, such as one on which the unique digital item is located. The unique digital item is transferred from the source account to a temporary storage account in association with the retrieval tag. Responsive to a redemption request initiated by the trusted third-party, the unique digital item is transferred from the temporary storage account to an account of the second party. Prior to transferring the unique digital item, the second party may inspect the unique digital item. The transfer occurs after all parties have committed to the transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0013The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

p-0014<figref idrefs="DRAWINGS">FIG. 1</figref> is a pictorial representation of a network of data processing systems in which the present invention may be implemented;

p-0015<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of a data processing system that may be implemented as a server in accordance with a preferred embodiment of the present invention;

p-0016<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram illustrating a data processing system in which the present invention may be implemented;

p-0017<figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram illustrating components used in transferring unique digital items in accordance with a preferred embodiment of the present invention;

p-0018<figref idrefs="DRAWINGS">FIGS. 5A-5F</figref> are diagrams illustrating an example of a transaction for trading unique digital items in accordance with a preferred embodiment of the present invention;

p-0019<figref idrefs="DRAWINGS">FIGS. 6A-6E</figref> are diagrams illustrating an example of a lease transaction for a unique digital item in accordance with a preferred embodiment of the present invention;

p-0020<figref idrefs="DRAWINGS">FIG. 7</figref> is a flowchart of a process for placing a unique digital item into escrow in accordance with a preferred embodiment of the present invention;

p-0021<figref idrefs="DRAWINGS">FIG. 8</figref> is a flowchart of a process used in transferring a unique digital item to a trusted third-party in accordance with a preferred embodiment of the present invention;

p-0022<figref idrefs="DRAWINGS">FIG. 9</figref> is a flowchart of a procedure by which a trusted third-party processes a transaction in accordance with a preferred embodiment of the present invention;

p-0023<figref idrefs="DRAWINGS">FIG. 10</figref> is a flowchart of a procedure by which a trusted third-party server processes a redemption request in accordance with a preferred embodiment of the present invention;

p-0024<figref idrefs="DRAWINGS">FIG. 11</figref> is a flowchart of a procedure by which a storage server processes a redemption request in accordance with a preferred embodiment of the present invention;

p-0025<figref idrefs="DRAWINGS">FIG. 12</figref> is a flowchart of a process by which a party may return a unique digital item that is leased in accordance with a preferred embodiment of the present invention;

p-0026<figref idrefs="DRAWINGS">FIG. 13</figref> is a flowchart of a process by which a party may request compensation for late return of a unique digital item that is leased in accordance with a preferred embodiment of the present invention; and

p-0027<figref idrefs="DRAWINGS">FIG. 14</figref> is a flowchart of a process for conducting a temporary ownership transfer in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

p-0028With reference now to the figures, <figref idrefs="DRAWINGS">FIG. 1</figref> depicts a pictorial representation of a network of data processing systems in which the present invention may be implemented. Network data processing system <b>100</b> is a network of computers in which the present invention may be implemented. Network data processing system <b>100</b> contains a network <b>102</b>, which is the medium used to provide communications links between various devices and computers connected together within network data processing system <b>100</b>. Network <b>102</b> may include connections, such as wire, wireless communication links, or fiber optic cables.

p-0029In the depicted example, server <b>104</b> is connected to network <b>102</b> along with storage unit <b>106</b>. In addition, clients <b>108</b>, <b>110</b>, and <b>112</b> are connected to network <b>102</b>. Clients <b>108</b>, <b>110</b>, and <b>112</b> may be, for example, personal computers or network computers. In the depicted example, server <b>104</b> provides data, such as boot files, operating system images, and applications to clients <b>108</b>-<b>112</b>. Clients <b>108</b>, <b>110</b>, and <b>112</b> are clients to server <b>104</b>. Network data processing system <b>100</b> may include additional servers, clients, and other devices not shown. In the depicted example, network data processing system <b>100</b> is the Internet with network <b>102</b> representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system <b>100</b> also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). <figref idrefs="DRAWINGS">FIG. 1</figref> is intended as an example, and not as an architectural limitation for the present invention.

p-0030Referring to <figref idrefs="DRAWINGS">FIG. 2</figref>, a block diagram of a data processing system that may be implemented as a server, such as server <b>104</b> in <figref idrefs="DRAWINGS">FIG. 1</figref>, is depicted in accordance with a preferred embodiment of the present invention. Data processing system <b>200</b> may be a symmetric multiprocessor (SMP) system including a plurality of processors <b>202</b> and <b>204</b> connected to system bus <b>206</b>. Alternatively, a single processor system may be employed. Also connected to system bus <b>206</b> is memory controller/cache <b>208</b>, which provides an interface to local memory <b>209</b>. I/O bus bridge <b>210</b> is connected to system bus <b>206</b> and provides an interface to I/O bus <b>212</b>. Memory controller/cache <b>208</b> and I/O bus bridge <b>210</b> may be integrated as depicted.

p-0031Peripheral component interconnect (PCI) bus bridge <b>214</b> connected to I/O bus <b>212</b> provides an interface to PCI local bus <b>216</b>. A number of modems may be connected to PCI local bus <b>216</b>. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients <b>108</b>-<b>112</b> in <figref idrefs="DRAWINGS">FIG. 1</figref> may be provided through modem <b>218</b> and network adapter <b>220</b> connected to PCI local bus <b>216</b> through add-in boards.

p-0032Additional PCI bus bridges <b>222</b> and <b>224</b> provide interfaces for additional PCI local buses <b>226</b> and <b>228</b>, from which additional modems or network adapters may be supported. In this manner, data processing system <b>200</b> allows connections to multiple network computers. A memory-mapped graphics adapter <b>230</b> and hard disk <b>232</b> may also be connected to I/O bus <b>212</b> as depicted, either directly or indirectly.

p-0033Those of ordinary skill in the art will appreciate that the hardware depicted in <figref idrefs="DRAWINGS">FIG. 2</figref> may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.

p-0034The data processing system depicted in <figref idrefs="DRAWINGS">FIG. 2</figref> may be, for example, an IBM eServer pSeries system, a product of International Business Machines Corporation in Armonk, New York, running the Advanced Interactive Executive (AIX) operating system or LINUX operating system.

p-0035With reference now to <figref idrefs="DRAWINGS">FIG. 3</figref>, a block diagram illustrating a data processing system is depicted in which the present invention may be implemented. Data processing system <b>300</b> is an example of a client computer. Data processing system <b>300</b> employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) may be used. Processor <b>302</b> and main memory <b>304</b> are connected to PCI local bus <b>306</b> through PCI bridge <b>308</b>. PCI bridge <b>308</b> also may include an integrated memory controller and cache memory for processor <b>302</b>. Additional connections to PCI local bus <b>306</b> may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter <b>310</b>, Small computer system interface (SCSI) host bus adapter <b>312</b>, and expansion bus interface <b>314</b> are connected to PCI local bus <b>306</b> by direct component connection. In contrast, audio adapter <b>316</b>, graphics adapter <b>318</b>, and audio/video adapter <b>319</b> are connected to PCI local bus <b>306</b> by add-in boards inserted into expansion slots. Expansion bus interface <b>314</b> provides a connection for a keyboard and mouse adapter <b>320</b>, modem <b>322</b>, and additional memory <b>324</b>. SCSI host bus adapter <b>312</b> provides a connection for hard disk drive <b>326</b>, tape drive <b>328</b>, and CD-ROM drive <b>330</b>. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

p-0036An operating system runs on processor <b>302</b> and is used to coordinate and provide control of various components within data processing system <b>300</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>. The operating system may be a commercially available operating system, such as Windows XP, which is available from Microsoft Corporation. An object oriented programming system such as Java may run in conjunction with the operating system and provide calls to the operating system from Java programs or applications executing on data processing system <b>300</b>. “Java” is a trademark of Sun Microsystems, Inc. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on storage devices, such as hard disk drive <b>326</b>, and may be loaded into main memory <b>304</b> for execution by processor <b>302</b>.

p-0037Those of ordinary skill in the art will appreciate that the hardware in <figref idrefs="DRAWINGS">FIG. 3</figref> may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash read-only memory (ROM), equivalent nonvolatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in <figref idrefs="DRAWINGS">FIG. 3</figref>. Also, the processes of the present invention may be applied to a multiprocessor data processing system.

p-0038As another example, data processing system <b>300</b> may be a stand-alone system configured to be bootable without relying on some type of network communication interfaces As a further example, data processing system <b>300</b> may be a personal digital assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.

p-0039The depicted example in <figref idrefs="DRAWINGS">FIG. 3</figref> and above-described examples are not meant to imply architectural limitations. For example, data processing system <b>300</b> also may be a notebook computer or hand held computer in addition to taking the form of a PDA. Data processing system <b>300</b> also may be a kiosk or a Web appliance.

p-0040The present invention provides an improved method, apparatus, and computer instructions for trading digital property. Digital property is an item that exists in electronic form. Many items that exist in the world have analogs in the cyber world. The mechanism of the present invention is directed towards unique digital items that exist on a network data processing system, such as the Internet. The present invention provides a mechanism to exchange a unique digital item in which this item is placed into escrow prior to a transaction. These unique digital items may take many forms, for example, in a gaming environment an electronic trading card, token, currency, character, ring, castle, or armor. Fraud is prevented by using a trusted third-party, as well as allowing inspection of the digital item. In other words, the present invention provides a mechanism for monitored transfer of unique digital property between different realms in which these realms may be incompatible or do not have a mutual trust mechanism. A realm may be, for example, an environment in which the unique digital property is used or originates. Two realms may exist on the same server or on different server computers. The mechanism of the present invention also provides a way to rent or lease unique digital items.

p-0041Turning next to <figref idrefs="DRAWINGS">FIG. 4</figref>, a block diagram illustrating components used in transferring unique digital items is depicted in accordance with a preferred embodiment of the present invention. In this example, Web server <b>400</b> includes server process <b>402</b>, which is used to process requests from clients. Web server <b>400</b> may be implemented using a data processing system, such as data processing system <b>200</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>. Web server <b>400</b> is a storage server. A storage server is a server on which a unique digital item is located. This storage server may be, for example, a game server or any server on which a unique digital item can be held.

p-0042In these examples, clients may be, for example, client <b>424</b> and client <b>426</b>. These clients may be implemented, using a data processing system, such as data processing system <b>300</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>. In this example, digital property is owned by different users. Users at these clients may agree to exchange digital property using a trusted third-party service. In these examples, the property is a unique digital item. The unique digital item is associated with a user in accounts <b>408</b>. An accounts in which a unique digital item is held is hereinafter referred to as a storage account. In these examples, the digital property includes first unique digital item <b>410</b> and second unique digital item <b>412</b>.

p-0043User at client <b>404</b> sends a request to list a unique digital item, such as unique digital item <b>410</b>. This request is hereinafter referred to as a listing request, which is received by server process <b>402</b>. In response to receiving this request, server process <b>402</b> queries universal description discovery and integration (UDDI) directory <b>414</b> to obtain a list of digital trusted third-party service providers, such as an escrow service. This list of providers is returned to client <b>404</b>. The user at client <b>404</b> may then select one of the services. When the trusted third-party service is selected, the user may assign the unique digital item to another party, which is the recipient. This allows the user to select a trusted conduit through which to transfer unique digital item <b>410</b>.

p-0044Universal description, discovery and integration is an industry initiative for a universal business registry (catalog) of Web services. UDDI is designed to enable software to automatically discover and integrate with services on the Web. UDDI contains white pages (addresses and contacts), yellow pages (industry classification) and green pages (description of services). The green pages include the XML version, type of encryption and a document type definition (DTD) of the standard. UDDI messages ride on top of the simple object access protocol (SOAP), which invokes services on the Web.

p-0045In response to a selection of a service by the user, server process <b>402</b> queries UDDI directory <b>414</b> to obtain a Web services definition language (WSDL) Web service interface description for the selected digital trusted third-party service. WSDL is a protocol for a Web service to describe its capabilities. WSDL describes the protocols and formats used by the service. WSDL descriptions can be housed in a UDDI directory, and the combination is used to promote the use of Web services worldwide.

p-0046Preferably using a Web service interface description, such as WSDL, Web server <b>400</b> sends a listing request to the Web service interface for the trusted third-party service. The listing request is used to list a unique digital item on a trusted third-party server. In this example, the interface is to trusted third-party server process <b>416</b> in trusted third-party server <b>418</b>. Trusted third-party server <b>418</b> may be implemented using a data processing system, such as data processing system <b>200</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>. Trusted third-party server <b>418</b> may include trusted third-party accounts, which are accounts on which a listing of a unique digital item may be made.

p-0047In sending a listing request, server process <b>402</b> generates retrieval tag <b>422</b>, which forms the listing request in these examples. Retrieval tag <b>422</b> is digitally signed by server process <b>402</b>. The retrieval tag contains the name of server process <b>402</b>, a URL address of the Web service for server process <b>402</b>, a retrieval tag ID, the originating account ID, a digital item ID, a digital item descriptor, a digital item property type, and metadata. A digital item ID is a unique item ID used by server process <b>402</b> to track the item. A digital item descriptor provides a mechanism for users to inspect the digital item and may contain a descriptor string and a file to graphically view the digital item. The digital property type provides a mechanism to verify on which servers the digital item can reside. Metadata may contain, for example, an expiration timestamp, a temporary storage account ID, or any other descriptive information.

p-0048This retrieval tag is then sent to trusted third-party server process <b>416</b> as part of a listing request from Web server <b>400</b> to trusted third-party server <b>418</b>. This service may be implemented using a data processing system, such as data processing system <b>200</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>. Retrieval tag <b>422</b> includes the originating storage account ID, which is used by trusted third-party server process <b>416</b> to determine which of its trusted third-party accounts is to receive the listing of the unique digital item.

p-0049After receiving the listing request, trusted third-party server process <b>416</b> authenticates the data in this request. This data is authenticated by comparing the digital signature sent with the data against a published public key for Web server <b>400</b>. After the data has been authenticated, trusted third-party server process <b>416</b> generates a listing in a trusted third-party account for a user, such as a user at client <b>404</b>. This listing includes retrieval tag <b>422</b>.

p-0050After sending the listing request, server process <b>402</b> transfers unique digital item <b>410</b> to digital property temporary storage <b>424</b>. Trusted third-party server process <b>418</b> receives the listing request and creates listing <b>428</b> and makes a copy of retrieval tag <b>422</b>. This copy is referred to as copy of retrieval tag <b>430</b>.

p-0051After unique digital item <b>410</b> has been listed, a time stamp is associated with the unique digital item. This time stamp can be used to define a period of time after which the unique digital item will be de-listed and returned to the originating account if a transfer has not been made. The retrieval tag of a listed item is to be held exclusively by the trusted third-party at all times to prevent outside parties from misusing the retrieval tag.

p-0052Parties may exchange listings for unique digital items on the trusted third-party server. When a listing changes ownership, trusted third-party server process <b>418</b> sends a temporary ownership transfer request to server process <b>402</b> in which the request contains copy of retrieval tag <b>430</b> and a storage account ID. In this case, a new retrieval tag is generated by server process <b>402</b>, containing the new storage account ID, and returned to trusted third-party server process <b>418</b>. Copy of retrieval tag <b>430</b> is transmitted from server process <b>402</b> to server process <b>418</b>. Server process <b>418</b> decodes the message and stores copy of retrieval tag <b>430</b> in memory. A link or pointer to copy of retrieval tag <b>430</b> is added to the trusted third-party account's list of retrieval tags. When this happens, the account is said to “hold” the retrieval tag.

p-0053To redeem unique digital item <b>410</b> out of escrow back onto a server on which the item may be used, a redemption request is sent to server process <b>402</b>. For example, trusted third-party server process <b>416</b> may send a redemption request to server process <b>402</b> in which this request includes retrieval tag <b>422</b>. Such a redemption request may be done by trusted third-party server process <b>416</b> on behalf of a client such as <b>404</b> or <b>406</b>. The redemption request also includes a recipient account ID which indicates a destination storage account for digital item <b>410</b>. The redemption request may be made by parties or representatives of parties, such as the buyer. Any account with the trusted third-party can make a redemption request provided that account “holds” the retrieval tag for the unique digital item to be redeemed. Upon receiving a redemption request, server process <b>402</b> authenticates the redemption request and identifies the digital property associated with retrieval tag <b>422</b>. In this instance, unique digital item <b>410</b> is associated with retrieval tag <b>422</b>. This item is found within local digital property storage <b>424</b> in these examples. Unique digital item <b>410</b> is then placed into the account identified in the redemption request.

p-0054Further, in some cases, the user placing the unique digital item in escrow, such as a user at client <b>404</b> wishes to withdraw the unique digital item from escrow. In this case, client <b>404</b> would request the unique digital item from trusted third-party server <b>416</b>. Trusted third-party server process <b>416</b> sends a redemption request to server process <b>402</b> using retrieval tag <b>422</b>.

p-0055The different transactions described in <figref idrefs="DRAWINGS">FIG. 4</figref> are secure transactions, such as secure sockets layer (SSL) When an SSL session is started, the server sends its public key to the browser, which the browser uses to send a randomly generated secret key back to the server in order to have a secret key exchange for that session.

p-0056Further, these components may be used in a lease or rental system in which temporary ownership of digital property occurs. Temporary ownership as used herein is for a temporary transfer or exchange of a unique digital item. With temporary ownership, a unique digital item may be reassigned or designated to another user on a server on which the unique digital item resides. With temporary ownership, the unique digital item also may be moved to another server in addition to having a different user assigned as the owner or possessor of the item. After a period of time or after some triggering event, the unique digital item is then returned to the original user. The triggering event may be an occurrence of an event, such as, for example, an occurrence of a storm or appearance of an item in an online game.

p-0057For example, a party at client <b>404</b> may have a unique digital item, such as unique digital item <b>410</b> that a party at client <b>406</b> desires to lease or rent. This party at client <b>406</b> provides a payment and a deposit in these examples.

p-0058The parties mutually agree to use the same trusted third-party and list their unique digital items on the trusted third-party server. When the items are listed, each party gains a listing on the trusted third-party server. The party at client <b>404</b> gains a listing for unique digital item <b>410</b>, while the party at client <b>406</b> gains listings for the payment and deposit. The parties at clients <b>404</b> and <b>406</b> may inspect the items using the descriptor information contained in the listings.

p-0059If the parties cancel, the retrieval tags may be used to obtain the items that they placed into storage. If the parties agree to a transaction, they may exchange listings on the trusted third-party server, and then redeem the listings to gain possession of the unique digital items.

p-0060Alternatively, the parties may decide to conduct a transaction that involves the temporary ownership of unique digital items. Again, the parties mutually agree to use the same trusted third-party and list their unique digital items on the trusted third-party server. A lease contract is drawn up on the trusted third-party server, and all parties must agree to the terms and conditions of the lease contract. These terms may spell out penalties for late return, automatic return of the leased items upon lease expiration, marking leased items untradeable on the storage server, or substitution of a sufficiently similar unique digital item in place of the leased item.

p-0061Turning now to <figref idrefs="DRAWINGS">FIGS. 5A-5F</figref>, diagrams illustrating an example of a transaction for trading unique digital items are depicted in accordance with a preferred embodiment of the present invention. In this example, in <figref idrefs="DRAWINGS">FIG. 5A</figref>, party A <b>500</b> wishes to trade with party B <b>502</b>. Prior to the transaction or trade, party A <b>500</b> owns item A <b>504</b> in account <b>506</b> on server D <b>508</b>. Server D <b>508</b> is a storage server in these examples. Party B <b>502</b> owns item B <b>510</b> in account B <b>512</b> on server D <b>508</b>. These two accounts are storage accounts.

p-0062Both parties mutually agree to use a trusted third-party, such as escrow service C <b>511</b>. Escrow service C <b>511</b> is a trusted third-party server in this example. As illustrated, party A <b>500</b> has escrow account A <b>514</b> in escrow accounts <b>516</b> on escrow service C <b>511</b>. Party B has escrow account <b>518</b> in escrow accounts <b>516</b> on escrow service C <b>511</b>. These accounts are trusted third-party accounts which, in these examples, contain a list of all storage accounts associated with the trusted third-party account. An example of an entry in this list is a reference to the storage account ID <b>506</b> stored along with the name of server D <b>508</b>.

p-0063Server D <b>508</b> includes temporary storage <b>513</b>, which is a storage account. In <figref idrefs="DRAWINGS">FIG. 5B</figref>, party A <b>500</b> logs onto account A <b>506</b> on server D <b>508</b> and instructs server D <b>508</b> to place item A <b>504</b> into escrow, choosing escrow service C <b>511</b>. In response, server D <b>508</b> transfers item A <b>504</b> into temporary storage <b>513</b>. Server D <b>508</b> also generates retrieval tag <b>520</b> and sends this tag to escrow service C <b>511</b> as part of an escrow listing request. In response to receiving this request, listing A <b>522</b> appears in escrow account A <b>514</b> using a digital item descriptor, as described above. Party A <b>500</b> may choose to place additional items into escrow.

p-0064In a similar fashion, party B <b>502</b> may log onto account B <b>512</b> and request server <b>508</b> to transfer item B <b>510</b> into escrow. In response to such a request, server D <b>508</b> transfers item B <b>510</b> into temporary storage <b>513</b> in <figref idrefs="DRAWINGS">FIG. 5C</figref>. Temporary storage <b>513</b> is an example of a storage account. Server D <b>508</b> generates retrieval tag <b>524</b> and sends this retrieval tag to escrow service C <b>511</b> in a listing request. When escrow service C <b>511</b> receives the listing request, listing B <b>526</b> is created in escrow account B <b>518</b>. Party B <b>502</b> may chose to place additional unique digital items into escrow service C <b>511</b>.

p-0065In <figref idrefs="DRAWINGS">FIG. 5D</figref>, party A <b>500</b> logs onto escrow service C <b>511</b> and creates transaction E <b>528</b>. Party B <b>502</b> also logs onto escrow service C <b>511</b> and locates transaction E <b>528</b>. Transaction E <b>508</b> may be located in a number of different ways, such as searching for a transaction name provided by party A <b>500</b> or by searching for transactions that contain party A <b>500</b> on escrow service C <b>511</b>.

p-0066At this point, party A <b>500</b> and party B <b>502</b> may negotiate terms and may add and remove items that are part of transaction E <b>528</b>. For example, item A <b>504</b> and item B <b>510</b> may be items that are added to transaction E <b>528</b> by A <b>500</b> and party B <b>502</b>, respectively.

p-0067Transaction E <b>528</b> has different commitment states in these examples. In the unlocked state, party A <b>500</b> may freely add or remove items owned by party A <b>500</b> from transaction E <b>528</b>. Party B <b>504</b> may freely add or remove items owned by party B <b>504</b> from transaction E <b>528</b>. In these examples, a graphical user interface is used by party A <b>500</b> to lock one side of transaction E <b>528</b> at any time. Similarly, party B <b>502</b> may lock transaction E <b>500</b> at any time. With a partial lock, at least one, but not all parties have clicked “lock” on the graphical user interface. Any attempt to change the deal (add or remove items) will cause transaction E <b>528</b> to revert back to the unlocked state. In the locked state, all parties have clicked “lock”.

p-0068Thereafter, the “commit” button is enabled. Party A <b>500</b> and party B <b>502</b> may inspect transaction E <b>528</b> prior to committing the transaction. Party A <b>500</b> may click the “commit” button to commit one side of transaction E <b>528</b> at any time. Similarly, party B <b>502</b> may commit to transaction E <b>528</b> at any time. A partial commit state in transaction E <b>528</b> occurs when at least one, but not all parties have clicked the “commit” button on their screens. A committed state occurs for transaction E <b>528</b> when all of the parties have clicked the “commit” button. Transaction E <b>528</b> is attempted. If transaction E <b>528</b> completes, the parties receive a confirmation message and their accounts now contain the newly acquired items listed. If a problem occurs, an error message is displayed and the accounts still list the original (pre-trade) contents.

p-0069If an error occurs or all parties exit the transaction, no transaction occurs, and all parties retain their pre-trade listings in their escrow accounts. The listings in these accounts may be redeemed at any time for the unique digital items.

p-0070Assuming the transaction, transaction E <b>528</b>, between party A <b>500</b> and party B <b>502</b> reaches the committed state, escrow service C <b>511</b> transfers listing A <b>522</b> from escrow account A <b>514</b> into escrow account B <b>518</b>, as illustrated in <figref idrefs="DRAWINGS">FIG. 5E</figref>. Additionally, listing B <b>526</b> in escrow account B <b>518</b> is transferred into escrow account A <b>514</b>.

p-0071Party A <b>500</b> may then redeem or receive item B <b>510</b> from escrow in escrow service C <b>511</b> by designating a destination account, account A <b>506</b> on server D <b>508</b>. Escrow service C <b>511</b> sends a redemption request to server D <b>508</b>, which includes retrieval tag B <b>524</b> and an identification of account A <b>506</b>. In response, server D <b>508</b> transfers item B <b>510</b> into account A <b>506</b> as illustrated in <figref idrefs="DRAWINGS">FIG. 5F</figref> to illustrate a final state after redemption has occurred.

p-0072Similarly, party B <b>502</b> may then redeem or receive item B <b>504</b> from escrow in escrow service C <b>511</b> by indicating a destination account, account B <b>512</b> on server D <b>508</b>. Escrow service C <b>511</b> sends a redemption request to server D <b>508</b>, which includes retrieval tag A <b>520</b> and an identification of account A <b>506</b>. In response to receiving this request, server D <b>508</b> transfers item A <b>504</b> into account B <b>506</b>. Redemption occurs when item A <b>504</b> is moved into account B <b>506</b>. Once the redemption is done, the retrieval tag is invalidated on servers <b>508</b> and <b>511</b>. In other words, this tag may no longer be used for future redemption requests.

p-0073Thus, the example exchange illustrated in <figref idrefs="DRAWINGS">FIGS. 5A-5F</figref> demonstrates a mechanism for exchanging items in which items are placed into escrow prior to committing to the transactions. In particular, the use of a retrieval tag for unique digital items provides a way to identify unique digital items that are to be transferred using an trusted third-party service. Further, the example illustrated in <figref idrefs="DRAWINGS">FIGS. 5A-5F</figref>, transfer a unique digital item to an account of a first party in response to the transfer of another unique digital item to another party. Additionally, a transfer of the unique digital item to the account of the first party may occur through a payment of money or through a performance of a selected action. This action may be, for example, an execution of another transaction or a contract. In such a case, the performance may be verified through a confirmation by a trusted third party or by both parties indicating that the performance of this action has occurred. Further, fraud is prevented through the use of a trusted third-party and satisfaction of all parties is ensured by the ability to inspect the items prior to committing the trade.

p-0074Turning now to <figref idrefs="DRAWINGS">FIG. 6A-6E</figref>, diagrams illustrating an example of a lease transaction for a unique digital item are depicted in accordance with a preferred embodiment of the present invention. In this example, in <figref idrefs="DRAWINGS">FIG. 6A</figref>, party A <b>600</b> wishes to rent item B <b>602</b> in account B <b>604</b> on server <b>606</b> from party B <b>608</b> for a period of time using payment Al <b>610</b> and deposit A<b>2</b><b>612</b> in account A <b>614</b>. Temporary storage <b>616</b> is used to hold these items when a lease transaction is started between party A <b>600</b> and party B <b>608</b>. Server <b>606</b> is a storage server. Account A <b>614</b>, account B <b>604</b>, and temporary storage <b>616</b> are storage accounts in these examples.

p-0075Both parties agree on a trusted third-party, such as leasing service <b>618</b>. Leasing service <b>618</b> is a service similar to escrow service C <b>511</b> in <figref idrefs="DRAWINGS">FIG. 5</figref>. This service is a trusted third-party service. Both services may be implemented with software on a data processing system, such as data processing system <b>200</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>. In this example, party A <b>600</b> has set up lease account A <b>620</b> on leasing service <b>618</b>, while party B <b>608</b> has set up lease account B <b>622</b> on leasing service <b>618</b>. These lease accounts are trusted third-party accounts.

p-0076Party A <b>600</b> logs onto account A <b>614</b> on server <b>606</b> and instructs server <b>606</b> to make payment Al <b>610</b> and deposit A<b>2</b><b>612</b> available to leasing service <b>618</b>, which was selected by a list of valid services by party A <b>600</b>. In response to this instruction, server <b>606</b> moves payment A<b>1</b><b>610</b> and deposit A<b>2</b><b>612</b> into temporary storage <b>616</b>, as illustrated in <figref idrefs="DRAWINGS">FIG. 6B</figref>. Server <b>606</b> generates and sends retrieval tag A<b>1</b><b>624</b> and retrieval tag A<b>2</b><b>626</b> to leasing service <b>618</b>. These tags are part of a listing request in these examples. In response to receiving these retrieval tags, leasing service <b>618</b> generates listing A<b>1</b><b>628</b> and listing A<b>2</b><b>630</b> in lease account A <b>620</b>.

p-0077In a similar fashion, party B <b>608</b> logs onto account B <b>604</b> on server <b>606</b> and requests server <b>606</b> to make item B <b>602</b> available to leasing service <b>618</b>. As a result, server <b>606</b> transfers item B <b>602</b> from account B <b>604</b> to temporary storage <b>616</b>. Server <b>606</b> also generates return tag B <b>632</b> and sends this return tag in a listing request to leasing service <b>618</b>. In turn, leasing service <b>618</b> generates listing B <b>634</b> in lease account B <b>622</b>.

p-0078Party A <b>600</b> also logs onto leasing service <b>618</b> and creates contract <b>636</b>, as shown in <figref idrefs="DRAWINGS">FIG. 6B</figref>. Contract <b>636</b> can take many forms. In the depicted examples, this contract includes the name of the server holding the item or items being rented, a URL address for the Web service for the server holding the item or items, a name of the server holding the deposit, and a URL address for the Web service for the server holding the deposit.

p-0079Additionally, contract <b>636</b> also includes a contract ID number, an account ID for the lessor, an account ID for the lessee, retrieval tags for items being rented, a retrieval tag for the deposit, a retrieval tag for the payment, and contract terms and conditions. These conditions may include, for example, a time period or expiration date for the lease or rental, as well as terms detailing any sort of penalties for late or non-return of the item.

p-0080Party B <b>608</b> may find contract <b>636</b> on leasing service <b>618</b> by searching for a contract name provided by party A <b>600</b> or searching for contracts that contain party A <b>600</b> on leasing service <b>618</b>. At this point, party A <b>600</b> and party B <b>608</b> may negotiate terms and conditions for contract <b>636</b>. The terms and conditions may change depending on the negotiations. In this negotiation phase, contract <b>636</b> has a number of states. In the unlocked state, parties may freely change terms and conditions of the contract. A graphical user interface is used by party A <b>600</b> to lock one side of contract <b>636</b> at any time. In a similar fashion, party B <b>608</b> may lock contract <b>636</b> at any time. A partial lock state occurs when at least one, but not all parties, have selected the “lock” button. Any attempt to change the terms or conditions of contract <b>636</b> will change the state of contract <b>636</b> back to the unlocked state.

p-0081A locked state for contract <b>636</b> occurs when all of the parties in this example have selected the “lock” button on their screens. At this point, a “sign contract” button is enabled on the screens of all parties. At this point, the parties may inspect contract <b>636</b> prior to signing. Party A <b>600</b> may select the “sign contract” button to agree to the contract at any time. Party B <b>608</b> may perform similar actions. Contract <b>636</b> is in a partially signed state when at least one party, but not all parties have selected the “sign contract” button.

p-0082Contract <b>636</b> enters the signed state when all parties in this example have selected the “sign contract” button. At this point, the parties receive a confirmation message and their lease service accounts are updated to include listings of the newly acquired items. If a problem occurs in the process, an error message is presented to the parties, and the accounts continue to list the original contents. The contents also remain in the original accounts if all parties exit without signing contract <b>636</b>. In such a case, contract <b>636</b> is discarded and no exchange is made.

p-0083Assuming contract <b>636</b> reaches a signed state, leasing service <b>618</b> transfers listing B <b>634</b> from lease account B <b>622</b> to account A <b>620</b>, along with copy A <b>635</b> of contract <b>636</b>. Additionally, leasing service <b>618</b> transfers listing A<b>1</b><b>628</b> for payment A<b>1</b><b>610</b> into account B <b>622</b>, as well as copy B <b>637</b> of contract <b>636</b>. Party A <b>600</b> may then redeem or obtain item B <b>602</b> from leasing service <b>618</b>. Party A <b>600</b> indicates a destination account, account A <b>614</b> on server <b>606</b>.

p-0084Leasing service <b>618</b> then sends a redemption request to server <b>606</b> with retrieval tag B <b>632</b> and identification of account A <b>614</b>. In response to receiving this request, server <b>606</b> transfers item B <b>602</b> from temporary storage <b>616</b> into account A <b>614</b>, as shown in <figref idrefs="DRAWINGS">FIG. 6C</figref>. Party B <b>608</b> may redeem payment Al <b>610</b> from leasing service <b>618</b> by indicating a destination account, account B <b>604</b> on server <b>606</b>. In response, leasing service <b>618</b> sends a redemption request to server <b>606</b> in which the request includes retrieval tag B <b>632</b> and an identification of account B <b>604</b>. When this request is received by server <b>606</b>, payment Al <b>610</b> is moved into account B <b>604</b>, as illustrated in <figref idrefs="DRAWINGS">FIG. 6D</figref>. These redemption requests include the appropriate retrieval tags, as well as an identification of the destinations for the items associated with the tags.

p-0085At any time prior to the expiration, prior to the period of time for the lease, party A <b>600</b> may present item B <b>602</b> and copy A <b>635</b> of contract <b>636</b> to leasing service <b>618</b> and receive deposit <b>612</b>. In this instance, item B <b>602</b> is returned to account B <b>604</b> and party A <b>600</b> receives deposit A<b>2</b><b>612</b> in account A <b>614</b> in <figref idrefs="DRAWINGS">FIG. 6E</figref>. If party A <b>600</b> fails to return item B <b>602</b> prior to the expiration, party B <b>608</b> may present copy B <b>637</b> of contract <b>636</b> to leasing service <b>618</b> and receive all or some portion of deposit <b>612</b>. In this manner, a mechanism of the present invention provides a system for leasing unique digital items. This mechanism involves placing a deposit with a trusted third-party.

p-0086The examples illustrated in <figref idrefs="DRAWINGS">FIGS. 5A-5F</figref> and <figref idrefs="DRAWINGS">FIGS. 6A-6E</figref> depict transactions in which items and payments occur on the same server. These examples also may be applied to the generation of digital rights in which a digital right is a digital representation of a right to claim goods or services. For example, a digital right may be electronic coupons, loyalty points, or electronic gift certificates. The digital rights may be held by different issuing sources and may be exchanged between various parties holding those rights. The retrieval tags in these examples represent the unique digital items, which may take many forms, such as, for example, real estate in an online game, a character in an online game, or a digital right. Also, the examples depict exchanges and leases with two parties. These processes may be applied to larger numbers of parties than the two illustrated in the figures.

p-0087Further, the processes illustrated in these examples may be applied to transfers that occur over different servers. In the examples in <figref idrefs="DRAWINGS">FIGS. 5A-5F</figref>, it is not necessary for item A <b>504</b> and item B <b>510</b> to reside on the same storage server D <b>508</b>. If different storage servers are used in a transaction, each party has accounts for each storage server. A party may trade a listing on one storage server in exchange for a listing on a different storage server. The newly acquired listing is redeemed on its respective storage server.

p-0088Turning next to <figref idrefs="DRAWINGS">FIG. 7</figref>, a flowchart of a process for placing a unique digital item into escrow is depicted in accordance with a preferred embodiment of the present invention. The process illustrated in <figref idrefs="DRAWINGS">FIG. 7</figref> may be implemented in a server process, such as server process <b>402</b> in Web server <b>400</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>.

p-0089The process begins by receiving a request for digital escrow services from a client (step <b>700</b>). In response to receiving this request, a list of digital escrow services is obtained from UDDI directories (step <b>702</b>). This list is sent to the client (step <b>704</b>). A selection of a digital escrow service from the list is received from the client (step <b>706</b>). In response to receiving this selection, a WSDL Web service interface description is obtained for the selected service (step <b>708</b>). A connection is then established with the Web service (step <b>710</b>). In this example, the Web service is the selected digital escrow service identified by the client. This connection is a secure connection using a protocol, such as SSL.

p-0090After the connection has been established, a selection of a unique digital item for escrow is received from the client (step <b>711</b>). Then a retrieval tag is generated for the unique digital item and the tag is added to a list of active retrieval tags (step <b>712</b>). This retrieval tag is associated with the unique digital item and is used for transferring this item between accounts used for holding the unique digital item. The unique digital item is then transferred to a temporary storage account (step <b>714</b>).

p-0091A listing request is sent to the escrow service in which the listing request includes the retrieval tag (step <b>716</b>). Next, a determination is made as to whether additional unique digital items are to be escrowed (step <b>718</b>). If additional unique digital items are to be escrowed, the process returns to step <b>711</b> as described above. If no additional unique digital items are to be escrowed, then the process terminates thereafter.

p-0092Turning next to <figref idrefs="DRAWINGS">FIG. 8</figref>, flowchart of a process used in transferring a unique digital item to a trusted third-party is depicted in accordance with a preferred embodiment of the present invention. The process illustrated in <figref idrefs="DRAWINGS">FIG. 8</figref> may be implemented in a process such as trusted third-party server process <b>416</b> in escrow server <b>418</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>.

p-0093The process begins by receiving a listing request from a server (step <b>800</b>). This listing request includes a retrieval tag for a unique digital item that is to be escrowed. After this listing request is received, the data in the retrieval tag is authenticated (step <b>802</b>). The authentication is performed to ensure that the data actually sent from the server has not been altered or tampered. A digital signature is sent with the data. This authentication may be performed by comparing the digital signature with a published public key for the server from which the data was received.

p-0094A determination is made as to whether the data in the listing request is valid (step <b>804</b>). If the data is valid, the process then reads a storage account ID for the party from the retrieval tag (step <b>806</b>). A trusted third-party account is identified by searching for a trusted third-party account containing the storage account ID for the party (step <b>808</b>). After the account is found, the unique digital item is listed (step <b>810</b>) with the process terminating thereafter. The unique digital item may be listed such that the parties can examine or verify the item that has been escrowed. This listing is generated based on data received from the data on the unique digital item from the server back in step <b>800</b>. By listing the unique digital item, such that the item may be inspected, the chance of fraud is reduced using this mechanism in the present invention.

p-0095Turning back to step <b>804</b>, if the data in the listing request is not valid, an error is returned to the server (step <b>816</b>), with the process terminating thereafter.

p-0096With reference now to <figref idrefs="DRAWINGS">FIG. 9</figref>, a flowchart of a procedure by which a trusted third-party processes a transaction is depicted in accordance with a preferred embodiment of the present invention. The process illustrated in <figref idrefs="DRAWINGS">FIG. 9</figref> may be implemented in a trusted third party server, such as escrow <b>418</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>. This process is initiated when a transaction has reached a committed state, as described above.

p-0097The process begins by selecting an unprocessed listing and checks the digital item property type for the unprocessed listing (step <b>900</b>). Next, a determination is made as to whether the destination storage server account for the new owner exists (step <b>902</b>). If the destination storage server account exists, a determination is made as to whether additional unprocessed listings are present (step <b>904</b>). If additional unprocessed listings are present, the process returns to step <b>900</b> as described above.

p-0098Otherwise, a listing is selected and the listing is transferred to a trusted third party account for the recipient (step <b>906</b>). A temporary ownership transfer request is sent to the storage server for the unique digital item (step <b>908</b>). Thereafter, a determination is made as to whether additional listings are present for the transaction (step <b>910</b>). If additional listings are present for the transaction, the process returns to step <b>906</b> as described above. If, however, additional listings are not present, a determination is made as to whether the party, the new owner, has elected to receive the item (step <b>912</b>). If the party has elected to receive the listed item, a redemption request is processed for the party (step <b>914</b>).

p-0099Afterwards, a determination is made as to whether additional listed items have been received (step <b>916</b>). If additional listed items have been received, the process returns to step <b>912</b> as described above. Otherwise, the process terminates. With reference again to step <b>912</b>, if the party has not elected to receive the item, the process terminates.

p-0100Turning next to <figref idrefs="DRAWINGS">FIG. 10</figref>, a flowchart of a procedure by which a trusted third-party server processes a redemption request is depicted in accordance with a preferred embodiment of the present invention. The process illustrated in <figref idrefs="DRAWINGS">FIG. 10</figref> may be implemented in a trusted third party server.

p-0101The process begins by receiving a redemption request to redeem a listed item (step <b>1000</b>). A retrieval tag is looked up for the listing (step <b>1002</b>). The unique digital item is then transferred to the recipient's account (step <b>1004</b>).

p-0102Next, the recipient party's storage account ID is looked up from the party's trusted third party account ID (step <b>1006</b>). A redemption request is sent to the storage server Web service in which the request includes the retrieval tag and the storage account ID (step <b>1008</b>). A confirmation is received from the storage server (step <b>1010</b>), and the retrieval tag is destroyed (step <b>1012</b>) with the process terminating thereafter.

p-0103With reference next to <figref idrefs="DRAWINGS">FIG. 11</figref>, a flowchart of a process for returning a unique digital item is depicted in accordance with a preferred embodiment of the present invention. The process illustrated in <figref idrefs="DRAWINGS">FIG. 11</figref> may be implemented in a server, such as server process <b>402</b> in Web server <b>400</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>. In these examples, this process may be initiated when the original owner of the unique digital item changes his or her mind with respect to a transfer and desires to retrieve the unique digital item from escrow. This process may be initiated by the original owner if the transaction allowing transfer of the unique digital item to the recipient has not occurred.

p-0104The process begins by receiving a redemption request in which the redemption includes a retrieval tag and a recipient account ID (step <b>1100</b>). In this example, the recipient account ID is the account of the original owner of the unique digital item and is digitally signed. Thereafter, digital signature is authenticated (step <b>1102</b>). A determination is made as to whether the signature is valid (step <b>1104</b>). If the signature is valid, a determination is made as to whether the retrieval tag in the redemption request is in the list of active tags (step <b>1106</b>). If the retrieval tag is in the list, the retrieval tag is used to locate the unique digital item in the temporary storage (step <b>1108</b>). Thereafter, the unique digital item is transferred from the temporary storage account to the recipient account (step <b>1110</b>). After the unique digital item has been transferred, the retrieval tag is removed from the list of active retrieval tags (step <b>1112</b>), with the process terminating thereafter.

p-0105Turning back to step <b>1106</b>, if the retrieval tag is not on the list of active retrieval tags, an error is returned (step <b>1114</b>), with the process terminating thereafter. The process also returns an error in step <b>1114</b> if the signature is not valid in step <b>1104</b>.

p-0106With reference now to <figref idrefs="DRAWINGS">FIG. 12</figref>, a flowchart of a process by which a party may return a unique digital item that is leased is depicted in accordance with a preferred embodiment of the present invention. The process illustrated in <figref idrefs="DRAWINGS">FIG. 12</figref> may be implemented in a server, such as server process <b>402</b> in Web server <b>400</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>.

p-0107The process begins by receiving an initiation of a listing request from a storage server at the trusted third party server for return of the unique digital item (step <b>1200</b>). A determination is made as to whether additional items are to be returned (step <b>1202</b>). If additional items are to be returned, the process returns to step <b>1200</b> as described above. Otherwise, a selection of a copy of a contract containing the deposit is received (step <b>1204</b>). An indication is received from the party in which the indication indicates which of the party's listed items are to be returned with the contract (step <b>1206</b>).

p-0108The terms of the contract are then checked (step <b>1208</b>), and a determination is made as to whether the lease has not yet expired (step <b>1210</b>). If the lease has not yet expired, a determination is made as to whether the item fits return criterion (step <b>1212</b>). If the item fits the criterion, a determination is made as to whether the deposit is still available (step <b>1214</b>). If the deposit is not available, the process terminates.

p-0109Otherwise, the listing for the deposit is transferred to a party's trusted third party account (step <b>1216</b>). Then, listings for returned items are transferred to the lessor's trusted third party account (step <b>1218</b>). The contract is then destroyed (step <b>1220</b>).

p-0110Thereafter, a determination is made as to whether an election is received from the party to receive the deposit (step <b>1222</b>). If the party elects to receive the deposit, a redemption request is processed for the deposit, indicating the recipient storage server account for the party (step <b>1224</b>). Next, a determination is made as to whether the lessor elects to receive the returned items (step <b>1226</b>). If the lessor elects to receive the returned items, a redemption request is processed for the returned item in which the request includes an indication of the recipient storage server account for the lessor (step <b>1228</b>). Then, a determination is made as to whether the lessor is to receive additional returned items (step <b>1230</b>). If additional returned items are not to be received by the lessor, the process terminates.

p-0111With reference again to step <b>1226</b>, if the lessor does not elect to receive returned items, the process returns to step <b>1226</b>. The process terminates if the party does not elect to receive the deposit in step <b>1222</b>. With reference again to step <b>1212</b>, if the item does not fit return criterion, the process terminates. The process also terminates in step <b>1210</b> if the lease has not yet expired.

p-0112In <figref idrefs="DRAWINGS">FIG. 13</figref>, a flowchart of a process by which a party may request compensation for late return of a unique digital item that is leased is depicted in accordance with a preferred embodiment of the present invention. The process as illustrated in <figref idrefs="DRAWINGS">FIG. 13</figref> may be implemented in a server process, such as trusted third-party server process <b>416</b> in escrow server <b>418</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>.

p-0113The process begins by receiving selection of a copy of a contract containing the deposit from a party (step <b>1302</b>). After receiving a selection of the copy of the contract, a request is received from the party requesting compensation for the late return of the unique digital item (step <b>1304</b>). The terms of the contract are then checked (step <b>1306</b>).

p-0114Then, a determination is made as to whether the items have not yet been returned (step <b>1308</b>). If the unique digital items have been returned, a determination is made as to whether lease expiration criterion has been met (step <b>1310</b>). If the criterion has been met, a determination is made as to whether the requested compensation is allowed by the contract (step <b>1312</b>). If the requested compensation is allowed, then the compensation portion of the listing for the deposit is transferred to the party's trusted third party account (step <b>1314</b>).

p-0115Then, a determination is made as to whether the contract is complete (step <b>1316</b>). If the contract is complete, the contract is destroyed (step <b>1318</b>). Then a determination is made as to whether the party elects to receive the compensation (step <b>1320</b>). If the party elects to receive the compensation, a redemption request is processed for the compensation in which the redemption request includes an indication of the party's recipient storage server account (step <b>1322</b>) with the process terminating thereafter.

p-0116With reference again to step <b>1320</b>, if the party does not elect to receive the compensation, the process terminates. Turning back to step <b>1316</b>, if the contract is not complete, the process also terminates. With reference back to step <b>1312</b>, the process terminates if the requested compensation is not allowed by contract. Turning back to step <b>1310</b>, the process terminates if the lease expiration criterion has not been met. The process also terminates if the items have not been returned in step <b>1308</b>.

p-0117With reference again to step <b>1304</b>, if the unique digital item has not been returned, the process then terminates without returning the deposit. The process also terminates in step <b>1302</b> if the lease is not complete.

p-0118Turning next to <figref idrefs="DRAWINGS">FIG. 14</figref>, a flowchart of a process for conducting a temporary ownership transfer is depicted in accordance with a preferred embodiment of the present invention. The process illustrated in <figref idrefs="DRAWINGS">FIG. 14</figref>, may be implemented in a server process <b>402</b> in Web server <b>400</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>. This process may be initiated to automatically return a unique digital item at the end of a lease.

p-0119The process begins by receiving a temporary ownership transfer request at the storage server (step <b>1400</b>). The storage server generates a new retrieval tag in response to receiving the response (step <b>1402</b>). This retrieval tag is then sent back to the trusted third party server (step <b>1404</b>), with the process terminating thereafter.

p-0120In the depicted examples, the items are unique items that may be transferred between different realms. Items may be made unique in many different ways. For example, a unique digital item may be identified as unique based on a unique identifier associated with the item. The unique digital item may also have a unique digital signature.

p-0121Thus, the present invention provides a method, apparatus, and computer instructions for transferring digital property, such as unique digital items. These unique digital items may take various forms such as armors, rings, characters, and houses that exist on a server for a game or other application. The mechanism of the present invention provides an ability to transfer an item between parties or trade items between parties in a fashion that reduces the chance that a fraudulent transaction occurs. The mechanism allows for the placing of the unique item into a storage in which the unique item is held until conditions for releasing the item are met. The mechanism of the present invention employs the use of a tag, such as a retrieval tag or a lease tag, to facilitate the storing, locating, and transferring of the unique digital item. Additionally, the mechanism of the present invention may apply to exchanges or temporary ownership contracts involving more than two parties. Further, the number of items handled by the mechanism of the present invention may vary depending on the particular exchange.

p-0122Also, the items may be located on different servers from each other. For example, if two unique digital items are being exchanged, these two items may be located on separate Web servers. The exchange in this situation causes the two items to be moved to different servers. In a situation in which a unique digital item is moved from one server to another server, the unique digital item may be moved in a number of different ways. For example, a new instance of the unique digital item may be created on the target server to which the item is to be moved, with the original digital item being destroyed on the source server on which the unique digital item originated.

p-0123It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.

p-0124The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.