decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
BitTorrent - It's not just about copyright any more
Tuesday, June 21 2011 @ 09:00 AM EDT

Peer-to-peer provider BitTorrent is somewhat familiar with being at the center of copyright controversies, but last Tuesday, June 14, it entered the realm of patent disputes when it was sued by Tranz-Send Broadcasting Network, Inc., a Delaware corporation, for infringement of Tranz-Send's U.S. patent number 7,301,944 (the '944 patent). The '944 patent, entitled "Media File Distribution With Adaptive Transmission Protocols," was filed on April 16, 1999, and issued November 27, 2007.

This patent claims priority back to an application filed on October 24, 1997, so that is the relevant priority date for any prior art. The abstract for the patent describes the invention as follows:
A server/client media file distribution system is provided in which the server system is adapted to receive transmission requests from clients, status information from a network, and protocol information from each client. The server, based upon this information, adaptively transmits a given media file stored therein to one or more clients using the optimal transmission speed and/or network protocol based on the network status information and protocol information. Additionally, the present invention provides a looping file arrangement in which a plurality of clients can receive the same media file on multiple network channels, without the need to provide multiple copies of the same media file for each request of that file.
Of course, patent abstracts are notorious for not really describing the claimed invention, so we have reproduced the description and the claims of the '944 patent below. Tranz-Send asserts that, at a minimum, Bittorrent infringes claim 1 of the patent, describing the alleged infringement like this in the complaint [PDF]:
6. The '944 patent is directed to a software application to solve problems with sending large data over networks, accomplished by splitting data into smaller bits and spraying those bits across the networks, where the bits of data will reside and/or get redistributed on any requesting or accepting server and/or computer.

. . .

On information and belief, BitTorrent implements, facilitates, oversees and manages a peer-to-peer (P2P) file sharing network allowing users to download and upload large data files while redistributing and, thus, reducing upload/download costs and bandwidths, as well as alleviating the burden of having to provide mulitple copies of requested files over a network.

10. Through the use of the BitTorrent protocol, BitTorrent provides and implements various clients, i.e., computer programs, such BitTorrent Mainline, BitTorrent Software versions (6.0 and others), Mu (micro) Torrent, and more, adapted to be implemented by users and over the network for file sharing among peers. Accordingly, the above BitTorrent software (BTS) is implemented by users, such a companies, organizations or individuals for distributing files across a network in response to multiple requests.

11. By making, operating, using and/or selling the BTS and/or other software, BitTorrent has infringed and continues to infringe, contribute to the infringement of, or induce the infringement of at least claim 1 of the '944 patent, either literally or under the doctrine of equivalents.

By the way, Bittorrent is not the only defendant; Tranz-Send has also asserted the '944 patent against Kontiki, Inc. in this same suit.

Tranz-Send is not your stereotypical patent troll. It is a start-up company in the Bay Area focused on "developing the BlockBuster of the Internet, by electronic transfer to computers which are conected to the TV, for the same cost of rental plus a dime." It's CEO is a fellow named Scott Redmond, who, if he is the same Scott Redmond who started Peep Telephony, comes with some baggage. He certainly thinks highly of himself. Given all of that, one has to wonder whether Tranz-Send isn't just a fiction to hide the troll activity.

Our interest in this case arises from the important role that peer-to-peer transmissions play in the development of free and open source software, so it will be interesting to follow.

***********

Patent 7,301,944 - Claims and description
[NB: We have not reproduced the drawings associated with the description. You can find those drawings in the PDF of the complaint.]

CLAIMS

The invention claimed is:

1. A media distribution system, comprising: a media file database configured to store media files, wherein one or more of the media files have been compressed prior to storage in the media file database; a computing device configured to receive user requests for delivery of the one or more of the media files stored in the media file database, the computing device further configured to: identify average network throughput between computing device and the requesting users; and route the user requests for delivery of the requested one or more media files to a distribution server capable of servicing the user requests based upon at least the average network throughput; and a distribution server coupled to the media file database, the distribution server configured to simultaneously deliver a single copy of the requested one or more of the media files identified in the routed user requests to the requesting users in less-than-real-time, wherein the distribution server automatically adjusts delivery of the requested one or more media files to the requesting users based on current average network throughput between the distribution server and the requesting users.

2. The system of claim 1, wherein one or more of the media files is divided into a plurality of frames, at least one of the plurality of frames including a header.

3. The system of claim 2, wherein one or more of the media files have been encrypted prior to storage in the media file database.

4. The system of claim 3, wherein at least one of the plurality of frames includes an encryption frame key in the header.

5. The system of claim 1, wherein one or more of the media files includes a digital watermark identifying a source of the one or more media files.

6. The system of claim 1, wherein one or more of the media files includes a digital watermark identifying ownership of the one or more media files.

7. The system of claim 1, wherein the computing device is further configured to identify a transmission protocol for delivery of the requested one or more media files to the requesting users.

8. The system of claim 7, wherein the computing device is further configured to route the user requests for delivery of the requested one or more media files to a distribution server capable of servicing the user requests further based upon at least the identified transmission protocol.

9. The system of claim 8, wherein the identified transmission protocol includes a multicast transmission protocol and the distribution server simultaneously delivers the one or more media files via a multicast transmission to the requesting users.

10. The system of claim 9, wherein the distribution server is further configured to repeat the transmission of the one or more media files via the multicast transmission to the requesting users until each of the requesting users has received the entirety of the one or more media files.

11. The system of claim 1, further comprising an advertisement database configured to store advertisement media files.

12. The system of claim 11, wherein an advertisement media file from the advertisement database is concatenated to the one or more media files based on at least an association parameter.

13. The system of claim 1, further comprising a financial transaction server configured to process a payment for delivery of the one or more media files requested by a user.

14. The system of claim 1, further comprising a second distribution server coupled to a second media file database, the second media file database configured to store media files, wherein one or more of the media files have been compressed prior to storage in the second media file database.

15. The system of claim 14, wherein the computing device is further configured to determine if the distribution server is no longer able to simultaneously deliver the requested one or more of the media files identified in the routed user requests to the requesting users in less-than-real-time after commencing delivery of the requested one or more media files.

16. The system of claim 15, wherein the computing device is further configured to reroute responsibility for the continued delivery of the requested one or more media files to the second distribution server.

17. The system of claim 14, wherein the computing device is further configured to determine if the distribution server is no longer able to optimally and simultaneously deliver the requested one or more of the media files identified in the routed user requests to the requesting users after commencing delivery of the requested one or more media files.

18. The system of claim 17, wherein the computing device is further configured to automatically and dynamically re-route responsibility for the continued delivery of the requested one or more media files between the first and second distribution server depending on at least the average network throughput.

DESCRIPTION

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to media file distribution, and, more particularly, to a media file distribution system with adaptive transmission protocols in a networked client/server environment which provides automated, highly compressed, user-selectable media file distribution. Particular utility of the present invention is in less-than real-time server-client audio/video file distribution over conventional networks; although the present invention has equal utility in still image and/or high-resolution image file data distribution (e.g., x-ray, MRI, etc.).

2. Description of Related Art

Multimedia file distribution systems, which include distribution of audio and/or video information, are well known in the art. Examples include video-on-demand systems and network-based real-time streaming video systems and methodologies. Recent developments in high-speed network communications (e.g., ISDN, DSL, cable modems, etc.) have permitted the development of real-time streaming video data distribution in a client/server environment. Such systems typically employ extensive video file server systems that can transmit streaming video file data directly to a user's television set or PC (via, for example, Internet communications protocols (e.g., TCP/IP connections based on HTTP or FTP file transfer protocols). These systems typically transmit a separate copy of the streaming video file to each receiver. This uses additional network bandwidth for each additional receiver. This can quickly lead to saturated networks, degrading the quality of the streaming video received, as well as impacting other users and uses of the network. Examples of such file distribution systems are described in U.S. Pat. Nos. 5,132,992; 5,253,275; and 5,550,863 issued to Yurt et al., and hereby incorporated by reference.

Conventional file transfer techniques use either the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) for the transmission of the data. These two protocols are part of the standard TCP/IP protocol suite. TCP is a connection-based protocol, meaning that there is a logical connection opened between the two systems involved in the transfer. Because of the connection, and the TCP protocol process, this connection is a "reliable connection." This means that packets are guaranteed to be received, intact and in order, or the connection is broken. Examples of common use of TCP would be browsing on the World Wide Web, File Transfer Protocol, sending and reading email, etc.

