MXPA06005351A - State-based memory unloading - Google Patents

Abstract

A system is described for managing memory, the system including, among other things, a memory with logic and a processor configured with the logic to receive an indication of an application state from a plurality of applications in memory and determine which of the plurality of applications to effect removal from the memory based on the received indication.

Description

DOWNLOAD OF MEMORY BASED ON THE STATE OF THE APPLICATION Field of the Invention The present description is generally related to television systems and more particularly, relates to the management of memory in television systems. BACKGROUND OF THE INVENTION With recent advances in digital broadcasting technology, subscriber television systems can now provide much more than traditional analog broadcast video. In the implementation of enhanced programming, the home communication terminal ("HCT"), otherwise known as the decoder, has become an important computing device for accessing content services (and content). within those services) and for a user to navigate through a number of available services. In addition to supporting traditional analog broadcast video functionality, digital HCTs (or "DHCTs") now also support an increasing number of digital two-way services, such as video on demand and personal video recording. Generally, a DHCT is connected to a cable or satellite system, or generally, to a subscriber television system, and includes software and hardware necessary to provide the functionality of the digital television system on the user's site. Some of the softwares executed by the DH CT can be downloaded and / or updated through the subscribers' television system. When the software is downloaded from memory, such as to free up a free memory space for other software, systems often lack discernment as to the software they must download from memory, particularly the software that operates at a higher control level. Even systems that employ organized methods of software flow in and out of memory often deduce the user experience. For example, some systems may employ a prioritization methodology that eliminates software that consumes most of the memory space when memory space is needed. Unfortunately, the software that consumes most of the memory space will usually be the software that is removed, which can increase the time consumed to reload the software when necessary. Among other problems, due to careless handling of the download and / or reloading of the software outside and inside the memory, it can lead to a lack of user satisfaction in the functioning of the subscriber television system. Therefore, there is a need in the industry to solve the deficiencies and / or inconveniences mentioned above. BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the description can be better understood by reference to the following drawings. The components of the drawings are not necessarily to scale, instead emphasis has been placed upon clearly illustrating the principles of the present disclosure. In addition, in the drawings, similar reference numbers designate corresponding parts in the different figures. Figure 1 is a block diagram illustrating an example subscriber television system (STS), according to one embodiment of the description. Figure 2 is a block diagram illustrating an example of selected components of a head tip as illustrated in Figure 1, according to one embodiment of the description. Figure 3 is a block diagram illustrating a domestic digital communication terminal (DHCT), as shown in Figure 1, which is connected to the head tip and to a television decoder, according to a modality of the description.

Figure 4 is a schematic diagram of an exemplary remote control apparatus for providing input to the DHCT illustrated in Figure 3, according to one embodiment of the description. Figure 5 is a diagram of the screen illustrating an example poker game that is in progress according to one embodiment of the description. Figure 6 is a diagram of the screen of an exemplary service guide to which a user may invoke while playing a game of poker illustrated in Figure 5, according to one embodiment of the present disclosure. Figure 7 is a diagram of the screen of an exemplary web page that can be invoked by the user from the example service guide of Figure 6, according to one embodiment of the description. Figure 8 is a diagram of the screen illustrating the example poker game of Figure 5 returned to a boot state after being downloaded and loaded again without saving the state of the application, according to a mode of the present description. Figure 9A is a flowchart illustrating an example of a method employed by an application to inform a master control of a change in status, according to one embodiment of the description. Figures 9B and 9C are programming diagrams of an example application programming interface (API) and the associated data structure, respectively, wherein the API is preferably invoked by an application whenever transitions of the application state occur. inactive to a fully active application state or from a fully active to inactive state, according to the present embodiment of the description. Fig. 10A is a flow diagram illustrating an exemplary download priority method, according to one embodiment of the description. Fig. 10B is a flow diagram illustrating a "pulse model" mechanism for a master controller for receiving status information, according to one embodiment of the description. Figures 10C and 10D are programming diagrams illustrating an example API and the associated data structure, respectively, wherein the API enables an application to provide status information to a master controller, according to a mode of the present description. Figure 10E is a programming diagram illustrating a sample API that makes it possible for an application to retrieve the status information of a master controller, according to one embodiment of the description.

Figure 11 is a screen diagram of an example user information menu superimposed on the example service guide illustrated in Figure 6, according to one embodiment of the present disclosure. Detailed Description of the Invention Preferred embodiments of the description will be described more fully below with reference to the accompanying drawings. The preferred embodiments of the description will be described in the context of a television subscriber system, with the understanding that other communication systems, including home entertainment systems, building management systems, among others, can also benefit. In particular, preferred embodiments of the disclosure include systems and methods for enabling applications and / or other modules to be intelligently downloaded (eg, deleted) from memory and reloaded with minimal interference to the user. . Preferred embodiments of the present disclosure also include systems and methods that provide the user with information regarding the effect of downloading an application. The preferred embodiments of the description decide which applications are the preferred applications for the download according to previously defined criteria. If the applications that are not preferred applications for the download need to be downloaded, the preferred embodiments of the description minimize the effect on the user experience, as will be described later. An application will be understood in the present description as including a packaged functionality comprising any part from a single line of code to multiple lines of code that accept an entry, such as a variable that has been passed or a user input and performs one or more operations that result in an exit. In the present description emphasis will be placed on the applications that provide a service in the subscriber television system (for example, the pay-per-event service, on-demand services, games, web search, etc.), in the understanding that other memory management systems can benefit and in a similar manner, within the scope of the preferred embodiments of the description. From time to time it may be necessary for the applications to be removed from a memory of the domestic digital communication terminal (DHCT) to enable other operations to be implemented. The applications may have status information, such as an information that indicates whether the application is in one of two or more stages of operation, such as whether the operation originated from the initial start of a poker game or if an application was it has been signed for an instant messaging server among others. Downloading these applications to conventional systems will cause the status information to be lost. If a notification is not provided to the user and the application is downloaded, the new loading of the application (for example, in a transparent manner for the user) without the status information can cause confusion (for example, the user can pre-glue himself). What happened to my poker hand? "Or" Why do not I need to sign it again? "). The systems and methods of the preferred embodiments enable a application to report dynamically to the master controller of the state of the application (for example, the usage status information). The master controller is an entity responsible for prioritizing which applications to upload and download. The status information includes data that explains the resolution of removing the application from the memory in a way that the user can understand. The master controller communicates with a responsible entity to download and reload the applications to enable these operations to occur intelligently. However, the functionality of the preferred modes is distributed among several modules.It should be understood that one or more of the functionalities that are mentioned below can be integrated into fewer or more modules. During execution of the application code, the application will preferably notify the master control each time it changes state. The possible states generally include "inactive", which includes the situation where the application can be downloaded and loaded again if the user knows the difference, or "fully active condition", which introduces a situation where the application is maintaining a state of the user (for example, that is currently operating or is activated) and if it is downloaded causes the operations and / or the manifestation of the operations (for example, a user interface (U l) on a display device) appears in a different way to the user when it is reloaded. As will be described later, there are also variations in the fully active state condition, in which an application in fully active state and any supports do not support the status information. For example, when the application informs the master controller that it is in the fully active state condition, it has the ability to provide application-specific status data to the master controller. The master controller can store this data when the application is downloaded and then provide it back when the application is reloaded. The master controller can use the knowledge that the application is inactive or fully active when it decides which application to download. In addition, each time the application notifies its status to the master controller, it preferably provides an information object. This information object allows the master controller to intelligently communicate to the user the result of the download of an application. There is also the ability to present options (for example, a U with options that can be selected such as "OK", "cancel", etc.). The information object may include almost any means, including text, graphics, and / or sound. The master controller has the choice to allow the object options of the information to be presented or to force a simple acknowledgment of receipt. It should be understood by those skilled in the art that a designer of the application may select to decide whether something is in an inactive or fully active state. For example, a condition can have a defined state, but the state has a minimal effect so that the designer can decide to ignore it (memory, etc.) since storing the state is an unnecessary burden. Preferred embodiments are described with a master controller that decides whether to download an application based on the status communicated by an application. Therefore, several state distinctions can be viewed more objectively from the perspective of the master controller in their communications with the application to be downloaded, rather than by the perceptions of the user. In other words, it is the perception of the impact of the user's experience "in the opinion of" the application, whether the user agrees or disagrees. For example, when a common application to the master controller is inactive, the master controller can download the application because the application has communicated it and the download can be implemented if there is no significant interruption of the user experience. If the application is identical to the master controller that is in full compliance with a status record, the master controller similarly downloads the application in the acquired understanding of the application not to do so without degrading the user experience. . Also, when a single application that is in a fully active state, without a status record, then the master controller routes the steps to ensure the interruption to the user's experience, who is at least informed, since in this circumstance, the application has told him that the download It will degrade the user experience. This dependence on the judgment or resolution of the application provides flexibility in state problems.

