U.S. Pat. No. 8,834,273

DETAILED DESCRIPTION OF EXAMPLE ILLUSTRATIVE EMBODIMENTS

FIG. 1shows an example overall video game distribution network. InFIG. 1, one or more video game developer(s)50develop video games52and provide them to one or more content distributor(s)54. In some examples, the content distributor(s)54may also receive and distribute other content56such as, for example, television programming, movies, audio programs and any other content imaginable. For example, content distributor(s)54may be in the business of distributing television programming, movies and other mass media via a satellite or other wide area content distribution network58to a number of remote locations. WhileFIG. 1shows video game developers50and content distributors54as separate entities, in other arrangements these two roles may be performed by the same business entity.

As shown inFIG. 1, the wide area content distribution network58transports video games52and other content54to a plurality of user distribution networks60. Wide area content distribution network58may include, for example, one or more satellites in geo-synchronous orbit that receive and retransmit streaming television and movie programming. In other examples, wide area content distribution network58may include the Internet, telephone lines, portable mass media storage devices such as optical disks, or virtually any other way to move data from one place to another.

In the example shown, user-distribution networks60provide a “store and forward” function, i.e., they receive content from the wide area content distribution network58and store that content for on-demand use by users. User distribution networks60may also provide real time streaming content to users. However, as will be understood from the discussion below, the conventional “store and forward” model is not used for video games in the preferred exemplary embodiment. Rather, in the preferred exemplary illustrative embodiment, video games are actually executed on a user-interactive basis at a “head-end” of the user distribution network and the results of the interactive video game play are then transmitted to end users. In other applications, a more conventional “store and forward” function may alternatively be performed where video game instructions are stored and then forwarded for local execution at end user locations using end user execution hardware.

In one particular illustrative example, user distribution networks60may be installed in particular locations remote from the content distributor54. For example, the user distribution networks60may be installed in hotels or resort facilities to provide content to guest rooms. User distribution networks60could be installed in cruise ships, airplanes, trains, and other transportation vehicles where passengers have access to a personal video screen and input controls. In still other arrangements, user distribution networks60may comprise cable, DSL or other distribution networks. For example, user distribution networks60might comprise a cable television head-end that distributes television and other content to monthly or other subscribers. User distribution networks60could alternatively comprise two-way interactive satellite or other content distribution networks of any type on the Internet.

As shown inFIG. 1, an exemplary illustrative user distribution network60(1) includes a content server62that receives games52and other content56transported by wide area content distribution network58. Content server62may provide streaming content to a plurality of users having user appliances66such as television sets. In one particular illustrative arrangement, user appliances66may comprise conventional home color television sets installed in hotel rooms, cruise ship suites, residences or other places. The user input devices72may in one illustrative embodiment comprise separate handheld controller devices of the type conventionally used to play video games, e.g., they may include joysticks, thumb pads, push buttons and/or other conventional controls found on handheld video game controllers. In one exemplary embodiment, there may be no connection between appliances66and handheld controllers72. In other embodiments, the user input devices72and appliances66may be integrated as a single system such as a personal computer, airline seatback controller or other such arrangement.

In the example shown, content server62provides video games52it has received via the wide area content distribution network58to an interactive multiplexed video game server68for storage into an encrypted game library70. The interactive multiplexed video game server68is able to retrieve and at least partially decrypt games from the video game library70in response to user demand, and provides streaming interactive video game play to multiple user appliances66via the interactive content distribution network64. Users in turn provide inputs via handheld controllers72to interactively control such video game play.

In one exemplary embodiment, there may be an additional user input device (e.g., an interactive remote control device, a telephone, or any other arrangement) for use by users to request video game play. In one example arrangement, the user appliance66may include a set top box linked using infrared or other wireless link to the same or further handheld remote control device72allowing data entry. In this particular arrangement, the user selects video game play by manipulating the same or different remote control device72while watching menu screens displayed on the appliance66. These remote control inputs are provided to content server62via the interactive content distribution network64in the exemplary arrangement. The content server62may then, in turn, provide control signaling to interactive multiplexed video game server68indicating that a particular user at a particular location (e.g., hotel room) has requested a particular video game. The interactive multiplexed video game server68may retrieve the selected video game from encrypted game library70on user demand, decrypt and execute the video game, and provide the resulting display information to the particular user's appliance66via interactive content distribution network64. User inputs the user provides by operating handheld controller72may be routed by the interactive content distribution network64to the interactive multiplexed video game server68for interactively controlling game play of that particular video game.