UDP is a connectionless protocol, meaning that there is no open connection as you would find in a TCP session. Packets are transmitted by the sender and addressed to the receiver. UDP is not a "Reliable protocol". Packets in a UDP session, may be received out of sequence and may even be lost. Applications must either accept this loss, or implement some other means for ensuring reliability. Examples of common use of UDP would be Domain Name Service queries, RealAudio/RealVideo, network management functions, etc. Both TCP and UDP are designed for use between two systems. UDP can also be used for "Broadcast". Broadcast packets are limited to a single Local Area Network (LAN), and so will not cross any routers connected to that LAN.

Current development in the area of IP Multicasting are improving the art in areas such as reliability, performance, session management, network management, statistical research, router management, routing protocols, and other areas required for the smooth operation of IP Multicasting on public networks (e.g., The Internet). However, this art has not overcome the aforementioned problems: either the bandwidth requirements for multiple client access are too large, or the transmission protocol becomes unreliable. Moreover, the prior art is incapable of providing a system which can analyze client transmission demands and adaptively adjust the transmission protocols to most effectively accommodate a plurality of users.

SUMMARY OF THE INVENTION

Accordingly, the present invention solves the aforementioned drawbacks of the prior art by providing a server/client media file distribution system in which the server system is adapted to receive transmission requests from clients. The server also receives status information from a network, and protocol information from each client. The server, based upon this information, adaptively transmits a given media file stored therein to one or more clients using the optimal transmission speed and/or network protocol based on the network status information and protocol information.

In the preferred system, the present invention provides a media file distribution system having a file distribution server system comprising a media file archive database in communication with one or more users over a network, said media file archive comprising one or more precompressed and pre-encrypted media data files, said server being for receiving one or more transmission requests for a selected media file from a plurality of users, the improvement comprising a file distribution system being adapted to receive a plurality of said transmission requests from a plurality of users, the transmission protocols of said plurality of said users and status information from said network and optimally simultaneously transmit said media file to each user based on said transmission protocols and said status information.

Additionally, the present invention provides a looping file arrangement in which a plurality of clients can receive the same media file on multiple network channels, without the need to provide multiple copies of the same media file for each request of that file. Also, the present invention provides multiple-level encryption technology that permits the server system to fully control both access and use of a given media file.

It will be appreciated by those skilled in the art that although the following Detailed Description will proceed with reference being made to preferred embodiments and methods of use, the present invention is not intended to be limited to these preferred embodiments and methods of use. Rather, the present invention is of broad scope and is intended to be limited as only set forth in the accompanying claims.

Other features and advantages of the present invention will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and wherein:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the media file client/server system of the present invention;

FIG. 2 is a block diagram of the preferred network arrangement of the file distribution server system of the present invention;

FIG. 3 is a block diagram of the preferred media file database system of the present invention;

FIG. 4A is a block diagram of the preferred media file distribution system of the present invention;

FIG. 4B is a flow chart diagram of the preferred media file distribution system of FIG. 4A;

FIG. 4C is a flow chart diagram of the preferred media file transmission protocol of the present invention;

FIG. 4D is a flow chart diagram of the preferred file transmission of the present invention.

FIG. 5 is a block diagram of one embodiment of the media file playback system of the present invention;

FIG. 6 is a block diagram of another embodiment of the media file playback system of the present invention.

FIG. 7 is a block diagram of another embodiment of the media file playback system of the present invention; and

FIG. 8 is a block diagram of the user control interface system of the present invention;

FIG. 9A is a block diagram of convention network data transmission;

FIG. 9B is the preferred network data transmission of the present invention; and

FIG. 10 is a flowchart of the preferred server-client data transmission including the preferred de-encryption process of the present invention.

It will be appreciated by those skilled in the art that although the following Detailed Description will proceed with reference being made to preferred embodiments, the present invention is not intended to be limited to these embodiments. For example, it should be understood from the outset that although preferably the functional components of the preferred embodiments of the system of the present invention are embodied as one or more distributed computer program processes running on one or more conventional general purpose computers (e.g., IBM-compatible, Apple MacIntosh, and/or RISC microprocessor-based computers), conventional telecommunications (e.g., modem and/or ISDN means), networked together by conventional network hardware and software, other types of computers and network resources may be used without departing from the present invention. It should also be understood that the media file playback devices herein described can be embodied in various hardware forms, including: RAM/ROM drives, removable and/or permanent disk drives (including, but not limited to, hard disk drives, Jazz drives, and/or other removable media known in the art). Furthermore, it should be appreciated from the outset that one or more of the functional components may alternatively be constructed out of custom, dedicated electronic hardware and/or software, without departing from the present invention. Thus, the present invention is intended to cover all such alternatives, modifications, and equivalents as may be included within the spirit and broad scope of the invention as defined only by the hereinafter appended claims.

Additionally, as used herein, the term "Unicast" describes a file transfer session between a single server and a single client receiver, using either TCP or UDP. The term "Multicast" (or more specifically "IP Multicast") describes a file transfer session between a single server and a plurality of client receivers. Because of the additional clients, all Multicast sessions must be based on the UDP protocol as the TCP protocol specification does not allow for more than two endpoints for the connection.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 is a block diagram of the media file client/server system of the present invention. Shown in FIG. 1 is a file distribution server 12 (which includes media file database system 18 and client database 20), a client (user) system 14 (which includes a media file playback system 24), connected via a network system 16. As an overview, the present invention is intended to provide media file distribution in a server/client environment. Media files can be any of feature films, television programs, audio files, or any other combination of audio and/or video programming. Further, media files can also contain non-media data. The following detailed description will be in reference to audio/video file distribution, and in particular, to full-length video file (i.e., feature film) distribution. The present invention is intended to permit a user to access the file distribution server, order an event (a movie), pay for the transaction via the financial transaction server 22 (more fully described in copending application serial number 956,743), and receive the movie for later playback in one of a plurality of user playback devices. The present invention is preferably adapted to permit less-than real-time transmission of media files to one or more users using current networking technology (i.e., 28.8 and 56K modem technology) without having expensive and/or proprietary networking requirements placed on the user (i.e., such as those required by video-on-demand systems). Each of the functional components depicted in FIG. 1 are discussed more fully below.>p> It should be understood at the outset that the present invention advantageously utilizes storage and transmission of precompressed and pre-encrypted file data (hereinafter referred to as "media file archive"), thereby eliminating the need for extensive processing power required for "on-the-fly" compression and encryption of media file data. This advantage is especially useful for full-length video files which, along with a soundtrack, would require massive amounts of storage to hold in an uncompressed form. In addition, by providing an array of media files in precompressed format, the present invention is adapted to permit multiple, simultaneous download of a single media file, as will be described below. In addition, the preferred system of the present invention incorporates pre-encrypted media file data stored in the media file database. The encryption/de-encryption process (digital copy protection), described more fully below, preferably includes conventional and/or proprietary encryption algorithms that require users to obtain a valid decryption key for a given media file transmitted.

FIG. 2 depicts the preferred file distribution server arrangement of the present invention. Preferably, file distribution server installation 11 is comprised of a plurality (11A, 11B . . . 11N) of individual installations, each being located in geographically diverse areas, on individual power grids, e.g., each being located in a separate city, or within the same city on different power grids, thereby permitting the present invention to be fault-tolerant and maintain service to users in the event one or more servers should become off-line. Preferably each file distribution server installation is comprised of a plurality of request servers (13A, 13B . . . 13N), and a plurality of media file servers (12A, 12B . . . 12N). Each server (12 and 13) is preferably adapted with appropriate an network interface 48A . . . 48N to permit one or more users access to the corresponding server over the network 16. Those skilled in the art will recognize that network interface 48A . . . 48 N can include of standard and/or proprietary networking hardware/software (e.g., TCP/IP networking hardware/software). Network 16 preferably includes a standard TCP/IP network (e.g., world wide web). Each server is also preferably adapted with conventional firewall hardware/software (not shown) to prevent unauthorized user access to media files stored therein. Also as shown in FIG. 2, each server 12A . . . 12N is preferably in communication with the network traffic directors 50A . . . 50N, via a heartbeat link. The heartbeat link is a status signal providing each server's respective status information, e.g., on-line/off-line, network overflow, user request data, etc. This heartbeat signal allows the network traffic director to route incoming requests to an operational server (12 and 13) able to service the request. In the event of a server failure, the network traffic director 50A . . . 50N will detect the failure and transfer the requests being handled by that server to another server (12 or 13) able to continue processing the request. Multiple network traffic directors 50A . . . 50N are included in the preferred embodiment to prevent the network traffic director from becoming a single point of failure. Each network traffic director 50A . . . 50N is active and handling requests. In the event of a network traffic director failure, the remaining network traffic directors will take over the additional load automatically. Thus, network traffic director 50A . . . 50N is adapted to receive network status messages, heartbeat link status messages, and individual user request messages, preferably in real-time, to permit the network traffic director to route incoming requests based on these criteria. Additionally, the traffic director monitors the transmission protocol and transmission speed of each client, and uses this information to optimally transmit a given media file to one or more clients.

