EP1854261A1 - Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems - Google Patents

Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems

Info

Publication number
EP1854261A1
EP1854261A1 EP05751848A EP05751848A EP1854261A1 EP 1854261 A1 EP1854261 A1 EP 1854261A1 EP 05751848 A EP05751848 A EP 05751848A EP 05751848 A EP05751848 A EP 05751848A EP 1854261 A1 EP1854261 A1 EP 1854261A1
Authority
EP
European Patent Office
Prior art keywords
terminal
file
content
upload
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05751848A
Other languages
English (en)
French (fr)
Inventor
Kurt Smit
Wan Kan-Hung
Matthias Runte
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Arvato Mobile GmbH
Original Assignee
Arvato Mobile GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Arvato Mobile GmbH filed Critical Arvato Mobile GmbH
Publication of EP1854261A1 publication Critical patent/EP1854261A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a method for transferring digital contents of a content provider to the users of an online content transmission system in a computer communication network, in which a file containing a specific, desired by a download user content, at least partially from a terminal of an upload User of the content transmission system is transmitted via the computer communication network to a terminal of the download user. Moreover, the invention relates to a corresponding content transmission system for carrying out such a method and to a terminal suitable for this method for downloading a digital content of a content provider from a computer communication network.
  • downloading in the usual notation
  • downloading platform the operator of such a content transfer system
  • the operators of such download platforms are obliged to invest in new hardware on a regular basis, which ultimately means that relatively high proportionate hardware costs must be covered by the revenues.
  • a user authentication for the digital content by the service provider then takes place.
  • the second user may use the downloaded digital content.
  • a payment is made to the first user who has forwarded the digital content.
  • a third user, who then wants to have this content, can in turn download the content from the second or alternatively from the first user. It is possible that appropriate payments are made to each user in the forwarding chain.
  • This transmission method or this content transmission system has, on the one hand, the advantage that the transmission takes place via a decentralized system structure, a so-called “peer-to-peer (P2P) network", in which the contents are forwarded from one user to another user The contents are thus generally present within the network, so that the burden of downloading a content is distributed over the network.
  • P2P peer-to-peer
  • This peer-to-peer system structure is considerably less expensive than a classic central download platform because it It is not necessary to expand the infrastructure in the form of new servers as the number of users increases, but as the number of users increases, so does the number of potential uploaders (ie the users from whom content can be transmitted to other users). As the number of users increases, the infrastructure automatically increases without additional costs.
  • the cost of legally downloading copyrighted digital content can be significantly reduced, thereby reducing the attractiveness of using illegal exchange platforms relative to such legal platforms.
  • Another advantage is that users who are willing to send digital content to others will receive compensation for it. It is expected that users' willingness to illegally send copyrighted content to others will be reduced if they can receive compensation for using a legitimate peer-to-peer platform. Conversely, the downloaders of such legal content within the peer-to-peer platform can legally send the content back to other users and also receive compensation for it.
  • a disadvantage of the aforementioned method is that when transmitting files in a peer-to-peer network, the transmission rate relative to a download from a server is relatively low.
  • asymmetric networks such as DSL networks have the connections of the end users to the network now, although usually a relatively high download bandwidth, but only a small upload bandwidth for a "upload" of data from the terminal to the network on standard DSL connection, a download rate of 780 bit / s, whereas the upload rate is only 128 bit / s
  • future satellite-based networks it can be assumed that the discrepancy between upload and download rate is even greater, eg 15 Mbit / s download and only 64 bit / s or 128 bit / s upload is due to the fact that in most situations, for example when browsing on the Internet, users need to download significantly more data than they need to upload data to the network.
  • fragments of the file are transferred from terminals of various upload users to the terminal of the download user. That is, in a method according to the invention for downloading a digital content of a content provider from a computer communication network to a terminal of a download user of a content transmission system is ensured according to the invention that the terminal of the download user receives fragments of the file from terminals of different upload users .
  • a “download user” is meant a user who downloads a file with a certain content to his terminal
  • the "upload user” is a user of the system who makes his terminal available for this download, ie uploads file parts to the peer-to-peer network for this transaction. It is clear that these terms refer to a file transfer and in other situations the roles can change, ie a download user becomes an upload user and vice versa.
  • Such an inventive method shortens the download time in asymmetric networks such.
  • B. DSL quite considerably, since several upload terminals with a low upload bandwidth serve a download terminal with a higher download bandwidth.
  • the fragments of the desired file coming from different terminals of the upload users can be received in parallel from the terminal of the download user.
  • parallel is to be understood as meaning the transmission protocol, although the individual transmission packets are transmitted technically serially on the lowest network level, but the individual packets are thereby influenced without the download terminal having an influence on the order of the transmission protocol Packets have sent to the receiving terminal that the download bandwidth is used optimally and the fragments are transmitted as quickly as possible. The desired file must then be reconstructed at the download user only from the fragments obtained from the various terminals However, this is not a problem because even with a classical transmission of a file from a single other terminal connected to the network, the transmission usually takes place in packets and a corresponding reconstruction of the file at the receiver is required.
  • an inventive terminal for downloading a digital content of a content provider of a computer communications network must be available, which in addition to a network interface for receiving fragments of the file from other terminals connected to the computer communication network has a suitable transaction control unit, which is designed such that the terminal receives fragments of the file from terminals of different upload users.
  • Such a terminal may be any terminal which can be connected to the computer communications network, for example a PC, a laptop, a personal digital assistant (PDA), a mobile device with suitable equipment or a device which is specifically designed for Receiving and processing of digital content is provided, such as a set-top box for use with a TV, an MP3 player or the like.
  • a PC personal digital assistant
  • PDA personal digital assistant
  • terminals are programmable devices. Therefore, for example, the transaction control unit and the other components required for carrying out the invention or for carrying out certain embodiments of the invention may be in the form of be implemented by software on the terminal. This has the advantage that existing terminals for a function according to the invention can be retrofitted by suitable software installations.
  • At least a portion of the fragments of the file is preferably transmitted from a specially provided base storage terminal of the content transfer system to the terminal of the download user, if none or too few Terminals of upload users are available on which the appropriate parts of the file are available for transmission.
  • a specially provided base storage terminal of the content transfer system For this purpose, only the transaction control unit of the terminal of the download user, also referred to below as the download terminal, must be configured such that the terminal accordingly receives at least a portion of the fragments of the file from such a base memory terminal.
  • This base storage terminal may be, for example, a server of the content provider and / or the operator of the content transmission system. Of course, several such basic storage terminals may be available within the content transmission system.
  • Such a base memory terminal is usually required at least if none of the users has the file with the appropriate content, ie for the first time downloading the content into the peer-to-peer network.
  • the second user may already have a specific content requesting to receive the file with the corresponding content to a part of the first user and to another part of the central base storage terminal. If a third user then requests the same content, he receives this z. From the terminals of the first and second users and in parallel parts of a basic storage terminal. This procedure is continued until a maximum number of terminals is reached by upload users.
  • the central base storage terminal always takes a back seat and is therefore charged less and less.
  • the organization of when which fragment of the file is downloaded from which upload terminal can be done by the transaction control unit of the download user's terminal.
  • the maximum number of upload terminals may be set so that the total upload bandwidth achieved by the various upload terminals is approximately equal to the download bandwidth available at the download user's terminal. Therefore, this maximum number of upload terminals does not have to be fixed, but can be determined depending on the upload bandwidths available for the individual upload terminals. Similarly, the distribution of how many portions of the file are downloaded from which of the upload terminals can also be selected.
  • the term "upload terminal” should not only be understood as the terminals of upload users, but also as a central basic storage terminal on which the file is available for download.
  • the terminal of the download user sends to possible upload terminals on which at least certain parts of the file are available for upload, request signals for requesting specific fragments of the desired file.
  • the respective requested segments are then transmitted from the relevant upload terminal to the download terminal.
  • the terminal of the download user sends to an upload terminal a request signal block, with which several fragments of the desired file are requested at the same time.
  • Such a procedure is therefore also useful in other networks in which a file is not transferred in parallel from multiple uploaders to a Downloader, but in each of which a Downloader can only transfer the file from an upload terminal.
  • This method can therefore also be seen as a separate invention for solving the above-mentioned task of accelerating the download.
  • a request for a particular content is sent in a preferred embodiment from the terminal of the download user to a central indexing device of the content transmission system.
  • This central indexing device determines a group of candidate upload terminals on which at least parts of the file-generally the entire file-are available for uploading. It will then from the central indexing device to the terminal of the download user address information such.
  • the request signals for requesting specific fragments of the file are sent by the latter to at least part of the candidate upload terminals.
  • the transfer initiation device of the content transfer system therefore has a corresponding indexing device.
  • the central indexing device has for this purpose a suitable memory device which contains the information on which terminals of different users of the content transmission system or on which base memory terminals which contents are provided.
  • the indexing device has a selection unit in order, after receiving a request from a user for a specific content from these terminals, to determine the group of candidate upload terminals in each case according to predetermined criteria.
  • the indexing device receives from a terminal of a user of the content transmission system, when files are available for uploading to other users of the content transmission system, an offer signal containing information about the available files , This means that possible upload users log in to the indexing facility. If a particular user regularly and / or constantly provides files for download by other users on his terminal, it is sufficient if this offer signal contains only the information as to whether something has changed in the offer of the respective user since the last time the offer signal was sent.
  • the selection of the upload terminals, to which a request signal for the transmission of a fragment is sent from the download terminal preferably takes place as a function of the priority values assigned to the individual upload terminals.
  • the candidate upload terminals are preferably already selected by the indexing device as a function of priority values and either prioritized - ie in an appropriate order - sent to the download terminal so that the download terminal sends the request signals to the candidate upload terminals in sends the order as the candidate upload terminals get sent from the indexer.
  • the associated priority values can also be transmitted with the address information and then requested in turn from the download terminal in accordance with the priority values at the potential upload terminals.
  • the priority values may be given to the terminals of the various upload users each upon first registration with the content provider or system operator or even in the case of a later registration, if they register as possible uploaders.
  • the priorities can be selected depending on the quality of the data connection, in particular taking into account the provided upload bandwidth.
  • any other criteria can be used to determine the priorities.
  • the priority of a particular upload terminal can also be changed at any time, for example, to ensure that the potential upload terminals are loaded as evenly as possible and - if a payment for an upload to the upload users - also all potential upload Users have a chance to receive compensation.
  • any other arbitrary weighting function is conceivable, the z. B. certain users, such as regular customers, according to predetermined criteria of the content provider preferred.
  • a file containing a particular digital content is assigned a unique identifier, such as a unique name, an ID number, or the like.
  • a unique identifier such as a unique name, an ID number, or the like.
  • this is an identifier that can simultaneously serve to secure and authenticate the file, that is dependent on the content of the file. This can be done by using a hash value of the respective file or similar. at.
  • the desired file can be uniquely identified, whereby it can be more easily ensured that it is indeed the desired and already authenticated file.
  • the download user can also check whether the received file has been delivered completely, unchanged and unadulterated.
  • each file is decomposed into a number of defined segments and assigned a unique identifier to each of the segments.
  • a request signal of the download terminal to an upload terminal contains the unique identifier of the segment of the file to which a requested fragment belongs.
  • the request for the segments is in the order necessary for subsequent use, thus earliest possible use of the file can be achieved.
  • the breakdown into individual segments has the advantage that it does not have to wait until a download is completely completed in order to carry out a check of the data sent, but it is sufficient if the download terminal has completely received a specific segment. It can then already checked the respective segment using the unique identifier and determined whether the segment has been completely and unadulterated transmitted or if necessary, further measures, such. As a renewed request certain segments or fragments are required.
  • the download terminal sends a request signal to another candidate upload terminal if a particular fragment to be transmitted is incompletely or not received by a first upload terminal, with which a fragment is then requested, which corresponds exactly to the erroneous or missing part of the fragment to be sent by the first upload terminal. That is, it is - unlike previously known methods - not the complete fragment again requested by another upload terminal, but it is sufficient if the rest of the fragment, which has not yet been delivered properly, is requested again. This considerably speeds up the transmission process, in particular in peer-to-peer networks, in which it can happen that an upload user whose terminal is currently being used for uploading switches off the relevant terminal or, for other reasons, disconnects it.
  • a request signal of the terminal of the download user to an upload terminal preferably contains not only the unique identifier of the file and / or the segment of the file to which a requested fragment belongs, but also an offset value which determines the position of the fragment within the File or segment of the file and the length of the fragment.
  • the requesting terminal can specify the fragments exactly, so that it can easily request residual fragments if a first requested fragment has not been completely delivered.
  • the files are each made available encrypted within the content transmission system and transmitted to the users or transmitted further.
  • the user In order to use the file then, for example, to view or listen on the respective terminal, open a file to copy to a data store, in particular to burn a CD, the user needs a matching "bowl" for this file
  • Choice of encryption and keys for example, depending on the fee paid, the different users are granted different rights, such as whether a file on a terminal unlimited playable, how many burning operations allowed are how often transfers to other devices - such as MP3 players - are allowed, etc.
  • a key can also be effective for a limited time. Suitable encryption methods are known to the person skilled in the art.
  • DRM Digital Rights Management can be used for this, as are offered, inter alia, by Microsoft®.
  • a programming of such DRM systems can, for.
  • XRML eXtensible Rights Markup Language
  • the download user is preferably provided with a corresponding key for decrypting the file before the transmission of fragments of the file. If the download terminal already possesses the key before receiving fragments of the file, it is possible to decrypt the received parts of the file even before the complete file download has ended, particularly in the case of a segment-by-segment check of the file, as described above , This has the advantage that the digital content can be used during the download. For example, a video movie may already be viewed by the download user during the download, which usually takes a little longer due to the large amount of data.
  • a user In a preferred variant of the method, a user must first authenticate himself to an authentication unit in order to use the content transmission system within an authentication procedure. After successful authentication, the user is sent an authentication ID. With this authentication identifier, the user can then authenticate himself in the further course of the procedure with respect to other functional units of the content transmission system.
  • This method has the advantage that a complete organizational separation of the outwardly appearing content provider from the actual operator of the content transmission system, hereinafter also referred to as "system operator" is possible, the user, for example, to a content provider associated with and under the Control of the content provider's authentication unit. authenticated and receives the authentication identifier. This authentication identifier can then be used in relation to all functional units of the system operator.
  • the system operator thus does not need to carry out a more precise authentication of the respective user, and in particular it is not necessary for the system operator to obtain the passwords, user names or the like. of the respective user who receives this from its content provider.
  • this method makes it possible for companies which are normally active in other industries, for example as operators of a restaurant chain or as beverage, confectionery, toy or furniture retailers, to also serve as content providers for purposes of advertising and / or customer loyalty without great effort for videos, music, software or the like on the Internet. Ie. they do not have to set up and maintain the necessary infrastructure themselves, but can instead use the services of an operator of a content transmission system according to the invention.
  • such an authentication identifier can be used in combination with conventional methods of cryptography, such as encrypted data transmission, also with respect to other users or their terminals, in order to enable unambiguous identification of the respective communication partner.
  • Such an authentication identifier may be limited in time or to a specific session of the user, so that the user z. For example, each time the system logs on, it receives a new authentication ID. In principle, however, such an authentication identifier can also be assigned only once upon first registration of the user.
  • a further separation takes place by the download user (usually directly to the download terminal) after a selection, ie after buying a digital content offered by the content provider, a mitpfsb concernss Trents- tion and a Quiempfangberecht Trent to be sent.
  • the download user can then send the file claim credential to the respective upload terminals for receiving fragments of the desired file.
  • the key recipient authorization identifier is forwarded to a license issuer for receiving the key. This has the advantage that the license issuing facility can be independent of a content provider that appears to the end user and / or of the system operator.
  • the content provider or the operator of the content transmission system also operate the license issuing organization and are even authorized to grant licenses for the content.
  • a separation of these functions also allows, for example, that the license issuer is operated by the actual owner of the copyright or licensing rights of the content and the content provider and the system operator - apart from the later billing with the rights holder and the secure transmission of the files - not deal with the licenses.
  • this allows both the content provider and the system operator to offer content from a wide range of right holders and, depending on the right holder, different license services or licensing facilities to be used in the process, depending on which right holder owns the copyright or licensing rights for the particular content desired ,
  • each file with a digital content offered by a specific content provider and / or each segment of such a file within the content transmission system is assigned a unique identifier which depends not only on the content of the file or the segment, but also on the respective content provider.
  • the identifier of the file is unique. If the file is changed, the identifier also changes, so that the file can still be authenticated using the identifier.
  • This preferred method has the advantage that the content provider can ensure that only users belonging to the respective content provider send files to one another within the peer-to-peer network. In this way, the content provider can ensure that, if one of its users requests content, that content is also transmitted by other of its users and, if paid accordingly, that fee is paid to its own users.
  • the content transfer system preferably has a transaction action control device which - after a transmission of fragments of the file from upload terminals to the terminal of the download user - provides performance-relevant data from the upload terminals and / or from the download user's terminal. On the basis of these data, a remuneration of the upload users for the provision of the respective upload terminals for the transmission of the data to the terminal of the download user can then be determined.
  • the remuneration can be "performance-dependent", for example, depending on the amount of data transmitted.
  • this data can also be used for a simple control of the transaction, ie to determine whether, for example, the download user also the same amount of data received as sent from the upload terminals.
  • files are transmitted within the content transmission system that are initially transmitted by the content provider and / or by the system operator on a central base storage terminal. be provided. These contents are checked in advance and secured by issuing a corresponding identifier, for example the hash value, and authorized for transmission within the system.
  • a corresponding identifier for example the hash value
  • a file with the relevant digital content can then be checked first by the content provider and / or by the network operator, and it is also associated with a positive review of this file an identifier. Of course, this is not required if this is a file that the user has received within the content delivery system.
  • Such a file then already has a unique identifier within the content transmission system.
  • This has the advantage that a user can not only consume the same himself directly after the purchase of such a checked legal content, but also on a terminal for transmission to other users within the content transfer system and make available - if from his terminal from uploads other users - receives appropriate compensation, with which he can refinance the purchase of the content.
  • the content transmission system has an offer overview unit which is either made available to the content provider by the system operator or operated by the latter.
  • a “content provider shop” can be “visited” by a user in the usual way, for example via the Internet with a suitable browser. The user can then view the available content and possibly metadata such. B. additional information of the content or trailer or other excerpts from the Get content for a test.
  • the user can then select a content and preferably also add it to a virtual "shopping cart” in order then to download all the selected contents at the end of a session after the payment details have been processed.
  • information about the content provided by a specific user on his terminal for uploading to other users of the content transmission system can also be retrieved from an offer information unit located on the terminal of the relevant user from a terminal of another user.
  • an offer information unit located on the terminal of the relevant user from a terminal of another user.
  • a user decides to download one of the contents, it is preferably a download in the manner according to the invention from a plurality of terminals, irrespective of whether the download user in question was caused to download by the shop of another user or by the shop of the content provider other users of the system. If the download user was made to download by visiting the shop of another user, the user can be paid a commission, even if he is not involved in the upload.
  • This approach reinforces user engagement with a particular content provider and encourages users to actively participate within the content delivery system.
  • FIG. 1 shows a schematic illustration of the sequence of transmission of a content to a first user, a second user and a third user according to an embodiment of the invention
  • FIG. 2 shows a schematic representation of a file divided into several segments
  • FIG. 3 is a principle block diagram of a structure of an embodiment of the content transfer system according to the invention.
  • FIG. 4 shows a schematic block diagram of an exemplary embodiment of a terminal which can be used within the method
  • FIG. 5 shows a more detailed schematic representation of the sequence of a download according to a further embodiment of the invention
  • FIG. 6 shows a schematic representation of a possible log-on of a terminal secured by a firewall
  • FIG. 7 shows a schematic illustration of a sequence of a download from a terminal secured by a firewall.
  • FIG. 1 shows in a very simplified form a possible sequence of the method according to the invention for downloading to the terminals T1, T2, T3 of the first three users of a content transmission system who want to download a file with a specific content.
  • a basic memory terminal SP also referred to below as "Seedpeer" SP for a first download by a user, for which purpose the file with the corresponding content is prepared by the system operator SB, ie for example checked and encrypted and by a unique Identifier, e.g. A hash value, saved and deployed on the Seedpeer SP.
  • a unique Identifier e.g. A hash value
  • the file D is also broken down into a certain number of segments PO, P1, P2, P3, P4 and these individual segments PO, P1, P2, P3, P4 are also unique characteristics, eg. Hash values.
  • the segments PO, P1, P2, P3, P4 of a file D are each marked with an index.
  • the first segment PO receives the index 0.
  • Each of these segments PO, P1, P2, P3, P4 has an offset O P1 , O P2> which marks the beginning of the segment within the file D, and a fixed length Ip, IR.
  • the structure of such a decomposed file D is shown schematically in FIG. 2, but only the offsets Opi, Op2 of the second segment P1 and of the third segment P2 are shown in the offsets for better clarity.
  • the file D shown there is in total divided into 5 segments PO, P1, P2, P3, P4, all segments except for the last segment P4 having the same length Ip. Only the last segment P4 has a length IR, which corresponds to the remaining length of the file D.
  • the length of such a segment can in principle be set freely and also depend on the length of the overall file. Thus, in a first embodiment it is provided to select a length lp of 1 MB for segments of music titles and a length lp of 8 MB for segments of video films.
  • the identifier of the file D or of the individual segments PO, P1, P2, P3, P4 is unique insofar as the identifier no longer fits if the content of the segment PO, P1, P2, P3, P4 or the file D will be changed. In this way, it can be checked by means of the identifier whether a file D or a segment PO, P1, P2, P3, P4 has been manipulated or altered in any other way.
  • the identifier is also still dependent on the content provider RS, so that one and the same file or a segment of such a file, which is offered by two different content providers, does not have the same identifier.
  • the file or parts of the file can then be downloaded at any time by the users of the Seedpeer SP stating a unique identifier of a segment PO, P1, P2, P3, P4 of the desired file.
  • each of these segments PO, P1, P2, P3, P4 is split into fragments F on a later data request from a download terminal, regardless of whether the request is sent to a seed spear or a terminal of an upload user.
  • a fragment F is a unit that is transmitted coherently from exactly one upload terminal to exactly one download terminal via the network.
  • the fragments F also have an index, an offset value O F and a length I F.
  • the index does not necessarily reflect the order of the fragments F within the segment PO, P1, P2, P3, P4.
  • the offset value O F represents the offset within the segment, ie the distance of the start point of the fragment F from the starting point of the segment.
  • the first fragment F is usually given the index 0.
  • the offset OF and the length I F of a requested fragment are determined by the downloader immediately before the request freely selectable.
  • the length of a fragment may be on the order of 256 KB, for example. However, the size and number of fragments need not be determined at the beginning of a file transfer. An upload terminal that receives the request always transmits exactly the data requested by the download terminal.
  • the preparation and provision of the contents on the Seedpeer SP is shown in FIG. 1 in step 100.
  • the setting of the files D by the system operator SB on the Seedpeer SP is generally carried out according to the specifications of the content provider RS.
  • a first user logs in via a first terminal T1 to the content provider RS or to a server assigned to the content provider RS, on which the content provider RS operates an internet online shop SR (step 101).
  • a server assigned to the content provider RS on which the content provider RS operates an internet online shop SR
  • he After he has authenticated himself, he then receives an authentification identifier, also referred to below as "ticket", which is valid for the entire session in step 102.
  • an authentification identifier also referred to below as "ticket”
  • a part assigned to the content provider RS is stored on a server SUA of the system operator SB, which serves specifically for authentication purposes, and a possible procedure for this login procedure will be described in more detail later.
  • step 103 the first user can then use his terminal T1, for example with the aid of a conventional browser, to select a content in the Internet shop of the content provider and select it for sale.
  • step 104 the billing by the content provider RS is performed in step 104.
  • step 105 the unique identifiers of the file D and the associated segments PO, P1, P2 , P3, P4, and a file-receiving authentication identifier, hereinafter referred to as "download-ID”, and a key-receiving authentication identifier, hereinafter referred to as "voucher”, sent to the terminal T1 of the first user.
  • the voucher is valid for a limited time, ie the user must pick up a key for the file D within a certain time with the voucher.
  • the first user sends from his terminal T1, stating the voucher, a key request to a license server SL (step 106) and then receives from the license server SL the key to his terminal T1 sent (step 107).
  • a source request is sent from the terminal T1 sending the ticket and the identifier of the desired file to a central indexing device Sl, which here belongs to the system operator SB and is installed with further functional units of the system operator SB on a server.
  • address information is sent back to the terminal T1, indicating on which candidate upload terminals the file with the desired content is available.
  • the indexing device S1 searches the candidate upload terminals on the basis of priorities assigned to the individual terminals according to a predetermined weighting function and then sends the address information in the order in which the terminal T1 at the individual candidate upload terminals after a transmission of Fragments F of the desired file D should request.
  • the example shown in FIG. 1 above is the first download of a particular content. Therefore, this file is so far deposited only on the Seedpeer SP.
  • the terminal T1 of the first user therefore receives only the address of the Seedpeers SP.
  • a request signal is sent to the seed spear SP in step 110, which then in step 111, the desired fragments, in this case gradually the complete file, to the terminal T1 sends.
  • step 112 power data is sent to the system operator SB, on the basis of which the download is checked in step 113.
  • the terminal T1 transmit power data to the system operator SB, to control by comparing the data transmitted by the Seedpeer SP and the data transmitted by the T1 download terminal.
  • this step is not shown in FIG.
  • the file containing the relevant content is present not only on the basic storage terminal SP but also on the terminal T1 of the first user.
  • the terminal T1 of the first user is also available for further transmission of the file to other users. It makes sense that this was done through a special registration, since not every user is willing to make his terminal available for uploads and not always the terminal is connected to the network.
  • One possible method for such a special "uploader registration" will be explained later with reference to FIG.
  • a second user after logging on to a content provider RS in step 121 with his terminal T2 and receiving a ticket in step 122, chooses the same content in step 123 when searching for a content as the first user received it before.
  • billing is again carried out here at the content provider in step 124.
  • a key request is sent from the terminal T2 indicating the voucher to the license server SL, which then returns the key in step 127.
  • a source request to the central indexing device S1 of the system operator SB takes place from the terminal T2 of the second user in step 128, which then in step 129 the address information, on which candidate upload terminals the file with the relevant content available for download, returns to terminal T2.
  • this is, on the one hand, the address of the ter- minals T1 of the first user and the address of the Seedpeers SP.
  • the terminal T2 of the second user sends request signals to the candidate terminals T1 and SP. This is done by specifying the download ID, on the basis of which the terminals T1, SP available for upload check the authorization of the download terminal T2.
  • the upload terminals T1, SP then send in steps 132, 133 the requested fragments of the file to the terminal T2 of the second user.
  • both the terminal T1 of the first user and the seed spear SP in steps 134, 135 respectively transmit performance data to the system operator SB on the basis of which a check of the transaction is carried out (step 136).
  • a check of the transaction it is also determined how much data the first user has transmitted from his terminal T1 to the terminal T2 of the second user and accordingly calculates a compensation for the first user for the provision of his terminal T1 during the download to the second user ,
  • a remuneration message is accordingly sent to the terminal T1 of the first user.
  • This fee can be credited to the first user, so that he can charge the compensation received, for example, at later, own downloads with the then payable amounts.
  • the system operator SB or the content provider RS accounts for the users are led and the user the amount in another way, for example, by a transfer on reaching a minimum sum, is paid.
  • the sending of such a remuneration notification is optional. However, it has the advantage that an upload user can query on his terminal at any time, which amounts he has received so far through his uploader activity. This is additional motivation for users to make their terminals available for uploads.
  • both the first user and the second user subsequently provide their terminals T1, T2 for further uploads,
  • a third user who wants to download the same content, now a total of three terminals, namely the terminal T1 of the first user, the terminal T2 of the second user and the Seedpeer SP available.
  • step 141 The third user must also first register with his terminal T3 in step 141 to the content provider RS and receives a ticket in step 142.
  • step 143 he can then select the content in the online shop SR of the content provider RS. Once he has decided on the said content, in step 144, the settlement.
  • step 145 the identifiers of the file and the segments, a download ID and a voucher are then sent back to the terminal T3 of the third user.
  • step 146 a key request is sent from the terminal T3 sending the voucher to the license server SL, whereupon the latter sends back the key in step 147.
  • the terminal T3 in step 148 indicating the ticket to the system operator SB or the central indexing device Sl a request for possible upload terminals and receives in step 149, the addresses of the terminal T2 of the second user and the terminal T1 of the first user.
  • the third user with his terminal T3 it is sufficient for the third user with his terminal T3 to download the file from two upload terminals T1, T2 of other users.
  • it is usually the case that significantly more upload terminals are used to download a file for example ten or more upload terminals for downloading a file to a download terminal.
  • the address of a seed spear SP can also be sent, for example, for cases in which a download from one of the other indicated candidate upload terminals T1, T2 should not be possible for any reason.
  • steps 150, 151 then sends the terminal T3 of the third user to the terminals T2, T1 of the second and the first user in each case a request signal, in turn, the download ID is indicated for control.
  • steps 152 and 153 the requested fragments are sent from the terminals T2, T1 to the terminal T3 of the download user.
  • the upload terminals T2, T1 then send in step 154, 155 again performance data to the system operator SB, which then carries out the control in step 156 and calculates a remuneration for the users of the upload terminals T2, T1.
  • steps 157, 158 corresponding remuneration messages are sent to the terminals T2, T1 of the respective users.
  • FIG. 3 gives an overview of the architecture of an embodiment of a content transmission system according to the invention.
  • the network N used is the Internet.
  • terminals T1, T2, T3, Tn different users of the system.
  • These terminals T1, T2, T3, Tn can be conventional PCs, laptops or the like, but also other devices suitable for connection to a corresponding network N and which can be used to download and / or process digital content Such as set-top boxes, MP3 players, mobile devices and PDAs with appropriate equipment, etc.
  • the terminals T1, T2, T3, Tn contain a data memory DS1, DS2, DS3, DSn, on which the downloaded files and / or files are stored for upload.
  • client installed on the terminals T1, T2, T3, Tn for use in the method according to the invention a special software, hereinafter referred to as "client" installed, which is shown here as each function block C1, C2, C3, Cn.
  • FIG. Roughly schematic here is again the terminal T with the Data storage D and a network interface Nl shown, via which the connection to the Internet N takes place.
  • a terminal T of course, also all other components that usually contain such terminals, such.
  • a motherboard As in a normal PC, a motherboard, processors, graphics cards, power, user interface, etc. All these components are not shown for clarity. They are known in the art and therefore need not be further explained here.
  • the client C implemented here in the form of software on the terminal consists of several modules.
  • a first module 1 is a transaction control unit 1, which provides for the coordination of the transactions during the download and / or upload of files according to the inventive method.
  • the client C has a content database module 2, in which information about the files available for upload are stored. Before being included in this content database, each file is checked for interchangeability within the content delivery system. For this purpose, the client C first calculates the identifier of the file, for example the hash sum, according to the predetermined method. It is then clarified at the content provider, if this hash value already exists. If so, all metadata, including information about the associated exchange rights, are downloaded to the known content database module 2 of the client C for the known hash value. For the files that were already downloaded by the client C itself within the content transfer system after purchase at the same content provider, this test can be omitted, since all tests have already been carried out here.
  • the client C Before being included in this content database, each file is checked for interchangeability within the content delivery system. For this purpose, the client C first calculates the identifier of the file, for example the hash sum, according to the predetermined method. It is then clarified at the content provider, if this hash value already exists. If so, all metadata,
  • the respective file segment from which fragments are to be transmitted is checked in principle again before uploading fragments to other users by comparison with the associated hash sum of the segment. This will help prevent any damage Files are transmitted. If an error occurs, the file in question is removed from the list of uploaded files in the content database.
  • Another component is a browser 3, with which the user can contact the websites of the Internet shop SR of the content provider RS, so that the user in the Internet shop SR content can choose and purchase.
  • this client C belonging to the browser 3, another installed on the terminal T of the user, external browser can be used. Additional functions that may be required can also be installed in this external browser when client C is installed, if this is permitted by the manufacturer of the external browser. The internal browser of client C is then deactivated.
  • a further component of the client C in the exemplary embodiment illustrated is a offer information unit 4, hereinafter also referred to as "client shop” 4.
  • client shop 4 makes it possible for the user to make content available via the content provider RS on his own terminal T, for example Reviews or the like about the content available for upload on its terminal T.
  • This client shop 4 can be visited directly by other users using their browser 3.
  • a segment reconstruction unit 5 in which the requested fragments are reassembled to the individual segments and in which the segments are subsequently checked to see whether they have been completely and correctly received.
  • the check is carried out in such a way that after downloading a complete segment, the downloaded segment is compared with the segment hash sum, which is known to the download terminal. If an error occurs, the following actions are performed: First, the segment is moved to a defective segment repository. It also stores which upload terminal contributed which data to the segment. Subsequently, the segment is downloaded once more from a trusted central server, for example from a Seedpeer SP. It then compares the segment downloaded from the Seedpeer SP with the segment hash sum. If this segment also does not match the segment hash sum, the error may be on the part of the system operator SB. Then there is a cancellation of the download and an automatic message to a control center of the system operator SB. Otherwise, the correct segment is compared to the corrupt file segment. Based on the comparison, the upload terminal (s) that provided the erroneous data can be determined. The faulty sending upload terminals are reported to the central office of the system operator.
  • the fully reconstructed and validated segments are then communicated to a file reconstructor 6 which performs an overall check by comparing the file to the total hash sum of the file. In this case, no error should occur in itself, since possible errors in the examination of the segments should already have been determined. If an error nevertheless occurs, the entire downloaded file is deleted and an error message is sent to the control center of the system operator SB.
  • parts of the functionality or even the entire functionality may be provided by appropriate hardware in the terminals.
  • the client or at least some of the above components of the client are then installed in the form of hardware in a terminal which e.g. B. was specifically designed for the content transfer system according to the invention.
  • a terminal which e.g. B. was specifically designed for the content transfer system according to the invention.
  • various components are required within the content transmission system, as shown in FIG.
  • One component is a so-called indexing device Sl.
  • This indexing device Sl has a memory DSI, in which it is deposited which terminals T1, T2, T3, Tn, SP1, SP2 are currently available for downloading certain contents.
  • this indexing device S1 has a selection unit SU for selecting certain of these terminals T1, T2, T3, Tn, SP1, SP2 as candidate upload terminals from the available upload terminals when a request for a particular content by a user he follows.
  • TC transaction control device
  • MD metadata database
  • the system also includes a user authentication service SUA 1 which serves to authenticate the user when logging on to the system.
  • SUA 1 serves to authenticate the user when logging on to the system.
  • a license server SL is needed, which is responsible for managing the keys for decrypting the files offered, d. H. which handles the complete Digital Rights Management.
  • All these functional units of the system operator SB are usually installed on various servers connected to the Internet N. Basically, it is also possible to realize all functional units in a server. Similarly, the license server SL can be part of this general server, provided that the system operator SB itself takes over the Digital Rights Management.
  • the content provider RS is usually connected to its own server on the Internet N and operates there its content provider Internet shop SR. Basically, it is also possible that the system operator SB on a server or server area this Tasks acting on behalf of the actual content provider RS assumes, and this is not recognizable for the respective users.
  • two base memory terminals (seed peers) SP1, SP2 are also connected to the Internet N, on which content is made available for download by the users.
  • These seed peers SP1, SP2 can be assigned to the system operator SB or the content provider RS. Basically, it is also possible that these functions of the Seedpeers are integrated into a large powerful server of the system operator SB. However, the seed peers can also be operated by independent third parties.
  • Figure 5 is divided because of their length on the part figures 5a, 5b and 5c.
  • a login signal is sent from the terminal T1 of this upload user to the indexing device S1 of the system operator SB in step 501. This is done by transmitting a unique user ID, which is basically assigned to each user on initial registration with the system and which is unique to a particular user within the entire system.
  • step 502 The successful login is then acknowledged in step 502 by the central indexing device Sl. Subsequently, in step 503, the potential upload terminal T1 sends information about the files available for upload, again stating the unique user ID and stating the unique identifiers of the individual files, for example the hash values.
  • step 504 When registering a second user U, who wants to download a content, he first enters via the user interface at his terminal T2 in step 504 start and login commands. The terminal T2 then sends in step 505 a configuration request to the server or the installed Internet shop SR of the content provider RS, which then sends in step 506 a configuration response with which the client C is configured in the terminal T2 for the following session.
  • the terminal T2 automatically sends a login request with a user name and a password in step 507, which identifies the user U to the content provider RS.
  • This request is to a user authentication service SUA which is owned and controlled by the system operator SB.
  • This user authentication service SUA contains an instance, which in turn is under the control of the content provider RS.
  • a "ticket" is generated, with which the user U or his terminal T2 authenticates himself in the subsequent course of the procedure with respect to the further functional units.
  • This instance of the user authentication service SUA is constructed in such a way that the System operator SB has no access to the username and password of the user U, but that the username and the password remain a common secret of the user U and the content provider RS. The ticket is valid for the entire session.
  • the terminal T2 (optional) in steps 509 to 511 is also registered as a potential upload terminal at the central indexing device Sl.
  • the procedure is identical to the method described above in steps 501 to 503, in which the terminal T1 provides itself as a potential uploader. That is to say, a login is also carried out here at the central indexing service S1 (step 509) and upon receipt of a login confirmation (step 510), send a bid signal to the central indexing service Sl (step 511).
  • the terminal T2 With the aid of the ticket received from the user authentication service SUA, the terminal T2 then authenticates once again to the Internet shop SR (also referred to as the "reseller shop") of the content provider RS in step 512.
  • the ticket is processed by the content provider RS in steps 513, 514 Transmission to the user authentication server SUA and corresponding feedback from there checked.
  • step 515 the user can search for an offer in the reseller shop SR and for this purpose instructs his terminal T2 correspondingly, which transmits corresponding signals to the reseller shop SR in step 516.
  • metadata can be queried in steps 517, 518 from a metadata database MD of the system operator SB.
  • the metadata is additional information about a content, such as: As artists, composers, recording year, performers, but also licensing conditions, prices, etc. These data are stored in one of the database MD memory DSM (see Figure 3). These data are then forwarded in step 519 in the form of an offer to the terminal T2 of the user U and output in step 520 to the user U.
  • Steps 515 through 520 are intended to be a standard browsing within the content provider's Internet shop, i. H. The user can start various search queries as often as he likes, view content and receive the offer and other metadata.
  • step 521 the user U decides on a certain content, whereupon the terminal T2 sends a corresponding signal to the reseller shop SR in step 522.
  • the selected content is then assigned to a shopping cart in step 523.
  • the user U can then continue browsing within the Internet shop of content provider RS and select other content. Accordingly, steps 515 to 523 are repeated as often as desired. It is also possible to delete already selected content from the shopping cart.
  • the user U may decide to purchase the shopping cart in step 524. He enters this accordingly at his terminal T2, which then sends in step 525 a buy signal to the Resellershop SR.
  • the reseller shop SR then causes the creation of a voucher and a download ID and all other data required by the user to download and then use the content in the system in step 526 using the ticket transmitted by the user or his terminal T2.
  • the exact procedure is such that first in step 526 the reseller shop SR sends a purchase request with the ticket of the user U and the information about the shopping cart to a purchase transaction service TS, which is part of the transaction control device TC of the system operator SB.
  • This purchase transaction service TS first sends the ticket to the user authentication service SUA for verification.
  • the purchase transaction service TS Upon receipt of the answer in step 528, the purchase transaction service TS then sends a request to the license server SL in step 529 to create a voucher. After the user has been returned to the purchase transaction service TS in step 530, the purchase transaction service TS transmits a corresponding purchase response which contains the voucher and the download IDs required for downloading and the identifiers of the files or the individual segments of the files to be downloaded and, if necessary. contains more signatures to verify the transaction at the various instances, to the resellershop SR. This then forwards the answer to the terminal T2 of the user U in step 532.
  • the terminal T2 then sends in step 533 automatically specifying the voucher a request to the license server SL to transmit a license key.
  • the license server SL then generates a key corresponding to the license purchased by the user and sends it in step 535 to the terminal T2 of the user U.
  • step 536 the terminal T2 then requests from the central indexing service the list of possible uploaders stating the identifier of the file.
  • the central indexing device S1 then creates this list of candidate upload terminals in step 537. Configurable parameters can be taken into account by selecting the uploaders.
  • Each potential uploader receives an upload priority when logging in. This priority is calculated according to the specifications of the content provider RS.
  • the result of this selection is then transmitted to the terminal T2 in step 538, wherein the priorities of the candidate upload terminals are also transmitted. Based on these priorities, the respective candidate upload terminals are then selected by the terminal T2. That is, the terminal T2 first sends to the candidate upload terminal with the highest priority a request signal to request the download of the first fragment. At the second highest priority terminal, the second fragment is then requested until the maximum total number of connections is reached. Subsequently, the further fragments are queried in turn at the already used upload terminals. If several candidate upload terminals with the same priority exist, the download terminal selects them randomly. In the simplified embodiment shown in FIG. 5, the terminal T2 of the user U only requests fragments from the terminal T1 of an upload user and from a central seed spear SP.
  • a download request is initially made in step 539 to the up-ado terminal T1, the identifier of the desired file and the download ID being transmitted, which the terminal T2 has received on purchase.
  • the upload terminal T1 first verifies by the download ID and also checks if the file is actually available on the relevant terminal T1.
  • a response is then sent to the requesting terminal T2.
  • this terminal sends a concrete fragment request to the upload terminal T1, thereby passing the identifier of a segment PO, P1, P2, P3, P4 of the file D and an offset value OF and the length IF for the respective desired fragment F.
  • the offset value OF specifies exactly the starting point of a fragment F within a segment P1 of the file D.
  • the length IF of the fragment is also specified, so that the offset length O F and the length I F of the fragment are uniquely determined by the unique identifier of the segment P1.
  • the length of the fragment and the offset value OF can independently determine the terminal T2 or the transaction control unit 1 of the client C installed in the terminal T2 (see FIG. 3), depending on which fragment F it currently requires.
  • step 543 the requested fragment F is transmitted from the upload terminal T1 to the download terminal T2 of the user U.
  • the upload terminal T1 sends in step 544 a report to a transaction report receiver TR, which is also part of the transaction control device TC.
  • a transaction report receiver TR which is also part of the transaction control device TC.
  • steps 545-548 a download of fragments from a seed spear SP is presented. Since it is certain that the terminal SP contains the desired files, it can also be indicated at the same time as the download request in step 545 which fragments the terminal T2 wishes to receive. Then, after verification in step 546, the requested fragments may be downloaded to terminal T2 in subsequent step 547. Finally, in step 548, a report is also transmitted to the transaction report receiver TR.
  • Each request of the download terminal T2 to an upload terminal T1, SP may request a plurality of fragments in the form of a request block. This request signal block is then processed successively by the upload terminal T1, SP. This method significantly reduces the overhead of control data during a download.
  • the terminal T2 also several requests in succession at the individual uploaders, d. H. at the upload terminal T1 and at the base memory terminal SP, so as to obtain all the fragments of the file.
  • steps 542 and 543 and steps 545 and 547, respectively are repeated as often as desired.
  • the terminal T2 After the terminal T2 has received all the fragments of the file, it sends a download report to the transaction report receiver TR in step 549. By comparing the data received from the various terminals, it is possible to check whether the transaction has been successfully completed. In addition, the remuneration for the uploader can be calculated, as already explained in the context of Figure 1 above. The reimbursement itself can then take place at a later date.
  • the user U can then log off in step 550 by a corresponding command at his terminal T2 at Resellershop ST. This then sends in step 551 a logoff signal to the indexing device Sl, so that it is known that the terminal T2 is no longer available for uploads to other users, and in step 552 a another logoff signal to the user authentication service SUA, which then invalidates the ticket.
  • a problem with such a peer-to-peer network is that a plurality of end-user terminals are blocked by firewalls and therefore can not easily be built from outside a bidirectional, standing connection, such as a TCP connection. Such a connection must always from the inside, d. H. from the terminal secured by the firewall.
  • a firewall is installed on one of the two terminals between which transmission takes place, the connection between the two terminals is established by means of a third terminal on which no firewall is installed.
  • FIG. 6 shows schematically a possible procedure for logging on a terminal TL (hereinafter also referred to as "leaf" TL) secured by a firewall as a potential upload terminal at the central indexing device S1 when the user U 'passes through his terminal TL If a corresponding command causes a login in step 601, the terminal TL first sends a login signal to the central indexing device S1 in step 602. This then sends back a firewall test signal in step 603.
  • a terminal TL hereinafter also referred to as "leaf" TL
  • the terminal TL first sends a login signal to the central indexing device S1 in step 602. This then sends back a firewall test signal in step 603.
  • a time loop 604 is checked If this is not the case, it is assumed that the terminal TL is secured by a firewall, that is, a "leaf.”
  • the central indexer then returns a login response signal with which the terminal TL ready to upload an address of a responsible for the relevant terminal TL, not by a Fire wall secured further terminals TH (hereinafter also called “hub" TH) is transmitted.
  • a TCP connection is established between the leaf TL and the responsible hub TH.
  • the hub TH then sends in step 607 a status message to the central indexer Sl and an acknowledgment to the leaf TL.
  • the leaf TL sends an offer signal with its user ID and the files available for upload to the central indexing device S1.
  • the further connection can then always take place via the responsible hub TH.
  • FIG. 7 illustrates, as a further example, the case of downloading a fragment to a download terminal TD from such a firewall-secured upload leaf TL.
  • the download terminal TD can then first send a "push request signal" to the hub terminal TH in step 701, which sends a corresponding signal via the previously established connection to the upload leaf TL in step 702.
  • the download terminal TD can then log in Step 703, the connection to the download terminal TD open, so that in step 704, the download terminal TD in the usual way can send a request signal to download a fragment F to the upload leaf TL and then receives the desired fragment in step 705.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Beschrieben wird ein Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (SR) an die Nutzer eines Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk (N), bei dem eine Datei (D), welche einen bestimmten von einem Download-Nutzer gewünschten digitalen Inhalt enthält, zumindest teilweise von einem Terminal (T1, T2) eines Upload-Nutzers aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers übertragen wird. Dabei werden von Terminals (T1, T2) verschiedener Upload-Nutzer aus Fragmente (F) der Datei (D) an das Terminal (T2, T3) des Download-Nutzers übertragen.

Description

Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online-Inhalteübertragungssystems
Die Erfindung betrifft ein Verfahren zur Übertrag von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online-Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk, bei dem eine Datei, welche einen bestimmten, von einem Download-Nutzer gewünschten Inhalt enthält, zumindest teilweise von einem Terminal eines Upload-Nutzers des Inhalteübertragungssystems über das Computer-Kommunikationsnetzwerk an ein Terminal des Download-Nutzers übertragen wird. Darüber hinaus betrifft die Erfindung ein entsprechendes Inhalteübertragungssystem zur Durchführung eines solchen Verfahrens sowie ein für dieses Verfahren geeignetes Terminal zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters aus einem Computer-Kommunikationsnetzwerk.
In Computernetzwerken, wie z. B. im Internet, wird mittlerweile eine Vielzahl verschiedenster Inhalte angeboten. Zu solchen Inhalten zählen u. a. Spiele, Bilder, Musik, Filme, Software oder sonstige Veröffentlichungen jeglicher Art. Da durch neue Netzanschlusssysteme wie beispielsweise DSL die Bandbreiten zu den Endbenutzerverbindungen (d. h. zu deren am Netz angeschlossenen Terminals wie z. B. PCs, Laptops etc.) erheblich gesteigert werden konnten, können mittlerweile zwischen den privaten Nutzern sehr schnell und einfach auch recht große Dateien, wie z. B. komplette Musiktitel oder Videofilme, über solche Netzwerke übertragen werden. Die Netzwerke werden daher leider vielfach auch genutzt, um urheberrechtlich geschützte Inhalte illegal auszutauschen. Dadurch hat sich die Verletzung von Urheberrechten inzwischen als ein weltweites gesellschaftliches Problem etabliert.
Da es andererseits für die Nutzer außerordentlich bequem ist, Inhalte wie einzelne Musikstücke oder Videos auf einem heimischen Terminal empfangen zu können, gibt es auch eine zunehmende Zahl von professionellen Inhalteanbietern, die - in der Regel gegen entsprechende Bezahlung - ein legales Herunterladen von urheberrechtlich geschützten digitalen Inhalten ermöglichen. Solche Inhalteanbieter benutzen üblicherweise zentrale Inhalteübertragungssysteme, bei denen die Nutzer jeweils die gewünschten Inhalte von einem zentralen Server des Inhalteanbieters herunterladen. Eine solche zentralisierte Systemarchitektur ermöglicht eine sehr einfache Kontrolle über die transportierten Inhalte. Jedoch wird für die einzelnen Nutzer bei einem Herunterladen (im Folgenden auch in der üblichen Notation als „Download" bezeichnet) von Inhalten vom zentralen Server die zur Verfügung stehende Bandbreite immer kleiner, je mehr Nutzer parallel einen Download von diesem Server durchführen wollen. Für den Inhalteanbieter bzw. den Betreiber eines solchen Inhalteübertragungssystems (im Folgenden auch „Download-Plattform" genannt) ist es somit lediglich eine Frage der Zeit, dass er durch Aufstocken der Hardware, beispielsweise durch eine Parallelschaltung mehrerer Server, die Bandbreite wieder erhöht oder dass andernfalls die Nutzer wegen zu geringer Download-Bandbreiten verärgert werden und daher in Zukunft den Dienst nicht mehr nutzen. Dadurch sind die Betreiber solcher Download-Plattformen zu regelmäßigen Investitionen in neue Hardware verpflichtet, was letztlich bedeutet, dass durch die Umsätze relative hohe anteilige Hardwarekosten gedeckt werden müssen. Dadurch werden die Preise für das legale Herunterladen urheberrechtlich geschützter Inhalte teurer, was wiederum Nutzer dazu verleiten könnte, illegale Tauschplattformen zu nutzen. Zwar werden die Nutzer solcher illegaler Tauschplattformen mittlerweile strafrechtlich verfolgt, dies stößt aber häufig auf Probleme, da die Strafverfolgung an nationale Grenzen gebunden ist. Die Wahrscheinlichkeit einer erfolgreichen Strafverfolgung ist daher eher gering. Da solche Download-Plattformen mit illegal verbreitetem, urheberrechtlich geschütztem Inhalt meist kostenlos arbeiten, wird folglich eine Etablierung von Download- Plattformen mit ausschließlich legalen Inhalten erschwert, da hier bereits zur Deckung der an den Rechteinhaber abzuführenden Lizenzgebühren ein entsprechender Preis für die Nutzung der Inhalte zu entrichten ist.
Eine Möglichkeit zur Lösung dieses Dilemmas wird in der US 2004/0030651 A1 beschrieben. Bei dem dort genannten Verfahren wird durch geeignete Maßnahmen dafür gesorgt, dass die Nutzer des Systems die gewünschten digitalen Inhalte von anderen Nutzern des Systems downloaden können. Dabei müssen jedoch die Nutzer, welche die Inhalte herunterladen, eine entsprechende Zahlung leisten und ein Teil dieser Zahlung wird an den Nutzer weitergeleitet, welcher den Inhalt übertragen hat. Hierzu wird der digitale Inhalt beim Dienstanbieter zunächst vorbereitet, beispielsweise in irgendeiner Form verschlüsselt. Anschließend kann der Inhalt dann in üblicher Weise von einem zentralen Server aus durch einen ersten Nutzer heruntergeladen werden. Wenn ein weiterer Nutzer den Inhalt haben möchte, kann er diesen Inhalt wiederum vom Terminal des ersten Nutzers herunterladen. Anschließend muss er beim Dienstanbieter um Erlaubnis anfragen, den digitalen Inhalt zu nutzen. Gegen Zahlung einer Gebühr erfolgt dann eine Benutzungs- authentifizierung für den digitalen Inhalt durch den Dienstanbieter. Nach Erhalt dieser Authentifizierung kann der zweite Nutzer den heruntergeladenen digitalen Inhalt verwenden. Außerdem wird neben einer Zahlung der Lizenzgebühr an den Rechteinhaber eine Zahlung an den ersten Nutzer veranlasst, welcher den digitalen Inhalt weitergeleitet hat. Ein dritter Nutzer, der diesen Inhalt dann haben möchte, kann den Inhalt wiederum vom zweiten oder alternativ vom ersten Nutzer herunterladen. Dabei ist es möglich, dass entsprechende Zahlungen an jeden Nutzer in der Weiterleitungskette erfolgen.
Dieses Übertragungsverfahren bzw. dieses Inhalteübertragungssystem hat zum einen den Vorteil, dass die Übermittlung über eine dezentrale Systemstruktur, ein sogenanntes „Peer-to-Peer (P2P) -Netzwerk", erfolgt, bei dem die Inhalte von einem Nutzer an einen anderen Nutzer weitergeleitet werden. Die Inhalte sind somit innerhalb des Netzwerkes in der Regel vielfach vorhanden, so dass die Belastung beim Download eines Inhaltes über das Netzwerk verteilt wird. Eine solche Peer-to-Peer-Systemstruktur ist erheblich kostengünstiger als eine klassische zentrale Download-Plattform, da es nicht nötig ist, mit zunehmender Anzahl von Nutzern die Infrastruktur in Form von neuen Servern zu erweitern, sondern mit der Anzahl der Nutzer steigt auch gleichzeitig die Anzahl der potentiellen Uploader (d. h. der Nutzer, von denen aus Inhalte an andere Nutzer übertragen werden können). Mit wachsender Nutzeranzahl steigt somit ohne weitere Kosten automatisch die Infrastruktur. Dies führt dazu, dass die Kosten für das legale Herunterladen von urheberrechtlich geschützten digitalen Inhalten erheblich reduziert werden können, so dass die Attraktivität der Nutzung von illegalen Tauschplattformen im Verhältnis zu derartigen legalen Plattformen sinkt. Ein weiterer Vorteil besteht darin, dass die Nutzer, die bereit sind, digitale Inhalte an andere zu versenden, hierfür eine Vergütung erhalten. Es ist davon auszugehen, dass die Bereitschaft der Nutzer sinkt, urheberrechtlich geschützte Inhalte illegal an andere zu versenden, wenn sie bei Nutzung einer legalen Peer-to-Peer- Plattform hierfür eine Vergütung erhalten können. Umgekehrt können auch die Downloader solcher legalen Inhalte innerhalb der Peer-to-Peer-Plattform die Inhalte auf legale Weise wieder an andere Nutzer versenden und hierfür ebenfalls eine Vergütung erhalten. Daher ist es trotz der Zahlung einer Gebühr für den Download auch für den Download-Nutzer günstiger, von einem Inhalteanbieter den digitalen Inhalt auf legale Weise zu erwerben, da er bei einer Versendung des Inhalts an andere die Kosten refinanzieren oder sogar darüber hinaus langfristig noch einen Gewinn machen kann. Für die Rechteinhaber selber hat ein solches System den Vorteil, dass hierdurch ein neuer Distributionskanal geschaffen wird, welcher die Attraktivität illegaler Tauschbörsen erheblich reduziert.
Ein Nachteil des vorgenannten Verfahrens besteht jedoch darin, dass bei einer Übertragung von Dateien in einem Peer-to-Peer-Netzwerk die Übertragungsrate im Verhältnis zu einem Download von einem Server relativ gering ist. In sogenannten asymmetrischen Netzwerken wie z. B. DSL-Netzen weisen nämlich die Anschlüsse der Endnutzer an das Netzwerk üblicherweise inzwischen zwar eine relativ hohe Download-Bandbreite, aber nur eine geringe Upload-Bandbreite für ein „Heraufladen" von Daten vom Terminal an das Netz auf. So hat beispielsweise ein derzeit üblicher DSL-Anschluss eine Download-Rate von 780 bit/s, wogegen die Upload-Rate nur 128 bit/s beträgt. In zukünftigen satellitengestützten Netzen ist davon auszugehen, dass die Diskrepanz zwischen Upload- und Downloadrate noch größer ist, z. B. bei 15 Mbit/s Download und nur 64 bit/s oder 128 bit/s Upload liegt. Dies liegt u. a. daran, dass in den meisten Situationen, beispielsweise beim Browsen im Internet, von den Nutzern erheblich größere Datenmengen heruntergeladen werden müssen, als dass Daten in das Netz heraufgeladen werden müssen. Bei einer Peer-to-Peer-Datenübertragung ist folglich die Upload- Bandbreite des Upload-Terminals, von dem die digitalen Inhalte aus übertragen werden, der begrenzende Faktor. Dies führt zwangsläufig dazu, dass in einem solchen Netzwerk ein Download eines digitalen Inhalts durchschnittlich erheblich länger dauert als in einem zentralen Netzwerk, bei dem die Nutzer jeweils die digitalen Inhalte von speziell dafür vorgesehenen Servern mit einer ausreichend großen Upload-Bandbreite auf ihr Terminal herunterladen.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren der eingangsgenannten Art derart weiterzuentwickeln, dass der Download beschleunigt wird und insbesondere die vorgenannten Nachteile gegenüber einem zentralen Inhalteübertragungssystem beseitigt werden.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und durch ein Verfahren gemäß Anspruch 18 gelöst.
Erfindungsgemäß werden dabei Fragmente der Datei von Terminals verschiedener Upload-Nutzer aus an das Terminal des Download-Nutzers übertragen. Das heißt, bei einem erfindungsgemäßen Verfahren zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters aus einem Computer- Kommunikationsnetzwerk auf ein Terminal eines Download-Nutzers eines Inhalteübertragungssystems wird erfindungsgemäß dafür gesorgt, dass das Terminal des Download-Nutzers Fragmente der Datei von Terminals verschiedener Upload-Nutzer empfängt. Unter einem „Download-Nutzer" ist hierbei ein Nutzer zu verstehen, der eine Datei mit einem bestimmten Inhalt auf sein Terminal herunterlädt, wogegen der „Upload-Nutzer" ein Nutzer des Systems ist, der sein Terminal für diesen Download zur Verfügung stellt, d. h. für diese Transaktion Dateiteile zum Peer-to-Peer-Netzwerk hochlädt. Es ist klar, dass diese Bezeichnungen sich auf einen Dateitransfer beziehen und in anderen Situationen die Rollen wechseln können, d. h. ein Download- Nutzer zum Upload-Nutzer wird und umgekehrt.
Ein solches erfindungsgemäßes Verfahren verkürzt die Download-Zeit in asymmetrischen Netzwerken wie z. B. DSL ganz erheblich, da mehrere Up- load-Terminals mit einer geringen Upload-Bandbreite ein Download-Terminal mit einer höheren Download-Bandbreite bedienen. Dabei können die von verschiedenen Terminals der Upload-Nutzer kommenden Fragmente der gewünschten Datei parallel vom Terminal des Download-Nutzers empfangen werden. Der Begriff „parallel" ist hierbei im Sinne des Übertragungsprotokolls zu verstehen. Dabei werden zwar - auf unterster Netzwerkebene betrachtet - die einzelnen Übertragungspakete technisch seriell übertragen. Jedoch werden die einzelnen Pakete dabei, ohne dass das Download-Terminal Ein- fluss auf die Reihenfolge der Pakete hat, so an das empfangende Terminal gesendet, dass die Download-Bandbreite optimal genutzt wird und die Fragmente möglichst schnell übertragen werden. Die gewünschte Datei muss dann beim Download-Nutzer nur noch aus den von den verschiedenen Terminals erhaltenen Fragmenten rekonstruiert werden. Dies stellt aber kein Problem dar, da auch bei einer klassischen Übertragung einer Datei von nur einem einzigen anderen am Netzwerk angeschlossenen Terminal die Übertragung meist paketweise erfolgt und eine entsprechende Rekonstruktion der Datei beim Empfänger erforderlich ist. Geeignete Methoden hierzu sind folglich dem Fachmann geläufig.
Weitere Aufgaben der Erfindung sind die Schaffung eines Inhalteübertragungssystems sowie ein geeignetes Terminal zum Herunterladen eines digitalen Inhalts, mit denen dieses Verfahren durchführbar ist.
Diese Aufgaben werden zum einen durch ein Inhalteübertragungssystem gemäß Anspruch 28 und zum anderen durch ein Terminal gemäß Anspruch 32 gelöst. Ein erfindungsgemäßes Inhalteübertragungssystem zur Übertragung digitaler Inhalte eines Inhalteanbieters auf ein Terminal eines Download-Nutzers des Inhalteübertragungssystems in einem Computernetzwerk weist demnach eine Transferinitialisierungseinrichtung auf, welche nach Empfang einer Anfrage eines Download-Nutzers nach einem bestimmten Inhalt das Terminal des Download-Nutzers dazu veranlasst, Fragmente der Datei mit dem gewünschten Inhalt von verschiedenen ausgewählten Kandidaten-Upload- Terminals zu empfangen. Unter dem Begriff „Kandidaten-Upload-Terminals" sind hierbei die Terminals zu verstehen, auf denen zumindest Teile einer bestimmten Datei mit dem gewünschten Inhalt für die Übertragung an das Terminal des Download-Nutzers bereitstehen.
Auf Seiten des Download-Nutzers muss hierzu ein erfindungsgemäßes Terminal zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters eines Computer-Kommunikationsnetzwerk zur Verfügung stehen, welches neben einer Netzwerkschnittstelle zum Empfang von Fragmenten der Datei von anderen am Computer-Kommunikationsnetzwerk angeschlossenen Terminals eine geeignete Transaktionssteuereinheit aufweist, welche so ausgebildet ist, dass das Terminal Fragmente der Datei von Terminals verschiedener Upload-Nutzer empfängt.
Bei einem solchen Terminal kann es sich um ein beliebiges Endgerät handeln, welches an das Computer-Kommunikationsnetzwerk anschließbar ist, beispielsweise einen PC, ein Laptop, einen Personal Digital Assistant (PDA), ein Mobilfunkgerät mit einer geeigneten Ausstattung oder ein Gerät, welches speziell zum Empfang und zur Verarbeitung von digitalen Inhalten vorgesehen ist, wie beispielsweise eine Set-Top-Box zur Verwendung mit einem Fernseher, ein MP3-Player oder dergleichen.
Üblicherweise handelt es sich bei solchen Terminals um programmierbare Geräte. Daher können beispielsweise die Transaktionssteuereinheit und die sonstigen zur Durchführung der Erfindung bzw. zur Durchführung von bestimmten Ausgestaltungen der Erfindung benötigten Komponenten in Form von Software auf dem Terminal implementiert sein. Dies hat den Vorteil, dass durch geeignete Softwareinstallationen bereits bestehende Terminals für eine erfindungsgemäße Funktion nachgerüstet werden können.
Die abhängigen Ansprüche enthalten jeweils besonders vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung, wobei das erfindungsgemäße Inhalteübertragungssystem und das erfindungsgemäße Terminal auch nach erfindungsgemäßen Verfahren weitergebildet sein können und umgekehrt.
Um immer eine möglichst schnelle Versorgung der Nutzer mit den gewünschten Inhalten sicherstellen zu können, wird bevorzugt zumindest ein Teil der Fragmente der Datei von einem speziell hierfür vorgesehenen Basis- Speicherterminal des Inhalteübertragungssystems aus an das Terminal des Download-Nutzers übertragen, wenn keine oder zu wenige Terminals von Upload-Nutzern zur Verfügung stehen, auf denen die passenden Teile der Datei zu einer Übertragung bereitstehen. Hierzu muss lediglich die Transaktionssteuereinheit des Terminals des Download-Nutzers, im Folgenden auch Download-Terminal genannt, derart ausgebildet sein, dass das Terminal entsprechend zumindest einen Teil der Fragmente der Datei von einem solchen Basis-Speicherterminal empfängt. Bei diesem Basis-Speicherterminal kann es sich beispielsweise um einen Server des Inhalteanbieters und/oder des Betreibers des Inhalteübertragungssystems handeln. Selbstverständlich können innerhalb des Inhalteübertragungssystems auch mehrere solcher Basis-Speicherterminals zur Verfügung stehen.
Ein solches Basis-Speicherterminal ist in der Regel zumindest dann erforderlich, wenn noch keiner der Nutzer die Datei mit dem entsprechenden Inhalt besitzt, d. h. für das erstmalige Herunterladen des Inhalts in das Peer-to- Peer-Netzwerk. Zudem ist aber gemäß diesem bevorzugten Ausführungsbeispiel auch vorgesehen, in bestimmten Situationen zumindest ein Basis- Speicherterminal parallel zu den Terminals der Upload-Nutzer einzusetzen, um die Download-Geschwindigkeit auf einem bestimmten Niveau zu halten. Beispielsweise kann bereits der zweite Nutzer, der einen bestimmten Inhalt anfordert, die Datei mit dem entsprechenden Inhalt zu einem Teil von dem ersten Nutzer und zu einem weiteren Teil vom zentralen Basis- Speicherterminal erhalten. Fordert dann ein dritter Nutzer denselben Inhalt an, so erhält er diesen z. B. von den Terminals des ersten und zweiten Nutzers und parallel Teile von einem Basis-Speicherterminal. Dieses Vorgehen wird solange fortgeführt, bis eine maximale Anzahl an Terminals von Upload- Nutzern erreicht wird. Das zentrale Basis-Speicherterminal tritt dabei immer weiter in den Hintergrund und wird somit immer weniger belastet.
Die Organisation, wann welches Fragment der Datei von welchem Upload- Terminal aus heruntergeladen wird, kann durch die Transaktionssteuereinheit des Terminals des Download-Nutzers erfolgen. Die maximale Anzahl der Upload-Terminals kann so gesetzt sein, dass die Gesamt-Upload- Bandbreite, die durch die verschiedenen Upload-Terminals erreicht wird, in etwa der Download-Bandbreite entspricht, die am Terminal des Download- Nutzers zur Verfügung steht. Diese maximale Anzahl der Upload-Terminals muss daher auch nicht fix sein, sondern kann in Abhängigkeit von den bei den einzelnen Upload-Terminals zur Verfügung stehenden Upload- Bandbreiten festgelegt werden. Entsprechend kann auch die Verteilung gewählt werden, wie viele Anteile der Datei von welchem der Upload-Terminals heruntergeladen werden. Unter „Upload-Terminal" sind im Übrigen nicht nur die Terminals von Upload-Usern zu verstehen, sondern auch ein zentrales Basis-Speicherterminal, auf dem die Datei zum Download bereitsteht.
Vorzugsweise sendet das Terminal des Download-Nutzers an mögliche Upload-Terminals, auf denen zumindest bestimmte Teile der Datei zu einem Upload bereitstehen, Anforderungssignale zur Anforderung bestimmter Fragmente der gewünschten Datei. Es werden dann die jeweils angeforderten Segmente von dem betreffenden Upload-Terminal an das Download- Terminal übermittelt.
Bei einem besonders bevorzugten Ausführungsbeispiel sendet das Terminal des Download-Nutzers an ein Upload-Terminal dabei einen Anforderungs- signalblock, mit dem gleichzeitig mehrere Fragmente der gewünschten Datei angefordert werden. Dies beschleunigt das Übertragungsverfahren erheblich, da hierdurch der Overhead an Steuerdaten im Verhältnis zu den transportierten Nutzdaten stark reduziert werden kann. Eine solche Vorgehensweise ist daher auch in anderen Netzwerken sinnvoll, in denen eine Datei nicht parallel von mehreren Uploadern an einen Downloader übertragen wird, sondern in denen jeweils ein Downloader sich die Datei nur von einem Upload-Terminal übertragen lässt. Dieses Verfahren kann daher auch als eine eigene Erfindung zur Lösung der o. g. Aufgabe einer Beschleunigung des Downloads gesehen werden.
Damit das Terminal des Download-Nutzers darüber informiert ist, an welche Upload-Terminals überhaupt Anforderungssignale gesendet werden können, wird bei einem bevorzugten Ausführungsbeispiel vom Terminal des Download-Nutzers aus an eine zentrale Indexierungseinrichtung des Inhalteübertragungssystems eine Anfrage nach einem bestimmten Inhalt gesendet. Von dieser zentralen Indexierungseinrichtung wird dann eine Gruppe von Kandi- daten-Upload-Terminals ermittelt, auf denen zumindest Teile der Datei - in der Regel die ganze Datei - jeweils zu einem Upload bereitstehen. Es werden dann von der zentralen Indexierungseinrichtung an das Terminal des Download-Nutzers Adressinformationen, wie z. B. die Internet-URLs oder ähnliche Netzwerkadressen der Kandidaten-Upload-Terminals, an das Download-Terminal übermittelt. Soweit das Download-Terminal diese Informationen erhalten hat, werden von diesem zumindest an einen Teil der Kandidaten-Upload-Terminals die Anforderungssignale zur Anforderung bestimmter Fragmente der Datei gesendet.
Bei einer besonders bevorzugten Ausführungsform weist die Transferinitialisierungseinrichtung des Inhalteübertragungssystems daher eine entsprechende Indexierungseinrichtung auf. Die zentrale Indexierungseinrichtung besitzt hierzu eine geeignete Speichereinrichtung, welche die Informationen enthält, auf welchen Terminals verschiedener Nutzer des Inhalteübertragungssystems bzw. auf welchen Basis-Speicherterminals welche Inhalte be- reitgestellt sind. Außerdem weist die Indexierungseinrichtung eine Auswahleinheit auf, um nach Empfang einer Anfrage eines Nutzers nach einem bestimmten Inhalt aus diesen Terminals jeweils nach vorgegebenen Kriterien die Gruppe von Kandidaten-Upload-Terminals zu ermitteln.
Damit bei der zentralen Indexierungseinrichtung die notwendigen Informationen zur Verfügung stehen, erhält die Indexierungseinrichtung von einem Terminal eines Nutzers des Inhalteübertragungssystems, wenn auf diesem Terminal Dateien zu einem Upload an andere Nutzer des Inhalteübertragungssystems bereitstehen, ein Angebotssignal, das Informationen über die zur Verfügung stehenden Dateien enthält. Das heißt, mögliche Upload- Nutzer melden sich bei der Indexierungseinrichtung jeweils an. Wenn ein bestimmter Nutzer regelmäßig und/oder ständig auf seinem Terminal Dateien zum Download durch andere Nutzer bereitstellt, reicht es aus, wenn dieses Angebotssignal nur die Informationen enthält, ob sich im Angebot des jeweiligen Nutzers seit dem letzten Senden des Angebotssignals etwas geändert hat.
Die Auswahl der Upload-Terminals, an welche vom Download-Terminal aus ein Anforderungssignal zur Übermittlung eines Fragments ausgesandt wird, erfolgt vorzugsweise in Abhängigkeit von den einzelnen Upload-Terminals zugeordneten Prioritätswerten. Bevorzugt werden bereits von der Indexierungseinrichtung die Kandidaten-Upload-Terminals in Abhängigkeit von Prioritätswerten ausgewählt und entweder priorisiert - d. h. in einer passenden Reihenfolge - an das Download-Terminal übersandt, so dass das Download- Terminal die Anforderungssignale an die Kandidaten-Upload-Terminals in der Reihenfolge sendet, wie es die Kandidaten-Upload-Terminals von der Indexierungseinrichtung übermittelt bekommen. Ebenso können aber auch mit den Adressinformationen die zugeordneten Prioritätswerte übermittelt werden und dann vom Download-Terminal entsprechend der Prioritätswerte der Reihe nach bei den potentiellen Upload-Terminals angefragt werden. Die Prioritätswerte können den Terminals der verschiedenen Upload-Nutzer jeweils bei einer Erstregistrierung beim Inhalteanbieter oder Systembetreiber oder auch bei einer späteren Anmeldung, wenn sie sich als mögliche Uploa- der registrieren lassen, vergeben werden. Beispielsweise können die Prioritäten in Abhängigkeit von der Qualität der Datenverbindung, insbesondere unter Berücksichtigung der zur Verfügung gestellten Upload-Bandbreite, gewählt werden. Es können aber auch beliebige andere Kriterien zur Bestimmung der Prioritäten herangezogen werden. Des Weiteren kann die Priorität eines bestimmten Upload-Terminals auch jederzeit geändert werden, um beispielsweise dafür zu sorgen, dass die potentiellen Upload-Terminals möglichst gleichmäßig belastet werden und - sofern eine Vergütung für einen Upload an die Upload-Nutzer erfolgt - auch alle potentiellen Upload-Nutzer eine Chance haben, eine entsprechende Vergütung zu erhalten. Grundsätzlich ist aber auch jede andere beliebige Gewichtungsfunktion denkbar, die z. B. bestimmte Nutzer, beispielsweise Stammkunden, nach vorgegebenen Kriterien des Inhalteanbieters bevorzugt.
Vorzugsweise ist einer Datei, die einen bestimmten digitalen Inhalt, beispielsweise einen kompletten Videofilm, einen Musiktitel oder Ähnliches enthält, eine eindeutige Kennung, wie ein eindeutiger Name, eine Kennnummer oder dergleichen, zugeordnet. Besonders bevorzugt handelt es sich hierbei um eine Kennung, die gleichzeitig auch zur Sicherung und Authentifizierung der Datei dienen kann, d. h. die vom Inhalt der Datei abhängig ist. Hierzu bietet sich die Verwendung eines Hashwerts der betreffenden Datei o. Ä. an. Bei Verwendung einer solchen Kennung zur Anforderung einer Datei bzw. von Teilen der Datei kann zum einen die gewünschte Datei eindeutig identifiziert werden, wobei leichter sichergestellt werden kann, dass es sich tatsächlich um die gewünschte und bereits authentifizierte Datei handelt. Insbesondere kann auch der Download-Nutzer nach dem Erhalt einer Datei prüfen, ob die erhaltene Datei vollständig, unverändert und unverfälscht geliefert wurde. Dabei ist es egal, ob die Veränderung einer Datei bewusst durch eine gezielte Manipulation oder unbewusst, z. B. durch einen Übertragungsfehler, geschehen ist. Bei einer besonders bevorzugten Ausführungsvariante wird jede Datei in eine Anzahl von definierten Segmenten zerlegt und jedem der Segmente eine eindeutige Kennung zugeordnet. Vorzugsweise enthält dann ein Anforderungssignal des Download-Terminals an einen Upload-Terminal die eindeutige Kennung des Segments der Datei, zu dem ein angefordertes Fragment gehört. Vorzugsweise erfolgt die Anforderung der Segmente in der für die nachfolgende Verwendung notwendigen Reihenfolge, somit kann eine frühestmögliche Verwendung der Datei erreicht werden.
Die Zerlegung in einzelne Segmente hat den Vorteil, dass nicht abgewartet werden muss, bis ein Download komplett abgeschlossen ist, um eine Überprüfung der übersendeten Daten durchzuführen, sondern es reicht aus, wenn das Download-Terminal ein bestimmtes Segment vollständig erhalten hat. Es kann dann bereits das jeweilige Segment mit Hilfe der eindeutigen Kennung geprüft und festgestellt werden, ob das Segment vollständig und unverfälscht übertragen wurde oder ob ggf. weitere Maßnahmen, z. B. eine erneute Anforderung bestimmter Segmente bzw. Fragmente, erforderlich sind.
In einer bevorzugten Variante des Verfahrens sendet das Download- Terminal, wenn von einem ersten Upload-Terminal ein bestimmtes zu übersendendes Fragment unvollständig oder gar nicht empfangen wird, ein Anforderungssignal an ein anderes Kandidaten-Upload-Terminal, mit dem dann ein Fragment angefordert wird, das genau dem fehlerhaften oder fehlenden Teil des vom ersten Upload-Terminals zu übersenden Fragments entspricht. Das heißt, es wird - anders als bei bisher bekannten Verfahren - nicht das komplette Fragment noch einmal von einem anderen Upload-Terminal angefordert, sondern es reicht aus, wenn der Rest des Fragments, welcher noch nicht ordnungsgemäß geliefert wurde, erneut angefordert wird. Dies beschleunigt das Übertragungsverfahren erheblich, insbesondere in Peer-to- Peer-Netzwerken, in denen es durchaus vorkommen kann, dass ein Upload- Nutzer, dessen Terminal gerade zu einem Upload verwendet wird, das betreffende Terminal ausschaltet oder aus sonstigen Gründen eine Verbin- dung unterbrochen wird und somit eine bereits begonnene Übertragung eines Fragments nicht zu Ende geführt werden kann. Eine solche Vorgehensweise ist daher auch in anderen Netzwerken sinnvoll, in denen eine Datei nicht parallel von mehreren Uploadern an einen Downloader übertragen wird, sondern in denen jeweils ein Downloader die Datei sich nur von einem Upload-Terminal übertragen lässt. Auch in solchen Fällen ist es vorteilhaft, wenn die bereits richtig übertragenen Teile der Datei genutzt werden und das Download-Terminal lediglich die nicht gelieferten Teile von demselben oder einem anderen Uploader noch einmal anfordern muss. Dieses Verfahren kann daher ebenfalls als eine eigene Erfindung zur Lösung der o. g. Aufgabe einer Beschleunigung des Downloads gesehen werden.
Vorzugsweise enthält hierzu ein Anforderungssignal des Terminals des Download-Nutzers an ein Upload-Terminal nicht nur die eindeutige Kennung der Datei und/oder des Segments der Datei, zu dem ein angefordertes Fragment gehört, sondern auch einen Offsetwert, der die Position des Fragments innerhalb der Datei bzw. des Segments der Datei sowie die Länge des Fragments repräsentiert. Bei dieser Methode zum Aufbau des Anforderungssignals kann das anfragende Terminal die Fragmente genau spezifizieren, so dass es unproblematisch auch Restfragmente anfordern kann, wenn ein zunächst angefordertes Fragment nicht vollständig geliefert wurde.
Um sicherzustellen, dass die Datei nicht unbefugt genutzt werden kann, werden die Dateien jeweils verschlüsselt innerhalb des Inhalteübertragungssystems zur Verfügung gestellt und an die Nutzer übertragen bzw. weiter übertragen. Um die Datei dann zu nutzen, beispielsweise auf dem jeweiligen Terminal anzusehen oder anzuhören, eine Datei zu öffnen, auf einen Datenspeicher zu kopieren, insbesondere auf eine CD zu brennen, benötigt der Benutzer einen passenden „Schüssel" für diese Datei. Dabei können durch geeignete Wahl der Verschlüsselung und der Schlüssel, z. B. in Abhängigkeit von der gezahlten Gebühr, den verschiedenen Nutzern auch unterschiedliche Rechte zugestanden werden, beispielsweise ob eine Datei auf einem Terminal unbegrenzt abspielbar ist, wie viele Brennvorgänge erlaubt sind, wie oft Transfers auf andere Geräte - wie MP3-Player - erlaubt sind etc. Ebenso kann ein Schlüssel auch zeitlich begrenzt wirksam sein. Geeignete Verschlüsselungsverfahren sind dem Fachmann bekannt. Beispielsweise können hierfür übliche DRM-Verfahren (DRM-Digital Rights Management) eingesetzt werden, wie sie u. a. von Microsoft ® angeboten werden. Eine Programmierung solcher DRM-Systeme kann z. B. auf Basis der eXtensible rights Markup Language (XRML) erfolgen.
Vorzugsweise wird dem Download-Nutzer ein entsprechender Schlüssel zur Entschlüsselung der Datei bereits vor der Übertragung von Fragmenten der Datei übermittelt. Wenn das Download-Terminal den Schlüssel bereits vor dem Empfang von Fragmenten der Datei besitzt, ist es möglich, insbesondere bei einer - wie oben beschriebenen - segmentweisen Überprüfung der Datei, die empfangenen Teile der Datei bereits vor einer Beendigung des vollständigen Datei-Downloads zu entschlüsseln. Dies hat den Vorteil, dass die digitalen Inhalte schon während des Downloads genutzt werden können. Beispielsweise kann ein Videofilm so schon während des Herunterladens, welches aufgrund der großen Datenmenge in der Regel etwas länger dauert, vom Download-Nutzer betrachtet werden.
Bei einer bevorzugten Variante des Verfahrens muss sich ein Nutzer zur Verwendung des Inhalteübertragungssystems zunächst innerhalb eines Au- thentifizierungsverfahrens gegenüber einer Authentifizierungseinheit authentifizieren. Nach erfolgreicher Authentifizierung wird dem Nutzer eine Authen- tifizierungskennung zugesandt. Mit dieser Authentifizierungskennung kann sich der Nutzer dann im weiteren Verlauf des Verfahrens gegenüber anderen Funktionseinheiten des Inhalteübertragungssystems authentifizieren. Dieses Verfahren hat den Vorteil, dass eine komplette organisatorische Trennung des für den Nutzer nach außen erscheinenden Inhalteanbieters vom eigentlichen Betreiber des Inhalteübertragungssystems, im Folgenden auch kurz „Systembetreiber" genannt, möglich ist, wobei sich der Nutzer beispielsweise gegenüber einer dem Inhalteanbieter zugeordneten und unter der Kontrolle des Inhalteanbieters befindlichen Authentifizierungseinheit au- thentifiziert und die Authentifizierungskennung erhält. Diese Authentifizie- rungskennung kann dann gegenüber allen Funktionseinheiten des Systembetreibers verwendet werden. Der Systembetreiber braucht somit selbst keine genauere Authentifizierung des jeweiligen Nutzers durchzuführen, und es ist insbesondere nicht erforderlich, dass dem Systembetreiber die Passwörter, Benutzernamen o. Ä. des jeweiligen Nutzers bekannt werden, die dieser von seinem Inhalteanbieter erhält. Insbesondere ermöglicht dieses Verfahren, dass auch Firmen, die normalerweise in anderen Branchen, beispielsweise als Betreiber einer Gaststättenkette oder als Getränke-, Süßwaren-, Spielzeug- oder Möbelhändler tätig sind, zu Zwecken der Werbung und/oder der Kundenbindung ohne großen Aufwand auch als Inhalteanbieter für Videos, Musik, Software oder dergleichen im Internet auftreten können. D. h. sie müssen hierzu nicht selbst die notwendige Infrastruktur einrichten und warten, sondern können statt dessen die Dienste eines Betreibers eines erfindungsgemäßen Inhalteübertragungssystems in Anspruch nehmen.
Vorzugsweise kann eine solche Authentifizierungskennung in Kombination mit üblichen Verfahren der Kryptographie, wie verschlüsselter Datenübertragung auch gegenüber anderen Nutzern bzw. deren Terminals verwendet werden, um eine eindeutige Identifizierung des jeweiligen Kommunikationspartner zu ermöglichen.
Eine solche Authentifizierungskennung kann zeitlich oder auf eine bestimmte Sitzung des Nutzers begrenzt sein, so dass der Nutzer z. B. jedes Mal beim Neuanmelden beim System eine neue Authentifizierungskennung erhält. Grundsätzlich kann eine solche Authentifizierungskennung aber auch nur einmal bei einer Erstregistrierung des Nutzers vergeben werden.
Bei einem besonders bevorzugten Verfahren findet eine weitere Trennung statt, indem an den Download-Nutzer (in der Regel direkt an das Download- Terminal) nach einer Auswahl, d. h. nach einem Kauf eines vom Inhalteanbieter angebotenen digitalen Inhalts, eine Dateiempfangsberechtigungsken- nung und eine Schlüsselempfangsberechtigungskennung zugesandt werden. Vom Download-Nutzer kann dann die Dateiempfangsberechtigungskennung an die jeweiligen Upload-Terminals zum Erhalt von Fragmenten der gewünschten Datei gesendet werden. Die Schlüsselempfangsberechtigungs- kennung wird dagegen an eine Lizenzerteilungseinrichtung zum Erhalt des Schlüssels weitergeleitet. Dies hat den Vorteil, dass die Lizenzerteilungseinrichtung unabhängig von einem dem Endnutzer gegenüber in Erscheinung tretenden Inhalteanbieter und/oder vom Systembetreiber sein kann. Zwar ist es grundsätzlich möglich, dass beispielsweise der Inhalteanbieter oder der Betreiber des Inhalteübertragungssystems auch die Lizenzerteilungseinrichtung betreiben und selbst dazu befugt sind, Lizenzen für die Inhalte zu erteilen. Andererseits erlaubt eine Trennung dieser Funktionen auch, dass beispielsweise die Lizenzerteilungseinrichtung von dem eigentlichen Inhaber der Urheber- bzw. Lizenzierungsrechte der Inhalte betrieben wird und sich der Inhalteanbieter und der Systembetreiber - abgesehen von der späteren Abrechnung mit dem Rechteinhaber und der sicheren Übermittlung der Dateien - nicht mit den Lizenzen befassen müssen. Insbesondere erlaubt dies, dass sowohl der Inhalteanbieter als auch der Systembetreiber Inhalte von verschiedensten Rechteinhabern anbieten können und je nach Rechteinhaber unterschiedliche Lizenzdienste bzw. Lizenzerteilungseinrichtungen im Verfahren verwendet werden, in Abhängigkeit davon, welcher Rechteinhaber die Urheber- bzw. Lizenzierungsrechte für den jeweils gewünschten Inhalt besitzt.
Sofern Inhalteanbieter und Systembetreiber getrennte Organisationseinheiten sind, können mehrere getrennte Inhalteanbieter ein Inhalteübertragungssystem eines Systembetreibers nutzen. Dabei ist vorzugsweise jeder Datei mit einem von einem bestimmten Inhalteanbieter angebotenen digitalen Inhalt und/oder jedem Segment einer solchen Datei innerhalb des Inhalteübertragungssystems eine eindeutige Kennung zugeordnet, die nicht nur vom Inhalt der Datei bzw. des Segments, sondern auch vom jeweiligen Inhalteanbieter abhängt. Dies bedeutet, dass gleichartige Dateien mit demselben Inhalt innerhalb eines Inhalteübertragungssystems durchaus unterschiedliche eindeutige Kennungen aufweisen, sofern sie zu unterschiedlichen Inhal- teanbietern gehören. Innerhalb der von einem bestimmten Inhalteanbieter angebotenen Inhalte ist die Kennung der Datei jedoch eindeutig. Bei einer Veränderung der Datei verändert sich auch die Kennung, so dass die Datei nach wie vor mit Hilfe der Kennung authentifiziert werden kann. Dies ist beispielsweise dann möglich, wenn als Kennung ein Hashwert nicht nur über die Datei, sondern noch zusätzlich über eine eindeutige Kennung eines Inhalteanbieters gebildet wird. Dieses bevorzugte Verfahren hat den Vorteil, dass der Inhalteanbieter dafür sorgen kann, dass nur zu dem betreffenden Inhalteanbieter gehörige Nutzer untereinander Dateien innerhalb des Peer- to-Peer-Netzwerkes versenden. Auf diese Weise kann der Inhalteanbieter sicherstellen, dass - sofern einer seiner Nutzer einen Inhalt anfordert - dieser Inhalt auch von anderen seiner Nutzer übertragen wird und, wenn eine entsprechende Vergütung gezahlt wird, diese Vergütung den eigenen Nutzern zukommt.
Um eine Vergütung für den Upload-Nutzer festlegen zu können, weist das Inhalteübertragungssystem vorzugsweise eine Transaktionsaktionskontroll- einrichtung auf, die - nach einer Übermittlung von Fragmenten der Datei von Upload-Terminals an das Terminal des Download-Nutzers - leistungsrelevante Daten von den Upload-Terminals und/oder vom Terminal des Download-Nutzers empfängt. Anhand dieser Daten kann dann eine Vergütung der Upload-Nutzer für die Zur-Verfügung-Stellung der jeweiligen Upload- Terminals zur Übermittlung der Daten an das Terminal des Download- Nutzers ermittelt werden. Dabei kann die Vergütung „leistungsabhängig", beispielsweise in Abhängigkeit von der Menge der übermittelten Daten, erfolgen. Zusätzlich können diese Daten auch für eine einfache Kontrolle der Transaktion verwendet werden, d. h. um festzustellen, ob beispielsweise der Download-Nutzer auch die gleiche Menge an Daten erhalten hat, wie sie von den Upload-Terminals abgesendet wurde.
In erster Linie ist vorgesehen, dass innerhalb des Inhalteübertragungssystems Dateien übertragen werden, die vom Inhalteanbieter und/oder vom Systembetreiber zunächst auf einem zentralen Basis-Speicherterminal be- reitgestellt werden. Diese Inhalte werden entsprechend zuvor geprüft und durch Erteilung einer entsprechenden Kennung, beispielsweise des Hash- wertes, gesichert und für eine Übertragung innerhalb des Systems autorisiert. Grundsätzlich ist es jedoch auch möglich, dass ein Nutzer einen von ihm selbst erstellten bzw. zusammengestellten oder auf andere Weise legal erworbenen Inhalt innerhalb des Inhalteübertragungssystems zur Verfügung stellt. Eine Datei mit dem betreffenden digitalen Inhalt kann dann zunächst durch den Inhalteanbieter und/oder durch den Netzbetreiber geprüft werden, und es wird bei positiv verlaufender Überprüfung dieser Datei ebenfalls eine Kennung zugeordnet. Dies ist natürlich nicht erforderlich, wenn es sich hierbei um eine Datei handelt, die der Nutzer innerhalb des Inhalteübertragungssystems erhalten hat. Eine solche Datei weist dann bereits eine eindeutige Kennung innerhalb des Inhalteübertragungssystems auf. Grundsätzlich ist es auch möglich, im Handel Datenträger mit bestimmten Inhalten anzubieten, welche bereits für eine Übermittlung innerhalb eines bestimmten Inhalteübertragungssystems autorisiert sind und schon eine solche Kennung tragen. Dies hat den Vorteil, dass ein Nutzer unmittelbar nach Erwerb eines solchen geprüften legalen Inhalts diesen nicht nur selber konsumieren kann, sondern auch auf einem Terminal zur Übertragung an andere Nutzer innerhalb des betreffenden Inhalteübertragungssystems zur Verfügung stellen kann und - sofern von seinem Terminal aus Uploads an andere Nutzer erfolgen - entsprechende Vergütungen erhält, mit denen er den Kauf des Inhalts refinanzieren kann.
Damit ein beliebiger Nutzer sich zunächst informieren kann, welche Inhalte ein bestimmter Inhalteanbieter im Angebot hat, weist das Inhalteübertragungssystem eine Angebotsübersichtseinheit an, welche entweder vom Systembetreiber dem Inhalteanbieter zur Verfügung gestellt oder von diesem selbst betrieben wird. Ein solcher „Inhalteanbietershop" kann von einem Nutzer in üblicher Weise, beispielsweise über das Internet mit einem geeigneten Browser, „besucht" werden. Der Nutzer kann sich dann die zur Verfügung stehenden Inhalte anzeigen lassen und ggf. Metadaten wie z. B. zusätzliche Informationen der Inhalte oder auch Trailer oder andere Ausschnitte aus den Inhalten für einen Test abrufen. Wie in Internetshops üblich, kann der Nutzer dann einen Inhalt auswählen und vorzugsweise auch einem virtuellen „Warenkorb" hinzufügen, um dann alle ausgewählten Inhalte zum Ende einer Sitzung nach Abwicklung der Zahlungsmodalitäten herunterzuladen.
Bei einer besonders bevorzugten Variante können Informationen über die von einem bestimmten Nutzer auf seinem Terminal für einen Upload an andere Nutzer des Inhalteübertragungssystems bereitgestellten Inhalte auch von einer Angebotsinformationseinheit, die sich auf dem Terminal des betreffenden Nutzers befindet, von einem Terminal eines anderen Nutzers abgerufen werden. Das heißt, der betreffende Nutzer kann selbst auf seinem Terminal eine Art „Nutzer-Shop" einrichten, den andere Nutzer des Systems genau wie den Inhalteanbietershop mit einem Browser besuchen können. Der jeweilige Nutzer kann in „seinem" Shop beispielsweise eigene Bewertungen zu den Inhalten hinzufügen und/oder Empfehlungen abgeben. Er kann dadurch andere Nutzer animieren, bestimmte Inhalte herunterzuladen. Sofern sich ein Nutzer entscheidet, einen der Inhalte herunterzuladen, wird jedoch vorzugsweise - unabhängig davon, ob der betreffende Download- Nutzer durch den Shop eines anderen Nutzers oder durch den Shop des Inhalteanbieters zum Download veranlasst wurde - ein Download in der erfindungsgemäßen Weise von mehreren Terminals anderer Nutzer des Systems durchgeführt. Sofern der Download-Nutzer durch den Besuch des Shops eines anderen Nutzers zum Download veranlasst wurde, kann dem jeweiligen Nutzer eine Vermittlungsprovision gezahlt werden, auch wenn er nicht am Upload beteiligt wird.
Diese Vorgehensweise verstärkt die Bindung der Nutzer an einen bestimmten Inhalteanbieter und animiert die Nutzer zu einer aktiven Teilnahme innerhalb des Inhalteübertragungssystems.
Die Erfindung wird im Folgenden unter Hinweis auf die beigefügten Figuren anhand von Ausführungsbeispielen noch einmal näher erläutert. Es zeigen: Figur 1 eine schematische Darstellung des Ablaufs einer Übertragung eines Inhalts an einen ersten Nutzer, einen zweiten Nutzer und einen dritten Nutzer nach einer Ausführungsform der Erfindung,
Figur 2 eine schematische Darstellung einer in mehrere Segmente unterteilten Datei,
Figur 3 ein Prinzip-Blockschaltbild einer Struktur eines Ausführungsbeispiels des erfindungsgemäßen Inhalteübertragungssystems,
Figur 4 ein Prinzip-Blockschaltbild eines Ausführungsbeispiels eines innerhalb des Verfahrens nutzbaren Terminals,
Figur 5 eine detailliertere schematische Darstellung des Ablaufs eines Downloads nach einer weiteren Ausführungsform der Erfindung,
Figur 6 eine schematische Darstellung einer möglichen Anmeldung eines durch einen Firewall gesicherten Terminals,
Figur 7 eine schematische Darstellung eines Ablaufs eines Downloads von einem durch eine Firewall gesicherten Terminal.
In Figur 1 wird in sehr vereinfachter Form ein möglicher Ablauf des erfindungsgemäßen Verfahrens zum Download auf die Terminals T1 , T2, T3 der ersten drei Benutzer eines Inhalteübertragungssytems gezeigt, die eine Datei mit einem bestimmten Inhalt herunterladen möchten.
Voraussetzung ist zunächst, dass die betreffende Datei auf einem Basis- Speicherterminal SP, im Folgenden auch kurz „Seedpeer" SP genannt, für einen erstmaligen Download durch einen Nutzer hinterlegt ist. Hierzu wird die Datei mit dem entsprechenden Inhalt vom Systembetreiber SB vorbereitet, d. h. beispielsweise geprüft und verschlüsselt und durch eine eindeutige Kennung, z. B. einen Hashwert, gesichert und auf dem Seedpeer SP bereitgestellt.
Bei der Vorbereitung wird die Datei D auch in eine bestimmte Anzahl von Segmenten PO, P1 , P2, P3, P4 zerlegt und diesen einzelnen Segmenten PO, P1 , P2, P3, P4 werden ebenfalls eindeutige Kennwerte, z. B. Hashwerte, zugeordnet. Die Segmente PO, P1 , P2, P3, P4 einer Datei D sind jeweils mit einem Index gekennzeichnet. Das erste Segment PO erhält den Index 0. Jedes dieser Segmente PO, P1 , P2, P3, P4 hat einen Offset OP1, OP2> welcher den Beginn des Segments innerhalb der Datei D markiert, und eine festgelegte Länge Ip, IR. Die Struktur einer solchen zerlegten Datei D ist in Figur 2 schematisch dargestellt, wobei jedoch von den Offsets der besseren Übersichtlichkeit wegen nur die Offsets Opi, Op2 des zweiten Segments P1 und des dritten Segments P2 eingezeichnet sind. Die dort gezeigte Datei D ist insgesamt in 5 Segmente PO, P1 , P2, P3, P4 aufgeteilt, wobei alle Segmente bis auf das letzte Segment P4 die gleiche Länge Ip aufweisen. Lediglich das letzte Segment P4 hat eine Länge IR, welche der Restlänge der Datei D entspricht. Die Länge eines solchen Segments kann im Prinzip frei festgelegt werden und auch von der Länge der Gesamtdatei abhängen. So ist bei einem ersten Ausführungsbeispiel vorgesehen, für Segmente von Musiktiteln eine Länge Ip von 1 MB und für Segmente von Videofilmen eine Länge Ip von 8 MB zu wählen.
Die Kennung der Datei D bzw. der einzelnen Segmente PO, P1, P2, P3, P4 ist jeweils insoweit eindeutig, dass die Kennung nicht mehr passt, wenn der Inhalt des Segments PO, P1, P2, P3, P4 bzw. der Datei D geändert wird. Auf diese Weise ist mittels der Kennung prüfbar, ob eine Datei D bzw. ein Segment PO, P1 , P2, P3, P4 manipuliert oder auf sonstige Weise verändert wurde. Die Kennung ist außerdem noch vom Inhalteanbieter RS abhängig, so dass ein und dieselbe Datei bzw. ein Segment einer solchen Datei, welche von zwei verschiedenen Inhalteanbietern angeboten wird, nicht dieselbe Kennung aufweist. Die Datei bzw. Teile der Datei können dann jederzeit von den Nutzern vom Seedpeer SP unter Angabe einer eindeutigen Kennung eines Segments PO, P1 , P2, P3, P4 der gewünschten Datei heruntergeladen werden.
Dabei wird jedes dieser Segmente PO, P1, P2, P3, P4 bei einer späteren Datenanforderung von einem Download-Terminal, unabhängig davon, ob die Anforderung an einen Seedpeer oder ein Terminal eines Upload-Nutzers gesendet wird, in Fragmente F aufgeteilt. Ein Fragment F ist dabei eine Einheit, die zusammenhängend von genau einem Upload-Terminal an genau ein Download-Terminal über das Netzwerk übertragen wird. Die Fragmente F haben ebenfalls einen Index, einen Offsetwert OF und eine Länge IF. Der Index spiegelt jedoch, anders als bei den Segmenten PO, P1 , P2, P3, P4, nicht zwingend die Reihenfolge der Fragmente F innerhalb des Segments PO, P1 , P2, P3, P4 wieder. Der Offsetwert OF gibt den Versatz innerhalb des Segments, d. h. den Abstand des Startpunkts des Fragments F vom Startpunkt des Segments wieder. Das erste Fragment F erhält in der Regel den Index 0. Das Offset OF und die Länge IF eines angefragten Fragments werden vom Downloader unmittelbar vor der Anforderung frei wählbar festgelegt. Die Länge eines Fragments kann beispielsweise in der Größenordnung von 256 KB liegen. Größe und Anzahl der Fragmente brauchen jedoch beim Beginn eines Dateitransfers noch nicht festzustehen. Ein Upload-Terminal, welches die Anforderung empfängt, überträgt stets genau die Daten, die das Download-Terminal nachfragt.
Dies hat den Vorteil, dass, wenn bei der Übermittlung eines Fragments F die Verbindung unterbrochen wird und nur ein Teil des Fragments F übertragen wird, vom Terminal T2 aus nur eine Anfrage an ein anderes Terminal gesandt werden muss, um das Restfragment FR zu erhalten. Dies ist in Figur 2 angedeutet. Es muss beispielsweise, wenn das Fragment F bereits bis auf ein Restfragment FR übermittelt wurde, lediglich ein neues Fragment angefordert werden, welches den Offsetwert OFR und die Länge IFR des Restfragments aufweist. Es ist also nicht erforderlich, das komplette Fragment F noch einmal von einem anderen Terminal herunterzuladen, was erheblich zeitaufwendiger wäre.
Das Vorbereiten und Bereitstellen der Inhalte auf dem Seedpeer SP ist in Figur 1 im Schritt 100 dargestellt. Die Einstellung der Dateien D durch den Systembetreiber SB auf dem Seedpeer SP erfolgt dabei in der Regel nach den Vorgaben des Inhalteanbieters RS.
Zu irgendeinem späteren Zeitpunkt meldet sich dann ein erster Benutzer über ein erstes Terminal T1 beim Inhalteanbieter RS bzw. bei einem dem Inhalteanbieter RS zugeordneten Server an, auf welchem der Inhalteanbieter RS einen Internet-Onlineshop SR betreibt (Schritt 101). Er erhält dann, nachdem er sich entsprechend authentifiziert hat, im Schritt 102 eine Au- thentifizierungskennung, im Folgenden auch kurz „Ticket" genannt, welches für die gesamte Sitzung gültig ist. Zur Erstellung dieses Tickets wird ein dem Inhalteanbieter RS zugeordneter Teil auf einem Server SUA des Systembetreibers SB, welcher speziell für Authentifizierungszwecke dient, erstellt. Eine mögliche Vorgehensweise bei dieser Anmeldeprozedur wird später noch detaillierter beschrieben.
Im Schritt 103 kann dann der erste Nutzer mittels seines Terminals T1 , beispielsweise mit Hilfe eines üblichen Browsers, im Internetshop des Inhalteanbieters einen Inhalt aussuchen und zum Kauf auswählen.
Wenn sich der erste Nutzer für einen ersten Inhalt entschieden hat und diesen Inhalt „gekauft" hat, erfolgt im Schritt 104 die Abrechnung durch den Inhalteanbieter RS. Anschließend werden im Schritt 105 die eindeutigen Kennungen der Datei D und der zugehörigen Segmente PO, P1 , P2, P3, P4 sowie eine Dateiempfangsberechtigungskennung, im Folgenden „Download-ID" genannt, und eine Schlüsselempfangsberechtigungskennung, im Folgenden „Voucher" genannt, an das Terminal T1 des ersten Nutzers gesandt. Der Voucher ist zeitlich begrenzt gültig, d. h. der Benutzer muss innerhalb einer bestimmten Zeit mit dem Voucher einen Schlüssel für die Datei D abholen. Hierzu sendet der erste Nutzer von seinem Terminal T1 aus unter Angabe des Vouchers eine Schlüsselanfrage an einen Lizenzserver SL (Schritt 106) und erhält daraufhin vom Lizenzserver SL den Schlüssel auf sein Terminal T1 zugesandt (Schritt 107). In einem nächsten Schritt 108 wird vom Terminal T1 unter Versendung des Tickets und der Kennung der gewünschten Datei eine Quellenanfrage an eine zentrale Indexierungseinrichtung Sl gesendet, welche hier zum Systembetreiber SB gehört und beispielsweise mit weiteren Funktionseinheiten des Systembetreibers SB auf einem Server installiert ist. Von dort werden dann im Schritt 109 Adressinformationen an das Terminal T1 zurückgesandt, die angeben, auf welchen Kandidaten- Upload-Terminals die Datei mit dem gewünschten Inhalt zur Verfügung steht. Dabei sucht die Indexierungseinrichtung Sl die Kandidaten-Upload- Terminals anhand von den einzelnen Terminals zugeordneten Prioritäten gemäß einer vorgegebenen Gewichtungsfunktion aus und sendet dann die Adressinformationen in der Reihenfolge, in der das Terminal T1 anschließend bei den einzelnen Kandidaten-Upload-Terminals nach einer Übermittlung von Fragmenten F der gewünschten Datei D anfragen soll.
In dem in Figur 1 oben dargestellten Beispiel handelt es sich um den ersten Download eines bestimmten Inhalts. Daher ist diese Datei bisher lediglich auf dem Seedpeer SP hinterlegt. Das Terminal T1 des ersten Nutzers erhält daher nur die Adresse des Seedpeers SP. Vom Terminal T1 des Nutzers wird dann im Schritt 110 ein Anforderungssignal an den Seedpeer SP gesandt, welcher daraufhin im Schritt 111 die gewünschten Fragmente, in diesem Fall nach und nach die komplette Datei, an das Terminal T1 übersendet.
Vom Seedpeer SP werden dann nach dieser Übertragung im Schritt 112 Leistungsdaten an den Systembetreiber SB übersandt, aufgrund deren im Schritt 113 der Download kontrolliert wird. Hierzu kann beispielsweise auch das Terminal T1 Leistungsdaten an den Systembetreiber SB übersenden, um die Kontrolle durch einen Vergleich der von dem Seedpeer SP übermittelten Daten und der vom Download-Terminal T1 übermittelten Daten durchzuführen. Dieser Schritt ist in Figur 1 jedoch nicht dargestellt.
In der Indexierungseinheit Sl ist jetzt bekannt, dass die Datei mit dem betreffenden Inhalt nicht nur auf dem Basis-Speicherterminal SP, sondern auch auf dem Terminal T1 des ersten Nutzers vorhanden ist. In den weiteren Schritten wird vorausgesetzt, dass das Terminal T1 des ersten Nutzers auch für eine weitere Übermittlung der Datei an andere Nutzer zur Verfügung steht. Sinnvollerweise erfolgte dies durch eine spezielle Registrierung, da ja nicht jeder Nutzer bereit ist, sein Terminal für Uploads zur Verfügung zu stellen und auch nicht jederzeit das Terminal am Netz angeschlossen ist. Ein mögliches Verfahren für eine solche spezielle „Uploader-Registrierung" wird später noch anhand von Figur 5 erläutert.
Bei dem Beispiel gemäß Figur 1 wird dann weiter vorausgesetzt, dass ein zweiter Nutzer, nachdem er sich im Schritt 121 mit seinem Terminal T2 bei einem Inhalteanbieter RS angemeldet und im Schritt 122 ein Ticket erhalten hat, beim Suchen eines Inhalts im Schritt 123 denselben Inhalt auswählt, wie ihn der erste Nutzer zuvor erhalten hat. Nachdem der zweite Nutzer sich für diesen Inhalt entschieden hat, erfolgt auch hier eine Abrechnung beim Inhalteanbieter im Schritt 124. Im darauffolgenden Schritt 125 erfolgt dann wieder eine Übersendung der Kennung der Datei und der Segmente, der „Downlo- ad-ID" und des „Vouchers" an das Terminal T2 des zweiten Nutzers. Im Schritt 126 wird vom Terminal T2 eine Schlüsselanfrage unter Angabe des Vouchers an den Lizenzserver SL gesendet, welcher daraufhin im Schritt 127 den Schlüssel zurücksendet. Unter Angabe des Tickets des zweiten Nutzers erfolgt dann vom Terminal T2 des zweiten Nutzers im Schritt 128 eine Quellenanfrage an die zentrale Indexierungseinrichtung Sl des Systembetreibers SB, welche daraufhin im Schritt 129 die Adressinformationen, auf welchen Kandidaten-Upload-Terminals die Datei mit dem betreffenden Inhalt zum Download bereitsteht, an das Terminal T2 zurücksendet. In dem dargestellten Beispiel handelt es sich hierbei zum einen um die Adresse des Ter- minals T1 des ersten Nutzers und die Adresse des Seedpeers SP. In den Schritten 130 und 131 sendet daher das Terminal T2 des zweiten Nutzers Anforderungssignale an die in Frage kommenden Terminals T1 und SP. Dies erfolgt unter Angabe der Download-ID, anhand derer die zum Upload zur Verfügung stehenden Terminals T1 , SP die Berechtigung des Download- Terminals T2 überprüfen. Die Upload-Terminals T1 , SP senden daraufhin in den Schritten 132, 133 die angefragten Fragmente der Datei an das Terminal T2 des zweiten Nutzers. Am Ende des Downloads übermitteln sowohl das Terminal T1 des ersten Nutzers als auch der Seedpeer SP in den Schritten 134, 135 jeweils wieder Leistungsdaten an den Systembetreiber SB, anhand deren eine Kontrolle der Transaktion durchgeführt wird (Schritt 136). Bei der Kontrolle wird auch ermittelt, wie viele Daten der erste Nutzer von seinem Terminal T1 an das Terminal T2 des zweiten Nutzers übermittelt hat und dementsprechend eine Vergütung für den ersten Nutzer für die Zur- Verfügung-Stellung seines Terminals T1 beim Download zum zweiten Nutzer berechnet.
Im Schritt 137 wird dementsprechend eine Vergütungsmitteilung an das Terminal T1 des ersten Nutzers gesandt. Diese Vergütung kann dem ersten Nutzer gutgeschrieben werden, so dass er beispielsweise bei späteren, eigenen Downloads die erhaltene Vergütung mit den dann zu zahlenden Beträgen verrechnen kann. Es ist aber auch möglich, dass beim Systembetreiber SB oder beim Inhalteanbieter RS Konten für die Nutzer geführt werden und dem Nutzer der Betrag auf andere Weise, beispielsweise durch eine Überweisung bei Erreichen einer Mindestsumme, ausgezahlt wird. Die Übersendung einer solchen Vergütungsmitteilung ist optional. Sie hat jedoch den Vorteil, dass ein Upload-Nutzer auf seinem Terminal jederzeit abfragen kann, welche Beträge er bisher durch seine Uploader-Tätigkeit erhalten hat. Dies ist eine zusätzliche Motivation, damit die Nutzer ihre Terminals auch für Uploads zur Verfügung stellen.
Vorausgesetzt, dass sowohl der erste Nutzer als auch der zweite Nutzer anschließend ihre Terminals T1, T2 für weitere Uploads zur Verfügung stellen, stehen für einen dritten Nutzer, welcher den gleichen Inhalt herunterladen möchte, nun insgesamt drei Terminals, nämlich das Terminal T1 des ersten Nutzers, das Terminal T2 des zweiten Nutzers und der Seedpeer SP zur Verfügung.
Dieses Szenario wird im untersten Drittel von Figur 1 dargestellt. Auch der dritte Nutzer muss sich mit seinem Terminal T3 zunächst im Schritt 141 beim Inhalteanbieter RS anmelden und erhält im Schritt 142 ein Ticket. Im Schritt 143 kann er dann im Onlineshop SR des Inhalteanbieters RS den Inhalt auswählen. Sobald er sich für den besagten Inhalt entschieden hat, erfolgt im Schritt 144 die Abrechnung. Im Schritt 145 werden dann an das Terminal T3 des dritten Nutzers wieder die Kennungen der Datei und der Segmente, eine Download-ID und ein Voucher versandt. Im Schritt 146 wird vom Terminal T3 unter Übersendung des Vouchers eine Schlüsselanfrage an den Lizenzserver SL gesendet, woraufhin dieser im Schritt 147 den Schlüssel zurücksendet. Außerdem sendet das Terminal T3 im Schritt 148 unter Angabe des Tickets an den Systembetreiber SB bzw. die zentrale Indexierungsein- richtung Sl eine Anfrage nach möglichen Upload-Terminals und erhält im Schritt 149 die Adressen des Terminals T2 des zweiten Nutzers und des Terminals T1 des ersten Nutzers.
In dem in Figur 1 dargestellten Fall wird vorausgesetzt, dass es aufgrund der zur Verfügung stehenden Download- und Upload-Raten ausreicht, wenn der dritte Nutzer mit seinem Terminal T3 die Datei von zwei Upload-Terminals T1 , T2 anderer Nutzer herunterlädt. In der Regel ist es jedoch so, dass erheblich mehr Upload-Terminals für einen Download einer Datei genutzt werden, beispielsweise zehn oder mehr Upload-Terminals für das Herunterladen einer Datei auf ein Download-Terminal. Zusätzlich kann mit der Übermittlung der Adressinformationen 149 auch die Adresse eines Seedpeers SP mitgesandt werden, beispielsweise für Fälle, in denen aus irgendwelchen Gründen ein Download von einem der anderen angegebenen Kandidaten-Upload- Terminals T1 , T2 nicht möglich sein sollte. In den Schritten 150, 151 sendet dann das Terminal T3 des dritten Nutzers an die Terminals T2, T1 des zweiten und des ersten Nutzers jeweils ein Anfragesignal, wobei wiederum die Download-ID zur Kontrolle angegeben wird. Daraufhin werden in den Schritten 152 bzw. 153 die angefragten Fragmente von den Terminals T2, T1 an das Terminal T3 des Download-Nutzers über- sandt. Die Upload-Terminals T2, T1 senden dann in den Schritten 154, 155 wieder Leistungsdaten an den Systembetreiber SB, der daraufhin im Schritt 156 die Kontrolle durchführt und eine Vergütung für die Nutzer der Upload- Terminals T2, T1 berechnet. Anschließend werden in den Schritten 157, 158 entsprechende Vergütungsmitteilungen an die Terminals T2, T1 der betreffenden Nutzer versandt.
Figur 3 gibt einen Überblick über die Architektur eines Ausführungsbeispiels eines erfindungsgemäßen Inhalteübertragungssystems.
Dabei wird angenommen, dass es sich bei dem verwendeten Netzwerk N um das Internet handelt. An das Netzwerk N sind in üblicher Weise verschiedenste Terminals T1 , T2, T3, Tn verschiedener Nutzer des Systems angeschlossen. Bei diesen Terminals T1 , T2, T3, Tn kann es sich um übliche PCs, Laptops oder dergleichen handeln, aber auch um andere zum An- schluss an ein entsprechendes Netzwerk N geeignete Geräte, die zum Herunterladen und/oder Verarbeiten von digitalen Inhalten dienen können, wie beispielsweise Set-Top-Boxen, MP3-Player, Mobilfunkgeräte und PDAs mit entsprechender Ausstattung etc. Erforderlich ist auf jeden Fall, dass die Terminals T1 , T2, T3, Tn einen Datenspeicher DS1 , DS2, DS3, DSn enthalten, auf welchem die heruntergeladenen Dateien und/oder Dateien für einen Upload hinterlegt sind. Weiterhin ist auf den Terminals T1, T2, T3, Tn zur Nutzung in dem erfindungsgemäßen Verfahren eine spezielle Software, im Folgenden „Client" genannt, installiert, welche hier jeweils als Funktionsblock C1 , C2, C3, Cn dargestellt ist.
Die verschiedenen Komponenten eines solchen Clients C sind in Figur 4 dargestellt. Grob schematisch ist hier auch wieder das Terminal T mit dem Datenspeicher D sowie einer Netzschnittstelle Nl dargestellt, über die der Anschluss an das Internet N erfolgt. Darüber hinaus weist ein solches Terminal T selbstverständlich auch alle weiteren Komponenten auf, die derartige Terminals üblicherweise enthalten, wie z. B. bei einem normalen PC ein Motherboard, Prozessoren, Graphikkarten, Spannungsversorgung, Benutzerschnittstelle etc. All diese Komponenten sind der Übersichtlichkeit wegen hier nicht dargestellt. Sie sind dem Fachmann bekannt und brauchen daher hier nicht weiter erläutert zu werden.
Der hier in Form von Software auf dem Terminal implementierte Client C besteht aus mehreren Modulen.
Ein erstes Modul 1 ist eine Transaktionssteuereinheit 1 , welche für die Koordinierung der Transaktionen beim Download und/oder Upload von Dateien nach dem erfindungsgemäßen Verfahren sorgt.
Weiterhin weist der Client C ein Content-Datenbank-Modul 2 auf, in dem Informationen über die zum Upload bereitstehenden Dateien hinterlegt sind. Vor der Aufnahme in diese Content-Datenbank wird jede Datei auf ihre Tauschbarkeit innerhalb des Inhalteübertragungssystems geprüft. Hierzu wird vom Client C zunächst nach der vorgegebenen Methode die Kennung der Datei, beispielsweise die Hashsumme, berechnet. Es wird dann beim Inhalteanbieter geklärt, ob dieser Hashwert bereits existiert. Wenn ja, werden zu dem bekannten Hashwert sämtliche Metadaten inklusive Informationen über die zugehörigen Tauschrechte an das lokale Content-Datenbank- Modul 2 des Clients C heruntergeladen. Für die Dateien, die vom Client C selber bereits innerhalb des Inhalteübertragungssystems nach Kauf beim gleichen Inhalteanbieter heruntergeladen wurden, kann dieser Test entfallen, da hier bereits sämtliche Tests durchgeführt wurden. Als zusätzliche Sicherheit wird aber grundsätzlich noch einmal vor einem Upload von Fragmenten an andere Nutzer das jeweilige Dateisegment, aus dem Fragmente übermittelt werden sollen, durch Vergleich mit der zugehörigen Hashsumme des Segments geprüft. Auf diese Weise wird vermieden, dass ggf. beschädigte Dateien übermittelt werden. Tritt ein Fehler auf, wird die betreffende Datei in der Content-Datenbank aus der Liste der zum Upload bereitstehenden Dateien entfernt.
Weiterer Bestandteil ist ein Browser 3, mit dem der Nutzer die Webseiten des Internetshops SR des Inhalteanbieters RS kontaktieren kann, damit der Benutzer im Internetshop SR Inhalte aussuchen und erwerben kann. Anstelle dieses zum Client C gehörigen Browsers 3 kann auch ein anderer auf dem Terminal T des Nutzers installierter, externer Browser genutzt werden. Eventuell benötigte Zusatzfunktionen können auch beim Installieren des Clients C, sofern dies vom Hersteller des externen Browsers zugelassen ist, in diesen externen Browser installiert werden. Der interne Browser des Clients C wird dann deaktiviert.
Ein weiterer Bestandteil des Clients C ist in dem dargestellten Ausführungsbeispiel eine Angebotinformationseinheit 4, im Folgenden auch „Clientshop" 4 genannt. Dieser Clientshop 4 ermöglicht es, dass der Nutzer auf seinem Terminal T selbst im Internet Inhalte über den Inhalteanbieter RS zur Verfügung stellt und beispielsweise Bewertungen oder Ähnliches über die auf seinem Terminal T zum Upload bereitstehenden Inhalte abgibt. Dieser Clientshop 4 kann von anderen Nutzern mit Hilfe deren Browser 3 unmittelbar besucht werden.
Weitere Bestandteile des Clients C sind eine Segmentrekonstruktionseinheit 5, in welcher die angeforderten Fragmente zu den einzelnen Segmenten wieder zusammengesetzt werden und in der die Segmente anschließend daraufhin geprüft werden, ob sie vollständig und richtig empfangen wurden.
Die Überprüfung erfolgt in der Weise, dass nach dem Herunterladen eines vollständigen Segments das heruntergeladene Segment mit der Segment- Hash-Summe, welche dem Download-Terminal ja bekannt ist, verglichen wird. Tritt ein Fehler auf, werden folgende Aktionen durchgeführt: Zunächst wird das Segment in ein Repositorium für fehlerhafte Segmente verschoben. Dort wird außerdem gespeichert, welches Upload-Terminal welche Daten zu dem Segment beigetragen hat. Anschließend wird das Segment noch einmal von einem vertrauenswürdigen zentralen Server, beispielsweise von einem Seedpeer SP, heruntergeladen. Es wird dann das vom Seedpeer SP heruntergeladene Segment mit der Segment-Hash- Summe verglichen. Passt auch dieses Segment nicht mit der Segment- Hash-Summe überein, so liegt der Fehler möglicherweise auf Seiten des Systembetreibers SB. Es erfolgen dann ein Abbruch des Downloads und eine automatische Meldung an eine Zentrale des Systembetreibers SB. Andernfalls erfolgt ein Vergleich des korrekten Segments mit dem korrupten Dateisegment. Auf Basis des Vergleichs können das oder die Upload- Terminals ermittelt werden, die die fehlerhaften Daten geliefert haben. Die fehlerhaft sendenden Upload-Terminals werden an die Zentrale des Systembetreibers gemeldet.
Die vollständig rekonstruierten und geprüften Segmente werden dann an eine Dateirekonstruktionseinrichtung 6 übermittelt, welche einen Gesamt- Check durchführt, indem ein Vergleich der Datei mit der Gesamt-Hash- Summe der Datei durchgeführt wird. Hier sollte an sich kein Fehler mehr auftreten, da ja mögliche Fehler bei der Prüfung der Segmente bereits hätten festgestellt werden müssen. Tritt trotzdem ein Fehler auf, wird die komplette heruntergeladene Datei gelöscht und eine Fehlermeldung an die Zentrale des Systembetreibers SB gesandt.
Alternativ können auch Teile der Funktionalität oder sogar die gesamte Funktionalität durch geeignete Hardware in den Terminals bereitgestellt werden. Der Client oder zumindest einige der o. g. Komponenten des Client sind dann in Form von Hardeware in einemTerminal installiert, welches z. B. speziell für das erfindungsgemäße Inhalteübertragungssystem konstruiert wurde. Auf Seiten des Systembetreibers SB werden innerhalb des Inhalteübertragungssystems, wie in Figur 3 dargestellt, verschiedenste Komponenten benötigt. Eine Komponente ist eine sogenannte Indexierungseinrichtung Sl. Diese Indexierungseinrichtung Sl weist einen Speicher DSI auf, in dem hinterlegt ist, welche Terminals T1 , T2, T3, Tn, SP1 , SP2 aktuell für einen Download bestimmter Inhalte zur Verfügung stehen. Außerdem besitzt diese Indexierungseinrichtung Sl eine Auswahleinheit SU, um bestimmte dieser Terminals T1 , T2, T3, Tn, SP1 , SP2 als Kandidaten-Upload-Terminals aus den zur Verfügung stehenden Upload-Terminals auszuwählen, wenn eine Anfrage nach einem bestimmten Inhalt durch einen Nutzer erfolgt.
Weitere Bestandteile sind eine Transaktionskontrolleinrichtung TC mit einem zugehörigen Speicher DTC sowie eine Metadatenbank MD mit einem zugehörigen Speicher DSM. Die Funktionen dieser Komponenten TC, MD werden später noch erläutert.
Bestandteil des Systems ist außerdem ein Nutzerauthentifizierungsservice SUA1 welcher dazu dient, den Nutzer bei einer Anmeldung beim System zu authentifizieren.
Zusätzlich wird ein Lizenzserver SL benötigt, welcher für die Verwaltung der Schlüssel zur Entschlüsselung der angebotenen Dateien zuständig ist, d. h. welcher das komplette Digital Rights Management übernimmt.
All diese Funktionseinheiten des Systembetreibers SB sind in der Regel auf verschiedenen am Internet N angeschlossenen Servern installiert. Grundsätzlich ist es aber auch möglich, sämtliche Funktionseinheiten in einem Server zu verwirklichen. Ebenso kann der Lizenzserver SL Teil dieses allgemeinen Servers sein, sofern der Systembetreiber SB selber das Digital Rights Management übernimmt. Der Inhalteanbieter RS ist in der Regel mit einem eigenen Server am Internet N angeschlossen und betreibt dort seinen Inhalteanbieter-Internetshop SR. Grundsätzlich ist es aber auch möglich, dass der Systembetreiber SB auf einem Server bzw. Serverbereich diese Aufgaben stellvertretend für den eigentlichen Inhalteanbieter RS übernimmt, wobei dies für die jeweiligen Nutzer nicht erkennbar ist.
In dem in Figur 2 dargestellten Ausführungsbeispiel sind am Internet N außerdem noch zwei Basis-Speicherterminals (Seedpeers) SP1, SP2 angeschlossen, auf denen Inhalte zum Download durch die Nutzer zur Verfügung gestellt werden. Diese Seedpeers SP1 , SP2 können dem System betreiber SB oder dem Inhalteanbieter RS zugeordnet sein. Grundsätzlich ist es auch möglich, dass auch diese Funktionen des Seedpeers in einem großen leistungsfähigen Server des Systembetreibers SB integriert sind. Die Seed-Peer können aber auch von unabhängigen Dritten betrieben werden.
Wie die einzelnen Komponenten untereinander innerhalb eines Downloads zusammenarbeiten, wird beispielhaft anhand von Figur 5 näher erläutert, wobei hier ein Fall dargestellt wird, bei dem ein Nutzer U mittels seines Terminals T2 einen bestimmten Inhalt von einem Terminal T1 eines anderen Nutzers, welcher bereits im Besitz dieses Inhalts ist, sowie einem Seedpeer SP herunterlädt.
Figur 5 ist wegen ihrer Länge auf die Teil-Figuren 5a, 5b und 5c aufgeteilt. In Figur 5 wird zunächst davon ausgegangen, dass sich der erste Nutzer zunächst bei dem System als möglicher Uploader zur Verfügung stellt. Hierzu wird im Schritt 501 vom Terminal T1 dieses Upload-Nutzers ein Login-Signal an die Indexierungseinrichtung Sl des Systembetreibers SB gesandt. Dies erfolgt durch Übermittlung einer eindeutigen User-ID, die grundsätzlich jedem Nutzer bei der erstmaligen Registrierung beim System zugewiesen wird und die jeweils eindeutig für einen bestimmten Nutzer innerhalb des gesamten Systems ist.
Das erfolgreiche Login wird dann im Schritt 502 von der zentralen Indexierungseinrichtung Sl quittiert. Anschließend sendet das potentielle Upload- Terminal T1 im Schritt 503 Informationen über die zum Upload zur Verfügung stehenden Dateien, wiederum unter Angabe der eindeutigen Nutzer-ID und unter Angabe der eindeutigen Kennungen der einzelnen Dateien, beispielsweise der Hashwerte.
Bei der Anmeldung eines zweiten Nutzers U, welcher einen Inhalt herunterladen möchte, gibt dieser zunächst über die Benutzerschnittstelle an seinem Terminal T2 in Schritt 504 Start- und Login-Befehle ein. Das Terminal T2 sendet daraufhin im Schritt 505 eine Konfigurationsanfrage an den Server bzw. den dort installierten Internetshop SR des Inhalteanbieter RS, welcher daraufhin im Schritt 506 eine Konfigurationsantwort sendet, mit der der Client C im Terminal T2 für die folgende Sitzung passend konfiguriert wird.
Anschließend wird vom Terminal T2 im Schritt 507 automatisch eine Login- Anfrage mit einem Benutzernamen und einem Password gesandt, welches den Nutzer U gegenüber dem Inhalteanbieter RS ausweist. Diese Anfrage geht an einen Nutzerauthentifizierungsservice SUA, der hier im Besitz und unter Kontrolle des Systembetreibers SB ist. Dieser Nutzerauthentifikations- service SUA enthält eine Instanz, welche wiederum unter Kontrolle des Inhalteanbieters RS ist. Dort wird auf Basis des übersandten Usernamens und Password ein „Ticket" erzeugt, mit dem sich der Nutzer U bzw. dessen Terminal T2 im nachfolgenden Verlauf des Verfahrens gegenüber den weiteren Funktionseinheiten authentifiziert. Diese Instanz des Nutzerauthentifizie- rungsservice SUA ist so aufgebaut, dass der Systembetreiber SB keinen Zugriff auf den Usernamen und das Password des Nutzers U hat, sondern dass der Nutzername und das Password ein gemeinsames Geheimnis des Nutzers U und des Inhalteanbieters RS bleiben. Das Ticket ist für die komplette Sitzung gültig.
Danach wird das Terminal T2 (optional) in den Schritten 509 bis 511 auch als potenzielles Upload-Terminal bei der zentralen Indexierungseinrichtung Sl angemeldet. Die Vorgehensweise ist identisch zu dem oben in den Schritten 501 bis 503 beschriebenen Verfahren, bei dem sich das Terminal T1 als potentieller Uploader zur Verfügung stellt Das heißt, es wird auch hier ein Login beim zentralen Indexierungsdienst Sl durchgeführt (Schritt 509) und nach Erhalt einer Login-Bestätigung (Schritt 510) ein Angebotssignal an den zentralen Indexierungsdienst Sl gesandt (Schritt 511).
Mit Hilfe des von dem Nutzerauthentifizierungsservice SUA erhaltenen Tickets authentifiziert sich das Terminal T2 dann im Schritt 512 noch einmal gegenüber dem Internetshop SR (im Folgenden auch „Resellershop" genannt) des Inhalteanbieters RS. Das Ticket wird in den Schritten 513, 514 vom Inhalteanbieter RS durch Übersendung an den Nutzerauthentifizie- rungsserver SUA und entsprechende Rückmeldung von dort überprüft.
Anschließend kann der Nutzer im Schritt 515 im Resellershop SR nach einem Angebot suchen und weist hierzu sein Terminal T2 dementsprechend an, welches im Schritt 516 entsprechende Signale an den Resellershop SR übermittelt. Zu den jeweiligen Inhalten, für die sich der Nutzer interessiert, können in den Schritten 517, 518 Metadaten von einer Metadatenbank MD des Systembetreibers SB abgefragt werden. Bei den Metadaten handelt es sich um Zusatzinformationen zu einem Inhalt, wie z. B. Interpreten, Komponisten, Aufnahmejahr, Darsteller, aber auch Lizenzbedingungen, Preise etc. Diese Daten sind in einem der Datenbank MD zugeordneten Speicher DSM hinterlegt (siehe Figur 3). Diese Daten werden dann im Schritt 519 in Form eines Angebots an das Terminal T2 des Nutzers U weitergeleitet und im Schritt 520 an den Nutzer U ausgegeben. Die Schritte 515 bis 520 sollen hierbei ein übliches Browsen innerhalb des Internetshops des Inhalteanbieters darstellen, d. h. der Nutzer kann beliebig oft verschiedene Suchanfragen starten, Inhalte betrachten und erhält hierzu die Angebots- und sonstigen Metadaten.
Bei diesem Ausführungsbeispiel wird davon ausgegangen, dass sämtliche Metadaten, die zu einem bestimmten Inhalt zur Verfügung stehen, in der zentralen Metadatenbank MD bzw. deren Speicher DSM des Systembetreibers SB hinterlegt sind. Selbstverständlich ist es auch möglich, dass der Inhalteanbieter RS selber eine solche Metadatenbank im Resellershop SR betreibt. In diesem Fall sind die Schritte 517, 518 nicht erforderlich. Im Schritt 521 entscheidet sich der Nutzer U für einen bestimmten Inhalt, woraufhin das Terminal T2 im Schritt 522 ein entsprechendes Signal an den Resellershop SR versendet. Im Resellershop SR wird der ausgewählte Inhalt dann im Schritt 523 einem Warenkorb zugewiesen. Der Nutzer U kann danach weiterhin innerhalb des Internetshop des Inhalteanbieters RS browsen und weitere Inhalte auswählen. Es werden dementsprechend die Schritte 515 bis 523 beliebig oft wiederholt. Ebenso ist es auch möglich, bereits ausgewählte Inhalte wieder aus dem Warenkorb zu löschen.
Wenn der Nutzer U alle gewünschten Inhalte ausgewählt hat, kann er sich im Schritt 524 zum Kauf des Warenkorbs entschließen. Er gibt dies entsprechend an seinem Terminal T2 ein, welches daraufhin in Schritt 525 ein Kaufsignal an den Resellershop SR übersendet. Der Resellershop SR veranlasst dann im Schritt 526 mit Hilfe des vom Nutzer bzw. dessen Terminal T2 übermittelten Tickets die Erstellung eines Vouchers und einer Download-ID sowie aller weiteren Daten, die der Benutzer benötigt, um die Inhalte im System herunterzuladen und anschließend zu nutzen. Der genaue Ablauf ist dabei so, dass zunächst im Schritt 526 der Resellershop SR eine Kaufanfrage mit dem Ticket des Nutzers U und den Informationen über den Warenkorb an einen Kauftransaktionsservice TS sendet, welcher Bestandteil der Transaktionskontrolleinrichtung TC des Systembetreibers SB ist. Dieser Kauftransaktionsservice TS sendet zunächst das Ticket zur Überprüfung an den Nutzerauthentifizierungsservice SUA. Nach Erhalt der Antwort in Schritt 528 sendet der Kauftransaktionsservice TS dann im Schritt 529 eine Anfrage an den Lizenzserver SL zur Erstellung eines Vouchers. Nachdem der Vou- cher im Schritt 530 an den Kauftransaktionsservice TS zurückgesendet wurde, übermittelt der Kauftransaktionsservice TS eine entsprechende Kaufantwort, welche den Voucher sowie die zum Download benötigten Download- IDs und die Kennungen der herunterzuladenden Dateien bzw. der einzelnen Segmente der Dateien sowie ggf. weitere Signaturen zur Überprüfung der Transaktion an den verschiedenen Instanzen enthält, an den Resellershop SR. Dieser leitet die Antwort dann im Schritt 532 an das Terminal T2 des Nutzers U weiter.
Das Terminal T2 sendet danach im Schritt 533 automatisch unter Angabe des Vouchers eine Anforderung an den Lizenzserver SL, einen Lizenzschlüssel zu übermitteln. Im Schritt 534 erzeugt der Lizenzserver SL dann einen Schlüssel entsprechend der vom Nutzer gekauften Lizenz und sendet diesen im Schritt 535 an das Terminal T2 des Nutzers U.
Im Schritt 536 fordert das Terminal T2 dann vom zentralen Indexierungs- dienst die Liste der möglichen Uploader unter Angabe der Kennung der Datei an. Die zentrale Indexierungseinrichtung Sl erstellt dann im Schritt 537 diese Liste der Kandidaten-Upload-Terminals. Dabei können konfigurierbare Parameter über die Auswahl der Uploader berücksichtigt werden. Hierzu erhält jeder potenzielle Uploader beim Login eine Upload-Priorität zugewiesen. Diese Priorität wird nach den Vorgaben durch den Inhalteanbieter RS errechnet.
Das Ergebnis dieser Auswahl wird dann im Schritt 538 an das Terminal T2 übermittelt, wobei die Prioritäten der Kandidaten-Upload-Terminals mit übermittelt werden. Anhand dieser Prioritäten werden dann vom Terminal T2 die jeweiligen Kandidaten-Upload-Terminals ausgewählt. Das heißt, das Terminal T2 sendet zunächst an das Kandidaten-Upload-Terminal mit der höchsten Priorität ein Anforderungssignal, um den Download des ersten Fragments anzufordern. Bei dem Terminal mit der zweithöchsten Priorität wird dann das zweite Fragment angefordert, bis insgesamt die maximale Verbindungsanzahl erreicht ist. Anschließend werden die weiteren Fragmente wieder der Reihe nach bei den bereits genutzten Upload-Terminals abgefragt. Existieren mehrere Kandidaten-Upload-Terminals mit gleicher Priorität, so wählt das Download-Terminal unter diesen nach dem Zufallsprinzip aus. In dem in Figur 5 dargestellten, vereinfachten Ausführungsbeispiel fordert das Terminal T2 des Nutzers U nur Fragmente vom Terminal T1 eines UpIo- ad-Users und von einem zentralen Seedpeer SP an.
Hierzu erfolgt zunächst im Schritt 539 eine Download-Anfrage an das UpIo- ad-Terminal T1 , wobei die Kennung der gewünschten Datei und die Download-ID übermittelt werden, die das Terminal T2 beim Kauf erhalten hat. Im Schritt 540 führt das Upload-Terminal T1 zuerst eine Verifikation anhand der Download-ID durch und prüft außerdem, ob die Datei wirklich auf dem betreffenden Terminal T1 bereitsteht. In Schritt 541 wird dann eine Antwort an das anfragende Terminal T2 gesandt. Daraufhin sendet dieses Terminal im Schritt 542 eine konkrete Fragmentanfrage an das Upload- Terminal T1 und übergibt hierbei die Kennung eines Segments PO, P1 , P2, P3, P4 der Datei D und einen Offsetwert OF und die Länge IF für das jeweils gewünschte Fragment F.
Zur Erläuterung dieser Werte wird noch einmal auf Figur 2 und die obige Beschreibung hierzu verwiesen. Der Offsetwert OF gibt hier genau den Startpunkt eines Fragments F innerhalb eines Segments P1 der Datei D an. Die Länge IF des Fragments wird ebenfalls angegeben, so dass durch die eindeutige Kennung des Segments P1 die Offsetlänge OF und die Länge IF des Fragments eindeutig bestimmt ist. Die Länge des Fragments und den Offsetwert OF kann dabei das Terminal T2 bzw. die Transaktionssteuereinheit 1 des im Terminal T2 installierten Clients C (vergleiche Figur 3) selbständig festlegen, je nachdem, welches Fragment F es gerade benötigt.
Im Schritt 543 wird schließlich das angefragte Fragment F vom Upload- Terminal T1 an das Download-Terminal T2 des Nutzers U übermittelt. Anschließend sendet das Upload-Terminal T1 im Schritt 544 einen Report an einen Transaktionsreportempfänger TR, welcher ebenfalls Bestandteil der Transaktionskontrolleinrichtung TC ist. Um eine sichere und schnelle Übertragung zu gewährleisten, können bestimmte Zeitspannen gesetzt werden, in denen bei einer solchen Peer-to- Peer-Datenübermittlung die Daten übergeben werden sollten. Andernfalls wird der Versuch abgebrochen und es werden Daten von anderen Terminals angefordert. Beispielsweise kann, falls über eine Verbindung in einem bestimmten Zeitraum, z. B. in den letzten 5 Sekunden, keinerlei Daten übertragen wurden und in dem Zeitraum auch keine Verbindung zu einem Terminal aufgebaut wurde und wenn innerhalb eines weiteren bestimmten Zeitraums keine Verbindung zu einem Seedpeer des Systembetreibers bzw. Inhalteanbieters aufgebaut wurde, eine entsprechende Verbindung zu einem solchen Seedpeer aufgebaut werden, um die Datei von dort zu erhalten. Das Gleiche kann erfolgen, wenn bereits Verbindungen zu bestimmten anderen Terminals von Download-Nutzern existieren, über die aber in einem bestimmten Zeitraum, z. B. mehr als 30 Sekunden, keine Daten mehr übertragen wurden. Diese Verbindungen können dann abgebrochen werden und die UpIo- ad-Terminals können als „schlecht" markiert und die Restfragmente neu angefordert werden.
Ebenso kann auch, wenn eine Vielzahl weiterer Upload-Terminals zur Verfügung stehen, die jeweils langsamste Verbindung unterbrochen, das betreffende Upload-Terminal als langsam markiert und eine neue Verbindung mit einem wartenden Upload-Terminal aufgebaut werden, um den Download zu beschleunigen.
In den Schritten 545 bis 548 wird ein Download von Fragmenten von einem Seedpeer SP dargestellt. Da hier sicher ist, dass das Terminal SP die gewünschten Dateien enthält, kann gleichzeitig mit der Download-Anfrage im Schritt 545 auch angegeben werden, welche Fragmente das Terminal T2 erhalten möchte. Es können dann nach der Verifikation im Schritt 546 gleich die angeforderten Fragmente im nachfolgenden Schritt 547 an das Terminal T2 heruntergeladen werden. Schließlich wird auch hier im Schritt 548 ein Report an den Transaktionsreportempfänger TR übermittelt. Jede Anfrage des Download-Terminals T2 an ein Upload-Terminal T1, SP kann in Form eines Anfrageblocks gleich eine Vielzahl von Fragmenten anfordern. Dieser Anfragesignalblock wird dann vom Upload-Terminal T1 , SP sukzessive abgearbeitet. Dieses Verfahren reduziert den Overhead an Steuerdaten bei einem Download erheblich. Da die Möglichkeit besteht, im Rahmen eines Warenkorbs mehrere Inhalte bzw. Dateien zu kaufen, ist es bei einer bevorzugten Variante des Verfahrens auch möglich, dass bei einem Upload-Terminal gleichzeitig - beispielsweise auch innerhalb eines Anfragesignalblocks - Fragmente unterschiedlicher Dateien anzufordern, um den Download des gesamten Warenkorbs zu optimieren.
Es ist klar, dass das Terminal T2 auch mehrere Anfragen nacheinander bei den einzelnen Uploadern, d. h. beim Upload-Terminal T1 und beim Basis- Speicherterminal SP, anfordern kann, um so alle Fragmente der Datei zu erhalten. In diesem Fall werden die Schritte 542 und 543 bzw. die Schritte 545 und 547 beliebig oft wiederholt. Dabei kann es unter bestimmten Umständen zur Verringerung des Datenoverheads auch sinnvoll sein, wenn erst nach Beendigung des kompletten Uploads die Upload-Reports 544 bzw. 548 versandt werden.
Nachdem das Terminal T2 sämtliche Fragmente der Datei erhalten hat, sendet es im Schritt 549 einen Download-Report an den Transaktionsreportempfänger TR. Durch Vergleich der von den verschiedenen Terminals erhaltenen Daten kann kontrolliert werden, ob die Transaktion erfolgreich abgeschlossen wurde. Außerdem kann die Vergütung für den Uploader berechnet werden, wie dies schon im Rahmen von Figur 1 weiter oben erläutert wurde. Die Vergütung selbst kann dann zu einem späteren Zeitpunkt erfolgen.
Der Nutzer U kann sich anschließend in Schritt 550 durch einen entsprechenden Befehl an seinem Terminal T2 beim Resellershop ST abmelden. Dieser sendet daraufhin im Schritt 551 ein Logoff-Signal an die Indexie- rungseinrichtung Sl, damit dort bekannt ist, dass das Terminal T2 nicht mehr für Uploads an andere Nutzer zur Verfügung steht, sowie im Schritt 552 ein weiteres Logoff-Signal an den Nutzerauthentifizierungsservice SUA, welcher daraufhin das Ticket entwertet.
Ein Problem bei einem solchen Peer-to-Peer-Netzwerk besteht darin, dass eine Vielzahl von Endbenutzerterminals durch Firewalls blockiert sind und daher nicht auf einfache Weise von außen eine bidirektionale, stehende Verbindung, beispielsweise eine TCP-Verbindung, aufgebaut werden kann. Eine solche Verbindung muss immer von innen, d. h. von dem durch die Firewall gesicherten Terminal, aufgeschlossen werden. Um dieses Problem zu lösen, wird vorzugsweise bei dem erfindungsgemäßen Verfahren in einem solchen Fall, wenn auf einem der beiden Terminals, zwischen denen eine Übertragung stattfindet, eine Firewall installiert ist, die Verbindung zwischen den beiden Terminals mit Hilfe eines dritten Terminals aufgebaut, auf dem keine Firewall installiert ist.
In Figur 6 ist schematisch ein möglicher Ablauf einer Anmeldung eines durch eine Firewall gesicherten Terminals TL (im Folgenden auch „Leaf" TL genannt) als potentielles Upload-Terminal bei der zentralen Indexierungsein- richtung Sl dargestellt. Wenn der Nutzer U' sein Terminal TL durch einen entsprechenden Befehl im Schritt 601 zu einem Login veranlasst, sendet das Terminal TL zunächst im Schritt 602 ein Login-Signal an die zentrale Indexie- rungseinrichtung Sl. Diese sendet dann im Schritt 603 ein Firewall-Testsignal zurück. Gleichzeitig wird in einer Zeitschleife 604 kontrolliert, ob ein entsprechendes Signal zurückkommt. Ist dies nicht der Fall, so wird davon ausgegangen, dass das Terminal TL durch eine Firewall gesichert ist, d .h. ein „Leaf ist. Im Schritt 605 sendet die zentrale Indexierungseinrichtung dann ein Login-Antwortsignal zurück, mit dem an das zum Upload bereite Terminal TL eine Adresse eines für das betreffende Terminal TL zuständigen, nicht durch eine Firewall gesicherten weiteren Terminals TH (im Folgenden auch „Hub" TH genannt) übermittelt wird. Es wird dann im Schritt 606 eine TCP- Verbindung zwischen dem Leaf TL und dem zuständigen Hub TH aufgebaut. Der Hub TH sendet dann im Schritt 607 eine Statusnachricht an die zentrale Indexierungseinrichtung Sl und eine Bestätigung an den Leaf TL. Anschlie- ßend sendet der Leaf TL im Schritt 609 ein Angebotssignal mit seiner Nut- zer-ID und den zum Upload zur Verfügung stehenden Dateien an die zentrale Indexierungseinrichtung Sl. Die weitere Verbindung kann dann immer über den zuständigen Hub TH erfolgen.
Figur 7 stellt als ein weiteres Beispiel den Fall dar, dass von einem solchen durch eine Firewall gesicherten Upload-Leaf TL ein Fragment auf ein Download-Terminal TD heruntergeladen werden soll.
Da in der zentralen Indexierungseinrichtung Sl bekannt ist, dass der Upload- Leaf TF über eine Firewall gesichert ist und nur über einen zugehörigen Hub TH ansprechbar ist, wird mit den Adressdaten an das Download-Terminal TD gleichzeitig die Adresse dieses zugehörigen Hub TH übermittelt. Das Download-Terminal TD kann dann im Schritt 701 zunächst ein „Push Request Signal" an das Hub-Terminal TH senden, welches ein entsprechendes Signal über die zuvor eingerichtete Verbindung im Schritt 702 an den Upload-Leaf TL sendet. Dieser kann daraufhin dann in Schritt 703 die Verbindung zum Download-Terminal TD öffnen, so dass im Schritt 704 das Download- Terminal TD in üblicher Weise ein Anfragesignal zum Download eines Fragments F an den Upload-Leaf TL senden kann und daraufhin im Schritt 705 das gewünschte Fragment erhält.
Auf diese Weise ist es ohne weiteres möglich, nicht nur zwischen zwei nicht Firewall-gesicherten Terminals Daten auszutauschen, sondern auch von einem durch Firewall gesicherten Terminal Dateien an ein ungesichertes Terminal herunterzuladen. Es muss lediglich dafür gesorgt werden, dass einem Leaf immer ein Hub zugeordnet ist. Sollte ein Hub ausfallen, kann durch entsprechende Aktionen der zentralen Indexierungseinrichtung Sl dem Leaf jederzeit ein neuer freier Hub zugewiesen werden, wobei der Ausfall des Hubs entweder durch den Leaf selber oder auch durch ein anderes Terminal, welches den Leaf ansprechen möchte, festgestellt werden kann und eine entsprechende Nachricht an die zentrale Indexierungseinrichtung Sl gesendet werden kann. Ebenso kann auch die zentrale Indexierungseinrichtung selber den Ausfall eines Hubs feststellen, beispielsweise, indem ein solcher Hub regelmäßig Statusnachrichten an die zentrale Indexierungseinrichtung Sl aussendet und das Ausbleiben einer solchen Nachricht von der zentralen Indexierungseinrichtung bemerkt wird. In ähnlicher Weise kann auch beim Ausfall eines Leafs durch den zugehörigen Hub ein Signal an die zentrale Indexierungseinrichtung Sl übermittelt werden.
Selbstverständlich ist es auch möglich, mit einem Firewall-gesicherten Terminal Dateien von einem ungesicherten Terminal herunterzuladen, da die Initiative hier ja ohnehin von dem anfragenden Terminal, in diesem Fall also von dem durch die Firewall gesicherten Download-Terminal, gestartet wird. Lediglich eine Verbindung zwischen zwei durch eine Firewall gesicherten Terminals ist mit diesem Verfahren nicht möglich.
Es wird abschließend noch einmal darauf hingewiesen, dass die vorbeschriebenen Ausführungsformen der Erfindung besonders bevorzugte beispielhafte Ausgestaltungen darstellen. Eine Vielzahl von Ausführungsformen des erfindungsgemäßen Verfahrens und der erfindungsgemäßen Vorrichtung sind vom Gedanken der Erfindung mit erfasst, auch wenn sie in den vorstehenden Ausführungen nicht ausführlich beschrieben wurden. Insbesondere sind auch verschiedenste Kombinationen der beschriebenen Varianten möglich. Es wird außerdem der Vollständigkeit halber darauf hingewiesen, dass, sofern nicht explizit anders erwähnt, die Verwendung der unbestimmten Artikel „ein" bzw. „eine" nicht ausschließt, dass die betreffenden Merkmale auch mehrfach vorhanden sein können, und das die Begriffe „Einrichtung", „Einheit" oder „Modul" nicht zwingend bedeuten, dass die betreffenden Komponenten nicht auch aus mehreren räumlich getrennten, zusammenwirkenden Teilen bestehen können.

Claims

Patentansprüche
1. Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (RS) an die Nutzer eines Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk (N), bei dem eine Datei (D)1 welche einen bestimmten von einem Download-Nutzer (U) gewünschten digitalen Inhalt enthält, zumindest teilweise von einem Terminal (T1 , T2) eines Upload-Nutzers aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers (U) übertragen wird, dadurch gekennzeichnet, dass von Terminals (T1 , T2) verschiedener Upload-Nutzer aus Fragmente (F) der Datei (D) an das Terminal (T2, T3) des Download- Nutzers (U) übertragen werden.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass zumindest ein Teil der Fragmente (F) der Datei (D) von einem Basis- Speicherterminal (SP, SP1 , SP2) aus an das Terminal des Download- Nutzers (U) übertragen werden, sofern kein oder zu wenige Terminals (T, T1 , T2, T3, Tn) von Upload-Nutzem zur Verfügung stehen, auf denen zumindest passende Teile der Datei (D) zu einer Übertragung bereit stehen.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass vom Terminal (T2, T3) des Download-Nutzers (U) aus an mögliche Up- load-Terminals (T1 , T2, SP), auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, Anforderungssignale zur Anforderung bestimmter Fragmente (F) der gewünschten Datei (D) gesendet werden.
4. Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (RS) an die Nutzer eines Inhalteübertragungssystems in einem Compu- ter-Kommunikationsnetzwerk (N)1 insbesondere nach einem der Ansprüche 1 bis 3, bei dem Fragmente (F) einer Datei (D), welche einen bestimmten von einem Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1 ,T2) aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers (U) übertragen wird, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) an ein mögliches Upload-Terminal (T1, T2, SP) einen Anforderungssignalblock sendet, mit dem gleichzeitig mehrere Fragmente (F) der gewünschten Datei (D) angefordert werden.
5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass vom Terminal (T2, T3) des Download-Nutzers (U) an eine zentrale Indexierungseinrichtung (Sl) eine Anfrage nach einem bestimmten Inhalt gesandt wird, dass von der zentralen Indexierungseinrichtung (Sl) eine Gruppe von Kandidaten-Upload-Terminals (T1 , T2, SP) ermittelt wird, auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, dass von der zentralen Indexierungseinrichtung (Sl) an das Terminal (T2, T3) des Download-Nutzers (U) Adressinformationen betreffend die Kandidaten-Upload-Terminals (T1 , T2, SP) übermittelt werden, und dass vom Terminal (T2, T3) des Download-Nutzers (U) aus zumindest an einen Teil der Kandidaten-Upload-Terminals (T1 , T2, SP) Anforderungssignale zur Anforderung bestimmter Fragmente (F) der gewünschten Datei (D) gesendet werden.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die zentrale Indexierungseinrichtung (Sl) von einem Terminal (T) eines Nutzers des Inhalteübertragungssystems, wenn auf diesem Terminal (T) Dateien zu einem Upload an andere Nutzer des Inhalteübertragungssystem bereit stehen, ein Angebotssignal empfängt, welches Informationen über die zur Verfügung stehenden Dateien enthält.
7. Verfahren nach einem der Ansprüche 3 bis 6, dadurch gekennzeichnet, dass eine Auswahl der Upload-Terminals (T1 , T2, SP), an welche vom Terminal (T2, T3) des Download-Nutzers (U) aus ein Anforderungssignal zur Übermittlung eines Fragments (F) ausgesandt wird, in Abhängigkeit von den einzelnen Upload-Terminals (T1 , T2, SP) zugeordneten Prioritätswerten erfolgt.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Datei (D) in eine Anzahl von definierten Segmenten (PO, P1, P2, P3, P4) zerlegt wird und jedem Segment (PO, P1, P2, P3, P4) eine eindeutige Kennung zugeordnet wird.
9. Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (RS) an die Nutzer eines Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk (N)1 insbesondere nach einem der Ansprüche 1 bis 8, bei dem ein Fragment (F) einer Datei (D), welche einen bestimmten von einem Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1 , T2) aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers (U) übertragen wird, dadurch gekennzeichnet, dass vom Terminal (T2, T3) des Download-Nutzers (U) aus, wenn von einem ersten Upload-Terminal (T1 , T2) ein zu übersendendes Fragment (F) nicht vollständig oder fehlerhaft empfangen wird, ein Anforderungssignal an ein anderes mögliches Upload-Terminal (T1 , T2, SP) gesandt wird, mit dem ein Fragment (FR) angefordert wird, welches dem fehlerhaften oder fehlenden Teil des vom ersten Upload-Terminal (T1 , T2) zu übersendenden Fragments (F) entspricht.
10. Verfahren nach einem der Ansprüche 3 bis 9, dadurch gekennzeichnet, dass ein Anforderungssignal des Terminals (T2, T3) des Download- Nutzers (U) an ein Upload-Terminal (T1 , T2, SP) die eindeutige Ken- nung der Datei (D) und/oder des Segments (PO, P1 , P2, P3, P4) der Datei, zu dem ein angefordertes Fragment (F1 FR) gehört, einen Offsetwert (OF, OFR), welcher die Position des Fragments (F, FR) innerhalb der Datei (D) oder des Segments (PO, P1, P2, P3, P4) der Datei (D) repräsentiert, und die Länge (lFl IFR) des Fragments (F, FR) enthält.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass ein Nutzer (U) sich zunächst innerhalb eines Authentifizie- rungsverfahrens (102, 122, 142, 507, 508) gegenüber einer Authentifi- zierungseinheit (SUA) authentifiziert und dem Nutzer (U) nach erfolgreicher Authentifizierung eine Authentifizierungskennung zugesandt wird und sich der Nutzer (U) dann im weiteren Verlauf des Verfahrens gegenüber anderen Funktionseinheiten des Inhalteübertragungssystems durch Übersendung der Authentifizierungskennung authentifiziert.
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Datei (D) mit dem gewünschten Inhalt in verschlüsselter Form an das Terminal (T1, T2, T3) des Download-Nutzers (U) übertragen wird und dem Download-Nutzer (U) vor der Übertragung von Fragmenten (F) der Datei (D) ein Schlüssel zur Entschlüsselung der Datei (D) übermittelt wird.
13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass an den Download-Nutzer (U) nach einer Auswahl eines vom Inhalteanbieter (RS) angebotenen digitalen Inhalts eine Dateiempfangsberechtigungs- kennung und eine Schlüsselempfangsberechtigungskennung zugesandt werden, und dass vom Download-Nutzer (U) die Dateiempfangs- berechtigungskennung an die jeweiligen Upload-Terminals (T1 , T2, SP) zum Erhalt von Fragmenten (F) der gewünschten Datei (D) und die Schlüsselempfangsberechtigungskennung an eine Lizenzerteilungseinrichtung (SL) zum Erhalt des Schlüssels weitergeleitet werden.
14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass nach einer Übermittlung von Fragmenten (F) einer Datei (D) von einem Terminal (T1 , T2) eines Upload-Nutzers an ein Terminal (T2, T3) eines Download-Nutzers (U) leistungsrelevante Daten vom Terminal (T1, T2) des Upload-Nutzers und/oder vom Terminal (T2, T3) des Download-Nutzers (U) an eine Transaktionskontrolleinrichtung (TC) gesandt werden und durch den Inhalteanbieter (RS) und/oder durch einen Betreiber (SB) des Inhalteübertragungssystems eine Vergütung des Upload-Nutzers für die Zur-Verfügung-Stellung seines Terminals (T1, T2) zur Übermittlung der Daten an das Terminal (T2, T3) des Download-Nutzers (U) erfolgt.
15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass ein Inhalteanbieter (RS) und der Betreiber (SB) des Inhalteübertragungssystems getrennte Organisationseinheiten sind und jeder Datei (D) mit einem von einem bestimmten Inhalteanbieter (RS) angebotenen digitalen Inhalt und/oder jedem Segment (PO, P1 , P2, P3, P4) einer solchen Datei (D) innerhalb des Inhalteübertragungssystems eine eindeutige Kennung zugeordnet ist, welche vom betreffenden Inhalteanbieter (RS) und vom Inhalt der Datei (D) oder des Segments (PO, P1. P2, P3, P4) abhängt.
16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass eine Datei (D) mit einen digitalen Inhalt, der von einem Nutzer des Inhalteübertragungssystems auf seinem Terminal (T, T1, T2, T3, TN) zu einem Upload an andere Nutzer des Inhalteübertragungssystems bereit gestellt werden soll, zunächst durch eine Instanz des Inhalteanbieters (RS) und/oder durch eine Instanz eines Betreibers (SB) des Inhalteübertragungssystems überprüft und der Datei (D) bei positiver Überprüfung eine Kennung zugeordnet wird.
17. Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass Informationen über die von einen bestimmten Nutzer auf sei- nem Terminal (T) zu einem Upload an andere Nutzer des Inhalteübertragungssystems bereitgestellten Inhalte von einer Angebotsinformationseinheit (4) des Terminals (T) des betreffenden Nutzers aus auf ein Terminal eines anderen Nutzers abrufbar sind.
18. Verfahren zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) auf ein Terminal (T2, T3) eines Download-Nutzers (U) eines Inhalteübertragungssystems, bei dem das Terminal (T2, T3) des Download-Nutzers (U) eine Datei (D), welche einen bestimmten, von dem betreffenden Download-Nutzer (U) gewünschten digitalen Inhalt enthält, zumindest teilweise von einem Terminal (T1 , T2) eines Upload-Nutzers des Inhalteübertragungssystems aus empfängt, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) Fragmente (F) der Datei (D) von Terminals (T1 , T2) verschiedener Upload-Nutzer aus empfängt.
19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers zumindest einen Teil der Fragmente (F) der Datei (D) von einem Basis-Speicherterminal (SP, SP1, SP2) empfängt, sofern kein oder zu wenige Terminals (T, T1 , T2, T3, TN) von Upload-Nutzern zur Verfügung stehen, auf denen zumindest passende Teile der Datei (D) zu einer Übertragung bereit stehen.
20. Verfahren nach Anspruch 18 oder 19, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) an mögliche Up- load-Terminals (T1 , T2, SP), auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, Anforderungssignale zur Anforderung bestimmter Fragmente (F) der gewünschten Datei (D) sendet.
21. Verfahren zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) auf ein Terminal (T2, T3) eines Download-Nutzers (U) eines Inhalteübertragungssystems, insbesondere nach einem der Ansprüche 18 bis 20, bei dem das Terminal (T2, T3) des Download-Nutzers (U) Fragmente (F) einer Datei (D), welche einen bestimmten, von dem betreffenden Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1 , T2) aus empfängt, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) an ein mögliches Upload-Terminal (T1 , T2, SP) einen Anforderungssignalblock sendet, mit dem gleichzeitig mehrere Fragmente (F) der gewünschten Datei (D) angefordert werden.
22. Verfahren nach Anspruch 20 oder 21 , dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) eine Anfrage nach einem bestimmten Inhalt an eine zentrale Indexierungseinrichtung (Sl) sendet, dass das Terminal (T2, T3) des Download-Nutzers (U) von der zentralen Indexierungseinrichtung (Sl) Adressinformationen betreffend mögliche Kandidaten-Upload-Terminals (T1 , T2, SP) empfängt, auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereitstehen, und dass das Terminal (T2, T3) des Download-Nutzers (U) zumindest an einen Teil der Kandidaten-Upload-Terminals Anforderungssignale zur Anforderung bestimmter Segmente der gewünschten Datei sendet.
23. Verfahren nach einem der Ansprüche 20 bis 22, dadurch gekennzeichnet, dass eine Datei (D) aus einer Anzahl von definierten Segmenten (PO, P1 , P2, P3, P4) besteht und jedem Segment (PO, P1 , P2, P3, P4) eine eindeutige Kennung zugeordnet ist und die Anforderungssignale des Terminals (T2, T3) des Download-Nutzers (U) an mögliche Upload- Terminals (T1 , T2, SP) die Kennung des Segments (PO, P1 , P2, P3, P4) enthalten, zu welchem das angeforderte Fragment (F) gehört.
24. Verfahren, zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) auf ein Terminal (T2, T3) eines Download-Nutzers (U) eines Inhalteübertragungssystems, insbesondere nach einem der Ansprüche 18 bis 23, bei dem das Terminal (T2, T3) des Download-Nutzers (U) ein Fragment (F) einer Datei (D), welche einen bestimmten, von dem betreffenden Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1 , T2) aus empfängt, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U), wenn von einem ersten Upload-Terminal (T1 , T2) ein zu übersendendes Fragment (F) nicht vollständig oder fehlerhaft empfangen wird, ein Anforderungssignal an ein anderes Kandidaten-Upload-Terminal (T1 , T2, SP) sendet, mit dem ein Fragment (FR) angefordert wird, welches dem fehlerhaften oder fehlenden Teil des vom ersten Upload-Terminal (T1 , T2) zu übersendenden Fragments (F) entspricht.
25. Verfahren nach einem der Ansprüche 20 bis 24, dadurch gekennzeichnet, dass ein Anforderungssignal des Terminals (T2, T3) des Download-Nutzers (U) an ein Upload-Terminal (T1 , T2, SP) die eindeutige Kennung der Datei (D) und/oder des Segments (PO, P1 , P2, P3, P4) der Datei (D), zu dem ein angefordertes Fragment (F, FR) gehört, einen Offsetwert (OF, OFR), welcher die Position des Fragments (F, FR) innerhalb der Datei (D) bzw. des Segments (PO, P1, P2, P3, P4) der Datei (D) repräsentiert, und die Länge (IF, IFR) des Fragments (F, FR) enthält.
26. Verfahren nach einem der Ansprüche 18 bis 25, dadurch gekennzeichnet, dass die Datei (D) mit dem gewünschten Inhalt in verschlüsselter Form an das Terminal (T2, T3) des Download-Nutzers (U) übertragen wird und das Terminal (T2, T3) des Download-Nutzers (U) vor dem Empfang von Fragmenten (F) der Datei (D) einen Schlüssel empfängt und bereits empfangene Teile der Datei (D) vor einer Beendigung des vollständigen Datei-Downloads entschlüsselt.
27. Computerprogrammprodukt, welches direkt in einen Speicher eines programmierbaren Terminals ladbar ist, mit Programmcode-Mitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 18 bis 26
5 auszuführen, wenn das Programmprodukt auf dem Terminal ausgeführt wird.
28. Inhalteübertragungssystem zur Übertragung digitaler Inhalte eines Inhalteanbieters (RS) auf ein Terminal (T2, T3) eines Download-Nutzers ιo (U) des Inhalteübertragungssystems in einem Computer-
Kommunikationsnetzwerk (N), mit einer Transferinitialisierungseinrichtung, welche nach Empfang einer Anfrage eines Download-Nutzers (U) nach einem bestimmten Inhalt das Terminal (T2, T3) des Download- Nutzers (U) dazu veranlasst, Fragmente (F) der Datei (D) mit dem ge- i5 wünschten Inhalt von verschiedenen ausgewählten Kandidaten-Upload-
Terminals (T1 , T2, SP) zu empfangen.
29. Inhalteübertragungssystem nach Anspruch 28, gekennzeichnet durch ein Basis-Speicherterminal (SP, SP1 , SP2) zur Übertragung einer Datei
>o (D) mit dem betreffenden digitalen Inhalt an ein Terminal (T1 , T2) eines
Download-Nutzers (U), sofern kein oder zu wenige Terminals von Up- load-Nutzer zur Verfügung stehen, auf denen zumindest passende Teile der Datei (D) zu einer Übertragung bereit stehen.
>5 30. Inhalteübertragungssystem nach Anspruch 28 oder 29, dadurch gekennzeichnet, dass die Transferinitialisierungseinrichtung eine zentrale Indexierungseinrichtung (Sl) umfasst, mit - einer Speichereinrichtung (DSI), welche Informationen enthält, auf welchen Terminals (T, T1 , T2, T3, TN) verschiedener Nutzer des In- (0 halteübertragungssystems und/oder auf welchen Basis-Speicherterminals (SP, SP1 , SP2) welche Inhalte zu einer Übertragung an Nutzer über das Computer-Kommunikationsnetzwerk (N) bereitgestellt sind, - und einer Auswahleinheit (SU), um nach Empfang einer Anfrage eines Download-Nutzers (U) nach einem bestimmten Inhalt aus den Terminals (T, T1 , T2, T3, Tn, SP, SP1 , SP2), auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, eine Gruppe von Kandidaten-Upload-Terminals (T1 , T2, SP) zu ermitteln.
31. Inhalteübertragungssystem nach einem der Ansprüche 28 bis 30, gekennzeichnet durch eine Transaktionskontrolleinrichtung (TC), welche nach einer Übermittlung von Fragmenten der Datei von Upload- Terminals (Tl 1 T2) an das Terminal (T2, T3) des Download-Nutzers (U) leistungsrelevante Daten von den Upload-Terminals und/oder vom Terminal (T2, T3) des Download-Nutzers (U) empfängt, um eine Vergütung der Upload-Nutzer für die Zur- Verfügung-Stellung der jeweiligen Upload-Terminals (T1 , T2) zur Übermittlung der Daten an das Terminal (T2, T3) des Download-Nutzers (U) zu ermitteln.
32. Terminal (T, T1 , T2, T3, Tn) zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) mit einer Netzwerkschnittstelle (Nl) zum Empfang von Fragmenten (F) der Datei (D) von anderen am Computer-Kommunikationsnetzwerk (N) angeschlossenen Terminals (T, T1 , T2, T3, Tn) und mit einer Transaktionssteuereinheit (1), welche so ausgebildet ist, dass das Terminal (T, T1 , T2, T3, Tn) Fragmente (F) der Datei (D) von Terminals (T, T1, T2, T3, Tn) verschiedener Upload-Nutzer aus empfängt.
EP05751848A 2005-03-02 2005-06-11 Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems Withdrawn EP1854261A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005010131A DE102005010131A1 (de) 2005-03-02 2005-03-02 Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems
PCT/EP2005/006274 WO2006092158A1 (de) 2005-03-02 2005-06-11 Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems

