Peer To Patent

21

A system that facilitates data distribution in a peer to peer network, comprising:a bulletin board that maintains a list of requests, the requests being in a predefined machine readable format;

a plurality of nodes that make requests for data, fill requests for data and register periodically at a check in frequency; and

an access layer that tracks and enforces fairness among the plurality of nodes, such that the plurality of nodes contribute to the system.

Relevance

This claim describes the form and function of the typical BitTorrent tracker, including the original official implementation.

Claim Chart

All

22

The system of Claim 21, further comprising a host computer that controls the bulletin board and the access layer.

Relevance

This is a common feature of many BitTorrent trackers (including XBNBT <http://xbnbt.sourceforge.net/> ), which either interface with an existing bulletin board (such as PHPBB) or implement their own (as with The Pirate Bay's custom tracker).

Claim Chart

All

23

The system of Claim 21, wherein the check in frequency for respective nodes is assigned by the access layer according to a number of nodes in the system, types of data requested, and a ratio of requests filled and made.

Relevance

This is a common function of nearly every modern BitTorrent client. Tracker request ("announce") timing is set based on previous requests, the time for the tracker to fulfill a request and the need of a client for more peer connections.

Claim Chart

All

24

The system of Claim 21, wherein the bulletin board computes weightings regarding popularity of data and assigns such weightings to the requests in the list of requests.

Relevance

This is a common feature of many BitTorrent trackers (including XBNBT <http://xbnbt.sourceforge.net/> ) that include a web interface. These typically have some way of ranking torrents by popularity as well as by availability.

Claim Chart

All

25

The system of Claim 21, wherein the access layer tracks performance statistics for the plurality of nodes and regulates requests by the plurality of nodes based on the performance statistics.

Relevance

Most modern BitTorrent trackers support this.

Claim Chart

All

26

The system of Claim 25, wherein the performance statistics comprise proper check ins, requests filled and requests made.

Relevance

A common feature of BitTorrent trackers.

Claim Chart

All

27

The system of Claim 26, wherein the access layer computes a performance ratio of requests satisfied versus requests made over time, the access layer then prevents nodes from making requests if the computed performance ratio is below a threshold value.

Relevance

This is a common feature of most client software, including Azureus, Rtorrent, Ctorrent, uTorrent, and any others.

Claim Chart

All

28

The system of Claim 26, wherein the access layer provide respective nodes with an initial number of serving credits and then adds credits for requests filled and removes credits for requests made, such that a node can only make a request if the node has a predetermined number of credits available.

Relevance

This is a common feature of most "private" trackers and is implemented by many popular open source trackers.

Claim Chart

All

29

The system of Claim 26, wherein the access layer determines if the nodes are regularly checking in by computing a percentage based on a number of times checked in versus a number of times a node should have checked in, such that the nodes receive credits for properly checking in and lose credits for failing to check in.

Relevance

This is done by some trackers (especially private trackers), where users are temporarily "banned" from the tracker when "improper" behavior is detected or occasionally when an unapproved client is used.

Claim Chart

All

30

The system of Claim 26, wherein the access layer determines whether nodes of the plurality of nodes are active by monitoring check ins, requests filled and requests made, such that inactive nodes are detected by failing to check in, fill a request or make a request within a selected time out value and are removed from the system.

Relevance

This is a common heuristic (including within the original official implementation) of tracker software. It is used to de-list a client from the announce when it has "timed out."

Claim Chart

All

31

The system of Claim 30, wherein the performance statistics of inactive nodes is retained and reused if the inactive nodes rejoin the system.

Relevance

A common feature of BitTorrent tracker software which includes a "membership" functionality. This is common with private trackers and many public trackers which have a login.

Claim Chart

All

32

The system of claim , at least a subset of the nodes working in unison to satisfy a particular request, each of the nodes of the subset fulfilling a portion of the request.

Relevance

This is a standard feature, described as part of the original official BitTorrent specification.

Claim Chart

All

33

The system of claim , the requests being respectively aged, the aging of requests being a function of demand of an item associated with a request.

Relevance

This is a common function of a BitTorrent tracker, where old and unused torrents (usually ones which have not had "seed" clients for some specified period of time) are deleted and are no longer accepted for announces on the tracker.

Claim Chart

All

34

The system of Claim 33, the request being removed from the list upon an age thereof exceeding a threshold value.

Relevance

This is a common function of a BitTorrent tracker, where old and unused torrents (usually ones which have not had "seed" clients for some specified period of time) are deleted and are no longer accepted for announces on the tracker.

Claim Chart

All

35

A method of facilitating data distribution in a peer to peer network, comprising:maintaining a list of requests, the requests being in a predefined machine readable format;

providing a plurality of nodes that make requests for data, fill requests for data and register periodically at a check in frequency;

determining which requests of the list of requests to fill based on factors associated with the request, the factors include age, size of the requested data and available bandwidth; and

tracking performance statistics for the plurality of nodes and regulating requests by the plurality of nodes based on the performance statistics, wherein the performance statistics comprise proper check ins, requests filled and requests made.

Relevance

This is a common feature of BitTorrent clients that support the "super-seed mode" extension of the protocol. <http://home.elp.rr.com/tur/superseed.txt> This was first implemented in the BitTornado client in mid-2003.

Claim Chart

All

36

The method of Claim 35, further comprising computing a performance ratio of requests satisfied versus requests made over time, and preventing nodes from making requests if the computed performance ratio is below a threshold value.

Relevance

This is a common feature of modern BitTorrent clients implementing "super-seed mode."

Claim Chart

All

37

The method of Claim 35, further comprising providing respective nodes with an initial number of serving credits and then adding credits for requests filled and removing credits for requests made, such that a node can only make a request if the node has a predetermined number of credits available.

Relevance

This is a variation of the heuristic used by nearly every BitTorrent client, which penalizes peers for excessive "leeching" by ignoring requested pieces. Claim 35 is not a pre-requisite.

Claim Chart

All

39

The method of Claim 35, further comprising providing a subset of the nodes working in unison to satisfy a particular request, each of the nodes of the subset fulfilling a portion of the request.

Relevance

This is a normal case of most BitTorrent clients, which may request the same piece from multiple peers. This has been a standard feature since at least before version 3.9 of the official client.

Claim Chart

All

40

A system that facilitates data distribution in a peer to peer network, comprising:means for maintaining a list of requests, the requests being in a predefined machine readable format;

means for storing the requests on a bulletin board;

means for providing a plurality of nodes that make requests for data, fill requests for data and register periodically at a check in frequency;

means for weighting the requests, the weighting being a function of supply and demand for an item; and

means for tracking performance statistics for the plurality of nodes and regulating requests by the plurality of nodes based on the performance statistics, wherein the performance statistics comprise proper check ins, requests filled and requests made.

Relevance

This is a standard function of any BitTorrent tracker that reorders its announce list based on the reported speed of a client.

Claim Chart

All

Type of Prior Art	Source Code

Name/Title	BitTorrent

Publication Date	July 2, 2001

Author	Bram Cohen

URL	http://www.bittorrent.com

System Type	Application Program

Printed Materials (Documentation, Manual, Training Guide, Literature, et cetera)	Yes

Online Source Code Repository	Yes

Online project documentation	Yes

Storage Media (Floppy disk, CD-ROM, Tape, et cetera)	No

Other	No

How to Locate the Evidence (e.g. Location of the System Documentation -- Product Manual, User Guide, or Training Guide)	http://download.bittorrent.com/dl/

URL for Software Repository

URL for Product Description	http://www.bittorrent.org/beps/...

Licensing Model	Open Source

Programming Language	Python

Summary / Description	The BitTorrent protocol (designed and freely released in 2001) is a protocol in which clients connect to a server (called the tracker) which tracks the clients and forwards connection information among them.

Notes	The license has changed from open source to proprietary in the most recent version. Older versions are still available.