As shown in FIG. 2, requests from users are received by the network traffic director 50A . . . 50N, which forwards those requests to the request server 13A . . . 13N. The response is sent back to the user by the request server. This response includes information of the client software used to contact the media file server 12A . . . 12N. The media file server transmits the requested media file using industry standard and/or proprietary network protocols. These protocols are described further below. Media file server 12A . . . 12N is adapted to monitor the incoming user request messages and determine an overall throughput value based on the current users' transmission speed. In addition, the media file server 12A . . . 12N will monitor network performance during the transmission of the media file, adapting the transmission speed to optimally accommodate the transmission speeds of all the users currently viewing the media file. Thus, the transmission speed of the server can be automatically adjusted based on the average throughput speed of the users currently in communication with the server, and/or based on the lowest transmission speed available (thereby providing transmission at a least common denominator speed). The preferred embodiment includes multiple transmissions for each media file, each being at different speeds. These channels allow users to receive data from the channel most closely matching the throughput of their connection. This also allows high-speed client systems to be segregated from the lower-speed systems. This segregation provides the optimal throughput for each user. Although not shown in the drawings, each server (12 and 13) and network traffic director 50 preferably includes a back-up power supply (e.g. battery back-up power supply system) to permit the device to achieve the stated functionality in the event of a power failure, without interrupting service to the users connected thereto. To that end, each device is adapted to monitor the status of the back-up power supply and, when enabled, provide a "fail-over" to another on-line server capable of providing the required functionality.

Turning to FIG. 3, the processing steps necessary to create the media file archive 26, advertisement archive 34, and plug-in archive 30 elements for storage in the media file database 18 is depicted. The data is divided into blocks or frames, each frame having a header and payload section. The header information is normally not processed, but contains information about the processing applied to that frame. The data payload is what is actually processed. To create the media file archive 26, the raw media file 25 is preferably processed using compression technology 27A. This compression technology includes one or more of a variety of compression techniques, including MPEG I, II, IV, and/or other compression techniques known in the art, or may include proprietary and/or custom compression algorithms (such as provided by Iterated Systems, Inc, or as described in U.S. Pat. No. 5,420,942, hereby incorporated by reference).

Although optional, nearly all media files will be compressed. The compressed file is then preferably processed to add a digital watermark 32A. Not all files will require watermarking, and in fact some files must not be watermarked. In these cases, the watermark process is bypassed. The watermark, if applied, provides source identification used to identify the file later. Further processing provides digital protection of the media file by encrypting it using strong encryption algorithms 46 such as CAST-128, IDEA, Triple-DES, or other high-grade encryption technology. Not all, but most media files will require encryption. The resulting media file archive 26, which has been optionally compressed, watermarked, and encrypted, is stored in the media file database 18 associated with a collection of media file distribution servers 12.

Also shown on FIG. 3, media files provided by advertisers are also processed using compression 27B and watermarking 32B, providing the same benefits as described above. Advertisements are not encrypted. The resulting advertisement archive 34 is stored in the media file database 18 for later retrieval. For example, the watermark can include identification information (which may include, for example, originating ownership information of a given media file, etc.) and may also include copyright notice information. Module 34 is provided for those suppliers of media file data who also wish to include a trailing or ending advertisement, which is incorporated into a media file upon transmission to a user. To that end, module 34 also includes an updatable database (not shown) which contains advertisements, and also association parameters that can direct certain advertisements to be incorporated with certain media files. Thus, the present invention permits advertisers to provide advertisement data to the system. The advertisers can choose which media file(s) their ads are to be associated with, and those associations are preferably automatically affixed to the appropriate media file upon transmission. The advertising data can be affixed to the media file as a trailer and/or leader. Modules 28 and 30 are discussed more fully below with reference to FIG. 8.

Also shown on FIG. 3, plug-in and CODEC program source files 29 are processed and compiled 31 to produce a plug-in and CODEC module archive 30 which is stored in the media file database 18. As executable programs, they can be neither watermarked or encrypted, as such processing would render them unusable.

The encryption module 46 processes the media file by generating a random key which becomes the master key for the file. This master key is saved in a key database (not shown). For each block, a new random frame key is generated. This key is combined with the master key and the resulting key used to encrypt the payload of the frame. The frame key is saved in the frame header. This information will be used later to decrypt the data payload, a process described below with reference to FIG. 10.

FIG. 4A depicts the preferred embodiment of the file distribution server 12 and the relationships between that server and the media file database 18. As an overview, the present invention is adapted to permit multiple users access to the same media file (e.g., movie, image, etc.), thereby eliminating the need for multiple copies of a single media file. Further, the preferred embodiment of the file distribution server 12 uses network software and protocols to allow multiple users to access the same media file stream, reducing the network bandwidth required, thus reducing the impact on the Network. In the present invention, n-requests for media file content are transmitted by n-users over the network and received at the appropriate server (or, rerouted to a server having the selected media file), and are received by the request processor 36 running on that server. Each request is for a single media file archive, advertisement archive, or media plug-in or CODEC. Multiple requests can be issued by a client system, each to be processed by the server and handled individually.

The requests are processed and passed to the protocol control module 38 for further processing in preparation for transmission. The protocol control module preferably passes the request to the multicast protocol processor 40, which attempts to establish a multicast pathway between the customer system 14 and the media file server 12. If a multicast connection cannot be established, for whatever reason (e.g., lack of multicast support by the Internet Service Provider used by the customer system 14 to connect to the Internet), the protocol control module will pass the request to the unicast protocol processor 42 for establishment of a connection using the User Datagram Protocol (UDP), which is part of the standard TCP/IP network support.

Once the data connection is established, whether by multicast or unicast, the appropriate protocol processing module requests packets of information from the packet assembly module 44. The information necessary to assemble the packets for transmission is retrieved from the appropriate section of media file database 18. Further clarification of this process is provided below with reference to FIG. 4C.

Referring to FIG. 4b, the preferred embodiment the media archive database 18 is stored on media file storage device 40. In the preferred embodiment, the media file storage device 40 includes a plurality of media file storage devices 40A . . . 40N, consisting of one or more archive systems, for example, CD-ROM/DVD-ROM media devices, hard drive devices, or other digital media storage devices.

Referring to FIG. 4C, the steps for processing requests is described as follows. The operational flow 50 contains the flow of processing, while FIG. 4A shows the relationship between the subsystems of the media file server. Requests are received 52 by the request processor 36. If the requested file is not available on this server 54, the client system is redirected to a server with the requested file 55. The request is passed to the protocol process module 38. This modules controls the establishment of the network connection between the file distribution server 12 and the customer system 14. Preferably, this connection will use a multicast protocol, if possible. Thus, the multicast protocol module is invoked (if possible) to establish the multicast channel. First, the active channel list is consulted to determine if the requested event is already active on a multicast channel 56. If so, the channel information is sent to the client system 57. The client system uses this information to open the multicast channel using standard IP multicasting protocols such as DVMRP and PIM. If the event is not currently being transmitted, a new multicast channel is created, and synchronization packets are sent on this channel 59. These SYNC packets give the client system 14 something to verify receipt of data on the multicast channel without actually beginning the event until it is certain the data can be received. If the client system is not able to begin receiving the multicast data within a given timeframe 58 and 60, the unicast protocol module is invoked in an attempt to use the UDP protocol instead 61.

Once the channel is opened, data packets for the event are assembled by the packet assembly module 44, which is sent to the multicast protocol module 40 and unicast protocol module 42 for transmission on active channels for that event. For efficiency, the same packets are used for transmitting to all open channels for the event, whether they are multicast or unicast channels.

The same data stream is received by all client systems 14 actively receiving the event. Each client system will have started receiving the event data at a different point in data stream. The event data stream continues to be transmitted until the end of the event is reached 66. At this time, the event data stream is restarted from the beginning 62. Client systems continue to receive the event data until they have received the entire event 64. As each client completes the event, these clients systems notify the appropriate protocol module of the change in status 65. The "Loop" continues until all active client systems have completely received the event data. When there are no active clients monitoring a channel, the event data transmission is stopped and the channel is closed.

