US20070123352A1

US20070123352A1 - Preemptive loading of console games

Info

Publication number: US20070123352A1
Application number: US11/291,857
Authority: US
Inventors: Boyd Multerer; Dax Hawkins; Megan Tedesco; Jeffrey Bernhardt
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2005-11-30
Filing date: 2005-11-30
Publication date: 2007-05-31

Abstract

Executable content for use is preemptively loaded in order to allow the content to be used when requested by a user without the significant download delay which would otherwise be required. The executable content is downloaded without the user's specific request. When the content is to be used, additional data, such as license data or a password which may be purchased, may be required to access the full functionality of the executable content. Where the executable content is a game, the preemptive loading may be to a personal computer rather than a game console, in order to take advantage of the storage space traditionally available in such a personal computer. Content is loaded based on system information, which may include, without limitation, information about the system, the user of the system, and/or community information regarding a community the user belongs to or users similar to the user, among other information.

Description

BACKGROUND

Currently, the only way to legally acquire a game for a video game console is to purchase the game on physical media, such as a disc. Such a purchase must be made at a brick and mortar or on-line retail store. This requires the user to make a trip to the store or wait for shipping, to take care not to lose or damage their physical media, and to load the media into the drive of the game console each time they want to play the game. The consumer is limited to purchasing games that the store has available and the store is limited in the number of games it can carry. Additionally, there is cost associated with the production, logistics, and stocking of media, which increase the price of the game. The music, movie, and PC games markets have begun solving these problems by offering content in a downloadable format.
In the standard client/server configuration, the download times can be very long. The current estimated time to download a full console game using existing PC download methods would be between 2 and 12 hours. Thus, if an executable could be downloaded for a video console, a user requesting such a download would have to wait for the game to be downloaded. This delay greatly reduces the convenience of downloading for the customer.

SUMMARY

