WO2002044843A2

WO2002044843A2 - Systems and methods for conducting electronic media transactions

Info

Publication number: WO2002044843A2
Application number: PCT/US2001/044360
Authority: WO
Inventors: Gregory Alan Bolcer; Tim Byars; Arthur Hughes Muir Iii
Original assignee: Endeavors Technology, Inc.
Priority date: 2000-11-28
Filing date: 2001-11-26
Publication date: 2002-06-06
Also published as: GB0314860D0; AU2002217897A1; GB2390452B; WO2002044843A3; WO2002044843A9; GB2390452A

Abstract

A method for receiving electronic media from a remote server over a network using a local server is provided. The remote server is contacted via the network, and electronic media available on the remote server is selected for a proposed transaction. A proposed transaction token is received from the remote server, and stored locally using the local server, the proposed transaction token identifying the electronic media and an owner location identifier associated with the owner of the electronic media. The local server obtains a payment authorization from a settlement house to submit payment to the owner of the electronic media, and upon obtaining the authorization, the local server submits a transaction request, including the payment authorization, to the remote server, and receives the electronic media from the remote server, Upon authorization of the transaction, the settlement house sends a notice or payment to the owner identified by the owner location identifier.

Description

SYSTEMS AND METHODS FOR CONDUCTING ELECTRONIC MEDIA

TRANSACTIONS

FIELD OF THE INVENTION

The present invention relates generally to electronic commerce, and more particularly to systems and methods for conducting transactions involving the purchase or exchange of electronic media over a computer network.

BACKGROUND

It has become increasingly popular to engage in electronic commerce, i.e., to purchase goods and servers over a network, such as the Internet, and particularly the World Wide Web. The network generally includes a large number of computers and computer networks that are interconnected through various communications links. A purchaser, using a Web browser or other interactive application on a client computer, may contact a vendor web site on a remote server computer system via the network. The server may send the client computer graphical web pages of information, which the browser may display for the purchaser on the client computer. For example, the web pages may include a catalog or other list of goods or services available for purchase from the vendor that the purchaser may review.

When the purchaser is interested in making a purchase, they may select one or more products from the web pages and add them to a virtual "shopping cart," which the server uses to identify the products of interest. When the purchaser is finished selecting products for purchase, the server may prompt the purchaser for information to complete the order. This may include the purchaser's name, payment information, generally a credit card, and shipping information.

Because of the sensitive nature of this personal information, particularly of credit card numbers and the like, there is concern with transmitting this information between the client computer and the server. The information may pass through various intermediate computer systems between the client computer and the server, and therefore may be intercepted by unscrupulous third parties. For this reason, encryption methods have been suggested that are intended to provide secure transmission of this information. There remains a risk, however, that the information may still be intercepted and decrypted by third parties. To minimize the transmission of this sensitive personal information, systems and methods have been suggested that allow a purchaser to submit this information in advance of purchases, such as that disclosed in U.S. Patent No. 5,960,411. A purchaser may submit their personal information, e.g., name, credit card number, shipping information and the like, to a vendor via the server, and the server may retain the information for future purchases. The purchaser may receive a customer identifier, which they may use to identify themselves whenever they contact the server to purchase products from the vendor. Thus, the purchaser need only submit their personal information a single time, and not with each purchase. Each time they place an order with the vendor, the server may use the customer identifier to locate the purchaser's stored personal information and complete the order.

One concern with this approach, however, is that it requires a purchaser to submit their personal information to each vendor with which they engage in electronic commerce. Thus, several vendors may retain this sensitive personal information, and the purchaser may lose substantial control of their infoπnation. Accordingly, systems and methods that facilitate the transfer, purchase, and/or exchange of electronic media over a network would be considered useful.

SUMMARY OF THE INVENTION The present invention is directed to systems and methods for conducting commercial transactions, preferably involving the purchase or exchange of electronic media, over a network.

In accordance with one aspect of the present invention, a method is provided for purchasing electronic media from a remote media server using a local server. The media server is contacted via the network, and electronic media is selected that is available from the media server for a proposed transaction. A proposed transaction token is received by the local server from the media server, and is stored by the local server, e.g., on a local device upon which the local server resides. The proposed transaction token preferably identifies the selected electronic media, and may also identify a price associated with the proposed transaction involving the selected electronic media. The local server may subsequently be instructed to order the proposed transaction, whereby the local server may automatically submit a transaction request to the media server, and/or a transaction notice intended for the owner of the selected electronic media. Preferably, the transaction notice includes submitting a payment request to a settlement house via the network. The payment request preferably includes an owner identifier, identifying a location for contacting the owner of the selected electronic media. For example, the settlement house may submit notice of the proposed transaction to the location identified by the owner identifier upon approval of the payment request. The owner identifier may be the location of the media server or a different location accessible via the network. Upon confirmation of the payment request, the settlement house may transfer a payment token to the local server, and the local server may then submit the payment token to the media server as part of the transaction request. The media server may verify the authenticity of the payment token, and then may transfer an electronic guarantee token to the local server, the guarantee token authorizing completion of the proposed transaction. The guarantee token may subsequently be submitted to the media server, and a copy of the selected electronic media may be received from the media server. The guarantee token may allow a single copy of the selected electronic media to be received, or multiple copies, depending upon the terms of the proposed transaction. Preferably, the guarantee token is destroyed upon completion of the proposed transaction, e.g., when the selected electronic media is received from the media server. In a further embodiment of the present invention, the guarantee token may be transferred to another computing device via the network or may be delivered to another computing device than that used to initiate the transaction request, whereby the other computing device may use the guarantee token to complete the proposed transaction. In accordance with another aspect of the present invention, a method for receiving electronic media from a remote server over a network using a local server is provided. The remote server may have electronic media stored thereon that is owned by an owner having a contact location accessible via the network. The remote server may be contacted via the network, and electronic media available on the remote server may be selected for a proposed transaction. An electronic proposed transaction token may be received from the remote server, and stored locally using the local server. Preferably, the proposed transaction token identifies the selected electronic media, and the contact location for the owner of the selected electronic media. The local server may then be instructed to complete the proposed transaction, whereby the local server may automatically obtain a payment authorization to submit payment to the owner of the selected electronic media for the proposed transaction. For example, the local server may submit a payment request, including the owner contact location, to a settlement house, similar to the method described above. Upon authorization of the payment request, the settlement house may forward payment or a notice to the owner contact location. The settlement house may also submit a payment token to the local server once the authorization is approved or upon confirmation from the owner contact location. Upon obtaining the payment authorization, e.g., the payment token from the settlement house, the local server may submit a transaction request to the remote server, and receive the electronic media from the remote server.

