MX2011002225A - Arquitectura de software flexible modular para tv. - Google Patents

Abstract

Más bien que tener un juego de código único por producto de TV, se proporciona una base de código común a líneas de producto múltiples parejas. Los sistemas incrustados se pueden mejorar a través de una conexión de red. La arquitectura de software proporciona un acercamiento flexible para soportar múltiples ofertas de producto a través de un middleware modular de enchufe y proporcionando aceleración de hardware normalizada para ambas gráficas 2D y 3D. La capacidad de enchufe proporciona adiciones de particularidad y mejoras después de la venta.

Description

ARQUITECTURA DE SOFTWARE FLEXIBLE MODULAR PARA TV I. CAMPO DE LA INVENCIÓN La presente invención se relaciona generalmente con arquitecturas de software flexibles modulares para tvS .

II. ANTECEDENTES DE LA INVENCIÓN Las arquitecturas de TV existentes se basan en un modelo de funcionalidad fijo que no cambia a través del tiempo de vida del producto. El juego de particularidades y aplicaciones son fijas en el tiempo de definición de producto y no cambia. Este tipo de arquitectura no fue originalmente diseñado para acomodar actualizar particularidades de producto individuales después de que el producto se ha entregado al cliente.

COMPENDIO DE LA INVENCIÓN Como se entiende en 'la presente, un medio flexible para mejorar la TV después de la entrega es deseable. Además, como se entiende en la presente, la necesidad de flexibilidad se extiende más allá de mejorar después de la entrega al cliente, y más particularmente un medio más modular y flexible para desarrollar y luego configurar ofertas de producto a medida que se introducen será ventajoso.

Consecuentemente, una arquitectura ede sistema de TV modalizada en un medio de almacenamiento legible por computadora tangible incluye una unidad de coordinación lógica de aplicación (ALCU), y una pluralidad de módulos de enchufe (PIM) que comunican cón la ALCU. Cada PIM representa una particularidad de sistema de TV deseada. Las interacciones de PIM-a-PIM se definen en el nivel de PIM que es especifico de producto para soportar diferenciación de producto. Es decir, una combinación particular de PIMs se puede hacer especialmente de manera diferente en modelos diferentes para proporcionar diferenciación de producto adicional. Adicionalmente, al añadir un nuevo PIM, el nuevo PIM puede estar programado para comprobar otros PIMs específicos y hacer su comportamiento consecuentemente basado en los otros PIMs, y v. gr., la ID de modelo de TV, que se puede leer por el nuevo PIM.

En otro aspecto, un método incluye proporcionar en una primera y segunda líneas de modelo de sistema de TV una unidad de coordinación lógica de aplicación (ALCU) común a ambas líneas de modelo. El método también incluye proporcionar una pluralidad de módulos de enchufe (PIM) configurados para comunicarse con la ALCU, con cada PIM representando una particularidad de sistema de TV deseada y con la ALCU dirigiendo información entre los PIMs. Un juego de PIMs en la primera línea de modelo puede ser diferente a un juego de PI s en la segunda linea de modelo. El juego de PIMs puede ser establecido para establecer particularidades deseadas pretendidas para el modelo de TV particular. Las combinaciones de PIMs pueden incluir versiones de PIM modificado para añadir diferenciación de producto adicional.

En otro aspecto, un sistema de presentación incluye un circuito de presentación de video y procesador que implementa una arquitectura de particularidad de TV modalizada en software. La arquitectura incluye una unidad de coordinación lógica de aplicación (ALCU) y una pluralidad de módulos de enchufe (PIM) que comunican con la ALCU. Cada PIM representa una particularidad de sistema de TV deseada. La ALCU dirige información entre los PIMs, y los nuevos PIMs se pueden añadir a la ALCU para cooperar con los PIMs que se comunican con la ALCU.

En algunas modalidades de ejemplo un PIM que proporciona una primera particularidad modaliza un primer juicio de lanzamiento de aplicación en una primera linea de modelo y un PIM que proporciona una primera particularidad modaliza un segundo juicio de lanzamiento de aplicación en una segunda linea de modelo. El segundo juicio de lanzamiento de aplicación es diferente al primer juicio de lanzamiento de aplicación. En algunas implementaciones un PIM que proporciona una primera particularidad se registra para un primer evento en una primera linea de modelo y un PIM que proporciona la primera particularidad se registra para un segundo evento en una segunda linea de modelo. El segundo evento es diferente al primer evento. Las interacciones de PIM-a-PIM puede ser definidas al nivel de PIM para ser especificas de producto.