In order to provide executable content to a user, according to some embodiments of the present invention, a server establishes a connection to a system. The server then sends executable data to the system for storage on the system. The executable data has not been requested by the user of the system. The executable data is selected based on system information about the system.
In some embodiments, the system is a game console system, and the executable data is game data. In other embodiments, the system is a personal computer which is associated with a game console. For example, the game console can be permanently or occasionally connected to the personal computer. In such embodiments, the executable data is sent to the personal computer. At a later point in time, the game console is connected to the personal computer and can access or download the executable data.
The executable data is not specifically requested by the system. In some embodiments, the system can indicate that sending non-requested executable data is to be allowed. Whether any executable data is to be sent and, if so, the selection of which executable data is to be sent can be based, at least in part, on system data regarding the system. In some embodiments, a determination is made about executables previously associated with the system, such as games played on the game console (if the system is a game console) or games played on an associated game console (if the system is a personal computer which is associated with a game console.)
System information can also include user information about a user of the system. Thus, for example, a user may have indicated either implicit or explicitly preferences regarding games they are interested in. This preference information can be used to determine whether any candidate executable data for sending should be sent to the system. In some embodiments, a community of users can be formed, either explicitly through “friend” lists, or implicitly, by determining, for example, that a group of users all share similar preferences or similar games owned, and using this information to determine whether one user in the group would enjoy a game that that user has not played on their console system.
In some embodiments, at least some functionality of the executable data sent to the system is not usable without additional data. For example, upon payment of a license fee, license data may be sent to the system. When the license data is used with the executable data, the executable data may be used. In another example, the executable data is a game, and the game can be played for a certain period of time after which license data is necessary to continue game play. As another example, the executable data by itself allows a user to play certain levels of the game, but in order to use more than the trial version, additional data such as a password is required.
Because the user may be using the system, according to some embodiments, sending of executable data to the system is performed in such a way as to not perceptibly affect any ongoing operation of said system. This minimizes user inconvenience due to the described preemptive loading of executable data.
Only some embodiments of the invention have been described in this summary. Other embodiments, advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary constructions of the invention; however, the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:
FIG. 1 illustrates a gaming system that implements a uniform media portal architecture;
FIG. 2 is a block diagram of the gaming system;
FIG. 3 is a flow diagram showing a technique according to some embodiments of the invention;
FIG. 4 a flow diagram showing a technique according to some other embodiments of the invention; and
FIG. 5 is a block diagram illustrating a system according to some embodiments of the present invention.
Exemplary Gaming System
FIG. 1 shows an exemplary gaming system 100. It includes a game console 102 and up to four controllers, as represented by controllers 104(1) and 104(2). The game console 102 is equipped with an internal hard disk drive and a portable media drive 106 that supports various forms of portable storage media as represented by optical storage disc 108. Examples of suitable portable storage media include DVD, CD-ROM, game discs, and so forth.
The game console 102 has four slots 110 on its front face to support up to four controllers 104, although the number and arrangement of slots may be modified. A power button 112 and an eject button 114 are also positioned on the front face of the game console 102. The power button 112 switches power to the game console and the eject button 114 alternately opens and closes a tray of the portable media drive 106 to allow insertion and extraction of the optical storage disc 108.
Game console 102 connects to a television or other display (not shown) via A/V interfacing cables 120. A power cable 122 provides power to the game console. The game console 102 may further be configured with broadband capabilities, as represented by the cable or modem connector 124 to facilitate access to a network, such as the Internet.
Each controller 104 is coupled to the game console 102 via a wire or wireless interface. In the illustrated implementation, the controllers are USB (Universal Serial Bus) compatible and are connected to the console 102 via serial cables 130. The controller 102 may be equipped with any of a wide variety of user interaction mechanisms. As illustrated in FIG. 1, each controller 104 is equipped with two thumbsticks 132(1) and 132(2), a D-pad 134, buttons 136, and two triggers 138. These mechanisms are merely representative, and other known gaming mechanisms may be substituted for or added to those shown in FIG. 1.
A memory unit (MU) 140 may be inserted into the controller 104 to provide additional and portable storage. Portable memory units enable users to store game parameters and port them for play on other consoles. In the described implementation, each controller 104 is configured to accommodate two memory units 140, although more or less than two units may be employed in other implementations.
The gaming system 100 is capable of playing, for example, games, music, and videos. With the different storage offerings, titles can be played from the hard disk drive or the portable medium 108 in drive 106, from an online source, or from a memory unit 140. A sample of what the gaming system 100 is capable of playing back include:
1. Game titles played from CD and DVD, from the hard disk drive, or from an online source.
FIG. 2 shows functional components of the gaming system 100 in more detail. The game console 102 has a central processing unit (CPU) 200 and a memory controller 202 that facilitates processor access to various types of memory, including a flash ROM (Read Only Memory) 204, a RAM (Random Access Memory) 206, a hard disk drive 208, and the portable media drive 106. The CPU 200 is equipped with a level 1 cache 210 and a level 2 cache 212 to temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput.
The CPU 200, memory controller 202, and various memory devices are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus, also known as a Mezzanine bus.
As one suitable implementation, the CPU 200, memory controller 202, ROM 204, and RAM 206 are integrated onto a common module 214. In this implementation, ROM 204 is configured as a flash ROM that is connected to the memory controller 202 via a PCI (Peripheral Component Interconnect) bus and a ROM bus (neither of which are shown). RAM 206 is configured as multiple DDR it SDRAM (Double Data Rate Synchronous Dynamic RAM) that are independently controlled by the memory controller 202 via separate buses (not shown). The hard disk drive 208 and portable media drive 106 are connected to the memory controller via the PCI bus and an ATA (AT Attachment) bus 216.
A 3D graphics processing unit 220 and a video encoder 222 form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit 220 to the video encoder 222 via a digital video bus (not shown). An audio processing unit 224 and an audio codec (coder/decoder) 226 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit 224 and the audio codec 226 via a communication link (not shown). The video and audio processing pipelines output data to an ANV (audio/video) port 228 for transmission to the television or other display. In the illustrated implementation, the video and audio processing components 220-228 are mounted on the module 214.
Also implemented on the module 214 are a USB host controller 230 and a network interface 232. The USB host controller 230 is coupled to the CPU 200 and the memory controller 202 via a bus (e.g., PCI bus) and serves as host for the peripheral controllers 104(1)-104(4). The network interface 232 provides access to a network (e.g., Internet, home network, etc.) and may be any of a wide variety of various wired or wireless interface components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.
The game console 102 has two dual controller support subassemblies 240(1) and 240(2), with each subassembly supporting two game controllers 104(1)-104(4). A front panel I/O subassembly 242 supports the functionality of the power button 112 and the eject button 114, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the game console. The subassemblies 240(1), 240(2), and 242 are coupled to the module 214 via one or more cable assemblies 244.
Eight memory units 140(1)-140(8) are illustrated as being connectable to the four controllers 104(1)-104(4), i.e., two memory units for each controller. Each memory unit 140 offers additional storage on which games, game parameters, and other data may be stored. When inserted into a controller, the memory unit 140 can be accessed by the memory controller 202.
A system power supply module 250 provides power to the components of the gaming system 100. A fan 252 cools the circuitry within the game console 102.
The game console 102 implements a uniform media portal model that provides a consistent user interface and navigation hierarchy to move users through various entertainment areas. The portal model offers a convenient way to access content from multiple different media types—game data, audio data, and video data—regardless of the media type inserted into the portable media drive 106.
To implement the uniform media portal model, a console user interface (UI) application 260 is stored on the hard disk drive 208. When the game console is powered on, various portions of the console application 260 are loaded into RAM 206 and/or caches 210, 212 and executed on the CPU 200. The console application 260 presents a graphical user interface that provides a consistent user experience when navigating to different media types available on the game console.
The gaming system 100 may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the gaming system 100 allows one or more players to play games, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 232, the gaming system 100 may further be operated as a participant in a larger network gaming community. The network interface 232 may connect to a network. Such a network may be public (e.g. the Internet), private (e.g. a residential local area network (LAN)) or some combination of public and private. Such a network may introduce another memory source available to individual gaming systems 100—online storage. In addition to the portable storage medium 108, the hard disk drive 208, and the memory unit(s) 140, the gaming system 100(1) can also access data files available at remote storage locations via the network.
Preemptive Loading of Console Games
In order to reduce the inconvenience of buying executable on physical media or waiting for downloads of large amounts of executable data, media is delivered via a network, such as the Internet, on a pre-emptive basis. FIG. 3 is a flow diagram showing a technique according to some embodiments of the invention. As shown in FIG. 3, step 300, first, a determination is made that a specific user is likely to be interested in using a specific executable.
This determination may be made in any number of ways. Generally, the determination will be made at least in part based on some information regarding a user or a system. For example, the determination may be based on a user's prior history with other executables. For example, if system information indicates that the user has used racing games previously, this information may be used to draw an inference that the user of the system will be interested in a new racing game. Additionally, if the user has used all the games in a specific series, this information can be used to draw an inference that the user will be interested in a new game in that series.
The user or system information can be explicit or implicit. For example, in some embodiments of the invention, as described above, system information indicates that the user has used racing games previously; this information may be used to draw an inference that the user of the system will be interested in a new racing game. In one embodiment, information regarding the user's past purchases may be obtained from, for example, the information from a retailer of games. In other embodiments, registration data from a game publisher describes which games a specific user has bought and registered a copy of, and this registration data can be used to infer a user's interest in a specific game. This is implicit information, because the user's interest in racing games is inferred based on the user's history.
Explicit information may also be used to make the determination regarding the user's likelihood to be interested in an executable. For example, a user may have a user profile. The profile may include a checklist of the types of games the user is generally interested in. If “racing games” is included in the checklist, and the user has explicitly indicated interest in racing games in that way, then that explicit information regarding the user can be used to determine that a new racing game is likely to interest the user.
The determination can also be made based on information about a larger community of which the user is a part. For example, if user ratings are collected, and a community of users including the user has rated the executable highly, then the user's likely interest in the executable may be inferred. The community may be explicit or implicit. An explicit community may be formed by users who designate other users as “friends” or by users joining a community. An implicit community may include a number of users who are similar in some way. For example, if a number of users are similar in their ratings of twenty games, they may form a community. If all but two of users in the community rated a specific executable highly, and the other two have no rating for that specific executable at all, that may be the basis for a determination that those two users are likely to be interested in that executable.
Once the determination of step 300 is made, in step 310, the executable is delivered to the specific user. The delivery of the executable may be directly to the system which will execute the executable. Thus, for example, the delivery of a game may be directly to a game console. Because a game console may have less available memory for the delivery of a game, in some embodiments, the delivery is to a personal computer or other intermediary device associated with the console. Thus, if a user owns both a personal computer and a console, the executable may be delivered to the personal computer. The user may then decide to move the executable to the console at a later time, by connecting the personal computer and the console, or by using the personal computer to burn the executable onto console-readable media, and using that media with the console.
The delivery of the executable, one embodiment, occurs via the Internet. In one embodiment, the delivery is managed so that there is no interference with other uses of the connection between the deliverer of the executable and the location to which it is being delivered. Thus, for example, if an executable is being delivered to a personal computer, the delivery of that executable will only occur if the delivery will not compromise the network performance of the personal computer, and will be cancelled or rescheduled otherwise. The delivery occurs in such a way as to not perceptibly affect any ongoing operation of said system. In some embodiments, a priority system is established by the receiving system, which assigns priorities to different tasks which use resources such as the network connection or processor usage. In some such embodiments, some system tasks are assigned a low priority, indicating that they must adhere to predefined limits on the usage of resources or interference with higher priority tasks. The delivery of the executable in step 310, in some such embodiments, is defined as such a system task. In other embodiments, the delivery of the executable in step 310 is assigned a specific priority level so that its effects on system performance are minimized or eliminated.
In some embodiments of the present invention, the executable delivered in step 310 has at least some functionality disabled. Thus, the executable may not be usable at all, or may be executable only as a trial version. The trial version may be limited in the time which it can be used or, for example, in the case of a game, may allow play on a number of game levels but not on all game levels. In such embodiments, the technique of FIG. 3 may be extended to include two additional steps—first, making a determination that the user has requested enablement of the disabled functionality; and second, delivering unlocking data to the user. The unlocking data may be, for example, a missing piece of executable data, a password, or a license file. In addition to determining that enablement has been requested, payment or rights information may also be required in order to deliver the unlocking data. In some embodiments, in order to unlock functionality of an executable, the user must establish a connection to a service, and the functionality will be enabled depending on the user's connection to the service. For example, a user may maintain an account with a gaming service which is associated with certain privileges. These privileges may include using the unlocked functionality of the delivered executable, and in such cases, if the user is logged in to the gaming service, the user can use the locked functionality of the delivered executable.
Thus, the unlocking data, in some embodiments, is “per console” unlocking. The unlocking data unlocks the delivered executable on one console or system. In the case of a game executable being unlocked on a game console, the user can play the game executable on the console without needing to perform unlocking verification each time that play is desired. In this way, the user does not need a network connection to unlock the game executable for each play.
The “per user” embodiments allow the user to have access to the executable even if the user is using a different system. Thus, if a gaming user purchases a game and is entitled to play it, if the user is playing on a different console, the user can sign in and the unlocking data will be used to enable the functionality of the delivered executable.
FIG. 4 a flow diagram showing a technique according to some other embodiments of the invention. As shown in FIG. 4, step 400, a connection is established to a system. This connection may be by any means, including the Internet or other networks.
In step 410, executable data which has not been requested by a user of the remote system is sent to the remote system, where the executable data is selected based at least in part on system information regarding the remote system. Then determination is made that a specific user is likely to be interested in using a specific executable.
The steps of FIG. 4 will be further explained with reference to FIG. 5. FIG. 5 is a block diagram illustrating a system according to some embodiments of the present invention. As shown in FIG. 5, a game server 500 is in contact with a gaming system 100 via a connection 540. With reference again to FIG. 4, the connection of step 500 is via connection 540, which may be a connection via the Internet or another network, or by any other way of establishing a continuous or intermittent connection.
Again with reference to FIG. 5, the game server includes system information storage 510 which stores information regarding gaming system 100, in one embodiment along with information on other systems. This storage may be more permanent, such as a database storing information regarding a number of gaming systems. Or the storage may be more transitory, such as an embodiment in which the gaming system 100 is queried for system information which is then stored temporarily in system information storage 510 while a determination is being made about sending executable data to the gaming system 100.
Additionally, executable data selection module 520 is included in game server 500. This executable data selection module 520 determines, using information from system information storage 510, what executable data (if any) should be sent to gaming system 100. The executable data transmitter 530 transmits the executable data to the gaming system 100, as detailed in step 410 of FIG. 4.
In some embodiments, instead of directly sending executable data to gaming system 100, the game server 500 sends executable data to another computer system which is associated in some way with the game server 500. In this way, the storage and functionality of computer systems which are not game consoles can be utilized in carrying out the techniques of the invention. The intermediary computer system receiving the executable data is then used in transferring the executable data to the destination where it is executed.

