MXPA06003875A

MXPA06003875A - Modelo de ciclo de vida java para discos-bd.

Info

Publication number: MXPA06003875A
Application number: MXPA06003875A
Authority: MX
Inventors: Declan Patrick Kelly
Original assignee: Koninkl Philips Electronics Nv
Priority date: 2003-10-10
Filing date: 2004-09-30
Publication date: 2006-07-03
Also published as: CN101197175A; AU2004280492A1; RU2006115578A; CA2541929A1; US20070038989A1; RU2009104548A; WO2005036383A3; BRPI0415110A; CN1864135A; JP2007508612A; AR046101A1; EP1890231A2; KR20060135621A; WO2005036383A2; EP1673691A2; RU2369898C2; SG136965A1; TW200517950A; EP1890231A3

Abstract

Un portador de almacenamiento optico es cargado con aplicaciones implementadas como objetos Java que permite servicios interactivos, por ejemplo, juegos, reproduccion interactiva de contenido A/V, navegacion en la Web. Cada objeto Java incluye al menos tres metodos que establecen la aplicacion en un estado inactivo, un estado pausado o un estado activo. El portador tambien es cargado con una aplicacion del cargador de sistema que incluye un metodo principal. La aplicacion del cargador de sistema controla los respectivos ciclos de vida de todos los objetos Java presentes en el portador y controla los respectivos metodos de los objetos Java. La aplicacion del cargador de sistema solamente permite que se ejecute un objeto Java a la vez. El ciclo de vida de la aplicacion del cargador de sistema es enlazado con el disco y la aplicacion del cargador de sistema es cargada en una memoria cuando el disco sea insertado en el dispositivo y es eliminado cuando el disco sea removido. El dispositivo se ejecuta en una maquina virtual Java en la parte superior de la cual la aplicacion del cargador de sistema es configurada para correr. Debido a que el ciclo de vida de la aplicacion del cargador de sistema es enlazado con el disco, la maquina virtual Java corre durante el tiempo que el disco sea introducido en el dispositivo y no es eliminada cuando el objeto Java sea pausado o eliminado.

Description

MODELO DE CICLO DE VIDA JAVA PARA DISCOS-BD Descripción de la Invención La presente invención se dirige al campo del almacenamiento óptico. La invención es particularmente relevante para los discos y reproductores de rayo azul y sus especificaciones lógicas. El Disco de Rayo Azul ROM (BD-ROM) es la especificación próxima de almacenamiento óptico que está siendo trabajada en base a un consorcio de compañías de software de productos electrónicos de consumo y a la industria del entretenimiento para quienes es deseable integrar las últimas tecnologías de almacenamiento, reproducción y software para desarrollar la siguiente generación de portadores y reproductores que combine, tanto la oportunidad de nuevas experiencias para el usuario como una alta densidad de almacenamiento. El BD-ROM es el siguiente estándar en el disco óptico sólo de lectura, el cual utiliza un láser azul, de manera que sea posible obtener una capacidad al menos de 25GB por capa de datos. Los estándares ópticos podrían definir, tanto los formatos físicos como lógicos de los portadores. La invención es dirigida al formato lógico de los portadores ópticos, es decir, a la capa de aplicación sobre el disco, y por lo tanto, el formato físico no será discutido en este documento. REF. 169650 Una aplicación primaria prevista para el BD-ROM es la Televisión de Alta Definición, sin embargo, la conectividad de la Web y la interactividad, tal como la navegación en la Web, las aplicaciones de charla o juegos, también se encuentran dentro del alcance del estándar . El anteproyecto actual del estándar BD-ROM especifica un modo de película, en donde los datos digitales de Audio/Video (A/V) son puestos en práctica o experimentados a través de la interacción con los objetos de película. El concepto del modo de película incluye las funcionalidades similares al Disco Versátil Digital, las cuales principalmente se refieren a la reproducción de contenido A/V. Un objeto de película puede iniciar una lista de reproducción que comprende una lista de secuencias A/V almacenadas en el disco y también permite que el autor del contenido efectué algún tipo de procesamiento previo y posterior con respecto a la reproducción A/V. El modo de película también incluye títulos, como los ítems que el usuario observa y que puede seleccionar para su reproducción. Una tabla de índice enlaza los títulos con los objetos de película. Además de esta capacidad de reproducción A/V, los servicios interactivos estarán disponibles en la nueva generación de medios ópticos y el entorno de programación es necesario para permitir que las aplicaciones interactivas estén presentes en el disco. La tecnología Java™, de la empresa SUN, con su Máquina Virtual, las Interfaces de Programación de Aplicación y las bibliotecas existentes fueron observadas por el consorcio industrial como una buena tecnología candidata para permitir la factibilidad de las aplicaciones interactivas en los portadores de almacenamiento óptico . No obstante , se generan varios problemas en la adaptación del entorno de la Computadora Personal para los dispositivos electrónicos de consumo , puesto que las expectativas y la experiencia del usuario son distintas . Un primer problema es que las aplicaciones de software podrían contener errores que no serian superficiales durante el desarrollo o la prueba y estos errores no detectados de código no deben evitar que el BD-ROM sea leído ni tampoco que el reproductor BD-RGVE esté funcionando. En su lugar, el hecho que una aplicación se detenga en forma inesperada no debe provocar que el reproductor también se detenga. Un segundo problema, es un problema específico para Java, es común en Java, que una aplicación se ejecute en un instante de una máquina virtual Java y el paro de la aplicación implica normalmente la detención de la máquina virtual Java puesto que todos los ganchos (es decir, los códigos de máquina) en la plataforma nativa tienen que ser liberados . La detención y el inicio de la máquina virtual significan que se tienen que cargar todos los ficheros de clase relacionados con el entorno y este procedimiento puede tomar hasta 30 segundos . Sin embargo , un retraso en el orden de segundos es inaceptable en aplicaciones de dispositivos electrónicos de consumo .