Although the preferred embodiments of the description are described with a master controller that intelligently downloads applications based on the input of the application state, other modes may provide the master controller that decides the state and additional modalities may provide a mix of intelligence discernment shared status between the application and the master controller. A brief review will provide a map or guide for the following description. Because the preferred embodiments of the description can be understood in the context of a subscriber television system, an exemplary subscriber television system is described, followed by descriptions of the principal components included in the example head tip and in the example DHCT, as well as an example input device to enable the user to interact with the DHCT. Several example screen diagrams are then used to provide an illustration of a problem with the download or reload of applications according to the implementation. A couple of flowcharts are used to illustrate some example methods used by the preferred embodiments of the description to enable the download and intelligent re-loading of the information. These diagrams provide a perspective from an application or from a master controller. Finally, some programming interfaces of example applications (APIs) are described along with the corresponding data structure codes, making it possible for the APIs, the master controller and an application to communicate when they provide status information among other functions. However, the preferred embodiments of the description can be incorporated in many different ways and should not be construed as limited to the embodiments set forth in the present description, and instead these modalities are provided so that the description is complete and fully report the scope of the description to those skilled in the art. For example, preferred embodiments of the description provide the benefit of platforms with or without a hard disk, although the ability to store state information is facilitated when platforms using a hard disk are implemented. One implementation may cause the master controller of the preferred embodiments to save the state (e.g., by storing the status information) in the RAM memory or on a hard disk drive or other storage (e.g., such as a server in a network). ). The preferred embodiments of the description, in addition to providing an indication to the user of the effect of downloading an application, makes it possible to save the state in environments that generally can not support the fact of saving the state. For example, the preferred embodiments of the description make it possible for applications to keep the status even when operating in transmission only modes (eg, without 2-way communication) in DHCTs without hard drives, if the implementation uses the RAM. In addition, on some systems that include a hard disk drive, writing state information on the hard drive by applications can be problematic, due to design restrictions and other access limitations. Said systems can also benefit from the preferred embodiments of the description. Furthermore, none of the "examples" presented herein is intended to be limiting and are included as examples among many others contemplated and within the scope of the preferred embodiments of the description. Figure 1 is a block diagram illustrating an exemplary subscriber television system (STS) 10. In this example, the STS 10 includes a head tip 11, and a digital home communication terminal (DHCT) 16 that are connected by means of a communications network 18. It will be appreciated that the STS 10 shown in FIG. 1 is only illustrative and should not be construed as implying any limitation on the scope of the preferred embodiments of the description. For exampleAlthough single components (e.g., a head tip and a DHCT) are illustrated in Figure 1, the STS 10 may characterize a plurality of any of the illustrated components, it may be configured with alternative embodiments for any of the individual components or still with other additional components that have not been listed above. The subscriber television system also included within the scope of preferred embodiments of the disclosure, includes systems that do not use physical structure wiring for transmission, such as, but not limited to, satellite systems. A DHCT 16 is generally located in the residence or place of business of a user and can be an independent unit or integrated into another device, such as, for example, a television set, a personal computer or other display devices and a audio device. The DHCT 16 receives signals (video, audio and / or other data) from the head tip 11 through the network 18 and provides any inverse information to the head tip 11 through the network 18. In some analogous embodiments, a domestic communication terminal (HCT) is used, which is not a DHCT. Also, the functionality explained here can reside in personal computers, television sets, etc. The head tip 11 receives, among other data and / or content, program guide data from a program guide provider (not shown). The program guide data comprises information about the services that can be provided by means of the DHCT 16. The head tip 11 edits the program guide data and transmits the edited program guide data to the DHCT 16 by means of the network 18. The head tip 11 may include one or more server apparatuses (not shown), which provide video, audio and / or data to the client's devices such as the DHCT 16. The head tip 11 and the DHCT 16 cooperate to provide a user with television services by means of a television set (not shown). For example, television services may include broadcast television services, cable television services, premium category television services, video on demand (VOD) services and / or pay-per-view (PPV) services, among others. . Figure 2 illustrates an exemplary head tip 11 with selected components that are configured in accordance with one embodiment of the present disclosure. It should be understood that the head tip 11 shown in Figure 2 is illustrative only and should not be construed as implying any limitation on the scope of the preferred embodiments of the description. The head tip 11 receives content from a variety of service and content providers which can provide input in a variety of ways. The head tip 11 combines the content of different sources and distributes the content to the subscribers by means of the distribution systems of the network 18. The input signals can be transmitted from the sources to the head tip 11 by means of a variety of transmission mechanisms, including satellites (not shown), terrestrial communication transmitters and antennas (not shown). A digital network control system (DNCS) 223 provides administration, monitoring and / or control of network elements and transmission services provided to users. For example, a content provider such as a program guide information provider transmits the data for the television program guides through a network interface 209 to the DNCS 223 of the head tip 11, preferably using a protocol of File transparency (FTP). Although an implementation is shown to provide the program guide information through the DNCS 223, it should be understood that other content providers that provide additional services as being within the scope of the preferred embodiments are contemplated., as well as the variable routes through the head tip 11 that do not necessarily include the DNCS 223. The DNCS 223 includes the functionality that defines the relationships between the names of the channels of the list of the program guide data received from the program guide information provider and the numbered channels that are available through the DHCT 16. This functionality is used by the DNCS 223 to edit the program guide data to include channel numbers corresponding to the channel names of the channel. list. After the program guide data is edited by the DNCS 223, they are transmitted to the DHCT 16 preferably using a transmission file system (BFS) server 202. The BFS 202 server and its counterpart, a BFS client module. 343 in the DHCT 16, are part of a file transmission system. The BFS server 202 repeatedly sends the data through a network interface 206 to the DHCT 16 by means of a quadrature amplitude modulation (QAM) modem 203 for a period of time in a cyclic fashion, so that the DHCT 16 You can have access to the data that is necessary. Of course, other mechanisms and techniques can be used to transfer data to the DHCT 16.