En ejemplos no limitativos, cada PIM incluye un código de interfaz único a una linea de modelo particular y un código de particularidad común a través de todas las lineas de modelo en las que el PIM se busca que se use. El código de interfaz traduce llamadas de otros PIMs recibidas a través de la ALCU hacia celdas entendidas por el código de particularidad. La ALCU puede incluir una interfaz pública, una interfaz de utilidades, y una interfaz de PIM.

Los detalles de la presente invención, tanto en cuanto a su estructura como operación, se pueden entender mejor haciendo referencia a los dibujos que se acompañan, en los que los mismos números de referencia se refieren a partes semejantes, y en los cuales BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un diagrama esquemático de un ambiente de ejemplo en el que se pueden usar los presentes principios; La Figura 2 es un diagrama esquemático de una arquitectura de ejemplo de conformidad con los presentes principios .

DESCRIPCIÓN DETALLADA DE LA MODALIDAD PREFERIDA Haciendo referencia inicialmente a la Figura 1, se muestra un sistema 10 que incluye una presentación 12 visual. En la modalidad de ejemplo mostrada la presentación 12 visual es una presentación de video de TV tal como pero no limitada a una presentación de tipo matriz de panel plano.

El sistema 10 incluye un chasis 14 de TV que retiene la presentación 12 y un sintonizador 16 de TV que recibe señales de una fuente 18 de TV que programa tal como un extremo de cabeza de cable, caja superior de aparato, receptor de satélite, antena terrestre, etc. El sintonizador 16 típicamente está montado en el chasis 14 aún cuando en algunas modalidades el sintonizador 16 pude ser parte de la caja de aparato descrita adicionalmente abajo.

El chasis 14 también retiene típicamente un procesador 20 de TV que puede tener acceso a información, incluyendo una implementación de software de lógica presente, en un medio 22 de almacenamiento legible por computadora tangible, tal como uno o más almacenamientos de disco, almacenamientos de' estados sólido, etc. Los mandos de usuario pueden ser recibidos desde un control 24 remoto.

Se debe entender que mientras que la exposición abajo se enfoca en PIMs implementados por software que se pueden almacenar en el medio 22 dentro del chasis 14 de TV, en algunas modalidades un PIM se puede conectar a un impulsor de software para comunicarse con un dispositivo externo tal como una caja de aparato. En cualquier caso,' los PIMs se puede transmitir para almacenamiento al medio 22 a través de una conexión de red a la TV o un impulsor de dedo de bus en serie universal (USB) u otro método. En todavía otras implementaciones, si un PIM se implementa mediante una tarjeta de enchufe externa, la tarjeta, para justificar su costo añadido, puede contener hardware especializado para realizar computacionalmente intensas tareas de descargar aquellas tareas del procesador 20 de TV. Por ejemplo, búsquedas asociativas complejas para reconocer e identificar una cara de personas dentro de un video actual que se está présentando se pueden descargar a una tarjeta de enchufe en el caso de que la tarjeta se vaya a usar para proporcionar un PIM o PIMs. El PIM para dicha particularidad por día, por ejemplo, ejecutar comunicación de PIM a PIM para obtener una captura de video de la imagen de pantalla y enviarla al procesador externo en la tarjeta. La solicitud de dato de retorno podría entonces enviarse a la ALCU abajo descrita para dirigir los resultados a un PI de presentación para reportar los resultados. De esta manera, en la Figura 2 abajo descrita, un artículo tal como "Particularidad C" podría ser una interfaz a un procesador externo u otro dispositivo externo tal como un controlador de impulsión de dedo de USB.