Other objects and features of the present invention will become apparent from consideration of the following description taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic drawing, showing a network architecture, according to the present invention.

FIG. 2 is a schematic diagram of a computing device including a local server, in accordance with the present invention. FIG. 3 is a block diagram showing an exemplary computer system in which certain elements and functionality of the present invention may be implemented.

FIG. 4 is a flowchart showing a first method for purchasing electronic media from a content distributor, in accordance with the present invention. FIG. 5 is a flowchart showing a second method for purchasing electronic media in a peer-to-peer framework, in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Before describing exemplary systems and methods embodying aspects of the present invention, the following definitions are established.

"Owner" as used herein includes any person, enterprise, or other entity having a proprietary interest in electronic media, such as a copyright owner having a copyright interest in the electronic media, whether registered or unregistered, a manufacturer or developer who created the electronic media, or a licensee or agent authorized to act on behalf of or in a similar capacity to a copyright owner, manufacturer, or developer. Owner generally does not include a third party user of the electronic media, such as a peer user, who may be in possession of copies of electronic media and/or may be involved in a transaction involving the electronic media.

"Electronic media" as used herein includes any media that may be transferred electronically, e.g., over a network such as the Internet, including audio files, such as music files; video files; image files; software files, including application and data files; game files, such as read-only-memory ("ROM") files; and other similar computer resources.

"Token" as used herein includes an electronic signature or other electronic guarantee that may be transferred electronically and that may authenticate the identity of a party generating the token and/or authorize an action or response by a server receiving the token. The token may take the form of a data file or an executable file, which is configured for use only by the server receiving the file. Preferably, the token includes an authentication parameter that may be used by the receiving server to confirm the identity of the party generating the token. The token may include additional information relating to a transaction, such as one or more of the following: a product identifier, identifying the subject matter of the transaction, e.g., specific electronic media; a price, payment amount, or royalty value; an authorization, e.g., to send or receive a payment; an identifier identifying a party to the transaction, or a location, such as an URL or other URI, related to a party, and the like. Alternatively, the information may be programmatically derived from the token, e.g., using algorithms or encryption methods, as will be appreciated by those skilled in the art. Further explanation of tokens, in accordance with the present invention is provided with reference to the exemplary embodiments described below.

Turning now to the drawings, FIG. 1 shows an example of a network architecture, according to an embodiment of the present invention. Devices 10, 20, 30, . . . n are connected to a network 40, and a cache server 50 and a media server 60 are also connected to the network 40. In one embodiment, the network 40 may be a wide area network ("WAN"), a local area network ("LAN"), an intranet, a wireless network, a short messaging service ("SMS"), or a telephony network. Preferably, the network 40 may incorporate several different types of networks including, but not limited to, a WAN, a LAN, and/or a wireless network. For example, one such network including multiple different types of networks is the Internet.

The cache server 50 may be a computer system including an index or other searchable database. For example, the cache server 50 may include a specialized search engine, including a crawler, indexer, and query engine (not shown) for indexing, searching, and/or sharing electronic media among a plurality of subscribers of a shared- resource network. The crawler, similar to a browser, may contact computer systems maintained by the subscribers via the network 40 to access desired resources available on the systems, e.g., electronic media. The crawler may extract information from the electronic media and submit the information to the indexer, which may construct an index of the electronic media uncovered by the crawler. The query engine is an application employed by the subscribers or other requestors to search the index constructed by the indexer, e.g., to return links to candidate electronic media, i.e., accessible via the subscribers' systems, in response to query keywords and/or other criteria provided by the users. Alternatively, the cache server 50 may include a general purpose search engine, such as those used to search the Internet, as will be appreciated by those skilled in the art.

The media server 60 is a computer system capable of storing and/or serving up resources, such as electronic media. In one embodiment, the media server 60 may be a centralized archive or repository for electronic media 62. For example, the media server 60 may be a server operated by an owner (or owners) of electronic media, such as a music company, a software developer, or other enterprise that produces, develops, manufactures, owns, or otherwise generates electronic media. Alternatively, the media server 60 may access electronic media from a plurality of sources, e.g., accessible by the media server 60 via the network. For example, the media server 60 may include a plurality of servers connected to one another in a shared-resource network. Each server may be independently created, operated, and/or maintained by a peer user, subscriber, member, or other user of the shared-resource network.

In one embodiment, the cache server 50 and the media server 60 may be connected to one another. The cache server 50 may include a searchable database that includes an index of the electronic media stored on or accessible by the media server 60. The cache server 50 may include a query engine for searching the database or for directing queries at the media server 60, e.g., to search for electronic media on the media server 60 that satisfies the criteria of the queries. Alternatively, the database may be accessed using external search engines, such as those available for searching the Internet, or other methods known to those skilled in the art.