In the illustrative multi-user environment shown, interactive multiplexed video game server68can provide any number of real time video game execution sessions simultaneously (e.g., up to a predetermined maximum determined by equipment capabilities) to allow multiple remote users to play different (or the same) video games simultaneously. In one example, different remote users can ask to play different video games. The interactive multiplexed video game server68will retrieve these different video games from the encrypted game library70and execute them on demand for requesting remote users. If two remote users request the same video game, the interactive multiplexed video game server68in the illustrative embodiment can start two different execution sessions so each user can play the game simultaneously. If the remote users indicate a desire to play against one another, the exemplary interactive multiplexed video game server68can support head-to-head remote game play, i.e., multiple remote users at different remote locations (e.g., users at different hotels, users in different rooms of the same hotel, users in different cabins of a cruise ship, users at different game playing stations of an arcade or coffee house, etc.) can control the same game and play against one other or otherwise participate in the same video game play experience.

FIG. 2shows an exemplary illustrative technique for securely distributing video games52within theFIG. 1network topography. This exemplary secure distribution provides end-to-end encryption of video games52to minimize piracy and unauthorized copying and distribution. In the example shown, video games52are encrypted before transmission using first and second levels of encryption Σ1, Σ2(90,92). The first level of encryption Σ1(90) may be any convenient efficient encryption for use in encrypting large amounts of data such as, for example, the Data Encryption Standard (DES) or any other conventional encryption technique. This second level of encryption Σ2(92) may be any conventional encryption such as, for example, double-DES. The content distributor54may provide even further encryption layers and other secure protocols for transmission over wide area content distribution network58.

At the user distribution network60side, the user distribution network60partially decrypts the encrypted data stream provided over wide area content distribution network58by reversing the Σ2second-level encryption (92) with a second-level decryption D2(94). The resulting decrypted data stream is still encrypted by the first-level encryption Σ1so it is not in clear text. This still-encrypted data stream52′ is stored in encrypted form into encrypted game library70. In the exemplary embodiment, this first-level encryption Σ1is removed only dynamically, i.e., interactive multiplexed video game server68applies a first-level decryption D1(96) during video game execution without ever storing the entire video game in decrypted form. Since the video game remains encrypted while stored on the illustrative encrypted game library70and is not, in the illustrative example, stored in its entirety in clear text form, access to the encrypted game library will not assist a pirate. Someone desiring to break the security and make an unauthorized copy of a video game would need to have access to the internal operation of the interactive multiplexed video game server68and, in particular, to the particular decryption keys and other information that the decryption D2process96uses to decrypt encrypted video games stored with library70. The decryption elements within interactive multiplexed video game server60may be stored in tamper resistant hardware provided with tamper-resistant protection such as for example erasure of keys when tampering occurs.

The second level of encryption is removed before the video game is stored in the encrypted video game library70in the exemplary embodiment in order to save processing resources during execution by interactive multiplexed video game server68.

FIG. 3is a block diagram of an exemplary illustrative user distribution network60. In the exemplary embodiment shown, the interactive multiplexed video server68includes interface logic102, a plurality of buffers104and a plurality of game engines106. Interface logic102provides interfacing between the interactive multiplexed video game server68and content server62, library70and interactive content distribution network64. In one exemplary embodiment, for example, the interface logic102communicates with the content server62via a conventional USB, SCSI or other high speed input/output bus108; it communicates with the library70(which may be conventional high capacity magnetic disk storage device) via a convention EIDE bus110; and it communicates with input devices72attached to the interactive content distribution network64via a conventional serial interface bus112such as RS485 or other conventional standard. In addition, the interface logic102communicates with the various buffers104and game engines106via a secure data bus114in the preferred exemplary embodiment.