Referring to FIG. 4d, the receive loop is described. A packet is received 200 and written 210 to the local storage device on the client system 14. Each packet is serialized, and if the packet received was not the packet expected 220, some data may be missing. If the serial number of the packet is that of a packet previously missing, then the NAK table is updated to remove the entry corresponding to the previously missing packet, and any timers running on that data packet are stopped 250. If one or more packets are identified as missing 220 and 230, then a NAK packet is generated. In the case of a unicast connection 260, the NAK is sent immediately 280, otherwise the NAK suppression timer is started (Timer "A") 270 and processing of this incoming packet ends. If during the cycle of the NAK suppression timer, a NAK is received on the control channel 300 for the same packets missed by the client system 310, then the NAK suppression timer is stopped and the NAK data timer is started 320. When either of the timers expire, the previously generated NAK packet is transmitted to the server on the multicast control channel 280. The NAK data timer is restarted 290. The NAK cycle continues until there are no outstanding missing packets.

The difference between conventional network data transmission and that provided by the present invention is shown pictorially in FIGS. 9A and 9B, respectively. In FIG. 9A, multiple customers are seeking access to the same media file. To support simultaneous transmission in the conventional system, the media file must be duplicated at the time of transmission, one copy for each request instance (which significantly adds to the overall bandwidth requirements of the service). Alternatively, as shown in FIG. 9B, users are permitted simultaneous transmission of the data file at the temporal location in which a request is received, and the media file continually "loops around" to ensure each customer receives the entire media file. In the present invention the network bandwidth requirements are significantly reduced, since only a single instance of a media file is being transmitted over the network.

Turning now to FIGS. 5-7, separate preferred embodiments of the media file playback system 24 are depicted. In the embodiment of FIG. 5, a self-contained system (for example, a "set-top" system) 24' is provided which includes a communications interface, a user interface and associated hardware to permit a user to communicate to the file distribution server 12, order a desired media file and receive and play the media file using system 24'. Each of the functional components of FIG. 5 are described below.

System 24' includes a network interface 70 (e.g., modem, etc.) permitting two-way communication between the user of system 24' and server 12, via network 16. A user interface 80 is provided to permit communication between the system 24' and a user. For example, user interface 80 can include a remote controlled interface that is displayed in a menu format (using display 84) whereby a user can chose among various options. In addition to, or alternatively, the remote controlled user interface 80 can include an input device (e.g. keyboard, etc.) to permit a user to enter commands to system 24'. The user interface is described more fully below in reference to FIG. 8. In essence, a user is permitted to enter one or more commands related to the transmission of one or more desired media files. These commands are temporarily stored on temporary storage 72. Temporary storage 72 can include a combination of RAM memory and permanent memory (e.g., hard disk) for storage of user-generated commands and for temporary storage of the selected media file. Upon entering commands, system 24' initiates communication with server 12, via network 16. It should also be noted that user interface 80 preferably also includes commands to permit a financial transaction to occur using financial transaction server 22, which permits a user to enter financial information (e.g., credit card information, etc.) to purchase the media file. Server 12 begins transmission of the media file, in accordance with the above-described embodiments. The media file is temporarily stored in temporary storage 72.

Upon the appropriate command from user, the media file temporarily residing in temporary storage 72 is accessed to be played. Upon such commands, the media file is sent to decompression and de-encryption 74 to decompress and/or de-encrypt the media file. Decompression and de-encryption includes appropriate hardware/software to achieve the stated functionality. Of course, decompression hardware and software are adapted to decompress a given media file in accordance with the pre-compressed media file, or to decompress the media file in accordance with compression and encryption 46 performed on the server side. To that end, the media file, as sent by the server system, may also include appropriate plug-in modules or CODECS, which may include one or more self-executing structured files, for a given compression/decompression scheme. In addition to media file selection performed by the user, the system 24' of the present invention also preferably includes means to generate a unique passwordable encryption information. This information can include a user-supplied password, or, alternatively, may include a serial number automatically generated by system 24'. The encryption information is forwarded to the server along with the media file request commands, and the server encrypts the file accordingly, using, for example, public-key or other encryption technology. Using the information generated by the system 24' and the server, the media file is de-encrypted.

As noted above, media file preferably includes time stamp data. This information is used both as a temporal marker for transmission purposes on the server side (discussed above), and as a time limiting marker associated with the media file. Once the media file is decompressed and/or de-encrypted, the file is sent to a copy protection generator 76. Preferably, copy protection generator 76 is a digital signal processing that encodes the media file with analog copy protection. Analog copy protection includes coding that is generated within the data file that inhibits the file from being transferred to another medium, for example, video cassette, by ensuring that any such copy is significantly degraded in quality. Copy protection hardware, such as provided by Macrovision.RTM., include appropriate coding for a given media file type to be displayed in a preselected format (e.g., VGA, HDTV format, NTSC format, etc.). Preferably, copy protection 76 also includes the ability to add time limiting data that limits the viewable lifespan of the media file. Thus, for example, using the time stamp data generated by server, the copy protection generator can incorporate time limiting data, for example, 24 hours, into the media file, after which the media file is erased from the system 24'. Alternatively, copy protection generator 76 can include an automatic erase mechanism that erases the file as it is being viewed.

Once copy protection has been incorporated into the media file, the file is sent through a D/A converter 78 to convert the file into the appropriate output, e.g., HDTV, NTSC, VGA, etc., and is sent to a display 84, via display interface 82. Display 84 can include an analog display that is adapted to play the particular media file (e.g., HDTV, NTSC, PAL, etc.). Display interface 82 includes one or more interface jacks 82A . . . 82D for connection to a particular display 84. For example, jacks 82A . . . 82D can include an RCA jack, an input jack, a video out jack, etc. In addition, the media file may also include sound data (e.g., soundtrack data). Thus, interface 82 may further include sound output jacks (which may also include appropriate interfaces for Dolby.TM. Surround Sound connections, as are known in the art).

FIG. 6 depicts a PC embodiment of the media file playback system 24''. In this embodiment, the media file is transmitted directly to a user's PC and the PC is appropriately adapted for direct viewing of the media file on the computer's monitor or separate display. To that end, system 24'' includes a network interface 70, which includes appropriate hardware/software to permit the user to access the file distribution server 12 via the network 16. As in the previous embodiment, a user enters commands, via user interface 80, to transmit signals to the server to select a desired media file. The media file is transmitted and decompressed and/or de-encrypted 74 and stored on a removable media device 86. Removable media can include an Iomega Jazz disk, memory disk, hard disk, etc., and/or other portable storage devices known in the art. Referring to FIG. 6A, removable media includes temporary storage 72 to hold the media file, and is preferably adapted with on-board copy protection 76 (described above). A removable media player 88 is used in conjunction with the specific removable media type to display the media file on a display 84. In the preferred embodiment, the removable media device 86 is adapted to be able to interface with a standard VCR player. Thus, removable media device includes appropriate hardware to permit the video information to be fed to the analog head arrangement common to all VCRs. Alternatively, the removable media device can be played in an appropriately adapted media file playback system 24', described above.

In the system 24''' depicted in FIG. 7, a PC is used to obtain a media file from the server, and the media file is transmitted to a local display or a remote display using a remote transmission and reception system. The PC operates as described above with reference to FIG. 6. Upon output of the PC, the media file signals are sent to a converter 90. The converter 90 converts the media file from the chosen digital download format (e.g., VGA, etc.) to the appropriate display format, for example NTSC, HDTV, etc. In one form of this embodiment, the converted signal is sent to a standard wall outlet transmitter/receiver 92, 94. The transmitter/receiver 92, 94 can be supplied by VideoCom, Inc. The transmitter 92 is coupled to the internal wiring of the building (e.g., copper home and/or office wiring, etc.) which typically operates on 120 VAC at 60 Hz. The media file signals are modulated and sent to receiver 94, where the signals are demodulated and displayed on a display 84. Alternatively, the system 24''' can include and RF transmitter 96 and receiver 98 to transmit the media file signals to a remote display 84. RF transceivers, as are known in the art, include radio frequency modulation of the signals to broadcast the signal in a wireless manner. Of course, the modulation frequency can be chosen for a given environment and/or distance between transmitter 96 and receiver 98. Those skilled in the art will recognize that the PC depicted in FIGS. 6 and 7 includes all the necessary hardware/software to achieve the stated functionality, including that hardware/software to achieve communication and interaction with the server to order and transmit media files.