Turning to FIG. 2, each of the devices 10-n connected to the network 40 preferably is a computing device, such as a personal computer, a laptop, a wireless access protocol ("WAP") telephone, or other electronic device capable of receiving, storing, transmitting, and/or playing electronic media. Alternatively, the computing device may include special purpose electronic devices, such as those identified below, or electronic devices including embedded computer chips or similar hardware components, such as stereo systems, video systems, or other appliances. The devices 10-n generally include a local server 12, memory 14, and a communication interface 16. In a preferred embodiment, the local server 12 is a specialized, resource-conservative, embedded server, e.g., an HTTP web server. The local server 12 may be relatively small compared to conventional servers, such that it may be installed on virtually any electromc or computing device, including personal devices such as personal digital assistants (e.g., Palm Pilots), WAP phones, media players, or embedded micro-controllers, yet it may provide all of the services needed to securely engage in online transactions, e.g., involving the transfer of electronic media. The term "local server" is used generally herein to refer to such an embedded web server, or any combination of hardware-based components and/or software-based modules that may perform the features described herein. The teπn "thin server" may also be used to refer to the local server 12, because of its relatively small size compared to conventional servers.

Turning to Fig. 3, a block diagram illustrates an exemplary computer system 350 in which elements and functionality of the present invention may be implemented, e.g., for the devices 10-n and/or the media server 60 of FIG. 1. The system 350 includes one or more processors, such as processor 352. The processor 352 is connected to a communication bus 354. The communication bus 354 may include a data channel for facilitating information transfer between storage and other peripheral components of the system 350.

The system 350 also includes main memory 356 and may include secondary memory 358. The main memory 356 provides storage of instructions and data for programs executing on the processor 352. The main memory 356 may be semiconductor- based memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), and the like, as well as read only memory (ROM). The secondary memory 358 may include a hard disk drive 360 and/or a removable storage drive 362, for example a floppy disk drive, a magnetic tape drive, an optical disk drive, and the like. The removable storage drive 362 may read from and write to a removable storage unit 364 in a well-known manner.

The system 350 also includes a communication interface 374. Communication interface 374 allows software and data to be transferred between the system 350 and external devices, networks, or information sources. Examples of communication interface 374 include but are not limited to a modem, a network interface (for example an Ethernet card), a communications port, a PCMCIA slot and card, an infrared interface, a wireless interface, such as those using the Bluetooth standard, and the like.

The term "computer program product" is used to refer to any medium used to provide programming instructions to the system 350. Examples of certain media include removable storage units 364 and 372, a hard disk installed in hard disk drive 360, and signals 378. Thus, a computer program product may be a means for providing programming instructions to the system 350.

Turning to FIG. 4, an exemplary method is shown for purchasing electronic media 113 from a remote media server 112 over a network (not shown) using a local server 111, in accordance with the present invention. Generally, the local server 111 is resident on a local computing device, identified as local device or "Client 1" 110, which may be any of the computing devices described above. The media server is identified as "Content Distributor" 112, which may be a web server operated, for example, by an owner or vendor of electronic media. The media server 112 provides access to electronic media 113 owned by one or more respective owners, preferably in an archive, repository, or memory within the media server 112.

As an initial step, a user of the local device 110 initiates a search for electronic media at step 120. The user may direct the local device 110 to use a browser or other application to contact the cache server 114, and submit a query. The query may include keywords or other criteria to find electronic media of interest, for example, the names of songs, albums, movies, artists, actors, producers, directors, game titles, manufacturers, developers, and the like.

The cache server 114 may search its index 115 for matches to the query criteria, and return a response at step 122 to the local device 110 that may include a list of one or more electronic media that best match the query criteria. For example, the index 115 may include titles, names, or metadata associated with respective electronic media. Preferably, the response includes one or more location identifiers, e.g., an Uniform Resource Identifier ("URI"), such as an Uniform Resource Location ("URL"). The URI may identify the location(s) via the network where the matched electronic media may be found, or may identify a process for identifying the location, e.g., to identify a portable device that may be located at one or more different locations. In addition, the response may include a title of the matched electronic media, a name of a source associated with the location identifier, a price, details on a proposed transaction, e.g., an electronic transfer of a copy of the electronic media, and the like. Depending upon the resources available to the cache server 114, the response may include multiple entries for a particular electronic media, for example, indicating that the electronic media is available from multiple sources. For example, the location identifier may identify a media server that is directly connected to or otherwise associated with the cache server 114. Alternatively, or in addition, the location identifier may identify a web site operated by an official source, e.g., the owner of the identified electronic media or the owner's authorized distributor. In a further alternative, the location identifier may identify second party sources, such as fellow subscribers to a shared-resource network, as described further below with respect to FIG. 5. Media server 112 is intended to represent any of these possible media servers, which may be available via the network. Returning to FIG. 4, at step 124, the local device 110 may contact the media server

112 via the network. For example, the user of the local device 110 may simply select one of the location identifiers returned in the response to the user's query, and the browser may automatically comiect the local device 110 to the media server 112 via the network. In an alternative embodiment, the user may contact the media server 112 directly without using the cache server 114, e.g., if they already know that they are interested in electronic media available from the media server 112.

The user may then select one or more electronic media available from the media server 112 for a proposed transaction. Generally, the proposed transaction involves the transfer of one or more copies of selected electronic media. When particular electronic media is selected, the local device 110 may receive a proposed transaction token from the media server 112. The proposed transaction token is preferably stored by the local server 111 on the local device 110, e.g., within memory (not shown) of the local device 110. Preferably, the electronic media may be selected by a simple "drag and drop" method, such as that disclosed in application Serial No. 09/724,660, entitled "Systems and Methods for Ordering Products Over a Network," filed on the same day with the present application (attorney docket 256/227), the disclosure of which is expressly incorporated herein by reference. In this embodiment, an icon representing the electronic media of interest may be selected, whereupon metadata identifying the proposed transaction involving the selected electronic media may be transferred to the local device 110. Thus, the file containing the metadata may constitute the proposed transaction token.