Como se muestra en la Figura 1, el sistema 10 también puede incluir una caja 26 de aparato de modo que una caja superior de aparato o caja posterior de aparato se puede sujetar mecánicamente al chasis de TV y eléctricamente conectado al componente interno del mismo. Entre otros componentes, la caja 26 de aparato puede incluir un procesador 28 de caja que tiene acceso a uno o más medios 30 de almacenamiento legible por computadora para implementar la arquitectura presente. Se debe entender que los presentes principios se pueden implementar mediante el procesador 20 de TV que actúa en concierto con, el procesador 28 de caja, o que la caja 26 de aparato se puede omitir en cuyo caso los presentes principios se implémentan por el procesador 20 de TV.

El sistema 10 también de preferencia puede incluir una interfaz 32 de red de computadora de área amplia, en este caso, contenida en la caja 26 de aparato y controlada por el procesador 28 de caja, para tener acceso a una red de área amplia tal como el Internet para recibir los módulos abajo descritos del mismo. Sin limitación, la interfaz 32 se puede modalizar mediante un módem alambrado o inalámbrico.

Los presentes principios incluyen construir una base para soportar una escala de productos mejorables desde una sola base de código. La arguitectura no limitativa de ejemplo descrita más abajo expande el concepto de "aplicaciones de enchufe" para proporcionar "middleware de enchufe". Esto significa gue más gue solamente una interfaz de usuario (UI) se puede añadir como un "enchufe" descargable. Nuevas capacidades y particularidades se pueden añadir al sistema en una manera normalizada y consistente. La arguitectura no limitativa de, ejemplo describa más adelante proporciona un mecanismo para gue varias particularidades se añadan o remuevan a través de un linea de producción desde dentro de una sola fuente de base de código tanto durante el desarrollo como después de la entrega de producto como módulos de "enchufe" descargables . La arguitectura no limitativa de ejemplo descrita más adelante también permite un desarrollo de producto más eficiente y tiempo más rápido de mercado.

La arquitectura no limitativa de ejemplo descrita más abajo proporciona una entrega de evento expansible todavía normalizada mientras que reduce al mínimo el número total de eventos, equipos de módulo grupa dos que definen ofertas de producto, la capacidad de "congelar" cambios en un juego de producto mientras que permite que el desarrollo continúe en otros y un mecanismo convencional para permitir que componentes de middleware se conecten hacia el sistema total .

De esta manera, cada producto de TV no es simplemente un juego seleccionado de módulos de software genéricos. El código común que puede permanecer el mismo a través de productos se separa del código que necesita ser el único a cada producto.

Cada módulo único se llama un PIM (Módulo de Enchufe) . Cada PIM representa una particularidad de sistema de TV respectiva, de modo que particularidades pueden enchufarse hacia la arquitectura a través de PIMs que emplean una interfaz común a la Unidad de Coordinación Lógica de Aplicación (ALCU) . La ALCU dirige llamadas y eventos entre PIMs. La interfaz de PIM incluye un juego común de entradas de interfaces de programación de aplicación (API) para todos los PIMs que les permiten inicializar, cargar, reaccionar a eventos de sistema e iniciar eventos y acciones.

Cada PIM actúa un representante entre el módulo que representa, tal como entrada del mando remoto, a la interfaz de sistema generalizada usada por la ALCU. Cada PIM también actúa como el repositorio del' código único de producto. Cada módulo de software que conecta a través del PIM a la ALCU se mantiene "producto neutro" con elementos específicos de producto mantenidos dentro del PIM. Esto permite que las particularidades sean compartidas entre productos mientras que permiten la diferenciación de particularidad dentro de cada producto.

Consecuentemente, mientras que el comportamiento de sistema total se define en : la unidad de control lógica central, los comportamientos individuales para cada módulo se pueden añadir sobre una base de enchufe también. Cada módulo de sistema individual es transparente entre si y puede cambiarse o reemplazarse sin 'afectar cualquier otro módulo. El módulo modificado o reemplazado solamente necesita definir su comportamiento de sistema en su PIM, que acopla este módulo hacia el sistema completo a través de la ALCU.

Haciendo ahora referencia a la Figura 2, un módulo de software de base, referido' en la presente como Unidad de Coordinación Lógica de Aplicación (ALCU) 34, proporciona el mecanismo para dirigir la acción de aplicación y eventos de sistema entre PI s 36 de particularidad implementada por software y sincroniza comportamientos entre PIMs 36 de particularidad, que se pueden proporcionar en diferentes combinaciones de PIM para proporcionar diferentes escalas de producto de sistema de TV y venderse como paquetes de producto diferentes y/o que se pueden descargar individualmente del Internet al sistema 10 de TV después de instalación en casa para, v. gr . , mejorar un módulo existente en el paquete o añadir un nuevo módulo al paquete para añadir una nueva particularidad al sistema de TV en intercambio, para, . gr., pago de la nueva particularidad.