Por lo tanto, los inventores han buscado una solución que alivie estos inconvenientes y el entorno de programación, que es bien conocido como la Plataforma Multimedia de Hogar (MHP) , les ha proporcionado una base para desarrollar un ambiente en donde las aplicaciones presenten un modelo similar del ciclo de vida como el definido en MHP. La MHP es un estándar basado en Java para la televisión interactiva. En la MHP, una aplicación puede ejecutarse como una aplicación independiente o puede implementarse la así llamada interfaz Xlet . Las interfaces Xlets son comúnmente pequeños programas que efectúan funciones simples tal como las guías electrónicas de programación (EPGs) , los juegos interactivos, el contenido mejorado, el manejo de la ejecución en cascada de los medios de transmisión, las aplicaciones de charla, los listados de menú y similares. La interfaz Xlet es otro nombre para las aplicaciones Java y los mismos 'applets', las Xlets son controladas mediante el software que se ejecuta en ellas. En el caso de un 'applet' (un applet es una pequeña aplicación de software escrita en lenguaje Java), el software fundamental es un navegador u observador applet (es decir, el protocolo de navegación de Apple Computer) . En el caso de una interfaz Xlet, el software fundamental se encuentra en el receptor de televisión digital, un módulo o caja de conexión o cualquier otro dispositivo electrónico de consumo que soporte la plataforma Java. Una interfaz Xlet no comprende un método principal ni los implementos de una interfaz Xlet que definen las firmas de los métodos de ciclo de vida del Xlet. La interfaz Xlet define los métodos de ciclo de vida que señalan los siguientes cambios de estado: Creación, Iniciación, Pausa y Eliminación. Todas las implementaciones de TV Java tienen un manejador de aplicación que llama los métodos de ciclo de vida de las Xlets para mover una o más interfaces Xlets a través de sus distintos estados de aplicación. Por ejemplo, un observador podría estar jugando un juego junto con un programa de juego y además, decide verificar los listados del programa. Si los listados del programa y del juego fueran interfaces Xlets, el manejador de aplicación en el receptor señalarla que una Xlet está presente cuando el observador seleccione los listados de programa. En este punto, el manejador de aplicación podría detener la Xlet del juego, y el receptor podría descargar la interfaz Xlet de los listados de programa, en el receptor. El manejador de aplicación carga e inicia la interfaz Xlet de los listados de programa. En base al concepto Xlet, los inventores han implementado un tipo similar de aplicación para el ambiente BD-Rom (reproductor y portador) . Por lo tanto, la invención es dirigida a un portador de almacenamiento óptico que incluye al menos una aplicación de objeto Java que tiene un modelo predefinido de ciclo de vida. El modelo de ciclo de vida define al menos tres métodos, que cuando son llamados, provocan que la aplicación se encuentre en uno de los siguientes estados respectivos: un estado pausado, un estado activo y un estado inactivo. El portador también incluye una aplicación del cargador de sistema que es configurada para ejecutarse en una máquina virtual Java. Esta aplicación del cargador de sistema tiene un método principal y un ciclo de vida enlazado con la inserción del portador en el dispositivo de exploración, y además, la aplicación del cargador de sistema es configurada para controlar el ciclo de vida de la aplicación del objeto. El cargador de sistema también es, de manera que controle la aplicación de objeto en el estado pausado o en el estado inactivo cada vez que sea llamada otra aplicación almacenada en el portador. La invención aplica algunos conceptos que son inicialmente utilizados en la MHP en discos BD-Rom ya cargados al menos con una aplicación de objeto Java y una aplicación del cargador de sistema. La aplicación de objeto Java y la aplicación del cargador de sistema son en algunos aspectos similares a la respectiva aplicación de objeto Java y al manejador de aplicación. En la invención, solamente la aplicación del cargador de sistema incluye un método principal y el ciclo de vida de la aplicación de objeto que es controlado por la aplicación del cargador de sistema. El ciclo de vida de la aplicación del cargador de sistema es enlazado con la inserción del disco dentro del dispositivo de exploración, esto significa que la aplicación del cargador de sistema es cargada en el arranque del sistema operativo cuando el disco sea insertado y explorado, y es interrumpida posteriormente cuando el disco sea expulsado del dispositivo. De esta manera, la aplicación del cargador de sistema se ejecuta en la duración del disco en la máquina virtual Java y como resultado, la máquina virtual Java no es eliminada o suprimida ni reiniciada mientras el disco se encuentre en el dispositivo. Por lo tanto, es aliviado uno de los inconvenientes asociados con el reinicio de la máquina virtual Java mencionados con anterioridad. Además, un concepto específico de la invención es que la aplicación del cargador de sistema solamente permite que una aplicación de objeto se ejecute a la vez y provocaría que una primera aplicación de objeto se dirija hacia un estado pausado o inactivo si el usuario o el sistema llaman a otra aplicación de objeto mientras la primera aplicación se está ejecutando-. La invención difiere de la MHP en varios aspectos. En primer lugar, en la MHP puede ejecutarse al mismo tiempo más de una interfaz Xlet, mientras que la invención solamente permite que una aplicación de objeto Java sea ejecutada a la vez y que la aplicación del cargador de sistema sea almacenada en el disco con la aplicación de objeto Java y no en el reproductor en donde es almacenada la máquina virtual Java. Una ventaja de la invención es proporcionar un entorno de computación confiable y que sea bien aceptado para la comunidad de desarrolladores con el objeto de producir aplicaciones para medios ópticos . Breve Descripción de las Figuras A continuación, la presente invención será descrita en mayor detalle, por medio de ejemplos, con referencia a las figuras que la acompañan, en donde: La Figura 1 muestra los componentes básicos de un entorno Java ; La Figura 2 muestra los componentes lógicos de un sistema de disco/reproductor de la invención; y La Figura 3 muestra los métodos y estados del ciclo de vida de la aplicación de objeto Java de la invención. Los elementos dentro de las figuras que tienen características similares o correspondientes son identificados con los mismos números de referencia. La Figura 1 ilustra los elementos básicos de un entorno común Java. Un entorno común Java comprende componentes de software que se ejecutan en un hardware 110 de un dispositivo. El dispositivo podría ser una computadora personal o un dispositivo electrónico de consumo, tal como una computadora portátil de tipo 'tablet' Web, un asistente digital personal, una consola de juegos, un módulo o caja de conexión, y similares. La tecnología Java fue diseñada para permitir que las mismas aplicaciones se ejecuten en redes heterogéneas y en una diversidad de arquitecturas de hardware. La Máquina Virtual (VM) Java 120 es el primer componente de la plataforma Java que permite una tecnología neutral de arquitectura. La VM Java 120 es uno de los dos componentes principales de la plataforma portátil de tecnología Java, para la cual los compiladores de lenguaje de programación Java pueden generar códigos. La VM Java 120 puede ser modificada o llevada para su adaptación en un hardware específico 110. La plataforma Java, que solamente es software, también incluye, además de la VM Java 120, la Interfaz de Programa de Aplicación (API) Java 130. La API Java 130 es una gran colección de componentes de software elaborados con facilidad que proporcionan muchas capacidades útiles, tal como la interfaz gráfica de usuario (GUI) , conectividad, I/O, etc. La API Java 130 es agrupada en bibliotecas de clases e interfaces relacionadas; estas bibliotecas también pueden ser conocidas en la industria como paquetes. Entonces, en la parte superior de la plataforma Java 120, 130, podría ejecutarse el conjunto de aplicaciones 140 de desarrolladores que son escritas en código Java. La Figura 2 muestra un diagrama de bloque de un sistema BD-ROM de la invención. El sistema incluye el disco 200 y el reproductor 100. El reproductor 100 incluye el hardware 110, la interfaz de programación de aplicación 125 con las bibliotecas Java y la VM Java 120. El disco BD-Rom o disco de rayo azul 200 incluye una aplicación del cargador de sistema 210, los objetos Java 220, 230, 240, los datos A/V 260 y los objetos de película 250. Debe observarse que aunque la invención será descrita en el contexto del BD-Rom, la invención incluye cualquier tipo actual o futuro de portador de almacenamiento, ya sea óptico o no, que satisfaga las especificaciones de la invención, ya sea que el portador sólo sea de lectura, que sea susceptible de ser escrito o reescrito. Como se explicó en la parte de introducción, el disco BD-ROM 200 podría permitir un modo interactivo y un modo de película. El modo de película se ilustra a través de los bloques 260 y 250 en la Figura 2. Los objetos de película 250 podrían ser asociados con una o más listas de reproducción de secuencias A/V guardadas en la porción de almacenamiento de datos 260 del disco 200 y los objetos de película 250 permiten la observación y el procesamiento del contenido A/V 260. Por ejemplo, un objeto de película 250 podría señalar una lista de reproducción de clips A/V, los cuales forman, por ejemplo, una película. El usuario puede seleccionar y reproducir clips A/V o películas a través de títulos en una tabla de índice. La tabla de índice podría ser situada en un menú de raíz y una porción de este podría visualizarse al usuario para su selección.