A quadrature phase shift manipulation modem (QPSK) 207 is responsible for transporting the out-of-band IP datagram traffic (internet protocol) between the distribution head tip 11 and a DHCT 16. Data transmitted or received by the QPSK modem 207 can be routed by a head tip router 208. The head tip router 208 can be used to deliver upstream data to different server applications (not shown). Figure 3 is an illustration and block diagram for an exemplary DHCT 16 which is connected to a head tip 11 and a television set 341, according to one embodiment of the description. It should be understood that the DHCT 16 shown in Figure 3 is illustrative only and should not be construed as implying any limitation on the scope of the preferred embodiments of the description. For example, some of the functionality performed by the applications executed in the DHCT 16 (such as the MOD 363 application) may be performed instead, in whole or in part, on the head tip 11 and vice versa, and none in some modality The DHCT 16 preferably includes a communications interface 342 that receives signals (video, audio and / or other data) from the head tip 11 through the network 18 and can provide reverse information to the head tip 11 through the network 18. The DHCT 16 preferably includes one or more processors, such as the processor 344 (eg, a central processing unit or a digital signal processor), to control the operations of the DHCT 16, an output system 348 for operating the television screen and at least one tuner system 345 for tuning a particular television channel or frequency to present the content and for sending or receiving various types of data or content to and from the head 11. The DHCT 16 may include, in other modalities, multiple tuners to receive the content downloaded (or transmitted). The tuner system 345 makes it possible for the DHCT 16 to tune downstream transmissions, thereby allowing a user to receive a digital and / or analog content sent in the downlink transmission by means of the subscriber television system 10 (Figure 1) . The tuner system 345 includes, in one implementation, an out-of-band tuner for bi-directional QPSK data communication and one or more QAM tuners (in-band) for receiving television signals. Additionally, a receiver 346 receives the information generated on the outside, such as inputs or commands from the user of an input device, such as a remote control device 480 or other devices.

The DHCT 16 processes analog and / or digital transmission signals for storage in a storage device, such as a hard disk drive or optical disk (not shown) and / or for display on the television set 341. The DHCT 16 preferably includes a signal processing system 314 and a media machine 322. The components of the signal processing system 314 have the ability to demodulate the QAM, direct error correction and demultiplexing of MPEG transport streams. -2 and the analysis of elementary flows and elementary flows in packages. Additional components, not shown, may include an analog decoder and a compression machine to process a similar transmission signal and, in one implementation, convert it into compressed audio and video streams that are produced in accordance with the syntax and semantics of a Designated audio and video coding method, such as that specified by the MPEG-2 audior and the ISO MPEG-2 (International Organization for Standardization or ISO) standard video, among others. The signal processing system 314 produces compressed flows in packets and presents them as an entry for storage in the storage device, and in other implementations, such as an input to the media machine 322 for decompression by the video decompression machine (not shown) and an audio decompression machine (not shown) for displaying it on the television set 341 One skilled in the art will appreciate that the signal processing system 314 will preferably include other components not shown, including a memory, descriptors, samplers, digitizers (eg, analog-to-digital converters) and multiplexers, among other components. Furthermore, it should be understood that one or more of the components of the above list will interface with the processor 344 and / or the memory system 349 (and / or a dedicated memory for a particular component) to facilitate data transfer and / or processing of audio and / or video signals for deployment and / or storage. The memory 349, which can include a volatile memory and / or non-volatile memory, stores one or more programmed software applications referred to in the present description as applications, which contain instructions that can be executed by the processor 344 under the auspices of the operating system 353. Note that the application generally includes a part of the client and a counterpart of the server that cooperate to provide the full functionality of the application. The data required as input by an application is stored in the memory 349 and read by the processor 344 of the memory 349, as necessary, during the course of the execution of the application. The input data for an application may be data stored in the memory 349 by a secondary application or another source, either internal or external to the DHCT 16, or may be data that was created with the application at the time it was generated as a software application program. The data transmitted by the head tip 11 can be received by means of the communication interface 342, while the user input can be received from an input device by means of the receiver 346. The data generated by an application is stored in the memory 349 by the processor 344 during the course of the execution of the application. The availability, location and amount of data generated by an application for consumption by another application is generally communicated by means of messages through operating system services 353. An algorithm or executable program that corresponds to a component of the operating system or a component of the client platform or an application or respective parts thereof, may reside in memory 349, or in a local storage device (not shown) externally connected to or integrated within DHCT 16, and transferred in memory 349 to the execution. In a similar way, the data entry for an executable program may reside in the storage device and be transferred to the memory 349 for use by the executable program or algorithm. In addition, the output of data by an executable program may be written to the memory 349 by an algorithm or executable program and transferred to the storage device. In other modalities, the executable code is not transferred, instead, the functionality is carried out by other mechanisms. In the example DHCT 1 6 used in Figure 3, the memory 349 may include several applications, including the application of means on request (MOD) 363, email application 365, or a web browser application 366 , an I PG 394 application, a WatchTV 362 application, and a Pay-Per-View (PPV) application 364. It should be clear to one skilled in the art that these applications are not limiting and only serve as an example for the modes of the description . These applications and others provided by the subscriber television system operator, are higher level software entities in the network to provide services to the user. The memory 349 may also include a platform platform 356. The platform library 356 is a collection of useful utilities for the applications, such as the timer manager, the compression manager, a configuration manager, a hypertext markup language analyzer (HTML), a database administrator, a widget toolset, a string manager and / or other utilities (not shown). These applications have access to applications through application programming interfaces (APIs), as necessary, for each application that does not have to contain these utilities. Two components of the platform library 356 shown in FIG. 3 are a window manager 359 and a service application administrator (SAM) client 357. The window manager 359 includes a mechanism for implementing the sharing feature. screen regions and user input. The window manager 359 of the DHCT 16 is responsible for, as driven by one or more applications, implementing the creation, on-screen display and distribution of the limited screen resources of the DHCT. Allows multiple applications to share the screen by assigning ownership of screen regions or windows. Window manager 359 communicates with resource manager 367 to coordinate available resources (such as screen memory) between processes that consume different resources. These processes can be invoked directly or indirectly by one or more applications.