The proposed transaction token includes embedded information that identifies the selected electronic media, and may include additional information. For example, the token may include a source identifier, e.g., an URL associated with the media server 112 and/or the location of the electronic media within the archive 113 of the media server 112, a price for the proposed transaction involving the selected electronic media, a description of the selected electronic media, and the like. Preferably, the proposed transaction token also includes information on the type of proposed transaction, for example, specifying that the proposed transaction involves a single download of the selected electronic media, a specific number of downloads, or unlimited access. The proposed transaction may also be set to expire on a specific expiration date, and an expiration parameter may be embedded in the proposed transaction token.

The user of the local device 110 may at any time decide to delete the proposed transaction token if the user is no longer interested in the selected electronic media. Alternatively, the user may initiate the proposed transaction simply by instructing the local server on the local device 110. Because the proposed transaction token is stored on the local device 110, the user does not need to subsequently access the media server 112 or the network directly in order to complete the proposed transaction. For example, while "offline," the user may instruct the local server 111 to order a proposed transaction that is represented by a proposed transaction token stored by the local server 111 on the local device 110.

In response to this instruction, the local server 111 automatically undertakes all of the actions necessary to purchase or otherwise complete the proposed transaction, preferably without any further action by the user. This is an important feature of the present application because it enables a user to maintain local control .over a proposed transaction using their local server. Rather than having to contact a vendor's web site via the network, and submit information while online, the local server 111 may proceed substantially silently in the background while the user completes other tasks. In addition, because the local server 111 controls the proposed transaction, the transaction may be completed in a substantially secure manner, thereby substantially minimizing the risk of uncontrolled release of sensitive user information or fraud.

Preferably, when instructed to purchase and/or complete a proposed transaction identified by a selected proposed transaction token, the local server 111 automatically submits a transaction request to the media server 112. As an initial step, the local server 111 may obtain payment authorization for the proposed transaction. For example, the local server 111 may extract a price or payment value from the proposed transaction token and submit a request to a settlement house 116, as indicated by step 128. Preferably, the local server 111 submits the proposed transaction token to the settlement house 116 so that the settlement house 116 may extract information from the token to uniquely and securely identify the proposed transaction and/or the parties involved. For example, the proposed transaction token may identify the location of the media server 112 or other destination to which payment should be sent.

The settlement house 116 may be any known scheme established for settling payments via the network. For example, the settlement house 116 may use an electronic "wallet" system to automatically process the payment request, although alternatively, the payment request may be sent via a telephony network, e.g., to a fax machine, where all or part of the approval process may be completed manually or electronically.

The settlement house 116 may include prepaid accounts in which users retain funds against which they may draw when conducting transactions. Alternatively, the settlement house 116 may use a billing mechanism that periodically bills users for their purchased transactions, e.g., adding the transactions to the users' telephone or other utility bills.

Alternatively, the settlement house 116 may be a credit card company, banking institution, or other conventional creditor. Because the payment involved in electronic media transactions may be relatively small, conventional modes of payment, such as credit cards, may be inefficient, and therefore micro-payment schemes, such as charging against prepaid accounts or billing mechanisms, such as adding charges to a utility bill, such as a telephone, gas, or electric bill as described above, are presently preferred. In a further alternative, the payments may paid in several installments, e.g., at the time of each transfer of a copy of the electronic media (for multiple copy transactions), or based upon a predetermined payment schedule. The settlement house 116 may confirm the identity of the local server 111 using any known authentication method, and confirm that the user associated with the local server 111 has the funds available or is otherwise in good standing. If this verification is positive, the settlement house 116 may then submit a payment token at step 130 back to the local server 111. The payment token includes an authentication parameter confirming that the user has the ability to pay for the proposed transaction, and may also include the information contained in the proposed transaction token. Alternatively, the payment token may be linked to the proposed transaction token, for example, by the local server 111.

When the local server 111 receives the payment token, the local server 111 may then automatically contact the media server 112 and submit the payment token as part of the transaction request at step 132. The media server 112 may then process the transaction request, e.g., to verify the authenticity of the payment token. For example, the media server 112 may contact the settlement house 116 at step 134, e.g., submitting the payment token to confirm that the payment token is valid. The settlement house 116 may confirm the validity of the payment token, and send a verification response at step 136 back to the media server 112. Optionally, at this point, the settlement house 116 may also submit payment to the media server 112 electronically, as indicated by step 138, although the payment step may also be completed later, either electronically or using conventional payment methods.

Alternatively, the media server 112 and the local server 111 may exchange an authentication protocol that satisfies the media server 112 of the validity of the payment token without having to contact the settlement house 116 for verification. In this embodiment, the media server 112 may subsequently contact the settlement house 116 to request payment, e.g., by submitting the payment token.

In a further alternative, the media server 112 may have approved settlement houses with which it has established relationships. The list of approved settlement houses may be included in the proposed transaction token that is transferred to the local server 111 when the user first selects the electronic media associated with the proposed transaction token. The local server 111 may then consult a list of available settlement houses stored on the local device 110 and search for a match between each of the lists. If a match exists, possibly based upon a preferred ranking of settlement houses previously established by the user of the local device 110, the local server 111 may obtain a payment token from the matched settlement house, similar to the method described above. This payment token may be submitted to the media server 112, thereby possibly eliminating the need for the verification steps. In still a further alternative, the local server 111 may access a list of approved settlement houses when it contacts the media server at step 132, i.e., submits the transaction request. The local server 111 may search for a match between this list and a list of available settlement houses on the local device 110. If a match is found, the local server 111 may securely submit information regarding the matched settlement house to the media server 112, e.g., an account number, credit card number, and the like. This alternative may avoid the need for the local server 111 to obtain a payment token and/or for the media server 112 to obtain verification from the settlement house, although these steps may still be included as a precaution against fraud.