El modo interactivo incluye Xlets u objetos Java 220, 230, 240 y la aplicación del cargador de sistema 210. Los objetos Java 220, 230, 240 además de proporcionar aplicaciones de interactividad, tales como charla, escucha de menú, animación de pantalla, juegos, navegación de la Internet y similares, también podrían ser capaces de controlar la reproducción A/V. Los objetos Java 220-240 y la aplicación del cargador de sistema 210 podrían ser almacenados juntos en el disco 200 en un fichero único Jar. El fichero Jar es un fichero de archivo Java, el cual podría ser comprimido y cargado y también descomprimido en forma automática por la "VM Java 120. Este fichero Jar podría contener un fichero de manifiesto, el cual describe los ficheros comprendidos en el archivo e indica el fichero que contiene la aplicación de cargador de archivo 210. La aplicación del cargador de archivo 210 incluye un método principal y podría ser la única aplicación almacenada en el disco 200. El ciclo de vida de la aplicación de cargador de sistema 210 es intrínsecamente enlazado con el disco 200 y es cargado en el arranque cuando el disco 200 sea insertado en el reproductor 100 y es detenido cuando el disco 200 sea removido del reproductor 100. En consecuencia, la aplicación del cargador de sistema se ejecuta en la duración del disco 200. Por el contrario, los objetos Java 220-240 no incluyen un método principal y podría ejecutarse solo para una parte de la duración del disco 200.