In the exemplary embodiment shown inFIG. 3, each game engine106can execute an independent video game session. In the preferred embodiment, game engines106may comprise modified conventional home video game players such as Nintendo GameCube Systems sold by Nintendo. Of course, in other embodiments, game engines106could comprise any other video game playing platforms (e.g., Sony PS2, Microsoft XBOX, PCS, high speed computers emulating video game platforms, etc.). Nintendo GameCube Systems (and other home video game platforms) typically execute video games from proprietary optical disks. In the preferred exemplary embodiment shown, buffers104are provided in place of optical disk drives typically found within the video game system. The game engine106audio and video outputs190a,190vare applied to the user distribution network64via appropriate frequency converters if necessary so they can be distributed to the appropriate user or users and displayed and otherwise reproduced on user appliances66.

In the exemplary arrangement shown, each hard drive70and interface logic102supports multiple game engines106and associated buffers104. For example, in one particular arrangement, each hard drive70and interface logic102can support three to five game engines106and associated buffers104. The interface logic102multiplexes access to hard drive70among plural (e.g., 3-5) game engines106and associated buffers104. The exact number of game engines106that can be multiplexed from a single hard drive70depends upon the hard drive access speed among other factors. Costs are minimized by sharing a hard drive70among multiple game engines106in the example embodiment. Any number of such servers68shown inFIG. 3can be provided at a particular installation site to provide multiple hard drives70each supporting plural game engines106and associated buffers104via interface logic102. In the preferred exemplary embodiment, it is possible to download new games into the disk70while game players access that same disc to play games without interruption.

In the illustrative embodiment, hard drive70stores a video game library comprising a number of different video games. The hard drive70may be formatted into blocks (e.g., 1.5 GB each in one particular implementation). Each block may store a different game. The games are encrypted in the preferred exemplary embodiment such that addressability is preserved—i.e., when the game engine106requests code beginning at a particular optical disk address, it is possible to map that optical disk address to a particular code stored on hard drive70. The addressing is accomplished in the illustrative embodiment by offsetting the hard drive accesses based on block number corresponding to the particular game being played.

In one such exemplary arrangement, components are modularized by including interface logic102in the form of a printed circuit board within the same package as a conventional plug-in magnetic hard drive70. The game engines106may similarly be modified to each include a buffer104in the form of an additional printed circuit board installed within the video game hardware in place of an optical disk drive. Bus114may be a set of cables or wiring on a back plane with fast-release connectors that interconnect plug-in hard drive/interface logic modules with associated integrated game engine106/buffer104modules. This arrangement permits fast swap-in and swap-out of modules by untrained personnel. Since the data on hard drives70is encrypted and the hard drives may also be password-protected using conventional disk password protection, theft of such modules does not present a security problem. Dynamic changing of the disk passwords can be used to provide additional security. Attempts to unlock the disk70using the master password may result in erasure of all information stored on the disk.

In the exemplary arrangement shown inFIG. 3, each game engine106is time-shared among all users within the user distribution network60. More specifically, the user distribution network60may include any number of users only some of whom wish to play video games at any particular time. When a particular user notifies content server62that he or she wishes to play a video game (seeFIG. 4flowchart, block150), the content server retrieves the user identification from the request (FIG. 4, block152) and then determines whether there is any game engine106not currently in use (FIG. 4, block154). If a game engine106is available, the content server62temporarily assigns that available game engine to that particular user (FIG. 4, block156) and sets up a routing that will route inputs from that user's input device72to that particular game engine106via interface logic102(FIG. 4, block158). Depending upon the particular business arrangement involved, the content server62may also log billing information to permit the user to be billed on a per-use, minute, hourly or other basis (block160). TheFIG. 4flowchart may, if desired, include additional capabilities to establish head-to-head video game play so that multiple remote users can play the same video game against one another.

