 |
Description  |
|
|
BACKGROUND OF THE INVENTION
The invention relates to a distributed audio/video clip storage and
retrieval system, and more particularly, to a system whereby video
material, stored locally and at a remote location, can be requested and
retrieved at a user's multimedia terminal with or without sound and
associated database information. In a preferred embodiment, the invention
provided a system whereby remotely stored audio and video content can be
requested and retrieved from a server selected so as to maximize network
capacity and minimize transmission delays.
The Internet is a loose network of connected computers spread throughout
the world. A message can be sent from any computer on the Internet to any
other by specifying a destination address and passing the message from
computer to computer via a series of "hops." Each computer, or "node," on
the Internet has a unique Internet address. When an intermediate computer
receives a message in transit, the computer checks the intended
destination of the message and passes it along accordingly.
The Internet is growing, in terms of both size and sophistication, at a
rapid rate. In the past, most users of the Internet were academic,
research, or institutional users; the Internet was primarily used at that
time to transmit and receive electronic mail and network news and to allow
transfer of computer files.
However, since the introduction of the World Wide Web (also known as the
"Web" or the "WWW") several years ago, the Internet has begun to host
increasing amounts of other types of data of general interest, namely
representations of images, articles, etc.
The Web presents a graphical user interface to the Internet. "Web pages,"
often consisting primarily of text and graphical material, are stored on
numerous computers, known as "Web servers," throughout the Internet. These
Web pages are generally described, in terms of layout and content, by way
of a language known as "HTML" (HyperText Markup Language). Any particular
computer linked to the Internet can store one or more Web pages, i.e.
computer files in HTML format, for access by users.
A software program known as a "browser" can be used to access and view Web
pages across the Internet by specifying the location (i.e. Internet
address) of the desired Web page, or more commonly, by "hotlinking" to Web
pages. Common browsers are Lynx, NCSA Mosaic, and Netscape Navigator. The
desired Web page is specified by a uniform resource locator ("URL"),
indicating the precise location of the HTML file in the format
"http://internet.address/directory/filename.html".
Hotlinking is accomplished as follows. The user first accesses a Web page
having a known address, often on the computer located at the user's ISP
(Internet Service Provider). The ISP is the organization providing
Internet connectivity to the user. That Web page can contain, in addition
to textual and visual data specified in HTML format, "links," or embedded
information (in the form of URLs) pointing to the Internet addresses of
other Web pages, often on other computers throughout the Internet. The
user, by selecting a link (often by pointing and clicking with a mouse),
can then access other Web pages, which can in turn contain further data
and/or additional links. When a Web page is accessed, its information is
transmitted from the remote computer, wherever in the world it may be
located, across the Internet, to the user.
In recent times, the Web has begun to host highly sophisticated types of
multimedia content, such as audio and video data. Various extensions to
HTML, such as Netscape's EMBED tag, allow references to other data to be
embedded into Web pages. Some browsers are not capable of handling data
other than text and images. Other browsers can handle the data in various
ways. NCSA Mosaic, for example, handles references to unknown types of
data by allowing the data to be downloaded to the user's computer, and
then optionally invoking an external program to view or manipulate the
data. Recent releases of Netscape Navigator take the concept one step
further: a browser extension, or "plug-in," can be automatically invoked
to handle the data as it is received from the remote Web page. Other
means, such as network program "applets" written in the Java language (or
a similar language), can be used to extend the functionality of the
browser environment or network.
Compared to first generation Web content, namely text and still images,
audio and video data have extremely high storage and bandwidth
requirements. In particular, video files can be very large, from
approximately 10 megabytes to 10 gigabytes. In order to play video files
at speeds approaching their recorded rate at a user's terminal, the files
have to be delivered at a fast, constant 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
difficult, if not impossible, to provide sustained high-speed transmission
of large files over a multi-node link on the Internet. Because the data is
often transferred from afar, many factors can cause the delay or even loss
of parts or all of a transmission.
This attribute, combined with the rapid growth of the Web and the Internet
in general, has led to several problems. There is now a high and
increasing volume of Internet traffic caused by Web page access, and the
demand for bandwidth already exceeds supply.
Furthermore, certain content on the Web is extremely popular. Because
current Internet technology provides Web pages from specific or
"dedicated" remote site or servers, the most popular sites are often
overloaded. Furthermore, according to current Internet technology, each
response to a user request is generally transmitted separately. In other
words, if one hundred users request transmission of the same Web page at
the same time, one hundred separate transmissions must be made to these
users. Because many of these popular Web pages are often being transmitted
across many nodes on the Internet, there can be substantial duplication,
delays and lost requests, for both the requested data and other, unrelated
data being transmitted over the same routes. If a Web server containing
video data receives many simultaneous requests for its ability to transfer
all of the files at full speed is impaired.
Accordingly, a need exists for a system capable of providing improved
access to audio/video content on the Internet or another general purpose
network. Such a system would take steps to ensure that content is
delivered without delay or interruption to all users requesting it.
The prior art is primarily directed towards text or image database
providers, and so-called "video on demand". These systems are not designed
to store text and video or audio-visual data across multiple computer
systems in a distributed network. The "video on demand" concept is based
primarily on a host-client architecture for downloading real-time
audio-visual data, in very large amounts at a very high speed. Such
systems aim, for example, to provide full-length movies, with sound, to
on-line subscribers. Typically, remote users communicate with large
main-frame servers containing the audio-visual data. The host-client
architecture of such systems stems from the desire to eliminate bandwidth
limiting elements in the system by locating the video data solely on the
provider's high-capacity system. The provider must then insure that
hardware and software used to distribute this data is capable of the very
high storage and transmission rates required, and is virtually error free,
so that no perceivable data is corrupted or lost.
Known and proposed "video on demand" systems involve expensive and
sophisticated computer and communication systems which are adapted to feed
full length movies to attached subscribers "on demand." Such systems use a
massively parallel computing architecture, in an attempt to adapt the
multi-processing computing system to manage the monumental video data
delivery requirements of hundreds of simultaneous users. Each
multi-processing computer is a single "mainframe" computer and operating
system with numerous intricately interconnected individual
microprocessors. The massively parallel computers also have very high
speed internal data buses with the capability of sustaining a significant
but fixed level of internal data traffic.
Massively parallel systems present three distinct disadvantages: (1)
reliability, (2) cost, and (3) they are not scalable. Since video data is
highly storage intensive, a very large number of hard drives are required
to sustain the system. This requirement substantially increases cost.
Further, because the hard drive is generally the most unreliable aspect of
any computing system, using a large number of hard drives contributes
significantly to making the overall system more unreliable. Also, due to
the centralized systems basic structure, it is not scalable.
Another system employing large mainframe servers to store the audiovisual
data for delivery to a small number of users depends on reducing hard
drive throughput by developing specialized hard drive interface software.
This software determines how the computer's operating system uses the
computer's hard drive. For example, multiple blocks of related data can
always stored sequentially, instead of randomly. Although this may lead to
more effective data throughput rates, such systems have the ability to
accommodate only about 40 simultaneous users, and are geared to in house,
small scale, video distribution.
A limited or partial "distributed" architecture has been proposed, which
would link multiple personal computers together in order to fashion a much
larger monolithic functional unit. In this system, video data is
distributed only to build a single, much larger source of digital video
information. For example, a long video is assembled "on the fly" from
separately stored pieces on different machines. Such a system might
subsequently use ATM switch technology to merge the output of this array
of computers into one or more continuous video streams.
By contrast, the invention provides a true or complete distributed
architecture with increased reliability and the capability of supporting
thousands of simultaneously attached users, at a fraction of the cost of
the massively parallel system. In a preferred embodiment, the invention
uses the existing Internet infrastructure, in conjunction with a network
architecture as described herein, to achieve rapid and efficient delivery
of audio/visual content to end users.
The invention not only distributes unlike databases (for example, a related
but distinct "text database" and "audio-visual database") across the
assorted computing and communication devices, but it also partitions and
distributes data in a manner which maximizes the performance of the
network as a whole.
In one embodiment of the invention, the user, a real estate agent, has the
capability of receiving up-to-date audio-visual information about a listed
property. Presently, a real estate agent spends hours researching relevant
aspects of available property, to include, inspecting the property, taking
photographs of the property, and accumulating information about the
property. In fact, the typical agent sees less than 50 percent of the new
homes listed because of time constraints. Additional time and effort is
spent ascertaining the prospective buyer's desires, introducing the buyer
to the range of communities available within a chosen region, researching
properties that the potential buyer may be interested in, and then showing
these properties to the potential buyer.
According to the invention, a realtor's time will be more effectively used
on activities directly related to selling property, and not on time
intensive, activities necessary to stay abreast with market conditions.
For example, by being able to view the property on a video terminal the
realtor will reduce significantly the time spent researching potential
properties. The time spent visiting properties with the potential buyer is
likewise reduced by being able to introduce the property to the buyer via
the video clip. This allows the realtor to devote more time to closings
and other administrative duties associated with selling the property.
Also, having the video retrieval capability allows the realtor to
constantly refresh the customer's memory without having to revisit the
property.
SUMMARY OF THE INVENTION
The invention is directed to a video clip storage and retrieval system
whereby the user receives comprehensive data collected from one or more
databases by request from a user's multimedia terminal. The comprehensive
data is provided in the form of selected video clips coupled with
corresponding database information.
The video clip retrieval system is a distributed computer system or network
whereby video clips and text information, stored locally and at a remote
location, can be requested and viewed at a user's multimedia terminal. The
system is partitioned into database index managers ("IMs"), extended
storage and retrieval units ("extended SRUs"), data sequencing interfaces
("DSIs"), local storage and retrieval units ("local SRUs"), and user
terminal modules. Each partition supports features important to the
operation and management of the system, but are not necessarily assigned
to a specific physical computer or communication component.
In operation, a user first builds a request at a user terminal. The request
is transmitted to the user's primary index manager ("PIM") via a local
storage and retrieval unit (local SRU). The local SRU attaches a Regional
Identifier to the request to assist the PIM to efficiently search for,
locate and report on the requested information. The local SRU provides
temporary storage for the user's most requested video clips, and before
the query is sent to the user's PIM, the local SRU is polled for requested
video clips. The user query, amended to contain a Regional identifier and
to reflect any local matches, is then forwarded to the PIM.
The PIM uses the Regional Identifier to identify remote IMs which may have
the requested video information. The PIM also checks to see whether the
video clips stored at the local SRU are current. The PIM then queries its
own video clip listing and the listing for the remote IMs to locate the
requested information. A list or summary of all available data responsive
to the request is then transmitted 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 passed to the PIM. The PIM, having
previously located each requested video clip on other remote IMs,
retrieves the requested video clips and displays them at the user's
terminal by creating a DSI for each user that requests video clips that
are not stored at the local SRU, and informing the DSI where the requested
video clips are stored. The DSI collects the requested video clips from
the appropriate extended and remote SRUs and transmits this information to
the local SRUs.
The requested video clips satisfying the user query are then displayed at
the user's terminal. The user may display, copy, and/or save or print the
results. Copies can also be made on standard video cassettes. In a
preferred embodiment, the DSI has the capability of resequencing the
transmission order of video clips to further manage the demands on the
system. For example, requested video data may be stored and retrieved at
various locations throughout the system, at various distances from the
user, and accessible through different networks or communications routes,
with different bandwidths and transmission speeds. In a preferred
embodiment, the DSI determines the most appropriate routes and schedules
for downloading requested information, to provide fast and efficient
service to the user without unduly taxing the shared components of the
system. The PIM records how often particular video clips are requested,
and from this information determines whether those clips should be
duplicated at particular local SRUs for ready display. As video clips are
updated or eliminated, the PIM makes the required updates to the database
log. Also, the PIM keeps track of billing information 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 Internet
or other network.
First, specific Web page audiovisual content is dissociated from its
original server, and is distributed to numerous servers in geographically
different areas having a relatively short distance (geographically and
electronically) to the user's terminal. This is facilitated by embedding a
"video ID" in a Web page to indirectly specify a video clip. A database is
accessed to relate the video ID to the optimal server from which to
download the clip. This is accomplished in such a way as to locate
audio/video content on servers close to those users expected to request
it, thereby minimizing the number of network nodes traversed. Furthermore,
if certain servers are overloaded or out of service, the data is
dynamically redundant, so the desired content can be efficiently retrieved
from alternate sites.
According to the present invention, data is distributed on the network in a
configuration responsive to historical usage, current usage, and predicted
usage. By optimizing these considerations, network traffic can be reduced
and overloaded servers and communications links avoided. In addition,
geographical servers can be established to hold clips of particular
interest for a specific geographical region, and subject-matter server&
can be established to hold clips pertaining to certain subject areas.
Furthermore, frequently requested clips can be queued and multicast to
multiple users at one time. This, too, reduces network traffic and
increases responsivity.
Another aspect of the invention is its ability to allow a user to interact
with the retrieved video clip. Technology to physically manipulate video
information on personal computers 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 viewing. Video boards and systems of this
kind can employ compression protocols, such as "MPEG" Motion Picture
Experts Group) standards 1 and 2, and Motion "JPEG" (Joint Photographic
Experts Group) to store and transmit video data in a highly compressed
state. This reduces the storage capacity and transmission time needed to
work with the video data. Such systems allow a user to view and edit video
on a personal computer terminal, but unlike the present invention, do not
provide the capability of selecting and retrieving desired video clips
from remote locations at high speed.
In a preferred embodiment of the present invention, the user establishes an
account with a content provider or ISP. This account may be in the form of
a subscription, a debit account, or any of numerous other known payment
arrangements. When the user accesses subscribed-to content through the
system, the account can be updated. In this manner, the user can be billed
for usage in any manner desired, subscription information can be tracked
and preserved, authorization levels can be set, and data protection to
prevent unauthorized use can be accomplished.
The system may offer secondary audio visual information which would
correspond to the requested video clips. In an illustrative application
within the real estate industry, the secondary audio visual information
could be the schools, shopping centers, and hospitals situated in the
vicinity of a requested property. The secondary videos are related to the
primary audio-visual data or video clips through a coordinate system to
minimize data entry, data storage, and the demands on the system's
computational resources.
Certain advanced embodiments also allows the user to perform "what if"
alterations of the downloaded information, for example, allowing the user
to show a potential buyer what a listed house would look like with a porch
addition.
In general, the user's ability to download video clips is enhanced by the
present invention. When the user wants to view a clip, the video ID will
be retrieved and sent to a regional database. If the regional database can
match the video ID to a clip existing on a local server, and the user's
subscription rights are sufficient, then the clip will be downloaded from
the local server. If the clip is unavailable locally, or the local server
is overburdened, then succeedingly more remote servers will be queried for
the transfer. Accordingly, the fastest possible path will be selected, and
traffic will be minimized on the network.
Exemplary embodiments of this invention are directed to the real estate
industry and to video delivery over the Internet. However, as will become
readily apparent, the invention is applicable to a wide range of end uses
where convenient access to corresponding audio-visual information would be
useful. For example, the video clip retrieval system can be used for
retail sales, dating services, travel services, and many other
applications.
BRIEF DESCRIPTION OF THE DRAWINGS
The features of the invention will be more readily apparent from the
following detailed description and drawings of an illustrative embodiment
of the invention.
FIG. 1 is a block diagram showing a preferred hierarchy of the system.
FIG. 2 is a block diagram illustrating how various modules of the video
clip retrieval system may be addressed.
FIG. 3 is a flow chart illustrating data sequencing interface logic for
video clip storage management.
FIG. 4 is a block diagram of an embodiment of the present invention
implementing video clip delivery over the Internet.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 illustrates a preferred embodiment of the video clip storage and
retrieval system, showing its structural hierarchy and the various modules
which comprise the system. As shown, the system comprises one or more user
terminals 14, a local storage and retrieval unit ("local SRU") 18, a data
sequencing interface (DSI) 30, one or more extended storage and retrieval
units ("extended SRUs") 26, and one or more index managers ("IM") 22.
By way of a system overview, video clips are stored primarily on extended
SRUs 26, and are tracked and distributed by the IMs 22. A user obtains
videos of interest by communicating with a primary index manager ("PIM")
22 via a local SRU 18. The PIM 22 locates the requested video clips and
creates a DSI 30 to direct the efficient download of the video clips to
the user terminal 14. The connections between terminal 14 and the local
SRU 18 can be within the same computer, or between two or more computers
located within a building, which are linked together on a local area
network.
Exemplary software modules comprising each component of the system, and
databases associated with each software module, are depicted in Table 1,
below. Preferred and non-limiting embodiments of each module of the system
are also described below, with reference to FIG. 1 and Table 1.
TABLE 1
SOFTWARE MODULES & DATABASE PARTITIONING
##STR1##
##STR2##
User Terminal
A user terminal 14 is the user's interface to the system, and typically is
a personal computer, workstation, or a television set top box. Terminal 14
is connected to or includes the local SRU 18, and sends the user's
requests to the PIM 22, after initial interrogation of local SRU 18. As
shown in FIG. 1, terminal 14 communicates with a PIM 22 to obtain
requested audio-visual data, wherever the requested data is stored, e.g.
on extended SRUs 26 or remote SRUs 38, and on different systems or
networks at different communication and/or phone system addresses.
Terminal 14 receives or downloads requested audio-visual information
through the local SRU 18.
As shown in Table 1, each user terminal 14 comprises a search and query
interface, an audio-visual display interface, and audio-visual data
decompression logic. The search and query interface provides the user
access to a database or index which can be interrogated for desired video
clips and other information. For example, in a real estate application,
one such database could be the Multiple Listing Service (MLS).
The audio-visual display interface provides a mechanism for the user to
manipulate retrieved video clips. After requested video clips have been
displayed on the user's terminal 14, the user may then interact with the
system using, for example, a play, stop, pause, fast forward, fast
reverse, forward and reverse metaphor. The user may elect to "jump" to
specified locations within the clip, the locations being tabulated in a
window on the user's terminal 14. Also, displayed in another window on the
user's screen may be a list of available secondary options for user
interaction.
In a preferred embodiment, videos are stored and moved through the system
in a highly compressed state and will be decompressed at the users
terminal 14. The decompression logic utilized may be commercially
available video decompression standards and protocols, for example, Motion
Picture Experts Group ("MPEG") standards 1 and 2, MJPEG, Indeo, or
Fractal.
Local Search and Retrieval Unit (Local SRU)
The local SRU 18 is the temporary storage location for video clips and for
information downloaded from the extended and/or remote SRUs 26 and 38, for
use at user terminal 14. As shown in FIG. 1, user terminal 14 and local
SRU 18 may be combined as one computing system. In a preferred embodiment,
the local SRU 18 is connected to one or more user terminals 14, each local
SRU 18 being capable of supporting a large number of user terminals 14.
For example, the local SRU 18 may comprise a file server for a local area
network, with one or more integral or connected storage devices. In such
an embodiment, each terminal 14 interacts with the local SRU 18 via a
network connection, e.g. as a network node, using conventional network
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 drives, high speed optical
drives, RAID devices, and other media capable of storing locally a
reasonable complement of video clips for ready access and manipulation.
Portions of the local SRU's 18 disk storage capacity are designated as the
storage capacity required to duplicate a subset of the primary and remote
IM(s) audio-video data index databases. This information is used during
terminal queries to determine which video clips are stored locally. Video
segment revision information is also maintained within the index database,
and is returned to the IM during the query process in order to maintain
video segment accuracy. In the event that additional storage space is
required, additional disk storage may be provided to the local SRU, to
include storage capacity for active, inactive, and secondary audiovisual
listings.
Apart from storing audio-visual data, the local SRU 18 comprises local
search and update logic, a regional identifier builder, an audio-visual
data download interface, and (6) compression/decompression logic (Table
1).
The Regional Identifier Builder component of local SRU 18 attaches a
regional code or identifier to each user request. The regional identifier
allows the PIM 22 to communicate with specified remote IMs 34, and to
determine the locations of requested video clips stored at remote SRUs 38.
In an embodiment used to distribute real estate data, the regional
identifier may be the ZIP code of the property in the video segment. This
information may be taken directly from the text database. It will be
apparent, however, that the (Regional ID) field can be keyed to any
convenient category or context-sensitive description suitable for the type
of information stored and the desired end use.
Local SRU 18 transmits downloaded video clips to the user terminal 14 in a
highly compressed state. In a preferred embodiment of the invention, this
operation is mediated by an Audio-visual Download Interface associated
with local SRU 18 (Table 1), with decompression prior to and/or in
"real-time" during viewing occurring at the user terminal 14. Local SRU
18, via its download interface, also communicates with a DSI 30, described
in more detail below. DSI 30 manages the download of video clips and other
information to local SRU 18 from the various locations where responsive
information is found.
The local search and update logic serves primarily two functions. First, it
enables local SRU 18 to search its storage media for requested video clips
before the query is transmitted to the PIM 22. The update logic allows the
PIM 22 to identify whether the locally available video clip is current.
Thus, when the user's request is transmitted to the PIM 22, the request is
modified to indicate (1) whether the video segment is stored locally, and
(2) the current Revision Code associated with the video clip. If the PIM
22 locates a clip that supersedes the one currently stored on the local
SRU 18, the local SRU 18 is notified, the old data is deleted, and the new
data is downloaded from the SRU 26 containing the updated video clip.
A second function of the local search and update logic is to identify and
track the most frequently requested audio-visual clips. These video clips
are identified for continued storage within the local SRU 18. This ensures
that once a predetermined local SRU storage capacity is reached, only the
most heavily used video clips are 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 identified, 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 requested video clips, space
permitting. A combination of these and other storage swapping and
management approaches may be used.
In a preferred embodiment, DSI 30 transmits information in compressed form
to local SRUs 18 for downloading to the user's terminal 14. The
decompression is performed at the user terminal 14 using conventional
decompression standards. However, where the user is using a television
screen, or other unintelligent device, to receive the audiovisual data,
the decompression, via commercially available decompression standards
(discussed above) will take place at the local SRU 18.
Primary Index Manager
The PIM 22 is the primary search engine and database management module of
the invention. As shown in Table 1, PIM 22 comprises (a) index manager
supervisory process; (b) text database management logic; (c) storage
management logic; (d) message routing logic; and (e) DSI & extended SRU
command logic. The PIM 22 is designed so that no two functions must
specifically reside on the same physical computer, although it will be
apparent that in preferred embodiments certain functions may be
conveniently or efficiently grouped together conceptually and/or
physically, for greater ease of use.
The "index manager supervisory process" (Table 1) is the software interface
to the high speed communication interface (explained below). It provides
the communication interface to the local SRUs 18 and to the text
databases. When the user's query necessitates creating a DSI 30, the
"index manager supervisory process" creates a DSI 30 on its computer
system unless the "index manager supervisory process" determines that the
current state of high speed communications on its computer exceeds a
predetermined limit, for example, 40-80 users. In that event, the DSI 30
is created on a different computer system.
The "text database management logic" is incorporated from the text database
in use with the system, and manages and controls text data stored within
these databases. For example, in the real estate embodiment, the "text
database management logic" is the logic associated with the Multiple
Listing Service ("MLS") database, and is structured to allow MLS queries
spanning the entire distributed network.
The "storage management logic" is the system "storage engine" and is
responsible for placing new and/or updated or uploaded audio-visual data
on the most appropriate extended SRU 26. Audio-visual segments or clips
can be stored to more than one extended SRU 26, when duplication would
minimize traffic to and from local SRUs 18, for example over high speed
network 24 or communication line 16. The decision to move or copy data to
an extended SRU 26 from a remote IM 34 and SRU 28, or from another
extended SRU 26, is made for example by evaluating an algorithm which
accounts for available storage space on the various SRUs 26, the demand
for particular video clips, and the locations of users requesting the most
popular videos. The "storage management logic" may also track parameters
such as the cost of transmitting and storing duplicate information, and
helps to ensure that each extended SRU 26 is utilized efficiently, and
that no extended SRU 26 becomes "overextended."
The index manager "message routing logic" accepts regionalized queries from
the local SRU 18, deciphers the queries, and subsequently forwards the
disassembled queries to remote IMs 34. The index manager "message routing
logic" also accepts the responses received from the remote IMs 34,
formulates a comprehensive response, and relays this response to the user.
The "DSI and SRU command logic" provides the IM 22 with the capability of
directly communicating and controlling the DSIs 30 and the SRUs 26. The
PIM 22 uses this interface to pass the data required to enable the DSI 30
to communicate with the extended and remote SRUs 26 and 38 to direct these
SRUs to download video information.
The "SRU Command logic" sees to the duplication of popular videos on
alternate SRUs 26. It also places copies of video segments on SRUs
geographically closer to the users most interested in those videos. The
goal is not duplicate data onto SRUs 26 where the number of frequently
downloaded videos ("FDVs") is already high (above a predetermined value).
Duplication of data is performed according to the following logic during
non-peak periods of system operation. The PIM 22 determines whether it is
managing an extended SRU 26 which has an FDV level above this
predetermined value. This determination is made by searching through the
"Audio-Visual Data Index" database (described below) to identify the video
clips that have been accessed most frequently. From this video subset,
videos are selected for transferal or duplication based on where the video
was used most. If the FDV was transferred principally from DSIs 30 created
by the PIM 22, extended SRUs 26 located within the same computer are
evaluated to determine whether that extended SRU 26 can accept a duplicate
copy of the video clip. If so, the FDV is duplicated on the identified
extended SRU 26.
Extended Storage and Retrieval Unit (Extended SRU)
As noted above, extended 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. Although this section refers primarily to the
extended SRU 26, the term includes remote SRUs 38 which may also store
requested audio-visual information. The software modules are identical.
The most requested audiovisual data, to include the FDVs, are written in
contiguous allocation blocks closest to the system's disk storage
allocation table. Inactive video segments are stored in contiguous
allocation blocks furthest away from the "disk storage allocation table."
In an alternative configuration, the disk storage allocation table is
maintained in RAM or on a separate computer. Disk storage is organized in
macro storage cells which insure that each video segment will always be
stored in contiguous allocation blocks. This may be achieved, for example,
by using a storage cell capable of storing a two minute audiovisual
segment.
Referring to FIG. 1, one or more extended SRUs 26 are connected to the PIM
22 and to each terminal-unique DSI 30, in the event that the PIM 22
determines that a DSI 30 should be created. The extended SRUs 26, upon
direction of a DSI 30, transmit requested data, via the DSI 30, to an
appropriate local SRU 18, and ultimately to user terminal 14.
The extended SRU 26 comprises an SRU supervisory process, an IM command
interface, and a DSI command interface. The SRU supervisory process
enables the extended SRU 26 to communicate directly with the IMs 22 and
DSIs 30. This interface responds to messages and data packets addressed to
it. It also encapsulates, for network transmission purposes, video data to
be transmitted 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 unnecessarily duplicated
data. This storage and deletion of data are performed under the direction
of the PIM 22 via the "IM Command Interface."
The "DSI command interfaces" exist to allow the PIM 22 to function apart
from the extended SRUs 26. The DSI command interface is provided to direct
the extended SRU 26 to download the audio-visual information to the DSI 30
transmit buffers for eventual download to the user terminal 14.
Data Sequencing Interface (DSI)
According to the invention, each DSI 30 is created by the PIM 22 to
facilitate data transfer from the extended and remote SRUs 26 and 38 to
the user terminal 14. When created, the DSI 30 may reside within the
extended or local components of the system, but in the preferred
embodiment of FIG. 1 is shown locally. The DSI 30 collects, manages, and
buffers data which is transmitted from bot | | |
