JP2011507340A - 記録されたビデオセグメントと一体化されたストリーミング双方向ビデオ - Google Patents

記録されたビデオセグメントと一体化されたストリーミング双方向ビデオ Download PDF

Info

Publication number
JP2011507340A
JP2011507340A JP2010537059A JP2010537059A JP2011507340A JP 2011507340 A JP2011507340 A JP 2011507340A JP 2010537059 A JP2010537059 A JP 2010537059A JP 2010537059 A JP2010537059 A JP 2010537059A JP 2011507340 A JP2011507340 A JP 2011507340A
Authority
JP
Japan
Prior art keywords
video
game
user
frame
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2010537059A
Other languages
English (en)
Inventor
スティーブン ジー パールマン
デル ラーン ロジャー ヴァン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OnLive Inc
Original Assignee
OnLive Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OnLive Inc filed Critical OnLive Inc
Publication of JP2011507340A publication Critical patent/JP2011507340A/ja
Pending legal-status Critical Current

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/335—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • A63F13/12—
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/355—Performing operations on behalf of clients with restricted processing capabilities, e.g. servers transform changing game scene into an MPEG-stream for transmitting to a mobile phone or a thin client
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • A63F13/49—Saving the game status; Pausing or ending the game
    • A63F13/497—Partially or entirely replaying previous game actions
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/85—Providing additional services to players
    • A63F13/86—Watching games played by other players
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/115—Selection of the code volume for a coding unit prior to coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/154—Measured or subjectively estimated visual quality after decoding, e.g. measurement of distortion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/164—Feedback from the receiver or from the transmission channel
    • H04N19/166—Feedback from the receiver or from the transmission channel concerning the amount of transmission errors, e.g. bit error rate [BER]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/587—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal sub-sampling or interpolation, e.g. decimation or subsequent interpolation of pictures in a video sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/214—Specialised server platform, e.g. server located in an airplane, hotel, hospital
    • H04N21/2143—Specialised server platform, e.g. server located in an airplane, hotel, hospital located in a single building, e.g. hotel, hospital or museum
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2743—Video hosting of uploaded data from client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2747—Remote storage of video programs received via the downstream path, e.g. from the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4341—Demultiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47217—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for controlling playback functions for recorded or on-demand content, e.g. using progress bars, mode or play-point indicators or bookmarks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4781—Games
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/402—Communication between platforms, i.e. physical link to protocol
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/552—Details of game data or player data management for downloading to client devices, e.g. using OS version, hardware or software profile of the client device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/10—Adaptations for transmission by electrical cable
    • H04N7/106—Adaptations for transmission by electrical cable for domestic distribution

Abstract

【課題】記録されたビデオセグメントと一体化されたストリーミング双方向ビデオを提供する。
【解決手段】ストリーミング双方向ビデオの形態のユーザページを発生して、インターネットを経てサーバーセンターのサーバーに接続されたユーザコンピュータのディスプレイへ流すためのプログラムをそのサーバー上で実行することを含む方法において、ユーザページは、複数のビデオウインドウを含み、１つ以上のビデオウインドウは、ストリーミング双方向ビデオと、ユーザにより再生できる同時に記録されたビデオセグメントとを含む。
【選択図】図２ａ

Description

本発明は、一般的に、オーディオ及びビデオメディアを操作し及びそれにアクセスするユーザの能力を改善するデータ処理システムの分野に係る。
関連出願：本出願は、本出願の譲受人に譲渡された“APPARATUS AND METHOD FOR WIRELESS VIDEO GAMING”と題する２００２年１２月１０日出願の第１０／３１５，４６０号の一部継続（ＣＩＰ）出願である。
記録音声及び動画メディアは、トーマスエジソンの時代から世相を表している。２０世紀の初頭に、記録音声メディア（シリンダー及びレコード）及び動画メディア（ニコロデオン及び映画）が広く配給されたが、両技術は、まだ幼時期であった。１９２０年代後期に、動画が大量市場ベースで音声と結合され、その後、音声を伴うカラー動画となった。ラジオ放送は、大規模な広告支援形態の放送大量市場音声メディアへと徐々に進化した。１９４０年代中期にテレビ（ＴＶ）放送規格が確立されると、テレビは、予め録画された又は生の動画を家庭へ届ける放送大量市場メディアの一形式としてラジオに加わった。
２０世紀中期までは、米国の家庭の大部分は、記録音声メディアを再生する蓄音器レコードプレーヤ、生放送音声を受信するラジオ、及び生放送オーディオ／ビデオ（Ａ／Ｖ）メディアを上映するテレビ受像機を有していた。多くの場合に、これら３つの「メディアプレーヤ」（レコードプレーヤ、ラジオ及びＴＶ）は、共通のスピーカを共有する１つのキャビネットに結合されて、家庭の「メディアセンター」となった。メディアの選択肢は、消費者に制限されるが、メディア「エコシステム」は、かなり安定したものであった。ほとんどの消費者は、「メディアプレーヤ」をどのように使用するか知っており、それらの能力をフルに楽しむことができた。同時に、メディアの発行者（主に動画及びテレビスタジオ、並びに音楽会社）は、一般に普及した海賊版又は「二次販売」即ち中古メディアの再販から悩まされることなく、それらのメディアを劇場及び家庭の両方に配給することができた。典型的に、発行者は、二次販売から収入を得ず、従って、そうでなければ新規販売のために中古メディアの買い手から発行者が得るかもしれない収入が減少した。２０世紀の中期に販売された中古レコードは確かにあるが、そのような販売は、レコード発行者に大きな影響を及ぼさなかった。というのは、典型的に大人が一度又は数回見るだけの動画又はビデオ番組とは異なり、音楽トラックは、数百回又は数千回も聞かれるからである。従って、音楽メディアは、動画／ビデオメディアより遥かに「腐敗」しない（即ち、大人の消費者にとって価値が継続する）。レコードを購入すると、消費者がその音楽が好きな場合、消費者は、おそらくそれを長期間保持する。
２０世紀の中期から今日にかけて、メディアエコシステムは、消費者及び発行者の利益及び損害の両方にとって一連の根本的な変化を受けた。オーディオレコーダー、特に、高品質ステレオサウンド付きのカセットテープが広く導入されると、確かに高度の消費者便宜性があった。しかし、それは、消費者メディアと共に今や広く普及したもの、即ち海賊版の始まりも印した。確かに、大勢の消費者が彼ら自身のレコードを純粋に便宜性のためにテープ記録するのにカセットテープを使用したが、次第に多くの消費者（例えば、互いのレコードコレクションに手早くアクセスできる寄宿舎の学生）が海賊版コピーを作成した。又、消費者は、発行者からレコードやテープを買うのではなく、ラジオを経て演奏される音楽もテープ記録した。
消費者向けＶＣＲの出現は、新規なＶＣＲがＴＶショーを録画するようにセットでき、後で見ることができるので、更なる消費者便宜性を導くと共に、映画やＴＶ番組に「オンデマンド」ベースでアクセスできるビデオレンタルビジネスの創設も導いた。１９８０年代中期以来の大量市場家庭用メディア装置の急速な開発は、かつてない選択肢レベル及び消費者にとっての便宜性を導くと共に、メディア発行市場の急速な膨張も導いた。
今日、消費者は、過度のメディア選択肢及び過度のメディア装置に直面し、その多くは、特定の形式のメディア又は特定の発行者に結び付いたものである。熱心なメディア消費者は、家の種々の部屋にＴＶ及びコンピュータに接続された装置を積み重ねて有し、その結果、１つ以上のＴＶ受像機及び／又はパーソナルコンピュータ（ＰＣ）へのケーブルの「ネズミの巣穴」、並びにリモートコントローラのグループが生じている。（本出願に関して、「パーソナルコンピュータ」又は「ＰＣ」という語は、デスクトップ、Ｍａｃｉｎｔｏｓｈ（登録商標）又は他の非Ｗｉｎｄｏｗｓ（登録商標）コンピュータ、Ｗｉｎｄｏｗｓ適合装置、ＵＮＩＸ（登録商標）バリエーション、ラップトップ、等を含めて、家庭又はオフィスで使用するのに適した任意の種類のコンピュータを指す。）これらの装置は、ビデオゲームコンソール、ＶＣＲ、ＤＶＤプレーヤ、オーディオサラウンド−サウンドプロセッサ／増幅器、衛星セットトップボックス、ケーブルＴＶセットトップボックス、等を含む。そして、熱心な消費者にとって、互換性の問題があるために、複数の類似機能装置が存在する。例えば、消費者は、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙ ＤＶＤプレーヤの両方を所有したり、又はＭｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）及びＳｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）の両ビデオゲームシステムを所有したりすることがある。実際に、あるゲームはゲームコンソールのバージョンにわたって互換性がないために、消費者は、ＸＢｏｘと、その後のバージョン、例えば、Ｘｂｏｘ３６０（登録商標）との両方を所有することがある。多くの場合、消費者は、どのビデオ入力及びどのリモートコントローラを使用すべきか混乱する。ディスクが正しいプレーヤ（例えば、ＤＶＤ、ＨＤ−ＤＶＤ、Ｂｌｕ−ｒａｙ、Ｘｂｏｘ又はＰｌａｙｓｔａｔｉｏｎ）に入れられ、その装置に対してビデオ及びオーディオ入力が選択され、そして正しいリモートコントローラが見つかった後でも、消費者は、まだ、技術的な挑戦に直面する。例えば、ワイドスクリーンＤＶＤのケースでは、ユーザは、先ず、自分のＴＶ又はモニタスクリーンにおける正しいアスペクト比（例えば、４：３、フル、ズーム、ワイドズーム、シネマワイド、等）を決定し、次いで、セットすることが必要になる。同様に、ユーザは、先ず、正しいオーディオサラウンドサウンドシステムフォーマット（例えば、ＡＣ−３、ドルビーデジタル、ＤＴＳ、等）を決定し、次いで、セットすることが必要になる。多くの場合、消費者は、彼等のテレビ又はオーディオシステムのフル能力でメディアコンテンツを楽しんでいないことに気付かない（例えば、間違ったアスペクト比で押しつぶされた映画を見たり、又はサラウンドサウンドではなくステレオでオーディオを聞いたりしている）。
装置の積み重ね体には、インターネットベースのメディア装置が益々追加されている。Ｓｏｎｏｓ（登録商標）デジタルミュージックシステムのようなオーディオ装置は、インターネットからオーディオを直接ストリーミングしている。同様に、Ｓｌｉｎｇｂｏｘ（登録商標）エンターテイメントプレーヤのような装置は、ビデオを録画し、そしてホームネットワーク又はインターネットを通してそれをストリーミングし、遠隔位置でＰＣにおいてそれを見ることができる。インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスは、デジタルサブスクライバーライン（ＤＳＬ）又は他のホームインターネット接続を通してケーブルＴＶ型のサービスを提供している。又、最近では、Ｍｏｘｉ（登録商標）メディアセンターや、Ｗｉｎｄｏｗｓ ＸＰメディアセンターエディションを実行するＰＣのような単一の装置へ複数のメディアファンクションを一体化する努力もなされている。これらの装置は、各々、それが遂行するファンクションに対する便宜性の要素を与えるが、偏在性及びほとんどのメディアへの簡単なアクセス性が欠如している。更に、このような装置は、多くの場合に高価な処理及び／又はローカル記憶が必要なために、製造コストがしばしば数百ドルに達する。更に、これらの近代的な消費者向け電子装置は、典型的に、アイドル状態である間も、多量の電力を消費し、これは、時間と共に経費高となり且つエネルギーリソースを浪費することを意味する。例えば、ある装置は、消費者がそれをターンオフするのを怠るか又は異なるビデオ入力へスイッチした場合に動作し続けることがある。そして、どの装置も完全な解決策ではないので、家庭内の装置の他の積み重ね体と一体化しなければならず、これでは、依然、ユーザをワイヤのネズミの巣穴及びリモートコントローラの海に残すことになる。
更に、多くの新しいインターネットベースの装置は、それが適切に機能するときには、典型的に、メディアを、それが入手できる以上に一般的な形態で提供する。例えば、インターネットを通してビデオをストリーミングする装置は、多くの場合、ビデオ、ゲームの「制作」又は演出家の解説のようなＤＶＤをしばしば付随する双方向「エキストラ」ではなく、ビデオ資料だけをストリーミングする。これは、多くの場合、双方向性をローカルに取り扱う特定の装置に意図された特定のフォーマットで双方向資料が発生されることによるものである。例えば、ＤＶＤ、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙディスクは、それら自身の特定の双方向フォーマットを有している。普及型フォーマットを全てサポートするように開発されるホームメディア装置又はローカルコンピュータは、おそらく消費者が動作するには法外なほど高価で且つ複雑なものにするレベルの精巧さ及び融通性を要求することになる。
この問題に加えて、将来的に新規なフォーマットが導入された場合には、ローカル装置は、その新規なフォーマットをサポートするハードウェア能力をもたないことがあり、これは、消費者がアップグレード型のローカルメディア装置を購入しなければならないことを意味する。例えば、高解像度ビデオ又はステレオビデオ（例えば、各目に対して１つのビデオストリーム）が後日に導入された場合には、ローカル装置は、そのビデオをデコードする計算能力をもたないか、又は新たなフォーマットでビデオを出力するためのハードウェアをもたないことがある（例えば、各目に６０ｆｐｓが与えられて、１２０ｆｐｓのビデオがシャッター付き眼鏡と同期されることでステレオ感が達成されると仮定すれば、消費者のビデオハードウェアが６０ｆｐｓビデオしかサポートできない場合、このオプションは、アップグレード型ハードウェアを購入しなければ、利用できない）。
メディア装置の老朽化及び複雑さの問題は、精巧な双方向メディア、特に、ビデオゲームに至ったときには、重大な問題となる。
近代的なビデオゲームアプリケーションは、主として、４つの主要な非ポータブルハードウェアプラットホーム：即ち、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）１、２及び３（ＰＳ１、ＰＳ２及びＰＳ３）、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）及びＸｂｏｘ ３６０（登録商標）、Ｎｉｎｔｅｎｄｏ Ｇａｍｅｃｕｂｅ（登録商標）及びＷｉｉTM、並びにＰＣベースのゲーム、に分割される。これらプラットホームの各々は、他のものとは異なり、１つのプラットホームで実行するように書かれたゲームは、別のプラットホームでは実行されない。又、装置のある世代から次の世代への互換性の問題もある。ソフトウェアゲーム開発者の大半が、特定のプラットホームとは独立して設計されたソフトウェアゲームを創作しても、特定のゲームを特定のプラットホームで実行するためには、特定のプラットホームで使用するようにゲームを適応させるのに、ソフトウェアの専有レイヤ（しばしば「ゲーム開発エンジン」と称される）が必要になる。各プラットホームは、消費者へ「コンソール」（即ち、ＴＶ又はモニタ／スピーカに取り付けられるスタンドアローンボックス）として販売されるか、或いはＰＣそれ自体である。典型的に、ビデオゲームは、精巧なリアルタイムソフトウェアアプリケーションとして実施されるビデオゲームを含むＢｌｕ−ｒａｙ ＤＶＤ、ＤＶＤ−ＲＯＭ、又はＣＤ−ＲＯＭのような光学的メディアで販売される。家庭用ブロードバンドの速度が高まるにつれて、ビデオゲームは、ダウンロードに利用されることが益々増えている。
ビデオゲームソフトウェアとのプラットホーム互換性を得るための特定の要件は、進歩型ビデオゲームのリアルタイム性及び高計算要件のために極めて厳しいものである。例えば、あるＰＣから、より速い処理ユニット又はコアをもつ別のＰＣへの製造アプリケーション（例えば、マイクロソフトワード）の一般的な互換性と同様に、ビデオゲームのある世代から次の世代への（例えば、ＸＢｏｘからＸＢｏｘ３６０への、又はＰｌａｙｓｔａｔｉｏｎ２（ＰＳ２）からＰｌａｙｓｔａｔｉｏｎ３（ＰＳ３）への）完全なゲーム互換性が期待される。しかしながら、ビデオゲームでは、このようにならない。ビデオゲームの製造者は、典型的に、あるビデオゲーム世代が発売になるときに所与の価格点に対して考えられる最高の性能を求めているので、前世代システムに対して書かれた多くのゲームが後世代システムでは機能しないような急激なアーキテクチャー変更がシステムに対してしばしばなされる。例えば、ＸＢｏｘは、プロセッサのｘ８６ファミリーをベースとしたものであり、一方、ＸＢｏｘ３６０は、ＰｏｗｅｒＰＣファミリーをベースとしたものである。
従来のアーキテクチャーをエミュレートするための技術を利用できるが、ビデオゲームがリアルタイムアプリケーションであるとすれば、エミュレーションにおいて厳密に同じ挙動を達成することはしばしば不可能である。これは、消費者、ビデオゲームコンソール製造者、及びビデオゲームソフトウェア発行者にとって損害である。消費者については、全てのゲームをプレイできるようにするために、ビデオゲームコンソールの新旧の世代をＴＶに接続したままにする必要があることを意味する。コンソールの製造者については、エミュレーションに関連したコスト、及び新規コンソールの採用に手間取ることを意味する。又、発行者については、全ての潜在的な消費者に届くように、新たなゲームの複数のバージョンを発売する必要があり、即ちビデオゲームのブランド（例えば、ＸＢｏｘ、Ｐｌａｙｓｔａｔｉｏｎ）ごとのバージョンを発売するだけでなく、所与のブランドのバージョン（例えば、ＰＳ２及びＰＳ３）ごとのバージョンをしばしば発売する必要がある。例えば、他のプラットホームの中でも、ＸＢｏｘ、ＸＢｏｘ ３６０、ＰＳ２、ＰＳ３、Ｇａｍｅｃｕｂｅ、Ｗｉｉ及びＰＣに対して、エレクトロニックアーツ“Ｍａｄｄｅｎ ＮＦＬ ０８”の個別バージョンが開発されている。
セルラー（セル）電話及びポータブルメディアプレーヤのようなポータブル装置も、ゲーム開発者への挑戦を提示する。次第に、このような装置は、ワイヤレスデータネットワークに接続されており、ビデオゲームをダウンロードできるようになっている。しかし、市場には、広範囲な異なる表示解像度及び計算能力をもつ種々様々なセル電話及びメディア装置が出回っている。又、このような装置は、典型的に、電力消費、コスト及び重量に制約があるので、カリフォルニア州サンタクララのＮＶＩＤＩＡで製造される装置、等のグラフィックプロセッシングユニット（ＧＰＵ）のような進歩型グラフィック加速ハードウェアに欠けるものである。その結果、ゲームソフトウェアの開発者は、典型的に、多数の異なる形式のポータブル装置に対して所与のゲームタイトルを同時に開発する。ユーザは、自分の特定のセル電話又はポータブルメディアプレーヤに対して所与のゲームタイトルが得られないことが分かる。
家庭用ゲームコンソールの場合には、ハードウェアプラットホームの製造者は、典型的に、彼等のプラットホームでゲームを発行する能力についてソフトウェアゲーム開発者にロイヤリティを課する。セル電話の電信会社も、典型的に、ゲームをセル電話にダウンロードするためにゲーム発行者にロイヤリティを課する。ＰＣゲームの場合には、ゲームを発行するために支払われるロイヤリティはないが、ゲームの開発者は、典型的に、生じ得る広範囲のＰＣコンフィギュレーション及びインストール問題をサポートするための消費者サービス負担が大きいために、高いコストに直面する。又、ＰＣは、典型的に、ゲームソフトウェアの海賊行為に対してバリアがほとんどない。というのは、それらは、技術的知識のあるユーザによって再プログラムが容易であり、ゲームの海賊版を容易に作成して（例えば、インターネットを通して）容易に配布することができる。従って、ソフトウェアゲーム開発者については、ゲームコンソール、セル電話及びＰＣにおいて発行する上でコストがかかり且つ欠点があることになる。
コンソール及びＰＣソフトウェアのゲーム発行者にとって、コストは、これだけでは終わらない。小売チャンネルを通してゲームを配布するために、発行者は、利ざやを得るように小売店の販売価格より低い卸売価格を課する。又、発行者は、典型的に、製造コストを支払いそしてゲームを保持する物理的メディアを配布しなければならない。又、発行者は、例えば、ゲームが売れない場合、ゲームの価格が下がった場合、或いは小売店が卸売価格の一部又は全部を払い戻し及び／又はゲームを買い手から引き取らねばならない場合に考えられる不測の事態をカバーするために小売店により「価格保護費用」がしばしば課せられる。更に、小売店は、典型的に、広告チラシでゲームを市場に出す上で助けとなるように発行者に費用を課する。更に、小売店は、ゲームをプレイし終えたユーザからゲームを買い戻して、それを中古ゲームとして販売し、典型的に、中古ゲームの収入をゲーム発行者と分配しないことが増えている。ゲーム発行者に課せられるコスト負担に加えて、しばしばゲームの海賊版が作成されてインターネットを通して配布され、ユーザがそれをダウンロードして無料でコピーする事態になっている。
インターネットのブロードバンド速度が高まりつつあり、そして米国内及び世界中で、特に、家庭や、インターネット接続ＰＣがレンタルされるインターネット「カフェー」へのブロードバンド接続がより一般的になってきているので、ゲームは、ＰＣ又はコンソールへのダウンロードを経て益々配布されてきている。又、マルチプレーヤ及び大規模マルチプレーヤのオンラインゲームをプレイするためにブロードバンド接続が益々使用されてきている（それらは、両方とも、本開示では頭文字“ＭＭＯＧ”で参照される）。これらの変更は、小売配布に関連した問題及びコストをある程度軽減する。オンラインゲームをダウンロードすることは、配布コストが典型的に僅かであり且つ売れ残りメディアからのコストがほとんど又は全くないという点で、幾つかの欠点をゲーム発行者に差し向ける。しかし、ダウンロードされたゲームは、依然、海賊行為を受け、そしてそのサイズ（しばしば数ギガバイトのサイズ）のために、ダウンロードするのに非常に長い時間を要する。更に、ポータブルコンピュータ又はビデオゲームコンソールと共に販売されるような小さなディスク装置は複数のゲームで埋め尽くされる。しかしながら、ゲーム又はＭＭＯＧがプレイ可能なゲームのためのオンライン接続を要求する程度まで、海賊版の問題は、軽減されている。というのは、ユーザが、通常、有効なユーザアカウントを有することが要求されるからである。ディスプレイスクリーンのビデオを撮影するカメラ又はスピーカからの音声を録音するマイクロホンによりコピーできるリニアメディア（例えば、ビデオ及び音楽）とは異なり、各ビデオゲームの経験は独特なものであり、簡単なビデオ／オーディオ記録を使用してコピーすることができない。従って、著作権法が強力に施行されておらず、海賊行為が横行する地域でも、ＭＭＯＧは、海賊行為から遮蔽され、それ故、ビジネスをサポートすることができる。例えば、Ｖｉｖｅｎｄｉ ＳＡの“World of Warcraft”ＭＭＯＧは、世界中にわたって海賊行為で悩まされずに首尾良く展開された。そして、多くのオンライン又はＭＭＯＧゲーム、例えば、Ｌｉｎｄｅｎ Ｌａｂの“Second Life”ＭＭＯＧは、オンラインツールを使用して資産を買い、売り、そして形成するゲームに内蔵された経済的モデルを通してゲームのオペレータのための収入を発生する。従って、従来のゲームソフトウェアの購入又は契約に加えて、メカニズムを使用して、オンラインゲームを使用するための支払をすることができる。
オンラインの性質又はＭＭＯＧにより海賊行為をしばしば軽減できるが、オンラインゲームオペレータは、依然、残りの挑戦に直面している。多くのゲームは、オンライン又はＭＭＯＧが適切に機能するために実質的なローカル（即ち、家庭内）処理リソースを要求する。ユーザは、性能の低いローカルコンピュータ（例えば、ローエンドラップトップのような、ＧＰＵをもたないもの）を有する場合に、ゲームをプレイできないことがある。更に、ゲームコンソールが古くなるにつれて、最新型から徐々に後退し、より進歩したゲームを取り扱うことができなくなる。ユーザのローカルＰＣがゲームの計算要求を取り扱いできると仮定しても、しばしばインストールの複雑さがある。ドライバの互換性がないことがある（例えば、新たなゲームがダウンロードされる場合に、グラフィックドライバの新たなバージョンがインストールされ、これは、グラフィックドライバの古いバージョンに基づく以前にインストールされたゲームを不作動にすることがある）。コンソールは、より多くのゲームがダウンロードされるにつれて、ローカルディスクスペースを使い果たす。複雑なゲームは、典型的に、バグが見つかって修理されたとき、又はゲームに変更がなされた場合に（例えば、ゲームのレベルがプレイするのに難し過ぎるか又は容易過ぎるとゲーム開発者が分かった場合に）、ゲーム開発者から時間と共にダウンロードされたパッチを受け取る。これらのパッチは、新たなダウンロードを要求する。しかし、時々、全てのユーザが全てのパッチのダウンロードを完了するのではない。他のときには、ダウンロードされたパッチが他の互換性又はディスクスペース消費の問題を導入する。
又、ゲームのプレイ中に、グラフィック又は挙動情報をローカルＰＣ又はコンソールに与えるために大きなデータダウンロードが要求されることがある。例えば、ユーザがＭＭＯＧの部屋に入り、そしてグラフィックデータで作られるか又はユーザのローカルマシンでは得られない挙動をもつシーン又はキャラクタに遭遇する場合には、そのシーン又はキャラクタのデータをダウンロードしなければならない。その結果、インターネット接続が充分に高速でない場合には、ゲームのプレイ中に実質的な遅延を招く。そして、遭遇したシーン又はキャラクタが、ローカルＰＣ又はコンソールを越えるような記憶スペース又は計算能力を要求する場合には、ユーザがゲームを進められないか又は質の低いグラフィックで続けねばならない事態を招く。従って、オンライン又はＭＭＯＧゲームは、それらの記憶及び／又は計算の複雑さの要件をしばしば制限する。更に、それらは、ゲーム中のデータ転送の量をしばしば制限する。又、オンライン又はＭＭＯＧは、ゲームをプレイできるユーザの市場を狭めることもある。
更に、技術的知識のあるユーザがゲームのローカルコピーをリバースエンジニアリングし、そしてチートできるようにゲームを変更することが次第に増えてきている。チートは、人間的に可能である以上に速くボタン押しを繰り返すのと同程度に簡単である（例えば、銃を非常に速く撃つように）。ゲーム内資産トランザクションをサポートするゲームでは、チートが、実際の経済的価値の資産を含む詐欺的トランザクションを生じるレベルの精巧さに到達する。オンライン又はＭＭＯＧ経済的モデルがそのような資産トランザクションに基づくものであるときは、これは、ゲームオペレータに実質的に有害な結果をもたらす。
新たなゲームを開発するコストは、ＰＣ及びコンソールが（例えば、リアルタイムレイトレーシングのようなより現実的なグラフィック、及びリアルタイム物理的シミュレーションのようなより現実的な挙動と共に）益々精巧なゲームを作成できるのにつれて増大している。ビデオゲーム産業の初期には、ビデオゲーム開発は、アプリケーションソフトウェア開発に非常に類似したプロセスであり、即ち開発コストの大部分は、ソフトウェアの開発であり、グラフィック、オーディオ、及び挙動エレメント又は「資産」の開発、例えば、広範囲な特殊効果をもつ動画に対して開発されるものではない。今日、多くの精巧なビデオゲーム開発努力は、ソフトウェア開発よりも、特殊効果に富んだ動画開発に厳密に似ている。例えば、多くのビデオゲームは、３Ｄ世界のシミュレーションを与え、そして益々ホトリアリスティックな（即ち、生きた動きの映像写真撮影と同程度に現実的に見えるコンピュータグラフィックの）キャラクタ、プロップ及び環境を発生する。ホトリアリスティックなゲーム開発の最も挑戦的な観点の１つは、生きた動きの人間の顔と見分けがつかないようなコンピュータ発生の人間の顔を創作することである。カリフォルニア州サンフランシスコのＭｏｖａにより開発されたＣｏｎｔｏｕｒTMリアリティキャプチャーのような顔捕獲技術は、演技者の顔の正確な形状を運動中に高い解像度で捕獲し追跡する。この技術は、捕獲された生きた動きの顔と実質上区別できない３Ｄの顔をＰＣ又はゲームコンソール上にレンダリングできるようにする。「ホトリアル」な人間の顔を捕獲してレンダリングすることは、多数の観点で有用である。第１に、非常に認識し易い有名人又はスポーツプレーヤ（多くの場合に高い費用で雇われた）がビデオゲームにしばしば使用され、不完全さがユーザにとって明らかで、視覚体験(viewing experience)を混乱させ又は不快にさせることがある。又、多くの場合に、高度のホトリアリズムを達成するには高度の細部が要求され、即ち、潜在的に、顔が動くときに多角形及び／又はテクスチャがフレームごとに変化するようにして、多数の多角形及び高解像度テクスチャをレンダリングすることが要求される。
詳細なテクスチャを伴う多数の多角形のシーンが急速に変化するときには、ゲームをサポートするＰＣ又はゲームコンソールは、ゲームセグメントで発生される所要数のアニメーションフレームに対して充分な多角形及びテクスチャデータを記憶するに足るＲＡＭを有していないことがある。更に、ＰＣ又はコンソールに典型的に利用できる単一の光学的ドライブ又は単一のディスクドライブは、通常、ＲＡＭより非常に低速であり、そして典型的に、多角形及びテクスチャをレンダリングする際にＧＰＵが受け容れられる最大データレートを維持することができない。現在のゲームは、典型的に、多角形及びテクスチャの大部分をＲＡＭにロードし、これは、所与のシーンの複雑さ及び時間巾が主としてＲＡＭの容量により制限されることを意味する。例えば、顔のアニメーションの場合に、これは、ゲームが休止して多角形及びテクスチャ（及び他のデータ）をより多くのフレームに対してロードする前に、ＰＣ又はゲームコンソールを、ホトリアルでない低解像度の顔、又は限定された数のフレームについてのみアニメ化できるホトリアルな顔、のいずれかに制限する。
“Loading...”に類似したメッセージをＰＣ又はコンソールが表示するときに進行バーがスクリーンを横切ってゆっくり移動するのを見ていることは、複雑なビデオゲームの今日のユーザによって固有の欠点として容認されている。次のシーンがディスク（ここで、「ディスク」とは、特に指示のない限り、不揮発性の光学又は磁気メディア、並びに非ディスクメディア、例えば、半導体「フラッシュ」メモリを指す）からロードする間の遅延は、数秒又は数分を要する。これは、時間の浪費であり、ゲームプレーヤにとってかなりのフラストレーションとなる。上述したように、多くの又は全ての遅延は、多角形、テクスチャ又は他のデータをディスクからロードする時間によるものであるが、ＰＣ又はコンソール内のプロセッサ及び／又はＧＰＵがシーンのためのデータを準備する間にロード時間の一部分が費やされる場合もある。例えば、サッカービデオゲームは、プレーヤが、多数の選手、チーム、スタジアム及び天候条件の中から選択を行えるようにする。従って、どんな特定の組合せが選択されるかに基づいて、異なる多角形、テクスチャ及び他のデータ（集合的に「オブジェクト」）がシーンに対して要求される（例えば、異なるチームは、そのユニホームに異なるカラー及びパターンを有する）。多数の又は全ての種々の順列を列挙し、多数の又は全てのオブジェクトを前もって予め計算し、そしてそれらオブジェクトを、ゲームを記憶するのに使用されるディスクに記憶することができる。しかし、順列の数が多い場合には、全オブジェクトに対して要求される記憶の量が、ディスクに適合するには大き過ぎる（ダウンロードするには不可能である）ことがある。従って、既存のＰＣ及びコンソールシステムは、典型的に、所与のシーンの複雑さ及びプレイ時間巾の両方について制約があり、複雑なシーンに対する長いロード時間で悩まされている。
従来のビデオゲームシステム及びアプリケーションソフトウェアシステムに伴う別の顕著な制限は、それらが、例えば、ＰＣ又はゲームコンソールへ処理のためにロードされる必要のある多角形及びテクスチャのような３Ｄオブジェクトの大きなデータベースを次第に使用してきていることである。上述したように、このようなデータベースは、ディスクにローカルに記憶されるときに長いロード時間を要する。しかしながら、ロード時間は、通常、データベースがリモート位置に記憶されそしてインターネットを通してアクセスされる場合には更に厳しいものとなる。このような状態では、大きなデータベースをダウンロードするのに、数分、数時間、又は数日を要することがある。更に、このようなデータベースは、多くの場合に多大な費用で生成され（例えば、ゲーム、映画又は歴史ドキュメンタリーに使用するための詳細な高いマスト付きの帆船の３Ｄモデル）、そしてローカルエンドユーザに販売するように意図される。しかしながら、データベースは、ローカルユーザへダウンロードされると、海賊行為を受けるおそれがある。多くの場合、ユーザは、データベースを評価してそれがユーザのニーズに合うか（例えば、ユーザが特定の動きをするときにゲームキャラクタの３Ｄコスチュームが満足な見掛け又は外観を有するか）どうか調べるだけのためにデータベースのダウンロードを希望する。長いロード時間は、購入することを決断する前に３Ｄデータベースを評価するユーザにとって妨げになる。
ＭＭＯＧでは、特に、ユーザがカスタマイズされたキャラクタを次第に使用できるようなゲームとして、同様の問題が発生する。キャラクタを表示するためのＰＣ又はゲームコンソールの場合に、３Ｄ幾何学（多角形、テクスチャ、等）のデータベースへのアクセス及びそのキャラクタに対する挙動（例えば、キャラクタが盾を有する場合に、その盾が槍をそらすに充分な強度であるかどうか）を得ることが必要である。典型的に、ＭＭＯＧがユーザにより最初にプレイされるときには、キャラクタに対する多数のデータベースが、ゲームの初期コピーと共に予め入手でき、これは、ゲームの光学的ディスクにローカルで入手できるか又はディスクへダウンロードされる。しかし、ゲームが進行するにつれて、データベースがローカルで入手できないキャラクタ又はオブジェクトにユーザが遭遇する場合には（例えば、別のユーザがカスタマイズされたキャラクタを生成した場合には）、そのキャラクタ又はオブジェクトを表示できるまでに、そのデータベースがダウンロードされねばならない。これは、ゲームの実質的な遅延を生じさせる。
ビデオゲームの精巧さ及び複雑さがあるとすれば、従来のビデオゲームコンソールでのビデオゲーム開発者及び発行者の別の挑戦は、多くの場合、数千万ドルのコストで２ないし３年を掛けてビデオゲームを開発することである。新規なビデオゲームコンソールプラットホームがほぼ５年毎に一度の割合で導入されると仮定すれば、ゲーム開発者は、新規なプラットホームが発売されるのと同時にビデオゲームを入手できるようにするために、新規なゲームコンソールの発売よりこれらゲーム年だけ前に開発作業をスタートする必要がある。ほぼ同じ時期に（例えば、互いに１年又は２年以内に）競合する製造者から多数のコンソールが時々発売されるが、調べなければならないものは、各コンソールの人気であり、例えば、どのコンソールがビデオゲームソフトウェアの最大売り上げを生じるかである。例えば、近年のコンソールサイクルでは、Ｍｉｃｒｏｓｏｆｔ ＸＢｏｘ３６０、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ３及びＮｉｎｔｅｎｄｏ Ｗｉｉがほぼ同じ一般的な時間枠で導入されるようにスケジュールされている。しかし、導入の何年か前に、ゲーム開発者は、どのコンソールプラットホームが他のものより成功するか本質的に「賭け」をし、それに応じて、開発リソースを捧げなければならない。又、動画制作会社も、映画の封切りの充分前に映画の成功の見込みの推定に基づいて限られた制作リソースを配分しなければならない。ビデオゲームに要求される投資レベルの増大を仮定すれば、ゲーム制作は、動画制作と益々類似してきており、ゲーム制作会社は、特定のビデオゲームの将来の成功の推定に基づいて制作リソースを日常的に捧げる。しかし、動画会社とは異なり、この賭けは、単に制作それ自体の成功に基づくものではなく、むしろ、ゲームの実行が意図されたゲームコンソールの成功に基づいたものである。複数のコンソールに対するゲームを一度に発売することでリスクを軽減できるが、この付加的な努力がコストを増大し、ゲームの実際の発売をしばしば遅らせる。
ＰＣにおけるアプリケーションソフトウェア及びユーザ環境は、ユーザに対してより視覚的に訴えるだけでなく、より有効で且つ直感的なものにするために、計算上より集中的で、動的で且つ双方向のものとなる。例えば、新規なＷｉｎｄｏｗｓ ＶｉｓｔａTMオペレーティングシステム、及びＭａｃｉｎｔｏｓｈ（登録商標）オペレーティングシステムの次々のバージョンは、視覚アニメーション効果を合体している。Ａｕｔｏｄｅｓｋ社からのＭａｙａTMのような進歩型グラフィックツールは、最新のＣＰＵ及びＧＰＵの限界を押し進める非常に精巧な３Ｄレンダリング及びアニメーション能力を与える。しかしながら、これら新規なツールの計算上の要件は、そのような製品のユーザ及びソフトウェア開発者にとって多数の実際上の問題を生じさせる。
オペレーティングシステム（ＯＳ）の視覚表示は、もはや販売されていないが新規なＯＳで依然アップグレード可能である前世代のコンピュータを含めて、広範囲な種類のコンピュータにおいて機能しなければならないので、ＯＳグラフィック要件は、典型的にＧＰＵを含まないコンピュータを含めたＯＳのターゲットであるコンピュータの最小公分母によって大きく制限される。これは、ＯＳのグラフィック能力を甚だしく制限する。更に、バッテリ作動式のポータブルコンピュータ（例えば、ラップトップ）は、視覚表示能力を制限する。というのは、ＣＰＵ又はＧＰＵにおける高い計算上のアクティビティが、典型的に、電力消費を高め、バッテリ寿命を短くするからである。ポータブルコンピュータは、典型的に、プロセッサが利用されないときに消費電力を下げるためにプロセッサのアクティビティを自動的に下げるソフトウェアを含む。あるコンピュータモデルでは、ユーザは、プロセッサのアクティビティを手動で下げることができる。例えば、ソニーのＶＧＮ−ＳＺ２８０Ｐラップトップは、（低性能、長バッテリ寿命のために）片側に“Ｓｔａｍｉｎａ”と表示され且つ（高性能、短バッテリ寿命のために）他側に“Ｓｐｅｅｄ”と表示されたスイッチを含む。ポータブルコンピュータで実行されるＯＳは、コンピュータがそのピーク性能能力の一部分で実行される場合でも、有用に機能することができねばならない。従って、ＯＳグラフィック性能は、入手可能な最新の計算能力より遥かに下に留まることがしばしばある。
Ｍａｙａのようなハイエンドの計算に強いアプリケーションは、高性能ＰＣに使用されるという期待でしばしば販売される。これは、典型的に、非常に高い性能と、より高価で且つ低ポータブル性の最小公分母要求を確立する。その結果、このようなアプリケーションは、汎用のＯＳ（又はＭｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅのような汎用の生産アプリケーション）より非常に限定されたターゲット視聴者を有し、典型的に、汎用のＯＳソフトウェア又は汎用のアプリケーションソフトウェアより相当に少ない量で販売される。又、多くの場合、見込みのあるユーザがこのような計算に強いアプリケーションを前もって試すことは困難であるから、潜在的な視聴者は更に限定される。例えば、学生がＭａｙａの使い方を学習することを希望し、又はこのようなアプリケーションについて既に知識のある潜在的な買い手が購入（Ｍａｙａを実行できるハイエンドコンピュータを買うことも含む）に投資する前にＭａｙａを試すことを希望すると仮定する。学生又は潜在的な買い手は、Ｍａｙａのデモバージョンをダウンロードするか又はその物理的メディアコピーを得ることはできるが、Ｍａｙａをそのフル能力（例えば、複雑な３Ｄシーンを取り扱う）で実行できるコンピュータがない場合には、製品の完全なインフォームドアセスメントを行うことができない。これは、このようなハイエンドアプリケーションの視聴者を制限するものである。又、これは、高い販売価格にも貢献する。というのは、開発コストは、通常、汎用アプリケーションより非常に少数の購入にわたって割賦されるからである。
又、高価格アプリケーションは、個人や企業がアプリケーションソフトウェアの海賊版コピーを使用する大きな誘因も生み出す。その結果、ハイエンドのアプリケーションソフトウェアは、種々の技術を通して海賊行為を軽減するためにそのようなソフトウェアの発行者による顕著な努力にも関わらず、海賊版がはびこることで悩まされている。海賊版のハイエンドのアプリケーションを使用するときでも、ユーザは、海賊版コピーを実行するために高価な最新のＰＣに投資する必要性を排除することはできない。従って、海賊版ソフトウェアのユーザは、その実際の小売価格の一部分でソフトウェアアプリケーションを使用できるが、そのアプリケーションをフルに利用するためには、高価なＰＣを購入又は入手することが依然要求される。
高性能の海賊版ビデオゲームのユーザについても同じことが言える。海賊行為者は、ゲームをそれらの実際の価格の一部分で得ることはできるが、ゲームを適切にプレイするのに必要な高価なコンピューティングハードウェア（例えば、ＧＰＵ増強型ＰＣ、又はＸＢｏｘ３６０のようなハイエンドのビデオゲームコンソール）を購入することが依然要求される。ビデオゲームが典型的に消費者にとって気晴らしであると仮定すれば、ハイエンドのビデオゲームシステムのための付加的なコストが法外なものとなる。この事態は、現在の労働者の平均年収が米国に比してかなり低い国（例えば、中国）では、一層悪いものである。その結果、ハイエンドのビデオゲームシステム又はハイエンドのＰＣを所有するのは、人口の非常に僅かな割合だけとなる。このような国々では、インターネットに接続されたコンピュータを使用するための料金をユーザが支払う「インターネットカフェ」が極めて一般的となる。多くの場合に、このようなインターネットカフェは、プレーヤが計算に強いビデオゲームをプレイできるようにするＧＰＵのような高性能特徴をもたない旧モデル又はローエンドＰＣしか有していない。これは、中国で非常に成功し、そこのインターネットカフェで一般にプレイされるＶｉｖｅｎｄｉの“World of Warcraft”のような、ローエンドＰＣで実行されるゲームの成功における重要なファクタである。それと対照的に、“Second Life”のような計算に強いゲームは、中国のインターネットカフェにインストールされたＰＣでプレイできる見込みが極めて低い。このようなゲームは、インターネットカフェの低性能ＰＣにしかアクセスできないユーザには、実質上アクセス不能である。
又、ビデオゲームの購入を考えており、先ず、インターネットを経て自分の家にゲームのデモバージョンをダウンロードすることによりそれを試してみたいユーザにとってもバリアが存在する。ビデオゲームのデモは、多くの場合、幾つかの特徴がディスエイブルされるか又はゲームのプレイ量に限度が課せられたゲームの一人前のバージョンである。これは、ＰＣ又はコンソールのいずれかにゲームをインストールして実行できるまでにギガバイトのゲームをダウンロードする長いプロセス（おそらく数時間）を伴うことがある。ＰＣの場合には、ゲームに対して必要とされる特殊なドライバ（例えば、ＤｉｒｅｃｔＸ又はＯｐｅｎＧＬドライバ）を計算し、正しいバージョンをダウンロードして、それらをインストールし、次いで、ＰＣがゲームをプレイできるかどうか決定することを含む。この後者のステップは、ＰＣが充分な処理（ＣＰＵ及びＧＰＵ）能力、充分なＲＡＭ、及び互換性のあるＯＳ（例えば、あるゲームは、Ｗｉｎｄｏｗｓ ＸＰで実行されるが、Ｖｉｓｔａでは実行されない）を有するかどうか決定することを含む。従って、ビデオゲームデモを実行するよう試みる長いプロセスの後に、ユーザは、ユーザのＰＣコンフィギュレーションを仮定すれば、ビデオゲームデモがおそらくプレイできないことを充分見出すことができる。悪いことに、ユーザが、デモを試すために新規なドライバダウンロードすると、それらのドライババージョンは、ユーザがＰＣにおいて普通に使用している他のゲーム又はアプリケーションとの互換性がないことがあり、従って、デモをインストールすると、以前に動作できたゲーム又はアプリケーションが不作動になることがある。これらのバリアは、ユーザにフラストレーションを与えるだけでなく、ゲームを市場に出すビデオゲームソフトウェア発行者及びビデオゲーム開発者にとってもバリアとなる。
経済的な非効率さを招く別の問題は、所与のＰＣ又はゲームコンソールが、通常、アプリケーション及び／又はゲームに対するあるレベルの性能要件を受け容れるように設計されていることに関する。例えば、あるＰＣは、多少のＲＡＭを有し、低速又は高速のＣＰＵを有し、そしてＧＰＵを有する場合には低速又は高速のＧＰＵを有する。あるゲーム又はアプリケーションは、所与のＰＣ又はコンソールの全計算パワーの利点を取り入れるが、多くのゲーム又はアプリケーションは、そうではない。ゲーム又はアプリケーションについてのユーザの選択が、ローカルＰＣ又はコンソールのピーク性能能力に達しない場合には、ユーザは、利用されない特徴に関してＰＣ又はコンソール上で金銭を浪費することになる。コンソールの場合には、コンソールの製造者は、コンソールコストを助成するために必要であった以上に支払ったことになる。
ビデオゲームを買って楽しむ際に存在する別の問題は、ユーザがゲームの購入を決める前に他の者がそのゲームをプレイしているのをユーザが見ることができるようにすることに関する。ビデオゲームを記録して後で再生するための多数の従来の解決策が存在する。例えば、米国特許第５，５５８，３３９号は、（同じユーザ又は異なるユーザにより所有された）ビデオゲームクライアントコンピュータでの「ゲームプレイ」中にゲームコントローラのアクションを含むゲーム情報体情報を記録することを教示している。この状態情報を後で使用して、ビデオゲームクライアントコンピュータ（例えば、ＰＣ又はコンソール）上で幾つか又は全てのゲームアクションを再生することができる。この解決策の顕著な欠点は、ユーザが記録されたゲームを見るために、ユーザは、ゲームをプレイできるビデオゲームクライアントコンピュータを所有すると共に、記録されたゲーム状態が再生されたときにゲームプレイが同一となるようにそのコンピュータ上で実行されるビデオゲームアプリケーションを有していなければならないことである。この他に、ビデオゲームアプリケーションは、記録されたゲームと再生されるゲームとの間に実行の相違がないように書かれねばならない。
例えば、ゲームグラフィックは、一般的に、フレームごとに計算される。多くのゲームの場合に、ゲームロジックは、時々、シーンが特に複雑であるかどうか、又は実行速度を下げる他の遅延があるかどうか（例えば、ＰＣにおいて、ゲームアプリケーションからＣＰＵサイクルを取り去る別のプロセスが実行されるかどうか）に基づいて、次のフレームに対して表示されるグラフィックを計算するのに１フレームより短い又は長い時間を要する。このようなゲームでは、１フレーム時間より若干短く（例えば、数ＣＰＵクロックサイクル短く）計算された「スレッシュホールド」フレームが最終的に発生する。その同じシーンが、全く同じゲーム状態情報を使用して再び計算されたときには、１フレーム時間より数ＣＰＵクロックサイクル長くかかることが容易に起きる（例えば、内部ＣＰＵバスが外部ＤＲＡＭバスと若干位相ずれし、そしてゲーム処理から数ミリ秒のＣＰＵ時間を取り去る別のプロセスによる大きな遅延がなくても、数ＣＰＵサイクルの時間遅延を導入する場合には）。それ故、ゲームが再生されるときには、フレームは、１つのフレーム時間ではなく、２つのフレーム時間で計算される。幾つかの挙動は、ゲームがどれほど頻繁に新たなフレームを計算するか（例えば、いつゲームがゲームコントローラから入力をサンプルするか）に基づいている。ゲームが表示されている間には、異なる挙動に対する時間基準のこの相違は、ゲームのプレイに影響しないが、再生されたゲームが異なる結果を生じさせることを招く。例えば、バスケットボールの弾道は、一定の６０ｆｐｓ速度で計算されるが、ゲームコントローラの入力が、計算されたフレームの速度に基づいてサンプリングされる場合には、計算されたフレームの速度は、ゲームが記録されたときは５３ｆｐｓであるが、ゲームが再生されるときは５２ｆｐｓとなり、これは、バスケットボールがバスケットへ入ることが阻止されるかどうかに差を生じさせ、異なる結果を招くことになる。従って、ゲーム状態を使用してビデオゲームを記録するには、同じゲーム状態情報を使用した再生が全く同じ結果を生じさせるよう保証するために非常に入念なゲームソフトウェア設計が要求される。
ビデオゲームを記録するための別の従来の解決策は、ＰＣ又はビデオゲームシステムのビデオ出力を（例えば、ＶＣＲ、ＤＶＤレコーダへ、又はＰＣ上のビデオ捕獲ボードへ）単に記録することである。次いで、ビデオは、巻き戻して再生することもできるし、或いは記録されたビデオを、典型的に、圧縮した後にインターネットへアップロードすることもできる。この解決策の欠点は、３Ｄゲームシーケンスが再生されるときに、ユーザは、シーケンスが記録された視点のみからシーケンスを見ることに限定されることである。換言すれば、ユーザは、シーンの視点を変更することができない。
更に、家庭用ＰＣ又はゲームコンソールで再生される記録されたゲームシーケンスの圧縮ビデオがインターネットを通して他のユーザに利用されるときには、ビデオがリアルタイムで圧縮された場合でも、その圧縮されたビデオをリアルタイムでインターネットにアップロードすることは不可能である。その理由は、インターネットに接続された世界中の多数の家庭が、極めて非対称的なブロードバンド接続を有する（例えば、ＤＳＬ及びケーブルモデムは、典型的に、アップストリーム帯域巾よりも遥かに広いダウンストリーム帯域巾を有する）からである。圧縮された高解像度ビデオシーケンスは、多くの場合に、ネットワークのアップストリーム帯域巾容量より広い帯域巾を有し、それらをリアルタイムでアップロードするのを不可能にする。従って、ゲームシーケンスが再生された後、インターネットの別のユーザがゲームを見ることができるまでに著しい遅延が生じる（おそらく数分又は数時間）。この遅延は、ある状況（例えば、以前に生じたゲームプレーヤの成績を見る）では許容できるが、ゲーム（例えば、チャンピオンプレーヤによりプレイされるバスケットボールトーナメント）を生で見る能力、又はゲームが生でプレイされるときの「瞬時再生」能力を排除する。
別の従来の解決策は、テレビジョン制作員の管理下でのみ、視聴者が、テレビ受像機でビデオゲームを生で見ることができるようにする。米国及び他の国々における幾つかのチャンネルは、ビデオゲーム視聴チャンネルを提供し、テレビ視聴者は、ビデオゲームチャンネル上で何人かのビデオゲームユーザ（例えば、トーナメントでプレイする最高評価プレーヤ）を見ることができる。これは、テレビジョンチャンネル用のビデオ配信及び処理装置へビデオゲームシステム（ＰＣ及び／又はコンソール）のビデオ出力をフィードすることにより達成される。これは、多数のカメラがバスケットボールコートの周囲で異なるアングルから生映像を送る生のバスケットボールゲームをテレビチャンネルが放送するときとは異なる。従って、テレビチャンネルは、それらのビデオ／オーディオ処理を活用して、種々のビデオゲームシステムからの出力を操作するように装置に作用することができる。例えば、テレビチャンネルは、異なるプレーヤの状態を示すテキストをビデオゲームからのビデオの上に重畳することができ（生のバスケットボールゲーム中のオーバーレイテキストであるかのように）、そしてテレビチャンネルは、ゲーム中に生じるアクションについて論じることのできるコメンテータからの音声をかぶせて録音することができる。更に、ビデオゲーム出力を、ゲームの実際のプレーヤのビデオを記録するカメラと合成することができる（例えば、ゲームに対する感情的応答を示す）。
この解決策に伴う１つの問題は、生放送の興奮を得るために、このような生のビデオフィードがテレビチャンネルのビデオ配信及び処理装置にリアルタイムで得られねばならないことである。しかしながら、上述したように、これは、ビデオゲームシステムが家庭から実行されるとき、特に、放送の一部分が、ゲームプレーヤの実世界ビデオを捕獲するカメラからの生ビデオを含む場合には、しばしば不可能である。更に、トーナメント状態において、上述したように、家庭内のゲーム遊技者がゲームを変更し及びチートする問題もある。これらの理由で、テレビチャンネルを経てのこのようなビデオゲーム放送は、プレーヤ及びビデオゲームシステムが共通の位置（例えば、テレビスタジオ又は競技場）に集合し、そこで、テレビ制作装置が多数のビデオゲームシステム及び潜在的な生カメラからのビデオフィードを受け容れることができるように、しばしば構成される。
このような従来のビデオゲームテレビチャンネルは、ビデオゲームの世界におけるアクション及び実世界におけるアクションの両方に関して、例えば、ビデオゲームプレーヤが「アスリート」として描かれるようにして、生のスポーツイベントに類似した体験である非常に興奮させる上映をテレビの視聴者に与えることができるが、これらのビデオゲームシステムは、プレーヤが互いに物理的に非常に接近した状態にしばしば限定される。そして、テレビチャンネルが放送されて以来、各放送チャンネルは、テレビチャンネルの制作員により選択された１つのビデオストリームしか示すことができない。これらの制限や、放送時間、制作装置及び制作員の高いコストのために、テレビチャンネルは、典型的に、トップトーナメントでプレイする最高評価プレーヤしか示さない。
更に、ビデオゲームのフルスクリーン映像を全テレビ視聴者に放送する所与のテレビチャンネルは、一度に１つのビデオゲームしか示さない。これは、テレビ視聴者の選択肢を甚だしく制限する。例えば、テレビ視聴者は、所与の時間に映されるゲームに関心がないことがある。別の視聴者は、所与の時間にテレビチャンネルによって特集されない特定のプレーヤのゲームプレイを見ることにしか関心がない。他のケースでは、視聴者は、専門プレーヤがゲームにおける特定のレベルをどのように取り扱うか見ることにしか関心がない。更に他の視聴者は、制作チーム等により選択されたものとは異なる、ビデオゲームを見る視点をコントロールすることを希望する。手短に言えば、テレビ視聴者は、多数の異なるテレビチャンネルが見られる場合でも、テレビネットワークの特定の放送によって受け容れられないビデオゲームを見ることに無数の好みをもっている。上述した全ての理由で、従来のビデオゲームテレビチャンネルは、テレビ視聴者にビデオゲームを示す上で著しい制限がある。
従来のビデオゲームシステム及びアプリケーションソフトウェアシステムの別の欠点は、それらが複雑であり、且つエラー、クラッシュ及び／又は意図されない及び望ましからぬ挙動（集合的に「バグ」）により通常悩まされていることである。ゲーム及びアプリケーションは、典型的に、発売までにデバッグ及びチューニングプロセス（しばしば「ソフトウェアクオリティアシュアランス」又はＳＱＡと称される）に通されるが、ほぼ常に、ゲーム又はアプリケーションがその分野の広範囲な視聴者に発売されると、バグが突然現れる。不都合なことに、ソフトウェア開発者は、発売後に多くのバグを識別して追跡することは困難である。ソフトウェア開発者がバグに気付くことは困難である。バグについて学習したときでも、何がバグを生じさせたか識別するために利用できる情報は、限られた量しかない。例えば、ユーザは、ゲーム開発者の顧客サービスラインに電話し、ゲームをプレイするときに、スクリーンがフラッシュを開始し、次いで、濃い青色に変化し、ＰＣがフリーズすることを示すメッセージを残す。これは、ＳＱＡチームに、バグを追跡するのに有用な非常に僅かな情報しか与えない。オンライン接続されたあるゲーム又はアプリケーションは、時々、幾つかのケースでは、多くの情報を与えることができる。例えば、ゲーム又はアプリケーションを「クラッシュ」について監視するために、時々「ウオッチドッグ」プロセスを使用することができる。ウオッチドッグプロセスは、ゲーム又はアプリケーションプロセスがクラッシュしたときにその状態（例えば、スタックの状態、メモリ使用状態、ゲーム又はアプリケーションがどれほど進行したか、等）に関する統計情報を収集し、次いで、その情報を、インターネットを経てＳＱＡチームへアップロードすることができる。しかし、複雑なゲーム又はアプリケーションでは、このような情報は、クラッシュ時にユーザが何を行ったか正確に決定するために解読するのに非常に長時間を要する。従って、どんな事象シーケンスがクラッシュを招いたか決定することが不可能である。
ＰＣ及びゲームコンソールに関連した更に別の問題は、消費者に相当不便をかけるサービスの問題を受けることである。又、これらサービスの問題は、ＰＣ又はゲームコンソールの製造者に影響を及ぼす。というのは、製造者は、壊れたＰＣ又はコンソールを安全に運搬するために特殊なボックスを送付し、ＰＣ又はコンソールが保証期間内である場合には修理のコストを負う必要があるからである。又、ゲーム又はアプリケーションソフトウェアの発行者は、ＰＣ及び／又はコンソールが修理の状態にあることによる販売の損失（又はオンラインサービス使用）によっても影響を受ける。
図１は、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）３、Ｍｉｃｒｏｓｏｆｔ ＸＢｏｘ ３６０（登録商標）、Ｎｉｎｔｅｎｄｏ ＷｉｉTM、Ｗｉｎｄｏｗベースのパーソナルコンピュータ、又はＡｐｐｌｅ Ｍａｃｉｎｔｏｓｈのような従来のビデオゲームシステムを示す。これらシステムは、各々、プログラムコードを実行するための中央処理ユニット（ＣＰＵ）、典型的に、進歩型グラフィックオペレーションを遂行するためのグラフィック処理ユニット（ＧＰＵ）、並びに外部装置及びユーザと通信するための複数の形態の入力／出力（Ｉ／Ｏ）を備えている。簡単化のために、これらのコンポーネントは、単一のユニット１００として一緒に結合されて示されている。又、図１の従来のビデオゲームシステムは、光学的メディアドライブ１０４（例えば、ＤＶＤ−ＲＯＭドライブ）、ビデオゲームのプログラムコード及びデータを記憶するためのハードドライブ１０３、マルチプレーヤゲームをプレイし、ゲーム、パッチ、デモ又は他のメディアをダウンロードするためのネットワーク接続１０５、ＣＰＵ／ＧＰＵ１００により現在実行されているプログラムコードを記憶するためのランダムアクセスメモリ（ＲＡＭ）１０１、ゲームプレイ中にユーザからの入力コマンドを受け取るためのゲームコントローラ１０６、及びディスプレイ装置１０２（例えば、ＳＤＴＶ／ＨＤＴＶ又はコンピュータモニタ）を含むように示されている。
図１に示す従来のシステムは、多数の制限で悩まされている。第１に、光学的ドライブ１０４及びハードドライブ１０３は、ＲＡＭ１０１に比して非常に低速のアクセス速度を有する傾向がある。ＲＡＭ１０１を通して直接機能するときには、ＣＰＵ／ＧＰＵ１００は、実際に、プログラムコード及びデータがハードドライブ１０３又は光学ドライブ１０４から直接読み取られるときに可能であるより遥かに多くの多角形を毎秒処理することができる。というのは、ＲＡＭ１０１は、一般的に、帯域巾が非常に広く、ディスクメカニズムの比較的長いシーク遅延で悩まされないからである。しかし、これら従来システムでは、限定された量のＲＡＭしか設けられていない（例えば、２５６−５１２Ｍバイト）。それ故、ビデオゲームの次のシーケンスのためのデータでＲＡＭ１０１が周期的に埋められる“Ｌｏａｄｉｎｇ．．．”シーケンスがしばしば要求される。
あるシステムは、ゲームプレイと同時にプログラムコードのローディングを重畳させるように試みているが、これは、既知の事象シーケンスがあるときしか行うことができない（例えば、車を運転して道路を下る場合に、車を運転しながら、路傍にある接近してくるビルの幾何学形状をロードすることができる）。複雑で及び／又は急速なシーンの変化については、この形式の重畳は、通常、機能しない。例えば、ユーザが戦いの最中であり、そしてその瞬間に視野内のオブジェクトを表すデータでＲＡＭ１０１が完全に埋められるケースでは、ＲＡＭ１０１に現在ロードされていないオブジェクトを見るためにユーザが視野を素早く左へ動かした場合に、アクションの不連続状態が生じる。というのは、ハードドライブ１０３又は光学的メディア１０４から新たなオブジェクトをＲＡＭ１０１へロードするに充分な時間がないからである。
図１のシステムでは、ハードドライブ１０３及び光学的メディア１０４の記憶容量に制限があるために別の問題が生じる。比較的大きな記憶容量（例えば、５０ギガバイト以上）をもつディスク記憶装置を製造することはできるが、現在ビデオゲームで遭遇する幾つかのシーンについて充分な記憶容量をまだ与えることができない。例えば、上述したように、サッカーのビデオゲームは、世界中の多数のチーム、プレーヤ及びスタジアムの中からユーザが選択を行えるようにする。各チーム、各プレーヤ及び各スタジアムに対して、世界中の３Ｄ曲面を特徴付けるには非常に多数のテクスチャマップ及び環境マップが要求される（例えば、各チームが独特のジャージを有し、その各々が独特のテクスチャマップを要求する）。
この後者の問題に対処するために使用される１つの技術は、ユーザによってテクスチャ及び環境マップが選択されたときにゲームがそれらを予め計算することである。これは、映像の解凍、３Ｄマッピング、シェーディング、データ構造の編成、等を含めて、多数の計算上強いプロセスを含むことがある。その結果、ビデオゲームがこれらの計算を遂行する間にユーザにとって遅延が生じ得る。この遅延を減少するための１つの方法は、原理的に、ゲームが最初に開発されたときに、チーム、プレーヤ名簿及びスタジアムの各順列を含めて、これら計算の全てを遂行することである。従って、ゲームの発売バージョンは、光学的メディア１０４、又はインターネット上の１つ以上のサーバーに記憶された全てのこの前処理されたデータを、ユーザが選択を行うときにインターネットを通してハードドライブ１０３へダウンロードされる所与のチーム、プレーヤ名簿、スタジアム選択のための選択された前処理されたデータと共に含む。しかしながら、実際上の問題として、ゲームプレイにおいて考えられる各順列のこのような予めロードされるデータは、多分、今日の光学的メディア装置の容量を遥かに越えるテラバイトのデータになってしまう。更に、所与のチーム、プレーヤ名簿、スタジアム選択のためのデータは、多分、数百メガバイト以上のデータになってしまう。例えば、１０Ｍｂｐｓの家庭用ネットワーク接続では、ネットワーク接続１０５を通してこのデータをダウンロードするのに、データをローカルで計算する以上の時間を要することになる。
従って、図１に示す従来のゲームアーキテクチャーは、複雑なゲームの主要シーン移行間にユーザに著しい遅延を受けさせる。
図１に示す従来の解決策に伴う別の問題は、年々、ビデオゲームがより進歩する傾向にあり、より高いＣＰＵ／ＧＰＵパワーを要求することである。従って、限定された量のＲＡＭを仮定しても、ビデオゲームハードウェアの要件は、これらシステムに得られる処理パワーのピークレベルを越えてしまう。その結果、ユーザは、歩調を合わせるためにゲームハードウェアを数年毎にアップグレードする必要がある（又は新たなゲームを質の低いレベルでプレイする）。ビデオゲームが絶えず進歩する傾向の１つの結果として、家庭で使用するためのビデオゲームプレイマシンは、典型的に、それらのコストが、通常、サポートできる最高性能ゲームの要件により決定されるので、経済的に効率が悪い。例えば、ＸＢｏｘ ３６０は、高性能ＣＰＵ、ＧＰＵ、及び数百メガバイトのＲＡＭを必要とする“Gears of War”のようなゲームをプレイするのに使用されるか、又はＸＢｏｘ ３６０は、数キロバイトのＲＡＭ及び非常に低性能のＣＰＵしか要求しない１９７０年代のゲームであるＰａｃ Ｍａｎをプレイするのに使用される。実際に、ＸＢｏｘ ３６０は、Ｐａｃ Ｍａｎゲームを一度に多数同時にホストするに充分な計算パワーを有している。
ビデオゲームマシンは、典型的に、一週間のほとんどの時間中オフにされている。１３年以上経った現役ゲームに関するニールセン・エンターテーメント・スタディ２００６年７月号によれば、平均で、現役のゲームは、毎週１４時間をコンソールビデオゲームのプレイに費やしており、即ち一週間の合計時間の１２％に過ぎない。これは、平均でビデオゲームコンソールが８８％の時間アイドル状態であり、高価なリソースの使用効率が悪いことを意味する。購入価格を下げるためにビデオゲームコンソールが製造者によりしばしば助成されると仮定すれば（その助成金が将来のビデオゲームソフトウェアの購入からのロイヤリティにより還元されることを期待して）、これは、特に意義深いことである。
又、ビデオゲームコンソールは、ほとんどの消費者電子装置に関連したコストを負っている。例えば、システムの電子装置及びメカニズムは、エンクロージャ内に収容する必要がある。製造者は、修理保証を提供する必要がある。システムを販売する小売店は、システムの販売及び／又はビデオゲームソフトウェアの販売において利ざやを収集する必要がある。これらのファクタは、全てビデオゲームコンソールのコストに追加され、これは、製造者によって助成されねばならないか、消費者へ回されるか、又はその両方である。
更に、ビデオゲーム産業にとって海賊版が主たる問題である。実質上全ての主要ビデオゲームシステムに使用されるセキュリティメカニズムは、年々「クラック」されて、ビデオゲームの無断コピーが取られている。例えば、ＸＢｏｘ ３６０のセキュリティシステムは、２００６年７月にクラックされ、ユーザは、今や、不正コピーをオンラインでダウンロードすることができる。ダウンロード可能なゲーム（例えば、ＰＣ又はＭａｃ用のゲーム）は、特に海賊行為を受け易い。海賊行為の取り締まりが弱い世界のある地域では、スタンドアローンビデオゲームソフトウェアのための成功が見込める市場が本質的にない。というのは、ユーザが海賊版コピーを合法的コピーと同程度に容易にそのコストのほんの一部分で買えるからである。又、世界の多くの地域では、ゲームコンソールのコストが収入の高い割合であり、海賊版を取り締まっても、最新のゲームシステムを買う余裕がある人は僅かに過ぎない。
更に、中古ゲーム市場は、ビデオゲーム産業の収入を減少させる。ユーザは、ゲームに飽きると、ゲームを店に売ることができ、店は、ゲームを他のユーザに再販売する。この無許可であるが一般的な慣習は、ゲーム発行者の収入を著しく減少させる。同様に、数年毎にプラットホームの移行があるときには、通常、５０％の販売量低下が生じる。これは、ユーザが、新規バージョンプラットホームが発売されようとしていることを知ると、旧型プラットホーム用のゲームの購入を止める（例えば、Ｐｌａｙｓｔａｔｉｏｎ３が発売されようとしているときに、ユーザは、Ｐｌａｙｓｔａｔｉｏｎ２のゲームの購入を止める）からである。新規のプラットホームに関連した販売の損失及び開発コストの増加が相まって、ゲーム開発者の利益に非常に大きな影響が及ぶことになる。
又、新規なゲームコンソールは、非常に高価である。ＸＢｏｘ ３６０、Ｎｉｎｔｅｎｄｏ Ｗｉｉ、及びＳｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ３は、全て、数百ドルで小売される。ハイパワーのパーソナルコンピュータゲームシステムは、その価格が＄８０００までである。これは、特に、ハードウェアが数年後に旧式となり且つ多くのシステムが子供のために購入されることを考えると、ユーザにとって著しい投資を表す。
以上の問題に対する１つの解決策は、ゲームプログラムコード及びデータがサーバーにホストされそしてオンデマンドでクライアントマシンへデジタルブロードバンドネットワークを経てストリーミングされる圧縮されたビデオ及びオーディオとして配信されるオンラインゲームである。フィンランドのＧ−Ｃｌｕｓｔｅｒ（現在では、日本のソフトバンクブロードメディアの子会社）のような幾つかの会社は、これらのサービスをオンラインで提供する。同様のゲームサービスが、ホテル内にあるようなローカルネットワークにおいて利用でき、ＤＳＬ及びケーブルテレビジョンプロバイダーによって提供されている。これらシステムの主たる欠点は、待ち時間(latency)、即ちオペレータの「ヘッドエンド」に典型的に配置されたゲームサーバーへ信号が進み且つそこから進むのに要する時間の問題である。高速アクションビデオゲーム（「ツイッチ」ビデオゲームとしても知られている）は、ユーザがゲームコントローラでアクションを遂行する時間と、ディスプレイスクリーンが更新されてユーザアクションの結果を示す時間との間に非常に短い待ち時間を要求する。ゲームが「即座」に応答するという感覚をユーザがもつようにするため、短い待ち時間が必要とされる。ユーザは、ゲームの形式及びユーザの熟練度レベルに基づいて異なる待ち時間間隔で満足することができる。例えば、ゆっくりしたカジュアルなゲーム（バックギャモンのような）又は低速アクションの役割を演じるゲームについては１００ｍｓの待ち時間が許容できるが、高速アクションゲームでは、待ち時間が７０又は８０ｍｓを越えると、ユーザは、ゲームにおいて演技が不充分となり、受け容れられない。例えば、高速反応時間を要求するゲームでは、待ち時間が５０から１００ｍｓへ増加するにつれて、精度が鋭く低下する。
ゲーム又はアプリケーションサーバーが、近傍のコントロールされたネットワーク環境にインストールされるか、又はユーザへのネットワーク経路が予想可能で及び／又は帯域巾ピークを許容できる環境にインストールされるときには、最大待ち時間と、待ち時間の一貫性の両方について、待ち時間をコントロールすることが遥かに容易である（例えば、ユーザがネットワークを通してストリーミングするデジタルビデオから一定の動きを観察するように）。このようなレベルのコントロールは、ケーブルＴＶネットワークのヘッドエンドとケーブルＴＶ加入者の家庭との間、又はＤＳＬ中央オフィスからＤＳＬ加入者の家庭までの間、或いはサーバー又はユーザからの商業的オフィスのローカルエリアネットワーク（ＬＡＮ）環境において、達成することができる。又、保証された帯域巾及び待ち時間を有する会社間に特殊グレードのポイント対ポイントプライベート接続を得ることができる。しかし、一般的なインターネットに接続されたサーバーセンターにおいてゲームをホストし、次いで、ブロードバンド接続を経てユーザへ圧縮ビデオをストリーミングするゲーム又はアプリケーションシステムでは、多数のファクタから待ち時間を招き、従来システムの展開に甚だしい制限を生じさせる。
典型的なブロードバンド接続の家庭では、ユーザは、ブロードバンドサービスのためにＤＳＬ又はケーブルモデムをもつことができる。このようなブロードバンドサービスは、通常、ユーザの家庭と一般的なインターネットとの間に２５ｍｓ程度（時々はそれ以上の）の往復待ち時間を被る。更に、インターネットを経てサーバーセンターへデータをルーティングすることからも往復遅延を被る。インターネットを通しての待ち時間は、データが与えられるルート及びそれがルーティングされるときに被る遅延に基づいて変化する。ルーティング遅延に加えて、ほとんどのインターネットを相互接続する光ファイバを経て進む光の速度のために、往復遅延も被る。例えば、１０００マイルごとに、光ファイバを通る光の速度及び他のオーバーヘッドのために、約２２ｍｓの往復待ち時間を被る。
インターネットを経てストリーミングされるデータのデータレートのために、付加的な待ち時間が生じる。例えば、ユーザが「６Ｍｂｐｓ ＤＳＬサービス」として販売されるＤＳＬサービスを有する場合に、実際に、ユーザは、おそらく、せいぜい５Ｍｂｐｓ未満のダウンストリームスループットしか得ず、そしておそらく、デジタルサブスクライバーラインアクセスマルチプレクサ（ＤＳＬＡＭ）におけるピークロード時間中の混雑のような種々のファクタのために、接続の質低下を周期的に見ることになる。又、ケーブルモデムシステムネットワークにおける隣接部又は他のどこかを経てループされるローカル共有同軸ケーブルに混雑が生じる場合には、「６Ｍｂｐｓケーブルモデムサービス」として販売される接続に使用されるケーブルモデムのデータレートを遥かに低く減少する同様の問題が発生する。４Ｍｂｐｓの一定レートでのデータパケットがサーバーセンターからこのような接続を経てユーザデータグラムプロトコル（ＵＤＰ）フォーマットで一方向としてストリーミングされる場合には、全てがうまく機能すれば、データパケットが、付加的な待ち時間を被ることなく通過するが、混雑（又は他の障害）が存在し且つユーザへデータをストリーミングするのに３．５Ｍｂｐｓしか利用できない場合には、典型的な状態において、パケットがドロップされてデータロスを生じるか、又はパケットを送ることができるまで混雑点にパケットがキューイングされて付加的な待ち時間を招くか、のいずれかである。異なる混雑点は、遅延パケットを保持する異なるキューイング容量を有し、従って、あるケースでは、混雑を通過できないパケットが直ちにドロップされる。他のケースでは、数メガビットのデータがキューイングされ、最終的に、送出される。しかし、ほぼ全てのケースにおいて、混雑点におけるキューは、容量限界があり、これらの限界を越えると、キューがオーバーフローし、パケットがドロップされる。従って、付加的な待ち時間（又は更に悪い場合は、パケットのロス）を被るのを回避するために、ゲーム又はアプリケーションサーバーからユーザへのデータレート容量を越えないようにする必要がある。
又、サーバーにおいてビデオを圧縮しそしてクライアント装置においてビデオを解凍するのに要求される時間によっても待ち時間を被る。更に、サーバー上で実行されているビデオゲームが、表示されるべき次のフレームを計算する間にも待ち時間を被る。現在入手できるビデオ圧縮アルゴリズムは、高いデータレート又は長い待ち時間のいずれかで悩まされている。例えば、モーションＪＰＥＧは、待ち時間が短いことを特徴とするイントラフレーム専用ロッシー(intra frame-only lossy)圧縮アルゴリズムである。各ビデオフレームは、互いのビデオフレームと独立して圧縮される。クライアント装置は、圧縮されたモーションＪＰＥＧビデオのフレームを受け取ると、そのフレームを直ちに解凍して表示し、待ち時間を非常に短くする。しかし、各フレームは、別々に圧縮されるので、アルゴリズムは、連続するフレーム間の類似性を利用することができず、その結果、イントラフレーム専用ビデオ圧縮アルゴリズムは、非常に高いデータレートで悩まされている。例えば、６０ｆｐｓ（フレーム／秒）６４０ｘ４８０モーションＪＰＥＧビデオは、４０Ｍｂｐｓ（メガビット／秒）以上のデータを要求する。このように低い解像度のビデオウインドウに対するこのように高いデータレートは、多くのブロードバンドアプリケーションにおいて（及び確実にほとんどの消費者インターネットベースのアプリケーションに対して）法外に高価なものとなる。更に、各フレームは独立して圧縮されるので、ロッシー圧縮から生じ得るフレーム内の欠陥は、おそらく、連続するフレームの異なる場所に現れる。これは、ビデオが解凍されたときに、動く視覚上の欠陥として視聴者に見える。
マイクロソフト社からのＭＰＥＧ２、Ｈ．２６４、又はＶＣ９のような他の圧縮アルゴリズムは、従来の構成で使用されたときに、高い圧縮比を達成できるが、長い待ち時間が犠牲となる。このようなアルゴリズムは、インターフレーム及びイントラフレームの圧縮を使用する。周期的に、このようなアルゴリズムは、フレームのイントラフレーム専用圧縮を遂行する。このようなフレームは、キーフレーム（典型的に“Ｉ”フレームと称される）として知られている。次いで、これらのアルゴリズムは、典型的に、Ｉフレームを手前のフレーム及び連続するフレームの両方と比較する。手前のフレーム及び連続するフレームを独立して圧縮するのではなく、このアルゴリズムは、Ｉフレームから手前のフレーム及び連続するフレームへと映像の何が変化したか決定し、次いで、それらの変化を、Ｉフレームに先行する変化については“Ｂ”フレームとして、及びＩフレームに続く変化については“Ｐ”フレームとして記憶する。これは、イントラフレーム専用圧縮よりも非常にゆっくりしたデータレートを生じさせる。しかし、これは、典型的に、長い待ち時間を犠牲とする。Ｉフレームは、典型的に、Ｂ又はＰフレームより非常に大きく（しばしば１０倍以上）、その結果、所与のデータレートで送信するのに比例的に長い時間を要する。
例えば、Ｉフレームが、Ｂ及びＰフレームのサイズの１０倍であり、単一のＩイントラフレームごとに２９個のＢフレーム＋３０個のＰフレーム＝５９個のインターフレームがあるか、又は「フレームグループ（ＧＯＰ）」ごとに合計６０個のフレームがある状態を考える。従って、６０ｆｐｓでは、毎秒１つの６０フレームＧＯＰがある。送信チャンネルが２Ｍｂｐｓの最大データレートを有すると仮定する。チャンネルに最高クオリティのビデオを得るために、圧縮アルゴリズムは、２Ｍｂｐｓのデータストリームを発生し、上述した比を仮定すれば、これは、２メガビット（Ｍｂ）／（５９＋１０）＝３０，３９４ビット／イントラフレーム及び３０３，９３５ビット／Ｉフレームを生じさせる。圧縮されたビデオストリームが解凍アルゴリズムによって受信されるときには、ビデオを着実にプレイするために、各フレームを規則的な間隔（例えば、６０ｆｐｓ）で解凍して表示する必要がある。この結果を得るために、フレームが送信待ち時間を受ける場合には、全てのフレームを少なくともその待ち時間だけ遅延する必要があり、従って、最悪のケースのフレーム待ち時間は、各ビデオフレームに対する待ち時間を定義する。Ｉフレームは、最も大きなものであるから、最長の送信待ち時間を導入し、Ｉフレームを解凍して表示できるまでにＩフレーム全体を受信しなければならない（又はインターフレームがＩフレームに依存する）。チャンネルデータレートが２Ｍｂｐｓであると仮定すれば、Ｉフレームを送信するのに、３０３，９３５／２Ｍｂ＝１４５ｍｓを要することになる。
送信チャンネルの帯域巾の大部分を使用する上述したインターフレームビデオ圧縮システムは、フレームの平均サイズに対してＩフレームのサイズが大きいために長い待ち時間を受けることになる。又は、換言すれば、従来のインターフレーム圧縮アルゴリズムは、イントラフレーム専用圧縮アルゴリズムより低いフレーム当たり平均データレートを達成するが（例えば、２Ｍｂｐｓ対４０Ｍｂｐｓ）、大きなＩフレームのために、依然、高いフレーム当たりピークデータレートで悩まされている（例えば、３０３，９３５＊６０＝１８．２Ｍｂｐｓ）。前記分析は、Ｐ及びＢの両フレームがＩフレームより非常に小さいと仮定していることを銘記されたい。これは、一般的には、真であるが、高い映像複雑さが手前のフレーム、高モーション又はシーンの変化に相関していないフレームについては真ではない。このような状態では、Ｐ又はＢフレームがＩフレームと同程度の大きさになる（Ｐ又はＢフレームがＩフレームより大きくなると、精巧な圧縮アルゴリズムが、典型的に、Ｉフレームを「強制(force)」し、そしてＰ又はＢフレームをＩフレームに置き換える）。従って、デジタルビデオストリームには、いつでも、Ｉフレームサイズのデータレートピークが生じる。従って、圧縮されたビデオでは、平均ビデオデータレートが送信チャンネルのデータレート容量に接近するときに（ビデオに対する高いデータレート要求を仮定すると、しばしばそうである）、Ｉフレーム或いは大きなＰ又はＢフレームからの高いピークデータレートが長いフレーム待ち時間を生じさせる。
もちろん、以上の説明は、ＧＯＰにおける大きなＢ、Ｐ又はＩフレームによって生じる圧縮アルゴリズムの待ち時間を特徴付けるに過ぎない。Ｂフレームが使用される場合は、待ち時間がより長くなる。その理由は、Ｂフレームを表示できるまでに、Ｂフレーム及びＩフレーム後の全てのＢフレームを受信しなければならないからである。従って、各Ｉフレームの前に５個のＢフレームがあるＢＢＢＢＢＩＰＰＰＰＰＢＢＢＢＢＩＰＰＰＰＰのような画像グループ（ＧＯＰ）シーケンスにおいて、最初のＢフレームは、その後のＢフレーム及びＩフレームが受信されるまでビデオデコンプレッサによって表示することができない。従って、ビデオが６０ｆｐｓ（即ち、１６．６７ｍｓ／フレーム）でストリーミングされる場合には、最初のＢフレームを解凍できるまでに、チャンネル帯域巾がどれほど速くても、５個のＢフレーム及びＩフレームは、受信するのに１６．６７＊６＝１００ｍｓを要し、これは、ちょうど、５個のＢフレームである。３０個のＢフレームをもつ圧縮されたビデオシーケンスは、極めて一般的である。そして、２Ｍｂｐｓのような低いチャンネル帯域巾では、Ｉフレームのサイズにより生じる待ち時間の影響が、主として、Ｂフレームが到着するのを待機することによる待ち時間の影響に加えられる。従って、２Ｍｂｐｓチャンネルにおいて、非常に多数のＢフレームがある状態では、従来のビデオ圧縮技術を使用して、５００ｍｓ以上の待ち時間を越えるのは極めて容易である。Ｂフレームが使用されない（所与のクオリティレベルに対して低い圧縮比を犠牲にして）場合には、Ｂフレームの待ち時間を被らないが、上述したピークフレームサイズにより生じる待ち時間は、依然、被る。
この問題は、まさに多数のビデオゲームの性質により激化される。上述したＧＯＰ構造を使用するビデオ圧縮アルゴリズムは、主として、受動的な視聴に意図された生のビデオ又は動画資料で、使用上最適化されている。典型的に、カメラ（実際のカメラであるか、コンピュータ発生アニメーションの場合のバーチャルカメラであるかに関わらず）、及びシーンは、比較的安定である。というのは、単に、カメラ又はシーンがあまりに急に動く場合に、ビデオ又は映画資料が、（ａ）典型的に見るのに不快であり、そして（ｂ）それを見る場合に、カメラが突然グイと動くときに、通常、視聴者がアクションを厳密に追従できないからである（例えば、バースディケーキのキャンドルに息を吹きかける子供を撮影するときにカメラがバンプされ、そして突然ケーキから離れて戻るようにグイと動かされる場合に、視聴者は、典型的に、子供及びケーキに集中し、カメラが突然動くときの短い中断は無視する）。ビデオのインタビュー又はビデオ遠隔会議のケースでは、カメラを固定位置に保持して、全く動かさず、非常に僅かなデータピークしか生じさせない。しかし、３Ｄ高アクションビデオゲームは、一定の動きにより特徴付けられる（例えば、レースの期間中に全フレームが迅速な動きにあるような３Ｄレースを考えるか、又はバーチャルカメラが常にグイと動くようなファーストパーソンシューター(first-person shooter)を考える）。このようなビデオゲームは、これらの突然の動きの間に何が起きたかユーザがはっきり見る必要があるところの大きなそして頻繁なピークを伴うフレームシーケンスを生じさせる。従って、３Ｄ高アクションビデオゲームでは、圧縮欠陥は、ほとんど許容できない。従って、多くのビデオゲームのビデオ出力は、それらの性質により、非常に高く且つ頻繁なピークをもつ圧縮ビデオストリームを発生する。
高速アクションビデオゲームのユーザが長い待ち時間に対してあまり寛容度がないと仮定し、又、上述した全ての待ち時間の原因を仮定すれば、今日まで、インターネットを経てビデオをストリーミングするサーバーホスト型ビデオゲームには制限があった。更に、高度の双方向性を要求するアプリケーションのユーザは、そのアプリケーションが一般的なインターネット及びストリームビデオでホストされる場合には、同様に制限で悩まされている。このようなサービスは、ホスティングサーバーが、商業的な設定において、ヘッドエンド（ケーブルブロードバンドの場合）、又は中央オフィス（デジタルサブスクライバーライン（ＤＳＬ）の場合）、或いはＬＡＮ（又は特殊グレードのプライベート接続）内に直接設定されて、クライアント装置からサーバーへのルート及び距離が待ち時間を最小にするように制御され、且つ待ち時間を被ることなくピークを受け容れできるようなネットワークコンフィギュレーションを要求する。ＬＡＮ（典型的に１００Ｍｂｐｓから１Ｇｂｐｓ定格）及び充分な帯域巾の賃貸ラインは、典型的に、ピーク帯域巾要求をサポートすることができる（例えば、１８Ｍｂｐｓのピーク帯域巾は、１００ＭｂｐｓのＬＡＮ容量の小部分である）。
又、ピーク帯域巾要求は、特殊な受け容れがなされる場合には、住居用ブロードバンドインフラストラクチャーにより受け容れることができる。例えば、ケーブルＴＶシステムでは、デジタルビデオトラフィックに、大きなＩフレームのようなピークを取り扱うことのできる専用帯域巾が与えられる。そしてＤＳＬシステムでは、高速ＤＳＬモデムを準備して、高いピークを許すことができるか、又は高いデータレートを取り扱うことのできる特殊グレードの接続を準備することができる。しかし、一般的なインターネットに取り付けられる従来のケーブルモデム及びＤＳＬインフラストラクチャーは、圧縮ビデオのピーク帯域要件に対して遥かに低い寛容度しか有していない。従って、クライアント装置から長距離にあるサーバーセンターにおいてビデオゲーム又はアプリケーションをホストし、次いで、インターネットを経て従来の住居用ブロードバンド接続を通して圧縮ビデオ出力をストリーミングするオンラインサービスは、特に、非常に短い待ち時間を要求するゲーム及びアプリケーション（例えば、ファーストパーソンシューター及び他のマルチユーザ双方向アクションゲーム、又は高速応答時間を要求するアプリケーション）に関して、顕著な待ち時間及びピーク帯域巾制限で悩まされている。
本開示は、添付図面及び以下の詳細な説明から、より完全に理解されよう。しかしながら、ここに開示した要旨は、本発明を例示するものに過ぎず、ここに示す特定の実施形態に限定されるものではない。
従来のビデオゲームシステムのアーキテクチャーを示す。 一実施形態による高レベルシステムアーキテクチャーを示す。 一実施形態による高レベルシステムアーキテクチャーを示す。 クライアントとサーバーとの間の通信に対する実際のデータレート、定格データレート、及び要求されるデータレートを示す。 一実施形態により使用されたホスティングサービス及びクライアントを示す。 クライアントとホスティングサービスとの間の通信に関連した例示的待ち時間を示す。 一実施形態によるクライアント装置を示す。 別の実施形態によるクライアント装置を示す。 図４ｃのクライアント装置のブロック図である。 図４ｄのクライアント装置のブロック図である。 一実施形態により使用できるビデオ圧縮の一形式を例示する。 別の実施形態に使用できるビデオ圧縮の一形式を例示する。 低い複雑さ、低アクションのビデオシーケンスの送信に関連したデータレートのピークを示す。 高い複雑さ、高アクションのビデオシーケンスの送信に関連したデータレートのピークを示す。 一実施形態に使用されるビデオ圧縮技術を示す。 一実施形態に使用されるビデオ圧縮技術を示す。 一実施形態に使用される付加的なビデオ圧縮技術を示す。 データレートピークを緩和するために一実施形態に使用される技術を示す。 データレートピークを緩和するために一実施形態に使用される技術を示す。 データレートピークを緩和するために一実施形態に使用される技術を示す。 映像タイルをパケット内に効率的にパックする一実施形態を示す。 映像タイルをパケット内に効率的にパックする一実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 圧縮のためのマルチコア処理ユニットを示す一実施形態を示す。 実施形態による地理的ポジショニング及びホスティングサービス間の通信を示す。 実施形態による地理的ポジショニング及びホスティングサービス間の通信を示す。 クライアントとホスティングサービスとの間の通信に関連した待ち時間を例示する。 ホスティングサービスのサーバーセンターアーキテクチャーを示す。 複数の生のビデオウインドウを含むユーザインターフェイスの一実施形態のスクリーンショットを例示する。 特定のビデオウインドウを選択した後の図１６のユーザインターフェイスを示す。 特定のビデオウインドウをフルスクリーンサイズへズーミングした後の図１７のユーザインターフェイスを示す。 マルチプレーヤゲームのスクリーンにオーバーレイされる共同ユーザビデオデータを例示する。 ホスティングサービスにおけるゲームプレーヤのためのユーザページを例示する。 ３Ｄ双方向広告を例示する。 生の演技の表面捕獲からのテクスチャ処理表面を有するホトリアルな映像を発生するための一連のステップを例示する。 リニアメディアコンテンツの選択を許すユーザインターフェイスページを例示する。 ウェブページが生である前に経過する時間長さを接続速度に対して示すグラフである。
以下の説明では、本開示を完全に理解するために、装置の形式、システムコンフィギュレーション、通信方法、等の特定の細部について述べる。しかしながら、当業者であれば、ここに述べる実施形態を具現化するのに、これらの特定の細部は必要ないことが明らかであろう。
図２ａ−ｂは、ビデオゲーム及びソフトウェアアプリケーションが、契約サービスのもとでインターネット２０６（或いは他のパブリック又はプライベートネットワーク）を経てユーザの家屋２１１（「ユーザの家屋」とは、ユーザが所在する場所を意味し、移動装置を使用する場合には屋外も含む）においてホスティングサービス２１０によりホストされそしてクライアント装置２０５によりアクセスされるような２つの実施形態の高レベルアーキテクチャーを示す。クライアント装置２０５は、内部又は外部ディスプレイ装置２２２を有していてインターネットにワイヤード又はワイヤレス接続されるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ又はＬｉｎｕｘベースのＰＣ又はＡｐｐｌｅ社のＭａｃｉｎｔｏｓｈコンピュータのような汎用コンピュータでもよいし、又はビデオ及びオーディオをモニタ又はＴＶ受像機２２２へ出力するセットトップボックス（インターネットにワイヤード又はワイヤレス接続される）のような専用クライアント装置でもよいし、或いはおそらくインターネットにワイヤレス接続される移動装置でもよい。
これらの装置は、いずれも、それ自身のユーザ入力装置（例えば、キーボード、ボタン、タッチスクリーン、トラックパッド又は慣性感知棒、ビデオ捕獲カメラ及び／又は運動追跡カメラ、等）を有してもよいし、又は有線又は無線で接続された外部入力装置２２１（例えば、キーボード、マウス、ゲームコントローラ、慣性感知棒、ビデオ捕獲カメラ、及び／又は運動追跡カメラ、等）を使用してもよい。以下に詳細に述べるように、ホスティングサービス２１０は、高パワーのＣＰＵ／ＧＰＵ処理能力を伴うものを含めて、種々の性能レベルのサーバーを含む。ゲームのプレイ中、又はホスティングサービス２１０におけるアプリケーションの使用中に、家庭又はオフィス用のクライアント装置２０５は、ユーザからのキーボード及び／又はコントローラ入力を受け取り、次いで、インターネット２０６を通してホスティングサービス２１０へコントローラ入力を送信し、このホスティングサービス２１０は、それに応答してゲームプログラムを実行し、そしてゲーム又はアプリケーションソフトウェアのためのビデオ出力の連続フレーム（一連のビデオ映像）を発生する（例えば、ユーザがボタンを押して、スクリーン上のキャラクタを右へ移動するように指令する場合には、ゲームプログラムが、右へ移動するキャラクタを示す一連のビデオ映像を生成する）。この一連のビデオ映像は、次いで、短待ち時間のビデオコンプレッサを使用して圧縮され、次いで、ホスティングサービス２１０は、インターネット２０６を通して短待ち時間のビデオストリームを送信する。家庭又はオフィス用クライアント装置は、次いで、圧縮されたビデオストリームをデコードし、そしてモニタ又はＴＶにおいてその解凍されたビデオ映像をレンダリングする。その結果、クライアント装置２０５のコンピューティング及びグラフィックハードウェア要件が著しく緩和される。クライアント２０５は、キーボード／コントローラ入力をインターネット２０６へ転送し、そしてインターネット２０６から受け取った圧縮されたビデオストリームをデコードし解凍するための処理パワーを有するだけでよく、これは、実質上、パーソナルコンピュータが、今日、そのＣＰＵにおいてソフトウケアで実行できることである（例えば、ほぼ２ＧＨｚで実行されるインテル社のＣｏｒｅ Ｄｕｏ ＣＰＵは、Ｈ．２６４及びＷｉｎｄｏｗｓ Ｍｅｄｉａ ＶＣ９のようなコンプレッサを使用してエンコードされた７２０ｐ ＨＤＴＶを解凍することができる）。そして、クライアント装置のケースでは、専用のチップも、このような規格に対するビデオ解凍を、リアルタイムで、遥かに低いコストにおいて、且つ近代的なＰＣに要求されるような汎用ＣＰＵより遥かに低い消費電力で遂行することができる。特に、コントローラ入力を転送しそしてビデオを解凍する機能を遂行するために、家庭用クライアント装置２０５は、特殊なグラフィック処理ユニット（ＧＰＵ）、光学的ドライブ又はハードドライブ、例えば、図１に示す従来のビデオゲームシステムを要求しない。
ゲーム及びアプリケーションソフトウェアが、より複雑になり且つよりホトリアリスティックになるにつれて、それらは、高性能ＣＰＵ、ＧＰＵ、より多くのＲＡＭ、及びより大きくて高速のディスクドライブを要求し、且つホスティングサービス２１０のコンピューティングパワーは、アップグレードし続けるが、エンドユーザは、家庭又はオフィス用のクライアントプラットホーム２０５を更新することが要求されない。というのは、その処理要件は、所与のビデオ解凍アルゴリズムでの表示解像度及びフレームレートに対して一定のままだからである。従って、図２ａ−ｂに示すシステムには、今日見られるハードウェア制限及び互換性の問題が生じない。
更に、ゲーム及びアプリケーションソフトウェアは、ホスティングサービス２１０のサーバーでのみ実行されるので、ゲーム又はアプリケーションソフトウェアのコピー（光学的メディアの形態又はダウンロードされたソフトウェアとして）がユーザの家庭又はオフィスに存在することはない（ここで使用する「オフィス」とは、特に指示のない限り、例えば、学校の教室を含めて、非住居設定を含むものとする）。これは、ゲーム又はアプリケーションソフトウェアが不法にコピーされる（海賊版作成される）おそれを著しく軽減すると共に、海賊版作成されるゲーム又はアプリケーションにより貴重なデータベースが使用されるおそれを軽減する。実際に、家庭又はオフィスでの使用に実際的でないゲーム又はアプリケーションソフトウェアをプレイするために特殊なサーバーが要求される（例えば、非常に高価で、大きく又はノイズを発生する装置が要求される）場合には、ゲーム又はアプリケーションソフトウェアの海賊版コピーが得られたとしても、家庭又はオフィスで動作することはできない。
一実施形態では、ホスティングサービス２１０は、ソフトウェア開発ツールをゲーム又はアプリケーションソフトウェア開発者（一般的に、ソフトウェア開発会社、ゲーム又は映画スタジオ、或いはゲーム又はアプリケーションソフトウェア発行者を指す）２２０に与え、この開発者は、ホスティングサービス２１０において実行できるゲームを設計するようにビデオゲームを設計する。そのようなツールは、スタンドアローンＰＣ又はビデオゲームコンソールでは通常利用できないホスティングサービスの特徴を開発者が利用できるようにする（例えば、複雑な幾何学形状の非常に大きなデータベースへの高速アクセス（「幾何学形状」とは、特に指示のない限り、ここでは、多角形、テクスチャ、リギング、照明、挙動、並びに３Ｄデータベースを定義する他のコンポーネント及びパラメータを指すものとする））。
このアーキテクチャーのもとでは、異なるビジネスモデルが考えられる。１つのモデルのもとで、ホスティングサービス２１０は、図２ａに示すように、エンドユーザから契約料金を収集し、そして開発者２２０にロイヤリティを支払う。図２ｂに示す別の具現化においては、開発者２２０がユーザから契約料金を直接収集し、そしてゲーム又はアプリケーションコンテンツをホストするためにホスティングサービス２１０に支払をする。これらの基礎的な原理は、オンラインゲーム又はアプリケーションホスティングを提供するための特定のビジネスモデルに限定されない。
圧縮ビデオ特性
上述したように、ビデオゲームサービス又はアプリケーションソフトウェアサービスをオンラインで提供することに伴う１つの顕著な問題は、待ち時間である。（ユーザにより入力装置が操作される点から、ディスプレイ装置に応答が表示される点までの）７０から８０ｍｓの待ち時間が、高速応答時間を要求するゲーム及びアプリケーションの上限である。しかしながら、図２ａ及び２ｂに示すアーキテクチャーの環境では多数の実際的及び物理的な制約があるために、これを達成することが非常に困難である。
図３に示すように、ユーザがインターネットサービスに契約するときに、その接続は、典型的に、ユーザの家庭又はオフィスへの公称最大データレート３０１によって定格付けされる。プロバイダーのポリシー及びルーティング装置の能力に基づいて、その最大データレートは、若干厳格に施行できるが、典型的に、実際に得られるデータレートは、多数の異なる理由の１つで、低いものとなる。例えば、ＤＳＬ中央オフィス又はローカルケーブルモデムループに非常に多くのネットワークトラフィックがあるか、又はケーブルにノイズが生じてパケットをドロップさせるか、或いはプロバイダーが最大ビット数／月／ユーザを確立することがある。現在、ケーブル及びＤＳＬサービスに対する最大ダウンストリームデータレートは、典型的に、数百キロビット／秒（Ｋｂｐｓ）から３０Ｍｂｐｓの範囲である。セルラーサービスは、典型的に、数百Ｋｂｐｓのダウンストリームデータに制限される。しかしながら、ブロードバンドサービスの速度及びブロードバンドサービスに契約するユーザの数は、時間と共に急激に増加する。現在、ある分析では、米国のブロードバンド加入者の３３％が２Ｍｂｐｓ以上のダウンストリームデータレートを有することが推定される。例えば、ある分析では、２０１０年までに、米国のブロードバンド加入者の８５％以上が２Ｍｂｐｓ以上のデータレートを有することが推定される。
図３に示すように、実際に利用可能な最大データレート３０２は、時間と共に変動し得る。従って、短い待ち時間のオンラインゲーム又はアプリケーションソフトウェアコンテクストでは、時々、特定のビデオストリームに対する実際に利用できるデータレートを予想することが困難である。所与の数値のフレーム／秒（ｆｐｓ）における所与のレベルのクオリティをある量のシーンの複雑さに対し所与の解像度（例えば、６４０ｘ４８０＠６０ｆｐｓ）において維持するためにデータレート３０３が要求され、そして（図３にピークで示されるように）実際に利用できる最大データレート３０２より上に動きが上昇する場合には、多数の問題が発生し得る。例えば、あるインターネットサービスは、単にパケットをドロップし、ユーザのビデオスクリーンにデータロス及び映像歪／ロスを招くことになる。他のサービスは、付加的なパケットを一時的にバッファし（即ち、キューイングし）、そして利用可能なデータレートでクライアントへパケットを与えて、待ち時間の増加、即ち多数のビデオゲーム及びアプリケーションにとって受け容れられない結果を招くことになる。最終的に、あるインターネットサービスプロバイダーは、データレートの増加を、悪意のある攻撃、例えば、サービス拒否攻撃（ネットワーク接続を無能化するためにハッカーにより使用される良く知られた技術）とみなし、そしてユーザのインターネット接続を指定期間中切断する。従って、ここに述べる実施形態は、ビデオゲームに要求されるデータレートが、利用可能な最大データレートを越えないことを保証するステップをとる。
ホスティングサービスアーキテクチャー
図４ａは、一実施形態によるホスティングサービス２１０のアーキテクチャーを示す。ホスティングサービス２１０は、単一サーバーセンターに配置することもできるし、又は複数のサーバーセンターにわたり分散することもできる（あるサーバーセンターへの経路が他のサーバーセンターより短い待ち時間となる短待ち時間接続をユーザに与え、ユーザ間に負荷バランスを与え、そして１つ以上のサーバーセンターがフェイルする場合に冗長性を与えるために）。ホスティングサービス２１０は、最終的に、数百又は数千或いは数百万のサーバー４０２を含み、非常に大きなユーザベースにサービスすることができる。ホスティングサービスコントロールシステム４０１は、ホスティングサービス２１０に対する全体的なコントロールを与え、ルーター、サーバー、ビデオ圧縮システム、ビリング及びアカウンティングシステム、等に指令する。一実施形態では、ホスティングサービスコントロールシステム４０１は、ユーザ情報、サーバー情報及びシステム統計情報のためのデータベースを記憶するのに使用されるＲＡＩＤアレイに結合された分散処理Ｌｉｎｕｘベースシステムにおいて具現化される。以上の説明では、ホスティングサービス２１０により具現化される種々のアクションは、他の特定システムに起因しない限り、ホスティングサービスコントロールシステム４０１により開始されコントロールされる。
ホスティングサービス２１０は、インテル、ＩＢＭ、ヒューレットパッカード、等から現在入手できるもののような多数のサーバー４０２を含む。或いは又、サーバー４０２は、コンポーネントのカスタム構成でアッセンブルすることもできるし、又は全サーバーが単一チップとして具現化されるように最終的に一体化することもできる。この図は、図示明瞭化のために、少数のサーバー４０２しか示していないが、実際の展開では、１つ程度のサーバー４０２があってもよいし、又は数百万以上のサーバー４０２があってもよい。サーバー４０２は、全てが同様に構成されてもよいし（幾つかの構成パラメータの例として、同じＣＰＵ形式及び性能で、ＧＰＵをもったりもたなかったりして、そしてＧＰＵをもつ場合には、同じＧＰＵ形式及び性能で、又、同じ数のＣＰＵ及びＧＰＵで、又、同じ量及び形式／速度のＲＡＭで、並びに同じＲＡＭ構成で）、又はサーバー４０２の種々のサブセットが同じ構成を有してもよいし（例えば、サーバーの２５％をある仕方で構成することができ、５０％を異なる仕方で構成することができ、そして２５％を更に別の仕方で構成することができ）、或いは各サーバー４０２が異なるものでもよい。
一実施形態では、サーバー４０２は、ディスクレスであり、即ちそれ自身のローカル大量記憶装置（光学又は磁気記憶装置、或いは半導体ベースの記憶装置、例えば、フラッシュメモリ又は同様の機能を果たす他の大量記憶手段）を有するのではなく、各サーバーは、高速バックプレーン又はネットワーク接続を通して共有大量記憶装置にアクセスする。一実施形態では、この高速接続は、一連の独立ディスク冗長アレイ（ＲＡＩＤ）４０５に接続された記憶エリアネットワーク（ＳＡＮ）４０３であり、装置間の接続がギガビットイーサネット（登録商標）を使用して具現化される。当業者に明らかなように、ＳＡＮ４０３は、多数のＲＡＩＤアレイ４０５を一緒に合成して、最終的に広い帯域巾を生じさせ、即ち現在のゲームコンソール及びＰＣに使用されるＲＡＭから得られる帯域巾に接近するか又はそれを潜在的に越えるのに使用される。そして、磁気メディアのような回転メディアをベースとするＲＡＩＤアレイは、著しいシーク時間アクセス待ち時間をしばしば有するが、半導体記憶装置をベースとするＲＡＩＤアレイは、相当に短いアクセス待ち時間で具現化することができる。別の構成では、サーバー４０２の幾つか又は全部が、それら自身の大量記憶装置の幾つか又は全部をローカルで与える。例えば、サーバー４０２は、そのオペレーティングシステムのような頻繁にアクセスされる情報、及びビデオゲーム又はアプリケーションのコピーを短待ち時間のローカルフラッシュベースの記憶装置に記憶するが、幾何学形状又はゲーム状態情報の大きなデータベースに時々アクセスするには、ＳＡＮを使用して、回転メディアをベースとするＲＡＩＤアレイ４０５に大きなシーク待ち時間でアクセスする。
更に、一実施形態では、ホスティングサービス２１０は、以下に詳細に説明する短待ち時間のビデオ圧縮ロジック４０４を使用する。このビデオ圧縮ロジック４０４は、ソフトウェア、ハードウェア又はその組合せで具現化することができる（その幾つかの実施形態を以下に説明する）。ビデオ圧縮ロジック４０４は、オーディオ及びビジュアル資料を圧縮するためのロジックを含む。
動作に際し、ユーザの家屋２１１において、キーボード、マウス、ゲームコントローラ又は他の入力装置４２１を経てビデオゲームをプレイするか又はアプリケーションを使用する間に、クライアント４１５のコントロール信号ロジック４１３は、ユーザにより作動されたボタン押圧（及び他の形式のユーザ入力）を表す（典型的にＵＤＰパケットの形態の）コントロール信号４０６ａ−ｂを送信する。所与のユーザからのコントロール信号は、適当なサーバー（又は複数のサーバーがユーザの入力装置に応答する場合には複数のサーバー）４０２へルーティングされる。図４ａに示すように、コントロール信号４０６ａは、ＳＡＮを経てサーバー４０２へルーティングされる。それとは別に又はそれに加えて、コントロール信号４０６ｂは、ホスティングサービスネットワーク（例えば、イーサネットベースのローカルエリアネットワーク）を経てサーバー４０２へ直接ルーティングされる。それらがどのように送信されるかに関わらず、サーバー（１つ又は複数）は、コントロール信号４０６ａ−ｂに応答してゲーム又はアプリケーションソフトウェアを実行する。図４ａに示されていないが、ファイアウオール（１つ又は複数）及び／又はゲートウェイ（１つ又は複数）のような種々のネットワークコンポーネントは、ホスティングサービス２１０の縁（例えば、ホスティングサービス２１０とインターネット４１０との間）において、及び／又はインターネット４１０と家庭又はオフィスクライアント４１５との間のユーザの家屋２１１の縁において到来するトラフィック及び出て行くトラフィックを処理することができる。実行されたゲーム又はアプリケーションソフトウェアのグラフィック及びオーディオ出力、即ちビデオ映像の新たなシーケンスは、短待ち時間のビデオ圧縮ロジック４０４へ供給され、このロジックは、ここに述べるような短待ち時間のビデオ圧縮技術に基づいてビデオ映像のシーケンスを圧縮し、そして圧縮されたビデオストリームを、典型的に、圧縮された又は非圧縮のオーディオと共に、インターネット４１０を経て（又は、以下に述べるように、一般的なインターネットをバイパスする最適な高速ネットワークサービスを経て）クライアント４１５へ返送する。クライアント４１５における短待ち時間のビデオ解凍ロジック４１２は、次いで、ビデオ及びオーディオストリームを解凍し、その解凍されたビデオストリームをレンダリングし、そして典型的に、その解凍されたオーディオストリームをディスプレイ装置４２２においてプレイする。或いは又、オーディオは、ディスプレイ装置４２２とは個別のスピーカで再生してもよいし、そうでなくてもよい。入力装置４２１及びディスプレイ装置４２２は、図２ａ及び２ｂでは独立した装置として示されているが、ポータブルコンピュータ又は移動装置のようなクライアント装置内に一体化されてもよいことに注意されたい。
家庭又はオフィスクライアント４１５（図２ａ及び２ｂにおいて家庭又はオフィスクライアント２０５として既に述べた）は、非常に安価で且つ低電力の装置で、計算又はグラフィック性能が非常に限定されていると共に、ローカルの大量記憶装置が非常に限定されたものであるか又はそれを全く有していない。対照的に、ＳＡＮ４０３及び複数のＲＡＩＤ４０５に結合された各サーバー４０２は、非常に高い性能のコンピューティングシステムであり、そして実際に、複数のサーバーが並列処理構成で協働的に使用される場合は、保持することのできる計算及びグラフィック処理パワーの量にほぼ制限がなくなる。そして、ユーザにとって知覚的に短待ち時間のビデオ圧縮４０４及び短待ち時間のビデオ圧縮４１２のために、サーバー４０２の計算パワーがユーザに与えられる。ユーザが入力装置４２１のボタンを押すと、ディスプレイ４２２上の映像は、ゲーム又はアプリケーションソフトウェアがローカルで実行されるかのように、知覚的に意義のある遅延を伴わずに、ボタンの押圧に応答して更新される。従って、短待ち時間のビデオ解凍及びコントロール信号ロジック４１３を具現化する非常に低性能のコンピュータ又は安価なチップである家庭又はオフィスクライアント４１５では、ローカルで利用できると思われるリモート位置から効果的な任意の計算パワーがユーザに与えられる。これは、最も進歩したプロセッサ集中の（典型的に新規な）ビデオゲーム及び最高性能のアプリケーションをプレイするパワーをユーザに与える。
図４ｃは、非常に基本的で且つ安価な家庭又はオフィスクライアント装置４６５を示す。この装置は、図４ａ及び４ｂからの家庭又はオフィスクライアント４１５の実施形態である。これは約２インチの長さである。これは、パワーオーバーイーサネット（ＰｏＥ）でイーサネットケーブルとインターフェイスするイーサネットジャック４６２を有し、そこから、インターネットへの電力及び接続が得られる。ネットワークアドレストランスレーション（ＮＡＴ）をサポートするネットワーク内でＮＡＴを実行することができる。オフィス環境では、多数の新規なイーサネットスイッチは、ＰｏＥを有し、そしてＰｏＥをオフィスのイーサネットジャックへ直接持って行く。このような状況では、壁ジャックからクライアント４６５へのイーサネットケーブルが要求されるだけである。利用できるイーサネット接続が（例えば、ＤＳＬ又はケーブルモデムをもつが、ＰｏＥはもたない家庭において）電力を搬送しない場合には、非給電イーサネットケーブル及びＰｏＥ付き出力イーサネットを受け容れる安価な壁「ブリック」（即ち電源）が利用できる。
クライアント４６５は、キーボード、マウス、ゲームコントローラ及び／又はマイクロホン及び／又はヘッドセットのようなブルーツース入力装置４７９とインターフェイスするブルーツースワイヤレスインターフェイスに結合された（図４ａの）コントロール信号ロジック４１３を含む。又、クライアント４６５の一実施形態は、１２０ｆｐｓビデオをサポートできるディスプレイ装置４６８に結合されるビデオを１２０ｆｐｓで出力し、そしてシャッター付き眼鏡４６６に信号を送って（典型的に赤外線により）、各次々のフレームで片方の目に、次いで、他方の目に交互にシャッター作動することができる。ユーザが認知する効果は、ディスプレイスクリーンを「跳び出す」ステレオ３Ｄ映像である。このようなオペレーションをサポートする１つのこのようなディスプレイ装置４６８は、Ｓａｍｓｕｎｇ ＨＬ−Ｔ５０７６Ｓである。各目のビデオストリームは個別であるから、一実施形態では、独立した２つのビデオストリームがホスティングサービス２１０により圧縮され、フレームは、時間的にインターリーブされ、そしてフレームは、クライアント４６５内の独立した２つの解凍プロセスとして解凍される。
又、クライアント４６５は、到来するビデオ及びオーディオを解凍してＨＤＭＩ（高鮮明度マルチメディアインターフェイス）を通して出力する短待ち時間のビデオ解凍ロジック４１２と、ＳＤＴＶ（標準鮮明度テレビジョン）又はＨＤＴＶ（高鮮明度テレビジョン）４６８に差し込まれてＴＶにビデオ及びオーディオを与えるか又はＨＤＭＩをサポートするモニタ４６８に差し込まれるコネクタ４６３とを含む。ユーザのモニタ４６８がＨＤＭＩをサポートしない場合には、ＨＤＭＩ対ＤＶＩ（デジタルビジュアルインターフェイス）を使用することができるが、オーディオが失われる。ＨＤＭＩ規格のもとでは、ディスプレイの能力（例えば、サポートされる解像度、フレームレート）４６４がディスプレイ装置４６８から通信され、この情報は、次いで、インターネット接続４６２を通してホスティングサービス２１０へ返送され、従って、ディスプレイ装置に適したフォーマットで圧縮ビデオをストリーミングすることができる。
図４ｄは、より多くの外部インターフェイスを有する以外は図４ｃに示す家庭又はオフィスクライアント装置４６５と同じである家庭又はオフィスクライアント装置４７５を示す。又、クライアント４７５は、電力に対してＰｏＥを受け容れることもできるし、又は壁に差し込まれる外部電源アダプタ（図示せず）から延びることもできる。クライアント４７５のＵＳＢ入力を使用すると、ビデオカメラ４７７は、圧縮されたビデオをクライアント４７５へ供給し、これは、クライアント４７５によってホスティングサービス２１０へアップロードされ、以下に述べるように使用される。カメラ４７７に内蔵されるのは、以下に述べる圧縮技術を使用した短待ち時間のコンプレッサである。
インターネット接続としてイーサネットコネクタを有するのに加えて、クライアント４７５は、インターネットへの８０２．１１ｇワイヤレスインターフェイスも有する。両インターフェイスは、ＮＡＴをサポートするネットワーク内でＮＡＴを使用することができる。
又、ビデオ及びオーディオを出力するためにＨＤＭＩコネクタを有するのに加えて、クライアント４７５は、アナログ出力を含む（且つ標準アダプタケーブルでＶＧＡ出力を与える）デュアルリンクＤＶＩ−Ｉコネクタも有する。又、これは、複合ビデオ及びＳ−ビデオのためのアナログ出力も有する。
オーディオに対して、クライアント４７５は、左右のアナログステレオＲＣＡジャックを、そしてデジタルオーディオ出力に対して、ＴＯＳＬＩＮＫ出力を有する。
又、入力装置４７９へのブルーツースワイヤレスインターフェイスに加えて、入力装置にインターフェイスするためのＵＳＢジャックも有する。
図４ｅは、クライアント４６５の内部アーキテクチャーの一実施形態を示す。図示された装置の全部又は幾つかを、フィールドプログラマブルロジックアレー、カスタムＡＳＩＣ、或いはカスタム設計又は既製の多数の個別装置で具現化することができる。
ＰｏＥを伴うイーサネット４９７がイーサネットインターフェイス４８１に取り付けられる。ＰｏＥを伴うイーサネット４９７から電力４９９が導出され、クライアント４６５内の残りの装置に接続される。バス４８０は、装置間の通信のための共通バスである。
フラッシュ４７６からの小さなクライアントコントロールアプリケーションを実行するコントロールＣＰＵ４８３（ほとんどの場合に、ＲＡＭが埋設された１００ＭＨｚのＭＩＰＳ Ｒ４０００シリーズＣＰＵのような小型のＣＰＵで充分である）は、ネットワーク（即ち、イーサネットインターフェイス）のためのプロトコルスタックを具現化し、又、ホスティングサービス２１０と通信し、そしてクライアント４６５内の全ての装置を構成する。又、これは、入力装置４６９とのインターフェイスを取り扱い、そして必要に応じて、「順方向エラー修正」で保護して、パケットをユーザコントローラデータと共にホスティングサービス２１０へ返送する。又、コントロールＣＰＵ４８３は、パケットトラフィックを監視する（例えば、パケットが失われるか遅延された場合、それらの到着にタイムスタンプも押す）。この情報は、ホスティングサービス２１０へ返送され、従って、ネットワーク接続を常時監視し、それに応じて何を送信するか調整することができる。フラッシュメモリ４７６は、最初に、製造時に、コントロールＣＰＵ４８３のコントロールプログラムがロードされると共に、特定のクライアント４６５ユニットにとって独特のシリアル番号もロードされる。このシリアル番号は、ホスティングサービス２１０がクライアント４６５ユニットを独特に識別できるようにする。
ブルーツースインターフェイス４８４は、クライアント４６５の内部にあるそのアンテナを通して入力装置４６９へワイヤレス通信する。
ビデオデコンプレッサ４８６は、ここに述べるビデオ解凍を具現化するように構成された短待ち時間のビデオデコンプレッサである。非常に多数のビデオ解凍装置が、既製品として、又はＦＰＧＡ又はカスタムＡＳＩＣへ一体化できる知的プロパティ（ＩＰ）設計として、存在する。Ｈ．２６４デコーダのためのＩＰを提供する１つの会社は、ＮＳＷオーストラリアのオーシャンロジックオブマンリー(Ocean Logic of Manly)である。ＩＰを使用する効果は、ここで使用する圧縮技術が圧縮規格に従わないことである。ある標準的なデコンプレッサは、ここに述べる圧縮技術を受け容れるように構成されるに充分なほど融通性があるが、あるものはそうではない。しかし、ＩＰでは、デコンプレッサを必要に応じて設計し直す上で完全な融通性がある。
ビデオデコンプレッサの出力は、ビデオ出力サブシステム４８７に結合され、これは、ビデオをＨＤＭＩインターフェイス４９０のビデオ出力に結合する。
オーディオ解凍サブシステム４８８は、入手可能な標準的オーディオデコンプレッサを使用して具現化されるか、又はＩＰとして具現化することもでき、或いはオーディオの解凍は、例えば、Ｖｏｒｂｉｓオーディオデコンプレッサを具現化できるコントロールプロセッサ４８３内で具現化することもできる。
オーディオの解凍を具現化する装置は、オーディオ出力サブシステム４８９へ結合され、これは、オーディオをＨＤＭＩインターフェイス４９０のオーディオ出力へ結合する。
図４ｆは、クライアント４７５の内部アーキテクチャーの一実施形態を示す。明らかなように、このアーキテクチャーは、付加的なインターフェイスと、壁に差し込む電源アダプタからの任意の外部ＤＣ電力を除き、クライアント４６５と同じであり、その外部ＤＣ電力は、そのように使用される場合、イーサネットＰｏＥ４９７から到来する電力に取って代わる。クライアント４６５と共通の機能は、以下に説明を繰り返さず、付加的な機能を以下に説明する。
ＣＰＵ４８３は、付加的な装置と通信し、それを構成する。
ＷｉＦｉサブシステム４８２は、そのアンテナを通してイーサネット４９７への代替物としてワイヤレスインターネットアクセスを与える。ＷｉＦｉサブシステムは、カリフォルニア州サンタクララのアセロスコミュニケーションズ(Atheros Communications)を含めて幅広い製造者から入手できる。
ＵＳＢサブシステム４８５は、ワイヤードＵＳＢ入力装置４７９に対してブルーツース通信の代替物を与える。ＵＳＢサブシステムは、極めて標準的で、ＦＰＧＡ及びＡＳＩＣについて入手容易であり、且つビデオ解凍と同様に、他の機能を遂行する既製装置にしばしば内蔵される。
ビデオ出力サブシステム４８７は、クライアント４６５内よりも広範囲なビデオ出力を発生する。これは、ＨＤＭＩ４９０ビデオ出力を与えるのに加えて、ＤＶＩ−Ｉ４９１、Ｓ−ビデオ４９２及び複合ビデオ４９３を与える。又、ＤＶＩ−Ｉ４９１インターフェイスがデジタルビデオに対して使用されるときには、ディスプレイ能力４６４がディスプレイ装置からコントロールＣＰＵ４８３へ返送され、ディスプレイ装置４７８の能力をホスティングサービス２１０に通知できるようにする。ビデオ出力サブシステム４８７により与えられる全てのインターフェイスは、極めて標準的なインターフェイスであり、多数の形態で入手容易である。
オーディオ出力サブシステム４８９は、デジタルインターフェイス４９４（Ｓ／ＰＤＩＦ及び／又はＴＯＳＬＩＮＫ）を通してオーディオをデジタルで出力すると共に、ステレオアナログインターフェイス４９５を通してオーディオをアナログ形態で出力する。
往復待ち時間の分析
もちろん、以上の段落を理解するために、入力装置４２１を使用したユーザのアクションと、そのアクションの結果をディスプレイ装置４２０で見るときとの間の往復待ち時間は、７０−８０ｍｓ以下でなければならない。この待ち時間は、ユーザの家屋２１１内の入力装置４２１からホスティングサービス２１０へそしてユーザの家屋２１１へ戻って、ディスプレイ装置４２２へ至る経路における全てのファクタを考慮しなければならない。図４ｂは、信号が進行しなければならない種々のコンポーネント及びネットワークを示し、これらコンポーネント及びネットワークの上には、実際の具現化で予想できる待ち時間を列挙した時間線がある。図４ｂは、重要な経路ルーティングだけを示すように簡略化されていることに注意されたい。システムの他の特徴のために使用されるデータの他のルーティングは、以下で説明する。双頭矢印（例えば、矢印４５３）は、往復待ち時間を表し、単頭矢印（例えば、矢印４５７）は、片道待ち時間を表し、そして「〜」は、近似尺度を示す。列挙した待ち時間を達成できない実世界の状況があるが、米国内における多くのケースでは、ユーザの家屋２１１へのＤＳＬ及びケーブルモデム接続を使用し、次の段落で述べる環境においてこれら待ち時間を達成できることを指摘しなければならない。又、インターネットへのセルラーワイヤレス接続は、図示されたシステムにおいて確実に機能するが、ほとんどの現在のＵＳセルラーデータシステム（ＥＶＤＯのような）は、非常に長い待ち時間を被り、図４ｂに示す待ち時間を達成できないことにも注意されたい。しかしながら、これらの基礎的な原理は、このレベルの待ち時間を具現化できる将来のセルラー技術において具現化することができよう。
ユーザの家屋２１１における入力装置４２１からスタートして、ユーザが入力装置４２１を操作すると、ユーザコントロール信号がクライアント４１５へ送信され（これは、セットトップボックスのようなスタンドアローン装置でもよいし、或いはＰＣ又は移動装置のような別の装置で実行されるソフトウェア又はハードウェアでもよい）、そして（一実施形態ではＵＤＰフォーマットで）パケット化され、そのパケットには、ホスティングサービス２１０に到着するための行先アドレスが与えられる。又、パケットは、コントロール信号がどのユーザから到来するか指示する情報も含む。次いで、コントロール信号のパケット（１つ又は複数）は、ファイアウオール／ルーター／ＮＡＴ（ネットワークアドレストランスレーション）装置４４３を通してＷＡＮインターフェイス４４２へ転送される。ＷＡＮインターフェイス４４２は、ユーザのＩＳＰ（インターネットサービスプロバイダー）によりユーザの家屋２１１に与えられるインターフェイス装置である。ＷＡＮインターフェイス４４２は、ケーブル又はＤＳＬモデム、ＷｉＭａｘトランシーバー、ファイバートランシーバー、セルラーデータインターフェイス、インターネットプロトコル・オーバー・パワーラインインターフェイス、又はインターネットへの多数のインターフェイスの他のものでよい。更に、ファイアウオール／ルーター／ＮＡＴ装置４４３（及び潜在的にＷＡＮインターフェイス４４２）は、クライアント４１５に一体化されてもよい。その一例は、家庭又はオフィスクライアント４１５の機能を具現化するためのソフトウェアと、ある規格（例えば、８０２．１１ｇ）によりインターネットへワイヤレスでルーティング及び接続する手段とを含む移動電話である。
ＷＡＮインターフェイス４４２は、次いで、コントロール信号をユーザのインターネットサービスプロバイダー（ＩＳＰ）のための「存在点(point of presence)」４４１と称されるものへルーティングし、これは、ユーザの家屋２１１に接続されたＷＡＮトランスポートと、一般的インターネット又はプライベートネットワークとの間のインターフェイスをなすファシリティである。存在点の特性は、提供されるインターネットサービスの性質に基づいて変化する。ＤＳＬの場合、これは、典型的に、ＤＳＬＡＭが配置される電話会社の中央オフィスとなる。ケーブルモデムの場合、これは、典型的に、ケーブルマルチシステムオペレータ（ＭＳＯ）ヘッドエンドとなる。セルラーシステムの場合、これは、典型的に、セルラータワーに関連したコントロールルームとなる。しかし、存在点の性質が何であれ、これは、コントロール信号パケット（１つ又は複数）を一般的インターネット４１０へルーティングする。コントロール信号パケット（１つ又は複数）は、次いで、最も多くはファイバトランシーバーインターフェイスであるものを通して、ホスティングサービス２１０へのＷＡＮインターフェイス４４１へルーティングされる。ＷＡＮ４４１は、次いで、コントロール信号パケットをルーティングロジック４０９（これは、イーサネットスイッチ及びルーティングサーバーを含めて、多数の異なる仕方で具現化される）へルーティングし、これは、ユーザのアドレスを評価し、そしてコントロール信号を所与のユーザに対する正しいサーバー４０２へルーティングする。
サーバー４０２は、次いで、コントロール信号を、サーバー４０２で実行されるゲーム又はアプリケーションソフトウェアに対する入力として取り上げ、そしてそのコントロール信号を使用して、ゲーム又はアプリケーションの次のフレームを処理する。次のフレームが発生されると、サーバー４０２からビデオコンプレッサ４０４へビデオ及びオーディオが出力される。ビデオ及びオーディオは、サーバー４０２から種々の手段を経てコンプレッサ４０４へ出力される。先ず、コンプレッサ４０４は、サーバー４０２に組み込むことができ、従って、圧縮をサーバー４０２内でローカルに具現化することができる。又は、ビデオ及び／又はオーディオは、パケット化形態で、イーサネット接続のようなネットワーク接続を経て、サーバー４０２とビデオコンプレッサ４０４との間のプライベートネットワークであるネットワークへ、又はＳＡＮ４０３のような共有ネットワークを通して、出力することができる。或いは、ビデオは、サーバー４０２から、ＤＶＩ又はＶＧＡコネクタのようなビデオ出力コネクタを通して出力され、次いで、ビデオコンプレッサ４０４により捕獲されてもよい。又、オーディオは、サーバー４０２からデジタルオーディオとして（例えば、ＴＯＳＬＩＮＫ又はＳ／ＰＤＩＦコネクタを経て）出力されるか又はアナログオーディオとして出力されてもよく、アナログオーディオは、ビデオコンプレッサ４０４内のオーディオ圧縮ロジックによりデジタル化されエンコードされる。
ビデオコンプレッサ４０４は、ビデオフレーム、及びサーバー４０２からのそのフレーム時間中に発生されたオーディオを捕獲すると、以下に述べる技術を使用してビデオ及びオーディオを圧縮する。ビデオ及びオーディオが圧縮されると、アドレスと共にパケット化されて、ユーザのクライアント４１５へ返送され、ＷＡＮインターフェイス４４１へルーティングされ、このＷＡＮインターフェイスは、ビデオ及びオーディオパケットを一般的なインターネット４１０を経てルーティングし、このインターネットは、ビデオ及びオーディオパケットをユーザのＩＳＰ存在点４４１へルーティングし、この存在点は、ビデオ及びオーディオパケットをユーザの家屋のＷＡＮインターフェイス４４２へルーティングし、このインターフェイスは、ビデオ及びオーディオパケットをファイアウオール／ルーター／ＮＡＴ装置４４３へルーティングし、次いで、この装置は、ビデオ及びオーディオパケットをクライアント４１５へルーティングする。
クライアント４１５は、ビデオ及びオーディオを解凍し、次いで、ビデオをディスプレイ装置４２２（又はクライアントの内蔵ディスプレイ装置）に表示すると共に、オーディオをディスプレイ装置４２２又は個別の増幅器／スピーカへ或いはクライアントに内蔵された増幅器／スピーカへ送信する。
上述した全プロセスに知覚的に遅れがないことをユーザが認知するためには、往復遅延が７０又は８０ｍｓ未満である必要がある。前記往復経路における待ち時間遅延のあるものは、ホスティングサービス２１０及び／又はユーザのコントロールのもとにあり、他のものは、そうではない。それでも、非常に多数の実世界のシナリオの分析及びテストに基づき、おおよその測定値は次のようになる。
コントロール信号４５１を送信するための片道送信時間は、典型的に、１ｍｓ未満であり、ユーザの家屋４５２を通る往復ルーティングは、典型的に、イーサネット上に入手容易な消費者グレードのファイアウオール／ルーター／ＮＡＴスイッチを使用して約１ｍｓで達成される。ユーザＩＳＰは、その往復遅延４５３が広く変化するが、ＤＳＬ及びケーブルモデムプロバイダーでは、典型的に、１０ないし２５ｍｓである。一般的なインターネット４１０における往復待ち時間は、トラフィックがどのようにルーティングされるか及びルートに欠陥があるかどうか（これらの問題は以下で述べる）に基づいて大きく変化するが、典型的に、一般的なインターネットは、非常に最適なルートを与え、そして待ち時間は、行先までの距離が与えられると、主として光ファイバを通る光の速度によって決定される。以下に更に述べるように、ユーザの家屋２１１から離れてホスティングサービス２１０を発することが予想される最も遠いおおよその距離として１０００マイルを確立した。１０００マイル（往復２０００マイル）では、インターネットを通る信号の実際の通過時間は、約２２ｍｓである。ホスティングサービス２１０へのＷＡＮインターフェイス４４１は、典型的に、待ち時間を無視できる商業的グレードファイバの高速インターフェイスである。従って、一般的インターネットの待ち時間４５４は、典型的に、１ないし１０ｍｓである。ホスティングサービス２１０を通る片道ルーティング４５５の待ち時間は、１ｍｓ未満である。サーバー４０２は、典型的に、ゲーム又はアプリケーションのための新たなフレームを１フレーム時間（６０ｆｐｓでは１６．７ｍｓである）未満で計算し、従って、使用するために合理的な最大片道待ち時間は、１６ｍｓである。ここに述べるビデオ圧縮及びオーディオ圧縮アルゴリズムの最適なハードウェア具現化では、圧縮４５７を１ｍｓで完了することができる。あまり最適でない形態では、圧縮に６ｍｓ程度を要する（もちろん、もっと最適でない形態は、更に長い時間を要するが、このような具現化は、往復の全待ち時間に影響を及ぼし、７０−８０ｍｓの待ち時間目標を維持するには他の待ち時間を短縮する必要がある（例えば、一般的なインターネットを通る許容距離を短縮することができる））。インターネット４５４、ユーザＩＳＰ４５３及びユーザ家屋ルーティング４５２の往復待ち時間は、既に考慮されており、従って、残りは、ビデオ解凍４５８の待ち時間であり、これは、ビデオ解凍４５８が専用のハードウェアで具現化されるか、又は（ＰＣ又は移動装置のような）クライアント装置４１５においてソフトウェアで具現化されるかに基づいて、又、ディスプレイのサイズ及び解凍ＣＰＵの性能に基づいて、変化する。典型的に、解凍４５８は、１ないし８ｍｓを要する。
従って、実際上見られる最悪のケースの待ち時間を全部加算することにより、図４ａに示すシステムのユーザにより経験されると予想できる最悪のケースの往復待ち時間を決定することができる。それらは、１＋１＋２５＋２２＋１＋１６＋６＋８＝８０ｍｓである。そして、正に、実際に（以下に述べる注意と共に）、これは、図４ａに示すシステムのプロートタイプバージョンを使用し、既製品のＷｉｎｄｏｗｓ ＰＣをクライアント装置として及び米国内の家庭用ＤＳＬ及びケーブルモデム接続を使用して分かったおおよその往復待ち時間である。もちろん、最悪のケースより良好のシナリオでは、非常に短い待ち時間が得られるが、それは、広く使用される商業的サービスの開発に依存することができない。
一般的なインターネットを経て図４ｂに列挙する待ち時間を得るには、図４ａのビデオコンプレッサ４０４及びクライアント４１５のビデオデコンプレッサ４１２が、非常に特定の特性をもつパケットストリームを発生し、ホスティングサービス２１０からディスプレイ装置４２２までの全経路を経て発生されるパケットシーケンスが、遅延や過剰なパケットロスを受けず、且つ特に、ＷＡＮインターフェイス４４２及びファイアウオール／ルーター／ＮＡＴ４４３を通るユーザのインターネット接続を経てユーザに利用できる帯域巾の制約内に一貫して入るようにする必要がある。更に、ビデオコンプレッサは、通常のインターネット及びネットワーク送信において生じる不可避なパケットロス及びパケット並べ替えを許容できるに充分なほど頑丈なパケットストリームを生成しなければならない。
短待ち時間のビデオ圧縮
前記目標を達成するために、一実施形態は、待ち時間を減少し且つビデオを送信するためのピーク帯域巾要件を緩和するというビデオ圧縮の新規な解決策をとる。これらの実施形態を説明する前に、図５及び図６ａ−ｂを参照して、現在のビデオ圧縮技術の分析を行う。もちろん、これらの技術は、これらの技術で要求されるデータレートを取り扱うに充分な帯域巾がユーザに与えられる場合には、基礎的な原理に基づいて使用することができる。オーディオの圧縮は、ビデオの圧縮と同時に且つ同期して具現化されることを述べる以外、ここでは扱わないことに注意されたい。このシステムの要件を満足する従来のオーディオ圧縮技術が存在する。
図５は、ビデオを圧縮するための１つの特定の従来技術であって、特定の圧縮アルゴリズムを使用する圧縮ロジック５２０により各個々のビデオフレーム５０１−５０３を圧縮して、一連の圧縮されたフレーム５１１−５１３を発生する従来技術を示している。この技術の一実施形態は、「モーションＪＰＥＧ」であり、各フレームが、離散的コサイン変換（ＤＣＴ）に基づき、ジョイント・ピクチャー・エクスパート・グループ（ＪＰＥＧ）圧縮アルゴリズムに従って圧縮されるというものである。種々の異なる形式の圧縮アルゴリズムを使用してもよいが、これらの基礎的な原理（例えば、ＪＰＥＧ−２０００のようなウェーブレットベースの圧縮アルゴリズム）に依然適合させるようにする。
この形式の圧縮の１つの問題は、各フレームのデータレートを下げるが、連続フレーム間の類似性を利用してビデオストリーム全体のデータレートを下げるものでないことである。例えば、図５に示すように、映像の所与のクオリティに対し、６４０ｘ４８０ｘ２４ビット／ピクセル＝６４０＊４８０＊２４／８／１０２４＝９００キロバイト／フレーム（ＫＢ／フレーム）のフレームレートを仮定すれば、モーションＪＰＥＧは、１０のファクタでストリームを圧縮するだけであり、９０ＫＢ／フレームのデータストリームを生じさせる。６０フレーム／秒では、これは、９０ＫＢ＊８ビット＊６０フレーム／秒＝４２．２Ｍｂｐｓのチャンネル帯域巾を要求し、これは、今日の米国内のほぼ全ての家庭用インターネット接続に対して遥かに広い帯域巾となり、且つ多数のオフィス用インターネット接続に対しても非常に広い帯域巾となる。実際に、このような広い帯域巾で一定のデータストリームを要求し、且つオフィスＬＡＮ環境においても１人のユーザにしか役立たないとすれば、１００ＭｂｐｓのイーサネットＬＡＮ帯域巾の大きな割合を消費し、ＬＡＮをサポートするイーサネットスイッチに大きな負担を掛けることになる。従って、動画ビデオに対する圧縮は、（以下に述べるような）他の圧縮技術と比べたときに、非効率的である。更に、ロッシー圧縮アルゴリズムを使用するＪＰＥＧ及びＪＰＥＧ−２０００のような単一フレーム圧縮アルゴリズムは、静止映像では気付かない圧縮欠陥（例えば、シーンにおける密集した葉の中の欠陥は、その密集した葉がどのように見えるべきか目にとって厳密に分からないので、欠陥として見えないことがある）を生じる。しかし、シーンが動くと、欠陥が静止映像では気付かないシーンのエリアにあるにも関わらず、欠陥がフレームごとに変化することが目で検出されるので、欠陥が目立つようになる。その結果、余白的アナログＴＶ受信中に見える「スノー」ノイズに見掛けが類似した「バックグランドノイズ」がフレームのシーケンスにおいて知覚される。もちろん、この形式の圧縮は、ここに述べる幾つかの実施形態で依然使用できるが、一般的に述べると、シーンにおけるバックグランドノイズを回避するため、所与の知覚上のクオリティに対して高いデータレート（即ち、低い圧縮比）が要求される。
Ｈ．２６４、又はＷｉｎｄｏｗｓ ＭｅｄｉａＶＣ９、ＭＰＥＧ２及びＭＰＥＧ４のような他の形式の圧縮は、全て、連続するフレーム間の類似性を利用しているので、ビデオストリームの圧縮がより効率的である。これらの技術は、全て、ビデオを圧縮するための同じ一般的技術に依存している。従って、Ｈ．２６４規格について述べるが、他の種々の圧縮アルゴリズムにも同じ一般的原理が適用される。圧縮Ｈ．２６４のためのｘ２６４オープンソースソフトウェアライブラリー、及び解凍Ｈ．２６４のためのＦＦｍｐｅｇオープンソースソフトウェアライブラリーを含めて、非常に多数のＨ．２６４コンプレッサ及びデコンプレッサを利用することができる。
図６ａ及び６ｂは、従来の圧縮技術を例示するもので、一連の非圧縮のビデオフレーム５０１−５０３、５５９−５６１が、圧縮ロジック６２０により、一連の「Ｉフレーム」６１１、６７１、「Ｐフレーム」６１２−６１３、及び「Ｂフレーム」６７０へと圧縮される。図６ａの縦軸は、一般的に、エンコードされて得られる各フレームのサイズを表す（が、フレームは適切なスケールで描かれていない）。上述したように、Ｉフレーム、Ｂフレーム及びＰフレームを使用するビデオコーディングは、当業者に良く知られている。簡単に述べると、Ｉフレーム６１１は、完全非圧縮のフレーム５０１のＤＣＴベース圧縮である（上述した圧縮されたＪＰＥＧ映像と同様）。Ｐフレーム６１２−６１３は、一般的に、Ｉフレーム６１１よりサイズが著しく小さい。というのは、手前のＩフレーム又はＰフレームのデータの利点を取り入れるからであり、即ち手前のＩフレーム又はＰフレーム間の変化を示すデータを含むからである。Ｂフレーム６７０は、Ｐフレームと同様であるが、Ｂフレームは、後続する基準フレームにおけるフレームと、先行する基準フレームにおける潜在的なフレームとを使用する。
以下の説明では、望ましいフレームレートが６０フレーム／秒であり、各Ｉフレームが約１６０Ｋｂであり、平均Ｐフレーム及びＢフレームが１６Ｋｂであり、そして毎秒新たなＩフレームが発生されると仮定する。この１組のパラメータで、平均データレートは、１６０Ｋｂ＋１６Ｋｂ＊５９＝１．１Ｍｂｐｓとなる。このデータレートは、家庭及びオフィスへの多くの現在のブロードバンドインターネット接続に対する最大データレート内に充分入る。又、この技術は、イントラフレーム専用のエンコーディングからバックグランドノイズの問題を回避する傾向がある。というのは、Ｐ及びＢフレームは、フレーム間の差を追跡し、圧縮欠陥がフレームごとに現れたり消えたりする傾向がなく、前記バックグランドノイズの問題を緩和するからである。
前記形式の圧縮に伴う１つの問題は、平均データレートが比較的低い（例えば、１．１Ｍｂｐｓ）が、単一のＩフレームが送信に多数のフレーム分の時間を要することである。例えば、従来技術を使用すると、６０フレームごとに１６０ＫｂｐｓのＩフレームの状態で１．１Ｍｂｐｓでビデオをストリーミングするのに、典型的に、２．２Ｍｂｐｓのネットワーク接続（例えば、図３ａから２．２Ｍｂｐｓピークの利用可能な最大データレート３０２をもつＤＳＬ又はケーブルモデム）で充分である。これは、ビデオを解凍するまで解凍キューに１秒のビデオを入れておくことにより達成される。１秒で、１．１Ｍｂのデータが送信され、これは、利用可能なデータレートが周期的に５０％程度下がると仮定しても、２．２Ｍｂｐｓの利用可能な最大データレートによって容易に受け容れられる。不都合なことに、この従来の解決策は、１秒のビデオバッファが受信器にあるので、ビデオについて１秒の待ち時間を生じさせる。このような遅延は、多数の従来の用途（例えば、リニアビデオの再生）では充分であるが、７０−８０ｍｓを越える待ち時間を許容できない高速アクションのビデオゲームに対しては遥かに長い待ち時間である。
１秒のビデオバッファを排除する試みがなされたが、高速アクションビデオゲームのための充分な待ち時間短縮が得られていない。一例として、上述したＢフレームの使用は、Ｉフレームに先行する全てのＢフレーム及びＩフレームの受信を必要とする。ＰフレームとＢフレームとの間で５９個の非Ｉフレームがおおよそ分割されると仮定すれば、少なくとも２９個のＢフレームがあり、そしてＢフレームを表示できるまでにＩフレームが受信される。従って、チャンネルの利用可能な帯域巾に関わらず、各々１／６０秒巾の２９＋１＝３０フレームの遅延、即ち５００ｍｓの待ち時間が必要になる。明らかに、これは、遥かに長過ぎる。
従って、別の解決策は、Ｂフレームを排除し、そしてＩ及びＰフレームだけを使用することである。（その１つの結果として、所与のクオリティレベルに対してデータレートが増加することになるが、この例における一貫性のために、各Ｉフレームが１６０Ｋｂであり、平均Ｐフレームが１６Ｋｂのサイズであり、従って、データレートが依然１．１Ｍｂｐｓであると仮定し続ける。）この解決策は、Ｂフレームにより導入される不可避な待ち時間を排除する。というのは、各Ｐフレームのデコーディングが、以前に受信したフレームに依存するだけだからである。この解決策に伴う問題は、Ｉフレームが平均Ｐフレームより非常に大きいために、ほとんどの家庭及び多くのオフィスにおいて典型的である狭帯域巾チャンネルでは、Ｉフレームの送信が実質的な待ち時間を増大することである。これが図６ｂに示されている。Ｉフレームに要求されるピークデータレート６２３が、利用可能な最大データレート６２２を（及び定格最大データレート６２１も）遥かに越えるＩフレームを除いて、ビデオストリームのデータレート６２４は、利用可能な最大データレート６２１より低い。Ｐフレームにより要求されるデータレートは、利用可能な最大データレート未満である。２．２Ｍｂｐｓの利用可能な最大データレートのピークがその２．２Ｍｂｐｓのピークレートに着実に保たれるとしても、Ｉフレームを送信するのに１６０Ｋｂ／２．２Ｍｂ＝７１ｍｓを要し、利用可能な最大データレート６２２が５０％（１．１Ｍｂｐｓ）下がった場合には、Ｉフレームを送信するのに１４２ｍｓを要する。従って、Ｉフレームを送信する際の待ち時間は、７１から１４２ｍｓのどこかに入る。この待ち時間は、図４ｂに示された待ち時間に加算され、最悪の場合、これが７０ｍｓに加算され、従って、これは、ユーザが入力装置４２１を操作する時点から、ディスプレイ装置４２２に映像が現れるまで、１４１ないし２２２ｍｓの合計往復待ち時間を生じ、遥かに高いものとなる。そして、利用可能な最大データレートが２．２Ｍｂｐｓより下がる場合には、待ち時間は更に増大する。
又、一般的に、ピークデータレート６２３でＩＳＰを「ジャミング」させて、利用可能なデータレート６２２を遥かに越える厳しい結果が生じることにも注意されたい。異なるＩＳＰの装置は、異なる挙動をするが、利用可能なデータレート６２２より非常に高いデータレートでパケットを受け取るときには、次の挙動がＤＳＬ及びケーブルモデムＩＳＰの間で極めて一般的となる。（ａ）パケットをキューイングすることでパケットを遅延させ（待ち時間を導入し）、（ｂ）パケットの幾つか又は全部をドロップさせ、（ｃ）ある期間接続をディスエイブルする（おそらく、ＩＳＰに関するものであるから、「サービス拒絶」攻撃のような悪意のある攻撃である）。従って、図６ｂに示すような特性で全データレートにおいてパケットストリームを送信することは、実現可能な選択肢ではない。ピーク６２３は、ホスティングサービス２１０においてキューイングされ、そして利用可能な最大データレートより低いデータレートで送信され、上述した許容できない待ち時間を導入することがある。
更に、図６ｂに示すビデオストリームデータレートシーケンス６２４は、非常に「従順な」ビデオストリームデータレートシーケンスであり、そして著しく変化せず且つほとんど動きのないビデオシーケンスからビデオを圧縮することにより生じると予想される種類のデータレートシーケンスである（例えば、カメラが固定位置にあってほとんど動かず、そしてシーン内のオブジェクト、例えば、椅子に座って話している人がほとんど動きを示さないビデオ遠隔会議において一般的であるように）。
図６ｃに示すビデオストリームデータレートシーケンス６３４は、動画又はビデオゲーム或いはあるアプリケーションソフトウェアにおいて発生されるような、遥かに多いアクションを伴うビデオから見えると予想されるものに対して典型的なシーケンスである。Ｉフレームピーク６３３に加えて、極めて大きく且つ多くの場合に利用可能な最大データレートを越える６３５及び６３６のようなＰフレームピークもあることに注意されたい。これらのＰフレームピークは、Ｉフレームピークと同程度に大きいことはあまりないが、全データレートでチャンネルにより搬送されるには遥かに大き過ぎるもので、又、Ｉフレームピークと同様に、Ｐフレームピークは、ゆっくり送信されねばならない（従って、待ち時間が増大する）。
広帯域巾チャンネル（例えば、１００ＭｂｐｓのＬＡＮ、又は広帯域巾１００Ｍｂｐｓのプライベート接続））において、ネットワークは、Ｉフレームピーク６３３又はＰフレームピーク６３６のような大きなピークを許容することができ、そして原理的に、短い待ち時間を維持することができる。しかし、このようなネットワークは、多くの場合、大勢のユーザ間に共有され（例えば、オフィス環境において）、そしてこのような「ピーク」データは、特に、ネットワークトラフィックがプライベート共有接続へルーティングされた場合に（例えば、リモートデータセンターからオフィスへ）、ＬＡＮの性能に影響を及ぼす。先ず、この例は、６０ｆｐｓにおいて６４０ｘ４８０ピクセルの比較的低解像度のビデオストリームであることを銘記されたい。６０ｆｐｓにおいて１９２０ｘ１０８０のＨＤＴＶストリームは、近代的なコンピュータ及びディスプレイによって容易に取り扱われ、そして６０ｆｐｓにおいて２５６０ｘ１４４０解像度のディスプレイが益々入手可能になってきている（例えば、アップル社の３０”ディスプレイ）。又、６０ｆｐｓにおいて１９２０ｘ１０８０の高アクションビデオシーケンスは、適度なクオリティレベルに対してＨ．２６４圧縮を使用して４．５Ｍｂｐｓを必要とする。公称データレートの１０倍のＩフレームピークを仮定すれば、それは４５Ｍｂｐｓ以下のピークを生じるが、まだかなりのＰフレームピークがある。大勢のユーザが同じ１００Ｍｂｐｓのネットワーク（例えば、オフィスとデータセンターとの間のプライベートなネットワーク接続）を経てビデオストリームを受信する場合、大勢のユーザのビデオストリームからのピークがどのように整列して、ネットワークの帯域巾を圧倒し、そしてネットワーク上のユーザをサポートするスイッチのバックプレーンの帯域巾を潜在的に圧倒するか容易に見ることができる。ギガビットのイーサネットネットワークの場合でも、充分なユーザが充分なピークを一度に整列させる場合は、ネットワーク又はネットワークスイッチを圧倒することができる。そして、２５６０ｘ１４４０解像度のビデオがより平凡なものになると、平均ビデオストリームデータレートが９．５Ｍｂｐｓとなり、おそらく、９５Ｍｂｐｓのピークデータレートを生じさせる。言うまでもなく、データセンターとオフィスとの間の１００Ｍｂｐｓの接続（これは、今日、非常に高速な接続である）は、単一ユーザからのピークトラフィックによって完全に沈没される。従って、ＬＡＮ及びプライベートネットワーク接続が、ピークストリーミングビデオを更に許容できるとしても、高いピークを伴うストリーミングビデオは、望ましいものではなく、オフィスのＩＴ部門による特殊なプランニング及び適応を要求する。
もちろん、標準的なリニアビデオアプリケーションの場合、これらの事柄は、問題ではない。というのは、データレートが送信点において「平滑化」され、各フレームのデータが利用可能な最大データレート６２２より低く、そしてクライアントのバッファが、Ｉ、Ｐ及びＢフレームのシーケンスを、それらが解凍されるまで記憶するからである。従って、ネットワークにわたるデータレートは、ビデオストリームの平均データレートの近くに保たれる。不都合なことに、これは、Ｂフレームが使用されない場合でも待ち時間を導入し、即ち高速応答時間を要求するビデオゲーム及びアプリケーションのような短待ち時間アプリケーションについては受け容れられない。
高いピークを有するビデオストリームを軽減する１つの従来の解決策は、「コンスタントビットレート」（ＣＢＲ）エンコーディングとしばしば称される技術を使用することである。ＣＢＲという語は、全てのフレームが同じビットレート（即ち、サイズ）を有するように圧縮されることを意味すると思われるが、それが通常指すのは、ある数のフレーム（ここでは、１フレーム）にわたり最大ビットレートが許されるという圧縮パラダイムである。例えば、図６ｃのケースでは、ビットレートを、定格最大データレート６２１の例えば７０％に制限するエンコーディングにＣＢＲ制約が適用される場合に、圧縮アルゴリズムは、定格最大データレート６２１の７０％以上を使用して通常圧縮されるフレームが少ないビットで圧縮されるように、各フレームの圧縮を制限する。その結果、所与のクオリティレベルを維持するために通常より多くのビットを要求するフレームがビットの「欠乏」となり、これらフレームの映像クオリティは、定格最大データレート６２１の７０％以上のビットを要求しない他のフレームの場合より悪くなる。この解決策は、（ａ）予想される動き又はシーンの変化があまりなく、且つ（ｂ）ユーザが周期的なクオリティ低下を受け容れできるようなある形式の圧縮ビデオに対して、受け容れられる結果を生じさせることができる。ＣＢＲに適したアプリケーションの良い例は、ビデオ遠隔会議である。というのは、ピークが僅かしかなく、且つクオリティが短時間低下した場合に（例えば、カメラがパンして、著しいシーンの動き及び大きなピークを生じ、そのパン中に、高クオリティ映像圧縮に充分なビットがなく、映像クオリティの低下を招く場合に）、ほとんどのユーザにそれが受け容れられるからである。不都合なことに、ＣＢＲは、非常に複雑な又は多くの動きのあるシーンを有し、及び／又は適度な一定レベルのクオリティが要求される他の多数のアプリケーションにはあまり適していない。
一実施形態に使用される短待ち時間の圧縮ロジック４０４は、高いクオリティを維持しながら短待ち時間の圧縮ビデオをストリーミングすることに伴うある範囲の問題に対処するために多数の異なる技術を使用する。第１に、短待ち時間の圧縮ロジック４０４は、Ｉフレーム及びＰフレームしか発生せず、各Ｂフレームをデコードするために多数のフレーム分の時間を待機する必要性を緩和する。更に、図７ａに示すように、一実施形態では、短待ち時間の圧縮ロジック４０４は、各非圧縮フレーム７０１−７６０を一連の「タイル」へと細分化し、そして各タイルをＩフレーム又はＰフレームのいずれかとして個々にエンコードする。圧縮されたＩフレーム及びＰフレームのグループは、ここでは、「Ｒフレーム」７１１−７７０と称される。図７ａに示す特定例では、各非圧縮フレームが、１６タイルの４ｘ４マトリクスへと細分化される。しかしながら、これらの基礎的な原理は、特定の細分化スキムに限定されない。
一実施形態では、短待ち時間の圧縮ロジック４０４は、ビデオフレームを多数のタイルに分割し、そして各フレームからの１つのタイルをＩフレームとしてエンコード（即ち、圧縮）し（即ち、タイルは、フル映像サイズの１／１６の個別ビデオフレームであるかのように圧縮され、この「ミニ」フレームに使用される圧縮は、Ｉフレーム圧縮である）、そして残りのタイルをＰフレームとしてエンコード（即ち、圧縮）する（即ち、１／１６の各「ミニ」フレームに使用される圧縮は、Ｐフレーム圧縮である）。Ｉフレーム及びＰフレームとして圧縮されるタイルは、各々、「Ｉタイル」及び「Ｐタイル」と称される。各連続するビデオフレームでは、Ｉタイルとしてエンコードされるべきタイルが変化される。従って、所与のフレーム時間では、ビデオフレーム内のタイルのうちの１つのタイルだけがＩタイルであり、そして残りのタイルがＰタイルである。例えば、図７ａでは、非圧縮フレーム７０１のタイル０がＩタイルＩ0としてエンコードされ、そして残りの１−１５タイルがＰタイルＰ1−Ｐ15としてエンコードされ、Ｒフレーム７１１を形成する。次の非圧縮ビデオフレーム７０２では、非圧縮フレーム７０１のタイル１がＩタイルＩ1としてエンコードされ、そして残りのタイル０及び２から１５がＰタイルＰ0及びＰ2からＰ15としてエンコードされ、Ｒフレーム７１２を形成する。従って、タイルとしてＩタイル及びＰタイルは、連続するフレームにわたり時間的に次々にインターリーブされる。このプロセスは、マトリクス内の最後のタイルがＩタイル（即ち、Ｉ15）としてエンコードされてＲタイル７７０が発生されるまで続く。次いで、このプロセスが再開されて、フレーム７１１のような別のＲフレームを発生する（即ち、タイル０に対してＩタイルをエンコードし、等々）。図７ａには示されていないが、一実施形態では、Ｒフレームのビデオシーケンスのうちの第１のＲフレームがＩタイルしか含まない（即ち、その後のＰフレームが、動きを計算するための基準映像データを有するように）。或いは又、一実施形態では、スタートアップシーケンスが、通常と同じＩタイルパターンを使用するが、Ｉタイルでまだエンコードされていないタイルに対してＰタイルを含まない。換言すれば、あるタイルは、第１のＩタイルが到着するまでデータでエンコードされず、従って、以下に詳細に述べる図９ａのビデオストリームデータレート９３４におけるスタートアップピークを回避する。更に、以下に述べるように、これらの基礎的な原理に依然適合しつつ、タイルに対して種々の異なるサイズ及び形状を使用することができる。
クライアント４１５で実行されるビデオ解凍ロジック４１２は、各タイルを、小さなＩ及びＰフレームの個別のビデオシーケンスであるかのように解凍し、次いで、各タイルをフレームバッファドライブディスプレイ装置４２２へレンダリングする。例えば、Ｒフレーム７１１ないし７７０からのＩ0及びＰ0を使用して、ビデオ映像のタイル０を解凍し、レンダリングする。同様に、Ｒフレーム７１１ないし７７０からのＩ1及びＰ1を使用して、タイル１を再構成し、等々となる。上述したように、Ｉフレーム及びＰフレームの解凍は、良く知られた技術であり、Ｉタイル及びＰタイルの解凍は、クライアント４１５で実行されるビデオ解凍の複数のインスタンスを得ることにより遂行することができる。乗算プロセスは、クライアント４１５の計算負担を増大すると思われるが、実際には、そうではない。というのは、タイルそれ自体は、付加的なプロセスの数に対し比例的に小さく、従って、表示されるピクセルの数は、１つのプロセスがあって従来のフルサイズのＩ及びＰフレームを使用する場合と同じだからである。
このＲフレーム技術は、図６ｂ及び６ｃに示したＩフレームに典型的に関連した帯域巾ピークを著しく軽減する。というのは、所与のフレームが、大抵は、Ｉフレームより典型的に小さなＰフレームで作られるからである。例えば、典型的なＩフレームが１６０Ｋｂであると再び仮定すれば、図７ａに示す各フレームのＩタイルは、この量のほぼ１／１６即ち１０Ｋｂとなる。同様に、典型的なＰフレームが１６Ｋｂであると仮定すれば、図７ａに示す各タイルのＰフレームは、ほぼ１Ｋｂとなる。最終の結果として、ほぼ１０Ｋｂ＋１５＊１Ｋｂ＝２５ＫｂのＲフレームとなる。従って、各６０フレームシーケンスは、２５Ｋｂ＊６０＝１．５Ｍｂｐｓとなる。従って、６０フレーム／秒では、これは、１．５Ｍｂｐｓの帯域巾を維持することのできるチャンネルを要求するが、Ｉタイルのために相当に低いピークが６０フレームインターバル全体にわたって分布される。
Ｉフレーム及びＰフレームに対して同じデータレートを仮定した先の例では、平均データレートが１．１Ｍｂｐｓであったことに注意されたい。これは、先の例では、新たなＩフレームが６０フレームの時間ごとに一度しか導入されず、一方、この例では、１６フレームの時間、ひいては、Ｉフレームに等しい時間でＩフレームサイクルを作り上げる１６個のタイルが１６フレームの時間ごとに導入され、著しく高い平均データレートとなるからである。実際に、より頻繁にＩフレームを導入しても、データレートを直線的に高めることはない。これは、Ｐフレーム（又はＰタイル）が主として手前のフレームから次のフレームへの相違をエンコードするという事実のためである。従って、手前のフレームが次のフレームにかなり類似している場合には、Ｐフレームが非常に小さくなり、一方、手前のフレームが次のフレームとかなり相違がある場合には、Ｐフレームが非常に大きくなる。しかし、Ｐフレームは、主として、実際のフレームではなく、手前のフレームから導出されるので、それにより生じるエンコードされたフレームは、充分なビット数でＩフレームより大きなエラー（例えば、視覚欠陥）を含むことができる。そして、１つのＰフレームに別のＰフレームが続くときには、エラーの蓄積が生じ、長いシーケンスのＰフレームがあるときには悪化する。ここで、精巧なビデオコンプレッサは、一連のＰフレームの後に映像のクオリティが低下することを検出し、必要に応じて、より多くのビットをその後続Ｐフレームに割り当てて、クオリティを上げるか、又はそれが最も効率的なアクションのコースである場合には、ＰフレームをＩフレームに置き換える。従って、長いシーケンスのＰフレーム（例えば、上述した例のように５９個のＰフレーム）が使用されるとき、特に、シーンが多大な複雑さ及び／又は動きを有するときには、典型的に、ＰフレームがＩフレームから更に離れるにつれて、より多くのビットがＰフレームに必要とされる。
或いは、Ｐフレームを逆の視点から見ると、Ｉフレームに接近して続くＰフレームは、Ｉフレームから更に離れたＰフレームよりビットを必要としない傾向がある。従って、図７ａに示す例では、先行するＩフレームから１５フレーム以上離れたＰフレームはなく、一方、先の例では、Ｐフレームは、Ｉフレームから５９フレーム離れることができる。従って、より頻繁にＩフレームがあると、Ｐフレームは、より小さくなる。もちろん、厳密な相対的サイズは、ビデオストリームの性質に基づいて変化するが、図７ａの例では、Ｉタイルが１０Ｋｂである場合、Ｐタイルは、平均で、０．７５Ｋｂのみのサイズとなり、１０Ｋｂ＋１５＊０．７５Ｋｂ＝２１．２５Ｋｂとなるか、又は６０フレーム／秒では、データレートは、２１．２５Ｋｂ＊６０＝１．３Ｍｂｐｓとなり、又はＩフレームの後に５９個のＰフレームが続く１．１Ｍｂｐｓのストリームより約１６％高いデータレートとなる。この場合も、ビデオ圧縮に対するこれら２つの解決策間の相対的な結果は、ビデオシーケンスに基づいて変化するが、典型的に、Ｒフレームを使用すると、Ｉ／Ｐフレームシーケンスを使用する場合より、所与のクオリティレベルに対して約２０％多くのビットを要求することが実験で分かった。しかし、当然、Ｒフレームは、ピークを劇的に減少させ、Ｉ／Ｐフレームシーケンスより遥かに短い待ち時間でビデオシーケンスを使用可能にする。
Ｒフレームは、ビデオシーケンスの性質、チャンネルの信頼性、及び利用できるデータレートに基づいて、種々の異なる仕方で構成することができる。別の実施形態では、４ｘ４構成の１６とは異なる数のタイルが使用される。例えば、２枚のタイルを２ｘ１又は１ｘ２構成で使用することができ、４枚のタイルを２ｘ２、４ｘ１又は１ｘ４構成で使用することができ、６枚のタイルを３ｘ２、２ｘ３、６ｘ１又は１ｘ６構成で使用することができ、或いは８枚のタイルを４ｘ２（図７ｂに示すような）、２ｘ４、８ｘ１又は１ｘ８構成で使用することができる。タイルは、方形である必要がなく、又、ビデオフレームも、方形又は長方形である必要がないことに注意されたい。タイルは、使用するビデオフレーム及びアプリケーションに最も適した形状に分割することができる。
別の実施形態では、Ｉ及びＰタイルのサイクルがタイルの数に固定されない。例えば、８タイルの４ｘ２構成では、図７ｂに示すように１６サイクルシーケンスを依然使用することができる。順次の非圧縮フレーム７２１、７２２、７２３は、各々、８枚のタイル、０−７に分割され、各タイルが個々に圧縮される。Ｒフレーム７３１から、タイル０だけがＩタイルとして圧縮され、残りのタイルは、Ｐタイルとして圧縮される。その後のＲフレーム７３２については、８枚のタイル全部がＰタイルとして圧縮され、次いで、その後のＲフレーム７３３については、タイル１がＩタイルとして圧縮され、そして他のタイル全部がＰタイルとして圧縮される。従って、１６個のフレームについてシーケンスが続き、Ｉタイルは、１つおきのフレームのみに発生され、最後のＩタイルは、１５番目のフレーム時間中にタイル７について発生され（図７ｂには示さず）、そして第１６番目のフレーム時間中に、全Ｐタイルを使用してＲフレーム７８０が圧縮される。次いで、タイル０がＩタイルとして圧縮されそして他のタイルがＰタイルとして圧縮されるようにしてシーケンスが再開される。先の実施形態と同様に、全ビデオシーケンスの各第１フレームは、典型的に、全てＩタイルであり、その点から前方へのＰタイルの基準を与える。Ｉタイル及びＰタイルのサイクルは、タイルの数の偶数倍である必要がない。例えば、８枚のタイルでは、Ｉタイルをもつ各フレームの後に、全てＰタイルをもつ２つのフレームが続き、その後に、別のＩタイルが使用される。更に別の実施形態では、あるタイルは、例えば、スクリーンのあるエリアがより多くの動きを有し頻繁なＩタイルを要求すると分かっているが、他のエリアはより静的であって（例えば、ゲームのスコアを示す）頻繁なＩタイルをほとんど要求しない場合に、Ｉタイルが他のタイルより頻繁にある状態でシーケンスされる。更に、各フレームは、図７ａ−ｂにおいて単一のＩタイルと共に示されているが、（送信チャンネルの帯域巾に基づいて）単一のフレーム内で複数のＩタイルをエンコードすることもできる。逆に、あるフレーム又はフレームシーケンスを、Ｉタイルなしで（即ち、Ｐタイルのみで）送信することもできる。
先の段落で述べた解決策が良く機能する理由は、各単一フレームにわたってＩタイルを分布させないことで、大きなピークを生じると思われるが、システムの挙動は、そのように単純ではないことである。各タイルは、他のタイルとは個別に圧縮されるので、タイルが小さくなるほど、各タイルのエンコーディングは、効率的でなくなる。というのは、所与のタイルのコンプレッサが、他のタイルからの類似映像特徴及び類似の動きを利用できないためである。従って、スクリーンを１６枚のタイルに分割すると、一般的に、スクリーンを８枚のタイルに分割する場合よりエンコーディングの効率が低下する。しかし、スクリーンが８枚のタイルに分割され、そして全Ｉフレームのデータを、１６フレームごとではなく８フレームごとに導入させる場合には、全体的に非常に高いデータレートとなる。従って、８フレームごとではなく１６フレームごとに全Ｉフレームを導入することにより、全体的なデータレートが減少される。又、１６枚の小さなタイルではなく８枚の大きなタイルを使用することにより、全データレートが減少され、大きなタイルにより生じるデータピークをある程度軽減させる。
別の実施形態では、図７ａ及び７ｂの短待ち時間のビデオ圧縮ロジック４０４は、Ｒフレームにおける種々のタイルへのビットの割り当てを、圧縮されるべきビデオシーケンスの既知の特性に基づく設定で予め構成することにより、或いは各タイルにおける映像クオリティの進行中の分析に基づいて自動的に、コントロールする。例えば、ある競争ビデオゲームでは、（シーンにおいて比較的動きの少ない）プレーヤの車の前部が、シーンの下半分の大部分を占有し、一方、シーンの上半分が、ほぼ常に動いている接近する道路、ビル及び風景で完全に埋められる。圧縮ロジック４０４が各タイルに等しい数のビットを割り当てる場合には、図７ｂの非圧縮フレーム７２１のスクリーンの下半分のタイル（タイル４−７）が、一般的に、図７ｂの非圧縮フレーム７２１のスクリーンの上半分のタイル（タイル０−３）より高いクオリティで圧縮される。この特定のゲーム又はゲームのこの特定のシーンがこのような特性を有すると分かっている場合には、ホスティングサービス２１０のオペレータは、スクリーンの下部のタイルよりスクリーンの上部のタイルにより多くのビットを割り当てるように圧縮ロジック４０４を構成することができる。或いは、圧縮ロジック４０４は、フレームが圧縮された後に（ピーク信号対雑音比（ＰＳＮＲ）のような多数の圧縮クオリティメトリックの１つ以上を使用して）タイルの圧縮のクオリティを評価することができ、そしてある時間ウインドウにわたり、あるタイルが高いクオリティの結果を一貫して生じると決定する場合に、種々のタイルが同様のクオリティレベルに達するまで、低いクオリティの結果を生じるタイルにより多くのビットを徐々に割り当てる。別の実施形態では、圧縮ロジック４０４は、特定のタイル又はタイルのグループに高いクオリティを得るようにビットを割り当てる。例えば、スクリーンの縁より中心部のクオリティを高くするように全体的に良好な知覚上の見掛けを与えることができる。
一実施形態では、ビデオストリームのある領域の解像度を改善するために、ビデオ圧縮ロジック４０４は、シーンの複雑さ及び／又は動きが比較的大きいビデオスクリーンのエリアを、シーンの複雑さ及び／又は動きが比較的小さいビデオスクリーンのエリアより小さいタイルを使用してエンコードする。例えば、図８に示すように、１つのＲフレーム８１１の１つのエリア内の動くキャラクタ８０５の周りに小さなタイルが使用される（潜在的に、その後に、同じタイルサイズをもつ一連のＲフレーム（図示せず）が続く）。次いで、キャラクタ８０５が映像の新たなエリアへ移動すると、図示されたように、別のＲフレーム８１２内のこの新たなエリアの周りに小さなタイルが使用される。上述したように、これらの基礎的な原理に依然合致しながら、種々の異なるサイズ及び形状を「タイル」として使用することができる。
上述した循環するＩ／Ｐタイルは、ビデオストリームのデータレートのピークを実質的に減少するが、特に、動画、ビデオゲーム及びあるアプリケーションソフトウェアで発生する急速に変化する又は非常に複雑なビデオ映像の場合には、ピークを完全に排除することができない。例えば、突然のシーンの移行中に、複雑なフレームの後に、完全に異なる別の複雑なフレームが続くことがある。多数のＩタイルが若干のフレームの時間だけシーンの移行に先行することがあっても、それらは、この状態において助けとならない。というのは、新たなフレーム資料が手前のＩタイルと関係がないからである。このような状態（及び何もかもが変化しなくても、多くの映像が変化する他の状態）では、ビデオコンプレッサ４０４は、Ｐタイルの全部でなくてもその多くがＩタイルとしてより効率的にコード化され、その結果、そのフレームに対するデータレートに非常に大きなピークが生じると決定する。
上述したように、ほとんどの消費者グレードのインターネット接続（及び多くのオフィス接続）では、図６ｃに６２２として示す利用可能な最大データレートを越えるデータを定格最大データレート６２１と共に「ジャム(jam)」することが単純に実行できないケースがある。定格最大データレート６２１（例えば、“６Ｍｂｐｓ ＤＳＬ”）は、インターネット接続の購入を考えるユーザにとって本質的にマーケッティングナンバーであるが、一般的に、性能のレベルを保証するものではない。本発明の説明上、これは、無関係である。というのは、ビデオが接続を通してストリーミングされるときには、利用可能な最大データレート６２２だけが問題だからである。その結果、図９ａ及び９ｃにおいて、ピークの問題に対する解決策を説明するときに、定格最大データレートがグラフから削除され、利用可能な最大データレート９２２だけが示される。ビデオストリームデータレートは、利用可能な最大データレート９２２を越えてはならない。
これに対処するために、ビデオコンプレッサ４０４が第１に実行すべきことは、チャンネルが着実に取り扱うことのできるデータレートであるピークデータレート９４１を決定することである。このレートは、多数の技術によって決定することができる。１つのこのような技術は、図４ａ及び４ｂにおいて、ホスティングサービス２１０からクライアント４１５へ次第に高いデータレートテストストリームを徐々に送信し、そしてクライアントがパケットロス及び待ち時間のレベルに関してホスティングサービスへフィードバックを与えるようにさせるものである。パケットロス及び／又は待ち時間が鋭い増加を示し始めるときには、それは、利用可能な最大データレート９２２に到達しつつあるという指示である。その後、ホスティングサービス２１０は、適度な期間中受け容れられるパケットロスレベルでテストストリームが受信され且つ待ち時間がほぼ最小であることをクライアント４１５が報告するまで、テストストリームのデータレートを徐々に減少することができる。これは、ピーク最大データレート９４１を確立し、これは、次いで、ストリーミングビデオのためのピークデータレートとして使用される。時間と共に、ピークデータレート９４１が変動し（例えば、家の別のユーザがインターネット接続を激しく使用し始める場合に）、そしてクライアント４１５は、それを常時監視して、パケットロス又は待ち時間が増大するかどうか調べる必要があり、利用可能な最大データレート９２２が以前に確立されたピークデータレート９４１より降下することを指示し、そしてもしそうであれば、ピークデータレート９４１を指示する。同様に、時間と共に、クライアント４１５は、パケットロス及び待ち時間が最適なレベルに保たれることを見つけた場合には、ビデオコンプレッサがデータレートをゆっくり増加して利用可能な最大データレートが増加したかどうか調べることを要求でき（例えば、家の別のユーザがインターネット接続の激しい使用を止めた場合に）、そして利用可能な最大データレート９２２を越えたことをパケットロス及び／又は長い待ち時間が指示し、ピークデータレート９４１に対して低いレベルを再び見つけることができるが、それがおそらく増加データレートのテストの前のレベルより高いものとなるまで、再び待機する。従って、この技術（及びそれに類似した他の技術）を使用することにより、ピークデータレート９４１を見つけて、必要に応じて、周期的に調整することができる。ピークデータレート９４１は、ユーザへビデオをストリーミングするためにビデオコンプレッサにより使用できる最大データレートを確立する。ピークデータレートを決定するためのロジックは、ユーザの家屋２１１及び／又はホスティングサービス２１０において具現化することができる。ユーザの家屋２１１において、クライアント装置４１５は、計算を行ってピークデータレートを決定し、そしてその情報をホスティングサービス２１０へ返送し、ホスティングサービス２１０において、ホスティングサービスのサーバー４０２は、クライアント４１５から受け取った統計情報（例えば、パケットロス、待ち時間、最大データレート、等）に基づいて、計算を行ってピークデータレートを決定する。
図９ａは、図７ａ、７ｂ及び図８に示されて上述した循環Ｉ／Ｐタイル圧縮技術を使用して発生された実質的なシーンの複雑さ及び／又は動きを有するビデオストリームデータレート９３４を例示する。ビデオコンプレッサ４０４は、ピークデータレート９４１より低い平均データレートで圧縮ビデオを出力するように構成され、ほとんどの時間、ビデオストリームデータレートは、ピークデータレート９４１より低く保たれることに注意されたい。Ｉ／Ｐ／Ｂ又はＩ／Ｐフレームを使用して生成された図６ｃに示すビデオストリームデータレート６３４とデータレート９３４との比較は、循環Ｉ／Ｐタイル圧縮が非常に滑らかなデータレートを発生することを示している。更に、フレーム２ｘピーク９５２（これは２ｘピークデータレート９４２に接近する）及びフレーム４ｘピーク９５４（これは４ｘピークデータレート９４４に接近する）において、データレートは、ピークデータレート９４１を越え、受け容れられない。実際に、迅速に変化するビデオゲームからの高アクションビデオでも、ピークデータレート９４１を越えるピークがフレームの２％未満で発生し、２ｘピークデータレート９４２を越えるピークがまれに発生し、そして３ｘピークデータレート９４３を越えるピークはほとんど発生しない。しかし、それらが（例えば、シーンの移行中に）発生するときには、それらによって要求されるデータレートは、良好なクオリティのビデオ映像を発生するのに必要なものである。
この問題を解決する１つの方法は、最大データレート出力がピークデータレート９４１となるようにビデオコンプレッサ４０４を単に構成することである。不都合なことに、それによりピークフレーム中に生じるビデオ出力のクオリティは、圧縮アルゴリズムがビットについて「欠乏」しているので、不充分である。その結果、突然の移行又は高速な動きがあるときに圧縮欠陥が現れ、やがて、ユーザは、突然の変化又は急速な動きがあるときに常に欠陥が現れ、それが極めて迷惑であることを悟る。
人間の視覚系は、突然の変化又は急速な動きの間に現れる視覚上の欠陥には極めて敏感であるが、このような状態におけるフレームレートの減少の検出にはあまり敏感でない。実際に、このような突然の変化が生じたときに、人間の視覚系は、変化を追跡することに心を奪われ、フレームレートが短時間で６０ｆｐｓから３０ｆｐｓへ降下し、次いで、即座に６０ｆｐｓへ復帰することに気付かないと思われる。そして、突然のシーンの切り換えのような非常に急激な移行の場合には、人間の視覚系は、フレームレートが２０ｆｐｓ又は１５ｆｐｓへ降下し、次いで、即座に６０ｆｐｓへ戻ることに気付かない。観察する人間にとってフレームレートの減少が時々生じるだけである限り、ビデオは、６０ｆｐｓで連続的に動作したかのように見える。
人間の視覚系のこの特性は、図９ｂに示す技術により利用される。サーバー４０２（図４ａ及び４ｂからの）は、一定のフレームレート（一実施形態では６０ｆｐｓ）の非圧縮ビデオ出力ストリームを発生する。時間線は、各フレーム９６１−９７０を各々１／６０秒で示している。各非圧縮ビデオフレームは、フレーム９６１でスタートして、短待ち時間のビデオコンプレッサ４０４へ出力され、これは、フレームを１フレーム時間未満で圧縮し、第１フレームとして圧縮フレーム１ ９８１を発生する。圧縮フレーム１ ９８１に対して発生されるデータは、上述したように、多数のファクタに基づいて大きくてもよいし小さくてもよい。データが、フレーム時間（１／６０秒）内又はピークデータレート９４１未満でクライアント４１５へ送信できるに充分なほど小さい場合には、それが送信時間（ｘｍｉｔ時間）９９１中に送信される（矢印の長さは、送信時間の巾を示す）。次のフレーム時間において、サーバー４０２は、非圧縮フレーム２ ９６２を発生し、これは、圧縮フレーム２ ９８２へと圧縮され、そしてピークデータレート９４１においてフレーム時間未満である送信時間９９２中にクライアント４１５へ送信される。
次いで、次のフレーム時間に、サーバー４０２は、非圧縮フレーム３ ９６３を発生する。これがビデオコンプレッサ４０４により圧縮されると、それにより生じる圧縮フレーム３ ９８３は、１フレーム時間にピークデータレート９４１で送信できる以上のデータとなる。従って、それは、全フレーム時間と次のフレーム時間の一部分とを取り上げた送信時間（２ｘピーク）９９３中に送信される。ここで、次のフレーム時間中に、サーバー４０２は、別の非圧縮フレーム４ ９６４を発生し、それをビデオコンプレッサ４０４へ出力するが、データは、無視され、９７４で示されている。これは、ビデオコンプレッサ４０４が、手前の圧縮フレームをまだ送信している間に到着する更に別の非圧縮ビデオフレームを無視するように構成されているからである。もちろん、クライアント４１５のビデオデコンプレッサは、フレーム４を受信せず、２フレームの時間中、フレーム３をディスプレイ装置４２２に単に表示し続ける（即ち、フレームレートを６０ｆｐｓから３０ｆｐｓへ簡単に減少する）。
次のフレーム５に対して、サーバー４０２は、非圧縮フレーム５ ９６５を出力し、これは、圧縮フレーム５ ９８５へと圧縮され、そして送信時間９９５中の１フレーム以内に送信される。クライアント４１５のビデオデコンプレッサは、フレーム５を解凍し、ディスプレイ装置４２２に表示する。次いで、サーバー４０２は、非圧縮フレーム６ ９６６を出力し、ビデオコンプレッサ４０４は、それを圧縮フレーム６ ９８６へと圧縮するが、このときには、得られるデータが非常に長い。圧縮フレームは、送信時間（４ｘピーク）９９６中にピークデータレート９４１で送信されるが、フレームを送信するのに、ほぼ４フレームの時間を要する。次の３フレームの時間中に、ビデオコンプレッサ４０４は、サーバー４０２からの３フレームを無視し、そしてクライアント４１５のデコンプレッサは、フレーム６を４フレームの時間中にディスプレイ装置４２２に着実に保持する（即ち、フレームレートを６０ｆｐｓから１５ｆｐｓへ簡単に減少する）。次いで、最終的に、サーバー４０２は、フレーム１０ ９７０を出力し、ビデオコンプレッサ４０４は、それを圧縮フレーム１０ ９８７へ圧縮し、これは、送信時間９９７中に送信され、そしてクライアント４１５のデコンプレッサは、フレーム１０を解凍してディスプレイ装置４２２に表示し、そしてもう一度ビデオが６０ｆｐｓで再開する。
ビデオコンプレッサ４０４は、サーバー４０２により発生されたビデオストリームからビデオフレームをドロップするが、オーディオがどんな形態で到来するかに関わらずオーディオデータはドロップせず、ビデオフレームがドロップされるときにオーディオデータを圧縮し続けて、それらをクライアント４１５へ送信し、クライアントは、オーディオデータを解凍し続け、そしてオーディオを、ユーザにより使用される装置へ供給し、オーディオを再生することに注意されたい。従って、オーディオは、フレームがドロップされる期間中は非減衰状態を続ける。圧縮オーディオは、圧縮ビデオに比して、帯域巾の比較的僅かな割合を消費するだけであり、その結果、全体的なデータレートに大きな影響は及ぼさない。いずれのデータレート図にも示されていないが、ピークデータレート９４１内で圧縮オーディオストリームに対して常にデータレート容量が予約されている。
図９ｂについて上述した例は、データレートピーク中にフレームレートがいかに降下するか示すために選択されたものであるが、先に述べた循環Ｉ／Ｐタイル技術が使用されるときに、そのようなデータレートピーク及びそれによりドロップされるフレームは、ビデオゲーム、動画及びあるアプリケーションソフトウェアにおいて生じるような高いシーン複雑さ／高いアクションのシーケンス中でもまれであることは、示されていない。従って、フレームレートの減少は、時々で且つ短時間であり、人間の視覚系は、それを検知しない。
上述したフレームレート減少メカニズムが、図９ａに示すビデオストリームデータレートに適用される場合に、それにより生じるビデオストリームデータレートが図９ｃに示されている。この例では、２ｘピーク９５２が平坦な２ｘピーク９５３へ減少され、４ｘピーク９５５が平坦な４ｘピーク９５５へ減少され、そして全ビデオストリームデータレート９３４がピークデータレート９４１以下に保たれる。
従って、上述した技術を使用して、高アクションビデオストリームを、一般的なインターネット及び消費者グレードのインターネット接続を通して短い待ち時間で送信することができる。更に、ＬＡＮ（例えば、１００Ｍｂｓイーサネット又は８０２．１１ｇワイヤレス）、或いはプライベートネットワーク（例えば、データセンターとオフィスとの間の１００Ｍｂｐｓ接続）におけるオフィス環境では、高アクションビデオストリームをピークなしに送信することができ、大勢のユーザ（例えば、４．５Ｍｂｐｓにおいて６０ｆｐｓで１９２０ｘ１０８０を送信する）が、ネットワーク又はネットワークスイッチバックプレーンを圧倒する重畳ピークをもたずに、ＬＡＮ又は共有プライベートデータ接続を使用できるようにする。
データレートの調整
一実施形態では、ホスティングサービス２１０は、最初、利用可能な最大データレート６２２及びチャンネルの待ち時間にアクセスして、ビデオストリームのための適当なデータレートを決定し、次いで、それに応答してデータレートを動的に調整する。データレートを調整するために、ホスティングサービス２１０は、例えば、映像の解像度、及び／又はクライアント４１５へ送信されるビデオストリームのフレーム数／秒を変更することができる。又、ホスティングサービスは、圧縮ビデオのクオリティレベルを調整することもできる。ビデオストリームの解像度を、例えば、１２８０ｘ７２０解像度から６４０ｘ３６０へ変更するときに、クライアント４１５のビデオ解凍ロジック４１２は、ディスプレイスクリーン上に同じ映像サイズを維持するように映像をスケールアップすることができる。
一実施形態では、チャンネルが完全にドロップアウトする状況において、ホスティングサービス２１０は、ゲームを休止する。マルチプレーヤゲームの場合には、ホスティングサービスは、ユーザがゲームからドロップアウトしたことを他のユーザに報告し、及び／又は他のユーザに対してゲームを休止する。
ドロップ又は遅延したパケット
一実施形態において、図４ａ又は４ｂにおけるビデオコンプレッサ４０４とクライアント４１５との間のパケットロスのために、或いはパケットが順序ずれして受け取られて、解凍するには遅過ぎ且つ解凍フレームの待ち時間要件を満足するには遅過ぎる到着であるために、データが失われる場合に、ビデオ解凍ロジック４１２は、視覚上の欠陥を軽減することができる。ストリーミングＩ／Ｐフレーム具現化において、失われ／遅延したパケットがある場合には、スクリーン全体に影響が及び、潜在的に、ある期間中スクリーンを完全に凍結させるか、又は他のスクリーン巾の視覚上の欠陥を表示させる。例えば、失われ／遅延したパケットがＩフレームの損失を生じさせる場合には、デコンプレッサは、それに続く全てのＰフレームに対する基準を、新たなＩフレームが受け取られるまで欠くことになる。Ｐフレームが失われた場合には、それに続く全スクリーンのためのＰフレームに影響を及ぼすことになる。Ｉフレームが現れるまでどれほど長いかに基づき、これは、長い又は短い視覚上の影響となる。図７ａ及び７ｂに示すインターリーブされたＩ／Ｐタイルを使用すると、失われ／遅延したパケットは、スクリーン全体に影響を及ぼすおそれが非常に僅かになる。というのは、影響を受けるパケットに含まれたタイルにしか影響しないからである。各タイルのデータが個々のパケット内で送信される場合には、パケットが失われた場合に、それが１つのタイルにしか影響しない。もちろん、視覚上の欠陥の巾は、Ｉタイルパケットが失われるかどうか、及びＰタイルが失われた場合には、Ｉタイルが現れるまでにどれほど多くのフレームを要するか、に依存する。しかし、スクリーン上の異なるタイルがＩフレームで頻繁に（潜在的にフレームごとに）更新されるとすれば、スクリーン上の１つのタイルが影響を受ける場合でも、他のタイルは、そうではない。更に、ある事象が一度に多数のパケットのロスを生じさせる場合には（例えば、ＤＳＬラインに続く電力のスパイクでデータ流を短時間中断するもの）、あるタイルが、他のタイル以上に影響を受けるが、あるタイルは、新たなＩタイルで素早く更新されるので、短時間影響を受けるだけである。又、ストリーミングＩ／Ｐフレーム具現化では、Ｉフレームが最も重要なフレームであるだけでなく、非常に大きなフレームでもあり、従って、ドロップされ／遅延されたパケットを生じさせる事象がある場合には、Ｉフレームが影響を受ける確率が、非常に小さなＩタイルより高くなる（即ち、Ｉフレームが一部分でも失われた場合には、Ｉフレームを解凍できる見込みが全くなくなる）。これら全ての理由で、Ｉ／Ｐタイルを使用すると、パケットがドロップされ／遅延されるときに、視覚上の欠陥は、Ｉ／Ｐフレームの場合より遥かに少なくなる。
一実施形態では、圧縮されたタイルをＴＣＰ（送信コントロールプロトコル）パケット又はＵＤＰ（ユーザデータグラムプロトコル）パケット内にインテリジェントにパッケージすることにより失われたパケットの作用を減少することが試みられる。例えば、一実施形態では、タイルが、可能であれば、パケット境界に整列される。図１０ａは、この特徴を具現化せずに、タイルを一連のパケット１００１−１００５内にどのようにパックするか示す。より詳細には、図１０ａにおいて、単一パケットのロスが複数のフレームのロスを生じるように、タイルがパケット境界に交差し、非効率的にパックされる。例えば、パケット１００３または１００４が失われる場合に、３つのタイルが失われ、視覚上の欠陥を招く。
対称的に、図１０ｂは、パケットロスの作用を減少するためにパケット内にタイルをインテリジェントにパッキングするためのタイルパッキングロジック１０１０を示す。第１に、タイルパッキングロジック１０１０は、タイルをパケット境界に整列させる。従って、タイルＴ１、Ｔ３、Ｔ４、Ｔ７及びＴ２は、各々、パケット１００１−１００５の境界に整列される。又、タイルパッキングロジックは、パケット境界に交差せずに、考えられる最も効率的な仕方で、パケット内にタイルを嵌合させることも試みる。各タイルのサイズに基づいて、タイルＴ１及びＴ６は、１つのパケット１００１内で合成され、Ｔ３及びＴ５は、１つのパケット１００２内で合成され、タイルＴ４及びＴ８は、１つのパケット１００３内で合成され、タイルＴ８は、パケット１００４に追加され、そしてタイルＴ２は、パケット１００５に追加される。従って、このスキムのもとでは、単一パケットのロスは、（図１０ａに示す３つのタイルではなく）２つ以下のタイルのロスを招くことになる。
図１０ｂに示す実施形態に対する１つの付加的な利益は、タイルが、映像内に表示されるのとは異なる順序で送信されることである。このように、隣接パケットが送信を妨げる同じ事象から失われた場合に、スクリーン上の互いに近隣でないエリアに影響を及ぼし、ディスプレイ上の欠陥をあまり目立たなくする。
一実施形態では、順方向エラー修正（ＦＥＣ）技術を使用して、ビデオストリームの幾つかの部分をチャンネルエラーから保護する。この技術で知られているように、リードソロモン及びビタビのようなＦＥＣ技術は、エラー修正データ情報を発生して、通信チャンネルを経て送信されるデータに添付させる。基礎的なデータ（例えば、Ｉフレーム）にエラーが発生した場合には、ＦＥＣを使用して、エラーを修正することができる。
ＦＥＣコードは、送信のデータレートを高め、従って、理想的には、それらが最も必要とされるところに使用されるだけである。非常に目立つ視覚上の欠陥を生じないデータが送信される場合には、データを保護するためにＦＥＣコードを使用しないのが好ましい。例えば、失われるＩタイルの直前のＰタイルは、スクリーン上に１／６０秒だけ視覚上の欠陥を生じさせる（即ち、スクリーン上のタイルは更新されない）。このような視覚上の欠陥は、人間の目でかろうじて検知できる。ＰタイルがＩタイルから更に後方にある場合には、Ｐタイルを失うと、益々目立つことになる。例えば、タイルサイクルパターンが、Ｉタイルの後に１５個のＰタイルが続き、その後、Ｉタイルが再び得られるというものである場合、Ｉタイルの直後のＰタイルが失われると、そのタイルは、１５フレームの時間中誤った映像を示すことになる（６０ｆｐｓでは、それは、２５０ｍｓである）。人間の目は、２５０ｍｓ間のストリームの中断は容易に検知する。従って、Ｐタイルが新たなＩタイルから更に後方にあるほど（即ち、Ｐタイルがより接近してＩタイルに続くほど）、欠陥がより目立ったものになる。上述したように、一般的に、Ｐタイルがより接近してＩタイルに続くほど、そのＰタイルに対するデータがより小さくなる。従って、Ｉタイルに続くＰタイルは、失われないよう保護するのがより重要であるだけでなく、サイズが小さいことも重要である。そして、一般的に、保護される必要のあるデータが小さいほど、それを保護するために必要なＦＥＣコードも小さくなる。
従って、図１１ａに示すように、一実施形態では、ビデオストリームにおけるＩタイルの重要性のために、ＩタイルだけにＦＥＣコードが与えられる。従って、ＦＥＣ１１０１は、Ｉタイル１１００に対するエラー修正コードを含み、そしてＦＥＣ１１０４は、Ｉタイル１１０３に対するエラー修正コードを含む。この実施形態では、Ｐタイルに対してＦＥＣは発生されない。
図１１ｂに示す一実施形態では、失われた場合に視覚上の欠陥を生じさせるおそれが最もあるＰタイルについてもＦＥＣコードが発生される。この実施形態では、ＦＥＣ１１０５は、最初の３つのＰタイルに対してエラー修正コードを与えるが、それに続くＰタイルについては与えない。別の実施形態では、データサイズが最も小さいＰタイルについてＦＥＣコードが発生される（Ｉタイルの後に最も早く発生して、保護することが最も重要なＰタイルを自己選択する傾向がある）。
別の実施形態では、ＦＥＣコードをタイルと共に送信するのではなく、タイルが２回、そのたびに異なるパケットで、送信される。１つのパケットが失われ／遅延された場合には、他のパケットが使用される。
図１１ｃに示す一実施形態では、ＦＥＣコード１１１１及び１１１３は、ビデオと同時にホスティングサービスから送信されるオーディオパケット１１１０及び１１１２に対して各々発生される。ビデオストリームにおいてオーディオの完全性を維持することが特に重要である。というのは、歪んだオーディオ（例えば、カチカチ音又はスー音）は、特に望ましからぬユーザの経験を招くからである。ＦＥＣコードは、オーディオコンテンツがクライアントコンピュータ４１５において歪なくレンダリングされることを保証する上で助けとなる。
別の実施形態では、ＦＥＣコードをオーディオデータと共に送信するのではなく、オーディオデータが２回、そのたびに異なるパケットで、送信される。１つのパケットが失われ／遅延された場合には、他のパケットが使用される。
更に、図１１ｄに示す一実施形態では、クライアント４１５からホスティングサービス２１０へと上流に送信されるユーザ入力コマンド１１２０及び１１２２（例えば、ボタン押圧）に対してＦＥＣコード１１２１及び１１２３が各々使用される。これは重要である。というのは、ビデオゲーム又はアプリケーションにおいてボタン押圧又はマウス移動が欠落すると、望ましからぬユーザ経験を招くからである。
別の実施形態では、ＦＥＣコードをユーザ入力コマンドデータと共に送信するのではなく、ユーザ入力コマンドデータが２回、そのたびに異なるパケットで、送信される。１つのパケットが失われ／遅延された場合には、他のパケットが使用される。
一実施形態では、ホスティングサービス２１０がクライアント４１５との通信チャンネルのクオリティを評価して、ＦＥＣを使用すべきかどうか決定し、もしそうであれば、ビデオ、オーディオ及びユーザコマンドのどの部分にＦＥＣを適用すべきか決定する。チャンネルの「クオリティ」を評価することは、上述したように、パケットロス、待ち時間、等を評価するようなファンクションを含む。チャンネルに特に信頼性がない場合には、ホスティングサービス２１０は、Ｉタイル、Ｐタイル、オーディオ及びユーザコマンドの全てにＦＥＣを適用することができる。対照的に、チャンネルに信頼性がある場合には、ホスティングサービス２１０は、オーディオ及びユーザコマンドのみにＦＥＣを適用するか、又はオーディオ又はビデオにＦＥＣを適用するか、或いはＦＥＣを全く使用しない。これら基礎的な原理に依然合致しながら、ＦＥＣの適用の種々の他の順列を使用することができる。一実施形態では、ホスティングサービス２１０は、チャンネルの状態を常時監視し、それに応じてＦＥＣポリシーを変更する。
別の実施形態では、図４ａ及び４ｂを参照すれば、パケットが失われ／遅延されてタイルデータを失うことになるか、又はおそらく特に悪いパケット損失のために、ＦＥＣが、失われたタイルデータを修正できない場合には、クライアント４１５は、新たなＩタイルが受け取られる前にどれほど多くのフレームが残っているか評価し、それをクライアント４１５からホスティングサービス２１０への往復待ち時間と比較する。その往復待ち時間が、新たなＩタイルが当然到着するまでのフレームの数より少ない場合には、クライアント４１５は、新たなＩタイルを要求するメッセージをホスティングサービス２１０へ送信する。このメッセージは、ビデオコンプレッサ４０４へルーティングされ、このコンプレッサは、データが失われたところのタイルに対してＰタイルを発生するのではなく、Ｉタイルを発生する。図４ａ及び４ｂに示すシステムが、典型的に８０ｍｓ未満の往復待ち時間を与えるように設計されているとすれば、それにより、タイルが８０ｍｓ以内に修正される（６０ｆｐｓにおいて、フレームは、１６．６７ｍｓの巾であり、従って、全フレームの時間において、８０ｍｓの待ち時間で、５フレームの時間である８３．３３ｍｓ以内にタイルが修正され、即ち、これは、目立った中断であるが、例えば、１５フレームに対する２５０ｍｓの中断よりは遥かに目立たないものである）。コンプレッサ４０４がその通常の循環順序からＩタイルを発生するときに、Ｉタイルによりそのフレームの帯域巾が利用可能な帯域巾を越える場合は、コンプレッサ４０４は、他のタイルのサイクルを遅延させて、他のタイルがそのフレーム時間中にＰタイルを受け取るようにし（１つのタイルが通常そのフレーム中に当然Ｉタイルであるべき場合でも）、次いで、次のフレームでスタートして、通常の循環が続き、そして通常はその手前のフレームでＩタイルを受信するタイルが、Ｉタイルを受信するようにする。このアクションは、Ｒフレーム循環の位相を短時間遅延するが、通常は、視覚上、目立つものではない。
ビデオ及びオーディオコンプレッサ／デコンプレッサ具現化
図１２は、マルチコア及び／又はマルチプロセッサ１２００を使用して８枚のタイルを並列に圧縮する１つの特定の実施形態を示す。一実施形態では、２．６６ＧＨｚ以上で動作するデュアルプロセッサ・クオドコアＸｅｏｎ ＣＰＵコンピュータシステムが使用され、各コアは、オープンソースｘ２６４ Ｈ．２６４コンプレッサを独立プロセスとして具現化する。しかしながら、これら基礎的な原理に依然合致しながら、種々の他のハードウェア／ソフトウェアコンフィギュレーションが使用されてもよい。例えば、ＣＰＵコアの各々を、ＦＰＧＡで具現化されるＨ．２６４コンプレッサに置き換えることができる。図１２に示す例では、コア１２０１−１２０８を使用して、Ｉタイル及びＰタイルを８個の独立したスレッドとして同時に処理する。この技術で良く知られているように、現在のマルチコア及びマルチプロセッサコンピュータシステムは、本来、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＸＰプロフェッショナルエディション（６４ビット又は３２ビットエディション）及びＬｉｎｕｘのようなマルチスレッドオペレーティングシステムと一体化されたときにマルチスレッディング可能である。
図１２に示す実施形態では、８個のコアの各々は、１つのタイルについてのみ役立つので、ｘ２６４の個別インスタンス生成を各々実行する他のコアとは主として独立して動作する。ＰＣＩ Ｅｘｐｒｅｓｓ ｘ１ベースのＤＶＩ捕獲カード、例えば、オランダ、オーステルハウトのマイクロトロニクスからのセンデロ・ビデオ・イメージングＩＰデベロープメント・ボードを使用して、６４０ｘ４８０、８００ｘ６００、又は１２８０ｘ７２０解像度で非圧縮ビデオを捕獲し、そしてこのカードのＦＰＧＡは、直接メモリアクセス（ＤＭＡ）を使用して、ＤＶＩバスを経て捕獲されたビデオをシステムＲＡＭへと転送する。タイルは、４ｘ２配列１２０５に配列される（それらは、方形タイルとして示されているが、この実施形態では、１６０ｘ２４０解像度である）。ｘ２６４の各インスタンス化は、８個の１６８ｘ２４０タイルの１つを圧縮するように構成され、そしてそれらは、最初のＩタイル圧縮の後に、各コアがサイクルに入り、各１つのフレームが他のフレームと位相ずれし、１つのＩタイル、その後、７つのＰタイルを圧縮するように、図１２に示すように、同期される。
フレーム時間ごとに、得られた圧縮されたタイルが、上述した技術を使用して、パケットストリームへと合成され、次いで、その圧縮されたタイルが、行先クライアント４１５へ送信される。
図１２には示されていないが、合成される８枚のタイルのデータレートが特定のピークデータレート９４１を越える場合には、その合成される８枚のタイルのデータが送信されてしまうまで必要に応じて多数のフレームの時間中、全部で８ｘ２６４のプロセスが保留される。
一実施形態では、クライアント４１５は、ＦＦｍｐｅｇの８個のインスタンスを実行するＰＣにおいてソフトウェアとして具現化される。受信プロセスは、８枚のタイルを受信し、そして各タイルは、ＦＦｍｐｅｇへルーティングされ、これは、タイルを解凍して、ディスプレイ装置４２２上の適当なタイル位置にレンダリングする。
クライアント４１５は、ＰＣの入力装置ドライバからキーボード、マウス、又はゲームコントローラ入力を受け取り、そしてそれをサーバー４０２へ送信する。サーバー４０２は、次いで、その受け取った入力装置データを、サーバー４０２で実行されるゲーム又はアプリケーションに適用し、サーバー４０２は、Ｉｎｔｅｌ ２．１６ＧＨｚＣｏｒｅ Ｄｕｏ ＣＰＵを使用してＷｉｎｄｏｗｓを実行するＰＣである。次いで、サーバー４０２は、新たなフレームを発生し、そしてそのＤＶＩ出力を通して、マザーボードベースのグラフィックシステムから、或いはＮＶＩＤＩＡ８８００ＧＴＸ ＰＣＩカードのＤＶＩ出力を通して、それを出力する。
同時に、サーバー４０２は、ゲーム又はアプリケーションにより形成されたオーディオを、そのデジタルオーディオ出力（例えば、Ｓ／ＰＤＩＦ）を通して出力し、これは、ビデオ圧縮を具現化するデュアルクオドコアＸｅｏｎベースＰＣのデジタルオーディオ入力に結合される。Ｖｏｒｂｉｓオープンソースオーディオコンプレッサは、プロセススレッドに対して利用可能なコアを使用して、オーディオをビデオと同時に圧縮するように使用される。一実施形態では、タイルの圧縮を完了するコアが、オーディオ圧縮を最初に実行する。圧縮されたオーディオは、次いで、圧縮されたビデオと共に送信され、そしてクライアント４１５においてＶｏｒｂｉｓオーディオデコンプレッサを使用して解凍される。
ホスティングサービスサーバーセンター配布
光ファイバのようなガラスを通る光は、真空中の光の速度の一部分で進行し、従って、光ファイバにおける光の厳密な伝播速度を決定することができる。しかし、実際には、ルーティング遅延の時間、送信の非効率さ、及び他のオーバーヘッドを考慮すると、インターネット上の最適な待ち時間は、光速のほぼ５０％の送信速度を反映することが観察される。従って、最適な１０００マイル往復待ち時間は、約２２ｍｓであり、そして最適な３０００マイル往復待ち時間は、約６４ｍｓである。従って、米国の一方の海岸にある単一のサーバーは、（３０００マイル程度離れた）他方の海岸にあるクライアントに望ましい待ち時間でサービスするには離れ過ぎている。しかしながら、図１３ａに示すように、ホスティングサービス２１０のサーバーセンター１３００が、米国の中央部（例えば、カンザス、ネブラスカ、等）に位置されて、米国大陸の任意の点までの距離が約１５００マイル以下となる場合には、往復インターネット待ち時間を３２ｍｓ程度に小さくすることができる。図４ｂを参照すれば、ユーザＩＳＰ４５３に許された最悪のケースの待ち時間は、典型的に、２５ｍｓであるが、ＤＳＬ及びケーブルモデムシステムでは、１０から１５ｍｓに近い待ち時間が観察されていることに注意されたい。又、図４ｂは、ユーザの家屋２１１からホスティングセンター２１０までの最大距離が１０００マイルであると仮定している。従って、１５ｍｓの典型的なユーザＩＳＰ往復待ち時間が使用され、３２ｍｓの往復待ち時間に対して１５００マイルの最大インターネット距離では、ユーザが入力装置４２１を操作しそしてディスプレイ装置４２２上に応答を見る点からの合計往復待ち時間は、１＋１＋１５＋３２＋１＋１６＋６＋８＝８０ｍｓとなる。従って、８０ｍｓの応答時間が、典型的に、１５００マイルのインターネット距離にわたって得られる。これは、米国大陸において充分短いユーザＩＳＰ待ち時間４５３をもつユーザの家屋が、中央部に位置する単一のサーバーにアクセスできるようにする。
図１３ｂに示した別の実施形態では、ホスティングサービス２１０のサーバーセンターＨＳ−１ないしＨＳ６が、米国（又は他の地理的領域）に戦略的に配置され、ある大きなホスティングサービスサーバーセンター（例えば、ＨＳ２及びＨＳ５）は、人口の多いセンターの付近に配置される。一実施形態では、サーバーセンターＨＳ１ないしＨＳ６は、インターネット又はプライベートネットワーク或いはその両方の組合せであるネットワーク１３０１を経て情報を交換する。複数のサーバーセンターがある状態では、長いユーザＩＳＰ待ち時間４５３をもつユーザに対して短い待ち時間でサービスを提供することができる。
インターネット上の距離は、確実に、インターネットを通しての往復待ち時間に貢献するファクタであるが、時々、待ち時間にあまり関係のない他のファクタが影響するようになる。時々、パケットストリームがインターネットを通して離れた位置へルーティングされそして再び戻り、長いループから待ち時間を招く。時々、適切に動作しないルーティング装置が経路上にあり、送信遅延を招く。時々、経路に過負荷となるトラフィックがあって、遅延を導入する。そして、時々、ユーザのＩＳＰが所与の行先へルーティングされるのを全く阻止する故障が生じる。従って、一般的なインターネットは、通常、距離により主として決定される非常に信頼性のある最適なルート及び待ち時間で（特に、ユーザのローカルエリアの外部へのルートを生じさせる長距離接続で）、ある点から別の点への接続を与えるが、このような信頼性及び待ち時間は、保証されるものではなく、多くの場合、ユーザの家屋から一般的なインターネット上の所与の行先まで得ることができない。
一実施形態では、ユーザクライアント４１５が、最初にホスティングサービス２１０に接続して、ビデオゲームをプレイするか又はアプリケーションを使用するときに、クライアントは、始動時に利用可能なホスティングサービスサーバーセンターＨＳ１ないしＨＳ６の各々と通信する（例えば、上述した技術を使用して）。特定の接続に対して待ち時間が充分短い場合には、その接続が使用される。一実施形態では、クライアントは、最短待ち時間接続をもつものが選択されたところのホスティングサービスサーバーセンターの全部又はサブセットと通信する。クライアントが最短待ち時間接続をもつサービスセンターを選択してもよいし、又はサービスセンターが最短的時間接続をもつものを識別しそしてこの情報を（例えば、インターネットアドレスの形態で）クライアントに与えてもよい。
特定のホスティングサービスサーバーセンターが過負荷状態になり及び／又はユーザのゲーム又はアプリケーションが、別の負荷の少ないホスティングサービスサーバーセンターへの待ち時間を許容できる場合には、クライアント４１５は、他のホスティングサービスサーバーセンターに向け直される。このような状況では、ユーザが実行しているゲーム又はアプリケーションは、ユーザの過負荷状態にサーバーセンターにおけるサーバー４０２上で休止され、そしてゲーム又はアプリケーションの状態データは、別のホスティングサービスサーバーセンターにおけるサーバー４０２へ転送される。次いで、ゲーム又はアプリケーションが再開される。一実施形態では、ホスティングサービス２１０は、ゲーム又はアプリケーションが自然の休止点（例えば、ゲームにおけるレベル間、又はユーザがアプリケーションにおいて「セーブ」オペレーションを開始した後）に到達して転送を行うまで、待機する。更に別の実施形態では、ホスティングサービス２１０は、ユーザのアクティビティが特定の期間中（例えば１分間）休止するまで待機し、次いで、その時点で転送を開始する。
上述したように、一実施形態では、ホスティングサービス２１０は、そのクライアントに保証された待ち時間を与えるよう試みるために、図１４のインターネットバイパスサービス４４０に契約する。ここで使用されるインターネットバイパスサービスとは、保証された特性（例えば、待ち時間、データレート、等）をもつインターネットにおいてある点から別の点へのプライベートネットワークルートを与えるサービスである。例えば、ホスティングサービス２１０が、ＡＴ＆Ｔのサンフランシスコベースの中央オフィスへのルーティングではなく、サンフランシスコで提供されるＡＴ＆ＴのＤＳＬサービスを利用してユーザから大量のトラフィックを受信した場合に、ホスティングサービス２１０は、サンフランシスコベースの中央オフィスと、ホスティングサービス２１０のための１つ以上のサービスセンターとの間のサービスプロバイダー（おそらくＡＴ＆Ｔそれ自体又は別のプロバイダー）から大容量のプライベートデータ接続をリースすることができる。次いで、全てのホスティングサービスサーバーセンターＨＳ１ないしＨＳ６から一般的なインターネットを経てＡＴ＆ＴのＤＳＬを使用するサンフランシスコのユーザへのルートが非常に長い待ち時間を生じる場合には、それに代わって、プライベートデータ接続を使用することができる。プライベートデータ接続は、一般的に、一般的なインターネットを通るルートより費用が高いが、それがユーザへのホスティングサービス２１０接続の僅かな割合に保たれる限り、全コストへの影響は低く、ユーザは、より一貫したサービスを経験することになる。
サービスセンターは、多くの場合、停電時に２層のバックアップ電源を有する。第１の層は、典型的に、バッテリから（又は発電機に取り付けられてランニング状態に保たれるフライホイールのような別の直ちに利用できるエネルギー源から）のバックアップ電源であって、主電源が停電したときに直ちに電力を供給して、サーバーセンターをランニング状態に保持する。停電が短時間で、主電源が素早く（例えば、１分以内に）回復する場合には、バッテリは、全て、サーバーセンターをランニング状態に保持するために必要とされる。しかし、停電が長期間である場合には、典型的に、発電機（例えば、ジーゼル付勢）が始動され、バッテリを引き継いで、燃料がある限り運転することができる。このような発電機は、サーバーセンターが通常主電源から得るのと同程度の電力を発生できねばならないので、非常に高価である。
一実施形態では、ホスティングサービスＨＳ１ないしＨＳ５の各々は、互いにユーザデータを共有し、１つのサーバーセンターが停電した場合に、進行中のゲーム及びアプリケーションを休止し、次いで、ゲーム又はアプリケーションの状態データを各サーバー４０２から他のサーバーセンターのサーバー４０２へ転送し、そして各ユーザのクライアント４１５に通知して、新たなサーバー４０２と通信するように指令する。このような状態が頻繁に生じないとすれば、最適な待ち時間を与えることのできないホスティングサービスサーバーセンターへのユーザの転送を受け容れることができ（即ち、ユーザは、単に停電期間中に長い待ち時間を許容するだけでよく）、これは、ユーザを転送するための非常に広範囲のオプションを許す。例えば、米国を横切る時間ゾーン差が与えられると、東海岸のユーザは、ＰＭ１１時３０分には就寝するが、ＰＭ８時３０分の西海岸のユーザは、ビデオゲームの使用がピークになり始めている。その時間に西海岸のホスティングサービスサーバーセンターに停電が生じた場合に、他のホスティングサービスサーバーセンターには、全てのユーザを取り扱うに充分な西海岸サーバー４０２が存在しないことがある。このような状況では、利用できるサーバー４０２を有する東海岸のホスティングサービスサーバーセンターへあるユーザを転送することができ、それらユーザに対してのみ長い待ち時間となる。ユーザが、停電したサーバーセンターから転送されると、サーバーセンターは、次いで、そのサーバー及び装置の整然とした遮断を開始し、バッテリ（又は他の即座の電源バックアップ）が尽きるまでに全ての装置を遮断することができる。このように、サーバーセンター用の発電機のコストを回避することができる。
一実施形態では、ホスティングサービス２１０の激しい負荷の時間中に（ピークユーザ負荷によるか、又は１つ以上のサーバーセンターが停電したために）、ユーザは、彼等が使用しているゲーム又はアプリケーションの待ち時間要件に基づいて他のサーバーセンターへ転送される。従って、短待ち時間を要求するゲーム又はアプリケーションを使用しているユーザは、電源に制限があるときに、利用可能な短待ち時間サーバー接続への優先権が与えられる。
ホスティングサービスの特徴
図１５は、以下の特徴説明に使用されるホスティングサービス２１０のためのサーバーセンターのコンポーネントの実施形態を示す。図２ａに示されたホスティングサービス２１０と同様に、サーバーセンターのコンポーネントは、特に指示のない限り、ホスティングサービス２１０の制御システム４０１により制御され整合される。
ユーザクライアント４１５からのインバウンドインターネットトラフィック１５０１は、インバウンドルーティング１５０２に向けられる。典型的に、インバウンドインターネットトラフィック１５０１は、インターネットへの高速光ファイバ接続を経てサーバーセンターに入るが、適当な帯域巾、信頼性及び短待ち時間のネットワーク接続手段で充分である。インバウンドルーティング１５０２は、ネットワーク（ネットワークは、イーサネットネットワーク、ファイバチャンネルネットワークとして、或いは他の搬送手段を経て具現化できる）スイッチ、及びスイッチをサポートするルーティングサーバーのシステムであり、これは、到着するパケットを取り上げ、そして各パケットを適当なアプリケーション／ゲーム（ａｐｐ／ｇａｍｅ）サーバー１５２１−１５２５へルーティングする。一実施形態では、特定のａｐｐ／ｇａｍｅサーバーに配送されるパケットは、クライアントから受信されたデータのサブセットを表し、及び／又はデータセンター内の他のコンポーネント（例えば、ゲートウェイ及びルーターのようなネットワークコンポーネント）によって変換／変更されてもよい。あるケースでは、例えば、ゲーム又はアプリケーションが複数のサーバー上で並列に一度実行される場合に、パケットが一度に２つ以上のサーバー１５２１−１５２５へルーティングされる。ＲＡＩＤアレイ１５１１−１５１２は、インバウンドルーティングネットワーク１５０２へ接続され、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５がそれらＲＡＩＤアレイ１５１１−１５１２の読み取り及び書き込みを行えるようにする。更に、ＲＡＩＤアレイ１５１５（複数のＲＡＩＤアレイとして具現化できる）も、インバウンドルーティング１５０２に接続され、ＲＡＩＤアレイ１５１５からのデータは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５から読み出すことができる。インバウンドルーティング１５０２は、インバウンドインターネットトラフィック１５０１を根にもつスイッチのツリー構造、全ての種々の装置を相互接続するメッシュ構造、或いは相互通信装置間の集中トラフィックが他の装置間の集中トラフィックから分離されるようにして相互接続された一連のサブネットを含めて、広範囲な従来のネットワークアーキテクチャーで具現化することができる。ネットワークコンフィギュレーションの一形式は、ＳＡＮであり、これは、典型的に記憶装置として使用されるが、装置間の一般的な高速データ転送に使用することもできる。又、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、各々、インバウンドルーティング１５０２への複数のネットワーク接続を有する。例えば、サーバー１５２１−１５２５は、ＲＡＩＤアレイ１５１１−１５１２に取り付けられたサブネットへのネットワーク接続と、他の装置に取り付けられたサブネットへの別のネットワーク接続とを有することができる。
ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、図４ａに示す実施形態におけるサーバー４０２に関して上述したように、全部が同じに、幾つかが異なるように、又は全部が異なるように構成されてもよい。一実施形態では、各ユーザは、ホスティングサービスを利用するときに、典型的に、少なくとも１つのａｐｐ／ｇａｍｅサーバー１５２１−１５２５を使用する。説明を簡略化するため、所与のユーザがａｐｐ／ｇａｍｅサーバー１５２１を使用すると仮定するが、１人のユーザが複数のサーバーを使用することができると共に、複数のユーザが単一のａｐｐ／ｇａｍｅサーバー１５２１−１５２５を共有することができる。上述したようにクライアント４１５から送られるユーザ制御入力は、インバウンドインターネットトラフィック１５０１として受け取られ、そしてインバウンドルーティング１５０２を通してａｐｐ／ｇａｍｅサーバー１５２１へルーティングされる。ａｐｐ／ｇａｍｅサーバー１５２１は、ユーザの制御入力を、サーバー上で実行されるゲーム又はアプリケーションへの制御入力として使用し、そしてビデオ及びそれに関連したオーディオの次のフレームを計算する。次いで、ａｐｐ／ｇａｍｅサーバー１５２１は、非圧縮のビデオ／オーディオ１５２９を共有ビデオ圧縮１５３０へ出力する。ａｐｐ／ｇａｍｅサーバーは、非圧縮のビデオを、１ギガビット以上のイーサネット接続を含む手段を経て出力できるが、一実施形態では、ビデオがＤＶＩ接続を経て出力され、そしてオーディオ及び他の圧縮並びに通信チャンネル状態情報は、ユニバーサルシリアルバス（ＵＳＢ）接続を経て出力される。
共有ビデオ圧縮１５３０は、ａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５からの非圧縮ビデオ及びオーディオを圧縮する。圧縮は、完全にハードウェアで具現化されてもよいし、又はハードウェア実行ソフトウェアで具現化されてもよい。各ａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５に対する専用コンプレッサがあってもよいし、又はコンプレッサが充分高速である場合には、所与のコンプレッサを使用して、２つ以上のａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５からのビデオ／オーディオを圧縮することができる。例えば、６０ｆｐｓでは、ビデオフレーム時間は、１６．６７ｍｓである。コンプレッサがフレームを１ｍｓで圧縮できる場合には、そのコンプレッサを使用して、１６個程度のａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５からのビデオ／オーディオを圧縮することができ、これは、あるサーバーからの入力を別のサーバーの後に取り上げ、コンプレッサが各ビデオ／オーディオ圧縮プロセスの状態をセーブし、そしてコンテクストを、それがサーバーからのビデオ／オーディオストリーム間で循環するときにスイッチすることにより行われる。その結果、圧縮ハードウェアにおいて実質的なコスト節約が得られる。異なるサーバーが異なる時間にフレームを完了するので、一実施形態では、コンプレッサリソースが、各圧縮プロセスの状態を記憶するための共有記憶手段（例えば、ＲＡＭ、フラッシュ）と共に共有プール１５３０にあり、サーバー１５２１−１５２５のフレームが完了して圧縮の準備ができると、制御手段は、どの圧縮リソースがそのとき利用できるか決定し、圧縮リソースに、サーバーの圧縮プロセスの状態と、圧縮すべき非圧縮ビデオ／オーディオのフレームとを与える。
各サーバーの圧縮プロセスの状態の一部分は、圧縮それ自体に関する情報、例えば、Ｐタイルの基準として使用できる以前のフレームの解凍フレームバッファデータ、ビデオ出力の解像度；圧縮のクオリティ；タイル構造；タイル当たりのビットの割り当て；圧縮のクオリティ、オーディオフォーマット（例えば、ステレオ、サラウンドサウンド、Ｄｏｌｂｙ（登録商標）、ＡＣ−３）を含むことに注意されたい。しかし、圧縮プロセスの状態は、ピークデータレート９４１に関する通信チャンネル状態情報、以前のフレーム（図９ｂに示す）が現在出力されるかどうか（その結果、現在フレームを無視すべきかどうか）、そして潜在的に、圧縮に考慮すべきチャンネル特性、例えば、圧縮の判断に影響する過剰なパケットロス（例えば、Ｉタイルの頻度、等に関して）があるかどうか、も含む。クライアント４１５から送られるデータを監視する各ユーザをサポートするａｐｐ／ｇａｍｅサーバー１５２１−１５２５により決定されるように、ピークデータレート９４１又は他のチャンネル特性が時間と共に変化するときに、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、共有ハードウェア圧縮１５３０へ関連情報を送信する。
又、共有ハードウェア圧縮１５３０は、上述したような手段を使用して、圧縮されたビデオ／オーディオをパケット化し、そしてもし適当であれば、ＦＥＣコードを適用し、あるデータを複写し、又は他のステップを行って、ビデオ／オーディオデータストリームをクライアント４１５により受信しそしてできるだけ高いクオリティ及び信頼性で解凍するという能力を充分に確保するようにする。
以下に述べるような幾つかのアプリケーションでは、所与のａｐｐ／ｇａｍｅサーバー１５２１−１５２５のビデオ／オーディオ出力を同時に複数の解像度で（又は他の複数のフォーマットで）得られることが要求される。従って、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５が共有ハードウェア圧縮１５３０のリソースを通知する場合には、そのａｐｐ／ｇａｍｅサーバー１５２１−１５２５の非圧縮ビデオ／オーディオ１５２９が、異なるフォーマット、異なるリソース、及び／又は異なるパケット／エラー修正構造で同時に圧縮される。あるケースでは、幾つかの圧縮リソースを、同じビデオ／オーディオを圧縮する複数の圧縮プロセス間で共有することができる（例えば、多くの圧縮アルゴリズムには、圧縮を適用する前に映像を複数のサイズにスケーリングするステップがある。異なるサイズの映像を出力することが要求される場合に、このステップを使用して、一度に多数の圧縮プロセスに応じることができる）。他のケースでは、フォーマットごとに個別の圧縮リソースが要求される。いずれにせよ、所与のａｐｐ／ｇａｍｅサーバー１５２１−１５２５に要求される全ての種々の解像度及びフォーマットの圧縮されたビデオ／オーディオ１５３９は、（１つであっても多数であっても）アウトバウンドルーティング１５４０へ一度に出力される。一実施形態では、圧縮されたビデオ／オーディオ１５３９の出力はＵＤＰフォーマットであり、従って、パケットの位置方向性ストリームである。
アウトバウンドルーティングネットワーク１５４０は、圧縮された各ビデオ／オーディオストリームを、アウトバウンドインターネットトラフィック１５９９インターフェイス（これは、典型的に、インターネットへのファイバインターフェイスに接続される）を通して意図されたユーザ（１人又は複数）又は他の行先へ向け、及び／又は遅延バッファ１５１５へ戻し、及び／又はインバウンドルーティング１５０２へ戻し、及び／又はビデオ配布のためにプライベートネットワーク（図示せず）を通して向ける一連のルーティングサーバー及びスイッチを備えている。（以下に述べるように）アウトバウンドルーティング１５４０は、所与のビデオ／オーディオストリームを一度に複数の行先へ出力できることに注意されたい。一実施形態では、これは、一度に複数の行先へストリーミングされることが意図された所与のＵＤＰストリームをブロードキャストし、そしてこのブロードキャストをアウトバウンドルーティング１５４０内のルーティングサーバー及びスイッチにより繰り返すようなインターネットプロトコル（ＩＰ）マルチキャストを使用して具現化される。ブロードキャストの複数の行先は、インターネットを経て複数のユーザのクライアント４１５、インバウンドルーティング１５０２を経て複数のａｐｐ／ｇａｍｅサーバー１５２１−１５２５、及び／又は１つ以上の遅延バッファ１５１５である。従って、所与のサーバー１５２１−１５２２の出力は、１つ又は複数のフォーマットへ圧縮され、そして各圧縮されたストリームは、１つ又は複数の行先へ向けられる。
更に、別の実施形態では、複数のａｐｐ／ｇａｍｅサーバー１５２１−１５２５が１人のユーザにより同時に使用され（例えば、複雑なシーンの３Ｄ出力を生成するために並列処理構成で）そして各サーバーが出来上がる映像の一部分を発生する場合には、複数のサーバー１５２１−１５２５のビデオ出力を共有ハードウェア圧縮１５３０により合成フレームへと合成することができ、そしてその点以降は、それが単一のａｐｐ／ｇａｍｅサーバー１５２１−１５２５から到来したかのように、上述したように取り扱われる。
一実施形態では、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５により発生される全ビデオのコピー（少なくともユーザが見るビデオの解像度又はそれ以上）が、少なくとも数分（一実施形態では、１５分）、遅延バッファ１５１５に記録されることに注意されたい。これは、各ユーザが、以前の働き又は成績（ゲームの場合）を再検討するために各セッションからビデオを「巻き戻し」できるようにする。従って、一実施形態では、ユーザクライアント４１５へルーティングされる圧縮された各ビデオ／オーディオ出力１５３９のストリームは、遅延バッファ１５１５へもマルチキャストされる。ビデオ／オーディオが遅延バッファ１５１５に記憶されるときには、遅延バッファ１５１５のディレクトリが、遅延されたビデオ／オーディオのソースであるａｐｐ／ｇａｍｅサーバー１５２１−１５２５のネットワークアドレスと、遅延されたビデオ／オーディオを見つけることのできる遅延バッファ１５１５上の位置との間の相互参照を与える。
生の、瞬時に見られる、瞬時にプレイ可能なゲーム
ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ユーザのための所与のアプリケーション又はビデオゲームを実行するのに使用できるだけでなく、ホスティングサービス２１０によるナビゲーション及び他の特徴をサポートするホスティングサービス２１０のためのユーザインターフェイスアプリケーションを生成するのにも使用できる。１つのこのようなユーザインターフェイスアプリケーションのスクリーンショットが図１６に示されており、即ち「ゲームファインダー」スクリーンである。この特定のユーザインターフェイススクリーンは、ユーザが、他のユーザにより生で（又は遅延されて）プレイされている１５のゲームを見ることができるようにする。１６００のような「サムネール」ビデオウインドウの各々は、動きのある生のビデオウインドウで、１人のユーザのゲームから１つのビデオを示している。サムネールに示される視野は、ユーザが見ている同じ視野でもよいし、遅延された視野でもよい（例えば、ユーザがコンバットゲームをプレイする場合、ユーザは、自分がどこに隠れているか他のユーザから見えるのを望まず、又、ゲームプレイの視野を、ある期間、例えば、１０分遅らせることを選択してもよい）。又、視野は、ユーザの視野とは異なるゲームのカメラ視野でもよい。メニュー選択肢（この図には示さず）を通して、ユーザは、種々の基準に基づいて、一度に見るゲームの選択を選ぶことができる。例示的選択の小さな例として、ユーザは、（図１６に示すような）ゲームのランダムな選択、（異なるプレーヤにより全てプレイされる）一種類の全てのゲーム、ゲームのトップランクプレーヤのみ、ゲームの所与のレベルのプレーヤ、低いランクのプレーヤ（例えば、プレーヤが基礎を学習している場合）、「相棒」（又はライバル）であるプレーヤ、視聴者の最も多いゲーム、等を選ぶことができる。
一般的に、各ユーザは、自分のゲーム又はアプリケーションからのビデオが他人に見られるかどうか判断し、もしそうであれば、どんな他人、いつ他人に見られるか、遅れて見られるだけかどうか、判断することに注意されたい。
図１６に示すユーザインターフェイススクリーンを発生するａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ゲームが要求される各ユーザについてａｐｐ／ｇａｍｅサーバー１５２１−１５２５へメッセージを送信することにより１５個のビデオ／オーディオフィードを取得する。このメッセージは、インバウンドルーティング１５０２又は別のネットワークを通して送信される。このメッセージは、要求されたビデオ／オーディオのサイズ及びフォーマットを含み、ユーザインターフェイススクリーンを見ているユーザを識別する。所与のユーザは、「プライバシー」モードを選択し、他のユーザが彼のゲームのビデオ／オーディオを（彼の視点又は別の視点から）見るのを許さないことを選ぶか、或いは前記段落で述べたように、ユーザは、彼のゲームからのビデオ／オーディオを見るのを許すが、見るビデオ／オーディオを遅らせることを選んでもよい。ビデオ／オーディオを見ることを許すための要求を受け取って受け容れるユーザａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、要求側サーバーに確認を送り、共有ハードウェア圧縮１５３０に、要求されたフォーマット又はスクリーンサイズで付加的な圧縮されたビデオストリームを発生する要求も通知し（フォーマット及びスクリーンサイズが、既に発生されたものとは異なると仮定すれば）、そしてその圧縮されたビデオの行先（即ち、要求側サーバー）も指示する。要求されたビデオ／オーディオが遅延されるだけである場合には、要求側ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、そのように通知され、そして遅延バッファ１５１５のディレクトリにおけるビデオ／オーディオの位置と、遅延されたビデオ／オーディオのソースであるａｐｐ／ｇａｍｅサーバー１５２１−１５２５のネットワークアドレスとをルックアップすることにより、遅延バッファ１５１５から遅延されたビデオ／オーディオを取得する。これらの要求が全て発生されて処理されると、１５までの生のサムネールサイズのビデオストリームが、アウトバウンドルーティング１５４０から、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５へのインバウンドルーティング１５０２へルーティングされて、ユーザインターフェイススクリーンを発生し、そしてサーバーにより解凍されて表示される。遅延されたビデオ／オーディオストリームは、スクリーンサイズが大き過ぎることがあり、もしそうであれば、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ストリームを解凍して、ビデオストリームをサムネールサイズへスケールダウンする。一実施形態では、オーディオ／ビデオのための要求が、図４ａのホスティングサービス制御システムと同様の中央「管理」サービス（図１５には示さず）へ送られ（及びそれにより管理され）、これは、次いで、その要求を適当なａｐｐ／ｇａｍｅサーバー１５２１−１５２５へ向け直す。更に、一実施形態では、サムネールが、それを許すユーザのクライアントへ「プッシュ」されるので、要求が発せられないこともある。
全て同時に混合される１５個のゲームからのオーディオは、不快な音を発することがある。ユーザは、このように全ての音を一緒に混合することを選んでもよいし（おそらく、見ている全てのアクションにより生じる騒音の感覚を単に得るために）、又はユーザは、一度に１つのゲームからのオーディオのみを聞くことを選んでもよい。単一ゲームの選択は、黄色の選択ボックス１６０１を所与のゲームへ移動することにより達成される（黄色のボックスの移動は、キーボード上の矢印キーを使用するか、マウスを移動するか、ジョイスティックを動かすか、又は移動電話のような別の装置の方向ボタンを押すことにより達成できる）。単一のゲームが選択されると、そのゲームからのオーディオだけが再生される。又、ゲーム情報１６０２も示される。このゲームの場合には、例えば、発行者ロゴ（“ＥＡ”）及びゲームロゴ“Need for Speed Carbon”、及びオレンジの水平バーは、その特定の瞬間にゲームをプレイするか又は見ている人々の数を相対的な表現で指示する（この場合は、多数、従って、ゲームは、「ホット」）。更に、「スタッツ(Stats)」も設けられ、これは、１４５人のプレーヤがNeed for Speed Gameの８０個の異なるインスタンス化を能動的にプレイしており（即ち、個人プレーヤゲーム又はマルチプレーヤゲームのいずれかによりプレイできる）、そして６８０人の視聴者がいる（このユーザは、そのうちの１人である）ことを示している。これらの統計値（及び他の統計値）は、ホスティングサービス２１０のオペレーションのログを保持すると共に、ユーザに適宜請求し、又、コンテンツを提供する発行者に支払するために、ホスティングサービス制御システム４０１により収集され、そしてＲＡＩＤアレイ１５１１−１５１２に記憶される。統計値のあるものは、サービス制御システム４０１によりアクションによって記録され、そしてあるものは、個々のａｐｐ／ｇａｍｅサーバー１５２１−１５２５によりサービス制御システム４０１へ報告される。例えば、この「ゲームファインダー」アプリケーションを実行するａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ゲームを見ているとき（及びゲームを見終えたとき）ホスティングサービス制御システム４０１へメッセージを送信し、どれほど多くのゲームが見られているかの統計値を更新できるようにする。統計値のあるものは、この「ゲームファインダー」アプリケーションのようなユーザインターフェイスアプリケーションに利用される。
ユーザは、入力装置のアクチベーションボタンをクリックした場合に、フルスクリーンサイズへの生の状態を保ちながら黄色のボックス内のサムネールビデオをズームアップして見ることができる。この効果が図１７のプロセスに示されている。ビデオウインドウ１７００は、サイズが増大していることに注意されたい。この効果を具現化するために、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、選択されたゲームを実行しているａｐｐ／ｇａｍｅサーバー１５２１−１５２５から、そこにルーティングされたゲームのフルスクリーンサイズのビデオストリームのコピーを取ることを要求する（ユーザのディスプレイ装置４２２の解像度で）。ゲームを実行しているａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、共有ハードウェアコンプレッサ１５３０に、ゲームのサムネールサイズのコピーがもはや必要ない（別のａｐｐ／ｇａｍｅサーバー１５２１−１５２５がそのようなサムネールを要求しない限り）ことを通知し、次いで、ビデオのフルスクリーンサイズコピーを、ビデオをズームしているａｐｐ／ｇａｍｅサーバー１５２１−１５２５へ送信することを指令する。ゲームをプレイしているユーザは、ゲームをズームアップしているユーザと同じ解像度のディスプレイ装置４２２を有していても、いなくてもよい。更に、ゲームを見る他の者も、ゲームをズームアップしているユーザと同じ解像度のディスプレイ装置４２２を有していても、いなくてもよい（且つ異なるオーディオ再生手段、例えば、ステレオ又はサラウンドサウンドを有してもよい）。従って、共有ハードウェアコンプレッサ１５３０は、ビデオ／オーディオストリームを要求しているユーザの要件を満足する適当に圧縮されたビデオ／オーディオストリームが既に発生されたかどうか決定し、もしそれが存在する場合には、ビデオをズームしているａｐｐ／ｇａｍｅサーバー１５２１−１５２５へストリームのコピーをルーティングするようにアウトバウンドルーティング１５４０に通知し、又、もしそうでなければ、そのユーザに適したビデオの別のコピーを圧縮して、ビデオをズームしているａｐｐ／ｇａｍｅサーバー１５２１−１５２５及びインバウンドルーティング１５０２へストリームを返送するようにアウトバウンドルーティングに命令する。選択されたビデオのフルスクリーンバージョンを現在受信しているこのサーバーは、それを解凍し、フルサイズまで徐々にスケールアップする。
図１８は、ゲームがフルスクリーンへ完全にズームアップされた後にスクリーンがどのように見えるか示しており、ゲームは、矢印１８００で指された映像により示すように、ユーザのディスプレイ装置４２２の全解像度で示されている。ゲームファインダーアプリケーションを実行しているａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、もはや必要でないサムネールを発生した他のａｐｐ／ｇａｍｅサーバー１５２１−１５２５へメッセージを送信すると共に、他のゲームがもはや見られていないホスティングサービス制御サーバー４０１へメッセージを送信する。この点において、発生される表示は、スクリーンの頂部にあって、情報及びメニュー制御をユーザに与えるオーバーレイ１８０１である。このゲームが進行するにつれて、観衆は、２５０３人の視聴者まで増加したことに注意されたい。このように大勢の視聴者では、同じ又はほぼ同じ解像度をもつディスプレイ装置４２２に大勢の視聴者が結び付けられる（各ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、適合性を調整するためにビデオをスケーリングする能力を有する）。
図示されたゲームは、マルチプレーヤゲームであるから、ユーザは、ある点でゲームに加わることを決定できる。ホスティングサービス２１０は、種々の理由で、ユーザがゲームに加わるのを許しても許さなくてもよい。例えば、ユーザは、ゲームをプレイするために支払しなければならず、又、プレイしないことを選んでもよく、ユーザは、その特定のゲームに加わるに充分なランキングを有していないことがあり（例えば、他のプレーヤとの競争に耐えない）、或いはユーザのインターネット接続は、ユーザがプレイするのに充分な短い待ち時間を有していないことがある（例えば、ゲームを見るための待ち時間制約がなく、従って、遠くで（実際上、別の大陸で）プレイされるゲームを、待ち時間の問題なしに見ることはできるが、プレイするゲームについては、待ち時間は、（ａ）ゲームを楽しむために、及び（ｂ）短い待ち時間接続を有する他のプレーヤと平等の立場であるために、ユーザにとって充分短いものでなければならない）。ユーザがプレイを許された場合には、ユーザに対して「ゲームファインダー」ユーザインターフェイスを与えたａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ホスティングサービス制御サーバー４０１が、特定のゲームをプレイするために適当に構成されたａｐｐ／ｇａｍｅサーバー１５２１−１５２５を始動して（即ち、探索し始動して）、ＲＡＩＤアレイ１５１１−１５１２からゲームをロードし、次いで、ホスティングサービス制御サーバー４０１が、ゲームを現在ホストしているａｐｐ／ｇａｍｅゲームサーバーへユーザから制御信号を転送するようにインバウンドルーティング１５０２に命令すると共に、「ゲームファインダー」アプリケーションをホストしたａｐｐ／ｇａｍｅサーバーからのビデオ／オーディオを圧縮することから、ゲームを現在ホストしているａｐｐ／ｇａｍｅサーバーからのビデオ／オーディオを圧縮することへスイッチするように共有ハードウェアコンプレッサ１５３０に命令することを要求する。「ゲームファインダー」ａｐｐ／ｇａｍｅサービス、及びゲームをホストしている新たなａｐｐ／ｇａｍｅサーバーの垂直同期は、同期されず、その結果、２つの同期間におそらく時間差が生じる。共有ビデオ圧縮ハードウェア１５３０は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５がビデオフレームを完成したときにビデオの圧縮を開始するので、新たなサーバーからの第１のフレームは、古いサーバーのフルフレーム時間より早期に完成され、これは、その手前の圧縮されたフレームがその送信を完了する前である（例えば、図９ｂの送信時間９９２を考えると、非圧縮フレーム３ ９６３がフレーム時間の半分早期に完成された場合に、送信時間９９２に影響を及ぼす）。このような状況では、共有ビデオ圧縮ハードウェア１５３０は、新たなサーバーからの第１のフレームを無視し（例えば、フレーム４ ９６４が無視される(９７４)のと同様に）、クライアント４１５は、古いサーバーからの最後のフレームを特別のフレーム時間中保持し、そして共有ビデオ圧縮ハードウェア１５３０は、ゲームをホストする新たなａｐｐ／ｇａｍｅサーバーからの次のフレーム時間ビデオの圧縮を開始する。視覚上、あるａｐｐ／ｇａｍｅサーバーから他のａｐｐ／ｇａｍｅサーバーへの移行は、シームレスである。ホスティングサービス制御サーバー４０１は、次いで、「ゲームファインダー」をホストしていたａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５に、それが再び必要になるまでアイドル状態にスイッチするように通知する。
次いで、ユーザは、ゲームをプレイすることができる。そして、何が優れているかと言えば、ゲームは、知覚上即座にプレイされ（ギガビット／秒の速度でＲＡＩＤアレイ１５１１−１５１２からａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５にロードされるので）、そしてゲームは、理想的なドライバ、レジストリ構成（Ｗｉｎｄｏｗｓの場合）をもち、且つゲームのオペレーションと競合し得るサーバーで実行される他のアプリケーションをもたずに、ゲームに対して厳密に構成されたオペレーティングシステムと一緒にゲームに厳密に適したサーバーにロードされる。
又、ユーザがゲームを通して進行するにつれて、ゲームの各セグメントが、ＲＡＩＤアレイ１５１１−１５１２からギガビット／秒の速度でサーバーへロードされ（即ち、１ギガバイトの負荷が８秒で）、そしてＲＡＩＤアレイ１５１１−１５１２の膨大な記憶容量のために（これは多数のユーザ間の共有リソースであるから、非常に大きく、又、コスト効率がよい）、幾何学的な設定又は他のゲームセグメント設定を予め計算して、ＲＡＩＤアレイ１５１１−１５１２に記憶し、そして非常に迅速にロードすることができる。更に、各ａｐｐ／ｇａｍｅサーバー１５２１−１５２５のハードウェア構成及び計算能力が既知であるから、ピクセル及び頂点シェーダーを予め計算することができる。
従って、ゲームは、ほぼ瞬間的に始動し、理想的な環境で実行され、そしてその後のセグメントがほぼ瞬間的にロードされる。
しかし、これらの効果を越えて、ユーザは、ゲームをプレイする他人を見ることができ（上述した「ゲームファインダー」及び他の手段を経て）、そしてゲームに関心があるかどうか判断し、もしそうであれば、他人を見ることから秘訣を学習することができる。そして、ユーザは、大きなダウンロード及び／又はインストールを待機する必要なく、ゲームを瞬時にデモすることができ、又、ユーザは、おそらく、僅かな費用の試行ベースで、又は長期間ベースで、ゲームを瞬時にプレイすることができる。そして、ユーザは、ゲームを、ウインドウズＰＣ、マッキントッシュ、家のＴＶ受像機で、又、旅行中も、移動電話で、充分短い待ち時間のワイヤレス接続によりプレイすることができる。又、これは、全て、ゲームのコピーを物理的に所持せずに行うことができる。
上述したように、ユーザは、自分のゲームプレイを他人に見られることを許さないか、自分のゲームを遅延の後に見られるのを許すか、自分のゲームを選択されたユーザにより見られるのを許すか、又は自分のゲームを全てのユーザにより見られるのを許すかを判断することができる。それにも関わらず、ビデオ／オーディオは、一実施形態では、１５分間、遅延バッファ１５１５に記憶され、そしてユーザは、デジタルビデオレコーダ（ＤＶＲ）でＴＶを見ていたときに行うことができたのと同様に、自分の以前のゲームプレイを「巻き戻して」見ることができ、又、休止し、スローで再生し、早送りし、等々を行うことができる。この例では、ユーザは、ゲームをプレイするが、ユーザがアプリケーションを使用する場合には、同じ“ＤＶＲ”能力を利用することができる。これは、以前の行動を再検討すること及び以下に述べる他のアプリケーションでも有用である。更に、カメラの視野を変更できる、等のように、ゲーム状態情報の利用に基づいて巻き戻することができるようにゲームが設計されている場合は、この“３Ｄ ＤＶＲ”能力もサポートされるが、それをサポートするようにゲームを設計することが要求される。遅延バッファ１５１５を使用する“ＤＶＲ”能力は、もちろん、ゲーム又はアプリケーションが使用されたときに発生するビデオに限定して、ゲーム又はアプリケーションと共に機能するが、３Ｄ ＤＶＲ能力をもつゲームの場合には、ユーザは、以前にプレイしたセグメントの３Ｄにおける「フライスルー(fly through)」を制御することができ、そしてそれにより得られるビデオを遅延バッファ１５１５で記録させ、ゲームセグメントのゲーム状態を記録させることができる。従って、特定の「フライスルー」が、圧縮されたビデオとして記録されるが、ゲーム状態も記録されるので、後日、ゲームの同じセグメントについて異なるフライスルーが考えられることになる。
以下に述べるように、ホスティングサービス２１０におけるユーザは、各々、彼等に関する情報及び他のデータを掲示することのできる「ユーザページ」を有する。ユーザが掲示することのできるものの中には、彼等がセーブしたゲームプレイからのビデオセグメントがある。例えば、ユーザがゲームにおいて特に困難な挑戦を克服した場合には、ユーザは、ゲームにおいて偉大な成果をなし得た点の直前まで「巻き戻し」、次いで、他のユーザが見るために、ある時間巾（例えば、３０秒）のビデオセグメントをユーザの「ユーザページ」にセーブするようにホスティングサービス２１０に命令することができる。これを達成するには、ユーザが、遅延バッファ１５１５に記憶されたビデオをＲＡＩＤアレイ１５１１−１５１２へ再生してユーザの「ユーザページ」においてそのビデオセグメントをインデックスするように使用するという、単なるａｐｐ／ｇａｍｅサーバー１５２１−１５２５の問題である。
ゲームが、上述した３Ｄ ＤＶＲの能力を有する場合には、３Ｄ ＤＶＲに要求されるゲーム状態情報もユーザによって記録して、ユーザの「ユーザページ」に利用することができる。
能動的なプレーヤに加えて「観客」（即ち３Ｄの世界を進んで、アクションに関与せずにそれを観察できるユーザ）をもつようにゲームが設計されている場合には、「ゲームファインダー」アプリケーションは、ユーザが観客及びプレーヤとしてゲームに加わることができるようにする。具現化の視点から、ユーザが能動的なプレーヤではなく観客である場合も、ホスティングシステム２１０に対して差はない。ゲームは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５にロードされ、そしてユーザは、ゲームを制御する（例えば、世界を見るバーチャルカメラを制御する）。唯一の相違は、ユーザのゲーム経験である。
複数ユーザの協力
ホスティングサービス２１０の別の特徴は、複数のユーザが、大きく異なる視聴装置を使用していても、生のビデオを見ながら協力する能力である。これは、ゲームをプレイするとき及びアプリケーションを使用するときの両方に有用である。
多くのＰＣ及び移動電話は、ビデオカメラを装備しており、且つ特に、映像が小さいときには、リアルタイム映像圧縮を行う能力を有している。又、テレビに取り付けることのできる小型カメラも入手でき、リアルタイム圧縮を、ソフトウェアで具現化するか、又はビデオを圧縮するための多数のハードウェア圧縮装置の１つを使用して具現化するのは、困難なことではない。又、多数のＰＣ及び全ての移動電話は、マイクロホンを有し、又、マイクロホンと共にヘッドセットが利用できる。
このようなカメラ及び／又はマイクロホンは、ローカルのビデオ／オーディオ圧縮能力（特に、ここに述べる短待ち時間のビデオ圧縮技術を使用する）と合成されると、ユーザが、ユーザの家屋２１１からのビデオ及び／又はオーディオを入力装置の制御データと共にホスティングサービス２１０へ送信できるようにする。このような技術が使用されるときには、図１９に示す能力を達成でき、即ちユーザは、自分のビデオ及びオーディオ１９００を別のユーザのゲーム又はアプリケーション内のスクリーンに出現させることができる。この例は、カーレースにおいてチームメートが協力するマルチプレーヤゲームである。ユーザのビデオ／オーディオは、チームメートだけにより選択的に見る／聞くことができる。そして、実質上、待ち時間がないので、上述した技術を使用すると、プレーヤは、気付くほどの遅延を伴うことなく、互いにリアルタイムで話したり動いたりすることができる。
このビデオ／オーディオの一体化は、ユーザのカメラ／マイクロホンからの圧縮されたビデオ及び／又はオーディオをインバウンドインターネットトラフィック１５０１として到着させることにより達成される。次いで、インバウンドルーティング１５０２が、ビデオ及び／又はオーディオを、それを見る／聞くことが許されたａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へルーティングする。次いで、ビデオ及び／又はオーディオを使用することを選択する各ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５のユーザは、それを解凍し、そして１９００で示されたように、必要に応じて、ゲーム又はアプリケーション内に現れるように一体化する。
図１９の例は、このような協力がゲームにおいてどのように利用されるか示しているが、このような協力は、アプリケーションにとって非常にパワフルなツールである。ニューヨーク市ではニューヨークに本拠地を置く不動産開発業者のためにシカゴの建築家により大きなビルが設計されているが、その判断には、旅行中でマイアミの空港にたまたまいる金融投資家が含まれ、そして投資家と不動産開発業者の両方を満足させるために、周囲のビルにどのように調和させるかに関してそのビルの幾つかの設計要素について判断をする必要がある状況を考える。建設会社は、シカゴにおいてカメラがＰＣに取り付けられた高解像度モニタを有し、不動産開発業者は、ニューヨークにおいてカメラ付きのラップトップを有し、そして投資家は、マイアミにおいてカメラ付きの移動電話を有している。建設会社は、ホスティングサービス２１０を使用して、非常に現実的な３Ｄレンダリングを行うことのできるパワフルな建設設計アプリケーションをホストすることができ、ニューヨーク市内のビルの大きなデータベース及び設計中のビルのデータベースを使用することができる。建設設計アプリケーションは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５の１つで実行され、又は多大な計算パワーを要求する場合には、その幾つかにおいて実行される。異なる位置にいる３人のユーザの各々は、ホスティングサービス２１０に接続され、そしてその各々は、建設設計アプリケーションのビデオ出力の同時ビューを有するが、これは、各ユーザが有する所与の装置及びネットワーク接続特性に対して共有ハードウェア圧縮１５３０により適当なサイズにされる（例えば、建設会社は、２０Ｍｂｐｓの商業的インターネット接続を通して２５６０ｘ１４４０の６０ｆｐｓディスプレイを見ることができ、ニューヨークの不動産開発業者は、自分のラップトップの６ＭｂｐｓのＤＳＬ接続を経て１２８０ｘ７２０の６０ｆｐｓ映像を見ることができ、そして投資家は、自分の移動電話の２５０Ｋｂｐｓのセルラーデータ接続を経て３２０ｘ１８０の６０ｆｐｓ映像を見ることができる。各当事者は、他の当事者の音声を聞き（会議コールは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５において広く利用できる多数の会議コールソフトウェアパッケージのいずれかにより取り扱われ）、そしてユーザ入力装置上のボタンの操作を通して、ユーザは、ローカルカメラを使用してそれら自身のビデオ出演をすることができる。ミーティングが進むにつれて、建築家は、そのビルを回転し且つそのエリアの他のビルの近くを飛行したときにそのビルがどのように見えるか、非常にホトリアルな３Ｄレンダリングで示すことができ、そして同じビデオを、各当事者のディスプレイ装置の解像度で全ての当事者が見ることができる。当事者により使用されるローカル装置が、どれも、このようなリアリズムで３Ｄアニメーションを取り扱いできないことは問題ではないが、ニューヨーク市の周囲のビルをレンダリングするために要求される膨大なデータベースをダウンロードするか又は記憶することは言うまでもない。各ユーザの視点から、距離が離れているにも関わらず、又、異なるローカル装置であるにも関わらず、ユーザは、単純に、信じられないほどのリアリズムで繋ぎ目のない経験をする。そして、１人の当事者が顔を見えるようにして感情を良く伝えたいときには、そのようにすることができる。更に、不動産開発業者又は投資家のいずれかが建設プログラムの制御を手に入れてそれら自身の入力装置（キーボード、マウス、キーパッド又はタッチスクリーン）を使用したい場合には、知覚上待ち時間なしに応答でき、又、応答することになる（それらのネットワーク接続が不合理な待ち時間をもたないと仮定して）。例えば、移動電話の場合には、その移動電話が空港のＷｉＦｉネットワークに接続された場合には、待ち時間が非常に短くなる。しかし、米国で今日利用できるセルラーデータネットワークを使用する場合には、おそらく、顕著な遅れで悩まされることになる。更に、投資家が見ているミーティングのほとんどの目的では、建築家がビルの接近飛行を制御し、又はビデオ遠隔会議で話をするためには、セルラー待ち時間でも許容できねばならない。
最終的に、協力会議コールの終わりに、不動産開発業者及び投資家は、ホスティングサービスから彼等のコメントを発し且つ署名し、建設会社は、遅延バッファ１５１５に記録された会議のビデオを「巻き戻し」、そしてコメント、顔の表情、及び／又はミーティング中に作られたビルの３Ｄモデルに加えられたアクションを再検討することができる。セーブしたい特定のセグメントがある場合は、ビデオ／オーディオのそれらセグメントを、記録保管及び後で再生するために遅延バッファ１５１５からＲＡＩＤアレイ１５１１−１５１２へ移動することができる。
又、コストの観点から、建築家が計算パワー及びニューヨーク市の大きなデータベースを１５分の会議コールにしか使用する必要がない場合には、ハイパワーのワークステーションを所有し且つ大きなデータベースの高価なコピーを購入するのではなく、リソースを使用した時間について支払するだけでよい。
ビデオリッチなコミュニティサービス
ホスティングサービス２１０は、インターネットにビデオリッチなコミュニティサービスを確立するための空前の機会を可能にする。図２０は、ホスティングサービス２１０におけるゲームプレーヤのための規範的「ユーザページ」を示す。「ゲームファインダー」アプリケーションと同様に、「ユーザページ」は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５の１つにおいて実行されるアプリケーションである。このページにおけるサムネール及びビデオウインドウは、全て、絶えず動くビデオ（セグメントが短い場合は、ループになる）を示す。
ビデオカメラを使用するか、又はビデオをアップロードすることにより、ユーザ（ユーザ名は“ＫＩＬＬＨＡＺＡＲＤ”である）は、自分自身のビデオ２０００を掲示することができ、他のユーザがこれを見ることができる。このビデオは、ＲＡＩＤアレイ１５１１−１５１２に記憶される。又、他のユーザがＫＩＬＬＨＡＺＡＲＤの「ユーザページ」に到来するときに、ＫＩＬＬＨＡＺＡＲＤがそのときホスティングサービス２１０を使用していれば、（ユーザが彼を見るために彼の「ユーザページ」を見ることを許すと仮定すれば）彼が何を行おうとその生のビデオ２００１が示される。これは、サーバー制御システム４０１から要求される「ユーザページ」アプリケーションをホストするａｐｐ／ｇａｍｅサーバー１５２１−１５２５により達成され、ＫＩＬＬＨＡＺＡＲＤがアクティブであるかどうか、そしてもしそうであれば、彼が使用するａｐｐ／ｇａｍｅサーバー１５２１−１５２５により達成される。次いで、「ゲームファインダー」アプリケーションにより使用される同じ方法を使用して、適当な解像度及びフォーマットの圧縮されたビデオストリームが、「ユーザページ」アプリケーションを実行するａｐｐ／ｇａｍｅサーバー１５２１−１５２５へ送信され、そして表示される。ユーザがＫＩＬＬＨＡＺＡＲＤの生のゲームプレイでウインドウを選択し、次いで、その入力装置を適当にクリックする場合は、ウインドウがズームアップされ（この場合も「ゲームファインダー」アプリケーションと同じ方法を使用して）、そして生のビデオが、見ているユーザのインターネット接続の特性に適した、見ているユーザのディスプレイ装置４２２の解像度でスクリーンを埋める。
従来に勝るこの解決策の重要な効果は、「ユーザページ」を見ているユーザが、自分が所有していないゲームの生のプレイを見ることができ、且つ非常に良いことに、ゲームをプレイできるローカルコンピュータ又はゲームコンソールをもたなくてよいことである。これは、ゲームをプレイする「アクション中」である「ユーザページ」に示されたユーザをユーザが見る良い機会を与えると共に、見ているユーザが試してみたい又は上手くなりたいゲームに関して学習する機会でもある。
ＫＩＬＬＨＡＺＡＲＤの相棒２００２からのカメラ記録又はアップロードされたビデオクリップも「ユーザページ」に示され、そして各ビデオクリップの下には、相棒がオンラインでゲームをプレイしているかどうか示すテキストがある（例えば、ｓｉｘ＿ｓｈｏｔは、ゲーム“Ｅｒａｇｏｎ”をプレイしており、ＭｒＳｎｕｇｇｌｅｓ９９は、オフラインであり、等）。メニューアイテム（図示せず）をクリップすることにより、相棒のビデオクリップは、記録又はアップロードされたビデオを示すものから、ホスティングサービス２１０上で現在ゲームをプレイしている相棒がそのときゲームにおいて何をしているかの生のビデオへとスイッチする。従って、これは、相棒のためのゲームファインダーグループとなる。相棒のゲームが選択されそしてユーザがそれをクリックする場合には、全スクリーンをズームアップし、そしてユーザは、全スクリーンでプレイされるゲームを生で見ることができる。
この場合も、相棒のゲームを見ているユーザは、ゲームのコピーも、ゲームをプレイするためのローカルコンピューティング／ゲームコンソールリソースも、所有していない。ゲームを見るのは、実際上、瞬間的である。
上述したように、ユーザがホスティングサービス２１０においてゲームをプレイするときには、ユーザは、ゲームを「巻き戻し」、セーブしたいビデオセグメントを見出し、次いで、ビデオセグメントを自分の「ユーザページ」へセーブする。これらは、「自慢のクリップ(Brag Clips)」と称される。ビデオセグメント２００３は、全て、プレイした以前のゲームからＫＩＬＬＨＡＺＡＲＤによりセーブされた「自慢のクリップ」２００３である。番号２００４は、「自慢のクリップ」が何回見られたかを示し、そして「自慢のクリップ」が見られるときに、ユーザは、それを格付けする機会を得、オレンジのキー穴形状のアイコン２００５の数は、どれほど高い格付けであるかを示す。「自慢のクリップ」２００３は、ユーザが「ユーザページ」を見るとき、そのページにおけるビデオの残りと共に絶えずループする。ユーザが「自慢のクリップ」２００３の１つを選択してクリックする場合には、それがズームアップし、「自慢のクリップ」２００３を、クリップの再生、休止、巻き戻し、早送り、ステップスルー、等を行えるようにするＤＶＲコントロールと共に提示する。
「自慢のクリップ」２００３の再生は、ユーザが「自慢のクリップ」を記録し、それを解凍して再生するときに、ＲＡＩＤアレイ１５１１−１５１２に記憶された圧縮ビデオセグメントをａｐｐ／ｇａｍｅサーバー１５２１−１５２５がロードすることにより具現化される。
又、「自慢のクリップ」２００３は、“３Ｄ ＤＶＲ”ビデオセグメント（即ち、再生でき且つユーザがカメラの視点を変更するのを許すゲームからのゲーム状態シーケンス）でもあり、これは、そのような能力をサポートするゲームからのものである。この場合、ゲームセグメントが記録されたときにユーザが作った特定の「フライスルー」の圧縮ビデオ記録に加えて、ゲーム状態情報が記憶される。「ユーザページ」が見られ、そして全てのサムネール及びビデオウインドウが絶えずループ化するときには、３Ｄ ＤＶＲ「自慢のクリップ」２００３は、ユーザがゲームセグメントの「フライスルー」を記録したときに圧縮ビデオとして記録された「自慢のクリップ」２００３を絶えずループ化する。しかし、ユーザが３Ｄ ＤＶＲ「自慢のクリップ」２００３を選択してそれをクリップするときには、圧縮ビデオの「自慢のクリップ」を再生できるようにするＤＶＲコントロールに加えて、ユーザは、ゲームセグメントに対する３Ｄ ＤＶＲ能力を与えるボタンをクリックすることができる。それらは、彼等自身でゲームセグメント中にカメラの「フライスルー」を制御することができ、そしてそれらが望む（及びユーザページを所有するユーザがそれを許す）場合に、別の「自慢のクリップ」の「フライスルー」を圧縮ビデオ形態で記録することができ、これは、次いで、ユーザページの他の視聴者に利用可能となる（直ちに、又はユーザページの所有者が「自慢のクリップ」を再検討する機会をもった後に）。
この３Ｄ ＤＶＲ「自慢のクリップ」２００３の能力は、記録されたゲーム状態情報を別のａｐｐ／ｇａｍｅサーバー１５２１−１５２５において再生しようとしているゲームを作動することによりイネーブルされる。ゲームは、ほぼ瞬間的に作動できるので（上述したように）、「自慢のクリップ」により記録されたゲーム状態にプレイを限定してゲームを作動し、次いで、ユーザが、圧縮ビデオを遅延バッファ１５１５に記録しながらカメラで「フライスルー」を実行できるようにするのは、困難ではない。ユーザが「フライスルー」の実行を完了すると、ゲームが不作動にされる。
ユーザの視点から、３Ｄ ＤＶＲの「自慢のクリップ」２００３で「フライスルー」を作動することは、リニアな「自慢のクリップ」２００３のＤＶＲコントロールを制御することより努力が要らない。それらは、ゲームについて又はゲームをどのようにプレイするかについて何も知らなくてよい。それらは、別の者により記録されるゲームセグメント中に３Ｄ世界を凝視するバーチャルカメラオペレータに過ぎない。
又、ユーザは、それら自身のオーディオを、マイクロホンから記録されるか又はアップロードされる「自慢のクリップ」にオーバーダビングすることもできる。このようにして、「自慢のクリップ」は、ゲームからのキャラクタ及びアクションを使用して、カスタムアニメーションを生成するのに使用できる。このアニメーション技術は、「マシニマ(machinima)」として一般に知られている。
ユーザがゲームを進めるにつれて、異なるスキルレベルを達成する。プレイしたゲームは、達成度をサービスコントロールシステム４０１へ報告し、それらのスキルレベルが「ユーザページ」に示される。
双方向アニメ化広告
オンライン広告は、テキストから、静止映像へ、ビデオへ、そして今や、Ａｄｏｂｅ Ｆｌａｓｈのようなアニメーションシンクライアントを使用して典型的に具現化される双方向セグメントへと推移してきた。アニメーションシンクライアントを使用する理由は、ユーザが、典型的に、製品やサービスが彼等に推薦される特典に対する遅れが耐え難いからである。又、シンクライアントは、非常に低性能のＰＣで実行され、従って、広告主は、双方向アドが適切に機能するという高い信頼度をもつことができる。不都合なことに、Ａｄｏｂｅ Ｆｌａｓｈのようなアニメーションシンクライアントは、双方向性の度合い及び経験の巾が制限される（ダウンロード時間を軽減するために）。
図２１は、ショールーム内で車を回転させ、車がどのように見えるかリアルタイムレイトレーシングで示しながら、ユーザが車の外部及び内部の色を選択する双方向広告を示している。ユーザは、車を運転するアバターを選択し、次いで、ユーザは、レーストラック上、又はモナコのようなエキゾチックな場所でドライブするように車を取り出すことができる。ユーザは、より大きなエンジン又はより優れたタイヤを選択することができ、次いで、その変更した構成が車の加速性能又は路面の食い付きにどのように影響するか見ることができる。
もちろん、広告は、実際上、精巧な３Ｄビデオゲームである。しかし、ＰＣ又はビデオゲームコンソール上に再生できる広告については、おそらく、１００ＭＢダウンロードを要求し、そしてＰＣの場合には、特殊なドライバのインストールを要求すると共に、ＰＣが充分なＣＰＵ又はＧＰＵ計算能力に欠ける場合には全く実行されないことがある。従って、このような広告は、従来の構成では不可能である。
ホスティングサービス２１０では、このような広告は、ほぼ瞬時に起動し、そしてユーザのクライアント４１５の能力がどんなものであっても、完全に実行される。従って、それらは、シンクライアント双方向アドより素早く起動し、著しく経験に富み、且つ非常に信頼性が高い。
リアルタイムアニメーション中のストリーミング幾何学形状
ＲＡＩＤアレイ１５１１−１５１２及びインバウンドルーティング１５０２は、リアルタイムアニメーション（例えば、複雑なデータベースを伴うフライスルー）中にゲームプレイ又はアプリケーションの中間において幾何学形状をオンザフライで確実に配信するためにＲＡＩＤアレイ１５１１−１５１２及びインバウンドルーティング１５０２に依存するビデオゲーム及びアプリケーションを設計できるように高速で且つ短待ち時間のデータレートを与えることができる。
図１に示すビデオゲームシステムのような従来のシステムでは、特に実際の家庭用装置に使用できる大量記憶装置は、要求される幾何学形状をある程度予想できる状況を除き、ゲームプレイ中に幾何学形状をストリームするには遥かに低速である。例えば、特定の道路が存在するドライブゲームにおいて、視野に入って来るビルの幾何学形状は、合理的に充分なほど予想でき、そして大量記憶装置は、近づきつつある幾何学形状が位置している場所を前もって探すことができる。
しかし、予想できない変化を伴う複雑なシーンにおいて（例えば、あたり一面に複雑なキャラクタが存在する戦闘のシーンにおいて）、ＰＣ又はビデオゲームシステムのＲＡＭが、現在視野にある物体に対する幾何学形状で完全に埋められており、次いで、ユーザが突然それらのキャラクタを、それらキャラクタの背後の視野へ方向転換する場合に、幾何学形状がＲＡＭに予めロードされていなければ、それを表示できるまでに遅延が生じることになる。
ホスティングサービス２１０において、ＲＡＩＤアレイ１５１１−１５１２は、ギガビットイーサネット速度以上でデータをストリームすることができ、そしてＳＡＮネットワークでは、１０ギガビットのイーサネット又は他のネットワークに勝る１０ギガビット／秒の速度を達成することができる。１０ギガビット／秒は、ギガバイトのデータを１秒未満でロードする。６０ｆｐｓのフレーム時間（１６．６７ｍｓ）では、ほぼ１７０メガビット（２１ＭＢ）のデータをロードすることができる。当然、ＲＡＩＤ構成にある回転するメディアは、１フレーム時間より大きな待ち時間を依然被るが、フラッシュベースのＲＡＩＤ記憶装置は、結局、回転するメディアＲＡＩＤアレイと同程度の大きさであり、そのような長い待ち時間は被らない。一実施形態では、大量ＲＡＭライトスルーキャッシングを使用して、非常に短い待ち時間のアクセスを与える。
従って、充分に高いネットワーク速度及び充分に短い待ち時間の大量記憶では、ＣＰＵ及び／又はＧＰＵが３Ｄデータを処理できるのと同程度の速さでａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へ幾何学形状をストリームすることができる。従って、ユーザがそのキャラクタを突然方向転換しそして後を見る上述した例では、後方の全てのキャラクタに対する幾何学形状を、キャラクタが回転を完了する前にロードすることができ、従って、ユーザにとって、生のアクションと同程度にリアルなホトリアルな世界にいるかのように思える。
上述したように、ホトリアルなコンピュータアニメーションにおける最後の未開拓の１つは、人間の顔であり、不完全さに対して人間の目が敏感であるために、ホトリアルな顔からの若干のエラーが視聴者から否定的なリアクションを招くことがある。図２２は、ＣｏｎｔｏｕｒTM「リアリティキャプチャーテクノロジー」（本ＣＩＰ出願の譲受人に各々譲渡された同時係争中の特許出願、即ち２００４年９月１５日に出願された第１０／９４２，６０９号“Apparatus and method for capturing the motion of a performer”、２００４年９月１５日に出願された第１０／９４２，４１３号“Apparatus and method for capturing the expression of a performer”、２００５年２月２５日に出願された第１１／０６６，９５４号“Apparatus and method for improving marker identification within a motion capture system”、２００５年３月１０日に出願された第１１／０７７，６２８号“Apparatus and method for performing motion capture using shutter synchronization”、２００５年１０月２０日に出願された第１１／２５５，８５４号“Apparatus and method for performing motion capture using a random pattern on capture surfaces”、２００６年６月７日に出願された第１１／４４９，１３１号“System and method for performing motion capture using phosphor application techniques”、２００６年６月７日に出願された第１１／４４９，０４３号“System and method for performing motion capture by strobing a fluorescent lamp”、２００６年６月７日に出願された第１１／４４９，１２７号“System and method for three dimensional capture of stop-motion animated characters”の要旨）を使用して捕獲される生の演技が、非常に滑らかな捕獲表面を、次いで、高多角形数追跡表面（即ち、多角形の動きが顔の動きに正確に追従する）をどのように生じるか示している。最終的に、生の演技のビデオが追跡表面にマップされて、テクスチャ処理表面を形成するときに、ホトリアルな結果が得られる。
現在のＧＰＵ技術は、追跡表面における多角形の数及びテクスチャをレンダリングしそして表面をリアルタイムで照明することができるが、多角形及びテクスチャがフレーム時間ごとに変化する（これは、最もホトリアルな結果を生じる）場合には、近代的ＰＣ又はビデオゲームコンソールの利用可能な全てのＲＡＭを急速に消費してしまう。
上述したストリーミング幾何学形状技術を使用すると、ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へ幾何学形状を連続的に供給して、ホトリアルな顔を連続的にアニメ化し、生の動きの顔とほとんど見分けがつかない顔をもつビデオゲームを作成できるようにするが実際的である。
リニアなコンテンツと双方向特徴との一体化
動画、テレビ番組及びオーディオ資料（集合的に「リニアコンテンツ」）は、家庭及びオフィスのユーザに多数の形態で広く利用することができる。リニアコンテンツは、ＣＤ、ＤＶＤ、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙメディアのような物理的なメディアにおいて取得することができる。又、これは、衛星及びケーブルＴＶ放送からＤＶＲにより記録することもできる。そして、衛星及びケーブルＴＶを通してペイパービュー（ＰＰＶ）コンテンツとして、及びケーブルＴＶのビデオオンデマンド（ＶＯＤ）として利用することもできる。
益々多くのリニアコンテンツが、インターネットを通して、ダウンロードされたコンテンツとして及びストリーミングコンテンツとして利用できるようになった。今日、リニアメディアに関連した全ての特徴を経験するための場所は、実際に１つではない。例えば、ＤＶＤ及び他のビデオ光学メディアは、典型的に、演出家の解説、「メーキングオブ(making of)」特徴、等のように、他の場所では利用できない双方向特徴を有する。オンライン音楽サイトは、一般的にＣＤでは入手できないカバー技術及び歌情報を有するが、全てのＣＤをオンラインで入手できるのではない。又、テレビ番組に関連したウェブサイトは、しばしば、特別な特徴、ブログ、及びときには、俳優又は創作スタッフからのコメントを有する。
更に、多くの動画又はスポーツの出来事では、（動画の場合）しばしばリニアメディアと一緒に発売されるか、或いは（スポーツの場合）実世界の出来事（例えば、プレーヤのトレード）に密接に結びついたビデオゲームがしばしばある。
ホスティングサービス２１０は、異なる形態の関連コンテンツと一緒にリンクしてリニアコンテンツを配布するのに良く適している。確かに、動画の配信は、もはや、高度な双方向性のビデオゲームを配信する挑戦ではなく、ホスティングサービス２１０は、リニアコンテンツを家庭又はオフィスの広範な装置或いは移動装置へ配信することができる。図２３は、リニアコンテンツの選択を示すホスティングサービス２１０の規範的なユーザインターフェイスページを示している。
しかし、ほとんどのリニアコンテンツ配信システムとは異なり、ホスティングサービス２１０は、関連する双方向コンポーネント（例えば、ＤＶＤにおけるメニュー及び特徴、ＨＤ−ＤＶＤにおける双方向オーバーレイ、及びウェブサイトにおけるＡｄｏｂｅ Ｆｌａｓｈアニメーション（以下に述べる））を配信することもできる。従って、クライアント装置４１５の制限は、どの特徴が利用できるかについて、もはや制限を導入しない。
更に、ホスティングサービス２１０は、リニアコンテンツをビデオゲームコンテンツと動的に且つリアルタイムでリンクすることができる。例えば、ユーザがハリーポッターの映画においてクィディッチの試合を見て、クィディッチのプレイにトライしたい場合に、ボタンをクリックするだけで、映画を休止し、直ちに、ハリーポッタービデオゲームのクィディッチセグメントへ移ることができる。クィディッチの試合をプレイした後に、ボタンの別のクリックで、即座に映画が再開する。
写真的に捕獲されたビデオが生の動きのキャラクタと見分けがつかないようなホトリアルなグラフィック及び制作技術では、ユーザが、生の動きの映画におけるクィディッチゲームから、ここに述べるホスティングサービスにおけるビデオゲームのクィディッチゲームへ移行するときに、２つのシーンは、実質上、見分けがつかない。これは、２つの世界の間の線が見分けられないのでリニアコンテンツ及び双方向（例えば、ビデオゲーム）コンテンツの両方の演出家にとって全く新しい創作オプションを与える。
図１４に示すホスティングサービスアーキテクチャーを使用して、３Ｄ映画のバーチャルカメラの制御権を視聴者に与えることができる。例えば、列車の車両内で生じるシーンでは、視聴者がバーチャルカメラを制御して、ストーリーが進行する間に車両の周囲を見ることができる。これは、車両内の全ての３Ｄオブジェクト（アセット）が利用できると共に、シーンをリアルタイムでレンダリングできる充分なレベルの計算パワー、及びオリジナルの映画を仮定している。
そして、非コンピュータ発生娯楽であっても、非常にエキサイティングな双方向特徴を提供することができる。例えば、２００５動画“高慢と偏見(Pride and Prejudice)”は、華麗な古い英国風大邸宅における多くのシーンを有している。大邸宅の幾つかのシーンに対し、ユーザは、ビデオを休止し、次いで、カメラを制御して、大邸宅の塔、又はおそらく、周囲のエリアを撮影することができる。これを具現化するために、従来のアップル社のＱｕｉｃｋＴｉｍｅ ＶＲが具現化されたのと同様に、位置を見失わないように魚眼レンズをつけて大邸宅を通してカメラを搬送することができる。次いで、種々のフレームが変換され、従って、映像は歪むことなく、映画と共にＲＡＩＤアレイ１５１１−１５１２に記憶され、そしてユーザがバーチャルの塔に行くことを選択したときに再生することができる。
スポーツ行事では、バスケットボールゲームのような生のスポーツ行事を、ユーザが普通のＴＶで見るために、ホスティングサービス２１０を通してストリーミングすることができる。ユーザが特定のプレイを見た後に、ゲームのビデオゲーム（最終的には実際のプレーヤと同程度ホトリアルに見えるバスケットプレーヤを伴う）を、プレーヤが同じ位置でスタートして始めることができ、そしてユーザ（おそらく各々１人のプレーヤの制御権を得ている）がプレイをやり直して、プレーヤよりうまくいくかどうか確かめることができる。
ここに述べるホスティングサービス２１０は、この未来派的な世界をサポートするのに非常に良く適している。というのは、家庭又はほとんどのオフィス設定でインストールするのが不可能である計算パワー及び大量記憶リソースを保持することができ、又、家庭用設定では常に古い世代のＰＣ及びビデオゲームをもつものとなるが、その計算リソースは、入手可能な最新の計算ハードウェアで、常に、最新のものだからである。そして、ホスティングサービス２１０では、この計算の複雑さが全てユーザから隠され、従って、非常に精巧なシステムを使用しても、ユーザの観点から、テレビのチャンネルを切り換えるように簡単である。更に、ユーザは、全ての計算パワーにアクセスし、そして計算パワーがクライアント４１５から得られるところの経験にアクセスすることができる。
マルチプレーヤゲーム
ゲームがマルチプレーヤゲームであるという点で、インバウンドルーティング１５０２のネットワークを通してａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５と通信できると共に、インターネット（図示せず）へのネットワークブリッジで、ホスティングサービス２１０において実行されないサーバー又はゲームマシンと通信することができる。一般的なインターネットにおけるコンピュータでマルチプレーヤゲームをプレイするときには、ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５は、インターネットへのアクセスが非常に速い（ゲームが家庭のサーバーで実行された場合に比して）という利点を有するが、低速な接続でゲームをプレイする他のコンピュータの能力により制限を受けると共に、インターネット上のゲームサーバーが、比較的低速の消費者用インターネット接続上の家庭用コンピュータである最小公分母を受け容れるように設計されたことによっても潜在的に制限を受ける。
しかし、マルチプレーヤゲームが完全にホスティングサービス２１０のサーバーセンター内でプレイされるときには、差の世界を達成することができる。ユーザのためのゲームをホストする各ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５は、他のａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５と、非常に高速で非常に短待ち時間の接続及び膨大な非常に高速の記憶アレイをもつマルチプレーヤゲームのための集中制御をホストするサーバーとに相互接続される。例えば、インバウンドルーティング１５０２のネットワークにギガビットのイーサネットが使用される場合には、ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５は、ギガビット／秒の速度において潜在的に１ｍｓ以下の待ち時間で、互いに通信すると共に、マルチプレーヤゲームのための集中制御をホストするサーバーとも通信する。更に、ＲＡＩＤアレイ１５１１−１５１２は、非常に迅速に応答し、そしてギガビット／秒の速度でデータを転送することができる。例えば、家庭においてＰＣ又はゲームコンソールで実行されるゲームクライアントに制限された従来のシステムで、キャラクタが大量の幾何学形状及びそのキャラクタ独特の挙動を有するように、容貌及び服装に関してユーザがキャラクタをカスタマイズする場合に、そのキャラクタが別のユーザの視野に入ってきた場合には、ユーザは、長くて低速のダウンロードが完了して全ての幾何学形状及び挙動データがコンピュータにロードされるまで、待機しなければならなくなる。ホスティングサービス２１０内では、その同じダウンロードを、ＲＡＩＤアレイ１５１１−１５１２から対応されるギガビットのイーサネットを経てギガビット／秒の速度で行うことができる。家庭のユーザが８Ｍｂｐｓのインターネット接続（これは、今日の規格では非常に高速である）を有する場合でも、ギガビットイーサネットは、１００倍も高速である。従って、高速インターネット接続で１分かかるものが、ギガビットイーサネットでは１秒未満である。
トッププレーヤグループ及びトーナメント
ホスティングサービス２１０は、トーナメントに非常に良く適している。ローカルクライアントではゲームが実行されないので、ユーザがチートする機会がない。又、出力ルーティング１５４０がＵＤＰストリームをマルチキャストできるので、ホスティングサービス２１０は、メジャートーナメントを観衆の中の数千の人々に一度にブロードキャストすることができる。
実際に、数千のユーザが同じストリーム（例えば、メジャートーナメントのビューを示す）を受信するように普及した幾つかのビデオストリームがあるときは、多くのクライアント装置４１５へ大量配布するためにＡｋａｍａｉ又はＬｉｍｅｌｉｇｈｔのような「コンテンツデリバリーネットワーク」（ＣＤＮ）へビデオストリームを送信するのがより効率的である。
ＣＤＮを使用してトッププレーヤグループの「ゲームファインダー」ページを示すときには、同様の効率レベルを得ることができる。
メジャートーナメントの場合、生の有名アナウンサを使用して、ある試合中に実況放送することができる。メジャートーナメントを見ているのは大勢のユーザであるが、トーナメントでプレイするのは比較的少数である。有名アナウンサからの音声は、トーナメントでプレイしているユーザをホストすると共にトーナメントにおけるゲームの観客モードコピーをホストするａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へルーティングすることができ、そしてその音声は、ゲーム音声の上にオーバーダビングすることができる。有名アナウンサの映像も、ゲームにオーバーレイし、おそらくは、観客のビューにオーバーレイすることができる。
ウェブページロードの加速
ワールドワイドウェブ、その一次トランスポートプロトコルであるハイパーテキストトランスファープロトコル（ＨＴＴＰ）は、ビジネスだけが高速インターネット接続をもちそしてオンラインにいる消費者がダイヤルアップモデム又はＩＳＤＮを使用していた時代に考えられ定義されたものである。そのとき、高速接続用の「黄金律(gold standard)」は、１．５Ｍｂｐｓのデータレートを対称的に（即ち、両方向に等しいデータレートで）与えるＴ１ラインであった。
今日、状況は、完全に異なる。開発された世界の多くにおいてＤＳＬ又はケーブルモデム接続を通る平均的な家庭用接続の速度は、Ｔ１ラインより遥かに高いダウンストリームデータレートを有している。実際に、世界の幾つかの部分では、ファイバー・ツー・ザ・カーブ(fiber-to-the-curb)が、５０ないし１００Ｍｂｐｓ程度の高さのデータレートを家庭へ運ぶ。
不都合なことに、ＨＴＴＰは、これらの急激な速度改善の利点を効果的に取り入れるように構成されてこなかった（又、具現化もされなかった）。ウェブサイトは、リモートサーバーにおけるファイルの集合である。非常に簡単に言えば、ＨＴＴＰは、第１のファイルを要求し、そのファイルがダウンロードされるのを待機し、次いで、第２のファイルを要求し、そのファイルがダウンロードされるのを待機し、等々である。実際に、ＨＴＴＰは、２つ以上の「オープン接続」を許し、即ち一度に２つ以上のファイルを要求できるようにするが、合意された規格（及びウェブサーバーが過負荷にならないよう防止する要望）があるために、非常に僅かなオープン接続しか許されない。更に、ウェブページが構成される方法のために、ブラウザは、多くの場合、直ちにダウンロードに利用できる複数の同時のページに気付かない（即ち、ページをパーズした後にのみ、映像と同様に、新たなファイルをダウンロードする必要があることが明らかとなる）。従って、ウェブサイトのファイルは、本質的に１つ１つロードされる。そして、ＨＴＴＰによって使用される要求及び応答プロトコルのために、ロードされる各ファイルに関連して（米国で典型的なウェブサーバーにアクセスすると）おおよそ１００ｍｓの待ち時間がある。
比較的低速の接続では、これにより大きな問題が導入されることはない。というのは、ファイルそれ自体のダウンロード時間がウェブページの待ち時間を支配するからである。しかし、接続速度が上がるにつれて、特に、複雑なウェブページでは、問題が起き始める。
図２４に示す例では、典型的な商業的ウェブサイトが示されている（この特定のウェブサイトは、一流運動選手用の靴のブランドからのものである）。このウェブサイトには、５４のファイルがある。これらファイルは、ＨＴＭＬ、ＣＳＳ、ＪＰＥＧ、ＰＨＰ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、及びＦｌａｓｈファイルを含むと共に、ビデオコンテンツを含む。ページが生になる（即ち、ユーザがそれをクリックして、それを使用し始める）前に、合計１．５Ｍバイトをロードしなければならない。多数のファイルには、多くの理由がある。１つのこととして、複雑で且つ精巧なウェブページであり、そして別のこととして、ページにアクセスするユーザに関する情報（例えば、ユーザの母国、言語、以前に購入したかどうか、等）に動的に基づいてアッセンブルされるウェブページであり、そしてこれら全てのファクタに基づいて、異なるファイルがダウンロードされる。依然、これは、非常に典型的な商業用ウェブページである。
図２４は、接続速度が上がるにつれてウェブページが生になるまでに経過する時間量を示している。１．５Ｍｂｐｓの接続速度２４０１では、従来のウェブブラウザを伴う従来のウェブサーバーを使用すると、ウェブページが生になるまでに１３．５秒を要する。１２Ｍｂｐｓの接続速度２４０２では、ロード時間は、６．５秒に短縮され、即ち約２倍の速さになる。しかし、９６Ｍｂｐｓの接続速度２４０３では、ロード時間は、約５．５秒までしか短縮されない。その理由として、このように高いダウンロード速度では、ファイルそれ自体をダウンロードするための時間は最小であるが、ファイル当たりの待ち時間、各々約１００ｍｓが依然あって、その結果、５４ファイル＊１００ｍｓ＝５．４秒の待ち時間となる。従って、家庭への接続がどれほど速くても、このウェブサイトは、常に、それが生となるまでに少なくとも少なくとも５．４秒を要する。別のファクタは、サーバー側のキューイングであり、即ち各ＨＴＴＰ要求がキューの後部に追加され、従って、ビジーのサーバーでは、これが大きな影響を及ぼす。というのは、ウェブサーバーから小さなアイテムを得るたびに、ＨＴＴＰ要求がその方向転換を待機する必要があるためである。
これらの問題を解決する１つの仕方は、ＨＴＴＰを破棄するか又は再定義することである。或いは、おそらく、ウェブサイト所有者がそのファイルを単一のファイル（例えば、Ａｄｏｂｅ Ｆｌａｓｈフォーマットの）へうまく合併することである。しかし、実際的な問題として、この会社及び多くの他の者は、そのウェブサイトアーキテクチャー多大な投資をしている。更に、ある家庭は、１２−１００Ｍｂｐｓの接続を有するが、大多数の家庭は、依然、ゆっくりした速度であり、ＨＴＴＰも、低速度で機能する。
１つの別の仕方は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５のウェブブラウザをホストすると共に、ＲＡＩＤアレイ１５１１−１５１２のウェブサーバーに対するファイルをホストすることである（或いは潜在的にウェブブラウザをホストするａｐｐ／ｇａｍｅサーバー１５２１−１５２５のＲＡＭ又はローカル記憶装置において）。インバウンドルーティング１５０２を通して（又はローカル記憶装置への）非常に高速の相互接続があるために、ＨＴＴＰを使用してファイル当たり１００ｍｓの待ち時間となるのではなく、ＨＴＴＰを使用してファイル当たり最小の待ち時間となる。従って、家にいるユーザがＨＴＴＰを通してウェブページにアクセスするのではなく、ユーザは、クライアント４１５を通してウェブページにアクセスすることができる。次いで、１．５Ｍｂｐｓの接続では（このウェブページがそのビデオに対して著しい帯域巾を要求しないので）、ウェブページは、線２４００当たり１秒未満で生となる。本質的に、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５で実行されるウェブブラウザが生のページを表示するまでは待ち時間がなく、そしてクライアント４１５がウェブブラウザからのビデオ出力を表示するまでは検出可能な待ち時間がない。ユーザがウェブページ上でマウス操作し及び／又はタイプするときに、ユーザの入力情報がａｐｐ／ｇａｍｅサーバー１５２１−１５２５で実行されるウェブブラウザへ送信され、そしてウェブブラウザが適宜に応答する。
この解決策の１つの欠点は、コンプレッサがビデオデータを常時送信する場合に、ウェブページが静的なものとなっても、帯域巾が使用されることである。これは、ウェブページが変化するときだけ（及びその場合にのみ）データを送信し、次いで、変化したページの部分にのみデータを送信するようにコンプレッサを構成することにより、改善することができる。常時変化するフラッシングバナー、等をもつ幾つかのウェブページがあるが、このようなウェブページは、うっとうしい傾向となり、通常、ウェブページは、何かが動く（例えば、ビデオクリップ）理由がない限り静的なものとなる。このようなウェブページの場合、おそらく、従来のウェブサーバーよりも少ないデータがホスティングサービス２１０を使用して送信される。というのは、実際に表示される映像だけが送信され、シンクライアント実行コードも、決して見ることのない大きなオブジェクト、例えば、ロールオーバー映像も、送信されないからである。
従って、ホスティングサービス２１０を使用して、レガシーウェブページをホストすると、ウェブページのロード時間は、ウェブページをオープンすることがテレビのチャンネルを切り換えることと同じである点まで短縮することができ、即ちウェブページは、実際上瞬時に生となる。
ゲーム及びアプリケーションのデバッグの容易化
上述したように、リアルタイムグラフィックを伴うビデオゲーム及びアプリケーションは、非常に複雑なアプリケーションであり、典型的に、市場に発売されるときに、バグを含むことがある。ソフトウェア開発者は、バグに関してユーザからフィードバックを得、そしてクラッシュ後にマシン状態を還元するための何らかの手段を有するが、ゲーム又はリアルタイムアプリケーションに何が起きてクラッシュさせ又は不適切に機能させたか厳密に識別することは非常に困難である。
ゲーム又はアプリケーションがホスティングサービス２１０で実行されるときに、ゲーム又はアプリケーションのビデオ／オーディオ出力は、遅延バッファ１５１５に常時記録される。更に、ウオッチドッグプロセスが、各ａｐｐ／ｇａｍｅサーバー１５２１−１５２５を動作させ、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５が円滑に動作することをホスティングサービスコントロールシステム４０１に規則的に報告する。ウオッチドッグプロセスが報告を怠った場合には、サーバーコントロールシステム４０１は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５と通信するように試み、それが成功すれば、どんなマシン状態が得られてもそれを収集する。どんな情報が得られてもそれが、遅延バッファ１５１５に記録されたビデオ／オーディオと共に、ソフトウェア開発者へ送信される。
従って、ゲーム又はアプリケーションソフトウェアの開発者が、ホスティングサービス２１０からクラッシュの通知を得ると、何がクラッシュを招いたかのフレームごとの記録を得る。この情報は、バグを追跡して修理する上で非常に価値がある。
又、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５がクラッシュすると、サーバーは、最も最近の再スタート可能な点において再スタートされ、そして技術的な困難さについて謝罪するメッセージがユーザに与えられる。
リソースの共有及びコストの節約
図４ａ及び４ｂに示されたシステムは、エンドユーザとゲーム及びアプリケーションの開発者の両方に種々の利益を与える。例えば、典型的に、家庭及びオフィスのクライアントシステム（例えば、ＰＣ又はゲームコンソール）は、一週間に僅かな時間しか使用されない。ニールセンエンターテイメント“Active Gamer Benchmark Study”(http://www.prnewswire.com/cgibin/stories.pl?ACCT=104&STORY=/www/story/10-05-2006/0004446115&EDATE=)による２００６年１０月５日プレスリリースによれば、積極的なゲーマーは、一週間に平均１４時間を費やしてビデオゲームコンソールをプレイし、そして一週間に約１７時間をハンドヘルド状態にしている。又、このレポートは、（コンソール、ハンドヘルド及びＰＣゲームプレイを含む）全てのゲームプレイ活動に対し、積極的なゲーマーは、一週間に平均１３時間を費やすと述べている。コンソールビデオゲームのプレイ時間が高い数値であることを考慮すれば、一週間は、２４＊７＝１６８時間であり、これは、積極的なゲーマーの家では、ビデオゲームコンソールが一週間の時間のうち１７／１６８＝１０％しか使用されないことを意味する。即ち、９０％の時間は、ビデオゲームコンソールがアイドル状態である。高いコストのビデオゲームコンソールであり、そして製造者がこのような装置に助成しているとすれば、高価なリソースの非常に非効率的な使い方である。会社の中のＰＣも、典型的に、一週間のうち僅かな時間しか使用されず、特に、Ａｕｔｏｄｅｓｋ Ｍａｙａのようなハイエンドアプリケーションにしばしば要求される非ポータブルのデスクトップＰＣがそうである。ある会社は、全ての時間及び休日も営業し、そしてあるＰＣ（例えば、夜家で仕事をするために持ち運ばれるポータブル）は、全ての時間及び休日も使用されるが、会社のほとんどの活動は、月曜日から金曜日まで所定の営業時間ゾーンのほぼＡＭ９時からＰＭ５時までを中心とする傾向があり、休日や休息時間（昼食時のような）にはほとんど行われず、又、ほとんどのＰＣ使用は、ユーザがＰＣに積極的に関わる間に生じるので、デスクトップＰＣの使用は、これらの営業時間に従う傾向となる。ＰＣが、週５日間、ＡＭ９時からＰＭ５時まで恒常的に使用されると仮定すれば、ＰＣが週の時間の４０／１６８＝２４％使用されることを意味する。高性能デスクトップＰＣは、会社にとって非常個高価な投資であり、これは、非常に低い利用レベルを反映している。デスクトップコンピュータで授業する学校は、週のより小さな時間巾でもコンピュータを使用し、授業時間に基づいて変化するが、ほとんどの授業は、月曜日から金曜日までの昼間の時間中に行われる。従って、一般的に、ＰＣ及びビデオゲームコンソールは、週の時間の僅かな部分でしか利用されない。
特に、多くの人々は、平日月曜日から金曜日の昼間の時間中は会社や学校にいるので、これらの人々は、一般的に、これらの時間中はビデオゲームをプレイせず、従って、ビデオゲームをプレイするのは、一般的に、夜や週末や休日のような他の時間中である。
図４ａに示すホスティングサービスの構成が与えられると、上述した２つの段落で述べた使用パターンは、リソースの非常に効率的な利用を生じる。明らかなように、特に、ユーザが、精巧な３Ｄビデオゲームのような複雑なアプリケーションに対してリアルタイム応答を要求する場合には、所与の時間にホスティングサービス２１０によってサービスを受けることのできるユーザの数に限度がある。しかし、典型的にほとんどの時間アイドル状態にある家庭のビデオゲームコンソールや会社で使用されるＰＣとは異なり、サーバー４０２は、異なる時間に異なるユーザにより再利用することができる。例えば、高性能のデュアルＣＰＵ及びデュアルＧＰＵと大容量のＲＡＭとを伴う高性能サーバー４０２は、平日のＡＭ９時からＰＭ５時まで会社及び学校により利用することができるが、夜、週末及び休日には精巧なビデオゲームをプレイするゲーマーにより利用することができる。同様に、低性能のアプリケーションは、Ｃｅｌｅｒｏｎ ＣＰＵをもち、ＧＰＵをもたず（又は非常にローエンドのＧＰＵをもち）且つ制限されたＲＡＭをもつ低性能サーバー４０２において会社の時間中に会社及び学校によって利用することができ、そして低性能ゲームは、会社の時間中でないときに低性能サーバー４０２を利用することができる。
更に、ここに述べるホスティングサービス構成では、数百万でなくても数千のユーザ間でリソースが効率的に共用される。一般的に、オンラインサービスは、所与の時間にサービスを利用する全ユーザベースの僅かな割合しかもたない。上述したニールセンのビデオゲーム使用統計値を考えると、なぜそうなるか調べることは容易である。積極的なゲーマーがコンソールゲームを一週間に１７時間しかプレイしない場合に、ゲームのピーク使用時間が、夜（５−ＡＭ１２、７＊５日＝３５時間／週）及び週末（ＡＭ８−ＡＭ１２、１６＊２＝３２時間／週）の典型的な非仕事非会社時間中であると仮定すると、１７時間のゲームプレイに対して一週間に３５＋３２＝６５ピーク時間ある。システムに対する厳密なピークユーザ負荷は、多くの理由で推定が困難であり、即ちあるユーザは、オフピーク時間中にプレイし、ある日中の時間にユーザの集団ピークがあり、ピーク時間は、プレイするゲームの形式により影響され（例えば、子供のゲームは、おそらく、夜の早い時間にプレイされ）、等々である。しかし、ゲーマーがプレイする平均時間数が、ゲーマーがおそらくゲームをプレイする日の時間数より遥かに少ないとすれば、所与の時間にホスティングサービス２１０のユーザ数の一部分がそれを使用するだけである。この分析のためには、ピーク負荷が１２．５％であると仮定しなければならない。従って、計算、圧縮及び帯域巾リソースの１２．５％が所与の時間に使用されるだけであり、その結果、リソースの再使用により所与の性能レベルのゲームをプレイするように所与のユーザをサポートするのにハードウェアコストの１２．５％だけとなる。
更に、あるゲーム及びアプリケーションが他のものより多くの計算パワーを要求するとすれば、ユーザによってプレイされるゲーム又は実行されるアプリケーションに基づいてリソースを動的に割り当てることができる。従って、低性能ゲーム又はアプリケーションを選択するユーザには、低性能（低廉な）サーバー４０２が割り当てられ、そして高性能ゲーム又はアプリケーションを選択するユーザには、高性能（より高価な）サーバー４０２が割り当てられる。実際に、所与のゲーム又はアプリケーションは、ゲーム又はアプリケーションの低性能区分及び高性能区分を有し、そしてユーザは、ゲーム又はアプリケーションのニーズを満足する最低コストのサーバー４０２でのユーザの動作を保持するように、ゲーム又はアプリケーションの区分間で、あるサーバー４０２から別のサーバー４０２へスイッチすることができる。単一のディスクより遥かに高速のＲＡＩＤアレイ４０５が、低性能のサーバー４０２でも使用でき、高速ディスク転送レートの利益を得る。従って、プレイされるゲーム又は使用されるアプリケーションの全部にわたるサーバー４０２当たりの平均コストは、最高性能のゲーム又はアプリケーションをプレイする最も高価なサーバー４０２のコストよりかなり低く、更に、低性能サーバー４０２は、ＲＡＩＤアレイ４０５からディスク性能の利益を導出する。
更に、ホスティングサービス２１０のサーバー４０２は、ネットワークインターフェイス以外のディスク又は周辺インターフェイスをもたないＰＣマザーボード以上のものではなく、やがて、ＳＡＮ４０３への高速ネットワークインターフェイスのみをもつ単一チップへと一体化される。又、ＲＡＩＤアレイ４０５は、おそらく、ディスクより遥かに多数のユーザ間で共用され、従って、活動的なユーザ当たりのディスクコストは、１つのディスクドライブより遥かに低い。この装置は、全て、おそらく、環境的に制御されたサーバールーム環境においてラック内に存在する。サーバー４０２がフェイルした場合に、ホスティングサービス２１０において容易に修理又は交換することができる。対照的に、家庭又はオフィスにおけるＰＣ又はゲームコンソールは、叩かれたり落とされたりすることによる適度な摩耗及び引き裂きに生き残ることができねばならず、ハウジングを要求し、少なくとも１つのディスクドライブを有し、悪い環境条件（例えば、他のギアでオーバーヘッドＡＶキャビネットへ詰め込まれる）に生き残らねばならず、サービス保証を要求し、パッケージされて出荷されねばならず、且つおそらく小売利ざやを徴収する小売店により販売される頑強なスタンドアローン機器でなければならない。更に、ＰＣ又はゲームコンソールは、ほとんどの時間に低性能ゲーム又はアプリケーション（或いはゲーム又はアプリケーションの区分）がプレイされても、将来のある時点で使用される最も計算上強いと予想されるゲーム又はアプリケーションのピーク性能を満足するように構成されねばならない。そして、ＰＣ又はコンソールがフェイルした場合に、それを修理するのは、高価で且つ時間のかかるプロセス（製造者、ユーザ及びソフトウェア開発者に悪影響が及ぶ）である。
従って、図４ａに示すシステムがローカル計算リソースに匹敵する経験をユーザに与えるとすれば、家庭、オフィス又は学校のユーザが所与のレベルの計算能力を経験するために、図４ａに示すアーキテクチャーを通してその計算能力を与えるのにかなり低廉なものとなる。
アップグレードの必要性の排除
更に、ユーザは、新たなゲームをプレイし又はより高い性能の新たなアプリケーションを取り扱うためにＰＣ及び／又はコンソールをアップグレードすることに関して心配する必要はもはやない。ホスティングサービス２１０におけるゲーム又はアプリケーションは、そのゲーム又はアプリケーションのためにどんな形式のサーバー４０２が要求されるかに関わらず、ユーザに利用することができ、全てのゲーム及びアプリケーションは、ほぼ即座に（即ち、サーバー４０２上のＲＡＩＤアレイ４０５又はローカル記憶装置から素早くロードされて）且つ最新の更新及びバグ修理で適切に実行される（即ち、ソフトウェア開発者は、所与のゲーム又はアプリケーションを実行するサーバー４０２にとって理想的なサーバー構成を選択し、次いで、最適なドライバを伴うサーバー４０２を構成することができ、そして時間の経過と共に、開発者は、ホスティングサービス２１０におけるゲーム又はアプリケーションの全てのコピーに更新、バグ修理、等を一度に与えることができる）。実際に、ユーザがホスティングサービス２１０の使用を開始した後に、ユーザは、おそらく、（例えば、更新及び／又はバグ修理を通じて）優れた経験を与え続けるゲーム及びアプリケーションを見出し、そしてユーザは、１年前に存在しなかったコンピューティング技術（例えば、高性能ＧＰＵ）を使用するサービス２１０に新たなゲーム又はアプリケーションを利用できることを１年後に発見し、ひいては、１年後にゲームをプレイし又はアプリケーションを実行する技術を１年前に買うことがユーザにとって不可能であったことを発見することになろう。ゲームをプレイし又はアプリケーションを実行する計算リソースは、ユーザには見えないから（即ち、ユーザの観点から、ユーザは、テレビのチャンネルを切り換えるのと同様に、ほぼ瞬時に実行を開始するゲーム又はアプリケーションを単に選択するだけであるから）、ユーザのハードウェアは、ユーザが絶えずアップグレードに気付かなくても「アップグレード」されている。
バックアップの必要性の排除
会社、学校及び家庭においてユーザに対する別の主たる問題は、バックアップである。ローカルＰＣ又はビデオゲームコンソールに記憶された情報（例えば、コンソールの場合には、ユーザのゲーム成績及びランキング）は、ディスクがフェイルするか、又は偶発的な消去があった場合に、失われる。ＰＣのための手動又は自動バックアップを与えるアプリケーションは、多数入手でき、ゲームコンソールの状態をバックアップのためにオンラインサーバーへアップロードできるが、ローカルバックアップは、典型的に、別のローカルディスク（又は他の不揮発性記憶装置）へコピーして、これをどこか安全な場所に保管し組織化しなければならず、又、オンラインサービスに対するバックアップは、典型的な低コストインターネット接続を通して利用できるのがゆっくりのアップストリーム速度であるから、しばしば制限がある。図４ａのホスティングサービス２１０では、ＲＡＩＤアレイ４０５に記憶されるデータは、当業者に良く知られた従来のＲＡＩＤ構成技術を使用して、ディスクがフェイルした場合にも、データが失われず、そのフェイルしたディスクを収容しているサーバーセンターの専門家が通知を受けて、ディスクを交換し、ＲＡＩＤアレイがもう一度フェイル許容となるよう自動的に更新されるように、構成することができる。更に、全てのディスクドライブが互いに近くにあり、そしてそれらの間にはＳＡＮ４０２を通して高速ローカルネットワークがあるので、サーバーセンターにおいて全てのディスクシステムを規則的に二次記憶装置でバックアップし、この二次記憶装置をサーバーセンターに保管するか又は離れた場所へ移すことは困難ではない。ホスティングサービス２１０のユーザの視点から、データは、単純に常時セキュアなものであり、バックアップについて考える必要はない。
デモへのアクセス
ユーザは、多くの場合に、ゲーム又はアプリケーションを購入する前にそれを試したがる。上述したように、ゲーム及びアプリケーションをデモする従来の手段があるが（「デモ」の動詞形は、デモンストレーションバージョンを試すことを意味し、これは、名詞として「デモ」とも称される）、それらの各々は、制限及び／又は不便さで悩まされている。ホスティングサービス２１０を使用すると、ユーザがデモを試すのが容易で且つ便利になる。実際に、全てのユーザがユーザインターフェイス（以下に述べるような）を通してモデを選択して、デモを試す。デモは、デモに適したサーバー４０２へほぼ瞬間的にロードを行い、そして他のゲーム又はアプリケーションと同様に実行するだけである。デモが非常に高性能のサーバー４０２を要求するか低性能のサーバー４０２を要求するかに関わらず、又、どんな形式の家庭又はオフィスクライアント４１５をユーザが使用しても、ユーザの観点から、デモは、きちんと機能する。ゲーム又はアプリケーションデモのソフトウェア発行者は、どんなデモをどれほど長くユーザが試すことが許されるか厳密に制御することができ、そしてもちろん、デモは、デモンストレーションされるゲーム又はアプリケーションのフルバージョンにアクセスする機会をユーザに与えるユーザインターフェイスエレメントを含むことができる。
デモは、おそらく、価格未満又は無料で提供されるので、あるユーザは、デモ（特に、繰り返しプレイするのが楽しいゲームデモ）を繰り返し使用することを試みる。ホスティングサービス２１０は、所与のユーザに対してデモの使用を制限する種々の技術を使用することができる。最も単純な解決策は、ユーザごとにユーザＩＤを確立して、所与のユーザＩＤがデモをプレイすることが許される回数を制限することである。しかしながら、ユーザは、ユーザＩＤが無料の場合には、複数のユーザＩＤを設定することができる。この問題に対処する１つの技術は、所与のクライアント４１５がデモをプレイすることが許される回数を制限することである。クライアントがスタンドアローン装置である場合には、装置がシリアルナンバーを有し、ホスティングサービス２１０は、そのシリアルナンバーをもつクライアントによりデモをアクセスできる回数を制限することができる。クライアント４１５がＰＣ又は他の装置のソフトウェアとして実行される場合には、ホスティングサービス２１０によりシリアルナンバーを指定してＰＣに記憶し、これを使用してデモの使用を制限できるが、ＰＣをユーザが再プログラムでき且つシリアルナンバーを消去又は変更できるとすれば、ＰＣネットワークアダプタ「メディアアクセスコントロール（ＭＡＣ）」アドレス（及び／又は他のマシン特有の識別子、例えば、ハードドライブのシリアルナンバー、等）のレコードを保持して、それに対してデモの使用を制限するという別のオプションがホスティングサービス２１０に対して設けられる。しかしながら、ネットワークアダプタのＭＡＣアドレスを変更できるとすれば、これは、フールプルーフな方法ではない。別の解決策は、所与のＩＰアドレスに対してデモをプレイできる回数を制限することである。ＩＰアドレスは、ケーブルモデム及びＤＳＬプロバイダーによって周期的に再指定できるが、実際にはあまり頻繁に行われず、ＩＰが、住居ＤＳＬ又はケーブルモデムアクセスに対するＩＰアドレスのブロック内にあると決定できる場合には（例えば、ＩＳＰにコンタクトすることによって）、典型的に、所与の家庭に対して少数のデモ使用を確立することができる。又、家庭において同じＩＰアドレスを共有するＮＡＴルーターの後方に複数の装置が存在することもあるが、典型的に、住居設定では、このような装置は限定された数だけである。ＩＰアドレスが、会社にサービスするブロック内にある場合には、１つの会社に対して多数のデモを確立することができる。しかし、結局、ＰＣにおけるデモの数を制限する最良の方法は、上述した全ての解決策の組合せである。断固とした技術的に熟練したユーザが、繰り返しプレイされるデモの数を制限できるフールプルーフの方法はないが、多数のバリアを生成することで、トラブルの多いＰＣユーザがデモシステムを悪用しても価値がなく、むしろ、デモをそれらが意図されたように使用して新たなゲーム及びアプリケーションを試せるように、充分な抑止力を生み出すことができる。
学校、会社及び他の施設の利益
特に、図４ａに示すシステムを利用する会社、学校及び他の施設に対して著しい利益が得られる。会社及び学校は、ＰＣをインストールし、維持し及びアップグレードすることに関連して著しいコストがかかり、それが、Ｍａｙａのような高性能アプリケーションを実行するためのＰＣになったときには、特にそうである。上述したように、ＰＣは、一般的に、週の時間の僅かな部分しか利用されず、そして家庭の場合と同様に、所与のレベルの性能能力を伴うＰＣのコストは、オフィス又は学校環境の方がサーバーセンター環境よりも遥かに高い。
大きな会社又は学校（例えば、大規模な大学）の場合には、そのようなエンティティのＩＴ部門がサーバーセンターを設定し、そしてＬＡＮグレード接続を経てリモートアクセスされるコンピュータを維持するのが実際的である。ＬＡＮを経て又はオフィス間のプライベートな広帯域巾接続を通してコンピュータにリモートアクセスするための解決策は、多数存在する。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓターミナルサーバーでは、又はＲｅａｌＶＮＣ社からのＶＮＣのようなバーチャルネットワーク計算アプリケーションを通して、或いはＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓからのシンクライアント手段を通して、ユーザは、グラフィック応答時間及びユーザ経験においてある範囲のクオリティでＰＣ又はサーバーへのリモートアクセスを得ることができる。更に、このような自己管理型のサーバーセンターは、典型的に、単一の会社又は学校専用であり、従って、異種のアプリケーション（例えば、娯楽及び会社アプリケーション）が週の異なる時間に同じ計算リソースを利用するときに考えられる使用の重複の利点を取り入れることができない。従って、多くの会社及び学校は、各ユーザへのＬＡＮ速度ネットワーク接続を有するサーバーセンターをそれ自身で設定するスケール、リソース又は専門知識に欠ける。実際に、学校及び会社の大部分は、家庭と同じインターネット接続（例えば、ＤＳＬ、ケーブルモデム）を有する。
このような組織は、定常的ベース又は周期的ベースのいずれかで非常に高性能の計算の必要性を依然有している。例えば、小さな建築会社は、少数の建築家しかおらず、設計の仕事をするときに計算の必要性が比較的僅かであるが、非常に高性能の３Ｄ計算を周期的に必要とする（例えば、クライアントに対する新たな建築設計の３Ｄフライスルーを創作するときに）。図４ａに示すシステムは、このような組織に非常に良く適している。組織は、典型的に非常に安価な、家庭に提供されるものと同じ種類のネットワーク接続（例えば、ＤＳＬ、ケーブルモデム）以上のものを必要としない。それらは、安価なＰＣをクライアント４１５として利用するか、或いはＰＣを全く省き、制御信号ロジック４１３及び短待ち時間ビデオ解凍４１２を簡単に具現化する安価な専用装置を利用するかのいずれかである。これらの特徴は、ＰＣの窃盗や、ＰＣ内の専用コンポーネントへのダメージに伴う問題がある学校にとって特に魅力的である。
このような構成は、このような組織の多数の問題を解決する（そしてこれら効果の多くは、一般的な計算を行う家庭のユーザによっても共用される）。その１つとして、運営コスト（最終的に、実現可能な取引を得るためにある形態でユーザへ還元されねばならない）を非常に低くすることができる。というのは、（ａ）計算リソースが、週内に異なるピーク使用時間を有する他のアプリケーションと共有され、（ｂ）組織が、必要な時だけ高性能計算リソースにアクセスする（及びそのコストを被る）ことができ、（ｃ）組織が、高性能計算リソースをバックアップ又は維持するためのリソースを設ける必要がないからである。
海賊行為の排除
更に、ゲーム、アプリケーション、双方向映画、等は、今日のように海賊行為を受けることがもはやない。ゲームは、サービスセンターで実行されるので、ユーザには、基礎的なプログラムコードへのアクセス権が与えられず、従って、海賊行為を受けるものは何もない。ユーザがソースコードをコピーする場合でも、ユーザは、標準的なゲームコンソール又は家庭用コンピュータにおいてコードを実行することはできない。これは、標準的なビデオゲームが入手できない中国のような世界の場所に市場を開く。又、中古ゲームの再販売はできない。
ゲームの開発者にとって、今日、市場の不連続部は僅かである。ホスティングサービス２１０は、技術の完全に新たな世代がユーザや開発者を強制的にアップグレードさせ且つゲーム開発者がハードウェアプラットホームの適時の配信に依存する現在の状況とは対照的に、ゲームの要件が変化するにつれて時間と共に徐々に更新することができる。
ストリーミング双方向ビデオ
以上の説明は、一般的インターネットをベースとする短待ち時間のストリーミング双方向ビデオ（これは、ここで使用されるオーディオもビデオと一緒に暗示的に含む）の新規な基礎的概念により可能となる広範囲なアプリケーションを述べるものである。インターネットを通してストリーミングビデオを与える従来のシステムは、長待ち時間の双方向性で具現化できるアプリケーションを可能にするだけである。例えば、リニアビデオのための再生コントロール（例えば、休止、巻き戻し、早送り）は、長い待ち時間で充分に機能し、リニアビデオフィードの中から選択することができる。そして、上述したように、あるビデオゲームの性質は、それらを長待ち時間でプレイすることを許す。しかし、ストリーミングビデオのための従来の解決策の長待ち時間（又は低圧縮比）は、ストリーミングビデオの潜在的なアプリケーションを甚だしく制限するか、又はそれらの開発を特殊なネットワーク環境へと狭め、そしてそのような環境においても、従来の技術は、ネットワークに実質的な負担を導入する。ここに述べる技術は、インターネットを通る短待ち時間のストリーミング双方向ビデオ、特に、消費者グレードのインターネット接続を通して可能になるもの、で考えられる広範囲なアプリケーションに対してドアを開く。
実際上任意の量の計算パワー、任意の量の高速記憶、並びにパワフルなサーバーの中の非常に高速なネットワークでユーザ経験の向上を果たすに充分な、図４ｃのクライアント４６５と同程度に小さいクライアント装置で、実際に、新しい計算の時代を可能にする。更に、帯域巾要件は、システムの計算パワーが増大するにつれて拡大しないので（即ち、帯域巾要件は、表示解像度、クオリティ及びフレームレートに結び付いているだけであるので）、ブロードバンドインターネット接続が偏在し（例えば、広く普及した短待ち時間のワイヤレスカバレージを通して）、信頼性があり、且つ全ユーザのディスプレイ装置４２２のニーズを満足するに充分な広い帯域巾であるときには、典型的な消費者及び会社向けアプリケーションに対して、（Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ、ＯＳＸ、等を実行するＰＣ又は移動電話のような）シッククライアントが必要か、又は（Ａｄｏｂｅ Ｆｌａｓｈ又はＪａｖａのような）シンクライアントでもよいかが問題となる。
ストリーミング双方向ビデオの出現は、計算アーキテクチャーの構造についての仮定を考え直す結果となった。その一例が、図１５に示すホスティングサービス２１０のサーバーセンター実施形態である。遅延バッファ及び／又はグループビデオ１５５０のためのビデオ経路は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５のマルチキャストされたストリーミング双方向ビデオ出力が、経路１５５２を経てリアルタイムで、又は経路１５５１を経て選択可能な遅延の後に、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５へフィードバックされる。これは、従来のサーバー又はローカル計算アーキテクチャーでは不可能であるか又は実現不能な広範囲の実際的なアプリケーション（例えば、図１６，１７及び２０に示すもののような）を可能にする。しかし、より一般的なアーキテクチャー上の特徴として、フィードバックループ１５５０が与えるものは、ストリーミング双方向ビデオレベルでの反復である。というのは、アプリケーションが要求したときに、ビデオを不定にループバックできるからである。これは、従来得られなかった広範囲のアプリケーションの可能性を実現できるようにする。
別の重要なアーキテクチャー上の特徴は、ビデオストリームが単一方向のＵＤＰストリームであることである。これは、実際上、ストリーミング双方向ビデオのマルチキャスティングを任意の度合いで行えるようにする（対照的に、ＴＣＰ／ＩＰストリームの両方向ストリームは、ユーザの数が増えるにつれて前後通信からネットワークに益々大きな渋滞を生じることになる）。マルチキャスティングは、サーバーセンター内で重要な能力である。というのは、システムが、インターネットユーザ（及び実際には世界の人口）の増大するニーズに応答して、１対多又は多対多で、通信を行えるようにするからである。この場合も、ストリーミング双方向ビデオ反復及びマルチキャスティングの両方の使用を示す図１６について述べた例は、可能性についての非常に大きな氷山の頂点に過ぎない。
一実施形態では、ここ及び関連するステップに示す種々の機能的モジュールは、そのステップを遂行するための固定布線ロジックを含む特定のハードウェアコンポーネント、例えば、特定用途向け集積回路（ＡＳＩＣ）により遂行されるか、又はプログラムされたコンピュータコンポーネント及びカスタムハードウェアコンポーネントの組合せにより遂行される。
一実施形態では、これらモジュールは、テキサスインスツルーメント社のＴＭＳ３２０ｘアーキテクチャー（例えば、ＴＭＳ３２０Ｃ６０００、ＴＭＳ３２０Ｃ５０００、等）のプログラム可能なデジタル信号プロセッサ（ＤＳＰ）において具現化される。これらの基礎的な原理に適合する種々の異なるＤＳＰを使用することができる。
これら実施形態は、上述した種々のステップを含むことができる。これらステップは、汎用プロセッサ又は特殊目的のプロセッサが幾つかのステップを遂行するようにさせるマシン実行可能なインストラクションにおいて実施することができる。これら基礎的な原理に関連しない種々の要素、例えば、コンピュータメモリ、ハードドライブ、入力装置は、適切な観点を不明瞭にしないために図面から除外してある。
ここに開示する要旨の要素は、マシン実行可能なインストラクションを記憶するためのマシン読み取り可能なメディアとして与えられてもよい。マシン読み取り可能なメディアは、フラッシュメモリ、光学的ディスク、ＣＤ−ＲＯＭ、ＤＶＤ ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、電子的インストラクションを記憶するのに適した伝播メディア又は他の形式のマシン読み取り可能なメディアを含むが、これらに限定されない。例えば、本発明は、通信リンク（例えば、モデム又はネットワーク接続）を経ての搬送波又は他の伝播メディアで実施されるデータ信号によりリモートコンピュータ（例えば、サーバー）から要求側コンピュータ（例えば、クライアント）へ転送されるコンピュータプログラムとしてダウンロードすることができる。
又、ここに開示する要旨の要素は、一連のオペレーションを遂行するようにコンピュータ（例えば、プロセッサ又は他の電子装置）をプログラムするのに使用されるインストラクションが記憶されたマシン読み取り可能なメディアを含むコンピュータプログラム製品として提供されてもよいことを理解されたい。或いは又、オペレーションは、ハードウェア及びソフトウェアの組合せにより遂行されてもよい。マシン読み取り可能なメディアは、フロッピー（登録商標）ディスケット、光学的ディスク、ＣＤ−ＲＯＭ、及び磁気・光学ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、電子的インストラクションを記憶するのに適した伝播メディア又は他の形式のメディア／マシン読み取り可能なメディアを含むが、これらに限定されない。例えば、ここに開示する要旨の要素は、通信リンク（例えば、モデム又はネットワーク接続）を経ての搬送波又は他の伝播メディアで実施されるデータ信号によりプログラムがリモートコンピュータ又は電子装置から要求側コンピュータへ転送されるようなコンピュータプログラム製品としてダウンロードすることができる。
更に、ここに開示する要旨は、特定の実施形態に関連して説明したが、本開示の範囲内で多数の変更や修正がなされ得る。従って、本発明及び添付図面は、単なる例示に過ぎず、それに限定されるものではない。
１００：ＣＰＵ／ＧＰＵ
１０１：ＲＡＭ
１０２：ディスプレイ装置
１０３：ハードドライブ
１０４：光学的メディアドライブ
１０５：ネットワーク接続
１０６：ゲームコントローラ
２０５：クライアント装置
２０６：インターネット
２１０：ホスティングサービス
２１１：ユーザの家屋
２２０：ソフトウェア開発者
２２１：入力装置
２２２：モニタ又はＴＶ受像機
３０１：最大データレート
３０２：実際に利用できる最大データレート
３０３：要求されたデータレート
４０１：ホスティングサービスコントロールシステム
４０２：サーバー
４０３：ＳＡＮ
４０４：低待ち時間のビデオ圧縮
４０５：ＲＡＩＤアレイ
４０６：コントロール信号
４１０：インターネット
４１２：低待ち時間の解凍
４１３：コントロール信号ロジック
４１５：家庭又はオフィスクライアント
４２１：入力装置
４２２：モニタ又はＨＤＴＶ
４４１：中央オフィス、ヘッドエンド、セルタワー、等
４４２：ＷＡＮインターフェイス
４４３：ファイアウオール／ルーター／ＮＡＴ
４４４：ＷＡＮインターフェイス
４５１：コントロール信号
４５２：ユーザの家屋ルーティング
４５３：ユーザＩＳＰ
４５４：インターネット
４５５：サーバーセンタールーティング
４５６：フレーム計算
４５７：ビデオ圧縮
４５８：ビデオ解凍
４６２：パワーオーバーイーサネット
４６３：ＨＤＭＩ出力
４６４：ディスプレイ能力
４６５：イーサネット対ＨＤＭＩクライアント
４６６：シャッター付き眼鏡
４６８：モニタ又はＳＤ／ＨＤＴＶ
４６９：ブルーツース入力装置
４７６：フラッシュ
４８０：バス
４８１：イーサネットインターフェイス
４８３：コントロールＣＰＵ
４８４：ブルーツース
４８６：ビデオデコンプレッサ
４８７：ビデオ出力
４８８：オーディオデコンプレッサ
４８９：オーディオ出力
４９０：ＨＤＭＩ
４９７：イーサネット
４９９：電力

Claims (1)

  1. ストリーミング双方向ビデオの形態のユーザページを発生して、インターネットを経てサーバーセンターのサーバーに接続されたユーザクライアントのディスプレイへ流すためのプログラムをそのサーバーにおいて実行するステップであって、そのグラフィックユーザインターフェイスは、複数のビデオウインドウを含み、そして１つ以上のビデオウインドウがリアルタイムストリーミング双方向ビデオを含むものであるステップと、
    以前に記録されたビデオセグメントを同時に表示するステップと、
    ユーザが以前に記録されたビデオセグメントを再生できるようにするステップと、
    を備えた方法。
JP2010537059A 2007-12-05 2008-12-04 記録されたビデオセグメントと一体化されたストリーミング双方向ビデオ Pending JP2011507340A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/999,457 US9003461B2 (en) 2002-12-10 2007-12-05 Streaming interactive video integrated with recorded video segments
PCT/US2008/085554 WO2009073799A1 (en) 2007-12-05 2008-12-04 Streaming interactive video integrated with recorded video segments

Publications (1)

Publication Number Publication Date
JP2011507340A true JP2011507340A (ja) 2011-03-03

Family

ID=40718173

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010537059A Pending JP2011507340A (ja) 2007-12-05 2008-12-04 記録されたビデオセグメントと一体化されたストリーミング双方向ビデオ

Country Status (10)

Country Link
US (2) US9003461B2 (ja)
EP (1) EP2227728A4 (ja)
JP (1) JP2011507340A (ja)
KR (1) KR20100111668A (ja)
CN (1) CN101889254A (ja)
AU (1) AU2008333801A1 (ja)
CA (1) CA2707674A1 (ja)
NZ (1) NZ585658A (ja)
RU (1) RU2496135C2 (ja)
WO (1) WO2009073799A1 (ja)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090265245A1 (en) * 2005-06-27 2009-10-22 Wright Rocky J Communications platform for enabling bi-directional communication between providers consumers and advertisers using a computer network and/or mobile devices using desktop and or mobiletop interactive windowless video
US8888592B1 (en) 2009-06-01 2014-11-18 Sony Computer Entertainment America Llc Voice overlay
US8968087B1 (en) 2009-06-01 2015-03-03 Sony Computer Entertainment America Llc Video game overlay
US8613673B2 (en) 2008-12-15 2013-12-24 Sony Computer Entertainment America Llc Intelligent game loading
US8147339B1 (en) 2007-12-15 2012-04-03 Gaikai Inc. Systems and methods of serving game video
US8926435B2 (en) 2008-12-15 2015-01-06 Sony Computer Entertainment America Llc Dual-mode program execution
US8506402B2 (en) 2009-06-01 2013-08-13 Sony Computer Entertainment America Llc Game execution environments
US8707179B2 (en) 2009-09-25 2014-04-22 Avazap, Inc. Frameless video system
US8771064B2 (en) 2010-05-26 2014-07-08 Aristocrat Technologies Australia Pty Limited Gaming system and a method of gaming
US8560331B1 (en) 2010-08-02 2013-10-15 Sony Computer Entertainment America Llc Audio acceleration
KR102000618B1 (ko) 2010-09-13 2019-10-21 소니 인터랙티브 엔터테인먼트 아메리카 엘엘씨 부가기능의 관리
KR20130090898A (ko) 2010-09-13 2013-08-14 소니 컴퓨터 엔터테인먼트 아메리카 엘엘씨 2중 모드 프로그램 실행 및 로딩
US9059817B2 (en) * 2010-11-22 2015-06-16 Microsoft Technology Licensing, Llc Minimizing network latency in interactive internet applications
WO2012078640A2 (en) * 2010-12-06 2012-06-14 The Regents Of The University Of California Rendering and encoding adaptation to address computation and network bandwidth constraints
KR101312268B1 (ko) 2010-12-24 2013-09-25 주식회사 케이티 클라우드 컴퓨팅 환경에서 게임 서비스 제공 방법, 클라우드 컴퓨팅 서버, 및 클라우드 컴퓨팅 시스템
US9553924B1 (en) * 2011-06-13 2017-01-24 Arris Enterprises, Inc. Load sharing among loosely coupled or independent video servers
CN103024405B (zh) * 2011-09-20 2015-06-17 中国电信股份有限公司 嵌套视频窗口页面的3d显示方法、装置和系统及机顶盒
US20130088569A1 (en) * 2011-10-10 2013-04-11 Global Development Holding Ltd. Apparatuses, methods and systems for provision of 3d content over a communication network
US8636589B2 (en) * 2012-04-26 2014-01-28 Riot Games, Inc. Systems and methods that enable a spectator's experience for online active games
US9403090B2 (en) 2012-04-26 2016-08-02 Riot Games, Inc. Video game system with spectator mode hud
CN103475679B (zh) * 2012-06-06 2017-09-26 百度在线网络技术（北京）有限公司 对分片请求进行定长对齐的缓存方法、系统及装置
US20140094304A1 (en) * 2012-09-28 2014-04-03 Red Robot Labs, Inc. Apparatus and Method for In-Game Video Capture
US9264749B2 (en) * 2012-12-13 2016-02-16 Microsoft Technology Licensing, Llc Server GPU assistance for mobile GPU applications
US9460541B2 (en) * 2013-03-29 2016-10-04 Intel Corporation Avatar animation, social networking and touch screen applications
US20150007057A1 (en) * 2013-07-01 2015-01-01 Cisco Technlogy, Inc. System and Method for Application Sharing
EP3014387A4 (en) * 2013-08-07 2017-01-04 Fiiser, Inc. Methods and systems for generating dynamic user interface
US9336685B2 (en) * 2013-08-12 2016-05-10 Curious.Com, Inc. Video lesson builder system and method
US9792778B2 (en) * 2013-09-26 2017-10-17 Bally Gaming, Inc. Bundling assets for mobile devices
JP5817858B2 (ja) * 2014-01-30 2015-11-18 カシオ計算機株式会社 画像処理装置、画像処理方法、及びプログラム
KR102197067B1 (ko) * 2014-04-02 2020-12-30 삼성전자 주식회사 멀티 프레임들의 동일한 영역을 연속으로 렌더링하는 방법 및 장치
CN104731335B (zh) * 2015-03-26 2018-03-23 联想(北京)有限公司 一种播放内容调整方法及电子设备
CN104735385B (zh) 2015-03-31 2018-10-12 小米科技有限责任公司 播放控制方法及装置、电子设备
WO2016205145A1 (en) * 2015-06-14 2016-12-22 Sony Interactive Entertainment Inc. Expanded field of view re-rendering for vr spectating
CN105117187B (zh) * 2015-08-13 2018-04-24 小米科技有限责任公司 多媒体信息展示方法和装置
US9873056B2 (en) 2015-09-15 2018-01-23 Square Enix Holdings Co., Ltd. Game system including third party input
US9473758B1 (en) * 2015-12-06 2016-10-18 Sliver VR Technologies, Inc. Methods and systems for game video recording and virtual reality replay
US9918042B2 (en) 2016-04-29 2018-03-13 Getgo, Inc. Performing electronic conferencing operations using electronic portals at different locations
US10157638B2 (en) * 2016-06-24 2018-12-18 Google Llc Collage of interesting moments in a video
DE102016116555A1 (de) * 2016-09-05 2018-03-08 Nanocosmos Informationstechnologien Gmbh Verfahren zur Übertragung von echtzeitbasierten digitalen Videosignalen in Netzwerken
US9641566B1 (en) 2016-09-20 2017-05-02 Opentest, Inc. Methods and systems for instantaneous asynchronous media sharing
US20180104587A1 (en) * 2016-10-14 2018-04-19 Microsoft Technology Licensing, Llc Video game platform based on state data
JP6277503B1 (ja) * 2017-03-15 2018-02-14 株式会社コナミデジタルエンタテインメント サーバ装置、及びそれに用いられるコンピュータプログラム
CN107569850B (zh) * 2017-10-18 2021-01-26 广州谷得网络科技有限公司 一种vr线下体验多人游戏平台
CN108134944B (zh) * 2017-12-14 2020-05-29 北京奇艺世纪科技有限公司 一种收入异常主播用户的识别方法、装置及电子设备
US20190272156A1 (en) 2018-03-01 2019-09-05 Vreal Inc Virtual reality capture and replay systems and methods
US11032345B2 (en) 2018-05-10 2021-06-08 Microsoft Technology Licensing, Llc Client side data stream processing
US10924525B2 (en) 2018-10-01 2021-02-16 Microsoft Technology Licensing, Llc Inducing higher input latency in multiplayer programs
US11263670B2 (en) * 2018-11-19 2022-03-01 Activision Publishing, Inc. Systems and methods for dynamically modifying video game content based on non-video gaming content being concurrently experienced by a user
US10974153B2 (en) * 2019-01-17 2021-04-13 Disney Enterprises, Inc. Streamable compressed geometry for live broadcast
US10773157B1 (en) 2019-07-26 2020-09-15 Arkade, Inc. Interactive computing devices and accessories
US10946272B2 (en) * 2019-07-26 2021-03-16 Arkade, Inc. PC blaster game console
US10893127B1 (en) 2019-07-26 2021-01-12 Arkade, Inc. System and method for communicating interactive data between heterogeneous devices
US11711571B2 (en) * 2020-03-06 2023-07-25 Advanced Micro Devices, Inc. Client-side offload of graphics effects processing
US20220212100A1 (en) * 2021-01-04 2022-07-07 Microsoft Technology Licensing, Llc Systems and methods for streaming interactive applications

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004512865A (ja) * 2000-08-25 2004-04-30 インテロシティー　ユーエスエイ，アイエヌシー． セットトップボックスを介した対話型ゲーム
JP2005348262A (ja) * 2004-06-04 2005-12-15 Ricoh Co Ltd データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体

Family Cites Families (269)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4582324A (en) * 1984-01-04 1986-04-15 Bally Manufacturing Corporation Illusion of skill game machine for a gaming system
JPH04275784A (ja) 1991-03-04 1992-10-01 Matsushita Electric Ind Co Ltd 映像信号切り換え装置
KR100254956B1 (ko) 1991-12-23 2002-12-18 코닌클리케 필립스 일렉트로닉스 엔.브이. 재귀비데오신호프로세서
US5926208A (en) * 1992-02-19 1999-07-20 Noonen; Michael Video compression and decompression arrangement having reconfigurable camera and low-bandwidth transmission capability
US5291281A (en) 1992-06-18 1994-03-01 General Instrument Corporation Adaptive coding level control for video compression systems
US5289276A (en) 1992-06-19 1994-02-22 General Electric Company Method and apparatus for conveying compressed video data over a noisy communication channel
CA2139861A1 (en) * 1992-07-08 1994-01-20 Bernard J. Craig Media server for supplying video and multi-media data over the public telephone switched network
US5845088A (en) 1992-11-16 1998-12-01 Multimedia Systems Corporation Method for the production and transmission of enhanced interactive multimedia information
CA2144253C (en) * 1994-04-01 1999-09-21 Bruce F. Naylor System and method of generating compressed video graphics images
US5558339A (en) 1994-05-05 1996-09-24 Perlman; Stephen G. Network architecture to support recording and playback of real-time video games
EP0774186A4 (en) * 1994-05-05 2005-07-20 Catapult Entertainment Inc NETWORK ARCHITECTURE FOR REAL-TIME VIDEO GAMES
US5586257A (en) 1994-05-05 1996-12-17 Perlman; Stephen G. Network architecture to support multiple site real-time video games
JPH07319747A (ja) 1994-05-24 1995-12-08 Nec Telecom Syst Ltd データ更新システム
US5624316A (en) * 1994-06-06 1997-04-29 Catapult Entertainment Inc. Video game enhancer with intergral modem and smart card interface
US5583561A (en) 1994-06-07 1996-12-10 Unisys Corporation Multi-cast digital video data server using synchronization groups
US5606359A (en) 1994-06-30 1997-02-25 Hewlett-Packard Company Video on demand system with multiple data sources configured to provide vcr-like services
US5481312A (en) 1994-09-12 1996-01-02 At&T Corp. Method of and apparatus for the transmission of high and low priority segments of a video bitstream over packet networks
AU4158496A (en) * 1994-11-14 1996-06-06 Catapult Entertainment, Inc. Method and apparatus for synchronizing the execution of multiple video game systems in a networked environment
US6005561A (en) * 1994-12-14 1999-12-21 The 3Do Company Interactive information delivery system
US5517257A (en) * 1995-03-28 1996-05-14 Microsoft Corporation Video control user interface for interactive television systems and method for controlling display of a video movie
US5793410A (en) * 1995-05-26 1998-08-11 Hyundai Electronics America Video pedestal network
US5917962A (en) * 1995-06-06 1999-06-29 Apple Computer, Inc. Method and apparatus for partitioning an image
US5970143A (en) 1995-11-22 1999-10-19 Walker Asset Management Lp Remote-auditing of computer generated outcomes, authenticated billing and access control, and software metering system using cryptographic and other protocols
US5768382A (en) * 1995-11-22 1998-06-16 Walker Asset Management Limited Partnership Remote-auditing of computer generated outcomes and authenticated biling and access control system using cryptographic and other protocols
US5623308A (en) * 1995-07-07 1997-04-22 Lucent Technologies Inc. Multiple resolution, multi-stream video system using a single standard coder
US5830068A (en) 1995-09-08 1998-11-03 Ods Technologies, L.P. Interactive wagering systems and processes
EP0808064B1 (en) * 1995-12-01 2004-03-03 Matsushita Electric Industrial Co., Ltd. Apparatus, system and method for information processing for data transfer network
JPH09179752A (ja) 1995-12-25 1997-07-11 Hudson Soft Co Ltd Ｒｏｍカートリッジ用デバッグ方法および装置
US5894556A (en) 1996-03-21 1999-04-13 Mpath Interactive, Inc. Network match maker matching requesters based on communication attribute between the requesters
US6134590A (en) 1996-04-16 2000-10-17 Webtv Networks, Inc. Method and apparatus for automatically connecting devices to a local network
US6175854B1 (en) 1996-06-11 2001-01-16 Ameritech Services, Inc. Computer system architecture and method for multi-user, real-time applications
US5828370A (en) 1996-07-01 1998-10-27 Thompson Consumer Electronics Inc. Video delivery system and method for displaying indexing slider bar on the subscriber video screen
US20030093790A1 (en) 2000-03-28 2003-05-15 Logan James D. Audio and video program recording, editing and playback systems using metadata
US6343987B2 (en) 1996-11-07 2002-02-05 Kabushiki Kaisha Sega Enterprises Image processing device, image processing method and recording medium
US5861920A (en) 1996-11-08 1999-01-19 Hughes Electronics Corporation Hierarchical low latency video compression
US6037983A (en) 1996-11-08 2000-03-14 Hughes Electronics Corporation High quality reduced latency transmission of video objects
US5903735A (en) 1996-12-24 1999-05-11 Intel Corporation Method and apparatus for transmitting data having minimal bandwidth requirements
US6014706A (en) * 1997-01-30 2000-01-11 Microsoft Corporation Methods and apparatus for implementing control functions in a streamed video display system
US5920692A (en) 1997-03-24 1999-07-06 International Business Machines Corp. Method and system for a remote notification service for a multi-user server architecture
JPH10285510A (ja) 1997-04-04 1998-10-23 Sony Corp 映像送信方法
GB9708061D0 (en) 1997-04-22 1997-06-11 Two Way Tv Ltd Interactive, predictive game control system
US5995518A (en) 1997-05-01 1999-11-30 Hughes Electronics Corporation System and method for communication of information using channels of different latency
IL121178A (en) 1997-06-27 2003-11-23 Nds Ltd Interactive game system
JPH1133230A (ja) * 1997-07-16 1999-02-09 Sega Enterp Ltd 通信ゲームシステム
US6606746B1 (en) * 1997-10-16 2003-08-12 Opentv, Inc. Interactive television system and method for displaying a graphical user interface using insert pictures
JPH11161571A (ja) 1997-11-27 1999-06-18 Fujitsu Ltd 適応的伝送制御システム
US6769990B2 (en) 1998-02-06 2004-08-03 Robert Cohen Networked search and tracking games
JP3551407B2 (ja) 1998-02-16 2004-08-04 富士通株式会社 波長多重光伝送システム
US6421706B1 (en) 1998-02-25 2002-07-16 Worldcom, Inc. Multicast and unicast internet protocol content distribution having a feedback mechanism for real-time and store and forward information transfer
US6421675B1 (en) * 1998-03-16 2002-07-16 S. L. I. Systems, Inc. Search engine
US5884101A (en) * 1998-04-17 1999-03-16 I-Cube, Inc. Apparatus for detecting data buffer faults
US6530082B1 (en) 1998-04-30 2003-03-04 Wink Communications, Inc. Configurable monitoring of program viewership and usage of interactive applications
US6198850B1 (en) 1998-06-12 2001-03-06 Xerox Corporation System and method for segmentation dependent lossy and lossless compression for higher quality
US6536041B1 (en) 1998-06-16 2003-03-18 United Video Properties, Inc. Program guide system with real-time data sources
CN1867068A (zh) 1998-07-14 2006-11-22 联合视频制品公司 交互式电视节目导视系统及其方法
AR020608A1 (es) 1998-07-17 2002-05-22 United Video Properties Inc Un metodo y una disposicion para suministrar a un usuario acceso remoto a una guia de programacion interactiva por un enlace de acceso remoto
BR9912281A (pt) * 1998-07-20 2001-04-17 Canal Plus Sa Sistema de navegação para um sistema de televisão digital multicanal
UA57158C2 (uk) * 1998-07-22 2003-06-16 Імперіал Тобакко Лімітед Пачка для тютюнових виробів
AR019458A1 (es) 1998-07-23 2002-02-20 United Video Properties Inc Una disposicion de guia de programacion televisiva interactiva que sirve como entrada
JP2000057009A (ja) 1998-08-07 2000-02-25 Hudson Soft Co Ltd コンピュータゲームソフトウェアのデバッグシステム
US6697869B1 (en) * 1998-08-24 2004-02-24 Koninklijke Philips Electronics N.V. Emulation of streaming over the internet in a broadcast application
TW447221B (en) 1998-08-26 2001-07-21 United Video Properties Inc Television message system
TW463503B (en) 1998-08-26 2001-11-11 United Video Properties Inc Television chat system
ATE282920T1 (de) 1998-09-11 2004-12-15 Two Way Media Ltd Ablieferung von interaktiven anwendungen
GB2347332B (en) 1998-10-28 2003-07-09 Canon Kk Computer games apparatus
US6409602B1 (en) * 1998-11-06 2002-06-25 New Millenium Gaming Limited Slim terminal gaming system
US6853385B1 (en) 1999-11-09 2005-02-08 Broadcom Corporation Video, audio and graphics decode, composite and display system
US6241612B1 (en) * 1998-11-09 2001-06-05 Cirrus Logic, Inc. Voice communication during a multi-player game
EP1001631A1 (en) * 1998-11-09 2000-05-17 CANAL+ Société Anonyme Signalling of bouquet information in a digital transmission system
US6408128B1 (en) * 1998-11-12 2002-06-18 Max Abecassis Replaying with supplementary information a segment of a video
US6707487B1 (en) * 1998-11-20 2004-03-16 In The Play, Inc. Method for representing real-time motion
US6804825B1 (en) * 1998-11-30 2004-10-12 Microsoft Corporation Video on demand methods and systems
US6754241B1 (en) * 1999-01-06 2004-06-22 Sarnoff Corporation Computer system for statistical multiplexing of bitstreams
US6665872B1 (en) 1999-01-06 2003-12-16 Sarnoff Corporation Latency-based statistical multiplexing
US7469381B2 (en) 2007-01-07 2008-12-23 Apple Inc. List scrolling and document translation, scaling, and rotation on a touch-screen display
US6564380B1 (en) 1999-01-26 2003-05-13 Pixelworld Networks, Inc. System and method for sending live video on the internet
WO2000059220A1 (en) * 1999-03-30 2000-10-05 Diva Systems Corporation User access to secondary content associated with a primary content
US6470378B1 (en) 1999-03-31 2002-10-22 Intel Corporation Dynamic content customization in a clientserver environment
US7178106B2 (en) * 1999-04-21 2007-02-13 Sonic Solutions, A California Corporation Presentation of media content from multiple media sources
US6792615B1 (en) * 1999-05-19 2004-09-14 New Horizons Telecasting, Inc. Encapsulated, streaming media automation and distribution system
US8595764B2 (en) 1999-06-25 2013-11-26 Jlb Ventures, Llc Image-oriented electronic programming guide
CA2378304C (en) 1999-06-28 2014-04-08 United Video Properties, Inc. Interactive television system with newsgroups
CA2377941A1 (en) 1999-06-28 2001-01-04 United Video Properties, Inc. Interactive television program guide system and method with niche hubs
US6556624B1 (en) 1999-07-27 2003-04-29 At&T Corp. Method and apparatus for accomplishing multiple description coding for video
US6658618B1 (en) 1999-09-02 2003-12-02 Polycom, Inc. Error recovery method for video compression coding using multiple reference buffers and a message channel
US6523126B1 (en) 1999-10-18 2003-02-18 Intel Corporation Watchdog timer that is disabled upon receiving sleep status signal from monitored device wherein monitored device is not responsive to time-out of watchdog timer
MXPA02004015A (es) 1999-10-22 2003-09-25 Activesky Inc Un sistema de video orientado a los objetos.
US7987431B2 (en) 1999-10-29 2011-07-26 Surfcast, Inc. System and method for simultaneous display of multiple information sources
US6810528B1 (en) 1999-12-03 2004-10-26 Sony Computer Entertainment America Inc. System and method for providing an on-line gaming experience through a CATV broadband network
AU2059801A (en) * 1999-12-03 2001-06-12 Ourworld Live, Inc. Consumer access systems and methods for providing same
US20020019984A1 (en) * 2000-01-14 2002-02-14 Rakib Selim Shlomo Headend cherrypicker with digital video recording capability
AU2001232838A1 (en) 2000-01-14 2001-07-24 Portable Websites.Com, Inc. Method and apparatus for creating relocatable internet web sites
US20020059637A1 (en) * 2000-01-14 2002-05-16 Rakib Selim Shlomo Home gateway for video and data distribution from various types of headend facilities and including digital video recording functions
US8584182B2 (en) 2000-01-27 2013-11-12 Time Warner Cable Enterprises Llc System and method for providing broadcast programming, a virtual VCR, and a video scrapbook to programming subscribers
JP2004514189A (ja) 2000-02-17 2004-05-13 アクレイム　エンターテインメント　インコーポレイテッド マルチプレーヤーのコンピュータゲーム、システム及び方法
US6714200B1 (en) 2000-03-06 2004-03-30 Microsoft Corporation Method and system for efficiently streaming 3D animation across a wide area network
US20020040475A1 (en) * 2000-03-23 2002-04-04 Adrian Yap DVR system
KR100372899B1 (ko) * 2000-04-04 2003-02-25 주식회사 게임위즈 인터넷을 통한 게임방송방법 및 그 장치
US6731814B2 (en) 2000-05-01 2004-05-04 Xerox Corporation Method for compressing digital documents with control of image quality and compression rate
US20020119821A1 (en) * 2000-05-12 2002-08-29 Sanjoy Sen System and method for joining a broadband multi-user communication session
US6616533B1 (en) 2000-05-31 2003-09-09 Intel Corporation Providing advertising with video games
US20060130104A1 (en) 2000-06-28 2006-06-15 Madhukar Budagavi Network video method
US20020002074A1 (en) 2000-06-30 2002-01-03 Cyop Systems Method for an online player game payment system
US6788333B1 (en) 2000-07-07 2004-09-07 Microsoft Corporation Panoramic video
AU2001267581A1 (en) * 2000-07-15 2002-01-30 Filippo Costanzo Audio-video data switching and viewing system
DE60136377D1 (de) 2000-08-14 2008-12-11 Media Partners Dba Americast Anzeigen von werbung in einer interaktiven programmzeitschrift
CA2423988A1 (en) * 2000-08-25 2002-02-28 Intellocity Usa, Inc. Method of enhancing streaming media content
US8932136B2 (en) * 2000-08-25 2015-01-13 Opentv, Inc. Method and system for initiating an interactive game
US20020069405A1 (en) * 2000-09-20 2002-06-06 Chapin Paul W. System and method for spokesperson interactive television advertisements
CN100397899C (zh) * 2000-10-11 2008-06-25 联合视频制品公司 提供数据存储到点播媒体传递系统中服务器上的系统和方法
AU2002211598A1 (en) * 2000-10-16 2002-04-29 Cardionow, Inc. Medical image capture system and method
US7244181B2 (en) * 2000-11-14 2007-07-17 Netamin Communication Corp. Multi-player game employing dynamic re-sequencing
US20030177187A1 (en) * 2000-11-27 2003-09-18 Butterfly.Net. Inc. Computing grid for massively multi-player online games and other multi-user immersive persistent-state and session-based applications
US20020080267A1 (en) 2000-11-28 2002-06-27 Allan Moluf High capacity, low-latency multiplexer
US6996742B2 (en) * 2000-11-28 2006-02-07 Sedna Patent Services, Llc Method for regenerating and streaming content from a video server using RAID 5 data striping
US20020075382A1 (en) * 2000-12-01 2002-06-20 Yoram Cohen Method and apparatus for implementing a thin-client videophone in a cable television network
CA2432128A1 (en) * 2000-12-13 2002-06-20 The Chinese University Of Hong Kong Method and system for delivering media selections through a network
US7254622B2 (en) 2000-12-15 2007-08-07 Tetsuya Nomura Video-on-demand system
US20020087560A1 (en) * 2000-12-29 2002-07-04 Greg Bardwell On-line class and curriculum management
JP3726684B2 (ja) * 2001-01-11 2005-12-14 株式会社Ｋｄｄｉ研究所 動画像データ転送における輻輳を回避する通信システム
US7587520B1 (en) 2001-01-24 2009-09-08 3Dlabs Inc. Ltd. Image display system with visual server
US6973667B2 (en) 2001-03-01 2005-12-06 Minerva Networks, Inc. Method and system for providing time-shifted delivery of live media programs
US6751241B2 (en) * 2001-09-27 2004-06-15 Corning Incorporated Multimode fiber laser gratings
US20020142842A1 (en) 2001-03-29 2002-10-03 Easley Gregory W. Console-based system and method for providing multi-player interactive game functionality for use with interactive games
US20020154691A1 (en) 2001-04-19 2002-10-24 Kost James F. System and process for compression, multiplexing, and real-time low-latency playback of networked audio/video bit streams
GB2374756B (en) 2001-04-20 2004-07-28 Discreet Logic Inc Image processing
WO2002092177A2 (en) 2001-04-26 2002-11-21 Oy Gamecluster Ltd Method and arrangement for providing an interactive game including three-dimensional graphics
US7305691B2 (en) 2001-05-07 2007-12-04 Actv, Inc. System and method for providing targeted programming outside of the home
US20020170065A1 (en) 2001-05-08 2002-11-14 Pinnick Skyler D. Apparatus and method of managing compression of video and delivery of video over the internet
AU2002312747A1 (en) 2001-05-15 2002-11-25 Netadtack Aps Method and system for transmitting multicast data signals
US20020184303A1 (en) 2001-05-31 2002-12-05 Virtaul Media, Inc. Embedded web server capable of managing dynamic content delivery of data stream, audio stream, or video stream
KR20020092022A (ko) 2001-06-01 2002-12-11 애드버츄얼 주식회사 가상이미지 삽입기술을 이용한 실시간 쌍방향 스트리밍비디오 시스템
US20050005308A1 (en) * 2002-01-29 2005-01-06 Gotuit Video, Inc. Methods and apparatus for recording and replaying sports broadcasts
US20030017846A1 (en) * 2001-06-12 2003-01-23 Estevez Leonardo W. Wireless display
US7444662B2 (en) 2001-06-28 2008-10-28 Emc Corporation Video file server cache management using movie ratings for reservation of memory and bandwidth resources
US7367885B2 (en) * 2001-08-09 2008-05-06 Igt 3-D text in a gaming machine
JP2003060638A (ja) * 2001-08-15 2003-02-28 Sony Corp コンテンツ提供装置及びコンテンツ提供方法
US7636931B2 (en) 2001-08-17 2009-12-22 Igt Interactive television devices and systems
US6999083B2 (en) * 2001-08-22 2006-02-14 Microsoft Corporation System and method to provide a spectator experience for networked gaming
US6820218B1 (en) 2001-09-04 2004-11-16 Microsoft Corporation Persistent stateful component-based applications via automatic recovery
US20030048808A1 (en) * 2001-09-12 2003-03-13 Stahl Thomas Anthony Method and apparatus for changing received streaming content channels
CA2669171C (en) * 2001-09-26 2012-05-01 Interact Devices System and method for communicating media signals
US7931533B2 (en) * 2001-09-28 2011-04-26 Igt Game development architecture that decouples the game logic from the graphics logics
US7046269B2 (en) * 2001-10-16 2006-05-16 Sprint Communications Company L.P. Sharing of prerecorded motion video over an internetwork
US7031473B2 (en) 2001-11-13 2006-04-18 Microsoft Corporation Network architecture for secure communications between two console-based gaming systems
JP2007244887A (ja) 2001-12-03 2007-09-27 Ziosoft Inc ボリュームレンダリング処理方法、ボリュームレンダリング処理システム、計算機及びプログラム
US7299487B1 (en) 2001-12-04 2007-11-20 Unisys Corporation Control program, for a co-processor in a video-on-demand system, which uses transmission control lists to send video data packets with respective subgroups of internet protocol headers
GB0219509D0 (en) 2001-12-05 2002-10-02 Delamont Dean Improvements to interactive TV games system
US6917945B2 (en) * 2002-02-04 2005-07-12 Microsoft Corporation Encoding and decoding methods and systems
JP4409956B2 (ja) 2002-03-01 2010-02-03 ティーファイヴ ラブズ リミテッド 集中型対話グラフィカルアプリケーションサーバ
US6908390B2 (en) * 2002-03-29 2005-06-21 Igt Apparatus and method for a gaming tournament network
US6868439B2 (en) 2002-04-04 2005-03-15 Hewlett-Packard Development Company, L.P. System and method for supervising use of shared storage by multiple caching servers physically connected through a switching router to said shared storage via a robust high speed connection
AU2003219640B2 (en) 2002-04-19 2007-06-28 Radixs Pte Ltd System and method for use of multiple applications
US7543326B2 (en) * 2002-06-10 2009-06-02 Microsoft Corporation Dynamic rate control
US20040031061A1 (en) * 2002-07-31 2004-02-12 Bluestreak Technology Inc. System and method for providing real-time ticker information
US6834023B2 (en) * 2002-08-01 2004-12-21 Micron Technology, Inc. Method and apparatus for saving current in a memory device
ATE375187T1 (de) 2002-08-12 2007-10-15 Alcatel Lucent Verfahren und vorrichtungen zur implementerung von hochinteraktiven unterhaltungsdiensten unter verwendung der medienströmungstechnologie, das die bereitstellung auf abstand von virtuelle realitätdiensten ermöglicht
US20050273830A1 (en) 2002-10-30 2005-12-08 Nds Limited Interactive broadcast system
US7878908B2 (en) * 2002-11-14 2011-02-01 Nintendo Co., Ltd. Multiplexed secure video game play distribution
TW553512U (en) * 2002-11-15 2003-09-11 Molex Inc Electronic card connector
US9027063B2 (en) 2002-11-27 2015-05-05 Deluxe Digital Distribution Inc. Video-on-demand (VOD) management system and methods
US20030158700A1 (en) * 2002-11-27 2003-08-21 Forler Joseph Wayne Watchdog arrangement
US7219153B1 (en) * 2002-12-02 2007-05-15 Cisco Technology, Inc. Methods and apparatus for distributing content
US7559834B1 (en) 2002-12-02 2009-07-14 Microsoft Corporation Dynamic join/exit of players during play of console-based video game
US7089319B2 (en) 2002-12-09 2006-08-08 Anton Lysenko Method and system for instantaneous on-demand delivery of multimedia content over a communication network with aid of content capturing component, delivery-on-demand client and dynamically mapped resource locator server
US7165194B2 (en) * 2002-12-09 2007-01-16 International Business Machines Corporation Technical support for software products
US20110126255A1 (en) 2002-12-10 2011-05-26 Onlive, Inc. System and method for remote-hosted video effects
US8526490B2 (en) 2002-12-10 2013-09-03 Ol2, Inc. System and method for video compression using feedback including data related to the successful receipt of video content
US7849491B2 (en) * 2002-12-10 2010-12-07 Onlive, Inc. Apparatus and method for wireless video gaming
US8495678B2 (en) * 2002-12-10 2013-07-23 Ol2, Inc. System for reporting recorded video preceding system failures
US8468575B2 (en) 2002-12-10 2013-06-18 Ol2, Inc. System for recursive recombination of streaming interactive video
US8661496B2 (en) 2002-12-10 2014-02-25 Ol2, Inc. System for combining a plurality of views of real-time streaming interactive video
US7493078B2 (en) * 2002-12-10 2009-02-17 Onlive, Inc. Antenna assembly for satellite and wireless services
US7684752B2 (en) * 2002-12-10 2010-03-23 Onlive, Inc. Wireless network providing distributed video / data services
US7558525B2 (en) * 2002-12-10 2009-07-07 Onlive, Inc. Mass storage repository for a wireless network
US7116833B2 (en) 2002-12-23 2006-10-03 Eastman Kodak Company Method of transmitting selected regions of interest of digital video data at selected resolutions
JP4140384B2 (ja) 2003-01-07 2008-08-27 ソニー株式会社 端末装置および方法、記録媒体、並びにプログラム
JP2004227514A (ja) 2003-01-27 2004-08-12 Ricoh Co Ltd メモリユニット、プレゼンテーションデータ作成装置、プレゼンテーションデータ作成システム、プレゼンテーションデータ作成方法およびプレゼンテーション方法
WO2004073269A1 (ja) * 2003-02-13 2004-08-26 Fujitsu Limited 伝送システム，配信経路制御装置，負荷情報収集装置および配信経路制御方法
US7590084B2 (en) * 2003-02-14 2009-09-15 Onlive, Inc. Self-configuring, adaptive, three-dimensional, wireless network
US7593361B2 (en) * 2003-02-14 2009-09-22 Onlive, Inc. Method of operation for a three-dimensional, wireless network
US7215660B2 (en) 2003-02-14 2007-05-08 Rearden Llc Single transceiver architecture for a wireless network
US7789741B1 (en) * 2003-02-28 2010-09-07 Microsoft Corporation Squad vs. squad video game
TW589891B (en) 2003-03-07 2004-06-01 Asustek Comp Inc Real-time video conferencing method, system and storage medium in web game
TW589892B (en) * 2003-03-12 2004-06-01 Asustek Comp Inc Instant video conferencing method, system and storage medium implemented in web game using A/V synchronization technology
US7574691B2 (en) 2003-03-17 2009-08-11 Macrovision Corporation Methods and apparatus for rendering user interfaces and display information on remote client devices
EP1654864A4 (en) 2003-03-20 2009-05-27 Ge Security Inc SYSTEMS AND METHOD FOR MULTISTRIBBIT PROCESSING
CN1534503A (zh) 2003-03-27 2004-10-06 华硕电脑股份有限公司 实现网络游戏中实时影音会谈的方法、系统及储存媒体
US20040263626A1 (en) 2003-04-11 2004-12-30 Piccionelli Gregory A. On-line video production with selectable camera angles
US20040207724A1 (en) 2003-04-17 2004-10-21 Siemens Information And Communication Networks, Inc. System and method for real time playback of conferencing streams
US20040229688A1 (en) 2003-05-12 2004-11-18 Electronic Arts Inc. Methods and apparatus for playing video sequences while loading game data
US6963353B1 (en) 2003-05-14 2005-11-08 Cisco Technology, Inc. Non-causal speaker selection for conference multicast
CA2531970A1 (en) * 2003-07-10 2005-01-27 Comcast Cable Holdings, Llc Distributed and scalable architecture for on demand session and resource management
RU2265246C2 (ru) 2003-09-11 2005-11-27 Общество с ограниченной ответственностью "Мера НН" Способ и система формирования и распространения информации о продуктах по сети интернет
US7874917B2 (en) 2003-09-15 2011-01-25 Sony Computer Entertainment Inc. Methods and systems for enabling depth and direction detection when interfacing with a computer program
US7352952B2 (en) * 2003-10-16 2008-04-01 Magix Ag System and method for improved video editing
GB0324627D0 (en) 2003-10-22 2003-11-26 Waterleaf Ltd Redundant gaming system
US20050102375A1 (en) * 2003-10-23 2005-05-12 Kivin Varghese An Internet System for the Uploading, Viewing and Rating of Videos
US20060010392A1 (en) 2004-06-08 2006-01-12 Noel Vicki E Desktop sharing method and system
US20050183120A1 (en) * 2004-01-13 2005-08-18 Saurabh Jain Multi-user personalized digital multimedia distribution methods and systems
JP2005286972A (ja) 2004-03-31 2005-10-13 Sony Broadband Solution Corp 多地点会議接続システム、並びに多地点会議接続方法
US20060080702A1 (en) 2004-05-20 2006-04-13 Turner Broadcasting System, Inc. Systems and methods for delivering content over a network
US7984179B1 (en) 2004-06-29 2011-07-19 Sextant Navigation, Inc. Adaptive media transport management for continuous media stream over LAN/WAN environment
US7458894B2 (en) 2004-09-15 2008-12-02 Microsoft Corporation Online gaming spectator system
US8568225B2 (en) 2004-09-16 2013-10-29 Bally Gaming, Inc. User interface system and method for creating and verifying signed content
JP2007065928A (ja) * 2005-08-30 2007-03-15 Toshiba Corp 情報記憶媒体、情報処理方法、情報転送方法、情報再生方法、情報再生装置、情報記録方法、情報記録装置、及びプログラム
US7457878B1 (en) 2004-11-04 2008-11-25 Sun Microsystems, Inc. Low-latency ultra-thin-client infrastructure
US7483961B2 (en) 2004-11-23 2009-01-27 Microsoft Corporation Method and apparatus for controlling execution of an application
EP1839177A4 (en) 2005-01-05 2010-07-07 Divx Inc SYSTEM AND METHOD RELATING TO OFF-SITE USER INTERFACE
US7664872B2 (en) 2005-01-05 2010-02-16 Divx, Inc. Media transfer protocol
US20060168291A1 (en) * 2005-01-05 2006-07-27 Van Zoest Alexander Interactive multichannel data distribution system
US20060156330A1 (en) 2005-01-07 2006-07-13 Fu-Sheng Chiu Intelligent interactive multimedia
EP1694071A1 (en) 2005-02-11 2006-08-23 Vemotion Limited Interactive video applications
CA2598338A1 (en) 2005-03-21 2006-09-28 Newtec Cy Managing traffic in a satellite transmission system
WO2006100664A2 (en) 2005-03-21 2006-09-28 Yosef Mizrahi Method, system and computer-readable code for providing a computer gaming service
US7668914B2 (en) 2005-03-28 2010-02-23 Alcatel Lucent Milestone synchronization in broadcast multimedia streams
US20060230428A1 (en) 2005-04-11 2006-10-12 Rob Craig Multi-player video game system
WO2006124811A2 (en) 2005-05-13 2006-11-23 Professional Interactive Entertainment, Inc. System and method for network interactive game match-up and server selection
WO2006124922A2 (en) 2005-05-17 2006-11-23 Super Computer International Collaborative online gaming system and method
US20060277477A1 (en) 2005-06-02 2006-12-07 Christenson Mark G K System and method for generating enhanced depiction of electronic files such as web files
US9098597B2 (en) 2005-06-03 2015-08-04 Apple Inc. Presenting and managing clipped content
EP1891790A1 (fr) 2005-06-17 2008-02-27 France Télécom Procede de gestion de l'execution par un serveur d'une application offrant au moins un service multimedia interactif a au moins un terminal, produit programme d'ordinateur et serveur correspondants
WO2007008356A1 (en) 2005-07-08 2007-01-18 Tag Networks, Inc. Video game system using pre-encoded macro-blocks
US8284842B2 (en) 2005-07-08 2012-10-09 Activevideo Networks, Inc. Video game system using pre-encoded macro-blocks and a reference grid
US8118676B2 (en) 2005-07-08 2012-02-21 Activevideo Networks, Inc. Video game system using pre-encoded macro-blocks
US7936819B2 (en) * 2005-07-08 2011-05-03 Tag Networks, Inc. Video encoder with latency control
US20070024706A1 (en) 2005-08-01 2007-02-01 Brannon Robert H Jr Systems and methods for providing high-resolution regions-of-interest
JP2007079876A (ja) 2005-09-13 2007-03-29 Sony Corp 信号処理装置、信号処理方法及び信号処理プログラム
JP2007080357A (ja) * 2005-09-13 2007-03-29 Toshiba Corp 情報記憶媒体、情報再生方法、情報再生装置
JP2007088723A (ja) 2005-09-21 2007-04-05 Sharp Corp 携帯テレビ電話機用カメラ及びそれを備えた携帯テレビ電話機
US20070094700A1 (en) * 2005-10-25 2007-04-26 Jason Wolfe Game delivery system
US8025572B2 (en) 2005-11-21 2011-09-27 Microsoft Corporation Dynamic spectator mode
US8135040B2 (en) * 2005-11-30 2012-03-13 Microsoft Corporation Accelerated channel change
US8112513B2 (en) 2005-11-30 2012-02-07 Microsoft Corporation Multi-user display proxy server
US20070156815A1 (en) * 2005-12-30 2007-07-05 Nokia Corporation Method, system and entities for multicast content pushing
US20070173325A1 (en) * 2006-01-20 2007-07-26 Microsoft Corporation Join in-progress on-line game session
US8764566B2 (en) * 2006-02-24 2014-07-01 Igt Internet remote game server
JP2007249470A (ja) 2006-03-15 2007-09-27 Nec Biglobe Ltd クラスタサーバシステム、課金装置、課金方法
WO2007109162A2 (en) 2006-03-17 2007-09-27 Viddler, Inc. Methods and systems for displaying videos with overlays and tags
EP1837060A1 (en) * 2006-03-21 2007-09-26 In Fusio (S.A.) Method for displaying interactive video content from a video stream in a display of a user device
US8403757B2 (en) 2006-04-13 2013-03-26 Yosef Mizrachi Method and apparatus for providing gaming services and for handling video content
US8777737B2 (en) 2006-04-13 2014-07-15 Igt Method and apparatus for integrating remotely-hosted and locally rendered content on a gaming device
US8234547B2 (en) 2006-04-29 2012-07-31 Thomson Licensing Seamless handover of multicast sessions in internet protocol based wireless networks using staggercasting
US9327191B2 (en) * 2006-05-08 2016-05-03 Nintendo Co., Ltd. Method and apparatus for enhanced virtual camera control within 3D video games or other computer graphics presentations providing intelligent automatic 3D-assist for third person viewpoints
US20070265094A1 (en) 2006-05-10 2007-11-15 Norio Tone System and Method for Streaming Games and Services to Gaming Devices
JP4703480B2 (ja) 2006-05-17 2011-06-15 株式会社日立製作所 映像内の移動体検出方法、映像システムの異常発生原因分析支援方法及び支援システム
US20080263585A1 (en) * 2006-06-15 2008-10-23 Richard Gell System and method for on-line video debating
US20080005281A1 (en) 2006-06-29 2008-01-03 Microsoft Corporation Error capture and reporting in a distributed computing environment
US7788394B2 (en) * 2006-08-31 2010-08-31 General Instrument Corporation Streaming content over an internet protocol network
CA2664746C (en) 2006-09-29 2017-05-02 United Video Properties, Inc. Systems and methods for modifying an interactive media guidance application interface based on time of day
US20080092172A1 (en) 2006-09-29 2008-04-17 Guo Katherine H Method and apparatus for a zooming feature for mobile video service
US8850481B2 (en) * 2006-09-29 2014-09-30 United Video Properties, Inc. Systems and methods for modifying an interactive media guidance application interface based on time of day
US8711929B2 (en) * 2006-11-01 2014-04-29 Skyfire Labs, Inc. Network-based dynamic encoding
US8713192B2 (en) 2006-12-08 2014-04-29 Yahoo! Inc. System and method for routing streaming data requests
US20080209472A1 (en) * 2006-12-11 2008-08-28 David Eric Shanks Emphasized mosaic video channel with interactive user control
US8713439B2 (en) * 2006-12-15 2014-04-29 Yahoo! Inc. Systems and methods for providing a video playlist
JP4886500B2 (ja) 2006-12-20 2012-02-29 株式会社日立製作所 データ転送装置、及びそのシステム
US8019167B2 (en) 2007-01-03 2011-09-13 Human Monitoring Ltd. Compressing high resolution images in a low resolution video
KR101511674B1 (ko) 2007-01-06 2015-04-13 삼성전자주식회사 화상 전화 통신 시스템에서 인트라 리프레싱을 제어하는장치 및 방법
US20080228865A1 (en) 2007-03-15 2008-09-18 Nazareno Brier Cruzada Electronic personal computing and videophone system consisting of a remote server system providing dynamic, subscription based virtual computing services & resources, a thin client hardware device connected to a television set and wireless keyboard & mouse, and a wireless mobile device (a Pocket PC Phone)
JP3987880B2 (ja) 2007-03-26 2007-10-10 クラビット株式会社 サーバ・クライアント・システム、負荷分散装置、負荷分散方法および負荷分散プログラム
US8305914B2 (en) 2007-04-30 2012-11-06 Hewlett-Packard Development Company, L.P. Method for signal adjustment through latency control
US9911127B1 (en) 2007-05-02 2018-03-06 Google Llc Ratable video advertisements
US8046695B2 (en) * 2007-10-19 2011-10-25 Citrix Systems, Inc. Methods and systems for incorporating at least one window from a first desktop environment having a first themed graphical display into a second desktop environment having a second themed graphical display
US8136133B2 (en) * 2007-11-13 2012-03-13 Walker Digital, Llc Methods and systems for broadcasting modified live media
CA2707707A1 (en) 2007-12-05 2009-06-11 Onlive, Inc. Streaming interactive video client apparatus
US20090300701A1 (en) 2008-05-28 2009-12-03 Broadcom Corporation Area of interest processing of video delivered to handheld device
US9113124B2 (en) 2009-04-13 2015-08-18 Linkedin Corporation Method and system for still image capture from video footage
US8582952B2 (en) 2009-09-15 2013-11-12 Apple Inc. Method and apparatus for identifying video transitions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004512865A (ja) * 2000-08-25 2004-04-30 インテロシティー　ユーエスエイ，アイエヌシー． セットトップボックスを介した対話型ゲーム
JP2005348262A (ja) * 2004-06-04 2005-12-15 Ricoh Co Ltd データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"夢見るテクノロジー 第５回 サーバ側で画面も描画する！次世代ゲーム環境「Ｇクラスタ」", 月刊アスキー, vol. 第３０巻 第６号, JPN6013037882, 1 June 2006 (2006-06-01), JP, pages 95 - 97, ISSN: 0002664730 *

Also Published As

Publication number Publication date
US20150141145A1 (en) 2015-05-21
US9003461B2 (en) 2015-04-07
EP2227728A1 (en) 2010-09-15
RU2010127322A (ru) 2012-01-10
WO2009073799A1 (en) 2009-06-11
AU2008333801A1 (en) 2009-06-11
CA2707674A1 (en) 2009-06-11
US20090125967A1 (en) 2009-05-14
NZ585658A (en) 2013-02-22
EP2227728A4 (en) 2011-04-20
US9573059B2 (en) 2017-02-21
CN101889254A (zh) 2010-11-17
KR20100111668A (ko) 2010-10-15
RU2496135C2 (ru) 2013-10-20

Similar Documents

Publication Publication Date Title
JP6369999B2 (ja) 通信チャンネルを経て送信されるある形式のマルチメディアデータを保護するシステム及び方法
JP6442461B2 (ja) 通信チャンネルにわたるパケットロスの影響を減少するためのビデオ圧縮システム及び方法
JP6106208B2 (ja) ストリーミング双方向ビデオを圧縮するシステム及び方法
JP5677093B2 (ja) システム故障の前の記録されたビデオを報告するシステム
JP5568628B2 (ja) 複数のエンコーディングフォーマットを使用するマルチストリームビデオ圧縮のためのシステム及び方法
TWI459215B (zh) 用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法
JP2015053719A (ja) 選択されたタイル及びタイル回転パターンを使用してビデオをエンコードするためのシステム及び方法
JP2011508478A (ja) リアルタイムストリーミング双方向ビデオのビューをマルチキャスティングする方法
JP2011507340A (ja) 記録されたビデオセグメントと一体化されたストリーミング双方向ビデオ
JP2011507339A (ja) リアルタイムストリーミング双方向ビデオの複数のビューを合成するシステム
JP2011509545A (ja) ストリーミング双方向ビデオを使用して協力的に会議を行うシステム
JP2011507350A (ja) ストリーミング双方向ビデオクライアント装置
JP2011514017A (ja) ストリーミング双方向ビデオを通して使用されるリアルタイムアプリケーションに応対するデータベースをストリーミングするシステム
JP2011507344A (ja) 記録されたアプリケーション状態をアプリケーションストリーミング双方向ビデオ出力と合成するシステム
JP2011509546A (ja) ストリーミング双方向ビデオとして一緒に圧縮されるリニアコンテンツ及び双方向コンテンツを合成する方法
JP2011507077A (ja) ストリーミング双方向ビデオサーバー間でユーザセッションを移行する方法
JP2011507341A (ja) ストリーミング双方向ビデオを使用したバーチャル事象のホスティング及びブロードキャスティング
JP2011514565A (ja) クライアントの要求をサーバーセンターにインテリジェントに割り当てるシステム及び方法
JP2012521721A (ja) クライアント装置からのフィードバック情報に基づきビデオフレーム又はその一部分を圧縮するためのシステム及び方法
JP2012521719A (ja) フィードバックデータに基づいてビデオエンコーディングフォーマットを選択するためのシステム及び方法
JP2012521718A (ja) 待ち時間測定及び他のフィードバックに基づいてビデオを圧縮するためのシステム及び方法
JP2012521723A (ja) 一時的デコーダ装置及び方法
JP2012521269A (ja) 加速マシン切り換えのためのシステム及び方法
JP2012521268A (ja) マルチストリームビデオ圧縮のためのシステム及び方法
JP2012521720A (ja) ビデオコンテンツの首尾良い受信に関連したデータを含むフィードバックを使用してビデオを圧縮するシステム及び方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20111020

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130207

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130507

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130514

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130805

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20131018

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131028

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131114

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20140109

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20140602