Como se muestra en la Figura 2, cada PIM contiene una definición de particularidad y sub-módulo 38 de código de ejecución que es único al PIM particular. Asimismo, cada PIM 36 contiene un módulo 40 de código común que es el mismo para todos los PIMs, debido a razones que se describirán en breve. Cada PIM 36 también incluye una interfaz 42 de ALCU que comunica con una interfaz 44 de la ALCU 34, con las interfaces 42, 44 que definen un esquema de interfaz común para facilitar añadir y remover PIMs 36 de la ALCU 34 con facilidad.

Cada PIM 36, además de proporcionar software para establecer una particularidad respectiva para el sistema 10 de TV, puede añadir contestaciones hacia la ALCU 34 para definir comportamientos específicos de producto de módulo como se necesitan, como se describe más completamente abajo. Consecuentemente, la ALCU 34, que puede ser implementada en una modalidad como una clase única C++, es un mecanismo de dirección para distribuir eventos de sistema y acción entre los PIMs. Cada PIM 36 puede añadir un evento hacia una cola de evento de ALCU 34 a través de una interfaz de ALCU 34 como se expone adicionalmente abajo.

Además de dirigir información entre PIMs 36, la ALCU 34 también mantiene seguimiento de aplicaciones activas actuales, así como relaciones pare niño en una pila de estructura de datos de lista, en cuyas estructuras de datos de lista representan relación de aplicaciones de capacidad.

Las acciones y eventos se definen como solicitudes para realizar y acción o la . entrega de alguna información respecto a un evento. Una acción de ejemplo es la solicitud de lanzar una aplicación por un PIM 36, y un evento de ejemplo es una tecla de tablero que se dirige a una aplicación asociada a otro PIM que se ha lanzado.

Además de la interfaz 44 necesaria para los PIMs, como se muestra en la Figura 3, la ALCU 34 de ejemplo tiene un API 46 público para controlar la instalación y remoción de PIM. Además, la ALCU 34 incluye un API 48 interno para utilidades de la ALCU 34 que proporcionan rutinas comunes a servicio de operaciones de dirección.

La arquitectura de base de ALCU 34 de esta manera proporciona un medio común para conectar los PIMs, una interfaz para controlar las conexiones de PIM, y una interfaz 50 de utilidad común que se puede usar por ambas la ALCU 345 y los PIMs. Cada PIM puede expedir una acción que es guiada a través de la ALCU 34 otro PIM. La ALCU 34 4ecibe eventos de un PIM y lo añade a la cola de evento. Cada articulo en la cola de eventos es procesado en serie y despachado a un PIM de meta. En lugar de procesar un mensaje para cada llamada de función en el sistema, el mensaje que pasa ventajosamente se puede hacer sobre una base por PIM para mantener la totalidad del sistema de dirección baja.- La difusión de eventos a muchos PIMs se puede manejar teniendo cada registro de PIM un manejador de llamada para recibir cada tipo de evento en el que está interesado.

Una cola de evento de ALCU 34 es una estructura de datos de núcleo para que ALCU 34 procese todos los eventos de sistema. La cola de eventos se puede implementar tan simple como una cola FIFO que proporciona Primera-Llegada Primer- Servicio, o como una Cola de Prioridad, en la que los eventos de prioridad más elevada son procesados primero para llenar la linea de terminación de tiempo. La complejidad del mecanismo de dirección se puede hacer especialmente a la oferta de producto.

El formato de evento de ALCU 34 se puede especificar a través de un entero no firmado empacado en bit. El entero puede incluir un módulo ID, un tipo de evento, un tipo de subevento, y una o más banderas de evento. La ID de módulo indica el PIM de fuente del evento, mientras que el tipo de evento especifica lo que se está enviando. El tipo de subevento y las banderas de evento permiten que parámetros y calificadores se añadan al evento.

