CA2228607A1 - System and method for delivery of video data over a computer network - Google Patents

Abstract

A video clip storage and retrieval system whereby video clips, stored locally and/or at a more remote location, can be requested and retrieved by a user at the user's multimedia terminal. When the user requests a desired video clip, the request is processed by a primary index manager ("PIM") via a Local Search and Retrieval Unit ("SRU"). Before the message is communicated to the PIM, the local SRU checks its own storage to see whether the requested video clips are available locally. If some of the video clips are local, the local SRU still forwards the request to the PIM so that the PIM may determine specific video clip usage. The PIM determines the extended SRU where the audio-visual data is stored and passes this information to a Data Sequencing Interface ("DSI"). The DSI collects the video clips and downloads the clips to the user's terminal. The user may then view, copy, or print the video clip as desired. In a preferred embodiment, a distributed digital video clip delivery system, according to the invention, provides video clips stored at local and/or remote locations, which can be requested from the Internet and retrieved at the user's multimedia terminal. When the user requests a desired video clip shown on a Web page, the request is diverted to a primary index manager ("PIM"). The PIM attempts to locate the closest server containing the requested clip, from which the download is completed. The system further includes means for uploading and distributing clips to geographically diverse servers, dynamic load balancing, subscription management mechanisms, and protection means to discourage unauthorized duplication of video clips.

Description

PCT~US96/10403 ~Y~ L~I A~nD ~IEIlIO D FO R DELI~ERY
OF ~DEO D ATA O~ER A C O~ NEI~VO R K

The invention relates to a distributed audio/video clip storage and retrieval system, and more particularly, to a system whereby video m~tPri~1, stored 15 locally and at a remote location, can be requested and retrieved at a user~s mllltim l~...~in~1 with or without sound and associated ~l~t~h~cP illrwllldlion. In a ~lert;llc;d embodiment, the invention provided a system whereby remotely stored audio and video content can be requested and l~,Ll;~ ~ed from a server sP1Pcted so as to ...~,~;...;,e n~Lwol~ capacity and ~--;--;-~ tr~ncmiccion delays.

BAC K GRO mNnD OF l~lL l~rVEPrrlO N
This app1i~tion is a co.~ ;on-in-part of Serial No. 08/486,517, filed June 7, 1995.
The Tntprnet is a loose nc;Lwolh of col-l-P~;L~ colll~uLt;l~ spread 25 throughout the world. A message can be sent from any co...l,u~ on the TnternPt to any other by ~e~;iry,ng a ~1estin~tinn address and passing the message from co.n~uLel ~ to colll~uLer via a series of "hops." Each colll~uL~l, or "node," on the TntPrnPt has a unique TntPrnPt address. When an intprmeAi~tp co..-~ul~r receives a meCc~ge in transit, the cc,...~ r checks the int~nrled destin~tion of the m~sc~ge and passes it along 30 accol.lulgly.

PCT~US96/10403 The Tnt~orn~t is growing, in terms of both size and sophi~tit ~ti- n at a rapid rate. In the past, most users of the TntPrnPt were ac~ PmiC~ s ~ ull, or inctitntion~1 users; the TntPrnPt was primarily used at that tirne to ~ ...;1 and receive electronic mail and neLwulh news and to allow transfer of colnpulcr files.
However, since the introduction of the World Wide Web (also known as the "Web" or the "WWW") several years ago, the TntPmPt has begun to host increasing ~mountc of other types of data of general interest, namely ~l- i,e..LaLions of images, articles, etc.
The Web p--,se-lL~ a gr~rhi-~~l user intPrfa~e to the Tntprnpt "Web 10 pages," often consisting pnm~rily of text and ~.~l~.c~l m~t~ri~1, are stored on numerous Culll~JuLtl:~ hnown as "Web servers," throughout the TntPrnPt These Webpages are gPnPrally desc. ;hP~d in terms of layout and content, by way of a 1~n~ge known as "HTML" (HyperText Marhup T~n~1~ge). Any particular co...p~e. lin ed to the TnternPt can store one or more Web pages, i.e. co.l~l~u~Pr files in H~qL format, 15 for access by users.
A surlwalt ~,~g.~u.. known as a ''l~luw~ '' can be used to access and view Web pages across the TnternP~t by ~eciry--lg the location (i.e. TntPrnpt address) of the desired Web page, or more commonly, by "hnt1inking" to Web pages. Common b-uw~c.~ are Lynx, NCSA Mosaic, and Netscape Navigator. The desired Web page 20 is specified by a unirollll ~~s~,ul.;e locator ("URL"), indicating the precise location of the HTML file in the format "http://intPrnPt ~d~lress/di~:l~ly/fi1Pn~me html'h T-Tot1inking is accomplished as follows. The user first ~ccçs~es a Web page having a known address, often on the co-..~ulel located at the user's ISP (TntP~Pt Service Provider). The ISP is the o-g, -~ ;on providing Tnt~mPt co~ ;viLy to the25 user. That Web page can cont~in, in ~liti~m to textual and visual data crP~ifiPA in HI~L format, "lirLks," or çmheAded iulro~ alion (in the form of URLs) pointing to the TntPrn~t add-csses of other Web pages, often on other co...l.u~ throughout the TntPrnPt The user, by sP1~ting a lilLk (often by pointing and s1i~king with a mouse), can then access other Web pages, which can in turn contain further data and/or 30 a~lition~l links. When a Web page is a ces~Y1 its i.-ro----alion is l.,.t~"~;lle(1 from the remote co...l~ul- -, wherever in the world it may be located, across the TntPrnPt to the user.

In recent times, the Web has begun to host highly soFhi~tic~tpd types of mllltimPAi~ content, such as audio and video data. Various ~x~ n~ to HI~IL, suchas Netscape's PMR~n tag, allow .crel~nces to other data to be ernhedded into Webpages. Some bluwsGl~ are not capable of h~nt11ing data other than text and images.
5 Other IJ1UW5e.~ can handle the data in various ways. NCSA Mos~ir, for exarnple, handles ler~,lt;llcGs to unknown types of data by allowing the data to be downlr,~rlP~i to the user's co...~ r, and then optionally invoking an ç~t~rn~l ~lUglaUIl to view or manipulate the data. Recent releases of Netscape Navigator take the concept one step further: a blUWSCi~ e~tencinn, or "plug-in," can be ~ntom~tir~lly invoked to handle the 10 data as it is received from the remote Web page. Other means, such as nt;~wo.h program "applets" written in the Java language (or a similar language), can be used to extend the functionality of the blo~ser environment or network.
COlll~al~d to first gen~ ;on Web content, namely text and still images, audio and video data have extremely high storage and bandwidth l~ui.G.--ents. In15 particular, video files can be very large, from a~ )~ullalGly 10 megabytes to 10 gigabytes. In order to play video files at speeds approaching their .~co.ded rate at a user's termin~l, the files have to be delivered at a fast, Coll~kull speed. Too slow, and the image plays back slower than originally recorded. If the speed is uneven, then the video appears jerky, like an old-time movie. At present, it is rliffi~ult if not20 impossible, to provide snst~in~ high-speed tr~n~mi~cion of large files over a multi-node link on the Tntern~!t Re~Uce the data is often llaul~rGll~ from afar, many factors can cause the delay or even loss of parts or all of a t.,.n~ ;on This attribute, combined with the rapid growth of the Web and the TntPmPt in g~n~pl, has led to several problems. There is now a high and increasing 25 volume of Tntern~t t~affic caused by Web page access, and the d~m~n~l for bandwidth already exceeds supply.
Fu~lh~.~llore, certain content on the Web is ~L1G~11C1Y popular. Re~usç
current Tntern~t technology provides Web pages from specific or "de~ic~tçd" remote site or servers, the most popular sites are often overlo~d~A F~ ...ore, accol ILhlg to 30 current TnternPt technology, each 1~ ~onse to a user request is g~n~lly l.,.n~.,.;ll~
sel~-"~lely. In other words, if one hundred users request l~,~n~ ;oll of the same Web page at the same time, one hundl~d sel~. .lç tr~n~mi~cinn~ must be made to theseusers. R~usç many of these popular Web pages are often being l~ln~ t;d across W O 96/41285 PCT~US96/10403 many nodes on the TntPrll~t there can be s,.l,s~ dllplir~tinn, delays and lost requests, for both the requested data and other, u~ LI~ed data being l.,...c..~ ed over the same routes. If a Web server cont~inin~ video data receives many ~im requests for its ability to transfer all of the fles at full speed is il~
Accor~ gly, a need exists for a system capable of providing improved access to audio/video content on the TnfemPt or another general ~ul~ose n~two.L
Such a system would take steps to ensure that content is delivered without delay or h~le,lu~Lion to all users requesting it.
The prior art is pIimarily directed towards text or image d~t~h~ce providers, and so-called "video on demand". These systems are not ~P~ignP~ to store text and video or audio-visual data across multiple col..~ult;r systems in a di~llibul~d network. The "video on demand'l concept is based primarily on a host-client arçhitecl~lre for downln~rlinE real-time audio-visual data, in very large amounts at a very high speed. Such systems aim, for e~mrlP, to provide full-length movies, with 15 sound, to on-line S~l)5r~ Typically, remote users cv~ tP with large main-frame servers cr...~ the audio-visual data. The host-client ~ of such systems stems from the desire to eli...i.,~le bandwidth limiting ehPmPnt~ in the system by locating the video data solely on the provider's high-capacity system. The provider must then insure that h~dw~, and surLw~ used to distribute this data is capable of 20 the very high storage and fr~n~mi~ion rates required, and is virtually error free, so that no perceivable data is co.lu~Lt;d or lost.
Known and ~-uposed "video on dPm~n~l" systems involve e,~yel~ e and sophisticated co---~,ul._r and co.. -;~tinn systems which are adapted to feed full length movies to i~ 'fJl ~ubsc~ib~ ~ "on dem~nrl " Such systems use a massively 25 para~el co---~uLi--~ , in an attempt to adapt the multi-proces~ing coll.~uLi~lg system to manage the monllmPnt~l video data delivery ~ui~e~nents of hundreds of ~imnll~.lf~us users. Each multi-~lucessillg colllpulel is a single "-- ~;--r.,u~P" col..~uLe-and o~ system with numerous intri~t~ly il.L~.~;ollllf~Led individual ..-i.;.~loce~o.~ The massively parallel co...~ also have very high speed internal 30 data buses with the c~p~hility of sllst~inin~ a si~nifi~nt but fixed level of internal data t~affic.
Massively parallel systems present three distinct disadv~nt~gss- (1) reliability, (2) cost, and (3) they are not sç~l~hlP. Since video data is highly storage PCT~US96/10403 intensive, a very large number of hard drives are l~ui~ed to sustain the system. This lGyui-G-~-ent s~lbst~nti~lly increases cost. Further, because the hard drive is generally the most unreliable aspect of any CO~ uLulg system, using a large number of harddnves culllli~ulGs ~i~nific~ntly to making the ove~ll system more unreliable. Also, S due to the c~nt~li7e~ systems basic structure, it is not scalable.
Another system employing large .~ r~ e servers to store the audiovisual data for delivery to a small number of users d~pen~s on reA~lring hard drivé throughput by developing sper;~li7~ hard drive ;..~ r-~e svrLw,u~ This sorLw~G d~ s how the CO11I~UlG1~S u~ system uses the culll~uler'S hard 10 drive. For example, mnltirle blocks of related data can always stored se~lurnti~lly, instead of randomly. Although this may lead to more errG~ G data thr~ughput rates, such systems have the ability to accommod~te only about 40 Cimlllf~nPOUS users, and are geared to in house, small scale, video distribution.
A limited or partial "distributed" a~ L.. c has been pruposGd, which 15 would link mllltirle personal co--~l~ul~ tog~lh~r in order to fashion a much larger monolithic f....r~ l unit. In this system, video data is r~ ,ule~ only tû build a single, much larger source of digital video u~ For example, a long video isassembled ~on the fly" from sr~ t~1y stored pieces on dirrt.~,ll m~rhinP5. Such a system might s~bs~lve~.lly use ATM switch technology to merge the output of this20 array of co..~ into one or more col-~ ouc video streams.
By contrast, the invention provides a true or complete ~ 1. ;I.u~
a~ ;lr~ .G with increased reliability and the capability of Su~ Lu~g th~ c of ~imnll;..lP~usly ~tt~ehp~ users, at a fraction of the cost of the massively parallel system. In a ~.~Çcl.cd clllbo~l;...en~, the invention uses the existing ~ntprnpt25 ilr,a~L-.Icture, in col.ju~-l;rm with a n~Lw.,.ka cl-;l~;l-~-c; as desr~;hecl herein, to achieve rapid and effir;~nt delivery of audio/visual content to end users.
'Ihe invention not only di~L-ibul~s unlike ~t~h~es (for example, a related but distinct "text ri~f~h~ce" and "audio-visual ~t~h~ce") across the as~,-led coll~ulillg and co----------;r~tirn devices, but it also partitions and ~ ;hu~t's data in a 30 manner which ~ S the ~>e.ro.ll,ance of the llelwo-k as a whole.
In one emhorlim~nt of the invention, the user, a real estate agent, has the c~p~hility of ~cce;v~llg up-to-date audio-visual ihlr~.. ~l;.. about a listed ~.~e ~y.
E~sc.llly, a real estate agent spends hours .c~ea.~;lLulg relevant aspects of available WO 96/41285 PCTrUS96/10403 u~Gl~y, to inr~ lP., i,..~ ;..g the ~lU~ Ly, taking photographs of the plU~clLy, and accumulating i-~,ll.alion about the Lnùpc,ly. In fact, the typical agent sees less than 50 percent of the new homes listed because of time con~tr~intc ~ itirJn~l time and effort is spent asc~.L;~ g the plus~e~;live buyer's desires, introducing the buyer to the range of co.. ;l;~s available within a chosen region, lc~eal~ lg pl~e,Lies that the ~ûl~llLial buyer may be illh~G~LGd in, and then showing these prupelLi~s to the potential buyer.
Accoldmg to the invention, a realtor's time will be more effectively used on activities directly related to selling p~upe~Ly, and not on time intensive, activities n~c.~c~.y to stay abreast with market co~ltl;tions. For example, by being able to view the plUpGlLy on a video tP.rmin~l the realtor will reduce signifit-~ntly the time spent lesea,~ g polGllLial ulu~e~Lies~ The time spent visiting ,ulu~Gllies with the lGllLial buyer is likewise reduced by being able to introduce the ~lul~,.Ly to the buyer via the video clip. This allows the realtor to devote more time to slosin~c and other ~dminictr~tive duties ~ccoci~tp~A with selling the ,Ul~lLy. Also, having the video retrieval c~p~hility allows the realtor to const~ntly refresh the customer's memory without having to revisit the ~lU~Glly.

SI~RY OF TIIE INVENTION
The invention is directed to a video clip storage and retrieval system ~l~Gl~by the user receives comprehensive data collP~teA from one or more d~t~h~ces by request from a user's mnltim~oAi~ termin~l. The cGI.l~l,he.lsi~e data is provided in the form of sPl~octPJ1 video clips coupled with co"~on.l,l.lg ~l~t~h~ce illru....~lion The video clip retrieval system is a ~ ul~A colll~ul~r system or 25 nGLw-Jlh wh~,~y video clips and text ~lçûllll~lion~ stored locally and at a remote location, can be ~vlue,sl~?A- and viewed at a user's mnltim~Ai~ terntin~l The system is p~.L;I;~ d into d~t~h~ce index managers ("IMs"), eyten~p~ storage and retrieval units (~pyspnrlp~l SRUs"), data sequPnring intprfa~es ("DSIs"), local storage and retrieval units ("local SRUs"), and user termin~l mû~illles. Each i~lilion 5U~UlL~ f~LunGs30 hll~olL~IL to the operation and m~n~gçmPnt of the system, but are not nP,cP-s~;ly ~Csignp~d to a specific physical colll~ul~ or co.. ni~ti-n com~ollellL.
In opP~ti~n a user first builds a request at a user termin~l The request is L.,.nc.n;llPA to the user's ~lullaly index m~n~g~o.r ("P~") via a local storage and PCT~US96/10403 retrieval unit (local SRU). The local SRU ~tt~rhPs a ~7Pginn~1 Jde~ to the request to assist the PD~ to effi- iPnt1y search for, locate and report on the reql~ectt~A
"",~tion The local SRU provides tell~poldry storage for the user's most ~LU- ,ItA.
video clips, and before the query is sent to the user's PIM, the local SRU is polled for S requestP~ video clips. The user query, ~mPn~PA to contain a l~Pgio~1 irlPntif~ and to reflect any local m~tCh~s~ is then Çu,w~ded to the PIM.
The PI~l uses the Regional T~PntifiP.r to identify remote ~s which may have the l~ue.,lf~A video information. The P~ also checks to see wl~ er the video clips stored at the local SRU are current. The P~ then queries its own video clip 10 listing and the listing for the remote IMs to locate the l~ueslt~A ;llru~ l;nn A list or ~""-""~,~y of all available data responsive to the request is then l~ d to the user via the local SRU. The user may then update or modify the request to create an abbreviated list of video clips and/or other data the user wishes to view.
The abbreviated user query is then passeA to the PIM. The PrM, having 15 previously located each re~luPsteA video clip on other remote IMs, retrieves the requested video clips and displays them at the user's tPrrnin~l by creating a DSI for each user that lAIue~L~, video clips that are not stored at the local SRU, and i. roln~ g the DSI where the requestPA video clips are stored. The DSI collects the requested video clips from the ahJlu~lialG ~.xtP~ndPA and remote SRUs and l- .,~ c this 20 ~Iro,....lion to the local SRUs.
The l~ue51P~ video clips satisfying the user query are then displayed at the user's te~min~1 The user may display, copy, and/or save or print the results.
Copies can also be made on standard video c~csPtt~s. In a ~-Gfe,lGd embodiment, the DSI has the c~p~bi1ity of resequencing the l"~ ;nn order of video clips to further 25 manage the rlt n~n-ls on the system. For e~u~l~lc, lG l ,es~eA video data may be stored and l~ L i~,Ycd at various locations throughout the system, at various ~ict~nces from the user, and ~ ce~ le through dirr~ networks or cu~ ;c~tinnc routes, with o dirre~ bandwidths and l.~n.~.. ic~;r)n speeds. In a p.t;ÇGll~d embo-~imP.nt the DSI
~I tt . n~;nPS the most a~-upliale routes and s~hpA~ s for down10~lin~ re~uestPA30 il~u....~liOn, to provide fast and effi~iPnt serv*e to the user without unduly taxing the shared co-l-pon~.lls of the system. The PIM records how often particular video clips are l~ue~ A and from this i Ifol~alion de~----;nes whether those clips should be~1p]ir~tPA. at particular local SRUs for ready display. As video clips are uprl~tpA or PCTrUS96/10403 el;...;.,~t-~A, the P~ makes the required updates to the tl~t~h~ log. Also, the PIM
keeps track of billing illr~ inn for the users of the system.
The invention is also directed to a video clip storage and retrieval system allowing users to access data from Web or Web-like sites on the Tnt~orn~t or S other network.
First, specific Web page audiovisual content is ~iic~Oc~teA from its original server, and is distributed to numerous servers in geographically dirrGl~llL areas having a relatively short ~1ict~n-~e (geogr~phi~ ~11y and ele~;llùi~ically) to the user's telTnin~l This is f~ilit~t~d by emhed~ling a "video ID" in a Web page to indirectly 10 specify a video clip. A rl~t~b~e is ~ccec~ed to relate the video ID to the optimal server from which to download the clip. This is accomplished in such a way as tolocate audio/video content on servers close to those users ~ e~-~ed to request it, thereby ...i..;...;,;.lg the number of IIG~WOIh nodes lldvGl~d. Furth~mul~, if certain servers are overlo~ded or out of service, the data is dyn~mic~lly l~l..u.1~ so the lS desired content can be effici~ntly retrieved from ~lt~rn~te sites.
According to the present invention, data is ~ ulr~ on the ne~WO11~ in a confi~;ul~Lion .~,spù~l~ive to historical usage, current usage, and predicted usage. By optimi7ing these con~i~er~ti~nC~ network traffic can be reduced and ove-lo~-lerl servers and co~ tinnC links avoided. In addition, g~;-dphical servers can be 20 established to hold clips of particular interest for a specific geo~;la~hical region, and subject-matter se~vers can be established to hold clips p~L~ ;ulg to certain subject areas.
FlllLh~,~lllore, frequently requested clips can be queued and multicast to multiple users at one time. This, too, reduces n~,Lwolh traffic and i.~C.~sGs 25 l~ollsivity.
Another aspect of the invention is its ability to allow a user to interact with the i~L~ c~l video clip. Technology tû physically manipulate video information on personal col~pul - .~ is known. For example, video capture boards can receive a video signal from a television or VCR and can store video data for later editing or 30 viewing. Video boards and systems of this kind can employ coll-~l~,s~ion protocols, such as "MPEG" (Motion Picture Experts Group) standards 1 and 2, and Motion "JPEG" (Joint Pllvtogld~llic Experts Group) to store and lldn~lll;l video data in a highly c.,...l.l~ A state. This reduces the storage c~dciLy and ~ n~ ;"n time -W O 96/41285 PCT~US96/10403 needed to work with the video data. Such systems alIow a user to view and edit video on a personal co,-,~uLel tertnin~l, but unlike the present invention, do not provide the capability of sck~ and retrieving desired video clips from remote locations at high - speed.
In a preferred embodiment of the present invention, the user ect~hlich~oc an account with a content provider or ISP. This açcount may be in the form of a s~-bsçription, a debit account, or any of numerous other known ~ayll.C.I~ ~rrng~mentc When the user ~cessPs s..bs~ ed-to content through the system, the account can be updated. In this manner, the user can be billed for usage in any manner desired,10 sl~bs~ri~tion i,~l...aLion can be tracked and preserved, auLI-ul~Lion levels can be set, and data protection to prevent ~ I.ol ;,r~A use can be ~c comrlich~A
The system may offer seCon~ly audio visual u~r~ n which would coll~,yolld to the l~uei,Led video clips. In an illllctr~tive app~ ti~ n vithin the real estate industry, the .5CI~O~ y audio visual i.~lll.~ n could be the schools, shopping 15 centers, and hospit~lc situated in the vicinity of a l~uf-,~d pl~,ly. The s~o~ ly videos are related to the ~li --aly audio-visual data or video clips through a cooldiu.alG
system to ...;~ e data entry, data storage, and the d~ n/lc on the system's coll.pu~Lional les~.ul.,es.
Certain advanced embo~ also allows the user to l Glrw-l~ "what 20 if" ~ ldl;ons of the downlo~lPd iulrollllalioll~ for eY~mrle, allowing the user to show a ~ol~.-lial buyer what a listed house would look like with a porch ~ iition In gf-n~l, the user's ability to download video clips is e ~~h~nl eri by the present invention. When the user wants to view a clip, the video ID will be retrieved and sent to a regional ~l~t~b~ce If the regional ~~f~h~ce can match the video ID to a 25 clip e~ g on a local server, and the user's ,.,hs~ l;on rights are snffi~ ont~ then the clip will be downlo~d~ from the local server. If the clip is unavailable locally, or the local server is uvelbuldened, then suçceedingly more remote servers will be queried for the LLa~l~rcr. Accordingly, the fastest possible path will be sel~o~t~ and tIaffic will be ;.... .. ....;.I.i,PA on the llG~wolL.
Exemplary embo~1im~ntc of this invention are dilG~;IGd to the real estate iuldu~lly and to video delivery over the Tnt~rnpt However, as will become readily a~ .,L, the invention is applir-~hle to a wide range of end uses where cû"vel~ienl access to coll~,~olding audio-visual ~.~oll..~l;nn would be useful. Forexample, the , PCT~US96/l0403 W ~ 96/41285 video clip retrieval system can be used for retail sales, dating services, travel services, and many other applications.