Los objetos Java 220-240 podrían ser capaces de iniciar una lista de reproducción de las secuencias A/V, capturar y procesar las operaciones y comandos de usuario, tal como el usuario que presiona los códigos de control remoto y finalmente transfiere el control a los objetos de película 250. En esta modalidad, cuando el control es transferido de los objetos Java 220-240 al objeto de película 250, la aplicación de cargador de sistema 210 podría eliminar o hacer una pausa en los objetos Java 220-240, como será explicado posteriormente con referencia al modelo de ciclo de vida que se ilustra en la Figura 3. Sin embargo, aunque la aplicación de cargador 210 podría provocar que los objetos Java 220-240 se encuentren en un estado inactivo 340, la aplicación de cargador 210 todavía se ejecuta en la VM Java 120 que no es terminada. La aplicación de cargador de sistema 210 mantiene una lista de todas las aplicaciones de los objetos Java 220-240 presentes en el disco 200 y controla los respectivos ciclos de vida de todos los objetos 220-240. La aplicación de cargador de sistema 210 envía los comandos al objeto 220, 230 ó 240 mediante el llamado de sus métodos 215, 225, 235, 245 ó 255 con respecto a los estados 220-240 de objeto o de la aplicación. El objeto Java de aplicación 220-240 podría estar en uno de cuatro estados: el estado iniciado 310, el estado de pausa 320, el estado activo 330 y el estado inactivo o suprimido 240 y el ciclo de vida del objeto 220-240 incluye cuatro métodos 315-355 que pueden ser llamados. La aplicación de cargador de sistema 210 primero podría cargar el objeto Java 220-240 en la memoria en el estado cargado 310, el cual es en forma subsiguiente, automática o a través de la inicialización y podría llamar al método de inicialización 315 por la aplicación de cargador de sistema 210, forzado a dirigirse al estado de pausa 320 en donde la aplicación u objeto 220-240 está esperando un comando. El objeto Java 220-240 en el estado pausado 320 utiliza recursos mínimos del dispositivo 100 y la VM Java 120, y no presenta nada en la pantalla o ninguna salida del dispositivo 100. A partir del estado pausado 320, la aplicación de cargador de sistema 210 podría llamar al método de inicio 325 y activa el objeto Java 220-240 en el estado activo 330 en donde está corriendo la aplicación asociada con el objeto Java 220-240. A partir del estado activo 330, la aplicación de cargador de sistema 210 podría pausar el objeto Java 220-240 de regreso hacia el estado pausado 320 mediante una llamada a un método de pausa 265 o eliminar el estado activo del objeto Java 220-240 hacia el estado 340 a través de una llamada para eliminar el método 335. La aplicación de cargador 210 podría anular el objeto Java 220-240 de cualquiera de los estados 310, 320 ó 330 o la aplicación de cargador de sistema 210 podría esperar hasta que el objeto Java 220-240 termine por su propia cuenta.