Mientras que los eventos totales se definen a lo ancho del sistema, la combinación de evento y subvento proporciona a la ALCU 34 las flexibilidades para hacer especialmente la granularidad de dirección de conformidad con solicitudes. Para recibir eventos, cada PIM registra manejadores de evento para eventos y subeventos que desearía recibir, 1 ALCU 34 entonces dirige eventos a aquellos manejadores de evento registrados, o además a aquellos manejadores de subevento registrados para evitar difusión innecesaria o multidifusión de mensajes.

Cada PI se deriva de una interfaz de PIM de base, que puede ser una clase abstracta C++ y tiene un número de métodos virtuales puros que se implementan por la clase derivada. Cada PIM puede soportar instalación, remoción, inicialización, y cierre de si mismo. Cada PIM tiene puntos de entrada para recibir un lanzamiento de aplicación, evento de sistema, o evento de clave.

Un PIM, dependiendo de su función, puede no procesar todos los tipos de evento. Por ejemplo, un PIM que proporciona la particularidad de recibir una entrada de tecla desde el control remoto podría expedir un aviso o error si se recibe una solicitud de lanzamiento de aplicación.

La interfaz 46 pública de ALÑCU 34 puede ser una interfaz "C" para módulos de sistema para tener acceso de los internos de ALCU 34. La interfaz pública proporciona el control total de la cola de eventos de ALCU 34, instalando y removiendo PIMs y para iniciar ALCU 34, obteniendo estado del estado del sistema y obteniendo relaciones de pares, niños y hermanos de aplicación.

La interfaz 50 de utilidad de ALCU 34 se pone en interfaz con utilidades que se pueden usar por ambos la ALCU 34 y los PIMs. Estas utilidades son funciones de ayuda para regresan la ID de aplicación activa, la pregunta del estado de sistema o añadir/remover la llamadas necesarias para especificar el comportamiento de PIM. La interfaz 50 de utilidades de ALCU 34 también proporciona una unidad de base de ALCU 34 una capa de abstracción para tener acceso a la plataforma de sistema de modo que los detalles de la plataforma de sistema se pueden abstraer de la parte ded unidad de base de ALCU 34, que es un mecanismo para dirigir evento .

Como un ejemplo de cómo funciona la arquitectura anterior, hacer referencia a la Figura 4 y suponer que un "evento de tecla" se genera por un usuario que manipula una tecla en el control remoto 24. El evento de tecla se detecta por el procesador de TV y se pasa hacia la ALCU 34 a través de un PIM 52 cuya 'nica función podría ser alertar a la ALCU de recibo de mando "Eventos de tecla") . El evento de tecla se añade hacia una cola 654 de eventos en la ALCU 34. La cola 54 de eventos puede ser la primera en venir en primer orden. Los eventos en la cola se remueven y dirigen a los otros PIMs 56 que ha registrado una llamada para eventos de tecla. El manejo de enfoca puede ser arbitrado a través de la estructura de la arquitectura.

Por ejemplo, además de un PIM de evento de tecla, un PIM puede incluir una parte 58 de PIM buscador específico de producto que define las interacciones de ese PIM con otros PIMs para la linea de modelo particular que se está usando, y una parte 60 de funcionalidad de buscador que es común a través de todas las lineas de modelo para proporcionar funcionalidad de buscador :de Web. Dicho Pim podría registrarse para recibir "eventos de tecla" del PIM de evento de tecla en algunas líneas de producto, pero no en otras, dependiendo del diseño de la línea de producto particular y la mezcla de particularidades que se pretenden proporcionar.

En el caso en donde otro PIM tal como un PIM 58 buscador se registra para recibir "eventos de tecla" disparados por el control 24 remoto, el evento de tecla se puede filtrar a través de las utilidades de ALCU 34, que puede determinar cuya aplicación en la que la red actualmente tiene eenfoque en la TV. Esto permite a un PIM ver la entrada de tecla y permite además el soporte de tecla caliente, aislando el comportamiento de sistema dentro de los módulos de PIM. La ALCU 34 mantiene seguimiento de aplicaciones activas así como relaciones pare y niño entre aplicaciones. Una aplicación de pared puede tener múltiples aplicaciones de niño.