FIG. 5shows an example controller serial data packet format that input devices72may use to provide control inputs to game engines106. As shown inFIG. 5, each depression of a control on input device72may generate a data packet170of a form including a header172, a room number or other user identifier174, and a controller data payload section176including encoded data indicating the status of each one of the controls of the input device. The room number or other user identifier174is, as discussed above, used by server62for billing and other purposes and is also used by interface logic102for routing incoming serial data packets to an appropriate assigned buffer104and associated game engine106so that the correct user's (users') inputs are routed to the correct game engine106. As discussed above, serial data packets originating from multiple users may be routed to the same game engine106in the case of multi-player gaming. Such multiple users can be in the same or different locations. Server62in one embodiment may provide a matchmaking service for different users interested in finding gaming partners to play against.

FIG. 6shows an example data routing diagram for routing data within the exemplary illustrative interactive multiplexed video game server68. More specifically,FIG. 6shows interface logic102as including two main components: a processor202, and a field programmable gate array204. The processor202may include an internal or external serial interface (e.g., RS485 or other conventional serial interface) for communicating with user input devices72, at remote user locations. In one exemplary illustrative embodiment, the data from the remote user input devices72flows in only one direction, i.e., data packets of the type shown inFIG. 5flow from the user handheld controllers72to serial interface203for interpretation and processing by processor202. In other embodiments, there could be bi-directional data flow (e.g., to provide messaging to remote users, activate handheld controller features such as rumble type vibration generators, lights, etc.). Data packets from input user devices72may flow first through content server62or they may flow through other associated electronics instead that are part of the user distribution network64.

As also shown inFIG. 6, interface logic102may include a further serial interface205which may be internal or external to processor202. This further serial interface205in the preferred exemplary embodiment uses the USB protocol but other conventional protocols (e.g., SCSI, etc.) could be used instead. This interface205is used by processor202to communicate bi-directionally with content server62. The interface205, for example, receives encrypted games downloaded to content server62via the wide area content distribution network58for routing through processor202and logic204. This downloaded data is sent to a disk interface206for storage onto hard drive(s)70. In the preferred exemplary embodiment, this same serial interface205is used to exchange command information and responses between the interactive multiplexed video game server68and the content server62. Such command information and responses may include, for example, a command to allocate a particular game engine106to a particular user or users, status indicator, a command to shut down a game engine, etc.

In the preferred exemplary embodiment, both processor202and logic204are coupled to a buffer interface112. The buffer interface112in turn communicates over bus114with buffers104. Logic204reads data stored on hard disk206in a multiplexed fashion and supplies it to the buffer interface208for applying to buffers104and game engines106. This logic204in cooperation with processor202prioritizes scheduling and routing of hard disk70data to appropriate buffers104and game engines106. In the exemplary embodiment, the hard disk70, disk controller206, logic204and buffer interface208along with buffer104simulates an optical disk drive from the standpoint of game engine106. Because the access time of hard disk70in the exemplary embodiment is many times faster than typical optical disk drive access times, logic204is able to effectively multiplex or share the hard disk70among multiple game engines106.

Each game engine106generates signals that would be normally used to access an optical disk, and the buffer104and buffer interface208in conjunction with logic204converts these access requests into access signals that can be used to access hard disk70via disk controller206. In the exemplary embodiment, data from hard disk70need not flow through processor202but can be provided directly to buffer interface208via logic204in order to speed access times and avoid bottlenecks. However, processor202is also able to interact with game engines106via buffer interface208and buffers104in order to, for example, provide commands such as reset, execute, halt and the like as well as for reading game play status. Additionally, the processor202provides appropriate user controller inputs to the buffer interface208to allow the user to interact with an assigned game engine106during active game play.

FIG. 7shows one exemplary illustrative implementation of theFIG. 6interface logic102. In this exemplary implementation, microprocessor202executes a program stored in a flash memory210. Processor202in the exemplary arrangement includes an internal integral USB interface205and internal integral RS485 serial interface203. Processor202in the illustrative embodiment continually polls the buffers104to determine whether any of the buffers are requesting data and if so which kind (i.e., streaming audio data or video game instructions). When a request is received, processor202formulates a request for data from hard drive70, performing appropriate data address offset calculations to determine where the data is stored on the hard disk. The processor202then programs a direct memory access controller within interface logic102to actually perform the requested data transfer.