Publications (1)

Publication Number Publication Date
EP1854261A1 true EP1854261A1 (de) 2007-11-14

Family

ID=34970488

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05751848A Withdrawn EP1854261A1 (de) 2005-03-02 2005-06-11 Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems

Country Status (6)

Country Link
US (1) US20060200736A1 (de)
EP (1) EP1854261A1 (de)
BR (1) BRPI0520040A2 (de)
DE (1) DE102005010131A1 (de)
RU (1) RU2007136164A (de)
WO (1) WO2006092158A1 (de)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070157266A1 (en) * 2005-12-23 2007-07-05 United Video Properties, Inc. Interactive media guidance system having multiple devices
US7710958B2 (en) * 2006-01-20 2010-05-04 Iona Technologies Limited Method for recoverable message exchange independent of network protocols
US8738778B2 (en) * 2006-04-26 2014-05-27 Bittorrent, Inc. Peer-to-peer download and seed policy management
US7937362B1 (en) * 2006-04-28 2011-05-03 Roxbeam Media Network Corporation System and method for facilitating a credit system in a peer-to-peer content delivery network
EP1858226B1 (de) * 2006-05-19 2010-09-22 Microsoft Corporation Inhaltsverwaltung in Peer-to-peer Datenverteilungswolken
US9317506B2 (en) * 2006-09-22 2016-04-19 Microsoft Technology Licensing, Llc Accelerated data transfer using common prior data segments
US8775562B2 (en) * 2006-12-05 2014-07-08 International Business Machines Corporation Mapping file fragments to file information and tagging in a segmented file sharing system
US8131673B2 (en) * 2006-12-05 2012-03-06 International Business Machines Corporation Background file sharing in a segmented peer-to-peer file sharing network
US9794310B2 (en) * 2007-01-11 2017-10-17 Samsung Electronics Co., Ltd. Meta data information providing server, client apparatus, method of providing meta data information, and method of providing content
EP2835951B1 (de) * 2007-01-17 2018-08-22 Intertrust Technologies Corporation Verfahren, systeme und vorrichtung zur teilung fragmentierter dateien
DE102007013014A1 (de) * 2007-03-14 2008-09-18 Deutsche Telekom Ag Verfahren zur Online-Distribution von DRM-Nutzinhalten
US8280958B2 (en) * 2009-07-13 2012-10-02 International Business Machines Corporation List passing in a background file sharing network
US8204791B2 (en) * 2009-07-13 2012-06-19 International Business Machines Corporation File fragment pricing in a segmented file sharing network
JP2011097421A (ja) * 2009-10-30 2011-05-12 Panasonic Corp 通信端末装置及びコンテンツデータ受信方法
EP2447843B1 (de) * 2010-10-06 2013-07-03 Siemens Aktiengesellschaft Verfahren zur Verifizierung eines Anwendungsprogramms einer fehlersicheren Speicherprogrammierbaren Steuerung, und Speicherprogrammierbare Steuerung zur Ausführung des Verfahrens
US8880603B2 (en) 2011-06-07 2014-11-04 Interdigital Patent Holdings, Inc. Peer to peer (P2P) operation by integrating with content delivery networks (CDN)
US8719345B2 (en) * 2012-05-11 2014-05-06 Oracle International Corporation Database replication using collaborative data transfers
US8484347B1 (en) * 2012-06-19 2013-07-09 Kaspersky Lab Zao System and method for malware detection in peer-to-peer computer networks
EP2704053B1 (de) * 2012-08-27 2016-09-21 Giesecke & Devrient GmbH Verfahren und System zur Aktualisierung einer Firmware eines Sicherheitsmoduls
US9749663B1 (en) * 2014-11-23 2017-08-29 Silicondust Usa Inc. Distributed upload of television content
DE102018103077A1 (de) * 2018-02-12 2019-08-14 Rauner David Verfahren, Prozessor, nichtflüchtiger Speicher und Recheneinheit

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6219652B1 (en) * 1998-06-01 2001-04-17 Novell, Inc. Network license authentication
US7272645B2 (en) * 2001-05-25 2007-09-18 Sbc Technology Resources, Inc. Method of improving the reliability of peer-to-peer network downloads
KR20010088742A (ko) * 2001-08-28 2001-09-28 문의선 분산처리 및 피어 대 피어 통신을 이용한 네트워크 상의정보전송 병렬화 방법
KR20040013726A (ko) * 2002-08-08 2004-02-14 케이티하이텔 주식회사 온라인 컨텐츠 분배방법 및 장치
GB0303192D0 (en) * 2003-02-12 2003-03-19 Saviso Group Ltd Methods and apparatus for traffic management in peer-to-peer networks
GB0315886D0 (en) * 2003-07-07 2003-08-13 Way Benjamin B P Anti-piracy system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006092158A1 *