Once payment has been authorized, confirmed, and/or completed, the media server 112 preferably transmits an electronic guarantee token to the local server 111 at step 140. The local server 111 receives the guarantee token from the media server 112 and stores it on the local device 110. The guarantee token preferably includes an electronic guarantee authorizing completion of the proposed transaction. Preferably, the guarantee token identifies the associated electronic media, and the local server 111. At any time subsequent to receiving the guarantee token, the local server 111 may submit the guarantee token to the media server 112, whereupon the media server 112 may transfer a copy of the selected electronic media to the local device 110. If the proposed transaction is a single download of the selected electronic media, the elecfronic guarantee token is preferably destroyed or otherwise deactivated when the selected electronic media is received from the media server, i.e., upon completion of the transfer. Alternatively, if the proposed transaction allows the user to receive multiple copies of the selected electronic media, the electronic guarantee token may also include an embedded counter representing the number of authorized copies. Each time a copy of the electronic media is successfully downloaded, the counter may be reduced, and the guarantee token may be destroyed when the counter is reduced to zero. As another alternative, a new "decremental" token may issued when a copy of the elecfronic media is downloaded, and the old token may be destroyed. The decremental token may be similar to the original guarantee token, except that it may identify the number of remaining copies available under the purchased transaction. In a further alternative, the proposed transaction may authorize the user to have unlimited access to the associated electronic media until an expiration date. The guarantee token may then include an embedded expiration parameter identifying the expiration date. This transaction structure may be particularly useful for accessing interactive game files and the like. Upon reaching the expiration date, the guarantee token may be automatically destroyed. Alternatively, if an expired guarantee token is submitted to the media server 111, the media server 111 may confirm the expiration date and refuse to authorize a transfer of the associated electronic media if the expiration data has been exceeded.

Alternatively, rather than transferring an electronic guarantee token upon authorization of payment, the media server 112 may simply transfer a copy of the electronic media to the local device 110 upon confirmation of payment. Transfer of a guarantee token, however, may be preferred because it provides additional control for the user. For example, when a guarantee token is submitted to the media server 111, transfer of the associated electronic media to the local device 110 may be interrupted or otherwise incomplete, for example, due to a failure of the connection via the network. If this occurs, the local server 111 may simply contact the media server 112 again and resubmit the guarantee token, since the guarantee token is not destroyed until completion of the transfer.

In addition, use of a guarantee token allows the user or their local server 111 to control when transfer of the electronic media occurs. For example, the user may preprogram or otherwise instruct the local server 111 to engage in such transfers at predetermined times. Thus, the local server 111 may use the resources of the local device 110 to complete the transfer only when the resources are not needed for other tasks or when the transfer is unlikely to interfere with use of or slow down operation of the local device 110. In addition, a guarantee token may allow the proposed transaction to be transferable. For example, the user of the local device 110 may want to transfer the guarantee token to a third party (not shown), e.g., as a gift. The local server 111 may include a list of "buddies," i.e., other devices or users with which the local device 110 may share resources. The user may instruct the local server 111 to transfer the guarantee token to one of these other devices. These other devices must be compatible with the local server and/or the protocol of the guarantee token preferably including a thin server similar to the local server 111. For example, the user may use a graphical user interface to move an icon representing the guarantee token from their local server to a desired device or user, similar to the "drag and drop" mechanism described in the co-pending application incorporated above. When a guarantee token is selected for transfer, the local server 111 may contact the identified recipient, and substantially securely transfer the guarantee token. Alternatively, when a guarantee token is selected for transfer, the local server 111 may contact an intermediate server, such as the settlement house or vendor server described above. The guarantee token received by the local server 111 may be surrendered and a new guarantee token may be generated that may be uniquely usable by the intended recipient's server.

In an further alternative, a similar method may be utilized to purchase guarantee tokens or electronic media using a local server for transfer to a remote device, as will be appreciated by those skilled in the art. For example, a user may order a transaction to obtain one or more copies of elecfronic media using a portable device, but may request that the guarantee token be sent to a remote player or other computing device, for example, located at the user's home or office or belonging to a third party, that may be capable of using the electronic media. The remote device may include its own local server that may receive the guarantee token and/or automatically complete the transfer of the electronic media, e.g. using the methods described herein. Turning to FIG. 5, another preferred method is shown for transferring electronic media 213 over a network (not shown) using a local server 211, preferably between peer users using compatible servers. Generally, the local server 211 is resident on a local computing device, identified as local device or "Client 1" 210, which may be any of the computing devices described above. The remote device, identified as "Client 2" 212, includes one more electronic media 213 stored on the device 212, which may also be any of the computing devices described above. In a preferred embodiment, the users of the local and remote devices 210, 212 are both members of a shared-resource network, which allows members to share resources, such as electronic media, available on the respective members' devices. Generally, the electronic media 213 stored on the remote device 212 is owned by third parties, as illustrated by the exemplary "Content Distributor" or owner site 218.

As an initial step, a user of the local device 210 may initiate a search for electronic media at step 220. The user may direct the local device 210 to use a browser or other application to contact the cache server 214, and submit a query. In one embodiment, the cache server 214 may be a central search engine maintained and operated by a shared- resource network of which the user is a member. The query may include keywords or other criteria to find electronic media of interest, for example, the names of songs, albums, movies, artists, actors, producers, directors, game titles, manufacturers, developers, and the like.

The cache server 214 may periodically contact each of the members' devices to index the resources available for sharing. For example, the cache server 214 may include a conventional crawler (not shown), as will be appreciated by those skilled in the art. Alternatively, each of the members' devices may include a resident indexing agent (not shown) that may push indexing data to the cache server, such as that disclosed in U.S. application Serial No. 09/712,428, filed November 13, 2000, entitled "Systems and Methods for Indexing Data in a Network Environment" (attorney docket 256/123), the disclosure of which is expressly incorporated herein by reference.