In the example shown, buffer interface208is actually part of the field programmable gate array logic204and communicates with buffers104(1),104(N) via a serial “Joy Bus”212of the type used in conventional Nintendo GameCube System and other products for communication between handheld controllers and video game platforms. Processor202interprets controller data received from user input devices72and creates appropriate corresponding joybus data compatible with game engines106for the buffer interface to transmit to buffers104over bus116. In addition, bus114is used to communicate executable instructions and audio and video digital data to the buffers104for consumption by game engines106.

An example illustrative power-on sequence performed by processor202is as follows:configure field-programmable gate array logic204based on contents of flash memory210;initialize disk interface206and verify self-test results;initialize disk drive70via interface206, including setting security mode and password (which may be changed randomly at each power-on);interrogate buffers104via serial (SPI) bus212to determine how many game engines106are active and connected;send configuration data to buffers104via serial (SPI) bus212;loop and wait for game start or update game data command.

Upon receiving a “game start” command from server62(which game start command may include a game engine106identifier and a disk-offset value corresponding to the requested game on hard drive70), processor202may send a “game start” command and offset to the appropriate buffer104via bus116. Cost or charge logging may also occur on server62or otherwise to allow users to be charged on a per-play basis.

FIG. 8shows an example implementation of field programmable logic204shown inFIG. 7. In this example, field programmable game array logic204includes a DMA channel250, an error checking component252, a disk interface control block254and a buffer interface208. In this particular example, high speed data such as game downloads received from processor202via the serial interface108are routed to a USB Direct Memory Access channel250for data transfer handling. The Direct Memory Access (DMA) channel250receives this data and directs it appropriately using conventional direct memory access techniques. An error checking block252(e.g., CRC) uses conventional error checking techniques to detect and correct transmission errors.

In the exemplary embodiment, downloaded game data is routed by a disk control block254to disk70. In one exemplary embodiment, during this routing process a DES or other decryption block256within disk control block154strips off two layers out of the 3-layer DES encryption, leaving the data 1DES encrypted for storage onto disk70. Such decryption may be based on a predetermined decryption key stored in a tamper-resistant fashion. The data stored on the disk70in the exemplary embodiment is still encrypted by a further encryption layer (e.g., DES or other encryption) so it is stored securely on the hard disk

During reads from disk70at the request of game engines106and associated buffers104, read requests provided by the buffers over bus114are received by the buffer interface208and provided to disk control block254. In this exemplary arrangement, the disk control block254decryption element256may dynamically decrypt the data during disk reads to remove the last layer of encryption so that clear, executable game instructions and other information can be provided via buffer interface208to the appropriate buffer104and associated game engine106. In another exemplary arrangement, bus114may also carry encrypted information, and the decryption function can be performed instead by buffers104. This latter arrangement provides additional security against attacks based on probing bus114.

FIG. 9shows an exemplary implementation for a buffer104. In this exemplary arrangement, the illustrative buffer104includes a field programmable gate array302and a microprocessor304. The microprocessor304receives and processes the user handheld controller inputs received over a two-bit serial bus212as described above, and also programs and resets the field programmable gate array302upon power-up. Microprocessor304can also send status and buffer104identification information to interface102. The field programmable gate array302manages data buffers and also interacts with game engine106.

In more detail, the programmable gate array302temporarily stores game data within a data buffer306(e.g., a 512K SRAM or other appropriately sized read/write memory device) and may also temporarily store audio data in a streaming audio data buffer308(e.g., an 8 megabyte or other appropriately sized DRAM or other read/write memory storage device). These game data and streaming audio data buffers306,308are used in the preferred exemplary embodiment to temporarily buffer data that has been requested by game engine106for delivery to the game engine. The buffering function ensures that the game engine106will always have the data it requires at the time it requires it even though there may be latency on bus114, i.e., the data arrives soon enough. Buffer306may buffer only as much data and instructions that the game engine106has requested in its last command or other request (e.g., to avoid speed performance disparities vis-à-vis consumer hardware playing the same game). The larger audio data buffer308is used to buffer a relatively high bandwidth of streaming audio data for consumption by game engine106. Audio streaming is treated in the exemplary embodiment as a background priority task, with the audio data buffer308maintaining for example 3 seconds of audio data based on a game engine106audio data rate of 192 Kbytes/second (different applications may have different requirements). In the exemplary embodiment, audio buffering may be interrupt-driven and may take precedence over data/instruction buffering since audio interruption is typically very noticeable to end users.