Referring now to FIG. 8, the preferred user interface of the present invention is depicted in block diagram form. It should be noted that the functionality associated with the interface modules described below are preferably accomplished through appropriately programmed windowed environments and operating systems (e.g., Unix, Windows, Windows NT, Apple OS, etc.) as may be applied to the embodiments shown in FIGS. 6 and 7 above. Alternatively, a proprietary menu-driven environment may be used for the embodiment shown in FIG. 5. It should also be noted that the interface modules shown in FIG. 8 are only exemplary, and any of the stated functionality herein can be accomplished through an appropriately program module. As discussed herein, users are permitted to choose among various functionality when ordering a video file for transmission from the server. For example, certain video files will be stored on the server in a plurality of formats and pixel dimensions (e.g., VGA, letterbox, etc.), resolutions, frame rates, etc. Accordingly, a user may select a particular media file in a desired bit depth 100, language 104, aspect ratio (pixel dimension) 106, media file format 108, or sound feature (e.g., full stereo sound, mono sound, Dolby enhanced sound, etc.). The user may also choose a desired frame rate 118 or artifact filter selection (as may be associated with a certain compression technology) 1116. Additionally, the user may select a transmission protocol (e.g., HTTP, FTP, etc.) 110, select a transmission start time 112 and/or a preferred server transmission location 122. Also, as noted above, the user interface also preferably includes appropriate software to permit users to create templates 120 that are added to a media file.

FIG. 10 depicts a flow chart of the preferred server-client data transmission including the preferred de-encryption process of the present invention. It should be noted that the flow chart shown in FIG. 10 incorporates the description discussed above with reference to FIGS. 1-9. In the media file transmission system of the present invention, a user queries the server for a media file 128. If appropriate, the user supplies user-selectable data (i.e., that data associated with the user interface in FIG. 8) 130. The server determines the user's parameters 132, i.e., transmission protocol, etc. In addition, the server determines if the user has the appropriate plug-in programs and/or CODECS for a given media file. The user is prompted for payment information, and the server conducts a financial transaction 134. As described above, the preferred system stores files requiring encryption protection in encrypted form on the server systems storage devices 18. This encryption was performed using a unique, random key selected for each event requiring encryption protection. This encryption key is stored in a secure area of the server. The key for the given event is processed to cryptographically split the key into two parts. One part is placed into the play ticket provided to the user. The other part is placed into a validation database located in a secure area of the server. Both the play ticket and the media file are transmitted to the user 140 and stored locally on the user's system. The user attempts to play the media file 142. The play ticket interrupts the access to the media file, and automatically communicates with the server for validation 144. If the play ticket is valid, the server sends the second part of the decryption key 146, which when combined with the part from the play ticket results in the decryption key unique to the encryption of the media. Once the decryption key is recovered, both parts of the divided key are purged from the system. On the user's side, the decryption key is used to decrypt the media file 148. Thus, preferably, the decryption key remains resident in RAM and cannot be written to permanent storage. The user con then view the media file once only. If the user wishes to view the file more than once, process 142-150 discussed above repeats. As the play ticket has been used once, a new play ticket must be retrieved from the server. Preferably this new play ticket will not require the user to download the media file to replay, although some media files will be required to be purged from the system as they are playing.

Thus, it is evident that there has been provided a media file distribution system having adaptive transmission protocols that satisfies the aims and objectives set forth herein. Accordingly, the present invention is intended to be of broad scope, and only limited by the appended claims.

Here's the complaint, as text:

**************************

Mark W. Good (SBN 218809)
Benedict O'Mahoney (SBN 152447)
TERRA Law L.L.P.
[address, phone, fax, email]

Edward W. Goldstein (TX Bar No. 08099500)
Jody M. Goldstein (TX Bar No. 24002153)
Alisa Lipski (TX Bar No. 24041345)
Goldstein & Vowell, LLP
[address, phone, fax, email]

Attorneys for Plaintiff
Tranz-Send Broadcasting Network, Inc.

_____________________

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA

_____________________

TRANZ-SEND BROADCASTING NETWORK, INC., a Delaware Corporation,

Plaintiff,

vs.

BITTORRENT, INC., a California Corporation;
and KONTIKI, INC., a Delaware Corporation;
Defendants.

_______________________

Case No CV11-02917
ORIGINAL COMPLAINT
FOR: PATENT INFRINGEMENT

DEMAND FOR JURY TRIAL

______________________

ORIGINAL COMPLAINT

Plaintiff Tranz-Send Broadcasting Network, Inc. ("Plaintiff' or "Tranz-Send"), files this Original Complaint against BitTorrent, Inc. and Kontiki, Inc. (collectively "Defendants") alleging as follows:

1

THE PARTIES

1. Plaintiff, Tranz-Send Broadcasting Network, Inc. is a corporation organized under the laws of the state of Delaware.

2. Defendant BitTorrent, Inc. ("BitTorrent"), on information and belief, is a corporation organized and existing under the laws of California, with a principal place of business at 612 Howard Street, Suite 400, San Francisco, CA. 94104. BitTorrent can be served through its registered agent, James Eric Klinker at 612 Howard Street, Suite 400, San Francisco, CA, 94105- 3944.

JURISDICTION & VENUE

3. Defendant Kontiki, Inc. ("Kontiki"), on information and belief, is a corporation organized and existing under the laws of the state of Delaware, with a principal place of business at 1001 W. Maude Ave., Sunnyvale, CA 94085. Kontiki, Inc. can be served through its registered agent, C T Corporation, 818 W. 7th Street, Los Angeles, CA 90017-3407.

4. This is an action for infringement ofa United States patent. Accordingly, this action arises under the patent laws of the United States of America, 35 U.S.C. 1 et seq., and jurisdiction is properly based on 35 U.S.C. 271 and 28 U.S.C. 1338(a).

5. Venue is proper in this district under 28 U.S.C. ߬ 1391 (b-e) and 1400(b). Upon information and belief, each of the Defendants transacts or has transacted business in this judicial district, or committed and/or induced acts of patent infringement in this district.

PATENT INFRINGEMENT COUNT

6. On November 27, 2007, United States Patent No.7 ,301,944 ("the '944 patent") entitled "Media File Distribution With Adaptive Transmission Protocols" was duly and legally issued. Tranz-Send holds the title by assignment from the inventor Scott Redmond, including the right to sue for past, present and future damages. A copy of the '944 patent is attached as Exhibit A. The '944 patent is directed to a software application to solve problems with sending large data over networks, accomplished by splitting data into smaller bits and spraying those bits across the server andlor computer networks, where the bits of data will reside and/or get redistributed on any requesting or accepting

2

7. Pursuant to 35 U.S.C. 282, the '944 patent is presumed valid.

8. Each of the Defendants oversees and manages a peer-to-peer (P2P) file sharing network, allowing users to download and upload large data files.

9. On information and belief, BitTorrent implements, facilitates, oversees and manages a peer-to-peer (P2P) file sharing network allowing users to download and upload large 6 data files while redistributing and, thus, reducing upload/download costs and bandwidths, as well 7 as alleviating the burden of having to provide multiple copies of requested files over a network.

10. Through the use of the BitTorrent protocol, BitTorrent provides and implements various clients, i.e., computer programs, such BitTorrent Mainline, BitTorrent Software versions (6.0 and others), Mu (micro )Torrent, and more, adapted to be implemented by users and over the 11 II network for file sharing among peers. Accordingly, the above BitTorrent software (BTS) is implemented by users, such a companies, organizations, or individuals for distributing files across a network in response to multiple requests.

11. By making, operating, using and/or selling the BTS and/or other software, BitTorrent has infringed and continues to infringe, contribute to the infringement of, or induce the 16 II infringement of at least claim 1 of the '944 patent, either literally or under the doctrine of equivalents.

12. Accordingly, BitTorrent's acts of infringement of the '944 patent, as alleged above, have injured Plaintiff and, thus, Plaintiff is entitled to recover damages adequate to compensate it 20 II for BitTorrent's acts of infringement, which in no event can be less than a reasonable royalty.

13. On information and belief, Kontiki's Enterprise Content Delivery Network (ECDN) provides a combination of cloud-based centralized servers for video content and other 23 II rich data management for distributing client software. By hosting the centralized servers in their 24 II production cloud, Kontiki's ECDN is able to efficiently deliver high quality video and other data 25 II to multiple users, including multiple personal computers (PCs) and mobile devices simultaneously.

14. Kontiki applies peer-to-peer (P2P) software where one or more origin servers distribute single files among nodes, i.e., peers, so that the peers can share the file among

3

themselves until all the peers obtain a copy of the entire file.

15. By making, operating, using and/or selling its ECDN and its P2P file sharing software, Kontiki has infringed and continues to infringe, contribute to the infringement of, or induce the infringement of at least claim 1 of the '944 patent, either literally or under the doctrine 5 II of equivalents.

16. Accordingly, Kontiki's acts of infringement of the '944 patent, as alleged above, have injured Plaintiff and thus, Plaintiff is entitled to recover damages adequate to compensate it 8 for Kontiki's acts of infringement, which in no event can be less than a reasonable royalty.

DEMAND FOR JURY TRIAL

17. Plaintiff hereby demands a jury trial on all claims and issues.

PRAYER FOR RELIEF

Wherefore, Plaintiff prays for entry of judgment:

1. that Defendant BitTorrent, Inc. has infringed one or more claims, specifically claim 1, of the '944 patent;

2. that Defendant BitTorrent, Inc. accounts for and pays to Plaintiff all damages caused by its infringement of the '944 patent, which by statute can be no less than a reasonable royalty;

3. that Plaintiff be granted pre-judgment and post-judgment interest on the damages caused to it by reason of Defendant BitTorrent Inc.'s infringement of the '944 patent;

4. that Defendant Kontiki, Inc. has infringed one or more claims, specifically claim 1 of the '944 patent;

5. that Defendant Kontiki, Inc. accounts for and pays to Plaintiff all damages caused by its infringement of the '944 patent, which by statute can be no less than a reasonable royalty;

6. that Plaintiff be granted pre-judgment and post-judgment interest on the damages caused to it by reason of Defendant Kontiki Inc.'s infringement of the '944 patent;

7. that costs be awarded to Plaintiff; and

4

8. that Plaintiff be granted such other and further relief as the Court may deem just and proper under the current circumstances.

Dated: June 14, 2011

Respectfully submitted,

By: signature
Benedict O'Mahoney (SBN 152447)
Mark W. Good (SBN 218809)
TERRA Law LLP
[address, phone, fax, email]

ATTORNEYS FOR PLAINTIFF

5

[attached: Patent No. US 7,301,944 B1 (pages 6-28)]

  


BitTorrent - It's not just about copyright any more | 193 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections thread
Authored by: nsomos on Tuesday, June 21 2011 @ 09:20 AM EDT
Please group any corrections in this thread to make them easy to find.
It may be helpful to summarize in the posts title when possible.

[ Reply to This | # ]

Usenet and large files
Authored by: Anonymous on Tuesday, June 21 2011 @ 09:28 AM EDT
Way back in the 70's/80's large files were transmitted over usenet.

1) Binary files were uuencoded
2) The uuencoded files were split over many usenet messages with headers
identifying the file and the part order.
3) The usenet messages were distributed over usenet where each host did a
"I have" "I need" protocol.
4) The usenet hosts collected the file parts together
5) End user applications, some automated, collected the parts and made a whole
6) The whole once reassembled was unencoded and verified.