The SAM 357 client is a client component of a pair of client-server components, the server component (not shown) being located at the head tip 11, preferably in the DNCS 223 (Figure 2). A SAM 360 database (ie, structured data such as a database or data structure) that includes a data structure of services and a data structure of channels that are created and updated by the leading edge 11. In this case, the database will refer to a database, structured data or other data structures that are well known to those skilled in the art. The applications can also be downloaded to the memory 349 at the request of the SAM 357 client, generally in response to a request from the user with respect to a message from the head tip 11. An application which we refer to as a browser 355 can also be reside in the memory 349 to provide a navigation system for the products provided by the DHCT 16. For example, the navigator 355 is responsible for detecting the oppressions of important keys of the platform, such as an off button, a button guide, volume buttons up and down, the mute button, (all not shown), among others. The browser 355 thus communicates to the operating system 353 the status of the DHCT 16 (e.g., on or off). In one implementation, a unit of the apparatus 31 1 informs the operating system 353, when an oppression event of a key has been detected (for example, by means of an infrared remote control (IR), infrared keyboard, a keyboard, bus standard or universal (USB), etc.). The operating system 353 then notifies the application with the screen window "farther ahead" of the key oppression event. If the application has not registered an interest in that key oppression event, then it is passed to the next closest window. Because the window manager 359 allows the operating system 353 to have a window that is logically "more forward" but can be invisible to the user, the operating system 353 is aware of the key oppression event before passing the event to an application with a window. Many services can be defined using the same component of the application, with different parameters. Examples of services include, without limitation and in accordance with an implementation, presenting television programs (available through a WatchTV 362 application), pay-per-view events (available through a PPV364 application), digital music ( not shown), media on request (available through MOB application 363), games (available through a game application 361, where games can include poker, among others) and an interactive program guide (IPG) 394. In general, the identification of a service includes the identification of an executable application that provides the service together with a set of application-dependent parameters that indicate to the application the service that is to be provided. As an example, a service to present an HBO movie (a case of content) could be executed by the WatchTV 362 application, with a set of parameters that specify HBO. Similarly, a service presenting a poker game could be executed by the game application 361 with a set of parameters that specify poker. Each association of the application component (tune video) and a parameter component (HBO) represents a particular service that has an I.D. single service The SAM client 357 also interfaces with the resource manager 364 to control the resources of the DHCT 16. In one implementation, the applications can be downloaded into the memory 349 at the request of the SAM 357 client, generally in response to a request from the user or in response to a head tip message 11. Applications running on the DHCT 16 work with the browser 355, complying with several lines of instruction. First, the application uses the SAM 357 client for the provision, activation and suspension of services. Second, an application shares the resources of the DHCT 16 with other applications and is subject to the policies of the recovery management of the SAM 357 client, the operating system 353 and the DH CT 1 6. Third, an application handles situations in where resources are only available with the intervention of the browser 355. Fourth, when an application loses service authorization while providing a service, the application suspends the service through the SAM 357 client (browser 355 will reactivate an individual service application). ual when it becomes authorized later). Finally, a client of the application, or application are designed to not have access to certain user input keys reserved by the browser 355 (ie, the ignition, channel +/-, volume + / c, etc). The computation functionality of the DHCT 16 is provided by the operating system 353. Among other modules, the reactivator system 356 includes a resource manager 367 that provides an interface to the DHCT 16 resources such as, for example, the calculation of means. The operating system 353 further includes one or more propellers of the apparatus, such as a propeller of the apparatus 31 1 which operates in cooperation with the operating system 356 to provide operating instructions for the peripheral devices, such as the remote control apparatus. The operating system 356 also includes a memory manager 368 and a master controller 326, according to one embodiment of this description. The memory manager 368 will be explained further below. The 326 master controller is an entity that prioritizes the downloading and reloading of applications and, through cooperation with the SAM 357 client, enables the download and intelligent reloading of applications. The master controller 326 also dynamically receives the input of the applications that inform the master controller 326 of the state of the application (by means of the status information). The master controller 2326 is preferably in communication with an entity that understands which services are active. In one implementation, the entity that knows what services are active is the SAM 357 client, as explained above. Note that in some embodiments, the functionality of the master controller 326 may be integrated in the SAM 357 client, where the SAM 357 client is internal or external to the operating system 353. In alternative embodiments, the master controller may be a "in" layer. the top "of the operating system 356 in a manner very similar to the SAM 357 client. The operating system 353 also includes a BFS 343 client module that cooperates with a counterpart of the server to provide a directory of the modules, such as the applications . The directory in the modules is transmitted cyclically in the subscriber television system 10 (Fig. 1), and therefore, is readily available for DHCTs that need a particular application or other data. The DHCT 16 also includes one or more wired or wireless interfaces, also referred to as communication ports 374, for receiving and / or transmitting data to other devices. For example, the DHCT 16 can characterize a USB (Universal Serial Bus), Ethernet (for connection to a computer), IEEE-1394 (for connection to content devices in an entertainment center) and serial ports and / or parallel. The user inputs may be, for example, provided by an input device that includes a computer or transmitter with buttons or keys (or the input may be provided by means of buttons or keys by means of the Terminal), or by a device manual remote control 480 or a keyboard that includes user-operated buttons and even an audio input (for example, activated by voice), among others. An example of the remote control device 480 for providing the input to the DHCT 16 (Flg.7) is illustrated in Fig. 4. The example remote control device 480 includes a selection button 487 for making the selections presented in the display of screen and navigation buttons 485 to navigate within a particular screen display. The guide button 497 can be used to access a television program guide, such as, for example, an IPG screen. Buttons "A" 488, "B" 489, and "C" 490 may correspond to certain functions defined by the application that have a corresponding "A", "B" or "C" symbol in a user graphics interface ( GUI) presented on the screen device. Many alternative methods can be used to provide the user input including a remote control device with different buttons and / or different distributions, a keyboard device, a voice activated device, etc. The embodiments of the description described herein are not limited by the type of devices used to provide the user's input. The following screen diagrams will be used to illustrate an example implementation that uses applications to present the requested services and to show how the preferred embodiments of the present description can be used to provide integral operations during download and / or reload. of the applications to present these services. When an application that is currently running can not receive the memory it requires or is invoked by the user a new application that can not be loaded due to limited memory, therefore, many systems download all applications or download of arbitrarily, it can cause a problem that is determining which application to download. For example, if an application that is in fully active state is downloaded, the user will come to know that it has been downloaded because he or she reactivates that application (for example, through the tuning channel or the service portal). , the application will be loaded, but its rge in its initial state, which may confuse the user. For example, suppose a user is in the middle of a poker game, as illustrated by the example poker game screen 500 shown in Fig. 5. As an example, the game of poker can be invoked by a user through an interactive program guide (I PG) that has access to the service guide 600 (Fig. 6). As shown, the user is presented with a 502 poker hand and the 504 poker chips. The 506 automatic menu asks the user if he or she would like to (set bets) (ie, invest more money to support the current hand of poker 502). The user is presented with navigation arrow icons 508 which, in one implementation, suggest to the user that he or she may select the navigation arrows 485 (Fig. 4) on the remote control device 489 (Fig. 4) and do not "place bets" (button icon "no" 510) or "set bets" (button icon "yes" 512). Similarly, the user is presented with a "C" button icon 514 which suggests to the user that he or she may return to the service guide (such as the example service guide 600 shown in Fig. 6). ) by selecting a similarly marked button ("C" button 490 (Fig. 4)), on the remote control device 480. Assume that the user, who now has the poker chips on the line and a poker hand "activa" 502 decides to see the latest news by accessing the web of the world network. Before deciding whether to place the bets or not (ie, before responding to menu 506) the user selects the "C" button 490 (Fig. 4) as suggested by the service button button 514 to invoke 600 service guide, as shown in Fig. 6, which presents the user the service choices. Example service guide 600 provides a plurality of service 656, including PPE 657, VO D 658, music 659, software 660, games 665 and web access 662. The user can navigate to the different selections and select the desired service using the remote control device 480 (Fig. 4) as suggested by the navigation arrow icons 685 and the radio button 687. Note that there is a reduced portion 663 of the 600 display available for a movie network ucida of a current program. Although it is shown as a half screen, other settings, such as a quarter of a screen, can be used. If the poker game is in an "overlay" service then you can place other services in the reduced portion 663 (eg, WatchTV services). But the poker game itself can not be placed in the reduced portion 633. If the poker game is in a "channel-based" service, then it can be placed in the reduced portion 663. In a modality, if a service is active, can not be downloaded. For example, if the channel-based service is active (for example, visible in the reduced portion 663) and the service guide is active (for example, visible using the rest of the screen), then none it can be downloaded. A function key (for example a button icon) can be provided in some overlayer systems that make it possible to remove the reduced portion 663 and if it is implemented, deactivates the channel-based service and activates the removal of the portion reduced 663. In one embodiment, the poker game is channel-based and can be displayed in the reduced portion 663. The user can press a button corresponding to the button icon (not shown) that replaces the web screen with a full screen and then the poker game can be downloaded. Then at the moment when the user invokes the poker game again in the reduced portion 663, the poker game will have an unfolded screen corresponding to its initial state. In some situations, the initial state may not be easily sighted simply by invoking a screen in the reduced portion 663, if the reduced portion only shows a logo corresponding to the service (for example, if the screen is not programmed to be displayed in the reduced portion). 663). Continuing with the example of invoking web access, at the time of selecting the web access icon 662, the user is presented with an example screen 700 that provides the user with an HTML web page, through an application of the web search engine 366 (Fig. 3), which provides a series of icons for the categories from which you are going to make a selection, including the news icon 702, the sports icon 704, the market information icon 706 , the weather state icon 708 and the other information icon 710 (for example, that provides entertainment information, horoscopes, etc.). The example screen 700 also presents the user the button icons A to C (712) which corresponds to the functionality that can be invoked by a user using buttons marked similarly in the remote control device 480 (Fig. 4) . From this example screen 700, the user can select the news icon 702 to get the latest news.