In the exemplary embodiment, bus114that interface logic102uses to communicate with buffers104may include a 16-bit data path114d, an 8-bit command path114C and a 3-bit select path114S. The select path114S may be used to address different buffers104. The buffer FPGA may include a DIP or other switch310to “hard-wire” an address matching addresses provided over the buffer select bus114S (alternative addressing techniques are also possible). This 3-bit address in the exemplary embodiment is used to “bind” a particular buffer104to interface logic102with respect to a particular user room number or other identifier so as to temporarily assign the buffer104to a particular user for a particular game playing session. Once that user finishes playing video games, the server68releases the buffer104and associated game engine106for use by another user. In one example embodiment, “game save” data generated during game play can be stored on server62at the conclusion of game play so the user can retrieve and use it later during subsequent game play (which, in general, will occur on a different game engine106).

Commands are exchanged between interface logic102and buffers104via the command bus114C, and data is exchanged between interface logic102and buffers104via the data bus114D. Bus114may further include interrupt request lines114I that buffers104may use to interrupt the interface microprocessor202or other components (in the exemplary embodiment, a buffer104will use a particular interrupt request line based on its hardwired address to the interface logic102can tell immediately which buffer has generated the interrupt). The buffers104can use these interrupts to signal the interface logic102in response, for example, to the need to service a request from the game engine106for an additional read from disk70. As will be understood, these bus sizes and configurations are only exemplary—different requirements may dictate different data path configurations and/or widths.

As shown inFIG. 9, the buffer FPGA302includes a microprocessor interface312, a disk (DI) interface314, a serial interface316, a host command interface318, an audio/data multiplexer320, and an audio serializer322. The disk (DI) interface314is used to interface with the game engine106optical disk interface. Briefly, the DI interface314receives game engine106access requests intended for an optical disk, and converts them into appropriate intermediate commands for providing to interface logic102via the command interface318and bus114. The DI interface314thus acts as part of an optical disk emulator by translating game engine optical disk access commands into what will eventually become hard disk drive access commands for accessing data stored on a remote hard drive70. Even though the illustrative magnetic hard drive is capable of responding to read requests many times faster than the “normal” conventional optical disk drives typically associated with video game player engines, the preferred exemplary embodiment optical disk emulation is performed by duplicating, as closely as possible, the timing that a typical video game engine optical disk drive would exhibit in response to read requests. Host command interface318may provide appropriate hard disk offset information (as well as command handling) based on information it receives from the interface102. Data received from such hard drive70accesses are provided to the audio/data multiplexer320which routes data and instructions to the DI interface314for providing to the game engine106in response to optical disk access commands. DI interface314also handles other types of optical disk interface interaction with the game engine106to make it appear to the game engine106that it is actually communicating with a real, local optical disk drive. In other embodiments, game engines106are designed for magnetic disk access and interface314manages such accesses so they can be made remotely rather than locally.

In one exemplary illustrative embodiment, game engine106is designed to receive separate audio streaming data from an optical disk via an AI path. Audio/data multiplexer320buffers incoming streaming audio digital data in parallel format within the audio data buffer308. It also decides whether required data is already within the audio buffer308or whether an interrupt request for more data needs to be generated. Serializer322is used in the exemplary embodiment to appropriately serialize parallel-format audio data for presentation to game engine106audio input (AI) as a serial audio bit stream. Serializer322and audio data buffer308thus emulates the streaming audio data portion of an exemplary optical disk in the illustrative embodiment.

The serial interface316is used to interface with the game engine106“joy bus” serial interface. Serial interface316, microprocessor interface312and microprocessor304work together to provide appropriate remote user inputs to the game engine106to allow the remote user(s) to interact with the game play being generated by the game engine.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment. For example, while the illustrative embodiments have generally been described in connection with personal video game play, the arrangements could be used in video game arcades, for in-store video game displays, and for other applications. It is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to modifications and equivalent arrangements included within the scope of the appended claims.