En una modalidad de ejemplo, el estado pausado 320 es implementado como sigue. En el estado pausado 320, el objeto Java 220-240 debe detener el suministro de cualquier servicio y podría liberar recursos y volverse inmóvil . La liberación de todos los recursos comprende la liberación de todos los eventos y controles de usuario, tal como los códigos de control remoto, los teclados, las entradas de voz, las entradas de pantalla de toque, y similares. El objeto Java 220-240 no podría mantener el acceso exclusivo a estos controles y recursos y no debe responder a eventos generados por ellos. En forma alterna, el objeto Java 220-240 podría mantener el acceso temporal a uno o más recursos de control A/V. Por ejemplo, cualquier contenido A/V que fue iniciado como parte de una lista de reproducción antes que el objeto Java 220-240 fuera forzado hacia el estado pausado 320 podría continuar ejecutándose. No obstante, el objeto Java 220-240 no podría iniciar ninguna nueva lista de reproducción o iniciar alguna presentación de nuevo contenido, por ejemplo, un siguiente ítem en la lista de reproducción, ni podría responder a eventos relacionados con el contenido A/V. Como se mencionó con anterioridad, un objeto Java podría ser traído de regreso de su estado pausado 320 por medio de una llamada a su método de inicio 325. Cuando sea traído en el estado activo 330, el objeto Java 220-240 reclama todos los recursos que liberó en el estado pausado 320. Esto significa que en el registro, de los eventos de usuario, la presentación de pantalla, es efectuada en el método de inicio 325 o es comenzado a partir del método de inicio. El registro de acceso al control A/V podría ser efectuado después del método de inicio y podría ser mantenido hasta que el objeto Java 220-240 o la interfaz Xlet sea eliminada. En un entorno de computación, el registro de los eventos de usuario es necesario con el fin de recibir comandos y entradas de usuario. Si ningún proceso de registro fuera incluido, el objeto Java no enviará entradas de usuario y por lo tanto, no responderá a ellas. Como se mencionó con anterioridad, el control podría ser transferido del objeto Java 220-240 al objeto de película 250. Cuando el control sea transferido del objeto Java 220-240 al objeto de película 250, la aplicación de cargador de sistema 210 podría eliminar el objeto Java 220-240 como se explicó con anterioridad con referencia a la Figura 3. Sin embargo, aunque la aplicación de cargador de sistema 210 podría provocar que el objeto Java 220-240 se encuentre en el estado inactivo 340, la aplicación de cargador de sistema 210 todavía está ejecutándose en la VM Java 120 que no es terminada. La aplicación de cargador de sistema 210 se ejecuta en el plano posterior hasta que el control es transferido de regreso a esta, en tal caso, esta ejecuta el objeto Java 220-240 asociado con el menú de raíz, el cual muestra una lista de títulos interactivos. En forma alterna, un objeto de película 250 podría mostrar el menú de títulos interactivos en lugar del objeto Java 220-240 y cuando un título interactivo sea seleccionado, el control sería transferido a la aplicación de cargador de sistema 210 y el objeto Java 220-240 enlazado con el título seleccionado sería iniciado. El estado pausado 320 también podría ser requerido cuando el usuario presione el menú durante un título Java. Cuando esto suceda, el Menú es iniciado y otro título es comenzado. Si el usuario presionara el comando Reanudar, el reproductor 100 reanuda el título que estaba inicialmente reproduciendo cuando sucedió la primera llamada del Menú. Si el usuario seleccionara una vez más el botón Menú, entonces, una vez más el título actualmente en reproducción sería pausado y el anterior sería eliminado. El reproductor 100 podría tener un objeto Java 220-240 pausado que continúe cuando los comandos de usuario se reanuden. Si un objeto Java 220-240 fuera pausado cuando el usuario trata de hacer pausa a un segundo objeto Java, el primer objeto Java pausado sería eliminado, de modo que el segundo objeto pueda ser pausado. Debe entenderse que la invención incluye la ejecución de un objeto Java 220-240 de aplicación a la vez. De esta manera, en una modalidad de ejemplo, la aplicación de cargador de sistema 210 en el arranque inicia el objeto Java 220-240 que es asociado con la visualización de un menú interactivo. El usuario puede seleccionar de entre un número de títulos interactivos, en donde cada uno de los títulos visualizados es enlazado con otro objeto Java 220-240. Cuando el usuario selecciona un título, la aplicación de cargador de sistema 210 elimina o hace pausa en el objeto Java 220-240 de menú e inicia el objeto Java 220-240 enlazado con éste título. El nuevo objeto Java 220-240 es asociado, por ejemplo, con la reproducción de contenido A/V, un juego o con la pantalla de otros listados de menú que comprenden un número de ítems seleccionables o títulos asociados con otro conjunto de objetos Java. En otra modalidad de ejemplo, es requerido un mecanismo que señale cual objeto Java 220-240 es permitido que se ejecute con estos títulos. Este mecanismo es requerido para permitir una implementación fácil y para permitir el inicio y desconexión precisos de un objeto Java. Una tabla de índice podría ser definida, que indicara cual objeto (s) de película debe ejecutarse cuando un título sea seleccionado. La tabla de índice guarda los índices que almacenan los enlaces con el objeto de película 250 o los objetos Java 220-240. En otra modalidad, los objetos de película 250 podrían ser implementados como objetos Java que efectúan funciones equivalentes y en este caso, el disco 100 proporcionaría un entorno completo Java.