Underlying these interactive user services are the D HCT dynamic mechanisms that make it possible for one or more applications to be loaded. These applications can be loaded upon request and not only in any previously determined order. A result of this flexibility is that when the memory 349 (Fig. 3) of DH CT 1 6 (Fig. 4) becomes complete and no additional applications can be loaded, an application is downloaded. In some modalities, it can be requested that one or more of the applications renounce non-mandatory memory. In a similar way, because the functionality and actions of the individual applications loaded in the memory 349 can not be known before the download of the, it is possible that during the execution of an application, the memory 346 arrives to be complete. For example, many applications are "data driven" and the application and operating system do not know in advance how much memory will be required until external data is accessed. In this case, you can choose an application and download it from D HCT 1 6. Generally, whenever an application is downloaded, its "disappearance" is transparent to the user. The user is not notified and does not pass the application by any mechanism of discharge criteria, in the sense of "ignore your case", as to why it should not be downloaded. The result is that, in conventional systems, applications that have specific user status information will be downloaded and the user's specific status will be lost. When the user activates the application again, the application will be reloaded. It will start with a clean application, which often leaves the user confused about what has happened. As a lesson and continuing with the example illustrated in figures 5 through 7, let's say that the user registers the poker game as shown in Fig. 5 after registering the latest news. Fig. 8 is an example screen diagram of an example 800 poker game screen displayed at the time of service initiation. As shown, the user is presented with an introduction menu 802 which advises the user to select the number of players from the list of player numbers 804 preferably using the buttons on the remote control device 480 (Fig. 4) as suggested by the navigation arrow icons 806 and the icon of the 808 selection button. Considering the difference between this screen 800 and the screen 600 (Fig. 6) from which the user has launched a search of the news Currently, it is likely that the user is confused by this 800 screen as it seems to be warning the user to answer questions reminiscent of the initial user interface screen (not shown), which was presented at the beginning of the game of poker shown in Flg .6. The user no longer has the hand that he or she played at the end, nor the poker chips accumulated during the last game. In other words, the specific information of the user's status has been lost. Confusion can be created in this implementation for one or more reasons. For example, the application responsible for the poker game (for example, game application 361, Fig. 3) may have been arbitrarily downloaded to make room in memory 349 (Fig. 3) for the application responsible for accessing the game. web (for example, the web search application 366 Fig. 3). In addition, a 361 game application (which provides the poker game service) may have been a fully active state application and the state was not saved. The applications that are executed in the DHCT 16 (Fig. 3) can be generally rupadas in two categories. We can refer to a category that refers to those that are inactive, for example, the application can be downloaded and loaded again with little or no distinction between the screen or the apparent operation between the old and new content example. We can refer to another category as completely active. For example, if the application is downloaded and loaded again, the case of new content will appear to operate in a different state than the case of old content. Another example of the inacativa application is a client application for a data impulse server. The client's application is mainly acting on the data received from the network. However, a certain application allows a user to select a category of data, then the application will become fully active. An electronic mail application is another example of a fully active application. For example, the user may be required to provide a username and password to access the mail. Additionally, the user may have selected specific email messages on the screen. Some application was downloaded and loaded again, the specific state of the user will be lost. The user will be required to provide their username and password again, in addition to selecting their email messages one more time. An application can transit between the fully active and inactive state in the type of execution depending on the activity and / or the requests. The preferred embodiments of the description solve problems of loss of status, among other problems, according to several generalized goals: (1) ensure that the application status is not lost when the application is downloaded; and (2) inform the user of the consequences of downloading an application if an application must be downloaded. There are several underlying requirements that utilize the preferred embodiments of the present disclosure to accomplish these goals: (i) if the status will be lost, the applications should not be downloaded without notifying the user; (ii) if the status will be lost, the applications should not be downloaded without receiving the user's approval; However, if the memory is absolutely necessary, then the user's approval can be replaced by a notification; (iii) the applications are provided with a mechanism to store the state information when they are downloaded; (iv) the applications have a mechanism to request information from the previously stored state when they are loaded; (v) the applications have the ability to review the status information stored by a chronological layer; (vi) the applications have the ability to review the stored state information for version compatibility; and (vii) when an application is selected to download it, the applications that do not lose the state of the user are preferably selected on the applications that lose the state of the user. Note that in some modalities, the status data may or may not be stored in the new DHCT load. Also, if necessary, the stored data can be discarded.