BRIEF DESCRIPIION OF TEIE DRAWINGS
The features of the invention will be more readily a,u~ L from the following detailed description and drawings of an illustrative emhorlimPnt of the invenhon.
~ Figure 1 is a block rli~ m showing a ~ ;Çe.lGd l~ hy of the system.
Figure 2 is a block ~i~m illll~t~ting how various modllles of the video clip retrieval system may be addressed.
Figure 3 is a flow chart ill~ data s~uen~ing interf~e logic for video clip storage management.
Figure 4 is a block ~ gr~m of an embodiment of the present invention imp~ video clip delivery over the Tnte nP.t DETA~r) DESCRIPIION OF T~IE INVI~TION
Figure 1 illllct~tes a~ul-,fell~d embodime-nt of the video clip storage and retrieval system, showing its SLlll-;lu~ c~ and the various mor~ ps which comprise the system. As shown, the system CUIII~1iSCS one or more user termin~lc 14, a local storage and retrieval unit ("local SRU") 18, a data sequen~in~ intp~e (DSI) 30, one or more ~rt~-n~led storage and retrieval units ~ ten~iP~ SRUs") 26, and one or more index m~n~rs ("~I") 22.
By way of a system overview, video clips are stored primarily on e~t~n~lP~ SRUs 26, and are tracked and ~ ~1 by the IMs 22. A user obtains videos of interest by co.. ~ ting with a ~ llal~ index m~n~g~r ("PIM") 22 via alocal SRU 18. The PlM 22 locates the requèsted video clips and creates a DSI 30 to direct the effi~ nt download of the video clips to the user t~o~min~l 14. The ~"..~lionc bGL~ 1 termin~l 14 and the local SRU 18 can be within the sarne 30 co..-~ulGi, or b~L~een two or more CUI1l~JULG1~ located within a building, which are linked together on a local area ~ wolh.
~ .Y~ l y software mo~ules co---~u-i~ each co-n~u-~ -L of the system, and ~t~h~ces aCsoc:~ with each sorLw~uG module, are depicted in Table 1, below.

W O 96/41285 PCTrUS96/10403 Pl~rel~Gd and non-limitin~ embodiments of each module of the system are also d~-scJihed below, with reference to Figure 1 and Table 1.

PCT~US96/10403 TABLE 1 SOPTWARE MODIJLES & DATABASE PARTITIONING
SO~ rARE MODULES ¦ ¦DATABASE PARTITIONS

S USER TERl\~NAL
Search and Query Tnterf~r~
Audio-Visual Display Tnterfa~e Data Deco~ ~s~ion Logic INDEX MANAG_R INDEX MANAGER
~ Supervisory Process Text nat~h~ce Text Database M~n~çm~nt Logic IM List Storage Management Logic SRU List luec~e Routing Logic Audio-Visual Data Index DSI & SRU Command Logic Audio-Visual Access List DATA SEQUENCING INTERFACE
DSI Process Audio-Visual ,S~P.~;n~ Logic Index ~n~r Tnterf~e P.Ytenrl~ SRU Tnt.o.rf~ce Local SRU Tnterf~re EXTENDED SRU EXTENDED SRU
SRU Process Active A/V T.istin~.c IM ~o"-.. l~n-l Tnterf~e Inactive A/V T.iStin~c DSI Co nm~n-l TntPrf~re Secon~y A/V T ictin~c Remote A/V Tictin~c LOCAL SRU LOCAL SRU
Search and Update Logic Local A/V Data Index Re~ n~l kipntifier Builder Actual A/V Data Audio-Visual Download Tnt~rfa~-e Co~ n/Decol,-~ ssion PCTrUS96/10403 User Termin~l A user tennin~l 14 is the user's interf~e to the system, and typically is a personal COlllpULGl, wo.h~L~Lion, or a television set top box. Terminal 14 is - comle~led to or inrln~le5 the local SRU 18, and sends the user's ~uesl~ to the PIM
5 22, after initial i,,LGlluga~ion of local SRU 18. As shown in Fig. 1, ttorrnin~l 14 co.l....~-ni~t~s with a PIM 22 to obtain l~uesled audio-visual data, wherever the requested data is stored, e.g. on ~xtPn~PA SRUs 26 or remote SRUs 38, and on dirrel~ -l- systems or n~,Lwulk~ at dirr~ cû~ c~tit n and/or phone system addresses. Terminal 14 receives or downloads re~luP~tPA audio-visual il,Çul",aLion 10 through the local SRU 18.
As shown in Table 1, each user t~nnin~l 14 co...~ s a search and query int~ e, an audio-visual display int~ ce~ and audio-visual data decû",~l~ssion logic. The search and query intPrf~ce provides the user access to a ~l~t~b~P or index which can be il-~ lù~cd for desired video clips and other i,~l",a~ion. For exarnple, 15 in a real estate application, one such ~l~t~h~e could be the Mllltiple Listing Service ~MLS).
The audio-visual display ;nt~ re provides a ...P, ~ ", for the user to manipulate l~tli~ ~rcd video clips. After requested video clips have been displayed on the user's tP~nin~l 14, the user may then interact with the system using, for example, 20 a play, stop, pause, fast forward, fast reverse, Çc~lwald and reverse metaphor. The user may elect to "jump'' to ~e~irled loc~tion~ within the clip, the locations being t~h~ te~ in a willduw ûn the user's te~nin~l 14. Also, displayed in another window on the user's screen may be a list of available secon~l~ry options for user int~ctinn In a ~l~,Ç~llGd embo~liment7 videos are stored and moved through the 25 system in a highly CO-IIIJ1~ ~sed state and will be decolllpl~,i,s~l at the users tPnnin~l 14.
The deco,l",l~ ion logic utili7ed may be co.. ~el~;ially available video deco""ulGssion ~d~.ls and protocols, for example, Motion Picture Experts Group (''MPEG") standards 1 and 2, MJPEG, Indeo, or Fractal.

30 Local Search and Retrieval Unit (Local SRU) The local SRU 18 is the ~ ulal~r storage location for video clips and for il~. .~ ion downlo~1PA from the e~ P,~I and/or remote SRUs 26 and 38, for use at user termin~l 14. As shown in Figure 1, user tP~nin~l 14 and local SRU 18 may be PCT~US96/10403 comhin~A as one co~ uLin~, system. In a ~A~Ç~,ll~ d embodill-e.,l, the local SRU 18 is co~ ecl~l to one or more user tf~rmin~lc 14, each local SRU 18 being capable of supporting a large number of user terrnin~lc 14. For e ~mple, the local SRU 18 may comprise a file server for a local area neLwo-h, with one or more integral or comlecLed S storage devices. In such an embo-iiment each tr~rmin~l 14 int~ts with the local SRU 18 via a n~ lwolh conn~ , e.g. as a network node, using conventional nc~lwulh protocols and topologies.
Suitable storage media for use in a local SRU 18 include large capacity hard drives, such as 1, 2 or 5 gigabyte hard dnves, high speed optical dnves, RAID
10 devices, and other media capable of storing locally a re~cc-n~hle complement of video clips for ready access and manipulation. Portions of the local SRU's 18 disk storage capacity are df sign~teA as the storage Ca~àCiLy required to duplicate a subset of the U11AI1~Y and remote IM(s) audio-video data index t~t~h~cec. This illÇOllllaLioll is used during termin~l queries to d~;tfu-~ which video clips are stored locally. Video 15 segmf~nt revision uAçùllllaLioll is also -~ ~~ within the index rl~t~h~ce, and is returned to the IM during the query process in order to ~"~;"I;~in video seE~ P ~~
accuracy. In the event that additional storage space is required, ~ tion~l disk storage may be provided to the local SRU, to include storage ca~aciLy for active, inactive, and seconda~y audiovisual listings.
Apart from storing audio-visual data, the local SRU 18 colll~Jlises local search and update logic, a regional jflentififAr builder, an audio-visual data download intf~rf~re, and (6) co,ll~l~,.,;,ion/decolll~l~,s;,ioll logic CTable 1).
The Rf~gion~l Idtontifi~- Builder com~ollellL of local SRU 18 ~tt~rh~s a regional code or i~ - to each user request. The regional identifiPr allows the PIM
22 to co.,-."~ e with ,cpo~ifiPA remote IMs 34, and to clel~ the locations of ~ue.l~A video clips stored at remote SRUs 38. In an embodirnent used to distribute real estate data, the regional id~ntifit-r may be the ZIP code of the plup~lLy in the video se~ This ~Ar~J..n~ n may be taken directly from thè text d~t~b~c~. It will be ~ , ho~ er, that the (Regional ID) field carA be keyed to any convenient 1~Lt;~;uly or context-sensitive descli~lioll suitable for the type of i.~- -n~ n stored and the desired end use.
Local SRU 18 I."n~-"~ downk~d video clips to the user tP--min~l 14 in a highly ~OI~ SS~A state. In a ~lGre.lGd embo~lim~ont of the invention, this -operation is mPAi~t~A by an Audio-visual Download TnterfA~e asso.,.dtcd with local SRU 18 (Table 1), with decomy~ ion prior to and/or in "real-time" during viewingoccurring at the user t~rminAl 14. Local SRU 18, via its download intPrf~-e~ also co.l....~ t~os with a DSI 30, described in more detail below. DSI 30 manages the5 download of video clips and other illroll"aLion to local SRU 18 from the various locations where responsive inrolll,ation is found.
The local search and update logic serves primarily two functions. First, it enables local SRU 18 to search its storage media for ~ e-~ A video clips before the query is ~.A.~c...;l~eA to the PrM 22. The update logic allows the P~ 22 to identify 10 whether the locally available video clip is current. Thus, when the user's request is IIAn!~ d to the PrM 22, the request is modified to inrii-~te (1) whether the video segm~nf is stored locally, and (2) the current Revision Code associated with the video clip. If the PIM 22 locates a clip that ~u~ edes the one ~ ul~ lly stored on the local SRU 18, the local SRU 18 is notifi.oA, the old data is deleted, and the new data is 15 dowlllo~ from the SRU 26 co,~ the updated video clip.
A second function of the local search and update logic is to identify and track the most frequently ~ d audio-visual clips. These video clips are idLontifiPA
for continued storage within the local SRU 18. This ensures that once a preAr~c-...;..~d local SRU storage capas,iLy is reached, only the most heavily used video clips are 20 stored at the local SRU 18. In one embodiment of the invention, when a video clip with higher usage than the least used locally stored clip is idtontifi~A, the least used clip is replaced by the higher usage clip within local SRU 18. In another embodiment,local SRU 18 may store the last requestt~A video clips, space ~P-~ . A
col,.bi,ldtion of these and other storage s~a~i~lg and management approaches may be 25 used.
In a plGrcllcd embodiment, DSI 30 t~ .c...;l~ it~l...~l;~n in co",~lcssed form to local SRUs 18 for downlo~din~ to the user's termin~l 14. The ~1e~U...~ ion is ~el~,ll-ed at the user te-~rnin~l 14 using cGl~ ional d~ul~pl~,s~iol1 standards.
However, where the user is using a television screen, or other unintelligent device, to 30 receive the audiovisual data, the deco",~lGs~ion, via comm~cially available deco",~ ion ~ ls (diccussed above) will take place at the local SRU 18.

_ _ _ W O 96/41285 PCT~US96/10403 prim~ry Index Mana~er The PIM 22 is the ylu~ search engine and fi~t~b~ce m~n~gP.mPnt module of the invention. As shown in Table 1, PIM 22 comprises (a) index m~n~çr supervisory process; (b) text ~1~t~h~ce management logic; (c) storage m~n~gPmPntS logic; (d) mPsc~ge routing logic; and (e) DSI & extPn-~e~l SRU cornm~n~l logic. The PIM 22 is desi~rlP~ so that no two r,-" ~iol.C must specifically reside on the same physical c~.",yu~ , although it will be ayydlGllL that in ylcfe~lGd embodiments certain fimrtiorlc may be CO11~/G1~C11L1Y or çffiriontly g-uuyed together con-~ey~ lly andlor physically, for greater ease of use.
The "index m~n~er supervisory process" (Table 1) is the surLw~c interface to the high speed co"",..~ni~tinn intP.rfa~e (explained below). It provides the commnnic~tion intPrf~r~e to the local SRUs 18 and to the text ~l~t~h~ce5 When the user's query ~ e~ tle~ c.~Lu~g a DSI 30, the "index ...~n~er supervisory process"
creates a DSI 30 on its co,n~uLer system unless the "index manager supervisory process" ~l~t~ le,C that the current state of high speed co,......... ~ tic-ns on its colllyulcr exceeds a y~ ".;..P~I limit, for eY~mrlP, 40-80 users. In that event, the DSI 30 is created on a dirr~Gll~ cQl"l."~el system.
The "text fl~t~h~ce management logic" is .~-col~uldled from the text ~t~h~ce in use with the system, and m~n~ges and controls text data stored within these 20 ~i~t~ cPs. For example, in the real estate embo~im~nt the "text ~t~h~cP management logic" is the logic associa~ed with the Multiple Listing Service ("MLS") ~t~h~ce, and is structured to allow MLS queries .c~ ;"~ the entire di~llil,ulcd llc~w~lh.
The "storage m~n~gPmPnt logic" is the system "storage engine" and is responsible for placing new and/or updated or uploaded audio-visual data on the most 25 a~yr~y-;ate PYtP.nt~PA SRU 26. Audio-visual segmpntc or clips can be stored to more than one e~ le~ SRU 26, when dllplit~tion would Ini.~;....... ;,c traffic to and from local SRUs 18, for example over high speed network 24 or co............. l~ tinn line 16. The ~Pricinn to move or copy data to an e~ n~P~ SRU 26 from a remote IM 34 and SRU
28, or from another extPn~lP,d SRU 26, is made for exaunple by ev~ln~tin~ an algorithm 30 which ~co~ntc for available storage space on the various SRUs 26, the ~iem~n~ for p~rticul~r video clips, and the locations of users ~ e,l;n~ the most popular videos.
The "storage ~na~a~e~l~e-ll logic" may also track p~rAmPter~ such as the cost of .