Será evidente para una persona experta en la técnica, que otras numerosas alternativas caen dentro del alcance de las reivindicaciones adjuntas. A este respecto, las siguientes observaciones finales son efectuadas. Existen numerosos modos de implementar funciones por medio de ítems de hardware o software, o ambos. Por ejemplo, los dibujos presentados aquí son esquemáticos, cada uno sólo representa una modalidad. De esta manera, aunque un dibujo muestra distintas funciones como bloques diferentes, esto por ningún medio excluye que un ítem único de hardware o software efectúe varias funciones. Ni tampoco excluye que una función sea realizada a través de un montaje de ítems de hardware o software o ambos . Se hace constar que con relación a esta fecha el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims

REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones :

1. Un portador de almacenamiento, caracterizado porque comprende : al menos una aplicación de objeto Java que tiene un modelo predefinido de ciclo de vida que incluye al menos tres métodos, que cuando son llamados, provocan que la aplicación de objeto Java se encuentre en uno de los siguientes estados respectivos: un estado pausado, un estado activo y un estado inactivo; una aplicación de cargador de sistema que se ejecuta en una máquina virtual Java, la cual tiene un método principal y un ciclo de vida enlazado con la inserción del portador dentro del dispositivo de exploración y la aplicación de cargador de sistema es configurada para controlar el ciclo de vida de la aplicación de objeto; en donde la aplicación del cargador de sistema controla la aplicación de objeto en el estado pausado o inactivo cuando sea llamada otra aplicación de objeto Java en el portador.