http://www.harley.com/usenet/usenet-tutorial/how-binary-files-are-handled.html

[ Reply to This | # ]

offtopic thread
Authored by: designerfx on Tuesday, June 21 2011 @ 09:46 AM EDT
please post offtopic stuff here

[ Reply to This | # ]

news picks thread
Authored by: designerfx on Tuesday, June 21 2011 @ 09:47 AM EDT
if this is the first post on a topic, please include a link to the newspick.

[ Reply to This | # ]

comes thread
Authored by: designerfx on Tuesday, June 21 2011 @ 09:49 AM EDT
please post comes documents in text mode with all HTML markups.

[ Reply to This | # ]

prior art thread
Authored by: designerfx on Tuesday, June 21 2011 @ 09:52 AM EDT
lets collaborate all the prior art under this title.

First of note:
how do they get away with claiming that the related stuff is not simply 100%
"prior art"? FTP and TCP-IP are 100% prior art to this claim, yet they
can call it prior art and just ignore the actual evidence?

is that typical for a patent claim?

Also, they left out IPX/SPX, so that could probably be sufficient by itself.

[ Reply to This | # ]

BitTorrent - It's not just about copyright any more
Authored by: Anonymous on Tuesday, June 21 2011 @ 10:03 AM EDT
So does this mean that Tranz-Send are responsible for all the bittorrent
copyright violations?

Yoo-hoo, MPAA, RIAA are you there? This guy says he has lots and lots of money!

[ Reply to This | # ]

BitTorrent - It's not just about copyright any more
Authored by: Anonymous on Tuesday, June 21 2011 @ 10:19 AM EDT
I think there's a serious problem applying this patent to what Bittorrent does.

Please correct me if I'm wrong.

Bittorrent, as I understand it, does not use any sort of server for actual
transmission of the data. The tracker tells your BT client where the fragments

are located, and you directly connect to the person seeding the fragment.
You don't do any direct transaction through the server.

The patent seems to cover a server that transmits the data
"adaptively." In BT
there's no server transmission of the data at all, so I can't see how this
patent
applies here.

[ Reply to This | # ]

The patent seems to base its claims upon a client-server configuration
Authored by: Anonymous on Tuesday, June 21 2011 @ 10:25 AM EDT
The patent seems to base its claims upon a client-server configuration in which
there is a "Server" that sends out all of the media files from its
database to the clients. Bit-Torrent is a peer-to-peer based system without a
central server or database. Doesn't that fact in itself provide Bit-Torrent
enough proof to claim no infringement?

[ Reply to This | # ]

10 yesrs to approve? more
Authored by: Anonymous on Tuesday, June 21 2011 @ 10:43 AM EDT
The '944 patent, entitled "Media File Distribution With Adaptive Transmission Protocols," was filed on April 16, 1999, and issued November 27, 2007. This patent claims priority back to an application filed on October 24, 1997, so that is the relevant priority date for any prior art.
Is it common for patents to take this long to get approved? What happens to other inventions during this 10 year period that might be infringing? Forget first to invent or apply how about show a working invention with the invention.

[ Reply to This | # ]

BitTorrent - It's not just about copyright any more
Authored by: kfiles on Tuesday, June 21 2011 @ 10:51 AM EDT
Help me out here: isn't patent infringement contingent upon utilizing *all* the
elements of the independent claims? AFAICT, BitTorrent doesn't implement many of
the elements of claim 1: it has no media database, doesn't deliver a
"single copy" of media files, and certainly not in "less than
real-time". In addition, I don't think a given peer ("delivery
server") actually does "automatically adjusts delivery of the
requested one or more media files to the requesting users based on current
average network throughput between the distribution server and the requesting
users."

I may be wrong about the last part, but think the BitTorrent seeders are using
heuristics a little different from "average network throughput" to
determine the bitrate for each client in the swarm.

[ Reply to This | # ]

Preferred embodiment would never work
Authored by: NobodyYouKnow on Tuesday, June 21 2011 @ 11:00 AM EDT
From the first paragraph of the 'Detailed Description of Preferred Embodiments' section:

The following detailed description will be in reference to audio/video file distribution, and in particular, to full-length video file (i.e., feature film) distribution. ... The present invention is preferably adapted to permit less-than real-time transmission of media files to one or more users using current networking technology (i.e., 28.8 and 56K modem technology)...

You simply can't send watchable video in less than real time over a 56K (or less) link. Not by a factor of 40 or so.

[ Reply to This | # ]

BitTorrent uses multicast IP?
Authored by: Anonymous on Tuesday, June 21 2011 @ 11:54 AM EDT
9. The system of claim 8, wherein the identified transmission protocol includes a multicast transmission protocol and the distribution server simultaneously delivers the one or more media files via a multicast transmission to the requesting users.

I think BT only uses TCP and UDP unicast tranmissions. So doesn't the patent claim pretty much fall apart here?

--Joe

[ Reply to This | # ]

Venue
Authored by: jpvlsmv on Tuesday, June 21 2011 @ 11:58 AM EDT
On the bright side, this case was filed close to the defendant, in the northern
district of CA.

Rather than the usual patent troll location of the Eastern District of Texas, or
sony-style on the other side of the country.

--Joe

[ Reply to This | # ]

BitTorrent - It's not just about copyright any more
Authored by: Anonymous on Tuesday, June 21 2011 @ 12:02 PM EDT
I'm surprised that the bittorrent patent issued as it seems (to me)like the
digitial fountain patents (now owned by qualcomm) disclose/claim pretty much
everything in that area.

google "digital fountain".

[ Reply to This | # ]

please dont do that
Authored by: Anonymous on Tuesday, June 21 2011 @ 12:14 PM EDT
Please do *NOT* post entire patents into Groklaw articles

Please post links only so that those who have no interest in it can skip it, and
also for those who may be potentially jeopardised by the patents, by shoving it
in their face and making it part of the main page, you have turned them into
*willfull* infringers.

You are also, I would think, opening yourself up as a target, next thing you'll
see is a subpoena(?) demanding your logs and then any Groklaw reader who uses a
BitTorrent client who has clicked in to that page is now a *willfull* infringer,
with the evidence provided by you 'just trying' to help.

There is a reason why PJ used to only selectively paste extracts from claims.

I *really* wish you hadn't done that.



[ Reply to This | # ]

Stepping on a lbs 500 gorilla tail
Authored by: IMANAL_TOO on Tuesday, June 21 2011 @ 01:53 PM EDT
Did they just step on 500 lb gorilla tail?
"A trend in cooperative systems is the emergence of multimedia systems that aim to support synchronous cooperation in a manner which unifies both remote and co-located users. These systems combine information-sharing facilities provided in real time with video- and audiocommunication services. This review of IBM's desktop multimedia conferencing system Person to Person (P2P) presents the characteristics of its utilities."
From the abstract of an 1995 article called "Deskto p multimedia conferencing: IBMs person to person in organizational context" by Schahram Dustdar.

First, the article notes it is a trend (no less two years before the patent application).

Second, the article describes a system developed by the 500 lb gorilla, IBM.

Wait, if gorillas don't have a tail to step on, what part of the gorilla could they have stepped on then? Will Tranz-Send Broadcasting Network, Inc. stay around to see? Can they afford it?




---
______
IMANAL


.

[ Reply to This | # ]

Marimba - Submission to W3C for the HTTP Distribution and Replication Protocol
Authored by: Anonymous on Tuesday, June 21 2011 @ 03:25 PM EDT
http://connectedplanetonline.com/mag/telecom_protocol_wars_software/
September 1997
"Marimba submitted a new protocol to the World Wide Web consortium last
week that would reduce the bandwidth cost of distributing data over the
Internet. Sun Microsystems, Netscape, Novell and the @Home Network all support
the new protocol."

October, 1997
http://www.w3.org/Submission/1997/10/
and
August 25, 1997
http://www.w3.org/TR/NOTE-drp-19970825.html
"This document provides a complete description of the HTTP Distribution and
Replication Protocol (DRP). The goal of the DRP protocol is to significantly
improve the efficiency and reliability of data distribution over HTTP. Here is a
more detailed list of goals:

Provide a widely applicable mechanism for the efficient replication of data
and content.
Improve the efficiency and reliability of caching servers and proxies.
Significantly improve the efficiency of subscription-based data and content
distribution.
Improved reliability and versioning for the distribution of mission-critical
applications and data.
Create an interoperability standard for replicating content between clients
and servers from different vendors.
Keep the protocol simple to avoid incompatibilities.
Provide functionality that is complementary to existing standards.
Provide functionality that is backward compatible with existing HTTP servers
and proxies.
Provide functionality that can be deployed anywhere where HTTP is available
today.
The HTTP Distribution and Replication Protocol was designed to efficiently
replicate a hierarchical set of files to a large number of clients. No
assumption is made about the content or type of the files; they are simply files
in some hierarchical organization.
-----
The DRP protocol uses content identifiers to automatically share resources that
are requested more than once. This eliminates redundant transfers of commonly
used resources. The content identifiers used in the DRP protocol are based on
widely accepted checksum technology.


[ Reply to This | # ]

BitTorrent - It's not just about copyright any more
Authored by: Anonymous on Tuesday, June 21 2011 @ 04:36 PM EDT
May be I am ignorant about patents and thick as well but here is my take:
A media distribution system, comprising: a media file database configured to store media files, wherein one or more of the media files have been compressed prior to storage in the media file database; ...
If the distribution server is the bittorrent client, then we don't have the media file. However, if the distribution server is the bittorrent host with the media file (presumingly in a database), I don't think a torrent file seed constitute a 'database'. However, one can argue a listing of the torrent seed is a database.
... a computing device configured to receive user requests for delivery of the one or more of the media files stored in the media file database, the computing device further configured to: identify average network throughput between computing device and the requesting users; and route the user requests for delivery of the requested one or more media files to a distribution server capable of servicing the user requests based upon at least the average network throughput; and a distribution server coupled to the media file database, the distribution server configured to simultaneously deliver a single copy of the requested one or more of the media files identified in the routed user requests to the requesting users in less-than-real-time, wherein the distribution server automatically adjusts delivery of the requested one or more media files to the requesting users based on current average network throughput between the distribution server and the requesting users.
I think the keyword here is they used 'a distribution server' (singular) not 'distribution servers' (plural). BT client takes a file from one or more multiple BT hosts (distribution server). I do not think the 'one or more media files' refers breaking a file the user requests into multiple segments and send different segments down the line from multiple servers (or one server) to the client requesting it. To me, it appears to cover only when 'a computing device' select one (and only one) distribution server to service the request, and it will varies to routes to deliver the content to the user but I might be wrong

[ Reply to This | # ]

One definite non-infringement
Authored by: maroberts on Tuesday, June 21 2011 @ 04:49 PM EDT
"a media file database configured to store media files, wherein one or more
of the media files have been compressed prior to storage in the media file
database"

Whilst you can argue that the filing system stores media files, it is not a
requirement of Bittorrent operation that one or more media files are compressed
prior to storage, and therefore Bittorrent cannot infringe claim 1 or any of the
dependent claims.

[ Reply to This | # ]

Start at the beginning, Claim #1
Authored by: hAckz0r on Tuesday, June 21 2011 @ 06:01 PM EDT
Since Claim #1 is usually key to the Patent infringement lets just break this down to see how it stands up to Bittorrent, shall we? Please let me know where I am off base.

A media distribution system, comprising: a media file database configured to store media files,

bizzit!! This is a bad start for the patent. The Bittorrent server never touches a media file, just a torrent/tracking/sha-1 hash file. The client seeders hold the data, not the server.

wherein one or more of the media files have been compressed prior to storage in the media file database;

Compression of media is not a requirement of Bittorrent, but the users distributing data usually compress the data prior to distribution. The server does not contain the media file so it can not be compressed by bittorrent.

a computing device configured to receive user requests for delivery of the one or more of the media files stored in the media file database,

again the Bittorrent server only stores the tracking/torrent file, not the media.

the computing device further configured to: identify average network throughput between computing device and the requesting users;

The BT clients measure delivery times, not the server.

and route the user requests for delivery of the requested one or more media files to a distribution server capable of servicing the user requests based upon at least the average network throughput;

Clients request delivery from other clients, and the path back to the requesting client is the same path over which the request likely came. There is no control over the delivery path by the server.

and a distribution server coupled to the media file database,

Bizzt!! The Bittorrent server keeps track of clients with files to share. The Bittorrent server never touches the data being shared

the distribution server configured to simultaneously deliver a single copy of the requested one or more of the media files identified in the routed user requests to the requesting users in less-than-real-time,

This statement reaks of a real-time video feed, where the client consumes and processes the data in real-time, thus a BT client does not satisfy this. BT clients store the data, and real-time has no part in any general file transfer operation. To have a measure of transfer rate to real-time that would imply that the media processing is running in real time and slowed by a monotonic clocking mechanism. Last I checked, writing to a file didn't need to be slowed down by a clocking mechanism.

wherein the distribution server automatically adjusts delivery of the requested one or more media files to the requesting users based on current average network throughput between the distribution server and the requesting users.

The Server never touches the media file, so it can't have a role in adjusting delivery of any client requests.

---
DRM - As a "solution", it solves the wrong problem; As a "technology" its only 'logically' infeasible.

[ Reply to This | # ]

"No ex post facto" angle?
Authored by: jimrandomh on Tuesday, June 21 2011 @ 06:24 PM EDT
Has anyone tried arguing "no ex post facto" against a submarine
patent? The fact that this patent was not issued until six years after
BitTorrent was created, there was no hint to anyone that a patent was pending,
and it was in widespread use by the general public when the patent issued, seems
like a very serious problem, legally speaking, especially since organizations
have come to depend on BitTorrent. No amount of due diligence could possibly
have prevented infringement, and a substantial fraction of the population is
infringing, not just the defendants.

The "no ex post facto" clause in the constitution doesn't quite apply,
since a patent is not the same thing as a law, but could a case be made that
they're similar enough to limit particularly egregious cases of patents issuing
on techniques that are already in widespread use?

[ Reply to This | # ]

Question about compressed files for a patent expert
Authored by: bugstomper on Tuesday, June 21 2011 @ 06:33 PM EDT
I wonder if someone who knows about patent law coud weigh in on this question -
I'm sure it isn't one to be answered by uninformed logic or speculation.

One element of Claim 1 is "a media file database configured to store media
files, wherein one or more of the media files have been compressed prior to
storage in the media file database". Doesn't that mean that if none of the
files are compressed then something could not infringe on the claim even if all
the other elements of the claim were present?

If that is the case, then someone could build the identical system to server
"media" files and as long as the files were not compressed it would
not infringe.

Given such a system, how is it not obvious to use it to serve media files that
happen to be jpeg, mp3, mpeg, or any of commonly used formats for media files
which use compression?

Does a system that serves any files at all and does nothing special with
compressed files infringe because it can serve compressed files? Or does the
element of the claim mean that there has to be something in the system that has
to do specifically with compressed files?

[ Reply to This | # ]

fails on originality and obviousness
Authored by: Anonymous on Tuesday, June 21 2011 @ 06:46 PM EDT
The adaptive nature of the claimed patent is an obvious extension of the
adaptive nature of the ftp connection mechanism where speed is dynamically
adaptive to get the optimum performance over changing network conditions. The
ftp protocol has been around for many years longer than this patent was even
dreamed of.

The subject of the patent in question is just additional and IMHO obvious
glitter and packaging on top of the ancient work of true giants. Which
particular giants invented the ftp protocol, and when it was invented, I have no
idea, but it was long long ago in patent age terms.

[ Reply to This | # ]

If you do anything innovative, you will get sued.
Authored by: Anonymous on Tuesday, June 21 2011 @ 07:36 PM EDT
Yeah, that's really promoting the progress of science and useful arts.

Maybe it's time for me to change careers.

[ Reply to This | # ]

nfs
Authored by: Anonymous on Tuesday, June 21 2011 @ 08:07 PM EDT
Sounds like nfs is appropriate prior art.

[ Reply to This | # ]

Isn't this a Content Delivery Network?
Authored by: Anonymous on Wednesday, June 22 2011 @ 12:20 AM EDT

I know they're suing Bit Torrent but my first read through makes it seem like a Content Delivery Network....

So starting with the only claim that matters, The First Claim (all others are dependent on it)

1. A media distribution system, comprising:
Ok it's a System
a media file database configured to store media files, wherein one or more of the media files have been compressed to storage in the media file database;
"Media File Database" is vague enough to cover any file system where some of the files are media files and some of those are compressed.
a computing device configured to receive user requests for delivery of the one or more of the media files stored in the media file database,
"computing device" like a load balancing proxy which receives a new the user's request.
the computing device further configured to: identify average network throughput between computing device and the requesting users; and route the user requests for delivery of the requested one or more media files to a distribution server capable of servicing the user requests based upon at least the average network throughput;

Ok the load balancing proxy could monitor the network utilisation between the Distribution Server(s) and the User(s) and then routes the users request to a distribution server with the most available capacity.

This "route" step could be as simple as telling the user which distribution server to use. (eg Browser redirect)

NOTE: This part of the claim is not met if the decision which server to redirect to doesn't use "average network throughput" at all.
eg Random Distribution, Availability, CPU Load, User's Proximity or Network Latency to a distribution server etc

and a distribution server coupled to the media file database, the distribution server configured to simultaneously deliver a single copy of the requested one or more of the media files identified in the routed user requests to the requesting users in less-than-real-time,

Ok so the "Distribution Server" is like a backend web server...

  • Connected to the Media file Database.
  • It is able to deliver "one or more media" files to users in "less-than-real-time"

    NOTE: I understand "Less then real time" to mean media is transferred faster then it could be played in real-time. (ie 10 minute video transferred in 1 minute)
    If the user's connection was sufficiently slow and the media was sufficiently high resolution (eg 28.8k Dial Up and Blue Ray Media) then the less-then-real-time would be impossible to meet.

    wherein the distribution server automatically adjusts delivery of the requested one or more media files to the requesting users based on current average network throughput between the distribution server and the requesting users.

    Ok heres the hard bit... It doesn't say what adjustments to make, or how the average throughput impacts it... but being generous TCP has built-in algorithms to automatic address congestion on the network.

    [ Reply to This | # ]

  • Prior art - IBM SNADS in 1988
    Authored by: bugstomper on Wednesday, June 22 2011 @ 03:08 AM EDT
    Someone with more familiarity with IBM's System Network Architecture could probably better say if they can map the details to the elements of Claim 1 of the patent, but this article in Network World from 1988 makes IBM's SNADS (System Network Architecture Delivery System) look promising. It talks about peer-to-peer routing, adaptive to network conditions, transmitting just the part of a file that is needed at a destination.

    Here is a link to the article in Google Books: SNADS to take lead in peer-to-peer SNA nets Network World, Jan 11, 1988, p 5.

    [ Reply to This | # ]

    The problems of terminology
    Authored by: Anonymous on Wednesday, June 22 2011 @ 01:28 PM EDT
    A database. Well a filesystem is a database of sorts. You look objects up by
    canononical name.

    Encryption. Everything on a digital system is encrypted. The databits are
    representations of something.

    Transfer. Anything going from A to B goes through points in between and is
    spread out in time and space over multiple paths. That is the physics of mater
    and energy.

    So lots of proposed innovations are just higher level abstrations on top of
    already existing lower level conditions.

    [ Reply to This | # ]

    Files vs fragments of files
    Authored by: eric76 on Wednesday, June 22 2011 @ 05:42 PM EDT
    One thing in particular puzzles me about this. The patent considers a library
    sending multiple files to a recipient by allowing individual files to come from
    other servers.

    In Bit Torrent, you are typically sending one file -- although there may be more
    than one in some cases -- but the file is being transmitted in fragments from
    other computers, not as individual files. Most of the time, you will not get
    any complete file from any one server. Maybe if it is a very small file or if
    there is only one seed. Instead, you get individual fragments of the file from
    a number of different servers that, when joined together, constitute a single
    file.

    For anything but a very small file, at no time, on any of the computers involved
    would the computers be transferring a file -- only fragments of a file. And
    those many fragments would not be stored as a separate file on any of the
    computers involved.

    I would hesitate to call a fragment of a file a file any more than I would call
    "zy do" from "The quick brown fox jumps over the lazy dog" a
    sentence.

    [ Reply to This | # ]

    Claim 1 not BitTorrent + RFC-889 et al.
    Authored by: BitOBear on Thursday, June 23 2011 @ 01:44 AM EDT
    Claim 1 is a description of Multicast (see IGMP et al), where one server sends
    frames to multiple destinations.

    In BitTorrent there is one-or-more copies of a complete work (seeders) and one
    or more "Trackers" who's primary job is to direct clients to seeders
    where the one client can ask the one server for the one frame.

    A client with any one frame can also then selectively seed that one frame.

    At no time, however, does a BitTorrent seeder multicast a frame to multiple
    recipients. It may multiply unicast a given frame to multiple clients, but this
    is _not_ what is described in the text above because if the seeder sends a frame
    (say the word "the") it will, in fact send "the" several
    times, once for each recipient.

    So, not even close.

    Now, as to why the patent can patent multicasting data when RFC 889, published
    July 1986, describes setting up the send-once-received-by-multiple-clients
    protocol for the internet.

    Additionally on-demand scheduling for data over satellites was common by the
    application date. In this model one or more clients would request (via modem)
    specific datum (such as weather images etc) and the central broadcaster would
    then schedule the broadcast of same in such a way that all the requesters would
    be listed in the headers for the image so that the image only needed to be sent
    once.

    Anyway, this is a case of some company "successfully patenting" an
    existing RFC more-or-less.

    [ Reply to This | # ]

    Groklaw © Copyright 2003-2013 Pamela Jones.
    All trademarks and copyrights on this page are owned by their respective owners.
    Comments are owned by the individual posters.

    PJ's articles are licensed under a Creative Commons License. ( Details )