CA 02228607 l998-02-04 PCTrUS96/10403 tr~n~ ing and storing duplicate inform~tion, and helps to ensure that each ~YII n~l~P~
SRU 26 is utilized efficiPntly~ and that no PxtP,nAe~l SRU 26 becc,...~s "ove~tP,nA~A ~
The index manager "mPss~e routing logic" accepts regionalized queries from the local SRU 18, deciphers the queries, and subsequently folw~u-ls the 5 Ai~semblP~ queries to remote IMs 34, The index m~n~pr "mPs~e routing logic"
also accepts the ~,~onses received from the remote IMs 34, form~ t-p~s a comprehensive lca~onse~ and relays this response to the user.
The "DSI and SRU co..- -.~nA logic" provides the ~ 22 with the capability of directly co.l....ln~ and controlling the DSIs 30 and the SRUs 26.
10 The PlM 22 uses this ;,.~ e to pass the data required to enable the DSI 30 toco~ ..nr~t-P~ with the extPn-l~d and remote SRUs 26 and 38 to direct these SRUs to download video information, The "SRU Col.l,nand logic" sees to the ~IIlplir~tinn of popular videos on ~ltPrn~tP, SRUs 26, It also places copies of video s~...~ on SRUs geogl~ hiç~lly15 closer to the users most il~t~.,i,lcd in those videos. The goal is not dllpli-~te data onto SRUs 26 where the nurnber of frequently downl- ~AP~ videos ("FDVs") is already high (above a ~l~elf- ..-;.-~l value). Duplication of data is ~e~rulllled according to the following logic during non-peak periods of system opP~tinn The PIM 22 Actc ...inP$
whether it is m~n~in~ an P~xtpnripcl SRU 26 which has an FDV level above this 20 pre~cl~ P~I value. This dc~....i..,.l;nn is made by seal.;l-.,.g through the "Audio-Visual Data Index" ~l~f~h~P, (-lesçriheA. below) to identify the video clips that have been ~nces~P~ most fre,q~uently, From this video subset, videos are se1Prte~ forLlansr~ldl or d~lplir~tinn based on where the video was used most. If the FDV was tl~ul~rcllcd ~ lly from DSIs 30 created by the PIM 22, PYtpnrleA SRUs 26 located 25 within the same cûln~ul~ are evaluated to ~e~nlP wl-clher that çYtPnA~P~ SRU 26 can accept a A~plir~te copy of the video clip. If so, the FDV is Allplir~tP~ on the j(lPntifiPA 1~ Y I ~ IPA SR~ 26.

PYtPnAP~l Storage and R~trieval Unit (py~tenAp~l SRU) As noted above, ~X~ P~ SRU 26 is the principle storage facility for the system and is used to store audio-visual data in a plurality of audio-visual storage media. ~lth-nlgh this section refers primarily to the eX~ P~i SRU 26, the term _ PCT~US96/10403 inr~ e~s remote SRUs 38 which may also store ~ es(¢~ audio-visual u~ ;nn The surLw~e mo~inlf s are itlentir~
The most re~que~tP~ audiovisual data, to include the FDVs, are written in contiguous ~lloç~tion blocks closest to the system's disk storage allocation table.
S Inactive video s~-- ~ are stored in contiguous ~lloc~ti~-n blocks furthest away from the "disk storage allocation table." In an ~1tfrn~tive confi~--".~ -, the disk storage allocation table is ~ ~ in RAM or on a s~ e co~ ulel. Disk storage is ol~a,J.~ed in macro storage cells which insure that each video ~f ~ f ~1 wi~ always be stored in contiguous allocation blocks. This may be achieved, for eY~mplf, by using a 10 storage cell capable of storing a two minute audiovisual se~
Rer~.li..~ to Fig. 1, one or more ~cxlf ~1~ SRUs 26 are co.l~ ;lrA to the PIM 22 and to each tf rmin~l-unique DSI 30, in the event that the P~ 22 fl~L~-...i.~fs that a DSI 30 should be created. The elct~n~lf~ SRUs 26, upon direction of a DSI 30, ~., ..~...iL requested data, via the DSI 30, to an ~n,p,iaLe; local SRU 18, and 15 ultim~tf ly to user t~nnin~l 14.
The --l lell~ SRU 26 co~ es an SRU supervisory process, an IM
Cul.. ~ intfrf~e, and a DSI cc,.. ~n-i inte~e. The SRU supervisory process enables the ~lcl~f~ SRU 26 to co..~ e directly with the IMs 22 and DSIs 30.
This intf rf~-e ,~,s~onds to m~C~es and data packets addrf ssed to it. It also 20 encapsulates, for nelwo~h l~,~r~c~ .ll p,ll~o~es, video data to be ~,~ill¢~ to other SRUs 26 or DSIs 30. The SRU supervisory process allows the SRU 26 to store data transferred to it. Similarly, the SRU supervisory process can delete all out of date or mntore~rily duplicated data. This storage and deletion of data are ~ Çc,l",ed under the dilc~lion of the PIM 22 via the "~ ~'omm~n~l Tnt~ e "
The "DSI co,lln,alld intP~l~es" exist to allow the PIM 22 to function apart from the ~ ~1~ SRUs 26. The DSI co----~-~n~l interf~ is provided to directthe P~tPn~ l SRU 26 to download the audio-visual il~ lion to the DSI 30 t.
buffers for eventual download to the user tçrmin~l 14.
Data Se~u~l~cill~ Jnterf~e (DSI) Accolding to the invention, each DSI 30 is created by the PIM 22 to f~ilit~t~ data ~ nsr~ from the ~t~nried and remote SRUs 26 and 38 to the user tçrmin~l 14. When created, the DSI 30 may reside within the e7ct~n~ or local colllpon~l~L~ of the system, but in the plc;r~l~d embo-iimPnt of Figure 1 is shown locally. The DSI 30 collects, m~n~geS and buffers data which is 1~ e.i from both ~xtenflf.1 SRUs 26 and remote SRUs 38 to the local SRU 18, and then downloaded to the user's tPrmin~l 14.
~ A DSI 30 is created and/or inhi~li7f~ by PIM 22 whenever a user S requests audiovisual i.~o"~laLion that is not stored within the local SRU. In a ~l~f..,.;d embodiment, the DSI 30 is created just prior to the video data download process, and destroyed immf~Ai~tf-ly Lllt;l~lt;r~ This allows the system to use one co..~ tinn n~wulh for querying and another, preferably higher bandwidth, cfJ~....~....if~tion ntlwo,h for video data downloads. For eY~mplP, the D channel ("X.25 packet"
10 n~Lwf~ ) of an "i--~ ~.,u~ services digital Il~Lwulh" ("ISDN") conQf.-l;oll may carry the video querying traffic of the video he wo,h, to include fo~w~~ g the user query to the PIM 22, and receiving the ,~sL,on~e from the PlM 22. Once the user has finally d~;~t....;..~.d which video clips are to be retrieved, the PIM 22 if lf-ntifif c the most a~,u~,iale and effif i~nt location for the DSI 30 and then creates the DSI 30 at this location. A ~:let~ilf~-i "DSI Video Download List" is then passed to the DSI 30 by the PIM 22. The DSI 30 uses this list to direct the SRUs to download the reflu~ost~

Also, the DSI 30 allows the n~Lwolh to connect many geo~,a~l~ically disL,;buLed video data sources to one subsc-;i~e~ fieSI;u~l;o.~
DSI 30 co-ll~ es (1) a DSI supervisory process, (2) audio-visual sequencing logic, (3) a l'IM interf~f e, (4) an çYtPnf~ SRU interf~ e, and (S) a local SRU inf~rf~cf-The DSI supervisory process enables the DSI 30 to c~.. li~te directly with the PIM 22, the eY~ if~ and remote SRUs 26 and 38, and the local SRUs 18.
The "audio-visual se~u~ ;..g logic" for DSI 30 o~e.dtes broadly as shown in Figure 2. The "audio-visual se~u~n~ing logic" enables DSI 30 to r~sequfn~e data, to provide for more f-.ffif i~.nt use of the storage and retrieval units. The object is to allow the system to utilize idle ~sou,~;es throughout the n ~twolh. The DSI 30 30 actively fi~,tr.. ;~5 which colll~uLulg systems and co.. ~.. ;~lif n paths to the user should be used for each download. Thus, if a particular eYtPn~ SRU 26 is busy Su~f lLill~ other users, tlle PIM 22 may create a remote DSI 42 on a remote system for user tennin~l 14. Remote DSI 42 would then CfJ--i----~ P- with user t~nnin~l 14, W O 96/41285 PCTrUS96/10403 assume l.~on~;l.;lity for the download process, and direct the video data download to user tP.rmin~l 14.
The "index m~nAger int~orf~ce" provides (1) the co.. ~n-i int~rf~e b~Lwec;n the P~I 22 and the DSI 30, and (2) the fee~ihAc~ m~rhAni.sm between the DSI
5 30 and the PIM 22. In the first inctAn~e, the PIM 22 uses the "index m~n~Pr int.orfAce" to co.. ~ instructions to the DSI 30 in order for the DSI 30 to collect the requested video il~llllalion. In the second instAnre, the DSI 30 reports back to the PIM 22,~ ll~ng the PIM 22 of the status of each queried Pxtpn~ed SRU 26.
The "~ 1 SRU int~rfa- e" allows the DSI 30 to direct the idPntifi~d 10 ç~tPn~led SRUs 26 to download requested ih~ro....AIi~ n to DSI 30 I.An~ buffers, for download to the user terminAl 14. This interface is typically a very high speed intçrfA~e, for example, FDDI or "FireWire."
The DSI 30, uses the local SRU int~rfA~e to coo.di,l~te its video segm~nt download with the local SRUs 18. The cu....~....-ic~tinn int~rf~ce b~;lw~n the 15 DSI 30 and the local SRU 18 is typically a high speed inttorfAce, for example, ISDN.
Also, when the traffic around the P~ 22is high, the DSI command logic establishes, via the local SRU int~rf~e, a remote conn~lion with a local SRU 18 ( licc~ssed above).

DATABASE STRUCTURES
The system may employ r~l~tiosl~l or flat-file ~l~tAhA~es, text indexes andlor search çngin~os~ and raw data in the form of audio-visual clips and/or text infor nAti~n Field-c,ritont~ ~lAtAhAces may be used in the system, and in lG~l~S~ g such ~AtAhA~5 each field can be shown enclosed by ~ Psçc For example, (Field 1), (Field 2) ~ ,c.lL~ a rlAt~hAce with data fields 1 and 2. If the ~lAt~h~ce is related to another ~1AtAh~Ce, the relating field can be denoted with square brackets (O). Thus, in the following example, I)AtAh~C~ 2 is related to Database 1 through field 3.
n~tAhAC~ 1: (Field 1), (Field 2), [Field 3~
n~tAh~ce 2: rField 3], (Field 4), (Field 5) In the present invention, the PIM 22 sonwalc; is ~Iç,ci~n~ to contain the following dAt~bACe structures: (1) a Text rlAtAb~C~ (2) an IM list; (3) an SRU list; (4) an Audio-visual data index; and (5) an Audio-visual Access list.

PCT~US96/10403 In an illnctrative emhol1imPnt of the invention, the user, via the PIM 22, has access to at least one "text ~i~t~h~ce" co"~ g records with searchable fields, one of which is [Video ID]. Each record in this d~t~b~ce cu"~ ~ponds to a video clipstored on the extendPd or remote SRU 26 or 38. This ~~t~h~P may be ~ ;n~A by S the system or by one or more third party f1~t~ha~es, for example, the Multiple Listing Service (MLS) ~~t~h~ce, and using any suitable data m~n~mPnt "front-end."
The "~ list" (Table 1) is a hierarchical d~t~h~c~ storing u,~ ion needed to target specific r1~t~bh~ces during data queries, and serves to identify remote IMs 34 co..~ ~ues(~d audio-visual data. The "IM list" is Sllu~lul~d as follows:
(IM Address), [~2Pgio~l ID], (~lt~m:lte Address).
Rec~n.5e regional data may span multiple remote IMs 34, there may be multiple remote rM entries in the PIM list ~l~t~h~ce. The aM Address) helps locate the a~n~plidle remote IM 34 within the r~ ~wc"~. The ~ ginn~l ID] allows the PIM 22 to co--~ ic~t~ with remote IMs 34 iflentifi~1 as CG~ ),.."-I;nn relating to the 15 requested regional id~ r. This reduces the "u."b~. of servers cont~ctPA thereby reAn~ing m~Cc~ginE that occurs over the high speed n~.wul}~ 20. The regional ID is obtained during construction of the query by the local SRU 18 svrLw~, modules. In certain embodiu,c~ of the invention, (AltPrn~te Address) field is a system phonenumber, cle~L,u"ic address, or other path to the remote IM 34 in the event that other 20 third-party d~t~h~CP providers are used.
The "SRU list" is ~llu~;lul~d as follows:
(SRU Address), (SRU Under-run Count Rate), (SRU Access Count Rate)~
The (SRU Under-run Count Rate) is used to track the number of times during a ~leclet~ ~ period, for eY~mrl~, a 24 hour period, that the ~lct~n~lP~ SRU 26 or 25 remote SRU 38 were not able to fulfill data requests because the SRUs were busy downl~ ng data to fulfill other data l~e~l~. The (SRU Under-run Count Rate) willbe e7~p1~inPA below in the SRU mo,-~lu,ulg ~ c~s~inn. The (SRU Access Count Rate3 ...ol.;lu., how often during a predt;~r-..~ d time interval, a particular SRU is used for video delivery.
The "audio-visual data index" i~lentifips each video clip and S1JP~;~ its location. The "audio-visual data index" is sLlu~Lultd as follows:
tVideo ID], (SRU Address), (~)c~tion Code), (Revision Code), (Initial Copy Flag), (Usage Count Rate), tS~o~d~ ~ Array ID]

W O 96/41285 PCT~US96/10403 As above, the [Video ID] is a unique lGrGlGncc i~tPntifir.r for each video clip and cu,,~*)onds to an idG~I-iryil~g field within the text rl~t~h~cP, The (SRU Address) identifies the nGLwo~k location of the SRU cn..~ ;..g the re~luested audio-visual ..lrol"ldLion. The (Location Code) is the exact physical location of the video clip 5 within the SRU. The (Revision Code) inrli~tr s whether this version of the video clip is the current version. The (Initial Copy Flag) is a field that is ~rpr-nrtrd to each new video clip entry, so that the system knows that this version may only be updated, dl-plir~tP~, or removed to more remote storage lor,.l;onc, but not deleted from the d~t~h~ce entirely. The (Usage Count Rate) keeps track of how often a particular video 10 clip is requested during a prert~t~ p~t time interval, for example, a 24 hour period.
This i,lro,...,.t;nll is used to rlele...~ r FDV status. The [Secondary Array ID] is used to point to a "related" rl~t~h~ce of secondary or related video or text ulfu~ ;nn ~not shown).
Thus, in an embodiment where seconda.y i~ ;r n is provided, such 15 as the real estate emborl;...~ -~1, the user may e.nl-~l-re the available text and audio-visual data by providing ~lrlition~l lulrolllldLion about the ~l~,ecl~A data. For exarnple, in a ~-G~..ed l_l"bo.l;...F-.I directed to~dlds the real estate applir~tictn) the seconrl~ry rl~t~h~cr may contain audio-visual ih~.,lldlion about hospitals, schools, and traffic ..... c, etc. ~coci~lp~d with any l~uec~ JlU~ y video.
In the real estate example, the se~onrl~ry rl~t~h~ce may be ol~dl~c;d as follows:
[Seco~ . y Array ID], (Seglll- .,l Cooldu~ale) The [se-con~l~ry Array ID] provides a way for the PrM 22 to flag were additionalsecol--l,..y data is available. The (.Segm.o.nt Coo.dinale) ;..~ ,s the g~;.,.l.l-iC area COll~ull~u~g to the secon~ry iu~olmaLioll. The buu~ ;Ps of this gco~.~phir area may be l~lci3el,lt;d by latitude and tnngit~l~e cooldiuldh~s either taken from a map or, preferably, taken by GPS. Rer~llcP. the geogldl~l~ic area would typically enco~ ass multiple ~lU~lLy ticting.c, each entry in the seCon~l~ry ~t~h~ce would COll~ s~ond to several video clip entries.
The "audio-visual access list" is co~.l.. ;.~ed of the following fields:
[Video ID], (IM Address), (Access Rate) PCTrUS96/10403 This rl~t~h~ce ~ a list of DSI 30 S-I~O1Lin~ ~CU~ UI~ systems," by vir~e of the m~n~ging or nearest IM address to which audio-visual il~1.,laLion was delivered.
The DSI 30 le.lue~.Ls data from many SRUs. When a DSI has succec~fillly collected data from a particular SRU, its m~n~ging IM's "audio-visual access list" ~l~t~b~cp is S updated to reflect that video seg...~ delivery to that physical loc~tion within the nG~wu1h. The Iwlwo~ now has i,-Ço. .~ n 1~l~s~ the de~ nc of specific video segmPntc from specific SRUs. This illrullndlion is used to r3~1u ...;n~ the most r~ estin~tinn for videos and/or copies of videos r~ ;hul~ by the r,cLwûlh storage m~n~çment logic.
Apart from providing the ~1UIl~y storage lo~tir n for the video clips, the e~trn~P~3 SRU 26 co",~l;ses an "active A/V listing," and "inactive A/V listing," a "seconcl~ A/V listing," and a "remote A/V listing." The p~ ose for each of theselistings will be explained in relation to a real estate applir~tion In the real estate contr~t, new ~1U~ y listings are typically of grcater interest to the user and, 15 Lh~e~O1G, would colll,ulise the "active A/V listing." Older ~-~.,.Ly listings would not be selected as r~ ly and would cc.~.p~;cP, the "inactive A/V listing." However, a change in the p1U~.Ly status, for example, reducing the price of the p1o~.y may return the p1~C.~y to the "active A/V listing." The "5ç~ol.rl ~ A/V listing" would comprise the se~Q~ y ...Çol...S~;o~ Soci~teA with certain video clips. The "remote 20 A/V listing" would typically co.l.p1ise pl~. .Ly that has already been sold. This ..~c,....aLion would still be useful for co,..p~.,.l;~re pricing ~u-,uoscs, ~ut would be ~rcçs~A relatively infrequently.
The audio-visual data stored on the extçnrl~l SRU 26 is the video clip itself. In a ~ fc..ed embodiment of the invention, video data is stored on the 25 P~ lrlf~ SRU 26 in storage blocks equivalent to a~ ~natt;ly two (2) mimltes of audio-visual data. The actual length of these storage blocks varies and is depf nr3~ont upon the video delivery app1ic~tion Audio data is also stored on the SRU in blocks of similar length. The entire audio and video seg..~ may be stored contiguously, with the video and audio data being stored either SG~ Ie1Y or togeth~r The local SRU cvr.~il~s a "local audio-visual index" and "actual audio-visual data." Audio-visual data stored on the local SRU 18 is o-~ed in the same manner as the data stored on the e~tf nrl~d SRU 26. The "local audio-visual index"
cv...l.r;~f s the following data fields:

W O 96/41285 PCT~US96/10403 [Video ID], (T~r~tion Code), (Revision Code) The [Video ID] cul-~s~ollds to a field in the text ~~t~h~ce, and idPntifips the video clip. The (Location Code) specifies the exact storage location of the video clip within the local SRU 18. The (Revision Code) in-1ic~t~C whether the stored version of the 5 video clip is current.
When the DSI 30 is created, the PIM 22 ~ c~ a data structure that idPntifiPs the re~ueste~ video clips, and the exact locations of each video clip. The data structure is as follows:
[Video ID], aM Address), (SRU Address), (Location Code), (SRU
Access Count Rate), (SRU Under-run Count Rate) The [Video ID], (~M Address), (SRU Address), (SRU Access Count Rate), and (SRU
Under-run Count Rate) serve the sarne fun~tionc as previously des~liled. The [Video ID] field is the principle field, with the lc~ g fields being ;:lU~J~JWIU~g fields to the 15 [Video ID] field. The (T~t ~tion Code) is the precise video storage address within the SRU. Since it is possible for each video s~...~ -.l coll~*,onding to a unique [Video ID] to have multiple unique storage loc~finn~, the DSI 30 may have mllltirl~ records for se~ ~ storage locations for that video se~---r--l within the DSI's 30 video data download structure. Thus, if one SRU cannot respond to the DSIs co.. ~n-l because it is busy downlo~(ling audio-visual il~c,ll,.aLion to fulfill another request, then the DSI
30 simply l~Llicvcs the lc~ues(~~ video clip from another location.

STQRING A VIDEO CLIP
When a new video clip is received, the PIM 22 must first ~)r~ P.
which eyt~nrip~l or remote SRU 26 or 38 will store the audio-visual u~ollllaLion. The PIM 22i-lf~ s the IMs 34 ~u~ulLiulg that video S~~ ll's region by cu...~ g theregional ifl. .~l;l;."~ The PIM 22 then checks to see whether these SRUs have available FDV storage. This is because most new video clip listings will fall into the FDV c~L~gOly. If sllffl~i~nt E;DV storage is found, the video clip is stored on that SRU (26 or 38), and the supervising ~'s (22 or 34) A/V Data Index r~t~h~e is up-l~tP~ However, if no suitable storage is found, the PIM 22 will cl~ ;--r the SRU
with the lowest FDV allnc~tion and store the video to that SRU.
A video clip is stored as follows: (1) A video is t~n~mitt~ to an SRU
26 for stor~ge; (2) the "SRU supervisory process" writes the il~---~lion to the disk PCTrUS96/10403 WO 96/4128'.