2. El portador de conformidad con la reivindicación 1, caracterizado porque comprende una porción de almacenamiento óptico.

3. El portador de conformidad con la reivindicación 1, carac erizado porque la aplicación de objeto comprende un servicio interactivo.

4. El portador de conformidad con la reivindicación 1, caracterizado porque la aplicación de objeto y la aplicación del cargador de sistema son almacenadas en un fichero de archivo Java en el portador que comprende un fichero de manifiesto que indica a la aplicación del cargador de sistema.

5. El portador de conformidad con la reivindicación 1, caracterizado porque la aplicación de objeto incluye un control de reproducción de una secuencia de video.

6. El portador de conformidad con la reivindicación 1, caracterizado además porque comprende : una tabla de índice que asocia la aplicación de objeto con el ítem de título o menú.

7. El portador de conformidad con la reivindicación 1, caracterizado porque la aplicación del cargador de sistema es configurada para controlar la aplicación de objeto en el estado pausado y para controlar la liberación a través de la aplicación de recursos asociados con el dispositivo de exploración.

8. El portador de conformidad con la reivindicación 6, caracterizado porque los .recursos incluyen una pantalla del reproductor.

9. El portador de conformidad con la reivindicación 1, caracterizado porque la aplicación del cargador de sistema es configurada para controlar la aplicación de objeto en el estado de inicio y para controlar el registro con el sistema a fin de recibir los eventos de usuario.

10. El portador de conformidad con la reivindicación 1, caracte izado porque el portador además comprende un objeto de película asociado para controlar la reproducción de una secuencia de audio/video .

11. Un sistema, caracterizado porque comprende: un dispositivo de exploración que almacena una máquina virtual Java; un portador de almacenamiento que incluye : al menos una aplicación de objeto Java que tiene un modelo predefinido de ciclo de vida que está constituido al menos de tres métodos que, cuando son llamados, provocan que la aplicación de objeto Java se encuentre en uno de los siguientes estados respectivos: un estado pausado, un estado activo y un estado inactivo; una aplicación del cargador de sistema, que es configurada para ejecutarse en la máquina virtual Java, mientras el portador es introducido en el dispositivo de exploración, tiene un método principal y un ciclo de vida enlazado con la inserción del portador dentro del dispositivo de exploración y la aplicación del cargador de sistema es configurada para controlar el ciclo de vida de la aplicación de obj eto ; en donde la aplicación del cargador de sistema controla la aplicación de objeto en el estado pausado o inactivo cuando sea llamada otra aplicación de objeto Java en el portador .