After searching the index 215, the cache server 214 may return a response to the query at step 222 that may include a list of one or more electronic media satisfying the query. Preferably, the response includes one or more location identifiers identifying the location(s) via the network where the electronic media may be found, e.g., URLs or other URIs identifying other members' servers in the shared-resource network having copies of electronic media satisfying the query. In addition, the response may include a title of the electronic media, a name of the owner of the electronic media, a price, details on a proposed transaction, e.g., an electronic transfer of a copy of the electronic media, and the like.

At step 124, the local device 210 may contact the remote device 212 via the network. For example, the user of the local device 210 may simply select one of the location identifiers returned in the response to the user's query, and the browser may automatically connect the local device 210 to the remote device 212 identified by the location identifier. In an alternative embodiment, the user may contact the remote device 212 directly without using the cache server 214. For example, the user of the local device 210 may have received a notice from the user of the remote device 212 that particular electronic media is available from the remote device 212. Alternatively, the user of the local device 210 may post an interest in particular electronic media, e.g., using a BBS system available via the shared-resource network or otherwise, and receive responses to their posting from one or more remote devices.

The user may then select one or more electronic media available from the remote device 212 for a proposed transaction. Similar to the previous embodiment, the proposed transaction generally involves the transfer of one or more copies of the selected electronic media. When particular electronic media are selected, the local device 210 may receive a proposed transaction token from the remote device 212. The proposed transaction token is preferably stored by the local server 211 on the local device 210, e.g., within memory (not shown) of the local device 210. Preferably, the electronic media may be selected by a simple "drag and drop" action, as described above.

The proposed transaction token includes embedded or attached information that identifies the selected electronic media, and may include additional information. For example, the token may include a source identifier, e.g., an URI associated with the remote device 212 and/or the location of the elecfronic media within the archive 213 of the remote device 212, a price for the proposed transaction involving the selected electronic media, a description of the selected elecfronic media, an owner contact identifier identifying a location for contacting the owner of the selected elecfronic media, and the like. Preferably, the proposed transaction token includes information on the proposed transaction, for example, specifying that the proposed transaction involves a single download of the selected electronic media, a specific number of downloads, or unlimited access, as described above.

The user of the local device 210 may at any time decide to delete the proposed transaction token if the user is no longer interested in the selected elecfronic media. Alternatively, the user may initiate the proposed transaction simply by instructing the local server 211 on the local device 210. In a further alternative, the user of the local device 210 may instruct the local server 211 to initiate ordering the proposed transaction directly, i.e., without first receiving a proposed transaction token and transmitting it back to the remote device 212. Because the proposed transaction token is stored on the local device 210, the user does not need to subsequently access the remote device 212 or the network directly in order to complete the proposed transaction. For example, while "offline," the user may instruct the local server 211 to order a proposed transaction that is represented by a proposed transaction token stored by the local server 211 on the local device 210. In response to this instruction, the local server 211 may automatically undertake all of the actions necessary to purchase or otherwise complete the proposed transaction, preferably without any further action by the user. As explained above, this transaction structure may enable a user to maintain local control over a proposed transaction using their local server. Rather than having to contact a vendor's web site via the network and submit information while online, the local server 211 may proceed substantially silently in the background, e.g., while the local device 210 is used by the user for other tasks.

Preferably, when instructed to purchase and/or complete a proposed transaction identified by a selected proposed transaction token, the local server 211 automatically submits a transaction request to the remote device 212. As an initial step, the local server 211 may first obtain payment authorization for the proposed transaction, as indicated by steps 228, 230. For example, at step 228, the local server 211 may extract a price or payment value from the proposed transaction token and submit a payment request including this value to a settlement house 216, which may involve any of the settlement procedures described above. Preferably, the local server 211 submits the proposed transaction token to the settlement house 216 so that the settlement house 216 may extract information from the token to uniquely and securely identify the proposed transaction, the parties involved, and/or the price or payment value.

For example, the proposed transaction token may identify the local device 210, the remote device 212, and the owner of the selected electronic media, preferably by their locations, e.g., URLs, or other unique identifiers, such as URIs. The settlement house 216 may confirm the identity of the local server 211 using any known authentication method, and confirm that the user associated with the local server 211 has sufficient funds available, is credit- worthy, or is otherwise in good standing. If this verification is positive, the settlement house 216 may then submit a payment token at step 230 back to the local server 211. The payment token may include an authentication parameter confirming that the user has the ability to pay for the proposed transaction, and may also include the information contained in the proposed transaction token. Alternatively, the payment token may be linked to or added to the proposed transaction token, which may then be returned to the local server 211.

The owner contact identifier may be used by the settlement house 216 to send a notice and/or payment to the owner of the selected electronic media at step 238. For example, once the authorization to pay for the transaction has been confirmed, the settlement house 216 may send a notice identifying the selected electronic media, and a payment or royalty value. Thus, by submitting the proposed transaction token to the settlement house 216,the local server 211 may effectively send a notice intended for the owner of the elecfronic media.

In addition, an actual payment may be sent to the owner site 218, either electronically as part of step 238 or separately, e.g., using conventional payment methods. The payment to the owner may be all of the payment value associated with the proposed fransaction, or it may be a lesser value, e.g., a royalty payment. If the settlement house 216 handles many transactions involving electronic media owned by a respective owner, the settlement house 216 may compile the payments, and periodically submit a total payment to the owner, as will be appreciated by those skilled in the art. In a further alternative, the owner may not require any payment and may instead only require a notice. Thus, the settlement house 216, the local server 210, or even the remote server 212 may send the required notice to the location 218 identified by the owner contact identifier. In still another alternative, the settlement house 216 may send a payment to the owner site 218 and not to the remote device 212. Optionally, the owner may send a commission or other payment to the remote device 212, may credit an account, or may have other financial arrangements with the user of the remote device 212.