and retums the storage location of the data to the PIM 22 (the format of the storage location mPcc~ge is de~e..~ on the type of file: UN~, DOS, etc); and (3) the P~q22 writes the video clip's storage address into "A/V data index" (l~t~h~cç on the PIM
22.

RFTRIEVING A VIDEO CLIP
Figure 3 provides a ~ of how a ~.~Çt;l~l;d embodiment of the invention would operate to search and download data. The user first builds a data query at the user termin~l 14 from the text rl~t~h~ce For example, in the real estate 10 applic~tir.n, the user would specify a sel~rt~ Ly criteria from the MLS. Once constructed, the query is l.,..l~...i~l~ to the PIM 22 via a local SRU 18. The local SRU 18 mo~ifiPc the query in the following ways~ tt~ hPs a regional i-iPntifiPr to the query; and (2) sedl~l es its own rl~t~b~cç and flags each request that is stored at the local SRU 18 by a~elldil~g a Revision Code to the request. The audio-visual data15 index also sl e~ s the exact locations of the audio-visual data stored at the ~
SRUs 26 and, via the remote IMs 34, the locations of video data stored that the remote SRUs 38. The PIM 22 uses the regional i~le.~ r to identify which remote IMs 34 contain the req~lecteci video segmçntc. Each i-1entifiP~ remote IM 34 ploces~es the query, l'~;""';"~ a list or ~ y of available audio-visual ,~,f~ ces to the PIM 22.
20 The P~ 22 also uses the Revision Code to dP(.,...~ wh.,~ller the video segmçnt stored at the local SRU 18 is the most current copy available. The PIM 22 ~bs~~ y downloads a list of all available video clips to the user~s te~min~l 14,intlir~tin~ which video clips are immç~i~tçly available by virtue of the fact ~hat a current copy of the video se~ P-.I is stored at the local SRU 18.
Using the list of ..... ~ .g rl~t~h~cP records and audio-visual lG~~ ces, the user it1-ontifiPs and selects individual records or groups of records for further viewing and manipulation. Ihis abbl~.~idted list is t~A~ e~l to the PIM 22. The PIM 22 creates a DSI 30 and cu.. ...~ tçs the exact storage location of each ~e lu~l~ video clip to the DSI. The DSI 30, in s~u~ l fashion, queries each 30 çYtPn~d SRU 26 and remote SRU 38 (if applicable) co~ ting the exact videoclip location to the SRU. The DSI 30 may have ml-ltipl~ address locations for each u~,l~ video clip, sonne locations being on the ~Ytpn~led SRUs 26 and other ti~n.c being on remote SRUs 38. The DSI 30 will first attempt to collect the video PCTrUS96/10403 clips from the e ~ n~i~Dd SRUs 26 before ;~ to retrieve similar i..r~,....~,;.~"
from the remote SRUs 38. The affected SRUs downloads the ~ d data to the 1.,..-~.--;l buffers of the DSI 30, where a 1Jl~3~1r~ P~ number of video clips may be stored in RAM until the local SRU 18 is ready to receive the ulrul...~ The DSI 30 5 updates the SRU access counter and t~n~mit~ this u~ On to the PIM 22 for use in monitoring d~m~n~iC on the SRUs. Once the data has been received by the local SRU
18, the local SRU 18 downloads the video clips to the user termin~l 14.
In the event that the queried SRU is ~Gsc,lLly busy delivering data, the DSI 30 may either use the ~lt~rn~te video address to attempt to retrieve the requested 10 video clip from another SRU, or else moves on to retrieve the next ~~lue,~.~;i video segmp-nt Whenever an SRU fails to deliver the requçstD~i video clip, the DSI 30 inc.G"~e"L~ the SRU under-run counter for that SRU and eventually co..~ tes this ulrullll~l;nn to the PIM 22. If the SRU under-run count exceeds a pl~rirl ...i..~
threshold value (co.. i-;~~-tD~ to the DSI 30 upon creation), the PIM 22 directs15 further .~ue;,L~ away from this affected SRU by having the DSI 30 query ~ltrrn~t~
SRUs for the video clip in~ "..,~I;oll In the event that the video clip is only stored at this location, then a delay will be G~l~Ou~ ed as the DSI 30 wails for the video~lru~ a~ion to be downl~ ~ The PIM 22 will also direct that the number of FDVs be decrt ~ ID~ for this ~ffeCt~D~ t-nde~ SRU 26.
In ~d~ tion~ since the SRU under-run count p~r~m,ter id~ntifi~-s the k)c~ti--n of "over-~.~Ds~e,d" SRUs, audio-visual data will be moved or copied from these heavily loaded SRUs to more lightly loaded SRUs (based on their under-run levels), in an effo t to di~L~ibuLe or flatten S~U dDn~n-l This load m~n~f~Dm~ntprocess wiU occur during off-peak hours. The SRUs s~DlDrte~ for copies or l~lncr~
25 of data will be icie-.l;l;~i from video usage i,lro~l;ol- ol,l~u,ed from the "Audio-Visual Access List" located on the PlM 22.

Data is preferably (1) ..-~ on the e~t~n~ed SRUs 26 which are most often queried for that data, (2) d~-pli~tt?A on local SRUs 18 which most often 30 request the data, or (3) may be ~ p~ at~D~ on other remote SRUs 38 as space allows.
This supply and dem~n~i approach, In~D~ ed by PIM 22 in response to DSI mo"iLo.ing inputs, provides fast access to the most reql~est~l iu~çu~maLion and eff~cient storage with a .. ~ of useful ~ n~-y without waste or loss of l,~.rO.. ~ tD.rn~tively~

PCT~US96/10403 the ~ wol~ may also be configured to always store each audio-visual entry in at least one other location (space providing). This redun-l~n~y introduces improved throughput and offers irnproved reliability.

S COl~UNICATION l~TERFACES
In a IJlcÇ~lcd emboriimP-nt as shown in Figure 1, the system provides a plurality of ~Ytpn~p~d S~Us, each of which co~,.,.~.lnir~tçs with the P~ulla.y Index M~n~ger (PlM) 22 and the Data SequPnt~in~ ~nterf~ce (DSI) 30. This provides a flexible, high capacity, high throughput system which can be readily Pxp~n~lP~l as 10 needed, and can provide for PfflriPnt distribution and bach~p of video clips and other data on the system. Also as illuctr~tP~ in Figure 1, the video clip system may co~ tç with other systems, for al~ceCcin~ video clips or other data stored at remote locations.
~o"",.."~ tion bcLwecn the PIM 22 and the remote index managers 15 (IMs) 34 is primarily con~r-. ..PA with queries and results of que~ips~ and is f~cilit~tpci in a p~ ~d emhorlim~nt by a very high speed nc~wu,k 20, for example, the Fiber Di~l . ;l.ul~ Data TntPrf~e ("FDDI") which approaches speeds of 100 megabits persecond. The PrhI 22 CQIu~ul~ tps with the PYtPn~P~ SRUs 26 via a similar very high speed IIGLWO1h 32 where the eYtPnrl~PA SRUs 26 are located on the same CC""I u(~r as the P~ 22. ~Itern~tively~ other lltlwOIh:j may be used, for example a very high speed ATM n~,Lwolh in embodiments where the ~xtPnrlP~ SRUs 26 are di;~L ibuLed in a wide area ne~wu.h (WAN) confi~ulaLion. The PIM 22 further co".. i~ s with thelocal SRU 18 via a high speed network 16, such as ISDN. Whenever a DSI 30 is rr~tP,A, Pr~q 22 cOI~ u~ tP~s with the DSI 30 via nrLwo~h 36, and like PIM 22 CO~n~ t;On with ÇxtPn~P~ SRUs 26,is via a very high speed intp~aee (for example, FDDI, FireWire, or AI~I).
Co------~ ns belw~-l the e~lrl~ed or remote SRUs 26 or 38 and the DSI 30 are via a very high speed i.-l~ ~r~e 24, for f y~mplP, FDDI. This Co~ n intf~ 'e ~ 7~01~:i the throughput of vast amount~ of audio-visual data.
30 In co~f~t, the co.~ inn intPrf~-~e 28 bf;l~f~.l the DSI 30 and the local SRU 18 is less df~ ndi~ and may be via a high speed aSDN) i~lf ~ e It is ~ ble that the Cb~ tit)n intPrfa~e 28 between the DSI 30 and the local SRU 18 be at least 56 KBAUD to support the "real time" video ~c~luile~lle~ of a~ ~u..alt;ly 15 f p s Typically, the local SRU 18 and the user teTmin~l 14 are located in the same CO~ )uL~
providing for a very high speed co---- .~..~ir~tir~ns interfare The remote IMs 34 are linked to their own PxtPn~ A SRUs, shown as remote SRUs 38 in Figure 1. Remote SRUs 38 cU~ ;r~tp with remote DSIs 42, 5 other local SRUs 44, and other user tPnnin~lc 48 according to the same flexible hie~ y as the eYt~n~leA and local design dPscrihed above.

EXAMPT ,F~
R~lc;,enLali~re non-lirniting eY~mplPs of the invention follow, and ct~tP how the invention can advantageously be used. It will be readily ap~a,~
that, in addition to these examples nullll_~uus other applications of the video clip retrieval system are possible and are within the scope of the invention.

Example 1 - Real Estate In an embodiment of the invention for use with real estate data, the user would use a ~.u~c~ty ~i~t~b~P like the Multiple Listing Service as the p~ a,y text .l~t~h~cP, to ~e~ P the p~ -lies the user wishes to investig~tP~ The user forrnnl~tPs an initial search query which is l"...~ A to the local SRU 18. The local 20 SRU att~chP~ the Regional ID to the query, which, in this application, may be the ZIP
code(s), map, Cartesian, or GPS cOol.lillal~(s) accoci~fPd with the l~lue~(eA ~upe~Lies.
The local SRU 18 also Seal~ leS its own storage f~rilitiP~ to del~----;--r whether the ,~uesl~d video clips are stored locally and, if so, ~tt;lrhPs a Revision Code toavailable video clips. This enh~nre~i query is l.,..l~.ll;lled to the PIM 22. The P~ 22 25 (1) updates the video clip usage tables; (2) uses the Regional ID to efflr;Pntly d~ t~ ...;n~e from among many remote IMs 34, which remote IM 34 has any ilLformation .vaul~ to the enh~nred query; and (3) uses the Revision Code to ~ ;nP whether the locally available video clip is up-to-date. A list of available video clips is ed to the user. The user may then choose the video clips the user desires to 30 view. This request is lc~ P~ to the PIM 22 via the local SRU 18. The PIM 22 creates a DSI 30, indir~ting to the DSI 30 where the requestP~ video clips reside. The DSI 30 directs the P~tPnflP~ SRUs 26 to download the video clips into the DSI 30 tr~ncmit buffers. The video clips are ~ rA to the local SRU 18, and are ~u~s~u~ ly displayed at the user termin~l 14.
In this i1ll-ctr~tive application, any available seCo~ry video may be cataloged accol~ g to the geographical region it 5~1~)U1l~.. A list of SPC:On~ ly videos S may be displayed in a "Seconli~ry Video" window on the ~ubs. ~ 's termin~l whenever the ~lu~ly video is viewed. When the user l~ue.~ls the secon~i~ry video, this request is l.,...c...ill~A to the PIM 22. The PIM 22 has already determin~ the location of the spcr~n~1~ry video i~ alion. The PIM 22 either uses the previously created DSI 30 or it creates another DSI 3û and passes the lo~tinn of the secoll.l~y lû videos to the DSI 30. The DSI 30 then directs the SRUs co..l~;..;..~ the second~
video u~ f;on to download this i-~ol",a~ion.
In a fur~her embo-limPnt of the invention, the ylope~ly's coul.lil~alcs are obtainedl from previously established map data. In another emb~f1imPnt the longitude and latitude of each ~lupelly is ol,l~ined using a Global Positinning System (GPS) 15 system, for P-Y~mrle when the P1U1JC1IY is being f~ned, and may be recorded along with the plu~lly's colle~ollding text data.
,le 2 - ~,sc-;~lion Drug I..rul..lalion Another application of the invention is dilcclcd tow~is providing online drug ~ sc~ o~ u-~ ;o.l to ~hy ,i~ s. Tr~liti- n~lly, ph~rm~Cpnti~l co...l.~..iss2û have utilized very c~e~lsi~e detail forces to physically meet with physicians to educate them about plu~licl~y mPAi~tions. However, lcce.~lly~ with the tl. 11~ u11s dOwllwdl~ Ul~ on ~ulcscl;ylion pricing, the rapidly rising costs of drug discovery and development, the speed of reverse P',g;n~ E by co...pe~ and the more liberalgeneric drug a~-uv~l policy, drug co...~ s can no longer afford a full detail force 25 to market their ~.~-iel~y drugs. At present, high quality video c~C~ette~ areprûduced abûut the drug, and are sent directly to the phy~icid~l in an attempt to supplement the sales force.
One e.llbodilllent of the invention provides ready access to audio-visual ;.,r,,....~l;..,. about various drugs available to the physician. As with the real estate 30 app~ tinn~ a third party text ~l~t~hace may be used, for exarnple, an on-line version of the 'IPlly~ic~ns Desk Reference. " The physician may simply search through the on-line dA~;~b~.~e and select a list of drugs that the physician would like to view on video.
The system will search for, locate, and download the ~ terl audio-visual , PCTrUS96/10403 u~U~ ;r~n The drug videos may serve a variety of r n.~ c For ~Y~mpl~, the physician may use this audio-visual i.~ro~ aLion to learn about new drugs, or simply to refresh or update their knowledge about existing drugs. Also, drug Co~.p~-iFs may place advG-I;c~ about promotional drugs on the video clips for use by the physician.

PY~n~ple 3 - Retail Services Another application of the invention is directed luw~ds the retail industry, for example, the sale, lease and/or rental of new and used ~l~tomobil~s. The text ~l~t~b~ce could include a listing of automobiles, price data, ~,rO. n~ re data, etc.
The video clip retrieval system would retrieve pGlLine.lL video clips, thereby ~nh~nring the available text d~t~h~ce. Another ~rplic~tinn in the retail arena would be to provide multi-media illrû~ u on bl~cinrsces or services such as those listed in the "yellow pages. "
P.Y~nlRle 4 - r~ GI
A further applir~tion could be directed to the ~.,..~olln~.l industry, where video ~ lls could be used to enh~nre available text il~o,ma~ion profiles onsl)e~;l;PA employees. Such ih~ ;on may enculllpass providing il~.lllation to hP~lthr~re providers about existing and p,u~Li.~e p:lti.ontc The system may also be 20 used to provide il~ollllaLiun about the h~-~lthr~re providers to p~ti~ntc These videos clips would help the patients/consumer make a sel~octinn~ by providing a way to screen the physicians by providing bac~glùulld iulrulln~lLion on e~uc~fion and areas oft;~pe,Lise, as well as providing a video depi~tinn of the hc cph~l or clinic.

EY~nu~le S - Dating Services The dating service industry is yet another area where the video clip retrieval system could be lltili7~1 Video clips of pul~llLial "dates" could be shown by the dating service to assist custnmers in oblilil...lg suitable p~l~e~.

PY~m,l71e 6 - Travel Services Yet another application of the system is in the travel business where travel agents can access video clips of holiday locations for cnstomrrs to view.