Also Published As

Publication number Publication date
DE102005010131A1 (de) 2006-09-07
WO2006092158A1 (de) 2006-09-08
RU2007136164A (ru) 2009-04-20
US20060200736A1 (en) 2006-09-07
BRPI0520040A2 (pt) 2009-04-14

Similar Documents

Publication Publication Date Title
EP1854261A1 (de) Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems
DE60130377T2 (de) Verfahren zur steuerung des zugriffs auf digitalen inhalt und streaming-medien
DE69534052T2 (de) System zur Steuerung der Verteilung und Benutzung von Digitalwerken
DE69531439T2 (de) System zur Steuerung der Verteilung und Benutzung von Digitalwerken mit einer Gebührenmeldvorrichtung
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE69535248T2 (de) System und Verfahren zur Steuerung der Verteilung und Benutzung von Digitalwerken, das eine Nutzungsrechtsgrammatik verwendet
DE602004011282T2 (de) Versenden einer Herausgeber-Benutzungslizenz off-line in einem digitalen Rechtesystem
DE60214836T2 (de) Verfahren und netzwerk zum abliefern von streaming-daten
DE60212920T3 (de) Verfahren und system zur verwaltung von digitalen abonnementrechten
DE69533847T2 (de) System zur Steuerung der Verteilung und Benutzung von zusammengesetzten Digitalwerken
DE69728182T2 (de) Verfahren und gerät zum entfernten netzwerkzugriffseintrag und netzwerkzugriffsbericht
DE19960978B4 (de) Verfahren zum Steuern des Zugriffs auf in einem Datenarchivsystem gespeicherte elektronische Datendateien
DE60036713T2 (de) System und verfahren für gesicherte netzwerkstransaktionen
WO2004015952A2 (de) Vorrichtung zum kopiergeschützten verteilen elektronischer dokumente
DE102006027030A1 (de) Vorrichtung und Verfahren zum geschützten Verteilen elektronischer Dokumente
DE112016003268T5 (de) Systeme, Verfahren und Medien für Mediensitzungs-Parallelitätsmanagement mit wiederkehrenden Lizenzerneuerungen
EP1971106A2 (de) Verfahren zur Online-Distribution von DRM-Nutzinhalten
DE112015002469T5 (de) Architektur und Verfahren für eine gemeinsame Nutzung und/oder eine Verteilung eines Inhalts
EP1224807A1 (de) Vorrichtung und verfahren zum kopiergeschützten verteilen elektronischer dokumente
US20050108361A1 (en) Method and system for content delivery
WO2019180152A1 (de) Automatisiertes verfahren zum schutz von elektronischen daten zum zwecke der datenverarbeitung durch dritte unter einbezug transparenter und unterbrechungssicherer vergütung
JP4649744B2 (ja) コンテンツ無料配信装置および方法、ならびに、コンテンツ無料配信プログラムおよび記録媒体
DE102005062061B4 (de) Verfahren und Vorrichtung zum mobilfunknetzbasierten Zugriff auf in einem öffentlichen Datennetz bereitgestellten und eine Freigabe erfordernden Inhalten
DE102007027019A1 (de) Vorrichtung und Verfahren zur clientseitigen Freigabe elektronischer Dokumente
WO2006087290A2 (de) Distributionssystem für daten eines dienstes

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070906

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130103