In the preferred embodiments, the master controller 326 (Fig. 3) allows one or more applications to notify you when there is a transition from the application state from inactive to fully active, or from fully active to inactive. Therefore, referring to the flow diagram of Fig. 9A, an application preferably executes a code as part of its standard operation (step 91 0). In step 91 5, the application receives the indication of an event (for example, a signal corresponding to a key oppression event). Certain events or "actions" can cause a state change to occur. For example, a poker application or the 361 game application (for example, running poker) can be changed from inactive to fully active when the user is on the main screen (not shown) and selects "deal the cards" for the first time. Shuffled cards and dealt cards are now part of the user's status. As another example, an email application 365 (Fig. 3) can change from fully active to inactive when the user selects "ignore" or "change to another user". In this case, user-specific messages are not displayed and the email is in the same state as when it started execution. In step 920 the application determines whether the event will cause the application to become in a completely dormant or inactive state. For example, suppose a data transmission service that presents a default page (default) when "launching" the local climatological page that includes information regarding the local climate. When the user is presented to the user for the first time the local weather page, the application is considered inactive, since the application in this example always launches the local weather page. When the user switches to another page (for example, a local movie page that presents times and locations of movies for movies played locally) the application is now in a fully active state. If no state changes occur, the application continues with the operation code (step 910). If a change occurs in the state, then step 913 includes the application providing information to the master controller 326 (Fig. 3). Then the application continues with the operation code (step 910). Fig. 9B is a diagram of the example application programming interface (API) 490 that is preferably invoked by an application each time there are changes in the state of the application from inactive to fully active or from fully active to inactive. This API 940 enables the master 326 controller to make informed decisions regarding application download requests (for example, requests through the SAM 357 client, Fig. 3), and presents the user with options and results of the download of an app. Note that "uio" is a pointer to a Ctl-Unloadlnfo structure where the structure is divided according to the code of structures 942 described in Fig. 9C. Note that the structure code 942 is for an example implementation and other implementations that are within the scope of the preferred embodiments of the present disclosure are contemplated with a variation in the code. For example, structure code 942 supports ASCII strings, but other data structures that support graphics, sound and / or almost any other type of user interaction can be used. Furthermore, although it is described using the programming language "C", other programming languages may be used to provide the corresponding functionality and are contemplated as being within the scope of the preferred embodiments of the present disclosure. Referring to Fig. 9C, line 944 is a standard definition C for a structure. The structure is called "struct Ctl_Unloadlnfo". Line 946 indicates that the first field in that structure contains a pointer for data that constant characters (strings). This field contains an ASCII string. Line 948 indicates that the second field of the structure contains a pointer for constant character data. This contains an ASCII string. Line 950 indicates that the third field of the structure contains a pointer for constant character data. This string contains an ASCII string. If unloadMeStr or unloadStopStr are NULL, the option is not displayed. Line 952 indicates that the final parameter is Bolean for example true or false) and also indicates if the application has a state to save it (which can be restored if the application is loaded again). Line 954 finishes the definition of the structure and informs a compiler about which abbreviated associated names to use. When the application notifies the master controller 326 (Fig. 3) that it is in a fully active state, the download information can be provided. The download information preferably provides one or more of the following functionalities: 1. It can be used to explain to the user the effect of downloading the application. This is what we refer to as the "Explanation of Download Information." 2. You can provide selections that are presented to the user. These selections can give the user the ability to specify whether or not the action should be performed, depending on whether the results explained are desirable or not. This is what we refer to as the "Download Information Selections". 3. It can inform the 326 master controller whether or not the application is able to create a record of the status information that the master 326 controller stores when the application is downloaded. When the application is reloaded, this status record is re-provided to the application. This information of the state is what we refer to as the "State Registry". This state information is anything that the application designer decides is the state information unless it is sent in another way. In the example of the poker game, the state information may include the number of players, cards currently dealt, the order of the remaining cards in the bank, the amounts of poker chips, etc. The status information will preferably not include "application executables" or a specific memory address. In the preferred embodiments, the application operates under a premise that is the operating system 353 (figure 3) that has downloaded its code. Note that the download information may or may not be presented to the user, depending on the status of the application. Figure 1AA provides a flowchart of an example method used by the master controller 326 (Figure 3) to prioritize the download of an application, according to one embodiment of the present disclosure. Step 1 002 includes a download request. Download solitude may occur in response to one or more events, such as a request (from the user or otherwise) to activate an application that consumes more memory (contiguous or otherwise) to which it is available . The operating system 353 (FIG. 3) preferably includes a memory manager 368 (FIG. 3). The memory manager 368 can determine the amount of available memory and can connect a download request to the master controller 326 (FIG. 3) when determining that an inadequate memory is available to load the requested application. In other modalities, a memory manager can operate "at the top" of the process. That is, the memory manager "is not warned" of the process of downloading the application and simply reports a failure (for example, improper memory) in response to a memory request. An entity that requested the memory would be responsible for the process of downloading the applications. When the download process is complete, the request for the memory manager will be repeated. Regulating the previous explanation of the first mode of the master controller, in response to the download request, the master controller 326 identifies the services that are active and / or which services are not active (step 1 003) and "signals" the corresponding inactive applications as candidates for download (step 1 004). Preferably, this identification is made through the cooperation of the SAM 357 client (figure 3). Step 1 006 i nclude determining if any of the indicated applications is inactive. The master controller 326 (figure 3) recognizes that the inactive application can be downloaded without affecting the user experience (different perhaps to the load time). If a designated application is inactive, the master controller 326 performs (through cooperation with the SAM 357 client, figure 3) a download of that application (step 1 008). If none of the indicated applications is inactive, then step 1 01 0 includes determining whether any of the indicated applications are in a fully active state and support a status register. The download information supported by the application informs the 326 master controller if the application supports a status register. If any of the indicated applications are fully active and support a status register, step 1 01 8 includes performing the download (deletion) of the application (step 1 01 8). Note that the entire download information process listed above (for example, from 1 to 3) is preferably not used at this stage, only the downloading of application status information, except that when it is reloaded, the application will recover its status record (if necessary) and operate as if it had never been downloaded. If any of the indicated applications are not fully active and do not support a status register, the operations proceed to step 1022, which is described further below. In one embodiment, master controller 326 (FIG. 3) receives the status register of the application in what we refer to as the "impulse model" method or mechanism. In the "impulse model" mechanism, an application invokes an API when its state changes. Figure 10B is a flow chart illustrating this mechanism from the perspective of the master controller 326. In step 1011, the master controller 326 (Figure 3) waits for an indication of a state change of the application, which is preferably to receive a status record. In response to receiving the status register, the master controller 326 (FIG. 3) makes an internal request to determine if the status register is too large (step 1014), size calibrated in absolute or relative terms. For example, the size could be a configuration parameter received from the head tip 11 (figure 2) or an absolute value (default) "default" if no configuration parameter is received. If the status register is not too large, the master controller 326 stores the status register (step 1016) (or replaces an existing status register) and then the operations in step 1011 continue. If an application provides a status record that the master controller 326 (FIG. 3) considers that it is too large, the master controller 326 (FIG. 3) can discard the status register (step 1020) and the operations proceed to step 1011. When discarding the information, the master controller 326 can provide notification to the application that there is no status information for the application. Observe that the different steps of the aforementioned method can be implemented. For example, using additional data configured by the system operator, it may be possible to create a priority method that allows some applications to be downloaded in a fully active state before inactive applications. This may prove useful in circumstances where, for example, the MSO (media services organization) simply wanted an application to remain in the DHCT 16 (Figure 3) as long as possible, thus providing quick access if the application is completely active or is inactive or not. You can create priority levels. For example, all N-level applications would be considered for download before any level (N-1) applications. Within a single level, the inacative applications would be downloaded before the fully active applications. Another variation to the methodology described in association with Figure 10A, comprises receiving or actively requesting the status register (step 1012) of the master controller 326 (Figure 3), to which we can refer generically as a "model" method of extraction ". In other words, the master controller 326 extracts the status information from the application. Fig. 10C is a programming diagram illustrating an example API 1040 that enables an application to provide the status information to the master controller 326 (Fig. 3). An application makes this invocation when it is finishing the operation (for example, when it is close to being downloaded from memory). The API 1040 instructs the master controller 326 to associate the status registration information that the application provides with the name of the application. Note that "appName" is a unique module name and Ctl_StateRecord is a data structure, the latter being defined according to the structure code 1042 of Figure 10D.