PY~ml?le 7 - Internet Example Figure 4 is a block ~ ~m illll,ctr~ting a ylcÇcllcd embodiment of an TntPrnPt-related video clip storage and retrieval system according to the present invention. The system inrl~dec a user termin~l 50 and a local SRU 51, which is linked by a con~ tinn line 52 to the TntPrnPt service provider's ("ISP's") head-end ncLwo-h col..."l~ tinns interf~re 54. In a ~ler~ ,d embodiment, the intPrf~e 54 is an item commonly referred to as a network "termin~l server." The intPrf~ce 54 can also be a nti~wo~h router, switch, hub, co~ u~e., or other co~ r-~tinn device, capable of :iu~olLu~g a large number of user termin~lc.
In one embodiment of the present invention, the tennin~l 50 is a personal co",~uler lun~ g an HTML bro vser 82 vith an audio-video decoding and playback '~b-u~ser extPncion'' 84 as described above. The b~uw~e;r 82 offers theIlPr,~ filnrtion~lity to query and search data disL-ibu~cd across the TntPrnp~t The bruw5~r cx~ c;~n 84, in addition to orre-u~g audio-video display capabilities, possesses the logic l~ui~d to access audio-video and other data o.~al~ed and ~1l5illli~;llf~i by the local SRU 51, and to decu-,,,ul~s~ audio-visual data derived from the present illvellLion l~..uugll the local SRU 51. As will be ~l;sc~c~l below, the b.uw~
nsion 84 further allows the user to interact with audio-video clips.
The system also inrlll-i~Ps a PIM 64 and one or more extPnd~1 SRUs 66.
In a ~.ef~ d embo~iimPnt the PIM 64 inrlndec a modified Web server 68 and a ~t~h~ce management module 69. All of the fol~going components, inrlnrling the intPrf~e 54, are cû,-~lf~ r~ to a regional head-end backbone 80 within the user's home region 81. The backbone 80 may col"~lise any of a variety of known physical network co..,~one.,L~, such as FthP-rn~t and FDDI linked t~.g~;lh.- by assorted ~wil~;hes, bridges, routers, and hubs.
Also, on any CC'~ JU~ coml~ted to the backbone 80, one or more tr~nCient DSI ~,oces~es 58 may be created. Such DSIs 58 may be created by the PIM
64, as ~G~uil~l, for each user receiving audio-video content by the invention. The backbone 80 CO"'~ fS with the Tnt~ornet 56 via one or more nelwc"h routers 112.
A neigl.l~c,,i,lg region 89 is also shown. Like the home region 81, it inr~ s an index manager ("rM") 88 hosting a Web server 93 and a ~l~t~h~ce manager 91, at least one eYt~n~l SRU 92, l~lh~ --1 DSI ~uces~es 94, and a router 95. Therouter 95 is Co~ l~i to the Tntern~t 56. In addition, the n~l~o,i,~g region 89 is PCT~US96/10403 connlo~tecl to the home region 81 by way of a high-speed ~ler~i~zttp~ line 96 bt;l~Cell routers 112 and 95, allowing the SRUs and DSIs of the regions to co.. .ir~ztte. The ~1PAi~zlt~ line 96 can be COI~-YOn~ ~IL ~ of the existing Tnternft u~lasLluclulG or new cu.. ~ irzttinn lines added to supplement the TnternPt infrastructure. The neighboring region 89, like the home region 81, also has a head-end neLwu.h co... ;~ r.n inttorfzlce 98 capable of SuyyGlL ng a large number of user tenninztlc.
Note that the neighboring region 89 need not host its own IM 88. If the users local to the nei~hbol u-g region 89 are low enough in number that the cost of Ill t;lllnil~ an ad~itir~nztl IM 88 is prohibitive, the PIM 64 for the home region 81 can be used to control the other col-.pon. I~L, of the neigl.bo,.ng region 89 via the dcAi~ztt~i line 96. Furtherrnore, an "intranet"-like structure can be created by utili7ing a single PIM 64 capable of controlling a number of regional groups of SRUs (such as extenfie-' SRUS 66 and 92).
The content provider's region 91 is also shown. It, too, contztinc an IM
90 hosting a Web server 83 and a ~lZttZthZtCe ~U~ f - 85, at least one extf nrl~ SRU
100, one or more trz~n~iPnt DSIs 102, and a router 86, which is co~-~t~ to theTntf~rn~tS6. The ~ tl~ line 96 can also link the content provider's region 91 to the other regions 82 and 89. A head-end nelwu~h co.. lt.-;-~zttirtn int~orfz~e 104 cc,.n.~
the content provider's region 91 to a number of users, inr~ ling the provider who will upload audio-video content.
The filn~ tisns of the folGgoillg components will be rli~uu~ed in further detail below.

A. O~_...liou from the User's r~ e~
The user t~rrninz l 50 is the device through which a user int~r~cts with the delivery system. The tenninzl 50 typically is a personal colllyuh~, wo-k~lnl;n~-, or television set top box. The tt~--rninz l 50 is capable of running a bluwser 82 such as Netscape Navigator, and when yr~lllyled to do so by the bl'UW;7'el 82, can also run an audio-video playback application as a "plug-in" or b~uw~e~ r,xlr,ll~ n 84. The b-uw ,~r ~xt~n.~inn 84 receives audio/video data in yluleclGd md co---y-c~ed form, and provides a ...P~h~ --- for the user to rcceive, ullplolGcl, deco~p.Gss, and manipulate (i.e. play, rewind, stop, etc.) retrieved clips. The b.u~. SG~ extl~n~ion 84 is also capable of l.,...~...;ll;Ug data back to the nGIwolh 80, either through the I~1~W;7GL 82 or PCT~US96/10403 33 . .
inrle~nf~ ly~ In a ~rGre;,.Gd embo-lim~nt the bl~sc~ c~ 84 uses r~ ;o~-c - provided by the local SRU 51 to co~ tP with the delivery system of the invention.
A ~rc.l~,d embodiment of the present invention is conl~n~lated for use as a premium ~- bse~ ;plion service. The end user ~..I,sc. ;I.es to the ~/le.lliUIII service in order to be allowed access, and in one embodiment, the user is sent a confgurdtion file to be stored at the user termin~l 50. The configuration file co..l;.;nc a unique subscriher identifir~tinrt number, as well as the Tntprnpt address of the PIM 64 to be eA by the user. The P~I 64 .--~i- l;-;--c i--ro....~l;nn on the ~lhS~ Cl in a user t~h~cP~, namely the types of content sub5ç- ;l)ed to, user p~c;Çe~nees, limit~tir n~ on service, and billing h~lllldLioll.
In one embodiment the user rl~t~h~ce co.. L~u-s the following i lrul,aLion for each user:
Item Name Format Des~;~li~
Counter ~----.-- - ;r ~ihlldly index for the records. Each record ~ sc.lLs one s-~bs~ l;on ~CCOunt Player Number .. ~ c- ;r Unique ~ l;on number for the b~un~e~ eYtPn~ n 84 inct~llPA on the tPrrnin~l 50.
User ID nnmPric Unique number that ~ Pntifi~pc each ~hs~. ;her to the p-~,.--iu--- service.
This is a multiple-valued item such that multiple User IDs can be ~c~ c; l~d with a single player 44.
User Ratings mlmPrir array The content ~ c~ti h;lity ratings for a specific user.
Services SUbsr~ ccl nllmPric array The list of services to which the user's account has subsrrih S.. l-sc~ n Date date The initial subscription date.
Expiration Date date The e~ilalion date of the \~rZ~k;lllll--l Charge ~---~ .;c The ~ ,.;.. monthly e~ nce that can be i l~;ullGd by the account.

PCT~US96/10403 . 34 Demographic Info text array Name, address, ~)ay~ L m~tho~, etc., used for billing.
Usage Info text blob A log of all video clips ~ccPcc~
inçlllding date and time. This is for billing and user ch~ ;On The P~I 64 also m~int~in!c ihlfO~ dliOn on the audio-visual clips stored on its extPn~ed SRUs 66 in a clip d~t~h~e (col.e~ollding to the "audio-visual data index" previously tiicc~ d). In one embo~iim~t, the clip ~l~t~b~to co.~ c the following i.~lll.alion for each clip:
Item Name Format Des.. ;~lio~l Counter numeric Primary index for the records. Each record lG~lesGIlls one video clip.
Video ID text The globally unique name of the video clip, as ~reeifi~d above.
FYten~l SRUs IP array The IP addresses of all the P~tPnr~ed S~Us 66 which contain the file.
Copyright boolean A flag to indicate that the file is copyrighted and must be protected.
Charge l\~e~ lll nnmeri~. A code lG~JlG~t"llhlg the mP~h.~
for çh~ing for the file (pay per view, one-time fee, etc.).
Charge P~r~mtoter~ nnmeric array The amount charged per use under the specified charge mPrh~ ."
Expiration Date date Date after which the file is to be removed from the system.
Size of File mlm~ric Size of the file, in bytes.
Date date Date the file was made by the content provider.
Time time Time the file was made by the content provider.
Category mlme ic The subject calego.y of the file, used for load projections as rli~cu~c~d below.

W O 96/41285 PCTrUS96/10403 Usage Count m-mPric array The l~;.clu~ 1 rlG4ucncy of clip access across days and hours, used for load ~lujP~;Iion~
Segm~nt Info textlmlmpri~ If the file is segmpntpA this is the array of s~Pgm~Pnt dei,c~ and poillL.,~ into the file.
Link Info text/numeric If the file has been ~i~n.~l ~leA with links to other files, this is the array of link names, URLs, and poi into the file.
The PIM 64 also ~ llÇo,.. ~ n ,eg~.li~ each of its e~tçndPA
SRUs 66. Such infonrlation is stored in an SRU d~t~h~e as follows:
Item Name Format Des~ ion Counter nnmPric P~illlaly index for the records.
There is one record for each Ç~ P~l SRU 66.
IP Address IP The Tnt~rnPt address of the SRU.
Current P~lrv.. ~nre mlmeri~ A value that l-~se.lL~ the current ~.ru....~ e of the SRU.
Theoretical Pelr~.. ~n~e nnmPrit~ A value that lc~ 5~ ; the theoretical m~;-------- f~e delivery rate from the SRU.
The user can, using the blvw~er SOr~w~ 82 on the user t~rmin~l 50, browse the Web, ~cc~ing Web pages and selo~ting links as is known in the art. Atsome point, the user may wish to access a video clip h~n~lP~ by the s~bs~ ion service. This is done by acce~;..g a Web page on a content provider's Web server 83 or elsGwhGlG. The desired clip may or may not be among those the user has s~lhscrihed to.
The content provider's Web server 83 can ~ lly~ on the basis of a combin~tion of the user's and the ISP's s~bsc. ;l)Lion p~r~m~terS known to the content provider, create cu~tomi7YI Web pages for each user. This ~l~,cedul~ is known in the art. Preferably, the custom Web pages can be created on the ISP's regional Web server 68 (part of the PXM 64). Such an action can be unf~ k~n at regular intervals, for PY~mple daily or whenever new content is made available to the system, or j""..~r~ t;ly upon access by a user. By ~ccç~ g custom Web pages, the user will be informed of what subsc, ;l.Lioll content is available, based on ..ubs~ ;nn h~o~ )n, col,L~ined in the user r~t~h~e ~licc~ P~ above. In this way, the ISP can create a "video guide" set of Web pages cu--~ information the user is illL~G~led in, in-c~ ling .I,bsc~ ed-to video clips. The ih~rollll~Lion conlai.,~ in the ISP's "video guide" can be ;..I~.g.,~l~d with the ulrol",~Lion stored on the user's local SRU 51, thereby providing a se~ml~ss view of all content available. By s~ ting a link on the custom Web pages, the user can request a Web page co..~ s~hs~ipti~n content, which will then be delivered by the system of the invention, even if it is not present within the user's region 81.
At that time, the ISP's Web server 68 (or other Web server 83 or 93) begins to tl~ il the Web page to the user tPnnin~l 50 via t~iitinn~l means over the TnternP,t 56. Accordingly, data moves from the server (e.g. server 83) to the co..cis~o,,~li.,g router 86 to the Jnt~rnPt 56 (across potentially many nodes) to the user's ISP's router 112 to the head-end co....".,. i~tion inte~ e 54, and eventually to the t~rmin~l 50. A lGr~ nce to a desired clip is çmheAded within the H~L of the Web page. When the user's bluwser 82, e.g. Netscape Navigator, receives the lc;~l~"ce, supplied for example within an ~MRPn tag, an ;.. ~ , request is made of the Webserver 83 to ~"n~...;/ the embedded fle.
The type or format of the embedded fle is analyzed by the bluw-e~ 82.
Typically, this is in~ tP~ by an .oYt~n~ion on the fil~n~m~ of the embe~ded f~e and is known in the aIt. If the desired file is a video clip, the local SRU 51 belon~;n~ to the t~-min~l 50 and the bluw~ er P~t~n~iQn 84 are invoked to receive the data. First, the local SRU 51 ihll~.~;~l. a video ID, a unique ide~.l;r~e~ ~ecirying the sPlP~ted clip, which is stored within the ~MRPr~ field in the Web page. The local SRU 51 first Ps if the desired clip is already stored locally. If not, the local SRU 51 passes the video ID to the PIM 64 associated with the user's tennin~l 50. The local SRU 51 then awaits aulhol~Lion from the PIM 64 to ~luceed with a data ~ r~
The video ID corlci~tC of a ml-lti~lim~nci~ ~l set of content-~h~r~. (~i,;, .~;o.. couldu~alcs plus a unique file name. The content cour.lu,atcs enable a match with the regional IMs that have subscribed to that type of file, as will be ~I;c~;ucsecl later.
In one embo~imPnt the video ID is constructed from the fûllowing portiûns: a text name of the file as defined by the content provider; the content PCTrUS96/10403 provider's ~ccount number as provided by the o~ ;nn lUlll~Ulg the ~bs~
~ service; a CdlCgOly coo~ ,aLG, possibly a l~lGs~ licn of a l~lalchicdl portion of a category tree, a geographic coollu~alè used to ~letPrminP where the fiIe is relevant (e.g. a region, state, or city); a time stamp, and a tirne period over which the file is relevant. The ro~Ggoi-lg Ch~r~Cter;Ct;fC are known at the time a file is made available to the present system, and will be diccuccp~l in detail below.
In a ~lere.lcd embo~limP-nt, the local SRU 51 passes the video ID to the PIM 64 in the following form: a "virtual URL" is consLl,u;LGd in the forrn "http://"
plus the TntPrnPt address of the P~ 64, plus the user's ~..bsc~ cr ID number, plus the video ID. If the desired clip was located on the local SRU 51, then the virtual URL
request will contain a further au.iL.ule ~e~iryi lg that a p~rti~ r version of the file has already been located by the local SRU 51. The Netscape Navigator p..,ce lu-cNPN_GetURLNotify is available to accomplish sending this virtual URL to the PIM
64; the virtual URL is constructed to be in a format that will be ~cepterl by Netscape Navigator and other n~lwo~k 1~ W~e1~. Upon rcceipt by the PIM 64, the virtual URL
is deco-"~o3~d into the video ID and ~h5~ P.rID COl-.~OnC.-I~ which are then used to access the PlM's intemal rl~t~h~cP5 The PIM: 64 checks the user's s~lhscrirtion rights in its user ~l~t~h~CP
and if authorized and nP~e~ , initi~tP,s a DSI process 58 to download the desired clip to the user's tennin~l 50. The P~ 64, having idPntifipA the clip co..~ onding to the video ID in its clip ~i~t lb~c~P~ passes ih'ro~ inn to the DSI 58 lcga~dulg which PYtPnriP~ SRUs 66 have the clip. The DSI oversees initi~ting the lla..srcr process, e--s-~ g that data is sent from the ~ lia~e ~ .U1e~ SRU 66 through the i~ ri~c 54 to the user's pnninql 50. The data is then downlo~tled from the ~ ialc eYtPn~ed SRU 66 to the user's tennin~l 50, at which time the local SRU 51 will iulL~lcc~L and Llall~rc. the data to the b~owsel Ç~ 84. The b~wser ç,~tPnci~1n 84 can manipulate the data, store it in a storage area local to the termin~l 50, or prepare it for viewing, as desired. If the PIM 64 ~l~t ...;nFs that the user has not ~bsc.;hcd to the clip ;...~ ~1 by the sPl~rtP~I video ID, no DSI process is invoked, and the local SRU 51 will be n-tifiedl that either the clip must be downlo~P~ directly from the Web page, as is t~litir~n~lly done, or that the clip is entirely unavailable to that user.
Accol-lingly, the PIM 64 c~c~ci~es a m~n~geri~l function in the present iulvcllLion. The P~ 64 inrl-ldes a ~l~t~h~ce with dpt~ r~.. l;r~n on the clips PCT~US96/10403 sto ed on the PxtPnnP~ SRUs 66 ~o~ d with the PlM 64, for -x; ...p7~, the lnc~tinn and fi1~n~me of each clip, and aLLlil,ulcs such as subject matter, rating, file size, exri7~tion date, charge u~rO~ inn, etc. For clips not on an ~ .1~1 SRU 66, another IM d~t~hace ,,~ c a reduced level of i. rol-nalion about every IM, namely the Tnt~rn~t address of the IM and the content cooldinales of all audio-video fi es that it ~ ;,.I;.inc For e~mr~le, a ibrary of "news:sports:b~cek~11" clips might be P~I by several nearby and distant regional ISPs, in-h1fling the one comprising the user's region 81. As previously in ii-~t~A the PIM 64 also has a user d~t~h~P, which stores ~ro...~1inn on each of its users, namely sllbsc7irtion rights, aull-csli~ed rating levels, accrued charges, charge limits, etc. Upon receiving a virtual URL from a user, inrli~ting that the user wants to receive a c,ip having a ~e~ifiP~ video ID, the PIM 64 ~ccecseS the user ti~t~h~ce to ~ whether the user is valid. The PIM 64 then accesctos the clip ~t~h~e to d~l~-...;..F, based on clip all.;1.~fs, wllGL11.. the user has valid s~bs~riptinn rights and is ~1lthori7~A to download the desired clip. At this time, the PIM 64 can also check to dGI~ ~..;l1F if down1n~1ing the desired clip will cause the user to exceed his charge limit.
If any of the ÇolGgo..lg ~1~t~h~ce checks fail, the local SRU 5l will not receive ~ .o~ inn for the download, and the reason for the denial will be 1.,...~...;Lled from the PIM 64 to the bluwse- eXl~ ;on 84 and bluvvser 82 user int~ ce via the local SRU 51 to advise the user. If ~lt~rn~tive versions of the desired clip are available which would be ~11thori7P~ given the user's s~bsc-;l)Lio~ l;o.~C, the user can be ~1~ se.lled with the option to download the ~1fPrn~tive versions.
Upon a ~I~IL ~ tinn by the PIM 64 that the user is authorized to receive the desired clip or an ~1t~rn~tive version, it is ~ ~ as noted abovewhether the file embodying the clip has already been received and stored by the user's local SRU 5l. If so, that version of the file is co-n~ d against the current version stored in the clip ~l~t~h~ce on the PIM 64. If the file at the local SRU 51 is current, no download is nF-~-ec~..y~ and the locally stored version is l~ .Cr~-.Gd to the b-uw~ir f-Yt~oncion 84 for playback. If the file at the local SRU 51 is ~u~ eded, expired, or non-P~ictent~ steps are undertaken to download the proper file to bn)~er eYten~ion 84 via the local SRU 51.
The download is initi~tP~ by the following procedure. The PIM 64 queries its clip ~1~t~h~cP to ~lete.lll;l~F on which PlrtPnr~P~ SRUs 66 the desired clip is W O 96/41285 PCT~US96/10403 stored. If the clip is available on more than one extPn~eA SRU 66, the ~ A SRUs ~ 66 are prioriti7P~ accord.. lg to al)p~l,.ll load, with the least busy SRU 66 being given the highest priority. The PlM 64 then invokes a DSI 581 and provides it with a ioliL~ed list of SRUs 66 that contain the data.
The DSI 58 invoked by the PIM 64 selects the highest prioritg (least loaded) SRU 66 from the list provided by the PIM 64. The DSI 58 then oversees the transfer from the çxten~eA SRU 66 to the t-Prmin~l 50 via the infPrf~re 54 and local SRU 51; it does so by ad.l-~,ssi.lg the desired video clip with the TntPrnPt address of the user's local SRU 51. If the DSI 58 dt;l~J .~ s that the selectP~ ext~nllPA SRU 66 is overloaded or unable to respond (e.g. has not responded before a timeout), then the DSI 58 ~ c to use the next-highest priority extPnrlpA SRU 66 until the download is succeccful or until its possibilities are e~l.,...~leA At that time, il Çu~ aliOIl on download latency (i.e. which SRUs were unable to handle the download, and how long it took the su~cP-~rl.1 SRU to begin the s~ccPccful l.~1~ÇG ) is sent back to the PIM 64, to allow the PIM 64 to dy.~ lly rer~lr~ te ~I;o.;~;vs and a~cl-l loads.
The DSI 58 is a sunwalG process which, as in~ir~tP~A above, directs and oversees the download process. The DSI process 58 can be hosted by the PIM 64, an SRU 66, or a st~nrl~1nne server co~ f~leA to the PIM 64 and ~ n~i~ SRUs 66. To reduce bandwidth needs for the present invention, mllltirle l~ue~ for the same video clip from several users can be queued by the DSI 58 for a short period of time (for ex~mrle, from one to fifteen seconds) before the clip is sent. During the quelling period, the DSI 58 can be receiving the clip data from the a~lu~lialG SRU 66. At the PYpi~tion of the queuing time, the DSI 58 can then mnltit~ct the clip to aU of the users requesting the clip. To the extent that the path to all of the l~lue,~ users is the same (i.e. from the DSI to the head-end nGLWU1h;~ r~C 54), mlllti~cting permits the use of only one l-,---~---i~;on ~yeciryiulg the TntPrnPt add~- ~ses of all of the lion te~min~lc. Mnltir~ct l~llni.ll~rs will be ~iicr~lccP~ further below in the section on nl~lo~l;ng new contPnt F~ --r~re, the DSI 58 also su~ulls data prote~ti~n To tlicrollr~ge distribution of cc~ylightGd video clips by end-users of the present system, the DSI 58 will falsify key data fields of the audio-video clip, such as the MPEG
"se~uenre_header" data ~L1U~;IU1~ with data ~lesi~nP~l to make playback diffirlllt The correct video stream confi~...,.l;oll data will be stored in an e.~ Gd state (via known PCTrUS96/10403 e.~ y~Lioll methods, such as DES and RSA) in the MPEG system i~Llu-;Lulc "user stream" as defined by the MPEG specific~tinn Similarly, data derived from the user's ID will be added to the video datd (namely MPEG DCT macro blocks) as noise at various points along the stream, thereby w~e~lllAIk;rlg the file. The locations of this data is defined by a string of random numbers having a seed number stored within the encly~lcd portion of the user stream, as ciicc~-cse~ above. The seed number, in conjunction with the clip title or video ID, is also archived in the user ~l~t~h~cP, belongin~ to the PIM for later lGr~,.ence should it be ~ d that the user stream and user data block have been removed from an MPEG file.