Ahora se puede apreciar que mientras un solo PIM buscador ventajosamente se puede proporcionar para múltiples lineas de modelo de TV, el módulo buscado se puede hacer especialmente a una capacidad superior o inferior deseada para una linea de modelo particular debido a que cada PIM se puede programar para definir su comportamiento de sistema, linea de modelo mediante linea de modelo, registrando un manejador de evento para algunos eventos en una en linea de modelo y para otro o menos eventos en otra linea de modelo. Una vez que los PIMs reciben eventos dirigidos desde la ALCU 344, los eventos se trasladan además en el PIM a las llamadas de operación/función de módulo asociado.

Para promover adicionalmente , añadir o remover fácilmente un PIM de particularidad dentro de una sola base de código para diferentes productos, la arquitectura anterior hace los PIMs "capaces de enchufarse" usando las interfaces y funcionalidades arriba descritas. Por ejemplo, un PIM buscador se puede reemplazar sin impactar la arquitectura de sistema total. A este fin, el , PIM buscador de WEB tiene una interfaz pública que define las funciones públicas de PIM que se pueden llamar desde el PIM buscador. Cada vez que la ALCU 34 llama al PIM buscador, el PIM buscador traslada la llamada y luego invoca a las funciones públicas de PIM. De esta manera, el PIM buscador se puede añadir, remover y reemplazar con diferentes PIMs buscadores sin afectar la arquitectura del sistema.

La Figura 5 muestra que el PIM 58 buscador especifico de producto traslada los eventos de acción de aplicación, incluyendo evento de lanzamiento de aplicación, evento de reasumir aplicación, evento de suspender aplicación, y evento de terminar aplicación como se puede indicar por un "evento de tecla" particular, a las llamadas esperadas por el API 60 buscador que está asociado con el PIM de juego buscador 58 y que, volver a llamar, es común a todas las lineas de modelo. Por ejemplo, cuando el PIM 58 buscador recibe una aplicación de evento de lanzamiento especifico al tiempo modelo, invoca una función pública del API 60 buscador para mostrar la ventana de buscador seleccionada. Cuando el PIM 58 buscador recibe un evento de tecla que indica un evento de terminar aplicación, hace una llamada al API 60 buscador para cerrar la ventana. El PIM 58 buscador también atiende a transformación de formato de tecla asimismo, como se indica en la Figura 5.

De esta manera, el PIM 58 buscador transforma las entradas de tecla crudas que son recibidas de la ALCU 34 al formato de tecla requerido por el buscador. El PIM 58 buscador también traslada los eventos de red a un evento de buscador especifico. Usando un diferente medio buscador que crea un nuevo PIM que maneja las traslaciones necesarias para el juego de llamada del buscador nuevo. Juntos, ambos, el PIM 58 buscador y el API 60 buscador mostrados en la Figura 5 se pueden considerar como un solo PIM que proporciona la funcionalidad del buscador particular para el que el API 60 está configurado.

Un PIM 62 de gráficas modular también se puede proporcionar, denotado "X2" en la Figura 6. En esencia, ambos el buscador 60 y el rendidor 64 de gráficas asociado con el PIM 62 de gráficas son agentes de entrega de gráficas, y cada uno puede proporcionar gráficas para presentación en la presentación 12 independientemente del otro, como se indica en la figura 6. Un PIM 66 manejador de gráficas se puede proporcionar para coordinar composición de las salidas 68, 70 respectivas del rendidor 64 de gráficas y API 60 buscador hacia la presentación de pantalla final. El rendidor 64 de gráficas puede ser un rendidor 2D o 3D o puede soportar GLAbierto.

Añora se puede apreciar que con la presente arquitectura de enchufe, con cada PIM potencialmente siendo hechos expedientemente para diferentes lineas de modelo como se describe arriba esencialmente siendo capaz de definir interacciones en el nivel de PIM que incluye juicio de lanzamiento de aplicación a aplicación para ser especifico en producto, el tiempo de integración de sistema se reduce significativamente comparado con sistemas existentes. Un número de PIMs individuales se pueden construir en un nuevo sistema en un periodo de tiempo corto. Mejorando la capacidad de reuso de software, la estabilidad del software final se incrementa; el trabajo humano reguerido para mantenimiento de software reduce también. Debido a que los PIMs pueden descargarse del Internet, los presentes principios que incorporan TVs pueden añadir nuevas particularidades durante el tiempo.

