1. Field of the Invention
The invention generally relates to software applications, such as video game applications, that are configured to render graphics content to a display.
2. Background
In-game advertising refers to the use of computer and video games as a medium in which to deliver advertising. It has been reported that spending on in-game advertising in 2005 was $56 million USD, and that this figure is estimated to grow to $1.8 billion by 2010. In-game advertising is seen by some in the games industry as offering a promising new revenue stream that may provide publishers with a way to offset growing game development costs. This extra revenue may also allow developers to reduce the risk involved in a game development project, allowing them to innovate on game play and experiment with new ideas.
One approach to in-game advertising is to incorporate advertising content directly within the graphics content rendered by a game, such that advertisements appear to be an integrated part of the game. For example, an advertisement may be placed within the context of a two-dimensional (2D) or three-dimensional (3D) scene rendered by a game. Examples of such in-game advertisements may comprise a virtual billboard or a virtual version of a commercial product rendered within the game environment. These in-game advertisements may be either static or dynamic in nature. Static advertisements are coded directly into the game application by programmers during development and cannot be changed later. In contrast, dynamic advertisements can be altered remotely during run-time by an advertising agency or other entity. Dynamic in-game advertising can be achieved by integrating the game code with an in-game advertising software development kit (SDK) during game development, or by utilizing approaches as described in commonly-owned co-pending U.S. patent application Ser. No. 11/290,830.
Another approach to in-game advertising is to dedicate a portion of the display area to which the game scene is being rendered to advertising content such that the advertising content appears separate and apart from the graphics content of the game. An example of this approach may be seen in
One benefit of the latter approach is that it is typically easier to sell, serve, create, render and track the viewing of advertisements appearing in advertising display portion 104, since they do not need to be included as an integrated part of a scene rendered by the game. For example, they do not need to be included as objects within a 3D scene rendered by the game. Another benefit of the latter approach is that it facilitates the rendering of advertisements of a standard size. For example, the advertisements rendered within advertising display portion 104 may comply with size guidelines published by a trade association such as the Interactive Advertising Bureau (IAB). The use of such standard-sized advertisements makes it easier for designers to develop advertisements for different publishers. The use of such standard-sized advertisements also makes it possible to develop a consistent size-based pricing scheme for selling such advertising space to marketers, to utilize an existing sales force to sell such advertising space, and to utilize standard web advertisement-serving systems to serve advertisements into advertising display portion 104.
One method for allocating and rendering graphics to both game display portion 102 and advertising display portion 104 of display area 100 is to program such functionality into a game during development. However, this method increases development time and costs and also binds the game to a particular format and type of in-game advertising. Another method is to design the game so that it renders graphics to only a portion of a display area such that it can be run in parallel with another application that serves advertisements to the unused portion of the display area. However, a game so designed could either never be run in a mode in which it uses the full display area or must be programmed from the outset to include support for two modes of operation—one in which it renders graphics to only a portion of a display area and another in which it renders graphics to the entire display area.
Each of the foregoing methods requires the game developer to anticipate that the game will be run in a shared display area along with in-game advertising prior to release and to program the game accordingly to accommodate this feature. If the feature is not programmed into the game prior to release, then to add such functionality would require modifying and recompiling the source code after release. However, this may not be possible or commercially feasible in all cases. For example, the party wishing to modify the source code to accommodate this particular type of in-game advertising may not have access to the source code. As another example, multiple instances of the game may already have been purchased and installed by multiple end users.
What is needed, then, is a system, method and computer program product that enables a software application, such as a video game application, to render application-related graphics content to one portion of a display area and advertising content to a second portion of the same display area, even though the application was not originally programmed to support such functionality. Implementing the desired system, method and computer program product should not require modifying and recompiling the original application code or require any other changes to binary or data files associated with the original application. This allows the desired results to be achieved without developer intervention and on games that have been already provisioned and distributed to end-users machines.
The present invention provides a means by which a software application, such as a video game application, may be enhanced to render application-related graphics content to one portion of a display area and additional graphics content, such as advertising content to a second portion of the same display area, even though the application was not originally programmed to support such functionality. In one embodiment of the present invention, implementing this enhancement does not require modifying and recompiling the original application code.
In particular, a method for dynamically modifying graphics content associated with an executing software application is provided. In accordance with the method, one or more function calls issued by the software application are intercepted. The one or more function calls issued by the software application are configured to cause graphics content associated with the software application, such as a scene associated with a video game application, to be rendered to a display area. Responsive to the interception of the one or more function calls from the software application, one or more function calls are issued that are configured to cause the graphics content associated with the software application to be rendered to a first portion of the display area. The first portion of the display area may be smaller than the display area. Additional graphics content, such as advertising content, is rendered into a second portion of the display area. The second portion of the display area may be either overlapping or non-overlapping with respect to the first portion of the display area.
A computer program product is also provided. The computer program product comprises a computer-readable medium having computer program logic recorded thereon for enabling a processing unit to dynamically modify graphics content rendered by an executing software application. The computer program logic includes first means, second means, and third means. The first means enables the processing unit to intercept one or more function calls issued by the software application. The one or more function calls issued by the software application are configured to cause graphics content associated with the software application, such as a scene associated with a video game application, to be rendered to a display area. The second means enable the processing unit to issue one or more function calls responsive to intercepting the one or more function calls from the software application. The one or more function calls issued by the second means are configured to cause the graphics content associated with the software application to be rendered to a first portion of the display area. The first portion of the display area may be smaller than the display area. The third means enable the processing unit to render additional graphics content, such as advertising content, into a second portion of the display area. The second portion of the display area may be either overlapping or non-overlapping with respect to the first portion of the display area.
A system is further provided. The system includes a computer system and a server communicatively connected to the computer system. The computer system is configured to dynamically resize a scene associated with an executing application so that the scene occupies only a first portion of a display area of a display device. The server is configured to serve graphics content, such as advertising content, to the computer system. The computer system is further configured to render the graphics content to a second portion of the display area of the display device. The second portion of the display area may be either overlapping or non-overlapping with respect to the first portion of the display area.
Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the relevant art(s) to make and use the invention.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
Application 202 is a software application, such as a video game application, that is executed by computer system 200. Graphics functions 206 are software functions of computer system 200 that are accessible to application 202 during run-time and that assist application 202 in rendering application-related graphics information to a display within computer system 200. Graphics functions 206 may comprise, for example, one or more functions of an application programming interface (API) such as Microsoft® DirectX® or OpenGL®. Graphics content resizing/rendering component 204 is a software component that is installed on computer system 200 prior to execution of application 202. Graphics content resizing/rendering component 204 may be installed on computer system 200 together with application 202, or independent of it.
Application 202 is programmed such that, during execution, it issues function calls to graphics functions 206. The interaction of application 202 with graphics functions 206 is well-known in the art. However, in accordance with an embodiment of the present invention, certain function calls issued by application 202 are intercepted by graphics content resizing/rendering component 204. In response to intercepting these function calls, graphics content resizing/rendering component 204 issue modified versions of the intercepted function calls and/or new function calls to graphics functions 206.
As will be discussed in more detail herein, graphics content resizing/rendering component 204 is configured to intercept one or more function calls that are issued by application 202 to cause application-related graphics content to be rendered to a display area of a display device. Graphics content resizing/rendering component 204 is further configured to issue modified versions of the intercepted function calls and/or new function calls to cause the graphics content being rendered to the display area to be resized such that the graphics content is rendered to only a first portion of the display area, wherein the first portion of the display area may be smaller than the display area. Additionally, graphics content resizing/rendering component 204 is configured to issue new function calls that cause additional graphics content, such as one or more advertisements, to be rendered to one or more additional portions of the display area. Each of the additional portion(s) of the display area may be either overlapping or non-overlapping with respect to the first portion of the display area.
In one implementation of the present invention, in order to facilitate interception of function calls, graphics content resizing/rendering component 204 comprises one or more emulated versions of certain graphics functions 206. A particular example of the emulation of graphics functions 206 will now be described with reference to
During execution, application 302 issues function calls to a graphics API 304 in a well-known manner. Graphics API 304 comprises a series of libraries that are accessible to application 302 in PC memory and that include functions that may be called by application 302 for rendering and displaying graphics information. Graphics API 304 may be, for example, a Microsoft® Direct3D® API or an OpenGL® API. In response to receiving the function calls from application 302, graphics API 304 determines if such functions can be executed by graphics hardware 308 within the PC. If so, graphics API 304 issues commands to a device driver interface (DDI) 306 for graphics hardware 308. DDI 306 then processes the commands for handling by the graphics hardware 308.
In contrast to the conventional software architecture illustrated in
Depending on the operating system, emulating a genuine graphics API can be achieved in various ways. One method for emulating a genuine graphics API is file replacement. For example, since both DirectX® and OpenGL® APIs are dynamically loaded from a file, emulation can be achieved by simply replacing the pertinent file (for example, OpenGL.dll for OpenGL® and d3dX.dll for DirectX® where X is the DirectX® version). Alternatively, the DLL can be replaced with a stub DLL having a similar interface that implements a pass-through call to the original DLL for all functions but the functions to be intercepted.
An alternative method for intercepting function calls to the graphics API is to use the Detours hooking library published by Microsoft® Corporation of Redmond, Wash. Hooking may also be implemented at the kernel level. Kernel-level hooking may include the use of an operating system (OS) ready hook that generates a notification when a particular API is called. Another technique is to replace existing OS routines by changing a pointer in an OS API table to a hook routine pointer, and optionally chaining the call to the original OS routine before and/or after the hook logic execution. Another possible method is an API-based hooking technique that injects a DLL into any process that is being loaded by setting a global system hook or by setting a registry key to load such a DLL. Such injection is performed only to have the hook function running in the address space. While the OS loads such a DLL, a DLL initialization code changes a desired DLL dispatch table. Changing the table causes a pointer to the original API implementation to point to the interception DLL implementation for a desired API, thus hooking the API. Note that the above-describing hooking techniques are presented by way of example and are not intended to limit the present invention. Other methods and tools for intercepting function calls to graphics APIs are known to persons skilled in the relevant art(s).
The method of flowchart 500 begins at step 502, in which application 202 issues one or more function calls that are configured to cause graphics content associated with the application to be rendered to a display area on a display device. Depending on the implementation, the display area may be defined such that it occupies the entire screen of a display device or only a portion thereof. In accordance with one implementation, application 202 comprises a video game application and the graphics content associated with application 202 comprises a 2D or 3D scene associated with the game.
At step 504, graphics content resizing/rendering component 204 intercepts the function call(s) issued by application 202. Various methods by which graphics content resizing/rendering component 204 may intercept such function call(s), such as various types of API emulation and hooking, are discussed above in Section A, and thus will not be repeated here for the sake of brevity.
At step 506, responsive to intercepting the function call(s) issued by application 202, graphics content resizing/rendering component 204 issues one or more modified versions of the intercepted function call(s) and/or one or more new function calls to cause the graphics content associated with the software application to be rendered to a first portion of the display area. The first portion of the display area may be smaller than the display area.
At step 508, graphics content resizing/rendering component 204 renders additional graphics content into one or more additional portions of the display area. Each of the additional portion(s) of the display area may be either overlapping or non-overlapping with respect to the first portion of the display area. In one implementation, the additional graphics content comprises one or more advertisements. The additional graphics content may be stored locally with respect to system 200 or may be made available by a remote entity via a network, such as the Internet. For example, a remote entity such as an ad server may make graphics-based advertising content available to graphics content resizing/rendering component 204 via an Internet connection. However, these examples are not intended to limit the present invention and any type of graphics content from any source may be rendered into the one or more additional portions of the display area in step 508.
Specific methods for implementing the general method of flowchart 500 of
At step 604, graphics content resizing/rendering component 204 hooks the SetViewport call. At step 606, graphics content resizing/rendering component 204 modifies the SetViewport call to change the size and location of the rectangular viewport to which the scene is to be rendered. The size and location may be changed such that the rectangular viewport covers only a portion of the viewport defined by the original SetViewport call. At step 608, graphics content resizing/rendering component 204 issues the modified SetViewport call to graphics functions 206, where it is handled in a conventional manner.
Subsequent to the performance of the steps of flowchart 600 of
Flowchart 700 describes steps that occur when application 202 issues the Present call. The issuance of the Present call by application 202 is shown at step 702. At step 704, graphics content resizing/rendering component 204 hooks the Present call. At step 706 through 712, responsive to hooking the Present call, graphics content resizing/rendering component 204 performs steps to render additional graphics content into a new viewport. In particular, at step 706, graphics content resizing/rendering component 204 issues a BeginScene call. At step 708, graphics content resizing/rendering component 204 issues a SetViewport call to define a new viewport to which additional graphics content is to be rendered. This new viewport may be either overlapping or non-overlapping with respect to the viewport defined in step 608 of
At decision step 714, it is determined whether an additional area is needed to display further additional graphics content. If so, then steps 706 through 712 are repeated to create another viewport and to render the further additional graphics content into the new viewport. However, if no additional area is needed, then graphics content resizing/rendering component 204 calls the Present function to cause the modified scene, which now includes at least one additional viewport including additional graphics content, to be presented to the display area.
Persons skilled in the relevant art(s) will appreciate that the foregoing methods of flowcharts 600 and 700 may be modified to conform to a manner in which application 202 is programmed. For example, application 202 may not be programmed to issue a SetViewport call (as described above in reference to step 602 of flowchart 600) but may instead use a default viewport that occupies the entirety of a display area. In this case, rather than hooking a SetViewport call issued by application 202, graphics content resizing/rendering component 204 may, for example, hook a Direct3D® CreateDevice call and then, responsive to hooking the CreateDevice call, issue a SetViewport function call that defines a rectangular portion of the display area to which a scene associated with application 202 is to be rendered.
In another alternative implementation of flowcharts 600 and 700, graphics content resizing/rendering component 204 does not define a new viewport for displaying additional graphics content during step 708, but instead defines the new viewport responsive to the hooking of the original SetViewport function call in step 604. In a still further alternative implementation, graphics content resizing/rendering component 204 defines the new viewport responsive to the hooking of a CreateDevice function call by application 202.
At step 904, graphics content resizing/rendering component 204 hooks the initialization call. At step 906, graphics content resizing/rendering component 204 issues a Direct3D® SetRenderTarget call to cause graphics content associated with the application to be rendered to a buffer identified by graphics content resizing/rendering component 204 rather than to a location identified by application 202 or to a default location.
Subsequent to the performance of the steps of flowchart 900 of
Flowchart 1000 describes steps that occur when application 202 issues the Present call. The issuance of the Present call by application 202 is shown at step 1002. At step 1004, graphics content resizing/rendering component 204 hooks the Present call. At step 1006, responsive to hooking the Present call, graphics content resizing/rendering component 204 issues a BeginScene call. At step 1008, graphics content resizing/rendering component 204 defines a rectangular sprite that may have smaller dimensions than the dimensions of the rectangular display area. At step 1010, graphics content resizing/rendering component 204 issues a Direct3D® DrawSprite call to cause a sprite having the dimensions defined in step 1008 to be drawn to a specified location in the display area using the texture identified by the SetRenderTarget call issued in step 906 of flowchart 900 of
At step 1012 through 1016, graphics content resizing/rendering component 204 performs steps to render additional graphics content into a new viewport within the display area. In particular, at step 1012, graphics content resizing/rendering component 204 issues a SetViewport call to define a viewport within the display area to which additional graphics content is to be rendered. This new viewport may be either overlapping or non-overlapping with respect to the sprite drawn to the display area in step 1008. At step 1014, graphics content resizing/rendering component 204 draws the additional graphics content into the viewport defined in step 1012. At decision step 1016, it is determined whether an additional area within the display area is needed to display further additional graphics content. If so, then steps 1012 through 1014 are repeated to create another viewport within the display area and to render the further additional graphics content into the new viewport.
However, if no additional area is needed, then graphics content resizing/rendering component 204 issues an EndScene call as shown at step 1018. At step 1020, graphics content resizing/rendering component 204 calls the Present function to cause the modified scene, which now includes the sprite drawn in step 1008 and at least one viewport including additional graphics content, to be presented to the display area.
At step 1104, graphics content resizing/rendering component 204 hooks the Present call. At step 1106, responsive to hooking the Present call, graphics content resizing/rendering component 204 obtains a back buffer associated with application 202 and resizes it by stretching it to another render target having a desired size. The new render target is then used as the back buffer for application 202 and graphics content resizing/rendering component 304 to render the additional content and/or advertising.
At step 1106, graphics content resizing/rendering component 204 draws the additional graphics content into the new render target/back buffer. Finally, at step 1108, graphics content resizing/rendering component 204 calls Present to draw the modified back buffer to the display area.
At step 1204, graphics content resizing/rendering component 204 hooks the CreateDevice call. At step 1206, responsive to hooking the CreateDevice call, graphics content resizing/rendering component 204 creates an alternate window of a modified size which is configured to be a child of the window specified for application 202. As a result, application 202 executes in a window mode rather than a full-screen mode. At step 1208, graphics content resizing/rendering component 204 uses the newly-created window as the render target for the real DirectX device. At step 1210, graphics content resizing/rendering component 204 creates one or more additional windows within the remaining portions of the display area for the purpose of rendering additional graphics content. These additional windows may be used for example for the purpose of rendering advertising content.
As described above, an embodiment of the present invention dynamically resizes graphics content rendered by a software application, such as a video game application, to facilitate the rendering of additional graphics content, such as advertisements, to a portion of a display area that would otherwise have been occupied by the application-related graphics content. When such a technique is applied to a software application that allows a user to interact with objects within the display area using a pointer device (e.g., a mouse, keyboard, or any other I/O device capable of controlling a pointer), special care must be taken to ensure that the pointer image is displayed in the appropriate position and that the application receives pointer coordinates back from I/O elements in a position that will allow regular control of the application by the user. In particular, special care must be taken to ensure that the pointer image is displayed in an appropriate position within the resized application scene as opposed to the position at which the pointer image would normally have been displayed prior to resizing.
For applications that render the pointer image along with all the other objects rendered within a scene, the position of the pointer image is automatically adjusted when a scene rendered by the application is resized in accordance with one of the foregoing methods. However, when the display of the pointer image is managed by an entity outside of the application, such as by an operating system, a separate method must be used to reposition the pointer image to adjust for the resizing of the application scene. Such a method will now be described.
As further shown in
The method of flowchart 1400 begins at step 1402, in which a pointer event occurs. The pointer event may comprise, for example, a function call issued by an operating system within system 1300. The function call may be issued responsive to the receipt of input from a pointing device within or attached to system 1300.
At step 1404, pointer event capture component 1308 captures the pointer event. To this end, pointer event capture component 1308 may include a low-level pointer hook. Where the operating system is a Microsoft® Windows® operating system, the pointer hook may be set using a function such as SetWindowsHookEx. However, this approach is described by way of example only, and is not intended to be limiting. Many other techniques well-known to persons skilled in the relevant art(s) may be used to capture the pointer event.
Responsive to the capture of the pointer event, pointer event capture component performs several functions. In particular, at step 1406, pointer event capture component 1308 saves the current position of the pointer image as determined by the operating system. At decision step 1408, pointer event capture component 1308 determines if the pointer image maintained by the operating system is new or has changed as a result of the pointer event. If the pointer image is not new and has not changed as a result of the pointer event, then processing proceeds to step 1412. However, if the pointer image is new or has changed as a result of the pointer event, then pointer event capture component 1308 converts the pointer image to a bitmap or texture and saves it as shown at step 1410. This may be achieved in a Microsoft® Windows® environment, for example, by capturing a mouse cursor using an HCURSOR handle and obtaining an associated bitmap from the device context (DC) of the system. Processing then proceeds to step 1412, during which pointer event capture component 1308 disables the normal display of the pointer image by the operating system.
At step 1414, graphics content resizing/rendering component 1304 uses the current position of the pointer image that was saved by pointer event capture component 1308 to calculate a new position for the pointer image within the resized application-related scene. At step 1416, graphics content resizing/rendering component 1304 then draws the bitmap or texture representation of the pointer image saved by pointer event capture component 1308 to the new position within the resized application-related scene. Steps 1414 and 1416 may be performed by graphics resizing/rendering component 1304 responsive to intercepting a Present call from application 1302.
In one embodiment of the present invention, pointer event capture component 1308 is configured to perform steps 1406 through 1412 as described above only when it is determined that the captured pointer event is a pointer movement event.
The result of the foregoing method is that the display of a pointer image associated with application 1302 is bounded with the resized area defined by graphics content resizing/rendering component 1304 for displaying an application-related scene.
An alternative embodiment of the present invention includes the foregoing functionality but in another mode of operation also supports pointer-based interaction with the additional graphics content rendered by graphics content resizing/rendering component 1304. Such additional graphics content may comprise, for example, an interactive or “clickable” advertisement.
In accordance with this further embodiment, responsive to a user providing some predetermined input (such as pressing a particular combination of keys), graphics content resizing/rendering component 1304 enters an “interactive” mode in which the original position of the pointer image is not translated to a new position in the manner described above. In addition, the pointer image presented to the user may optionally be changed from what would have normally been presented to the user responsive to the user providing the predetermined input. This new pointer image may be used to indicate to the user that he/she has entered a different mode of interaction. While in the aforementioned interactive mode, when pointer event capture component 1308 captures a pointer movement event, graphics content resizing/rendering component 1304 displays the pointer image in its original position, without conversion to a new pointer image location. Furthermore when pointer event capture component 1308 captures a pointer click event, graphics content resizing/rendering component 1304 notifies an additional component and, based on this notification, the additional component performs one or more additional functions. For example, in an embodiment in which the additional component is an Internet browser, the one or more additional functions may include presenting a Web page in a new window that pertains to the advertised product or service.
As shown in
Computer system 1500 further includes a main memory 1506, such as a random access memory (RAM), and a secondary memory 1512. Secondary memory 1512 may include, for example, a hard disk drive 1522 and/or a removable storage drive 1524, which may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, or the like. Removable storage drive 1524 reads from and/or writes to a removable storage unit 1550 in a well known manner. Removable storage unit 1550 may comprise a floppy disk, magnetic tape, optical disk, or the like, which is read by and written to by removable storage drive 1524. As will be appreciated by persons skilled in the relevant art(s), removable storage unit 1550 includes a computer usable storage medium having stored therein computer software and/or data.
In an alternative implementation, secondary memory 1512 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1500. Such means can include, for example, a removable storage unit 1560 and an interface 1526. Examples of a removable storage unit 1560 and interface 1526 include a program cartridge and cartridge interface (such as that found in video game console devices), a removable memory chip (such as an EPROM or PROM) and associated socket, and other removable storage units 1560 and interfaces 1526 which allow software and data to be transferred from the removable storage unit 1560 to computer system 1500.
Computer system 1500 also includes at least one communication interface 1514. Communication interface 1514 allows software and data to be transferred between computer system 1500 and external devices via a communication path 1570. In particular, communication interface 1514 permits data to be transferred between computer system 1500 and a data communication network, such as a public data or private data communication network. Examples of communication interface 1514 can include a modem, a network interface (such as Ethernet card), a communication port, and the like. Software and data transferred via communication interface 1514 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communication interface 1514. These signals are provided to the communication interface via communication path 1570.
As shown in
As used herein, the term “computer program product” may refer, in part, to removable storage unit 1550, removable storage unit 1560, a hard disk installed in hard disk drive 1522, or a carrier wave carrying software over communication path 1570 (wireless link or cable) to communication interface 1514. A computer useable medium can include magnetic media, optical media, or other recordable media, or media that transmits a carrier wave or other signal. These computer program products are means for providing software to computer system 1500.
Computer programs (also called computer control logic) are stored in main memory 1506 and/or secondary memory 1512. Computer programs can also be received via communication interface 1514. Such computer programs, when executed, enable the computer system 1500 to perform one or more features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 1504 to perform features of the present invention. Accordingly, such computer programs represent controllers of the computer system 1500.
Software for implementing the present invention may be stored in a computer program product and loaded into computer system 1500 using removable storage drive 1524, hard disk drive 1522, or interface 1526. Alternatively, the computer program product may be downloaded to computer system 1500 over communications path 1570. The software, when executed by the processor 1504, causes the processor 1504 to perform functions of the invention as described herein.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art(s) that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Accordingly, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
This application is a continuation-in-part of U.S. patent application Ser. No. 11/290,830, entitled “System, Method and Computer Program Product for Dynamically Enhancing an Application Executing on a Computing Device” and filed Dec. 1, 2005. The entirety of U.S. patent application Ser. No. 11/290,830 is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
Parent | 11290830 | Dec 2005 | US |
Child | 11779391 | Jul 2007 | US |