Note that not all files must be yrùLe;led as in~ tP~ above; the e~ict~n~e of the scheme is partially contc-llplated as a dclcllc-lL factor. Fu.ll.~ ore, the wat~ k;~g enables ~ s to track down copyright vi~ tnrs Asdes~rihed above, the DSI 58,uluL~;l~ a clip based on specific user ;"r~,.""~t;on obt~in~ from the user ~t~h~ce of the PIM 64. The user's bluw~er PYtpncion 84 can ull~luLecL the clip based on the same i,lrullll ~t;oll Accol.lingly, only the user l~l.,e~ the clip can unprotect a ~lulcclcd clip.
The protection and w,.l....~,..k;i-g steps are optional; the present invention colllelll~lates that certain clips ~e.g. a.l~.Li~ g, public service an~ e~ , and u~lco~ylighted rn~teri~l) can be left ul~lvl~;Led. This would be in-lic~t~d by an aLllil,ule in the clip rl~t~h~e In this case, the DSI 58 will not protect the clip, and the clip can be received, stored, and viewed at the user terrnin~l 50 without un-prote~tinn F.lllhcllllore, the user could be free to 1~l;~ llr such unprotected clips.
As in~ tecl above, a system accol~ling to the present invention can have multiple index m~n~r.c for a large number of col~ users in ~ te g~".l,h;r~l areas. Figure 4ill.,~1~d~;S three index managers: the PlM 64 beln~ging to the user's geogr~phi~ region 81, an IM 88 bel~ nging to a ncighboling geographic region 89, and an IM 90 belonging to the content provider's region 91.
If the user's P~I 64 dell .".;nes that the desired clip is not on any of the e,~ttton~iP,cl SRUs 66, and the PIM dc;l~.",;.~Ps further that the user has s~ sc~;l.l;oll rights to access files from other regions, then the P~ 64 will query the closest IMs (e.g. IM
88) to cll t~ ;nP if any of the remote SRUs 92 local to the other remote IMs have the desired clip. The query can be directed to those IMs which are likely to have the clip.

PC~AUS96/10403 Each ~, inr.l...l;.~g the PIM 64, ,,~ c a d~t~h~cP of all other IMs co~ ~;LGd to the ~ system. For each IM, the ~t~h~CP in~ dP$ the TntPrnPt address of the lM, and i lr~,l.l.alion on the types of files stored by the IM's SRUs. The file type i~ n can be stored in the form of content cooldinaLe data, as previously ~iC~-ICCPfl Accoldingly, by conc--lting the ~i~t~h~cP" the PIM 64 can (it;~P""i"~ which IMs are likely to have the desired clip, and query only those IMs.
Each of the queried remote IMs, such as IM 88, l- *Jonds with a message inriit~fing whether its SRUs 92 contain the file, as well as i~,rc".,..l;~..~ on the a~a~ L load GA~ nCPA by those SRUs 92. If the desired clip is found, the list ofviable remote SRUs 92 will be t~ncfP red to the PrM 64. The PIM 64 will subsequently invoke a local DSI 58 with the SRU list to ~ r~, the file to the user's te~nin~l 50, as riicc~-ccP~ above.
If the P~M 64, after having queried the neighboling remote l~s, is still unable to locate the desired clip on an SRU 66 or 92, the PIM 64 will then contact the source IM 90, where the content provider first ~-pln~(~P~ the file. The TntPrnPt address of the source IM 90 is provided in the clip ~t~h~cç of the PIM 64. Lf the desired clip is still current (i.e. not expired or ~ ~IP~), it will exist on one of the SRUs 100 belonging to the source IM. A DSI 58 will then be invoked, as Aicr~cseA above, to download the clip to the ~G lue~Lu~g user's local SRU 51 and tP~Tnin~l 50.
As the video clip data is received, it is stored on local SRU 51 and con~;ullG--Lly sent to the b~uw~el e~rtPn~inn 84 to u~lulG~;L and display the video clip.
As ~Iic-~uccP~ above, the local SRU 51 stores the data in plvL~;LGd form.
~oncP,quPntly~ it is ~1~ L~Led against unauthorized duplication by an end user. If there is inc--ffi~ nt capd~iLy available in the local SRU 51 to store a ~ ue~ A clip, the search and update logic of the local SRU 51, ~licc~cc~d above, can delete some of the least-l~cenLly-used clips already stored to make room for the new data.
In a plerell~d embodiment of the invention, the clip can be stored in an MPEG, AVI, or QuickTime file format. Such formats are well-known in the art, andare capable of using various coll~ ssion scl-~-.-es. For example, MPEG 1 and 2 use the discrete cosine Lld~l~rol~ lion scheme, and MPEG 4 is ~l~posed to use wavelet colll~l~,ssioll. AVI and QuickTime files may genelally use such sC~mes as Indeo,Cin~ r, fractal, or wavelet Colllyl~ iOIl. Accoldingly, the bluw~el çl~tPrlcinn 84 of the invention must be able to illLGl~ld and ~lP~o~ s files of all types used in the PCT~US96/10403 invention, although not all co,~ ,sion formats and scll~ -..F-s noted above need be used.
If the user desires to view again a clip he has previously downlo~
and that is still on the local SRU 51, the b~uw~e. çxtPncion 84 can either allow the data to be ul~luLe~;lcd and viewed again without cost, or cause the local SRU 51 to query the P~ 64 and update the billing records if the desired clip is one that must be paid for each tirne it is viewed.
As a conc~u~ ~re of the fo,~oing schprn~l network load is 11~;11;111;~-~as co,,,~u~ to traditional digital video delivery systems. Many copies of a video clip can be downloadP~ in parallel to users in sç~ e geographic regions. The copies of the clip exist on servers local to each user's region, and in gçn~l, are l.,..~...ill~A
across fewer network nodes for each download. FulLhc.lllore, the eYtPnrlçd SRUs for s~."le regions have unique co.. ~.. ir~ .c paths, through each TnternPt service provider's head-end nelwolL to the region's users. Accoldillgly, many 5~ e downloads can be undertaken con~;ull~nlly in cCp~ le g~ hical areas without i.llp~ g (or being iullp~ilGd by) traffic con~liLions on the Tnt~m.ot 56 as a whole.
In ~d~lit~ as will be ~iccllccçd in detail below, each IM, inrlllfling the PIM 64, tracks the demand within its region for all clips. Clips that are infrequently accçcc~ within a particular region can be deleted from the çyt~n~d SRUs 66 and re-acquired from remote SRUs 92 or 100 only when nP~Pc~.y. In this way, local storage requirements are ...;..;...;~d Accol-lu~gly, for the clips in highest dçm~nd; it is most likely that the data can be downloaded from an ~oYtPn~içd SRU 66; this is the fastest path. For lower llçm~n~l clips, the nearest remote SRUs 92 will be the ones first qu~oriPA The re~onse times for remote SRUs 92 can be d~ d by inte~ctively testing the cv~ tions links (analogously to the "ping" ~lUgld~ll) to the remote SRUs 92 having the desired clip. The testing process is a co~ ioll of the following: the round-trip elapsed time for a test packet; available bandwidth Frl by delivering and lcceivil~g several packets; and the .,a~aciLy of the remote SRU 92 as l~olled.

PCTrUS96/10403 B. U~.a~~lin~ and Di~lril~u~ g New C~ltPnt The content provider is l~;s~un~ible for making content, narnely video clips, available to the present system. A surLw~t; tool is provided for that pul~ose~ It ~ is co.,lP~.. plated that the content provider will begin with a video clip in MPEG format (or another known digital video format). The content will then use the ~vrLwA e tool to assign a video ID, a rating, language and content A~l~;l,ul~;c, ~xri~tir)n dates, and other attributes to the clip, which will then be stored within the file ,~1.,5.'..1;.,~ the clip.
The MPEG file can be one having m--1tirle video and audio streams ~u~o.Li-,g various playback confi~...AI;nlls. For eY~mrl~, dirre.~ L versions can be provided in dirr~.e.,-languages, having dirre~c.-~ playback resolutions, having geo~lAr~ y specific h~-...AIiQ~ (such as tel~hone numbers), and having various rating levels (e.g. by cutting out or editing objectiorlAhle por~ions within some of the vel~ions). In a p.~rel-Gd e.nl)odi,.~t.,t of the invention, the data in the user dAt~h~ce be-l~ nEin~ to the P~ 64 is used to establish which version of a clip is desired by the user; upon download, the DSI 58 is di~ d by the PIM 64 to deco---pose the clip file and send the proper version.
The content alLlil,uLes Att~h~d to the clip are .e~ ed in the form of a hierarchy of subjects. For example, a clip could be ~nnolAIr~ as belc n~ing to the content areas "News:Sportc RAc~ball Yankees. " All four of these content areas would then be in~ At~ in the clip dAt~hAC5 of the PIM 64, as well as within the clip file itself. A wide variety of content areas would be pre-ectAhlich~l by the ol~An;~AIion providing the sl~bs~ npti~n service, for use by the content providers prior to uploading clips. It is further conte~lpldled that content providers having sreri~li7~ needs could add to the hic.,~ i~l tree of ~ul~je~ , with or without approval of the s~ s~ ,l;nn service provider.
As ~liccl)ssed above, the content provider will use the sorlwd c; tool to attach certain all.~ules to a clip file. I~e svr~wa c; tool will also co.. ~ Ate with a master dAt~h~e of video ID ~-~--b~ to ensure that each clip ~lrln~(le~l~ no matter from where, will have a unique video ID collsi~ with the present invention. The sorLwA G tool will then upload the clip to the content provider's Web server 83,allowing the clip to be .Ggi~ Gd with the present invention as descrihed in detail below.

PCT~US96/10403 When a content provider changes the content of a video clip, or makes a new clip available, the clip is uploaded to the content provider's Web server 83, and i.lro~ Lion about the data file leplcis~ ;ng the clip is sent to the IM 90 local to the content provider (the "source ~M" previously rliccllsced). The clip is then distributed to regional IMs and SRUs as follows.
The source IM 90 lGgi~el~ the clip in its own clip tl~t~b~ce~ storing illro....;1linn inrln-iing the name, date, time, video ID, sting, co~yligl.~ inform~tion, sul)s l;~Lioll h,r(.. ~ , content il r,~ n, and other ~ ul~s of the clip as the clip is t~ncferred from the content provider to the IM 90. The source IM 90 theninvokes the IM's stosge m~n~Pment logic to copy the file to at least one of its ~t~nr~ SRUs 100. The particular SRU or SRUs chosen can depend on load d~le...~ l;ons previously made by the source ~I 90, as gen.o~lly ~licrLIc5PA above.
The TntPrntot address of the chosen SRU 100 is also stored in the clip ~i~t~h~ce of the source IM 90.
The source IM 90 then ~ Ç l~ the updated file to other IMs throughout the system. As ~iscllcceA above, the ~ 90 ..,_;..~ a tl~t~h~ce of all other IMs in the system, and the types of content such other IMs ,..-;..1.;.. The receiving ~Ms accept the new clip and subsequently l,a..~rel it to their lc;~e~;Live SRUs. By way of the fol~oi"g mP~h~nicm, an ur~l~tPA video clip will be sent only to those IMs that would store such a file. The data tsnsfer inf l~ld~oc all of the i,lf~). l .,,t;~ n listed above, plus the TnternPt address of the source IM 90. The data can be sent by either mnlti~ ~ctin~ tec~hl~ ues or by prop~g~tisn~ wl-.,~l,~ each IM relays the mPcc~ge to aU
of its ne;~llbol-ug ~s, except the one from which the me~Cc~e was received. The mlllfir~cting method is ~,Gfe~l~d, as it results in less lltili7~tion of netwo,h bandwidth.
The prop~tinn mPthnrl, though robust, can result in a slow l~*JOnSf time for data updates if many IMs require the new data.
Each IM has a content ~l~t~hace of which cdte~o~ies of content are to be made available to the sl~bsc~ ;l-tl~ in its region, rPflPrting sel~tionC made by the TntPrnpt service provider hosting the IM. The content ~alegc,lies are l~,~,.,sented in the form of content c~ lf~ n cooldilldl~s, as f~ic~ ed above. Only those clips in the Sf~ CtP~i ~te~olies are stored on the SRUs belonging to the ~I. When an IM, such as the PIM 64, receives a mPCc~e about the availability of the new or changed clip, it checks the content f1~t~b~ce to flt-lf - ---inr whelller it should acquire the file. If PCT~US96/10403 so, the IM will send a message to the orig;~ IM 90 in~ir~tin~ that it will store the clip.
All~...,~lively, content can be .licl.;h,.l~ without first sending a message *....;..;.-g which IMs will store the clip. To do so, the ori~ p, IM will access its IM d~t~bilce to del~....;..P- which IMs have content cool.lu.ales that would include the new or updated clip. The list of rMs satisfying that query can then be used for distribution of contPnt To disLl~ule the clip to all requçctin~ IMs, the o.;~ IM 90 utilizes its storage m~n~g~mP,nt logic to handle sending the clip. The u. ;~ i..g 90 first reserves a m~ ir~ct TntPrnpt address as decign~t~od in the Tntprnpt mnltir~ct standard. The IM 90 then sends a message to each req~esting ~, re~llesting that they all join the ml-ltir~ct group. When the clip is then sent by the DSI 102 to the reserved multi~ct Tnt~mrt address, each rM will receive the file and d;~c~n~;n,.~ it to its SRUs according to its own criteria.
Acconliligly, each IM (such as P~ 64) then locates the least loaded eYt~nt~ SRU to be used for storing the clip (by the means previously ~ c~cs~i) and then again invokes its storage m~n~m~nt logic to copy the clip to one of its Gx~ n~
SRUs 66. The PIM 64 also checks to dele ...;ne if it already has an older version Of the clip. If sO, the storage m~n~g~m~,nt logic will delete the old version before Cu~yihlg the new version to an PYt~nded SRU 66. If the clip has several portions or se~ (e.g. in dirr.,..,.~ n~-~ges or having reginn~lly specific i..r~ ), only those ~lulLiOns in-iir~te~l as relevant by the IM's content ~t~h~ce need be stored. For example, if a p?rtir~ r ISP has no Spanish-spe~king users, then Spanish l~n~-~geversions of clips need not be stored locally.
The content provider can also instruct the system to remove all copies of a .~ PA clip. To do so, a meCc~ge embodying the in~LIu~;lioll can be sent to thecontent provider's ~ 90. The meCs~ge will then be p.~,~agaled throughout the ~ system, as in~1ir~t~P~I above for new and çll~nE~ clips. When each IM receives the instruction to remove a particular clip, it will query its clip ~i~t~hace to tlPtprrninp if any of its t;xle .~P~ SRUs are storing the clip. If so, the IM's storage ..-An~",..-f~nt logic will be invoked to delete all copies of the clip from the ~-u~-iale SRUs.
Each IM, inr1nciinE the PIM 64, also pelrulll,s its own .~ lpn~nne on the clip ~ b~ and the data stored on its f,~ PA SRUs 66. pf!rinflir~lly, the P~

PCTrUS96/10403 64 can check to dcilç..~ e if any of the clips in the clip rl~t~h~ç have expired, or if any of the clips have not been ~ncec~çc1 within a specifi~cl time period (e.g. one hour, one day, one week, or one month). If either is the case, the PIM 64 can invoke its storage m~n~gemPnt logic to delete the clips from the a~lu~,iale SRUs 66.

C. D~ ic Load ~ g....~
To ol)Lu~ e ~.rol"-a-lce, the system of the present invention hlcol~ulales several means of reducing co..~""~nit~tion~ bottlentorl~s (1) preloa~iing and distribution of files based on predicted usage; (2) dynamic load b~l~nning; (3) aulu~l-a~ic file repl~rem~nt The means ~ cu~Pd below are in the nature of on-demand p~llPli~m, or enrul~ g the use of multiple co"~"~"ir~tinn paths to reducebottl~nP~. However, it should be noted that other load management techniques areused by the invention, for example the pliolili~ed list of .o~t~n-iPA SRUs 26 created by the PrM 64, as ~I,c~ P~ above.

(1) Pr~ln~ling and Distribution The PIM 64 perio~ lly (e.g. hourly) collects and saves in its ~l~t~h~
the frequency with which each file on its ~ n~d SRUs 66 is l~ue~l~i as a fimction of day of week and time of day. The frequency of file access in each of llUlllt;lUUS
pre-defined c~Llegc,..cs (e.g. sports, automobiles, music, etc.) is t~hul~f~l and saved, as is the r~u~ ;y of access of each individual file, and the user's cc~ n,~ l;nn link speed used for each previous download. The above ..~rO,...~ is used to predict future usage.
In a ~,1fc,-~ embodiment of the present invention, three ~cgv. ;f 5 of prior usage are utilized to predict the number of times each given clip will be downlc~deA First, data based on the historical dçm~n-l of clips in the clip's subject matter U~lcguly, over the same hour and same day from previous weeks, is linearly extrapolated to predict that ~;alug~Jly'S demand at the present day and time. This first factor, by way of ç~mple, Cûllllil)ul~s a f ~cti~n of the final wçightin~ ideally 20-40%. Secon~l, data based on the particular clip (or its ~,G.lece~~o~) over the collG~onding hour on previous days is linearly extrapolated to predict that clip's demand at the present day and time. This second factor collllibules 20-30 % to the final wçi~htin~. Third, data based on the p~rti~ r clip (or its ~l~e~o,~) over the PCT~US96/10403 period directly ~ e l;.~ the prçsent hour is linearly extrapolated to predict the clip's dem~n-l This third factor contributes the ~ li"g fr~rfir,n, 30-60%, to the final wei~hting.
~ These three factors are combined to ectim~t-e load, i.e. how many times each clip will be downlr,a~PA in the ~collling period. At the end of each period, u,ujecled load can be com~d to actual load, and techniquçs known in the art (such as neural networks) can be applied to improve the wçightingc for future periods.Based on the pluiecliolls ~iccllcs-pA above, the PlM 64 e,l;",~lf,s the SRU
66 bandwidth ~~uL~ to ~rcommo~t~ the ~l~icled downloads. This e~;",~le can be made, for example, by multiplying the size of each file by the number of ~
downloads in the period. If the pluje~;led l~uir~d bandwidth is less than a threshold (e.g. 10-50%) of the capacity of a single SRU 66, then no load b~l~nring need beundertaken. However, if the ~ led required bandwidth is higher, then the files must be distributed over a sufflcipnt number of e~t~nrlP~l SRUs 66 until none exceeds the threshold. This is accomplished by evenly ~ ;..g the highest projected usage file over the number of SRUs snfficient to accommodate the llu~lber of p,uje~;led ciml-lt~n~qons downloads for the file at the users' plu;e~ d download speeds. The distribution is ~e ru,l-led by the storage m~n~gPmPnt logic invoked by the PlM 64 ciring to rlictrihutr fles.
Where there are more copies of files than are predicted to be needed, the PIM 64 will use the storage m~n~gement logic to delete the excess files from those SRUs 66 with the highest pl~i~ d loads (based on clips other than the one being deleted).

(2) Dy~lalllic Load R~l~nring Dynamic load b~l~nring of the e~rtenr1pA SRUs 66 is pe,ro"l,ed to n.;n;.n;,P the chances of any p~rtir~ r SRU 66 becoming a bottlPnprl~ and tû
",zix;"~;~e bandwidth lltili7~tion during periods of peak load. Load b~l~nring in acco,clallce with the Tnf~rnPt embodiment of the present invention is carried out generally as set forth above for the invention as a whole, and in specific; ~ n~ es as dcsclibed below.