Referring to Figure 10D, line 1046 indicates a data structure that is used to store arbitrary data, with the imposition that the data includes a version to enable an application to determine whether any saved state is compatible with the version of the application that is being loaded. Line 1048 indicates that a field is declared for the version. Lines 1050 and 1052 indicate that two fields hold private data. On line 1050, the first field is to contain the number of bytes of private data that exists. On line 1052, the second field is an adaptation of bytes of the same size specified above. This adaptation of bytes is private data, which is understood to include a collection of data that is only understood by the application (and therefore, is "private" for that application). For example, in a data transmission service as described above, the application may want to save the previously selected page (a non-default page, such as the local movie page) as the state. Several mechanisms can be used to implement the saving of the page as the state, such as using a unique number to reference the page or an ASCII string with the page name, among others. Suppose that the ASCII string method mentioned above is used. If the user selected "play movie," then the field on line 1050 would contain 15 (for example, the number of characters in the "movie playback" string plus a NULL terminator). This assumes that a string of a programming language style "C", in the understanding that the string can be represented using other languages and programming formats. Continuing the example, the "private data" on line 1052 are the individual bytes that comprise the string "movie playback". Because the programming language "C" generally prohibits a strictly variable size adaptation, the syntax "privateData [1]" is included with a comment to indicate that more than 1 byte of private data is likely to be used. The end of the structure is represented by line 1054. A state register includes data of an appropriate size for the typical memory availability in a DHCT 16 (Figure 3). The status register preferably stores the status of the application. The internal state registration format is private for the application. Preferably, the master controller 326 (FIG. 3) supports a version of the application that is attached to the status register. This ensures that if a different version of the application is loaded, the application does not retrieve an incompatible state record (for example, one that does not understand). When a termination request is received, the application constructs its data from the private state registry, and provides this data to the master controller 326. Similarly, an application that supports status register requests from the master 326 controller when it begins execution to retrieve a status record from a previous execution. Master controller 326 automatically provides the time and date of state registration creation (not shown). Because the Application Identifier (App_I D) may not be constant at multiple loads, the application preferably uses its unique module name to store and retrieve the status record. Although this is optimal when all applications support a state register, some applications may be unable to "compress" their state into a state register of a size that can be handled. For this reason, some applications may intentionally not support a status record. The status register can be stored using the operating system register 353 (Fig. 3). The registry is a mechanism provided by the operating system 353 which makes it possible for the information to be stored in a hierarchical manner. This information is persistent, even when the applications are downloaded. For example, a branch of the registry called "AppState" can be created and entries for each application can be associated with this branch, such as the "SuperPoker" entry. Finally, associated with "Appstate / SuperPoker" can be the status information that is provided to the ctl_SetStateRecord API 1040 (Figure 10C). Note that the state register can be stored in a non-volatile memory, a local hard drive, transmitted to the head tip 11 (figure 2) for storage, and / or other mechanisms that allow persistent storage. Figure 10E is a programming diagram illustrating an example of the API 1044 that enables an application to retrieve the status information of the master controller 326 (Figure 3). API 1044 distributes the memory on behalf of the application and returns the status information associated with the specified application name. Referring to the example of the data transmission service described above, the application generally does not know if it needs 15 bytes to recover the state or 200 bytes. Because the status information may not be of a known size, this API 1044 returns a copy of the complete data. This is in contrast to, although it does not prevent in some modalities, the copying of the data in memory previously distributed invoking the application. Because the invocation of the application generally does not know the appropriate size, the return of a copy facilitates memory management and clearly defines ownership of the data. An application preferably causes this API to be invoked when the execution is starting. If the state register exists for the specified application name, then the status information corresponding to the "stateRecord" is preferably returned and it is the responsibility of the application invoking it to release the memory that is no longer needed, (for example, when it is done with the data). Additionally, the invocation of the application should review the version number for compatibility. Once a state record is returned, future invocations to "GetStateRecord" with the name "AppName" result in a NULL parameter for the stateRecord, until the information is extracted from the master controller database and provided to the application. The master 326 controller can also download status records that have reached an expiration age, such as one day. The expiration age can be configured by the MSO or programmed in the head tip 11 (figure 2), in the absence of a parameter, you can build a default option in the code as suggested above. Master 326 controller automatically purges old records. However, in some modalities, an application may also encode the time / date information into its own status information and perform more granular temporal conditions. For example, an application may decide to use a shorter duration "for the state" than the master controller 326 encoding the time in the status register and then, upon receiving back the status record when it is loaded again, making a decision about whether to ignore the state register even if it still exists. 10 If it is determined that the indicated applications are of full status, but do not support a status register (in step 1010), then the master controller 326 (figure 3) may use an Explanation of Download Information and Download Information Options as described above and inform the user of the result of the application download. The user may be allowed to select between download information options (step 1022). Figure 11 is a screen diagram illustrating a Example user information menu 1100 that may be presented to the user in response to the user's search to invoke another service that creates a memory download problem, according to one embodiment of the present disclosure. For example, the information menu 1. 5 of the example user 1100 may be presented in response to the selection of the user of the Web access service 662 (figure 6) while on the service guidance screen 600 (figure 6) and while operating a game of poker. The user information menu 1100 may include several elements. The action chain 1102a, b specifies the action taken by the user or any other event that triggered the download of the application. In this case, the detonation action was the selection of the user of the access service to the Web 662, and therefore, the chain of action 1102a, b is, "Activating Access to the Web". Other chains of example actions may include, but are not limited to, "Activate Movies on Demand", "New Load Decoder", "Accessing Address Book", among others. Another element of the user information menu 1100 includes the Explanation of Download Information (Ul) 1104. As described above, the explanation of download information is provided by the application and used by the master controller 326 (figure 3) to explain to the user the result of downloading the application. The final text explanation presented to the user is the result of a text string provided in Explanation Ul 1104 and a substitution. In an implementation, any text within Explanation Ul 1104 that contains "% 1" (percent sign followed immediately by the number one) is replaced with the action chain 1102a, b. For example, the Ul 1104 explanation of the poker application may include:% 1 will cause your poker hand to be discarded. Continue% 1? If the load of the application of the search engine of the Web 366 (Figure 3) triggers the application to download the game application 361 (Figure 3) that is operating the poker game, the action chain 1102a, b would be "Activating Web Access". The final message displayed on the screen would be: The activation of access to the Web will cause your poker hand to be discarded. Do you continue to activate access to the Web ?. The master controller 326 (FIG. 3) may display the Ul 1104 explanation together with any selections of download information (Ul) 1106 at the same time. Ul 1106 selections include downloading the application and not downloading the application. Same as the explanation Ul 1104, the message displayed in the Ul 1106 selections are the result of a text substitution. The action chain 1102c, d is replaced whenever the Ul selection 1106 includes "% 1". For example, "Yes, download my poker game and% 1", "No, keep the poker hand and not% 1", it becomes after the substitution in "Yes, download my poker hand and activate access to the Web "and" No, keep my poker hand and do not activate access to the Web ", respectively. If the user selects the download option, the application of games that execute the poker will receive instructions to complete. If the "no download" operation is selected, the game application 361 will receive instructions to terminate and the application requesting the memory will be told that the request failed and should not be attempted again. If a user selects the "do not download" option, the memory reclamation process will preferably end and the process will not continue in the next application. In other modalities, the process will continue for another application. Observe that the modalities described above suppose the download of a single application at a moment, so that an application is either inactive or fully active with a status record, or fully active without status registration. In some modalities, there will be more than one inactive application, or no active application, but more than one fully active application among other combinations, which leads to additional priority questions for downloading. The criteria for prioritization may vary based on implementation. For example, priority schemes can be used, including downloading the application that consumes the largest amount of memory, downloading the application that has not been used for the longest period of time, downloading based on the priority assigned by the MSO, the download by assigned levels as described above, or the download of all applications from memory, among others. In addition, although described in the context of downloading the memory 349 (FIG. 3), one skilled in the art will also understand based on the present disclosure, that the preferred modalities can also be extended to prioritize the applications and other data in the storage devices (for example, hard disk drives, etc.). The blocks of the flow diagrams of Figures 9A and 1 0A and 1 0B should be understood as representing modules, segments or portions of the code, which includes one or more executable instructions to implement specific logical functions or steps in the process and alternate implementations are included within the scope of the preferred embodiment of the present disclosure, in which the functions may be executed outside the order shown or explained, including in a substantially concurrent manner or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present disclosure.