Además de los PIMs arriba mencionados, por vía de ejemplo no limitativo PIMs de ejemplo también se pueden proporcionar para permitir las siguientes particularidades: Búsqueda de Internet, Video de Internet, servicios basados en Ubicación, Mapas, Telefonía, Comunicación, Servicio de foto de Comunidad carga/descarga (v; gr., Flockr) , Pagos, traspaso de información (v. gr., Mi Aviso), disposición de sincronización a ifusión, Juegos de computadora, Diganósticos, EPG, DVR, PIMs de red de casa también se pueden proporcionar incluyendo PIMs para compartir foto/música/video, PIM de DNLA, un PIM de "empuje" para empujar datos de un teléfono a la TV a través de, v. gr., Bluetooth, etc.

PIMs 3D GUI también se pueden proporcionar incluyendo PIM de barra de medios cruzados. PIM de favoritos, PIM de integración de dispositivo.

Recordar que cada PIM se registra para ciertas llamadas dependiendo de la linea de modelo, de modo que cuando se recibe un lanzamiento de aplicación, el PIM llama un método para hacer un juicio de lanzamiento de aplicación. Si el valor regresado es falso, el PIN no lanza su aplicación asociada. Además, una aplicación en una linea de modelo puede bloquear otras aplicaciones para lanzar hasta que el usuario hace una selección, mientras que en otras lineas de modelo la aplicación puede no bloquear otras aplicaciones.

Debido a que cada PIM se puede hacer especialmente para su linea de modelo particular programando el PIM para registrarse para llamadas apropiadas para esa linea de modelo y programando ese PIM para hacer juicios de lanzamiento de aplicación que se desean para una linea particular, el mismo PIM se puede usar en múltiples lineas de modelo con un comportamiento respectivo diferente para cada linea.

Por ejemplo una linea de modelo de extremo elevado puede desear proporcionar las particularidades de una interfaz de usuario que es nativa a ese producto, red, y una interfaz de usuario de buscador, en cuyo caso los PIMs que representan la UI nativa, uno o más PIMs de red que representan particularidades tales como HD Mundial, registrador de video digital, alianza de red vida digital (DLNA) , etc, se pueden enchufar en la ALCU.

Por otra parte, una linea de modelo siguiente inferior se puede diseñar para proporcionar hacer red y un UI Buscador de WEB (E.G., Una hoja local para instalación), en cuyo caso los PIMs que proporcionan DLNA, EPG y particularidades de seguridad de casa se pueden enchufar en la ALCU. Un modelo inferior siguiente se puede diseñar para proporcionar un UI nativo y red, y PIM que proporciona DVR, , telefonía Bluetooth, y capacidad de control remoto se puedan enchura en la ALCU. Un modelo inferior siguiente se puede diseñar para proporcionar un UI nativo sin soporte de red, en cuyo caso un BluRay DVD PIM y un PIM de telefonía Bluetooth se pueden enchufar en la ALCU. Un modelo inferior más bajo se puede diseñar para proporcionar conexión de TV, solamente sin ningún UI prolongado, en cuyo caso un PIM de conexión A/V inalámbrico y PIM de control remoto solamente se puede proporcionar, etc.

Mientras que la arquitectura de ejemplo no limitativo de SOFTWARE FLEXIBLE MODULAR descrito adicionalmente abajo para tv se muestra en la presente y describe con detalle, se debe entender que el asunto materia que está abarcado por la presente invención está limitado solamente por las reivindicaciones.

Claims (15)

REIVINDICACIONES

1. - Sistema de presentación, que comprende: presentación de video; circuito de procesador que implementa una arquitectura de particularidad de TV modalizada en software y que incluye : una unidad de coordinación lógica de aplicación (ALCU) ; y una pluralidad de módulos de enchufe (PIM) que se comunican con la ALCU, cada PIM representando una particularidad de sistema de TV deseada, la ALCU dirigiendo información entre los PIMs, en donde nuevos PIMs se pueden agregar a la ALCU para cooperar con los PIMs que comunican con la ALCU, en donde eventos se definen a lo ancho del sistema, y en donde cada PIM registra cuando menos un manejador de evento respectivo para eventos que el PIM desea recibir, la ALCU subsecuentemente determina cuales eventos dirigir a cuales manejadores de evento basada en indicaciones de eventos deseados suministrados por los manejadores de evento .