PCT~US96/10403 The PIM 64 ~ A;I-c current ~ro~ ce ulÇ... ~ about each of its .o~t~n~ SRUs 66. This i,~o~ alivn is ob~u,ed from ~ ion~ of when the DSI
58 initiates and conrl~ s the t-~sÇe~ of a file from an SRU 66, as .l;c. .l~ced above.
If any SRU has a load ~ uacl~lg a threshold limit (e.g. 80%) of its theoretical capacity, the PIM 64 checks whether this is due to a few clips receiving a dis~-upo-Lionately large portion (e.g. greater than 10%) of download request~ If so, the PIM 64 invokes its storage mAnAg~m.ont logic to transfer the files to another, e.g.
the least-loaded SRU 66.
If the eA~e ;~d or current demand for a particular file or smaU group of files exceeds a threshold capacity (e.g. 30-50%) of a~l of the G~ lried SRUs 66 within a region, the PIM will attempt to move these clips into a RAM (random access memory) buffer 106 ~c~ces~ihle by the DSI 58. The use of the RAM buffer 106 willreduce the 4u~ y of disk acce~stos ~~u--~d to retrieve the highest demand clips. The de]ivery capacity of the SRUs 66 IllA;l~lA;l~ by the PIM 64 will then be nr~At~-A to reflect their ul~;-Gased c~acily.
If all of the ~t~n~l~d SRUs 66 within a region are unable to meet the demand of the current number of users, then the system can make use of remote SRUs mging to neighboring IMs, such as IM 88, as follows. After the DSI 58 has ~.llAIl~l~d its A~ to acquire data from the local SRUs, as gen~lly descrihedabove, the DSI 58 will re-query the PIM 64 to obtain a second list of viable SRUs.
As diccus~e~d above, the PIM 64 will query the a~ ;ale remote ~s to receive such ulru~ aLiol~.
Re~ e of the invention's dynamic load bAl~n~ing, should an e~t~ntied SRU 66, remote SRU 92 or 100, or remote IM 88 or 90 fail, ~lt~rnAtt~ servers andcolllllllll~ tinn paths are a~ lllAI;r~lly available to service the user. Data is Il"-illlAi~ A reAIln~1Antly on multiple physical servers. Each region, int~lnfling its IM
and e~tPn~i~d SRUs, is a self-culll~ 1 system for mAnAging and ~ ll;ng video clips; there is no cPnt~li7PA data m~nAgPmP!nt fun~tion C~ ncP~uP,ntly, a failure in one region does not catasllu~hically impact any other region.
I~.nlll --lll. le, as the number of end users to whom the ISP sells the lliUIII service in- lGases, and as the number of available video clips increases, the iul~,~,.lLioll offers l,ol~ ia]ly llnlimitPA growth c~acily. The number of physical eYt~-n~1P,d SRUs 66, as well as the disk capacity of each ~t~n~led SRU 66, can be -PCTrUS96/10403 increased in order to store more data. Additional IMs can be added to service Ad~litionAl gw~ l~ical regions or to subdivide overk~rip~d e~Lulg regions. To increase the number of parallel data Ll~ , more than one DSI 58 can coexist on shared physical servers or on S~A. ~I~ servers within a region.

(3) ~l~toln~ti~ File ReplAcemPnt The aulGInaliC file replAcemPnt aUl;l,uL~s of the invention are ~liccllcced above in the section on uploading and distributing new cont~nt D. Clip ~;~G~ ;U-~
One embodiment of the present invention can accommodAtP video clip segm~ntAtinn In other words, a clip can be made up of two or more segmPntc Aftersel~cting a segmPntP~ clip, the requesting user can be ~l~selllt;d with an index of se~...P~.Ic within the clip, and choose to download one, several, or aIl of the segmPntc To ~rcomrlich this, the content provider first edits the video clip using the surLw~ tool de~ ~ above, so that specific frames of the clip are identifiP~i by col-ce~;uli~re index mlmherc ~Se~mPnt data is AttAt~hPJl to the clip and stored within the file. The se~ data in~ ldes, for each index number, a textual name or ~iescrirtinn of the inrlPYP~ frame and the starting and ending byte counts of the in~lPYP~ segrn~nt In a ~lGrt;lled emho~limP-nt the user stream of an MPEG file is used to include the seg---~--l data; in this way, MPEG file cul..pdlibility is I~A;.-lA;.l~ for use by other players.
Spe~ifiL~lly, s~...~ data will be incll-de~ within an MPEG file as follows. An MPEG file may possess a number of video streams, a number of audio str~AmC~ a single MPEG format stream, and a single user stream. The streams are all tied lugt;Lll~ with pAr~mPters linking events for use at the same "~lc;,~..lA~;~?n time."
AccGl~lingly, sP.~ data of the invention can be merged into the user stream and tagged to occur at a specific ~l~se-.lAIinn time corresponding to a desired video or audio event. This chAr-A~tPrictic is useful for syncl~.u-.;,Alinn ~ul~oses.
" the user stream can include multiple sub-streams. A
~ f~ d e.-lbodi~ n~ of the present ~lVGIllioll will have at least two user sub-streams:
a s~ sub-stream and a ~ Le~;Lioll sub-stream. The seg.nf-~l sub-stream will contain the index .--~ and coi.~ondi.~g data ~licc~sceA above, as well as a table PCT~US96/10403 of co..~ to the s~...~ . The l.,ol~lion sub-strearn will contain the p~~ ;nl~ and w~lr.~ lk;..g data ~ c~cP~ above. By the use of ml-ltirl~ specially-defined sub-streams within the user stream of an MPEG fle, M[PEG viewers other than the l~lowser 82 or bl~JWSCl ~xt~n~ion 84 of the invention can be used to view w~ t~;lcd video clips downlo~ d by the present invention. Such viewers will simply ignore the additional i..Ç. . .~1 ;r n Un~egm~nted clips are generally stored on an SRU 66 as a conti~lou~
file on a hard disk belonging to an SRU 66. Seg- -P .I-ici clips, however, are stored as 5~1J~ ly ~ccç~ihle records. The PIM 64 then tracks, in its clip ~l~t~ e~ which se~m~nt~ are stored on which SRUs 66. The se~ data also remains within the MPEG file as ~i~c~sed above.
When the user requests to view a segm~ntçd clip, the clip is i~-nfifi~d by video ID and located by the PIM 64 as previously ~iiu'u~çd for u~ g....=-.l~ clips.
However, before the video data is downln~-~e~l, the clip segm~nt data is downlo~e~l to the user t~rmin~l 50 for display by the bl~wacr ç~t~n~ion 84. The user can then select the specific sPgm~ontc he wishes to download. The seg..~l ..t nnmhlo~ of the i-iPntifi~
seg,--~nls are then l~oll~d by the l~r~wael eYI~ ~c;~ n 84 to the DSI 58, which then downloads only the requçstçd se~ c from the ~ iate local SRUs 66 to the tt~-nnin~l 50 via the local SRU 51. If the s~ ; are stored on se~ SRUs 66, the DSI 58 can be loading segm~nt~ coll~;ullc-llly from the se~ t~ SRUs 66 in cp~l~.lio~ for download to the user te~nin~l 50.
There are other uses for the se~... .l data, as well. The content provider can tie additional i lro..--alion to frarnes or segmPntc of a clip. This ,-m~lion can be stored in an additinn~l control sub-stream (part of the MPEG user stream ~ viuusly c~iccu~P~). For e~ .pl~, the SÇ~ data can include ad~1itil~n~
video IDs or URLs ide..~iryillg other clips or HI~L files. When the clip is downl~ ed and played by the user's bluwacl e~ .cic)~ 84, the bluwae~ extPnsion 84 can then display the associated video ID, URL, or text ~IPSC~ ;h;.~ the link. The user can select one or more of these links, thereby directing the bl~wser 82 and/or bl~v~à~
eYt~n~ion 84 to acquire the ~Ccori~t~i infull..aLion by way of the present invention or by traditional means over the TntP~rnpt 56.
The seg~mp~nt data can also contain çmhe~lder~ instructions for the bh~wael extPncion 84. Such s~ .c l data can be in~ ed in an ~ l objçct sub-_ _ PCT~US96/10403 stream made part of the MPEG user stream, as dicc~ssed above. For eY~mrl-o~ by inr~ inE pl~l~;,.rcl codes ~ccoci~t~d with particular frames or 5~.nP~ of the clip, the l)low~e. ~f.,c;"n 84 can be instructed to add graphical objects, text, or other ~ controls to the display. Ad~iition~l cu.nl.u~ fim-~ti~n~lity can be added in the form of embedding tPrmin~l-inriPrPn~çnt cù~n~ulel pl~u~ S, such as those written in the Java ~u~ g l~ngu~ge, into the se~...- .l d~t~b~ce. As the clip is received by the b~UWSG~ çl~tPnci~n 84, the ~JlUgl~LIII code is also received and i..~ tGd, and can be passed to the blùw~eL ~2. At a~lul.riate times, the bluw~e~ e~ n 84 can then interact with the bl~wser 82 to cause the a~rupl;aLe actions to be taken.
The seL~ can each have their own ~ ule5~ such as content rating and l~n~e. Such a~Ll;~ h,s can be stored in the segm~m sub-strearn of an MPEG
file, as ~liccl~ccP,d above. ~ttr~bute i~l...alion can be used by the PIM 64 on a per-segm~nt basis to df~lf~ ;n~- which ~e~..-P--I~ are available to a particular user. Only those segm~nts available will be shown on the bluwser ~ten~ n 84 as downloadableThe PIM 64 will instruct the P~ 18 to download only those seg... -.l~ r~ by the ;..rO....~ in the user ~1~t~b~ce. Those seE;...~ ; not having ~ v~.l data are ignored. Thus, the clip file stored on the e~l...~rleA SRUs 66 is dyl.~ ly decomposed to el;---;n, l~ UUdG~ilGd content and lGeorlsllu~:tGd to provide the desired video clip to the user.
Note that the segm~nteA files can be stored as Se~ on the content provider's Web server 83, as well. When the present system is not available (e.g., the user has incllffi~ nt ~ ksc-;l-Lion rights or a particular clip has not been stored on any SRUs), a Web page can be used to list the individual segm~ontc~ with the segm~nt.c selectable as sep~ clips in a t~.~rlitinn~l manner over the Tnt~mPt 56.

E. Sl-bs..:~ Control and ~
As ~icrllcSe I above, the present invention can be a plc.lliu~ll service for subs~riher~ ~ollc~lu~ y, the following .,~bSc~ n m~n~om~nt capabilities are in~ d~l when needed.
To receive access to the present invention, the end user must ~bsc- ;I,e to the pl~ IIl service. The subscription may be free. The ISP provides the user with a sign-up ~ glanl (which may be impl~m~nfeA as a Web page on the ISP's Web server 68 having forms to receive data input). The user is queried as to price limits PCT~US96/10403 for monthly çh~rgps~ and provides billing i~ol,.,a~ion (such as a credit card llull~b~.).
User configuration data is collected, such as the desired playback quality and resolution of video clips. The user also estAhlichPs acceptable content restriçtio~s for use in the ratings system ~ cced below. E'.y using the sign-up plUgl~Ull or Acc~ the sign-up Web page in the future, the user has access to the confi~lrAtion data to alter it as desired.
For content that is available on a subs~ lion basis, the invention limits access to those users who are dei;g..~l~A as ..~bs~ e~.~ to the contP-nt Users may directly ,.~ s~ e to particular cQIltPnt, or ISPs may s~.l,s~ . ;l.e for their end users. In either case, the PIM 64 ",~ c in its user A ~t~h~e a listing of all those ~ o~ ;~eA
sllbsclil)el.. who are co~ e~;led to the PIM 64, limiting downl~ding of clips through the invention to those who are ~ o~ ;~. within that region.
Each video clip can also be Al~no!A~A with a date or elapsed time after which it will expire; such infnrrn .tir,n will be stored in the clip r ~t~ ce belonging to the PIM 64. The PIM 64 will then disallow t~,.nc...icc;c.n of an expired file to any user's bluw~cr e~ ;ol- 84, and can optionaUy disallow replaying (i.e. decline a request to un-prctect) a clip stored locally at the user~s t~rtnin~l ~o.
Certain clips can be made available on a "pay per view" basis. In such a case, each download (or, optionally, each viewing) will be tracked by the PIM 64;
the user's account accrues an incl~ Al charge on the basis of the download or viewing. The bl~J~. sc~ rt~ncion 84 can alert the user to the l.,lue~ charge in order to get ~ I;U~ for the clip's download.
A ~ _n;.~lll is built into the invention to avoid abuse of the "pay per view" billing system. With a pay per view system, there is a ~uh~ for a user to over-use the system, accl.~i"g an unreasonably high level of ch~rges. Consequently, the user or another person can pre-plu~ the blu~er e~t~ncinn 84 to enforce a cost limit; this cost limit would be password ,ulvl~led. Prior to downl~-~Ain~ a file, the PIM 64 co...~ 5 the total l~ul~lial cost to the brv~ser ~tenCion 84. If the total charge exceeds the player's limit, then the download is disallowed, or the user is asked to conf~m the t~nC~l~fi()n by ent~rinE the password.
An Alt~rn~te form of billing can be made in the form of ~.~I.s~ tion fees. The content provider can require that a periodic ~-lb~ ion fee be paid for a user to receive access to a s~o1ecteA group of video clips. Such ~.lI,sclibed access can then be nnlimitP~I or limited as the content provider or ISP desires. This billing scheme can be used in conjunction with the "pay per view" scheme disclosed above;
some clips might be free with an a~-u~liate s--'os~ ion, while others are still available only through pay per view. If certain downlo7l~1ed clips had to be Icl~ cd from remote regions 89 or 91, then a "long ~lict~nre" charge can be ~c5Pcc~l TheP~ 64 can track the accrual of periodic subscription fees and apply the charges to the accounts of the users in its region 81.
As ~ g~P~Ied above, a ~.u705~ nn can be limited to certain subject areas of interest. The user can use the bluw.e~ eYt~ncion 84 and b~uw..e~ 82 to search the Web for topics of i -l~,..L; such search c~p~bilitirs are lmown in the art. When a collPctinn of desired clips has been ~ ll;l.~, the user can use the bluw~.el e~tPncion 84 to submit a ~lu~osed group of clip ,~ue..l.. to the PIM 64. The PIM 64 can then respond with ;llrvllll~;nn on ~l~osed s~lbscrirtion terns and fees to ~~colnmo-l~tP the query results. The user can accept or reject such terms, and upon ~ccp~ re~ the user's ~ccount will be ~lpd~tyi accGld~ ly.
The present system also arcQmmod~tP-s various ratings for use in, for exarnple, p~lrnt~l control. When content is created or uplc ~çd to the content provider's Web server 83 and its IM 90, the content provider can assign a rating level, which will be stored in the Clip ~i~t~b~ce of the lM 90 (and the PIM 64), as well as optionally in the Web page col~l~i..;.lg the clip. The player can be pre-l,lu~l,llllll.P~ by the user or another person to disallow downl~ iing video clips having ratings higher than a sl)e~ll;~ limit; the rating control plug.,lll..ll;.l~ can be pl~l~Led by ~as~.~ol-l.
Each clip can be rated, for exarnple, by a tWO-~ -al rating matrix concicting of a ch~r~rterictir and s~ y. In one eml)o.l;..lf.ll, the ch~ l;rs would be nudity, pvul~P~,Il)~y~ l~n~gP, and violPnre; levels of s~v~lily can be, for example, from one to five.
Under the rating control ..I~ h~ lll, when a video clip is re~lested by the user, the P~I 64 is provided the rating il.ro.lll~ m either from the Web page (as part of the tag çmhe~1ing the video ID) or from the clip d~t~h~ce on the PIM 64, after the PIM 64 has i~lPnfifi~ the clip. The user's rating control limit is sent to the PIM
64 as part of the vir~ual URL constructed from the video ID. The PIM 64 carl then allow or deny the download based on that h~ro..ll~