CONCLUSION

It is noted that the foregoing examples have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the present invention. While the invention has been described with reference to various embodiments, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitations. Further, although the invention has been described herein with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed herein; rather, the invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims. Those skilled in the art, having the benefit of the teachings of this specification, may effect numerous modifications thereto and changes may be made without departing from the scope and spirit of the invention in its aspects.

Claims

1. A method for providing an executable to a system via a remote connection, said method comprising:

establishing a remote connection to said system; and

sending executable data to said system, where said executable data has not been requested by a user of said system, and where said executable data is selected based at least in part on determining system information regarding said system.

2. The method of claim 1, where said system comprises a game console system and said executable data comprises game data.

3. The method of claim 1, where said executable data comprises game data for a game console system, where said system comprises a personal computer, and where said system information comprises information regarding a game console unit associated with said personal computer.

4. The method of claim 1, where said system information comprises information regarding at least one executable previously associated with said system.

5. The method of claim 1, where said system information comprises user information regarding a user of said system.

6. The method of claim 5, where said user information comprises friend information comprising an indication of at least one other user, and where said executable data is selected based on usage information describing usage of at least one executable by at least one of said at least one other users.

7. The method of claim 5, where said user information comprises friend information comprising an indication of at least one other user, and where said executable data is selected based on ratings information describing ratings of at least one executable by at least one of said at least one other users.