In a preferred embodiment, the notice sent to the owner site 218 at step 238 is substantially anonymous. For example, the notice may identify the electronic media involved and the terms of a particular transaction, but may withhold the identity of the parties to the transaction. This may maintain a level of autonomy and/or anonymity desired by the users of either or both the local device 210 and the remote device 212.

In an alternative embodiment, upon receiving the payment token, the local server 211 may extract the owner location identifier directly from the proposed fransaction token and automatically transmit a notice to the owner site 218, including information as described above. This alternative may be less desirable, however, than using an intermediary, such as the settlement house 216, since it may allow the owner to identify the local device 210.

Next, when the local server 211 receives the payment token, the local server 211 may then automatically contact the remote device 212 and submit the payment token as part of the transaction request at step 232. The remote device 212 may then process the transaction request, e.g., to verify the authenticity of the payment token. The remote device 212 may also include a resident thin server (not shown) similar to and compatible with the local server 211, e.g., to provide a secure method of communication between the local and remote devices 210, 212. For example, the remote device 212, e.g., using its thin server, may contact the settlement house 216 at step 234, e.g., submitting the payment token to confirm that the payment token is valid. The settlement house 216 may confirm the validity of the payment token, and send a verification response at step 236 back to the remote device 212.

The settlement house 216 may submit a payment to the remote device 212, may credit an account maintained by the settlement house 216 on behalf of the user of the remote device 212, and the like. Optionally, the settlement house 216 may also submit payment to the owner site 218, as indicated by step 238, although the payment step may also be completed later, either electronically or using conventional payment methods, as described above. Alternatively, the remote device 212 and the local server 211 may exchange an authentication protocol that satisfies the remote device 212 of the validity of the payment token without having to contact the settlement house 216 for verification. In this embodiment, the remote device 212 may subsequently contact the settlement house 216 to request payment, e.g., by submitting the payment token. In a further alternative, the remote device 212 may not require any payment, e.g., in a shared-resource network arrangement in which members voluntarily share resources, whereupon the verification steps may be eliminated. For example, the users of the local and remote devices 210, 212 may both be members of a shared-resource network, which may allow its members to share electronic media freely, either for free, in exchange for a membership fee, or based upon other commercial arrangements.

Once payment has been authorized, confirmed, and/or completed or the transaction otherwise approved, the remote device 212 preferably transmits an electronic guarantee token to the local server 211 at step 240. The local server 211 receives the elecfronic guarantee token from the remote device 212 and stores it on the local device 210. The guarantee token preferably includes an electronic guarantee authorizing completion of the proposed transaction. Preferably, the guarantee token identifies the associated electronic media, and the local server 211. If the transaction involves a single copy of the selected electronic media, the remote device 212 may automatically transfer a copy to the local device 210 instead of the guarantee token, thereby completing the transaction. At any time subsequent to receiving the guarantee token, the local server 211 may submit the guarantee token to the remote device 212, whereupon the remote device 212 may fransfer a copy of the selected elecfronic media to the local device 210. As described above, the electronic guarantee token may be destroyed or otherwise deactivated upon completion of the proposed transaction, e.g., when the selected electronic media is received from the remote device 212.

While the invention is susceptible to various modifications, and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that the invention is not to be limited to the particular forms or methods disclosed, but to the confrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. In a system comprising a local computing device, a remote computing device, a settlement house, and an owner contact site interconnected by a network, the remote computing device having electronic media stored thereon, the local computing device comprising: a communication interface for communicating with the remote computing device via the network; a user interface for presenting available electronic media stored on the remote computing device, the user interface configured for enabling selection of electronic media for a proposed transaction comprising transfer of the selected electronic media from the remote computing device; memory for storing a proposed transaction token received from the remote computing device, the proposed transaction token comprising an identifier for the selected elecfronic media, and an owner contact identifier for identifying a location for contact contacting an owner of the selected electronic media; and a local server configured for submitting an authorization request to the settlement house, the authorization request comprising the owner contact identifier, the local server further configured for receiving an authorization from the settlement house and for submitting the authorization to the remote computing device, whereupon the communication interface may receive a copy of the selected electronic media from the remote computing device.

2. The system of claim 1, further comprising memory for storing the selected electronic media.

3. The system of claim 1 , further comprising a media player for playing the selected electronic media.

4. The system of claim 1, wherein the authorization request comprises a payment request, and wherein the system further comprises memory for storing a settlement token received from the settlement house upon authorization of the proposed transaction, the settlement token comprising the authorization.

5. The system of claim 1, wherein the local server is configured for receiving an electronic guarantee token from the remote computing device guaranteeing fransfer of the selected electronic media, the local server further configured for submitting the guarantee token to the remote computing device to initiate transfer of the selected electronic media from the remote computing device, and wherein the system further comprises memory for storing the guarantee token.

6. The system of claim 1, wherein the local computing device is selected from a list consisting of a desktop computer, a laptop computer, a WAP telephone, a personal digital assistant, and a media player.

7. A method for transferring elecfronic media from a remote media server over a network using a local server, the media server providing access to electronic media owned by respective owners, the method comprising: contacting the media server via the network; selecting electronic media available from the media server for a proposed transaction, the proposed transaction comprising transferring a copy of selected electronic media; receiving a proposed transaction token from the media server, the proposed transaction token identifying the selected electronic media; storing the proposed fransaction token on the local server; instructing the local server to order the proposed transaction, whereby the local server automatically submits a transaction request comprising the proposed transaction token to the media server; and receiving an electronic guarantee token from the media server in response to the transaction request, the guarantee token authorizing completion of the proposed fransaction.

8. The method of claim 7, the method further comprising: submitting the guarantee token to the media server; and receiving the copy of the selected electronic media from the media server.

9. The method of claim 8, wherein the electronic guarantee token is desfroyed when the selected electronic media is received from the media server.