The master controller 326 (Figure 3) can be implemented in hardware, software, fi rmware or a combination thereof. In the preferred embodiments, the master controller 326 is implemented in the software or firmware which is stored in a memory and which is executed by an appropriate instruction execution system. If implemented in the hardware, as in the alternative mode, the master controller 326 will be implemented with any or a combination of the following technologies, in which all are well known in the art: a separate logical system that has logical regu lations to implement logical functions at the time of the data signals, an application-specific inte grated area (AS IC) that has logical regu lation of appropriate combinations, a programmable regulation adaptation (PGA) ), an adaptation of programmable field regulation (FPGA), etc. The master controller 326, which comprises an ordered list of executable instructions for implementing logic functions, may be incorporated into any computer-readable medium to be used by or in connection with an instruction, device or device execution system, such as a computer. computer-based system, systems that contain a processor or other system that can execute the instructions of the instruction, device or device execution system and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can contain, store, communicate, propagate and transport the program to be used in connection with the system, apparatus or instruction execution device. . The computer-readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, apparatus or device or means of propagation. The most specific examples (a list that is not exhaustive) of the computer-readable medium would include the following: an electrical (electronic) connection that has one or more cables, a laptop (magnetic) disk, a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), a programmable read-only memory that can be erased (EPROM) or instant (electronic) memory, an optical fi ber (optical) and a read-only memory of a compact disc (CD ROM) (optical). Note that the computer-readable medium can be a paper or other suitable medium on which the program is printed, since the program can be captured electronically, for example, by optical scanning of the paper or other medium, which then compiled interpreted or processed in an appropriate manner if necessary, and then stored in a computer memory. It should be emphasized that the previously described modalities of the present disclosure, particularly, any "preferred embodiments" are only possible examples of implementations that establish only a clear understanding of the principles of the descriptions. Many variations and modifications can be made to the above-described embodiments of the description without departing substantially from the spirit of the principles of the description. All such modifications and variations are intended to be included in the present disclosure within the scope of the description and the present description and protected by the following claims.

Claims (28)

1. CLAIMS 1. A method for memory management, the method having the steps of: receiving an indication of an application status of a plurality of applications in memory; and determining which of the plurality of applications to select to effect the removal of the memory based on the received indication. The method as described in claim 1, characterized in that the step of receiving an indication of the state of the application includes receiving at least one indication of an inactive state, a fully active status indication with a status register. , and an indication of a fully active state without status registration. 3. The method as described in claim 2, characterized in that the step of receiving an indication of an inactive state includes receiving an indication of a state indicating that a user would not perceive a significant difference between the presentation associated with one of the plurality of applications before and after the removal of memory and the new load to memory. The method as described in claim 2, characterized in that the step of receiving a fully active status indication with a status register includes receiving an indication of a state indicating that a user would not perceive an important difference between a presentation associated with one of the plurality of applications before and after memory removal, and the new load to memory because the state is stored in the status register. The method as described in claim 4, which further includes the steps of effecting the removal of the application with a fully active state with a status register and saving the status record. 6. The method as described in claim 5, which further includes, in response to activation of the user of the deleted application, restoring the deleted application with the saved status register. The method as described in claim 2, characterized in that the step of receiving an indication of a fully active state without status state registration includes receiving an indication of a state indicating that a user would perceive a difference between a presentation associated with one of the plurality of applications before and after the removal of memory and the new loading into memory. The method as described in claim 7, characterized in that the step of receiving an indication of a fully active state status without status registration includes receiving a download information, wherein the download information includes at least one of an explanation of the download information, and selections of download information. The method as described in claim 1, characterized in that the determination step includes the steps of determining an application with an inactive state that is removed before an application with a fully active state with a status register, and that a fully active state with a status record is removed before a fully active state without status registration. The method as described in claim 1, which further includes the steps of effecting the deletion of an application with an inactive state before the deletion of an application with an inactive state with a status register and effecting the Delete an application with a fully active state with a status record before deleting an application with a fully active state without status registration. 11. A method as set forth in claim 1, which further includes the step of providing an explanation to a user when it is to be deleted from memory an application includes a fully active state without status record wherein the explanation informs the user of the result of deleting the application. 12. A method of memory management, the method comprising the steps of: receiving an indication that memory space is necessary in memory; receiving an indication of an application status of a plurality of applications in the memory, wherein the step of receiving an indication of the state of the application includes receiving at least one of an inactive status indication, an indication of a fully active state with a status record and a fully active status indication without status registration; determining which of the plurality of applications is selected to effect the elimination of the memory based on the received indication, characterized in that the determination step includes the steps of determining an application with an inactive state that is eliminated before an application with a state fully active with a status record, and that a fully active state with a status record is removed before a fully active state without status registration; and perform the removal of an application with an inactive state before the application of an application with a fully active state with a status record, and effect the removal of an application with a fully active state with a status record before the deletion of an application with a fully active state without state registration. 3. A method for supporting memory administration, the method comprising the steps of: receiving an indication of a user's solitude for a service; in response to the reception of the indication, it will receive an indication that a memory space is needed beyond what is available; provide an explanation that informs a user of the effect of imaging an application of memory to provide a requested service. 14. The method as recited in claim 1 3, which further includes the step of providing the user with selections to enable the user to determine whether to allow the provision of the required service. The method as described in claim 13, which further includes the step of retaining the application in memory in response to the user selection of a selection associated with terminating the request by the service. The method as described in claim 13, which further includes the step of effecting the deletion of the application from the memory in response to the selection of the user of a selection associated with proceeding with the service request. . The method as described in claim 13, characterized in that the effect of removing the application includes losing the state of the application. 18. A system for managing the memory comprising the system: a memory with logic; and a processor configured with logic to receive an indication of the state of application of a plurality of applications in memory, wherein the processor is further configured with logic to determine which of the plurality of applications is selected to effect the elimination of the memory based on the received indication. The system as described in claim 18, characterized in that an indication of the state of the application includes an indication of at least one of an inactive state, a fully active state with a status register, and a state completely active without state registration. 20. The system as described in claim 1, characterized in that the inactive state i includes a state where a user would not perceive a significant difference between a presentation associated with one of the plurality of applications prior to the elimination of the memory and after the new memory load. twenty-one . The system as described in claim 1 9, characterized in that the fully active state with a state register includes a state where a user would not perceive an important difference between a presentation associated with one of the plurality of applications before memory removal and after the new memory load because the status in the status register is saved. 22. The system as described in claim 21, characterized in that the processor is further configured with logic to effect the removal of the application with a fully active state with a status register and save the status register. 23. The system as described in claim 22, characterized in that the processor is also configured with the logic to, in response to the activation of the user of the deleted application, restore the deleted application with the registration of Been saved. The system as described in claim 1, characterized in that the fully active state without state registration includes a state where a user would perceive a difference between a presentation associated with one of the plurality of applications prior to removal of the memory and after the new memory load. 25. The system as described in claim 24, characterized in that the processor is further configured with the logic to provide the download information, characterized in that the download information includes at least one of an explanation of download information and selections of download information. The system as described in claim 18, characterized in that the processor is further configured with logic to determine that an application with an inactive state is deleted before an application with a fully active state with a status register, and that a fully active state with a state record is removed before a fully active state without state registration. The system as described in claim 18, characterized in that the processor is further configured with the logic to effect the removal of an application with an inactive state before the removal of an application with a fully active state with a record state, where the processor is further configured with the logic to effect the removal of an application with a fully active state with a status register before deleting an application with a fully active state if n state register. 28. The system as described in claim 18, characterized in that the processor is further configured with logic to provide an explanation to the user when a application that is to be mined from the memory includes a fully active state without state records, where the explanation i nforma to the user the result of removing the application.