8. The method of claim 1, where some functionality of said executable data can not be executed without additional data, said method further comprising:

sending said additional data to said system.

9. The method of claim 8, where said step of sending said additional data to said system comprises:

accepting payment information.

10. The method of claim 8, where said additional data comprises a digital license to use said executable data.

11. The method of claim 1, where said step of sending executable data to said system is performed in such a way as to not perceptibly affect any ongoing operation of said system.

12. A system for providing executable data to a remote system, comprising:

system information storage for storing system information regarding said remote system;

executable data selection module, operably connected to said system information storage, for selecting executable data based at least in part on said system information; and

executable data transmitter, operably connected to said executable data selection module, for transmitting executable data to said remote system.

13. The system of claim 12, where said executable data comprises game data.

14. The system of claim 12, where said system information comprises information regarding at least one executable previously associated with said system.

15. The system of claim 12, where said system information comprises user information regarding a user of said system.

16. The system of claim 12, where said user information is used to determine a community of at least one other users, and where said executable data is selected based on community information regarding said community.

17. The system of claim 12, where some functionality of said executable data can not be executed without additional data.

18. The system of claim 17, where said system further comprises:

payment acceptor for accepting payment information; and

additional data transmitter, operably connected to said payment acceptor, for transmitting said additional data to said remote system.

19. A computer-readable medium comprising computer-executable instructions for providing an executable to a system via a remote connection, said computer-executable instructions for performing steps comprising:

determining that a specific user is likely to be interested in using a specific executable; and

delivering that executable to said specific user in advance of a request from said specific user.

20. The computer-readable medium of claim 19, where at least some functionality is disabled in said delivered executable, said steps further comprising:

determining that said specific user has requested enablement of said disabled functionality; and

delivering unlocking data to said specific user, where said unlocking data enables said disabled functionality.