10. The method of claim 8, wherein the proposed transaction comprises fransferring a plurality of copies of the selected electronic media, the electronic guarantee token comprises a counter representing the plurality of copies.

11. The method of claim 10, further comprising: reducing the counter when the selected electronic media is received from the media server; and destroying the guarantee token when the counter is reduced to zero.

12. The method of claim 11 , further comprising receiving a decremental token when the selected electronic media is received from the media server, the decremental token comprising a counter representing the plurality of copies less one.

13. The method of claim 8, wherein the proposed transaction comprises fransferring a plurality of copies of the selected electronic media before an expiration date, the guarantee token comprises an expiration parameter identifying the expiration date, and wherein the guarantee token is automatically destroyed upon reaching the expiration date.

14. The method of 13, wherein the proposed transaction comprises receiving unlimited access to the selected electronic media before the expiration date.

15. The method of claim 7, wherein the proposed transaction token further comprises a price associated with the selected electronic media.

16. The method of claim 15, wherein the proposed transaction token further comprises an approved list of settlement methods, and wherein the step of instructing the local server further comprises: obtaining a settlement token using a settlement method on the approved list; and including the settlement token in the fransaction request, whereby the media server may obtain the price using the settlement method.

17. The method of claim 7, wherein the proposed transaction token comprises an owner contact identifier identifying a location accessible via the network for contacting the owner of the selected electronic media.

18. The method of claim 17, wherein the local server automatically submits a transaction notice intended for the owner of the selected electronic media when the local server is instructed to order the proposed transaction.

19. The method of claim 17, wherein the transaction notice is submitted by the local server to the location identified by the owner contact identifier.

20. The method of claim 17, wherein the step of submitting the transaction notice by the local server comprises submitting a payment request to a settlement house via the network, the payment request comprising the owner contact identifier, whereby the settlement house may submit notice of the proposed transaction to the location identified by the owner contact identifier upon approval of the payment request.

21. The method of claim 20, wherein the proposed transaction token comprises a payment amount, and wherein the fransaction notice comprises the payment amount, whereby the settlement house may submit a payment corresponding to the payment amount to the location identified by the owner contact identifier.

22. The method of claim 20, further comprising: receiving a payment token from the settlement house; and submitting the payment token to the media server before receiving the guarantee token from the media server.

23. The method of claim 7, further comprising sending the guarantee token to an other server via the network, whereby the other server may use the guarantee token to complete the proposed transaction.

24. A method for receiving electronic media from a remote server over a network using a local server, the remote server storing electronic media owned by an owner having a contact location accessible via the network, the method comprising: contacting the remote server via the network; selecting electronic media available on the remote server for a proposed transaction; instructing the local server to complete the proposed transaction, whereby the local server automatically transmits a transaction notice intended for the owner of the selected electronic media, and the local server submits a transaction request to the remote server; and receiving the electronic media from the remote server.

25. The method of claim 24, further comprising: receiving an electronic proposed transaction token from the remote server, the proposed transaction token identifying the selected electronic media, and a contact location for the owner of the selected elecfronic media; and storing the proposed transaction token locally using the local server.

26. The method of claim 24, wherein the local server, when instructed to complete the proposed transaction, obtains a payment authorization for submitting a payment for the proposed transaction.

27. The method of claim 26, wherein the transaction notice is submitted upon obtaining the payment authorization.

28. The method of claim 24, wherein the step of transmitting the transaction notice comprises submitting an authorization request to a settlement house, the authorization request comprising an owner contact identifier, whereby the settlement house may submit the transaction notice to a location identified by the owner contact identifier upon authorization of the proposed transaction.

29. The method of claim 28, wherein the step of submitting an authorization request comprises submitting a payment request to the settlement house.

30. The method of claim 29, further comprising receiving a payment token from the settlement house in response to the payment request.

31. The method of claim 30, wherein the step of submitting the transaction request comprises submitting the payment token to the remote server.

32. The method of claim 31 , wherein the remote server confirms that the payment token received from the local server is valid before the electronic media is received from the remote server.

33. The method of claim 29, wherein the transaction notice is submitted to the location identified by the owner contact identifier upon approval of the payment request, the fransaction notice comprising at least a portion of a payment for the proposed transaction.

34. The method of claim 28, wherein the transaction notice is submitted by the settlement house to the location identified by the owner contact identifier without identifying the local server.

35. The method of claim 24, further comprising: receiving an electronic guarantee token from the media server in response to the transaction request, the guarantee token authorizing completion of the proposed transaction; and submitting the guarantee token to the media server before receiving the copy of the selected elecfronic media from the media server.

36. A method for authorizing a transfer of electronic media between a first server and a second server over a network, the second server having electronic media stored thereon, the method comprising: receiving a payment request from the first server, the payment request comprising an identifier identifying electronic media, a price for a proposed transaction including transfer of a copy of the elecfronic media, and an owner contact identifier identifying a location for contacting an owner of the electronic media; verifying that the first server is qualified to pay the price for the proposed transaction; submitting a settlement token to the first server confirming that the first server is qualified to pay the price; and submitting a notice to the location identified by the owner contact identifier, the notice comprising the identifier identifying the electronic media, and a payment comprising at least a portion of the price.

37. The method of claim 36, further comprising: receiving a verification request from the second server, the verification request comprising the settlement token; confirming that the settlement token is valid; and submitting a verification to the second server confirming that the settlement token is valid.

38. The method of claim 37, further comprising submitting a payment to the second server upon confirmation of the validity of the settlement token, the payment comprising at least a portion of the price.

39. The method of claim 37, further comprising submitting a payment to the second server upon confirmation that the first server is qualified to pay the price, the payment comprising at least a portion of the price.

40. The method of claim 36, further comprising billing or debiting an account associated with the first server an amount equal to the price.