PCT~US96/10403 ~mple 8 - Alternative ~mbodiments In view of the above expl~n~tinn of the exemplary system, it will be ~lcciated that embodiments of the present invention may be em~lu~d in many dir~l~.ll appli~tionc to deliver large qU~ntitif~s of time-critical data across a n~ twulL
Specifi~lly, it should be noted that the foregoing ~iic~ snre is not limited to video clips, with or without audio, and would also pc.~llll well for audio-only clips, and cu.ll~uler data, arnong other data types. Similarly, the Ç~ n~l clf...P..I~ ~lic~ 5f~A
herein are not limited ~Llu~;Luldlly to the confi~-r~tion shown; it is CO~t~ .lated that the Pl~nnf ntC, such as the P~M 64 and the DSI 58, among others, can share hal~dw~G
on a single server, if such is df~cir~lf. or ne~eCc~y in a particular ell-bodi ~Alternatively, a functional elf mf nt may be split over several pieces of hal.lw~c to improve perfoll..ance, as is known in the art. Also, note that while only three regions are depicted and ~licciosed in Figure 4, the present invention is scalable, with many regions cu~ euled by the Tntf~rnf t 56 (or any other nclwc,.h) and high-speed lines (like line 96); each region is l~ewise e~l~e~ cl to have a large number of users conn~Led to its lc~eu~ e head-end nc;Lwu-h intf ~re 54.
While certain e~f ~ y ~Ilu(ilu~s and O~f~ S have been ~lesr- ;l.~l herein, the a~lù~l.ale scope hereof is deemed to be in accordance with the claims as set forth below.

Claims (130)

What is claimed is:

1. A video clip storage and retrieval system comprising:
a multimedia terminal through which a user may request video clips from a database, the multimedia terminal also being able to receive and display requested video clips;
a local storage and retrieval module which communicates with the multimedia terminal and which is adapted to receive and process video clip requests from the multimedia terminal;
a primary index manager which communicates with the local storage and retrieval module and which is adapted to receive and process video clip requests from the local storage and retrieval module;
an extended storage and retrieval module which communicates with the primary index manager, and which stores a plurality of databases including a database containing video clips;
a data sequencing interface controlled by the primary index manager and adapted to direct the extended storage and retrieval module to download the requested video clips; and means for downloading the requested video clips to the multimedia terminal via the local storage and retrieval module.

2. The video clip storage and retrieval system as in claim 1 further comprising a plurality of multimedia terminals to accommodate a plurality of users.

3. The video clip storage and retrieval system as in claim 1 wherein a plurality of extended storage and retrieval modules are connected to the primary index manager.

4. The video clip storage and retrieval system as in claim 1 wherein the primary index manager is further connected to a plurality of remote index managers.

5. The video clip storage and retrieval system as in claim 4 wherein the primary index manager and each remote index manager maintains a list of every video clip stored at the storage and retrieval units.

6. The video clip storage and retrieval system as in claim 4 further comprising means for the local storage and retrieval module to attach a regionalidentifier to each requested video clip before the request is transmitted to the primary index manager.

7. The video clip storage and retrieval system as in claim 5 wherein the primary index manager uses the regional identifier to identity remote index managers containing the requested video clips.

8. The video clip storage and retrieval system as in claim 5 further comprising:
means for searching the local storage and retrieval module to determine whether the requested video clips are stored therein; and means for modifying the user request to indicate whether the requested video clips are so stored.

9. The video clip storage and retrieval system as in claim 1 wherein the videos are stored in compressed form and the multimedia terminal includes decompression means to allow the user to view the video clip at the multimedia terminal.

10. The video clip storage and retrieval system as in claim 1 wherein the local search and retrieval module contains decompression means for downloading the requested video clips to the user terminals.

11. The video clip storage and retrieval system described in claim 3 wherein the data sequencing interface contains means for sequencing information received from the plurality of extended storage and retrieval module.

12. A video clip storage and retrieval system according to claim 1, wherein the user may request clips from a database at least one of real estate, pharmaceutical, retail sales, travel, and personnel information.

13. The video clip storage and retrieval system as in claim 12 wherein the database contains real estate information and the regional identifier is one of a ZIP code, cartesian coordinate, and GPS coordinate.

14. A method for storing and retrieving an audio-visual clip from a database comprising the steps of:
searching through the database to select audio-visual clips for viewing and formulating a request for the selected audio-visual clips;
transmitting the request for audio-visual clips from a user's multimedia terminal to a local search and retrieval module;
searching the local search and retrieval module to determine.
whether the requested audio-visual clips are stored therein;
modifying the request within the local search and retrieval module to indicate whether the requested audio-visual clips are stored therein, and by appending a regional identifier to each requested audio-visual clip;
transmitting the modified request to a primary index manager;
using the primary index manager to determine the exact storage location of each audio-visual clip within one or more extended search and retrieval modules;
creating and maintaining a data sequencing interface to direct the extended search and retrieval modules to download the requested audio-visual clips to the data sequencing interface;
downloading the audio-visual clips to the user's multimedia terminal via the local search and retrieval module; and decompressing the audio-visual clips from its compressed state for viewing at the user's multimedia terminal.

15. A distributed video clip storage and retrieval system comprising:
a plurality of video storage media at different geographic locations;
a plurality of digitized video clips, each of which is stored in one or more copies by the storage media at one or more locations;
a user interface comprising a video display terminal for requesting and viewing desired video clips;
a search engine for locating video clips requested via the user interface and residing on the video storage media;
at least one user-specific buffer for retrieving and forwarding one or more located video clips to the user interface;
a first communications channel linking user interface and the search engine;
a second communications channel linking the search engine and the storage media;
a third communications channel linking the storage media and the user-specific buffer;
a fourth communications channel, linking the user-specific buffer and the user interface; and a storage engine for distributing the video clips on the storage media at one or more locations, on a supply and demand basis.

16. A distributed video clip storage and retrieval system according to claim 15, wherein the first, second and fourth communications channels are each one of very high speed and high speed, and the third communications channel is very high speed.

17. A distributed video clip storage and retrieval system according to claim 16, wherein each very high speed channel uses a protocol selected from thegroup consisting of FDDI and ATM and each high speed channel uses an ISDN
protocol.

18. A distributed video clip storage and retrieval system according to claim 16 wherein each very high speed channel has a minimum bandwidth of at least about 100 mbaud, and each high speed channel has a minimum bandwidth of at leastabout 56 kbaud.

19. A distributed video clip storage and retrieval system according to claim 15, wherein each video clip and each storage media is uniquely identified, and each storage media comprises a file server having a digital memory and a database of the video clips stored in and retrieved from its digital memory.

20. A distributed video clip storage and retrieval system according to claim 19, wherein each file server has one or more memory devices, each of which is independently selected from the group consisting of high capacity hard drives, high speed optical drives, RAID devices, and WORM drives.

21. A distributed video clip storage and retrieval system according to claim 15, wherein each video clip is stored in a compressed format, and is decompressed for display.

22. A distributed video clip storage and retrieval system according to claim 21, wherein video decompression occurs at one of the user-specific buffer and the user interface.

23. A distributed video clip storage and retrieval system according to claim 21, wherein the compression format is one of MPEG I, MPEG II, MJPEG, Indio and Fractal.

24. A distributed video clip storage and retrieval system according to claim 15 wherein the user interface resides on a personal computer and includes a search interface and an audio-visual display interface.

25. A distributed video clip storage and retrieval system according to claim 24, wherein the user interface provides for further processing and manipulation of retrieved video clips.

26. A distributed video clip storage and retrieval system according to claim 15 wherein the user-specific buffer delivers video clips to a local storage media for storing retrieved video clips.

27. A distributed video clip storage and retrieval system according to claim 26, wherein the most frequently requested video clips are stored in the local storage media.

28. A distributed video clip storage and retrieval system according to claim 15, wherein the user interface and user-specific buffer independently reside on one of a file server and personal computer associated with one of the plurality of storage media.

29. A distributed video clip storage and retrieval system according to claim 15, wherein the search engine accesses one or more databases having information describing video clips stored on the system and their storage locations.

30. A distributed video clip storage and retrieval system according to claim 29, wherein at least one of the databases resides on one of the plurality of storage media.

31. A distributed video clip storage and retrieval system according to claim 30, wherein another of the databases resides on an independent on-line service.

32. A distributed video clip storage and retrieval system according to claim 15, wherein the user interface includes local search and update logic, forretrieving the most current information.

33. A distributed video clip storage and retrieval system according to claim 15, additionally comprising a unique system address and a communications gateway to one or more remote video clip storage and retrieval systems according to claim 15.

34. A distributed video clip storage and retrieval system according to claim 15, wherein the search engine comprises a communications interface, distributed user-specific buffer logic, database management logic, storage management logic, and message routing logic.

35. A distributed video clip storage and retrieval system according to claim 34, wherein the user-specific buffer logic determines the local availability of requested video clips, the database management logic determines the system-wide availability of requested video clips, the storage management logic determines the location and distribution of video clips stored on the system, and the message routing logic determines the communications channels for movement of queries and video clips throughout the system.

36. A distributed video clip storage and retrieval system according to claim 15, wherein each video clip is stored in contiguous blocks of memory.

37. A data sequencing interface for collecting, managing and buffering audio-visual data which is transmitted to the data sequencing interface from extended and remote storage locations for downloading to a user, comprising:
a first communications interface between an index manager and the data sequencing interface for communicating the exact location of audio-visual segments stored at one or more of the extended and remote storage locations, a second communications interface between the extended and remote storage locations and the data sequencing interface for transmitting the downloaded audio-visual segments to transmit buffers of the data sequencing interface;
audio-visual sequencing logic for sequentially requesting each audio-visual segment from each extended and remote storage location identified as containing the audio-visual segment until the audio-visual segment is retrieved;storage management logic for managing the location of each retrieved audio-visual segments; and a third communications interface between the data sequencing interface and the user over which the retrieved audio-visual segments is transmitted for the eventual download to the user.

38. The data sequencing interface as in claim 37 wherein:
the first and second communications interface are very high speed; and the third communications interface is a high speed.

39. The data sequencing interface as in claim 38 wherein each very high speed interface has a minimum bandwidth of at least about 100 MBaud, and each high speed interface has a minimum bandwidth of at least about 56 Kbaud.

40. The data sequencing interface as in claim 37 wherein the storage management logic comprises:
means for determining whether an audio-visual segment is retrieved from either one of the remote storage location or from the extended storage location;
means for comparing the number of times an audio-visual segment is retrieved from a remote storage location with the number of times the least requested audio-visual segment is retrieved from the extended storage location;
means for copying, from the remote storage location to the extended storage location, an audio-visual segment which is retrieved more often from the remote storage location than from the extended storage location; and means for removing the least requested audio-visual segment from the extended storage location and placing the least requested audio-visual segment onto one of the remote storage locations.

41. The data sequencing interface as in claim 37 wherein the audio-visual sequencing logic comprises:
means for determining whether an audio-visual segment requested from either the extended or remote storage location cannot be retrieved because of other requests for audio-visual data from that extended or remote storage location;
means for requesting the audio-visual segment from another extended or remote storage location;
means for communicating which storage location provided the audio-visual segment to the index manager.

42. A distributed video clip delivery system comprising:
a multimedia terminal through which a user may request video clips from a clip database, wherein said multimedia terminal is connected to a network and is able to receive and display requested video clips via said network;
a plurality of extended storage and retrieval units connected to said network, each storing a plurality of video clips;
a primary index manager which communicates with the multimedia terminal via said network and which is adapted to receive and processvideo clip requests from said multimedia terminal; and a data sequencing interface controlled by said primary index manager and adapted to direct said extended storage and retrieval units to download said requested video clips to said multimedia terminal.

43. The distributed video clip delivery system of claim 42, wherein said network is the Internet.

44. The distributed video clip delivery system of claim 42 further comprising a plurality of multimedia terminals to accommodate a plurality of users.

45. The distributed video clip delivery system of claim 44 further comprising a plurality of primary index managers to accommodate a plurality of users.

46. The distributed video clip delivery system of claim 45, wherein each of said multimedia terminals is associated with a single primary index manager.

47. The distributed video clip delivery system of claim 46, wherein a plurality of said multimedia terminals is associated with each of said primary index managers.

48. The distributed video clip delivery system of claim 42, wherein said multimedia terminal is connected to said network via a head-end interface.

49. The distributed video clip delivery system of claim 48, wherein said data sequencing interface is connected directly to said head-end interface.

50. The distributed video clip delivery system of claim 49, wherein each of said extended storage and retrieval units is connected to said data sequencing interface.

51. The distributed video clip delivery system of claim 50, further comprising a plurality of remote storage and retrieval units, each storing a plurality of video clips, connected to said network.

52. The distributed video clip delivery system of claim 42, wherein said primary index manager maintains a user database containing information on all authorized users.

53. The distributed video clip delivery system of claim 42, further comprising a browser program running on said multimedia terminal.

54. The distributed video clip delivery system of claim 53, further comprising a browser extension program running on said multimedia terminal, capable of interacting with said browser program.

55. The distributed video clip delivery system of claim 42, wherein said multimedia terminal further comprises a storage buffer for temporary storage of downloaded clips.

56. The distributed video clip delivery system of claim 42, wherein said data sequencing interface includes a RAM buffer adapted for the temporary storage of clips queued for downloading.

57. A method for distributing a video clip over a network to a user having a multimedia terminal, comprising the steps of:
browsing a netword;

identifying a video clip of interest;
searching a user database to retrieve user information corresponding to said user;
searching a clip database to retrieve clip information corresponding to said video clip interest;
matching the user information to the clip information to determine if the user is authorized to receive said clip;
analyzing the clip information to determine where the clip is stored;
directing a data sequencing interface to download the clip from its storage location; and downloading the clip to the user.

58. The method of claim 57, further comprising the step of viewing the clip on a multimedia terminal.

59. The method of claim 58, further comprising the step of storing the clip on a local storage and retrieval unit.

60. The method of claim 58, further comprising the step of updating the user database to reflect additional charges incurred by the user for the download.

61. The method of claim 58, further comprising the step of protecting the clip prior to downloading the clip.

62. The method of claim 61, further comprising the step of unprotecting the clip prior to viewing the clip.

63. The method of claim 62, further comprising the step of decompressing the clip prior to viewing the clip.

64. The method of claim 57, further comprising the step of determining whether the clip is stored at a local storage and retrieval unit before directing a data sequencing interface to download the clip.

65. The method of claim 64, wherein said clip is not downloaded if it is already stored at the local storage and retrieval unit.

66. The method of claim 65, wherein said clip is replayed on the multimedia terminal.

67. The method of claim 64, wherein said clip is replayed only if authorization is received from a primary index manager.

68. The method of claim 67, wherein said authorization is based on information in the user database and information in the clip database.

69. The method of claim 57, wherein said user database is maintained by a primary index manager.

70. The method of claim 69, wherein said clip database is maintained by said primary index manager.

71. The method of claim 70, wherein said searching, matching, analyzing, and directing steps are performed by said primary index manager.

72. The method of claim 57, wherein said downloading step is performed by a data sequencing interface.

73. The method of claim 71, wherein said identifying step is performed by the user directing the browser to send a request message to said primary index manager.

74. The method of claim 73, wherein said request message comprises portions identifying the user and the requested video clip.

75. The method of claim 74, wherein said request message is in the form of a text string specifying the Internet address of the primary index manger, identifying the user, and uniquely specifying the identity of the requested video clip.

76. The method of claim 71, further comprising the step of determining whether the clip is stored on an extended storage and retrieval unit prior to directing a data sequencing interface to download the clip.

77. The method of claim 76, further comprising the step of querying neighboring index managers to determine where the clip is stored if the clip is not stored on an extended storage and retrieval unit.

78. The method of claim 76, wherein said data sequencing interface is invoked on a computer directly connected to said extended storage and retrieval unit if the clip is stored on said extended storage and retrieval unit.

79. The method of claim 77, wherein said data sequencing interface is invoked on a computer directly connected to the storage and retrieval unit where the clip is stored.

80. The method of claim 77, further comprising the step of querying the source index manager to determine where the clip is stored if the clip is not stored on a storage and retrieval unit local to said neighboring index managers.

81. The method of claim 80, wherein said data sequencing interface is invoked on a computer connected to the storage and retrieval unit where the clip is stored.

82. The method of claim 76, further comprising the step of determining a fastest download path if the clip is stored on more than one extended storage and retrieval unit, and wherein said data sequencing interface is directed to download the clip over said fastest download path.

83. The method of claim 79, further comprising the step of determining a fastest download path if the clip is stored on more than one extended storage and retrieval unit, and wherein said data sequencing interface is directed to download the clip over said fastest download path.

84. The method of claim 57, wherein the user is informed if it has been determined that the user is unauthorized to receive the clip.

85. The method of claim 84, wherein the downloading is terminated if it has been determined that the user is unauthorized to receive the clip.

86. The method of claim 82, further comprising the step of determining and utilizing an alternate download path if said fastest download path is unavailable.

87. The method of claim 86, wherein said fastest download path is deemed unavailable if the downloading step is not able to be performed within a predetermined timeout period after the directing step.

88. The method of claim 57, further comprising the step of subscribing to desired content.

89. The method of claim 88, further comprising the step of generating custom Web paged based on said desired content, wherein said custom Web pages include links to subscribed clips.

90. The method of claim 89, wherein said identifying step is performed by the user selecting a link on one of said custom Web pages.

91. The method of claim 88, further comprising the step of updating the user database to reflect a periodic subscription fee.

92. The method of claim 57, wherein said matching step includes comparing a rating attribute in said clip information to a rating limit in said user information.

93. The method of claim 57, further comprising the step of making clips available on said network.

94. The method of claim 93, wherein said step of making clips available comprises the substeps of:
uploading a clip to a Web server;
registering the clip with an index manager corresponding to the Web server;
determining which selected index managers on the network will store the clip:
passing the clip to said selected index managers; and loading the clip to selected extended storage and retrieval units and registering the clip with the index manager corresponding to each such extended storage and retrieval unit.

95. The method of claim 94, wherein said passing step comprises multicasting the clip to said selected index managers.

96. The method of claim 94, wherein each index manager determines whether to load the clip to its corresponding storage and retrieval units.

97. The method of claim 95, wherein the determination is made on the basis of a content database maintained by the index manager.

98. The method of claim 57, further comprising the step of distributing clips for efficient network utilization.

94.

99. The method of claim 98, wherein said distributing step comprises the substeps of:
calculating a first predicted usage of clips for an upcoming period in a given subject area based on historical usage at the same time on previous days and on the same day in previous weeks;
calculating a second predicted usage of clips for an upcoming period based on historical usage at the same time on prior days;
calculating a third predicted usage of clips for an upcoming period based on historical usage in immediately preceding time periods;
combining said said predicted usages to determine, for each clip, an overall predicted usage in the upcoming period;
estimating the bandwidth required to accommodate the predicted usage;
determining which popular clips contribute most to the predicted usage; and moving said popular clips to distribute the load if the estimated bandwidth exceeds a threshold.

100. The method of claim 99, wherein said combining step utilizes the following weightings: 20-40% for the first predicted usage; 20-30% for the second predicted usage; and 30-60% for the third predicted usage.

101. The method of claim 99, wherein said threshold is 10-50% of theoretical bandwidth capacity without slowing.

102. The method of claim 99, wherein the moving step comprises distributing said popular clips over a number of extended storage and retrieval units capable of accommodating the predicted usage.

103. The method of claim 82, further comprising the step of communicating to the primary index manager the delays experienced in transmitting the clip.

104. The method of claim 103, wherein said primary index manager tracks the apparent load experienced by each of its extended storage and retrieval units.

105. The method of claim 104, wherein said primary index manager directs the redistribution of an extended storage and retrieval unit's clips if the extended storage and retrieval unit's apparent load is greater than a first threshold.

106. The method of claim 105, wherein said first threshold is approximately 80% of theoretical bandwidth capacity without slowing.

107. The method of claim 105, wherein said primary index manager directs that popular clips be loaded into a RAM buffer if an extended storage and retrieval unit's apparent load based on said popular clips is greater than a second threshold.

108. The method of claim 107, wherein said second threshold is 30-50% of theoretical bandwidth capacity without slowing.

109. The method of claim 107, wherein said primary index manager directs that clips be downloaded from remote storage and retrieval units associated with neighboring index managers if the data sequencing interface is unable to download from any extended storage and retrieval unit.

110. The method of claim 109, wherein said apparent said remote storage and retrieval units are identified by the data sequencing interface by querying the primary index manager.

111. The distributed video clip delivery system of claim 42, wherein certain video clips comprise a plurality of segments.

112. The distributed video clip delivery system of claim 111, wherein said segments are indicated by segment data associated with a segmented clip.

113. The distributed video clip delivery system of claim 112, wherein said segment data comprises textual information associated with each segment.

114. The distributed video clip delivery system of claim 113, wherein said segment data comprises Internet addresses associated with each segment.

115. The distributed video clip delivery system of claim 114, wherein said segment data identifies additional video clips.

116. The distributed video clip delivery system of claim 112, wherein said segment data is stored by said primary index manager.

117. The distributed video clip delivery system of claim 116, wherein said segmented clip is stored as a plurality of files on said extended storage and retrieval units.

118. The method of claim 57, further comprising the steps of:
determining whether the clip is segmented; and if the clip is segmented, informing the user of such and awaiting instructions on which segments are desired;
and wherein the downloading step downloads only the desired segments.

119. The method of claim 57, further comprising the steps of:
determining whether the clip is segmented;
calculating which segments are desired by accessing data in the user database;
and wherein the downloading step downloads only the desired segments.

120. The system of claim 55, wherein said storage buffer comprising a local storage and retrieval unit interposed between said terminal and said interface.

121. The system of claim 120, wherein said local storage and retrieval unit maintains a local database of video clips as space permits.

122. The system of claim 121, wherein multimedia terminal can access said local database alternatively to receiving video clips by said network.

123. The method of claim 75, wherein said request message is embedded in a Web page.

124. The method of claim 112, wherein said segmented clip is an MPEG file.

125. The method of claim 124, wherein said segment data is stored in a user segment belonging to said MPEG file.

126. The method of claim 61, wherein said protecting step comprises the sub-steps of:
identifying key data fields within the clip;
encrypting the contents of the key data fields;
storing the encrypted contents within said clip; and replacing the key data fields with falsified contents.

127. The method of claim 126, wherein said protecting step further comprises the sub-steps of:
generating a user watermark based on the information corresponding to said user; and storing the user watermark within said clip.

128. The method of claim 126, wherein said clip is an MPEG file, and wherein the encrypted contents are stored within a user stream belonging to the MPEG file.

129. The method of claim 127, wherein said clip is an MPEG file, and wherein the user watermark is stored within a user stream belonging to the MPEG
file.

130. The method of claim 126, wherein said unprotecting step comprises the substeps of:
identifying key data fields within the clip;
locating where the encrypted contents are stored;
decrypting the encrypted contents; and replacing the key data fields with the decrypted contents.