2. - El sistema de conformidad con la reivindicación 1, en donde eun PIM que proporciona una primera particularidad modaliza un primer juicio de lanzamiento de aplicación en una primera linea de modelo y un PIM que proporciona una primera particularidad modaliza un segundo juicio de lanzamiento de aplicación en una segunda línea de modelo, el segundo juicio de lanzamiento de aplicación siendo diferente al primer juicio de lanzamiento de aplicación.

3. - El sistema de conformidad con la reivindicación 1, en donde un PIM que proporciona una primera particularidad se registra para un primer evento en una primera línea de modelo y un PIM que proporciona una primera particularidad se registra para un segundo evento en una segunda línea de modelo, el segundo evento siendo diferente al primer evento.

4. - El sistema de conformidad con la reivindicación 1, en donde las interacciones de PIM-a-PIM se definen en el nivel de PIM para ser específico de producto.

5. - El sistema de conformidad con la reivindicación 1, en donde cada PIM incluye: un código de interfaz único a una línea de modelo particular; y un código de particularidad común a través de todas las líneas de modelo en las que el PIM busca ser usado.

6.- El sistema de conformidad con la reivindicación 5, en donde el código de interfaz traslada llamadas de otros PIMs recibidas a través de la ALCU hacia llamadas entendidas por el código de particularidad.

7. - El sistema de conformidad con la reivindicación 1, en donde la ALCU incluye una interfaz pública, una interfaz de utilidades, y una interfaz de PIM.

8. - Método que comprende : proporcionar en una primera y una segunda lineas de modelo de sistema de TV una unidad de coordinación lógica de aplicación (ALGU) común a ambas lineas de modelo; y proporcionar una pluralidad de módulos de enchufe (PIM) configurados para comunicarse con la ALGU, con cada PIM representando una particularidad de sistema de TV deseada y con la ALCU dirigiendo información entre los PIMs, en donde un juego de PIMs en la primera linea de modelo son diferentes de un juego de PIMs en la segunda linea de modelo, en donde un PIM que proporciona una primera particularidad modalidza un primer juicio de lanzamiento de aplicación en una primera lóinea de modelo y un PIM que proporciona una primera particularidad modaliza un segundo juicio de lanzamiento de aplicación en una segunda linea de modelo, el segundo juicio de lanzamiento de aplicación siendo diferente al primer juicio de lanzamiento de aplicación.

9. - el método de conformidad con la reivindicación 8, qu comprende descargar un nuevo PIM a una primera linea de modelo después de que la TV se vende para proporcionar una particularidad representada por el PIM a la TV, la TV no teniendo la particularidad antes de descargar el PIM.

10. - El método de conformidad con la reivindicación 8, en donde un PIM que proporciona una primera particular se registra para un primer evento en una primera linea de modelo y un PIM que proporciona una primera particularidad se registra para un segundo evento en un a segunda linea de modelo, el segundo evento siendo diferente al primer evento.

11. - El método de conformidad con la reivindicación 8, en donde las' interacciones de PIM-a-PIM se definen en el nivel de PIM que.es especifico de producto.

12. - El método de conformidad con la reivindicación 8, en donde cada PIM incluye: un código de interfa;z único a una linea de modelo particular; y un código de particularidad común a través de todas las lineas de modelo en las que el PIM busca ser usado, en donde el código de interfaz es único a una particularidad deseada de la linea de modelo.

13. - El método de conformidad con la reivindicación 12, en donde el código de interfaz traslada llamadas de otros PIMs recibidas a través de la ALCU en llamadas entendidas por el código de particularidad.

14. - El método de conformidad con la reivindicación 8, en donde ía ALCU incluye una interfaz pública, una interfaz de utilidades, y una interfaz de PIM.

15. - El sistema de conformidad con la reivindicación 1, en donde cuando menos un primer PIM se registra para recibir un evento predeterminado de un segundo PIM en algunas lineas de producto pero no en otras.