MXPA97007917A - Sistema para distribuir musica selectivamente - Google Patents

Sistema para distribuir musica selectivamente

Info

Publication number
MXPA97007917A
MXPA97007917A MXPA/A/1997/007917A MX9707917A MXPA97007917A MX PA97007917 A MXPA97007917 A MX PA97007917A MX 9707917 A MX9707917 A MX 9707917A MX PA97007917 A MXPA97007917 A MX PA97007917A
Authority
MX
Mexico
Prior art keywords
jukebox
data
music
songs
jukeboxes
Prior art date
Application number
MXPA/A/1997/007917A
Other languages
English (en)
Other versions
MX9707917A (es
Inventor
Kleiman Bobry Ruben
Original Assignee
Advanced Technology Research Sa Cv
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/833,265 external-priority patent/US5959945A/en
Application filed by Advanced Technology Research Sa Cv filed Critical Advanced Technology Research Sa Cv
Publication of MX9707917A publication Critical patent/MX9707917A/es
Publication of MXPA97007917A publication Critical patent/MXPA97007917A/es

Links

Abstract

La presente invención se refiere a un sistema de distribución de música para sinfonolas electrónicas digitales locales que comprende:un sitio de almacenamiento central que incluye canciones disponibles, gráficos y títulos;un sistema de menú, el sistema de menúincluye almacenar una porción de un menúen un sitio de sinfonola local, en donde el sitio de sinfonola local estáseparado del sitio de almacenamiento central, y almacenar un menúcompleto en el sitio de almacenamiento central;medios de comunicación entre el sitio de almacenamiento central y las sinfonolas locales, en donde las sinfonolas locales descargan información deseada automáticamente durante una transmisión desde el sitio de almacenamiento central;y un programador para coordinar la transmisión desde el sitio de almacenamiento central a las sinfonolas locales.

Description

SISTEMA PARA DISTRIBUIR MÚSICA SELECTIVAMENTE ANTECEDENTES DE LA INVENCIÓN 1. Campo de la Invención El presente invento se relaciona con un sistema de distribución musical para sinfonolas. Particularmente, se relaciona con un sistema en el cual una sinfonola selectivamente solicita la transmisión de canciones específicas desde un local de almacenaje centralizado, basado en el uso de información, y un sistema que coordina la transmisión para optimizar el ancho de banda del canal. 2. Discusión del Arte Relacionado Las sinfonolas convencionales reproducen música de discos o discos compactos los cuales contienen varias canciones. Los discos o discos compactos se almacenan localmente en la sinfonola y se seleccionan físicamente para ser reproducidos por las sinfonolas. El usuario visualiza un display enumerando las canciones seleccionadas y contenidas en cada disco o disco compacto. El usuario selecciona una canción para que sea ejecutada, esta operación se realiza depositando dinero dentro de la sinfonola y presionando las teclas que representan la canción deseada. El cambiador de discos o discos compactos de la sinfonola selecciona el «disco o disco compacto apropiado y lo transfiere al reproductor en un período de aproximadamente 30 segundos. Existen muchas deficiencias en las sinfonolas convencionales. El problema más significativo se relaciona con la selección de música. Los usuarios están limitados a la selección de canciones de los discos o dis8s (XMnpactos que se encuentran presentes físicamente dentro de la sinfonola. Sin embargo, gran parte de la música contenida en estos dis8s o discos compactos no se utiliza. Esto se debe a que frecuentemente las canciones menos populares se incluyen en los discos o discos compactos que también contienen canciones que si son populares. Los discos de las sinfonolas generalmente contienen dos canciones, una en cada lado. Los discos compactos pueden contener varias canciones. Generalmente, solamente un par de canciones son populares y se tocan con frecuencia. Las canciones restantes son solo parte del disco comparto y no son reproducidas. Los cálculos indican que el 80% de las canciones de una sinfonola no se utilizan. Esto es un desperdicio de espacio dentro de la sinfonola la cual podría contener canciones adicionales populares. De igual manera, no es sencillo personalizar la selección de las canciones a un tipo específico de clientela según la localización de la sinfonola. Los diferentes establ«3cimientos cuentan con clientela que con frecuencia desea diferentes tipos de música o canciones en particular. No existe ningún mecanismo capaz de determinar los gustos de los usuarios en localizaciones específicas. Por lo tanto, el propietario de la sinfonola utilizará información de las listas de popularidad para seleccionar las canciones. Alternativamente, se utilizan estudios realizados formalmente por investigadores o informalmente a través de operadores para seleccionar las canciones. Dichos estudios también tienen deficiencias debido a problemas de muestreo. Después de que la música ha sido seleccionada, el actualizar la música requiere de un gran «consumo de tiempo además de que resulta caro. Los discos o discos compactos se actualizan al ser substituidos manualmente. Cada copia del disco o disco compacto debe ser comprada y después instalada en la sinfonola. El listado de títulos también se actualiza manualmente al cambiar los discos.
Los costos de instalación y mantenimiento de una sinfonola pueden ser muy elevados. Una sinfonola tiene capacidad de hasta 100 discos o discos compactos. La instalación de la sinfonola requiere la compra de una cantidad considerable de discos o discos compactos. También es necesario hac*er «compras adicionales con el fin de cambiar la música. De igual manera, las descomposturas son comunes debido a que las sinfonolas incluyen muchas partes móviles. Hay descomposturas frecuentes en la parte que recibe el dinero o en la partes móviles de los discos/discos compactos. El mantenimiento de la sinfonola requiere de visitas de técnicos especializados. Ya que el costo de reproducción de una canción es bajo, el mantener una sinfonola resulta caro para un establecimiento en el cual las canciones no se reproducen con frecuencia.
Por lo tanto, existe la necesidad de una sinfonola que permita que la selección de canciones sea adaptada a las localizaciones específicas. Existe la necesidad de un sistema de sinfonola que elimine la selección y el cambio manual de canciones. Existe la necesidad de un sistema que reduzca los costos de operación de las sinfonolas. En la reproducción de música personal, las cintas, discos o discos compactos se reproducen en un sistema sencillo. Las canciones probables se limitan a las canciones que posee el usuario. Resulta costoso el poseer una librería musical amplia ya que cada canción debe ser comprada. Así mismo, cuando se cuenta con una librería amplia se requiere de mucho tiempo para realizar la selección de canciones ya que las canciones deben ser seleccionadas manualmente. El costo de las sinfonolas impide que los usuarios utilicen las sinfonolas como instrumento personal de reproducción musical. Adicionalmente, si un individuo renta una sinfonola para una fiesta, las canciones no pueden ser reproducidas consecutivamente. Más bien, se requiere de un retraso entre canciones que va de 8 a 30 segundos; esto es con el fin de cambiar los discos. Por lo tanto, existe la necesidad de un sistema de sinfonola que resulte económico y se pueda operar como sistema personal de reproducción musical. Existe la necesidad de un sistema que pueda reproducir las selecciones consecutivamente y pueda incluir efectos de transición. Algunas de las dificultades de las sinfonolas convencionales se han superado con diferentes variaciones de diseños tipo sinfonola. Generalmente, estos sistemas son uno de tres tipos: en demanda, casi en demanda, y cargado de información. En un sistema de en demanda, el usuario selecciona una canción específica de una librería central o general. La canción se reproduce inmediatamente. El sistema en demanda requiere de un canal de ciatos de alta velocidad y por lo menos de 128 a 256 kbps entre el servidor y la sinfonola. El ajustar esto en un área mayor que la local resultaría extremadamente costoso. Dicho sistema también requiere un módem de alta velocidad el cual es muy caro. Los sistemas Casi en demanda utilizan una variedad de canales para transferir las canciones a una localidad para su ejecución. El usuario puede seleccionar una de las muchas canciones disponibles en los canales de manera similar a la que se utiliza para elegir un canal de radio o televisión. Con el fin de tener las mismas posibilidades de repetición que las sinfonolas, «cada canción tendría que ser repetida aproximadamente seis veces simultáneamente. Igual que los sistemas en demanda, el ancho de banda necesario para la transferencia de música excede ampliamente las tecnologías del presente. En los sistemas de cargado de información, la música es cargada en la sinfonola desde una localidad central. La música se almacena en la localización local para su futura reproducción. La sinfonola computarizada es un ejemplo de este sistema. En las sinfonolas computarizadas, las canciones se almacenan digitalmente dentro de la memoria. Por ejemplo, en la patente U.S. No. 5,355,302, la información de las nuevas grabaciones es recibida dentro de la memoria de cada sinfonola computarizada. Las antiguas grabaciones se borran de la memoria para crear espacio para las nuevas canciones. La sinfonola monitorea y almacena información referente al número de veces que cada canción ha sido ejecutada. La información se junta en una estación central la cual utiliza esta información para calcular los pagos de regalías y para determinar las canciones que son menos populares y necesitan ser substituidas en la sinfonola. Las sinfonolas se manejan remotamente por un sistema de manejo central que utiliza modems y líneas de teléfono públicas o transmisores de radio frecuencia y antenas. La localidad de manejo central también cuenta con un catálogo maestro que contiene información acerca de cada disco y canción almacenados. El sistema de manejo central monitorea la sinfonola, determina el espacio de memoria disponible en la misma y transmite las nuevas canciones y el catálogo de información para actualizar la sinfonola. La sinfonola computarizada almacena canciones y gráficos localmente con información acerca de las canciones. La sinfonola puede iniciar comunicación con el sistema de manejo central a horas pre-establecidas o en caso de que la sinfonola determine que ha ocurrido algo de lo que el sistema de manejo deba estar enterado. En los sistemas de sinfonola computarizada conocidos, el sistema de manejo central determina que canciones deben ser substituidas y que sinfonolas deben de ser actualizadas por medio de la utilización de los datos de las peticiones de nuevas canciones solicitadas por los clientes para ayudar a determinar si los datos de la nueva canción deben ser cargados en la sinfonola. La sinfonola cuenta con una jerarquía de clasificación que permite al usuario localizar la canción de interés. Sin embargo, los sistemas existentes no incluyen mecanismos que permitan al usuario seleccionar las canciones por tipo de música y no proporcionan información a la sinfonola local relacionada con la disponibilidad de las canciones en la localidad de almacenaje central. Además, los mecanismos automáticos no se utilizan para actualizar canciones en base a las selecciones del usuario. Por lo tanto, existe la necesidad de un sistema que actualice automáticamente las canciones en base a las preferencias del usuario. En los sistemas existentes, las canciones se transfieren desde un local central a las sinfonolas locales a través de una variedad de medios, incluyendo transmisiones satelitales, transmisiones RF, transmisiones por línea telefónica y transferencia física de discos. Por lo general, las canciones se transfieren de manera individual a cada sinfonola. Los enormes archivos asociados con la carga de archivos musicales pueden resultar extremadamente costosos e ineficientes, además de que la inversión de tiempo también es considerable. El tamaño promtsdio de una canción comprimida está en el orden de los 50 megabytes. El costo de transferencia de los archivos incluyendo canciones, puede resultar prohibitivo para una sinfonola computarizada que utiliza una localidad central de almacenamiento de música. Con el fin de competir con las sinfonolas tradicionales, el costo de la distribución de música debe ser similar al de la compra de nuevos discos compactos. Adicionalmente, el costo del equipo para proveer la comunicación de las canciones con la sinfonola pu«sde ser elevado. La transferencia de las canciones mediante línea telefónica utilizando modems resulta caro, particularmente cuando se requiere de una conexión telefónica de larga distancia entre la sinfonola y la localización central. Aún cuando los modems de alta velocidad no son caros, en muchas localizaciones las líneas telefónicas no están lo suficientemente libres de los ruidos ocasionados por las altas velocidades. Un ancho de banda más elevado o la velocidad de las líneas telefónicas no siempre está disponible en muchas legalizaciones y resulta mas costoso. Las comunicaciones ISDN tienen velocidades aún más altas, pero resultan más costosos tanto para las líneas telefónicas como para el equipo. Otros tipos de modems de alta velocidad. como los ADSL son significativamente más caros y las conexiones no siempre están disponibles. El costo del receptor satelital también es alto, tanto para el equipo como para el servicio. Las canciones también pueden ser transferidas a través de Internet, pero esto puede causar posibles retrasos significativos. Las sinfonolas computarizadas también requieren ser conectadas a Internet a través de cierto tipo de modem, aunque no se requiera de una llamada telefónica de larga distancia. Por lo tanto, existe la necesidad de un sistema de transmisión más eficiente. Con el fin de competir con las sinfonolas tradicionales, el sistema de distribución de música debe incluir un costo bajo tanto para las líneas como para el equipo de comunicación. De igual manera, y según el crecirruento del sistema, los incrementos significativos en el costo de distribución del equipo se mantendrán mínimos. Las sinfonolas computarizadas por lo general cuentan con una arquitectura cerrada; esto quiere decir que la sinfonola está asociada «con un distribuidor de música y un sistema de distribución específicos. Esto origina una gran dependencia de la sinfonola con el sistema de distribución. Si el distribuidor deja de existir, la música de la sinfonola no será reemplazable. De igual manera, las refacciones para las reparaciones también dejarán de existir. Por lo tanto, existe la necesidad de un sistema de distribución «son una arquitectura abierta. Finalmente, el sistema de sinfonolas computarizadas debe ser seguro. Ya que las canciones se almacenan digitalmente en un mecanismo de memoria modificable, las canciones pueden ser copiadas a otros mecanismos. Así mismo, las canciones no autorizadas pueden ser cargadas dentro de la sinfonola. El sistema de distribución debe proporcionar un mecanismo de seguridad de canciones. Se debe pagar una tarifa por la copia y distribución de la música. El mecanismo de pago debe evitar las falsificaciones de crédito o débito. Se han utilizado varios mecanismos de aseguramiento de pago como tarjistas inteligentes (smart card), tarjetas de débito, tarjetas de crédito, etc. Estos mecanismos proporcionan una seguridad satisfactoria mientras las conexiones entre el mecanismo de pago y el control electrónico no puedan ser accesados o el software que controla el mecanismo de pago no pueda ser modificado.
Sm embargo, los operadores deben de tener acceso a las conexiones de las smfonolas ya que son ellos quienes dan servicio a las máquinas En consecuencia, las conexiones pueden ser cortadas y el mecanismo de pago puede ser emulado, engañando el control electrónico Por otro lado, el software que controla el mecanismo de pago puede ser fácilmente modificado y engañado, evitando así el pago de las tanfas Por lo tanto, existe la necesidad de crear un mecanismo de pago más seguro que pueda seguir siendo confiable y seguro aún cuando sean violados el mecanismo de pago o el software que lo controlan BREVE DESCRIPCIÓN DE LA INVENCIÓN Las deficiencias de los sistemas de smfonola existentes se superan substancialmente mediante un sistema de sinfonola que según el presente mvento pueda alma«xnar digitalmente canciones individuales La música puede ser transfenda a la smfonola desde una locahzacion central de almacenaje para actualizar la música sm necesidad de que sea substituida físicamente La smfonola cuenta con un sistema de jerarquía de música para determinar las preferencias del cliente con el fin de automatizar la selección de música durante la actualización Así mismo, se utiliza un sistema de distnbucion unic? «sntre la localización «central y la smfonola el cual mejora en la utilización del ancho de banda para la transmisión Por consiguiente, es un objetivo del presente mvento el proporcionar un sistema de sinfonola que utilice un algontmo de substitución estadístico que funcione con diferentes jerarquías de memona, un algontmo de programación de horapos, y métodos convencionales de comumcación con capacidades de direccionamiento y de transmisión Además, es objetivo del presente invento el proporcionar a sistemas recientemente instalados con música en demanda y proporcionar la música solicitada a los demás sistemas en tiempos difepdos basándose en las necesidades de los usuarios locales. El diferir en el tiempo las solicitudes de música y combinar solicitudes de múltiples locales en una transmisión única y simultánica a múltiples sinfonolas resulta en una distribución más eficiente y a menor costo. Además, es objetivo del presente invento el tener una sinfonola programable con diferentes métodos de pago para así permitir que se puedan hacer pagos por adelantado y el acceso automático de la sinfonola al sistema central de almacenaje. Es objetivo del presente invento el almacenar una porción de un menú jerárquico en una sinfonola local y recuperar porciones adicionales del menú basados en los accesos de los usuarios locales. El presente invento también permite que las canciones sean colocadas en la sinfonola local basándose en las solicitudes de los usuarios dentro de varias áreas y en relación con la disponibilidad. La sinfonola local determina automáticamente la música que debe ser recuperada en ciertas localidades y carga la música selectivamente basándose en las preferencias de los usuarios en dicha localidad. Es otro aspecto del invento el crear un sistema de música que sea de bajo costo, tanto el equipo como el servicio, para comunicar las canciones a la sinfonola y la información al local central. Según este aspecto del invento, una de las sinfonolas designada como sinfonola maestra tiene la capacidad de operar como centro regional de servicio. La música es comunicada desde una localidad de almacenamiento central al centro regional de servicio. La música puede ser guardada en el centro regional de servicio además de ser transmitida a otras sinfonolas. Las transmisiones subsecuentes desde el centro regional de servicio a las sinfonolas esclavas pueden realizarse mediante líneas telefónicas locales a velocidades más bajas y costos más reducidos. También las transmisiones subsecuentes se pueden realizar mediante el envío de discos o diskettes removibles. Así mismo, las sinfonolas individuales pueden comunicar información directamente al centro regional de servicio. Es otro aspecto del invento el proporcionar un sistema de distribución musical que sea compatible con el uso de discos compactos que ya posea el operador de la sinfonola. La sinfonola computarizada puede contar con una interfase que se conecta con los cambiadores comerciales de discos compactos. Se puede dar entrada o scannear las portadas de los álbums y los nombres de las canciones dentro de la memoria de la sinfonola. Si el usuario selecciona uno de los álbums o canciones en uno de los discos compactos, la sinfonola se comunica con el cambiador de discos compactos para seleccionar y reproducir la canción apropiada. Es otro aspecto del invento el proporcionar un ambiente seguro para la transferencia de música e información sensitiva (como los certificados monetarios) para la compra de canciones o el pago de servicios desde la localización central a cada una de las sinfonolas computarizadas. El sistema incluye hardware de seguridad en cada una de las sinfonolas, el cual es utilizado para encriptar y descifrar la música y otra información sensitiva (como los certificados monetarios) para la compra de canciones o el pago de servicios proporcionados por esa sinfonola. La música se almacena en un formato encriptado el cual previene que copias ilegales hechas en otros locales puedan ser ejecutadas, incluyendo otras sinfonolas dentro del sistema. El hardware de seguridad es usado para asegurar la autenticidad de la música distribuida y el pago apropiado de la música.
BREVE DESCRIPCIÓN DE LOS DIBUIOS La Fig. 1 es una ilustración esquemática del sistema de distribución de música según el presente invento. La Fig. 2 es una ilustración esquemática de la estructura de música k>cal incluyendo una jerarquía de clases de música. La Fig. 3 es una ilustración esquemática de una «cola en cadena para la música solicitada en un canal de servidor estadísticamente asignado. La Fig. 4 es una ilustración esquemática de una cola en cadena para la música solicitada en un canal de servidor dinámicamente asignado.
La Fig. 5 es una ilustración esquemática de una «cola en cadena para la música solicitada en un canal de inhibición atrasada del servidor. Las Figs. 6a y 6b ilustran el proceso de inicialización del hardware de seguridad en un mecanismo de seguridad del presente invento. Las Figs. 7a, 7b, y 7c ilustran el proceso para la distribución de música utilizando el mecanismo de seguridad del presente invento. Las Figs. 8a, 8b, y 8c ilustran el proceso para la distribución de certificados monetarios en el mecanismo de seguridad del presente invento. La Fig. 9 ilustra un diagrama de bloque de una segunda representación del sistema de distribución de música de acuerdo al presente invento.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN El presente invento está relacionado con una sinfonola la cual almacena la música de manera digital, y un sistema de distribución musical para substituir la música en la sinfonola. Esto incluye un aparato y un método para solicitar cierta música guardada en un local de almacenamiento central y su transmisión a sinfonolas locales. El presente invento se relaciona más en lo particular con la arquitectura de Inventarios Virtuales con Reproducción Perpetua y Ejecución Electrónica de Títulos (VIP) para el manejo de Títulos Electrónicos Virtuales (VET). Un VET es digitalmente codificado dentro de un sobre de seguridad digital para ser utilizado para la distribución del correo o transmisión electrónica o el almacenaje; y solo puede ser abierto por los usuarios autorizados. El sobre VET contiene diversos tipos de objetos con enlaces relaciónales, así como información de empaque y contable. Los VETs pueden ser vendidos, comprados, almacenados, rentados, distribuidos, ejecutados, reproducidos, producidos o intercambiados. La ejecución de un tipo de objeto en un VET da como resultado la percepción humana de textos. gráficas, sonidos, vídeos, objetos tridimensionales, etc. En consecuencia, los VETs pueden conformar el mecanismo de almacenaje para una sinfonola digital. Cada canción es almacenada en un VET separado el cual puede ser ejecutado en base a la demanda del usuario. La reproducción de un tipo de objeto en un VET da como resultado la reproducción de tipos de objetos en un medio, tal «como los Video Discos Digitales (DVD), Discos Compactos (CD), cintas, la impresión de texto en papel, la impresión de imágenes en papel, esculturas, etc. Por lo tanto, también es posible reproducir una canción en otro formato de manera que el cliente pueda obtener una copia real, y la sinfonola pueda funcionar como centro de distribución de menudeo. Los pagos de regalías para la transmisión de copias pueden asegurarse a través del uso del mecanismo de pago abajo discutido. La Fig. 1 ilustra un sistema de distribución de música utilizando VETs de acuerdo a la personificación del presente invento incluyendo métodos de acceso entre una sinfonola y un local central de almacenamiento. La Fig. 1 contiene una arquitectura VIP en un ambi«cnte cliente/servidor. El VIP está compuesto de tres elementos principales incluyendo la Terminal Inteligente (TI) TI1-TI9, los Centros de Servicio de Operación (OSC) Rl, R2, Gl y los Sistemas de Comunicación (CM) CM1-CM9. Aún cuando se ilustra un sistema de distribución individual, se utilizan sistemas de distribución múltiple para distribuir la música a cualquiera de las TIs. Por ejemplo, como se ilustra en la Fig 1, la TT4 puede recibir música a través del Rl (un canal de distribución primaria) o el R2 (un «canal de distribución secundario). De igual manera, cada TI puede ser conectada a más de una red independiente. En conscxuencia, cada TI puede operar en una arquitectura abierta no limitada a un distribuidor único. La TI puede operar similar a una computadora incluyendo instrucciones para conectarse a diferentes redes de distribución. La Fig. 1 ilustra una red individual y es discutida a continuación. En una representación del presente invento, la TT es una Sinfonola Personal (PJ) capaz de proveer sin ningún costo el 95% de la música en demanda. La Sinfonola Personal no limita los aparatos a localizaciones caseras. En ves de esto, se relaciona con la capacidad de seleccionar canciones de acuerdo a deseos y gustos personales de los clientes en localizaciones específicas Sin embargo, el sistema de distribución del presente invento puede ser utilizado para proporcionar música a través de un PJ para los individuos en una localidad. La gran capacidad de la PJ para ejecutar la música en demanda se logra al sensar la demanda de música directamente de los usuarios finales, tal y «como se discute a continuación. El VIP utiliza las cifras de las cifras censadas por varios PJs para colocar físicamente los VETs en plataformas de almacenaje más cercanas a los usuarios finales quienes probablemente solicitarán dichos VETs. Los Servidores Regionales Rl, R2 en el OSC utilizan la información de demanda sensada localmcmte para determinar la demanda de popularidad local, mientras que el Servidor Global Gl usa la información para determinar la demanda de popularidad regional. Cada PJ utiliza la demanda sensada individual para determinar el almacenaje local de VETs. La plataforma PJ (cualquiera de TI1-TI9) contiene un CPU, un sistema de almacenamiento masivo, un sistema operativo y drivers para los dispositivos de hardware. El CPU está basado en una PC o un hardware set-up-box. El sistema de almacenamiento es lo suficientemente grande como para almacenar más de 200 canciones comprimiólas, como VETs, junto con tipos de datos asociados (texto e imágenes gráficas), o por lo general tiene casi 1 Gigabyte de capacidad de almacenamiento. El sistema de almacenamiento masivo es escalable para ajustarse a las necesidades del usuario. Ya que las canciones se pueden seleccionar individualmente para ser insertadas (o eliminaclas) del sistema de almacenamiento de la PJ, solo es necesario almacenar las canciones necesitadas. No se desperdicia espacio de almacenaje en las canciones no deseadas. La Plataforma de Distribución Global Gl en la Fig. 1 consiste en un LAN (Local Área Network) conectado en un WAN (Wide Área Network). Este Centro de Servicio de Operación Global Gl está compuesto por un servidor maestro, un subsistema jerárquico de almacenamiento, un servidor de comunicación, un equipo de conexión a una red pública o privada, y una fábrica de VETs. Los OSCs Regionales Rl y R2 son similares a el OSC Global Gl, excepto porque estas no requieren una fábrica de VETs. Los OSCs Regionales Rl y R2 se encuentran geográficamente más cercanos a las TIs a las cuales dan servicio. En consecuencia, son una fuente de VETs más rápida y generalmente menos costosa. Como se mencionó antes, la demanda de información de cada uno de los PJs correspondiente a un OSC Regional se puede utilizar para detepninar los VETs específicos que se deben mantener en el OSC Regional. Los OSCs Regionales, como el Rl y R2 pueden operar como nodos alternos en la red VIP y como substitutos de el OSC para otras regiones para que en caso de que algún nodo de la red VIP falle se puedan accesar rutas y OSCs Regionales o Globales alternativas. Aunque solamente se ilustra un solo nivel de OSC entre el OSC Global y las PJs, múltiples niveles puedicn ser usados. La información de demanda se utiliza en cada nivel para mantener las canciones más populares en los niveles más bajos. El OSC proporciona servicios de operación a las TIs. En la Fig. 1 se muestran diferentes opciones para que las TIs accesen los OSCs CM1-CM9. Existe un volumen elevado y una alta velocidad de distribución de VETs desde los OSCs a las TIs. Además, hay bajo volumen y baja velocidad de intercambio de información desde las TIs a los OSCs. La información intercambiada incluye la TI enviando una solicitud de VET a un OSC, una TI accesando información estadísti<ca en el OSC, un OSC accesando información de ventas desde la TI, y un OSC realizando un diagnóstico a control remoto, etc. En caso de que un OSC Regional falle, es posible que una TI se conecte a otro OSC Regional, o a el OSC Global para servicio. La Til en la Fig. 1 utiliza una línea telefónica asincrónica analógica para el intercambio de información. La Til solicita un VET a el OSC Regional para reducir el costo de la llamada telefónica. Después el OSC Rl Regional pasa la solicitud a el OSC Gl Global, el cual envía el VET a través del satélite. A continuación, el satélite transmite el VET solicitado al receptor de satélite de la Til . En esta implementación solo se necesita kxalmente de un receptor, antena, convertidor para bajar frecuencias y línea telefónica. La TI2 utiliza una red digital integrada para el intercambio de información y la distribución de VETs. Esta red requiere de un módem y en la actualidad se está estandarizando entre los proveedores de servicio.
La TI3 utiliza discos removibles para almacenar toda la información relacionada con la contabilidad, ventas, las solicitudes de VETs del usuario, etc. El disco se envía a el OSC contratado en donde se carga la información dentro de la base de datos para ser procesada. Después el OSC genera un disco hecho a la medida con las solicitudes del VET para el usuario de la TI especificado. Alternativamente, el OSC puede crear un disco con programación general para distribuciones comunes, como es el caso de las nuevas canciones. La TI4 utiliza un cable módem para intercambiar información y solicitudes de VETs. En la actualidad, no hay uniformidad entre los operadores de cable lo que dificulta este método de acceso a el OSC. De igual manera, algunos operadores de cable no cuentan con la capacidad bi-direccional de transmisión de datos. La TI5 utiliza una línea de abonado asimétrica digital para intercambiar información y solicitar VETs. La TI6 utiliza video digital o un cable módem coaxial de fíbra-hibrida para accesar el OSC lo cual da lugar a un ancho de banda de muy alta velocidad. Este método está siendo activamente desarrollado en los Estados Unidos debido al incremento en las comuni«caciones de fibra óptica. La TI7 utiliza tecnologías terrestres inalámbricas de Servicio de Distribución Multipunto Metropolitana (MMDS) o Servicio de Distribución Local Multipunto (LMDS) para accesar a el OSC. La MMDS es unidireccional y tiene un amplio ancho de banda. La LMDS está basada bi-«rüreccionalmente en tecnología semejante a la celular. La TI8 utiliza solo un receptor satelital y no es interactiva. Los VETs se transmiten continuamente y las TIs seleccionan automáticamente lo que desean cargar basándose en las estadísticas locales de demanda tal y como se discute a continuación. A las TIs se les cobra una tarifa fija por el uso de telecomunicaciones o por el número de VETs cargados. Los OSCs poseen la capacidad de habilitar/deshabilitar la carga (reproducción) de la TI, así como sus capacidades de ejecución.
La TI9 utiliza una computadora portátil para capturar las transacciones e información estadísti«ca de la TI y carga los contenidos (VETs) requeridos por la misma. La conexión entre la TI y el OSC se hace a través de un puerto o LAN. Un servidor de comumcación o servidor de acceso realiza las funciones de interfase de interpretación de protocolo de red, igualación de velocidad, almacenamiento temporal y ruteo de red entre las TIs y los OSCs. Cuando se utiliza envío satelital a las TIs, el portador de la red se conecta a el OSC mediante un enlace TI de alta velocidad o mediante un enlace Ei (o cualquier otro enla«ce de alta velocidad) desde el servidor de comuni«caciones al enla«ce satelital (up-link), en donde se enviarán los ciatos al satélite para su envío en las TIs que están geográficamente «distribuidas. El servidor de comunicación y el OSC se conectan internamente con el servidor Maestro a través de una conexión de red la cual realiza la interconexión de todos los mecanismos para garantizar un desempeño alto en la velocidad de la red. La fábrica de VETs en el OSC Global Gl produce sobres de VET los cuales son transferidos a través del sistema. La fábrica de VETs cuenta con una o más estaciones de trabajo multim«cdia con capacidades de edición, almacenamiento temporal, y una «conexión interna con la red OSC hub. La estación de trabajo se conecta con los dispositivos LAN y WAN a través de la conexión del hub de comunicaciones de manera que la estación de trabajo pueda accesar los mecanismos del servidor maestro y los dispositivos WAN externos. Los contenidos del VET pueden incluir texto; como el nombre de un álbum, el título de una canción, el autor, productor, fecha, número de serie, propietario de las regalías, etc., una imagen; como la portada de un álbum, o audio; como la canción o el archivo digital. La estación de trabajo crea el VET y lo envía al Servidor Maestro a través del Hub de comunicaciones. El servidor maestro actualiza la base de datos del VET. La estación de trabajo cuenta con puertos para conectar dispositivos de captura tales como reproductores de Discos Compactos para capturar canciones. La unidad de captura convierte un título en señal.
En el presente invento, un sobre VET se distribuye como unidad individual. El sobre contiene un grupo de VETs del mismo o diferentes tipos de datos juntos. Normalmente, los VETs de un sobre tendrán una relación de títulos. Por ejemplo, un sobre puede ser creado a partir de un álbum de manera que el sobre contenga cin«co «canciones del álbum. El sobre contendría 5 títulos de audio comprimidos y encriptados, 5 títulos de canciones descomprimidos y no-encriptados, estando cada uno enlazado a su título de audio respectivo, un título de audio descomprimido ligado a cada uno de los títulos de las canciones, y una portada comprimida y no-encriptada ligada al título del álbum. El método de acceso entre una PJ y un local central de almacenaje como la mostrada en la Fig. 1 incluye los siguientes pasos. El OSC transmite periódicamente a todas las localidades una lista de todas las canciones disponibles para su distribución. La Sinfonola Personal (TH-TI9) carga la lista de las nuevas canciones. La PJ determina la demanda del usuario capturando los requerimientos del usuario y procesando las demandas estadísticamente. Después la PJ determina los nuevos títulos que es conveniente cargar. Previo al intento de carga, la PJ es cargada con créditos a través de un pago o depósito bancario o un mecanismo de colección de fondos de PJ; como monedas, billetes, tarjetas intelíg«cntes, etc. Una vez que se han depositado los créditos, la PJ se auto-habilita o no, por la transmisión satelital de el OSC para cargar un número de canciones. Conforme se va cargando un título, el número de créditos va disminuyendo. La PJ carga solamente los títulos que ha seleccionado mientras que tenga créditos. Cada una de las sinfonolas alma«cena localmente una porción de la música disponible en el sistema y también puede reproducir esa música. La música que no está en la sinfonola puede ser extraída desde un local central de almacenamiento a través de cualquier medio de transferencia electrónica como el CM1-CM9 mostrado en la Fig. 1. Solo la música que ha sido habilitada a través del uso de los créditos puede ser recibida, descifrada y reproducida. Las canciones no pueden ser habilitadas cuando la PJ se queda sin créditos. De igual manera, la música que es copiada de otra fuente, como por ejemplo otra PJ, no puede ser habilitacia. Por lo tanto, las «canciones copiadas no pueden ser descifradas o reproducidas. A continuación se discuten otras características de seguridad.
La Fig. 2 ilustra una estructura de música local para determinar la información de demanda y la selección de canciones ejecutadas. Dicha estru«ctura se incluye en cada nivel VIP, basándose en la información desde un nivel más bajo. La estructura incluye una jerarquía de clases de música con niveles para tipos de música (como la Latina) y sub-tipos (como Samba, Salsa, Merengue), álbums, y canciones. Cada sinfonola incluye solo una porción de la jerarquía que sería localmente accesible. La jerarquía completa se ubicaría en la localidad central. Los locales de distribución Regional, como la Rl y R2 en la Fig. 1 pueden incluir toda o parte de la jerarquía. Se navega a través de la porción de la jerarquía en la sinfonola con el fin de seleccionar canciones que estén localmente disponibles para su reproducción. El usuario selecciona un tipo de música, después un sub-tipo, un álbum y después una canción. Solo se pueden accesar las canciones para las cuales se alma«cenaron VETs. Aún cuando el usuario seleccione un álbum, no todas las canciones del álbum pu«cd«3n ser almacenadas o seleccionadas. Por lo tanto, las canciones populares de un álbum son almacenadas, mientras que las menos populares no lo son. Con el fin de determinar las preferencias del usuario, el usuario puede navegar por la jerarquía para seleccionar los tipos de música o las canciones específicas que no están actualmente disponibles y que sería deseable que estuvieran incluidas. Estas canciones pueden ser cargadas en la sinfonola desde el local central (o regional). La sinfonola mantiene estadísticas relacionadas con el número de veces que un nodo en la jerarquía es revisado por algún usuario. Si el nodo es revisado un cierto número de veces (ya sea dentro de un período de tiempo establecido o como un cierto porcentaje del número total de nodos visitados), la información que está debajo de ese nodo es recuperada del local central de almacenamiento. Por lo tanto, puede que localmente no existan canciones de un tipo de música. Sin embargo, conforme los usuarios accesan la jerarquía y seleccionan cada tipo, sus estadísticas aumentan hasta que las porciones más bajas de la jerarquía son recuperadas. El número de hits n«ccesario «con el fin de solicitar porciones adicionales de la jerarquía o de ciertas canciones del local central puede variar basado en los objetivos para la sinfonola. La recuperación más rápida, como puede ser el acceso directo en-línea, sería naturalmente más cara. Alternativamente, el sistema puede solicitar que la música nueva o la jerarquía sea enviada dentro de un período de tiempo establecido, como por ejemplo; dos días. Como se discutió anteriormente, algunas canciones pueden ser transmitidas a múltiples TIs simultán«camente desde el local central. La jerarquía también puede ser transmitida a múltiples TTs simultánicamente0 de manera similar. Con esta estructura, cuando la sinfonola determina que una «canción o una porción de la canción debe ser recuperada, monitorea la transmisión simultán«3a (broadcast) hasta que la canción o la porción de la jerarquía es transmitida. Cuando se detecte, la sinfonola cargará la información deseada de la transmisión. Cuando una porción de la jerarquía es recuperada, no necesariamente se recuperará todo lo que hay debajo de la misma. En su lugar, recuperará un nivel y porciones de niveles más bajos. Adicionalmente, se borran las porciones de la jerarquía y las canciones que no son accesadas con frecuencia para de esta manera hacer espacio para nuevas porciones y canciones. Por lo tanto, la sinfonola se actualiza automáticamente con canciones de interés para la clientela de esa localidad en particular. El sistema también optimiza el ancho de banda del canal para la transmisión de información desde el local central a las diferentes sinfonolas. Cada petición de porciones adicionales de la jerarquía o de títulos de canciones específicas incluye un tiempo de entrega. Cuando la información es solicitada y los tiempos de entrega se traslapan, la información puede ser transmitida simultáneamente a sinfonolas múltiples. Esto es particularmente importante cuando la información es transmitida por satélite o a través de una red de computadoras. Esto permite una transmisión simultántca (broadcast) a múltiples locales. En una representación del presente invento, la relación de la Canción/Cubierta del Álbum es el número de canciones productivas del mismo. Las canciones productivas se clasifican en dos tipos: aquellas que generan el 80% de las ventas mensuales y aquellas que generan el 20% de ventas restantes. Basado en estudios, el presente invento utiliza 16% de las canciones de álbums en sinfonolas basados en CD las cuales generan el 80% de ventas mensuales. Esas canciones son Éxitos. Las canciones de desempeño promedio (DP) equivalen al 11% de las canciones de álbums y son las que generan el otro 20% de las ventas. El número total de canciones productivas es la combinación de los Éxitos y las de desempeño promedio. Los inventarios del OSC se cargan solamente con canciones productivas, eliminando el 73% de las canciones no-productivas. Los Éxitos y las Canciones Promedio, los Estrenos Mensuales y el índice se transmiten peri-ódicamente por el local central de almacenaje sin necesidad de que sean solicitadas por las sinfonolas. Durante la transmisión, se requiere un ancho de banda que es necesario para la transmisión de los Éxitos y Canciones Promedio así como para los Estrenos Mensuales, la cual es una transmisión de actualización no-interactiva y puede ser planeada para que se realice en períodos programables; por ejemplo, dos veces al mes. Todas las sinfonolas locales reciben la transmisión no-interactiva de títulos nuevos. Los títulos pu«cden ser cargados por la sinfonola durante el tiempo de transmisión simultán«sa (broadcast). Un requerimiento de un segundo ancho de banda es necesario para la actualización de la transmisión interactiva cuando las sinfonolas solicitan sus VETs a los OSCs basándose en las demandas de los usuarios. Esto ocurre frecuentemente cuando la sinfonola es instalada en una nueva localidad. Tanto el modo interactivo como el no-intera«ctivo se pueden correr simultáneamente. Esto da como resultado un sistema de Entrega Concurrente de Traslapo Coincidente (COCD) para nr?nimizar los requerimientos de ancho de banda y el costo de la transmisión y para mejorar la disponibilidad de transmisión de los VETs. Diferentes clientes pueden solicitar el mismo VET en un tiempo de traslape. Entre más tiempo de traslape hay, las posibilidades de que los clientes compartan la misma entrega de VET es mayor. El tiempo de traslape se promueve ofreciendo costos más bajos a los clientes que toleran un rango de retraso de transmisión más largo. La COCD está comprendida de un sistema de colas, distribuidores, servidores de canal, un controlador COCD y un manejador de petición de conflictos. Una cola incluye Grupos VET los cuales representan una o más Solicitudes de Transmisión VET. Las colas cuentan con un apuntador de concatenación para mover los Grupos VET que completan sus períodos de espera en la cola a otra cola o a un Distnbuidor El Distnbuidor envía el Grupo VET a un Servidor de Canal para su transmisión En el sistema COCD, una TI, como por ejemplo una Sinfonola Personal, envía la Petición de Transmisión VET cuando se necesita que el VET sea transmitido Las Colas, Grupos y Peticiones cuentan con parámetros úmcos de mstrucción Los parámetros de clase mcluyen instruir al sistema COCD cuanto tiempo deberá esperar el VET antes de su transmisión, indicar durante que marco de tiempo ocurnrá la transmisión, instruir al sistema COCD sobre los ahorros en comunicación, e indicar cuando la cola queda habilitada para su transmisión, «etc Los parámetros de disponibilidad mcluyen el indicar al COCD el peor caso de una ventana de retraso esperado para un grupo en esa cola El controlador COCD realiza la tarea de inteligencia y operación del COCD Crea Grupos VET, los inserta y los mueve de cola en cola, actualiza los parámetros y arregla su programación El OSC llamara al COCD al recibir la Petición de las TI's de Transmitir los VETs La COCD determina que Grupos de VET están pendientes de transmisión con el mismo nombre de VET y parámetros de mstrucción compatibles Un nuevo grupo se inserta en la cola si la Solicitud de Transmisión de VET y el Grupo VET no tienen los mismos parámetros de clase De lo contrano la Solicitud de Transmisión de VET es apilada en el grupo Si se solicita un tiempo de retraso más «corto, entonces el grupo se actualiza con los nuevos parámetros de solicitud de disponibilidad y todas las solicitudes apiladas se mueven hacia una cola de disponibilidad más alta que coincida con todos los parámetros de mstrucción En caso de que no se solicite un período de retraso más corto, la solicitud se apila en el grupo Esto asegura que se produzca solo una transmisión para todas las solicitudes pendientes apiladas (stacked) y en espera en el mismo grupo para la transmisión de un mismo VET El Distnbuidor COCD elige Grupos VET desde una o más colas habilitadas y las distnbuye a uno o más canales de servidor El Distnbuidor balancea la elección y distnbucion en función del peso de la cola y del desempeño del canal servidor mediante la implementación de funciones de distnbucion, tales como round robín, fixed pnonty, daisy chain, etc El servidor de canal en la COCD recibe los grupos desde el Distribuidor y ejecuta la transmisión del VET actual. Las Figs. 3, 4 y 5 ilustran un ejemplo del sistema COCD con varias solicitudes de VET en espera. Existen 6 diferentes colas configuradas en el COCD según se muestra. En la Fig. 3, las colas 1, 2 y 3 están concatenadas e ilustran la optimización por disponibilidad de servidores de canal estadísticamente asignados. Si por ejemplo; un Grupo VET X es el primero en una cola y las colas de disponibilidad más alta «en la cadena se encuentran vacías, el Distribuidor jalará el Grupo VET X para su transmisión, causando que la transmisión ocurra antes del tiempo en que fue programada. Esta característica es especialmente apropiada para los servicios de comunicación en donde los servidores de canal se asignan estadísticamente (continúo) porque al OSC se le cobra se use o no se use el canal. La COCD vuelve a programar las solicitudes VET para distribuirlas y así optimizar el uso del tiempo del servidor de canal. En la Fig. 4, las colas 4 y 5 están concatenadas e ilustran la optimización por costos de transmisión de los servidores de canal dinámicamente asignados. Al retrasar la transmisión de los VETs solicitados, se origina una reducción en la transmisión de ciatos y un costo de transmisión más bajo, especialmente cuando los servidores de canal son asignados dinámicamente ya que los portadores se cargan de acuerdo a la cantidad de datos transmitidos. En la Fig. 5, la cola 6 ilustra por si misma la optimización por retraso fijo. En esta ilustración puede existir un tiempo preciso especificado para un grupo particular en cola. Estos VETs dependen del tiempo (time dependant), y por lo tanto no se promueven a una cola de disponibilidad más alta y no son apilados con o dentro de otros grupos VET. Este bloqueo de retraso permite un tiempo de espera más preciso antes de la transmisión. Esta característica es particularmente adecuada para los sistemas de transmisión simultánea (broadcast) los cuales requieren algún tipo de tiempo de transmisión deterministicx». Por ejemplo, con las transmisiones satelitales no-interactivas (TI8 en la Fig. 1) el OSC debe de transmitir los títulos de las canciones (la jerarquía de índice) de las nuevas canciones disponibles. El sistema puede retrasar una tiempo predeterminado; por ejemplo, una semana para que cada sinfonola determine la demanda de cada una de las nuevas canciones antes de que las mismas sean transmitidas. En las Figs. 3 y 4, a las «colas 1 y 4 se les ha asignado un canal servidor a través del Distribuidor 1. Las otras «colas en las Figs. 3-5 están concatenadas al Siguiente Estado o a la siguiente cola. Por ejemplo, en la Fig. 3, la salida de la cola 3 va a la entrada de la cola 2 y la salida de la cola 2 va a la entrada de la «cola 1. La cola 1 ocupa el 66% del tiempo del canal del servidor, mientras que la cola 4 utiliza solo el 33% de la atención del servicio del canal. El sistema de cola de este invento permite una transferencia más eficiente de música a lcxalidades múltiples, dando lugar así al ahorro de tiempo y dinero. La Sinfonola Personal del presente invento puede ser utilizada tanto en el comercio como en el hogar. Para la versión casera, el monitor, el equipo de comunicación, las unidades de recolección de fondos y el sub-sistema de sonido son opcionales y pueden incluirse a voluntad ya que el usuario en la casa podrá utilizar alguna televisión a manera de monitor y un sistema de somdo casero conectado a la PJ. Las Figs. 6a-8c ilustran la operación de un sistema de seguridad de acuerdo al presente invento.
El sistema de seguridad se usa para prevenir la copia inadecuada de canciones almacenadas en la Sinfonola Personal. También previene el almacenamiento no autorizado o la reproducción de música en la Sinfonola Personal. De igual manera previene el uso inadecuado de certificados monetarios usados para «comprar copias de canciones u otros tipos de productos o servicios. En el sistema de seguridad del presente invento, las canciones de cada sinfonola se almacenan en un formato encriptado el cual previene que sean transferidas a otra sinfonola o a otro sistema de almacenamiento. La música transferida a la sinfonola de una de los OSCs también es encriptada. La desencripción de la música transferida requiere de suficientes créditos monetarios; de otra manera, los VETs no pueden ser desencriptados. De igual manera, la coordinación del uso de los créditos monetarios debe de ser controlada por el OSC para así prevenir los incrementos no autorizados en los créditos.
Cada PJ incluye hardware de seguridad el cual se localiza en la tarjeta de audio u otro dispositivo electrónico. El hardware de seguridad, implementado en formato monolítico se utiliza para encriptar y desencriptar información. Ya que el hardware de seguridad es monolítico, solo se pueden accesar los datos de entrada y salida. Todas las «entradas y salidas digitales al hardware de seguridad están en un formato encriptado el cual previene el copiado no autorizado de los VETs o certificados monetarios, así como otros ciatos sensibles. El hardware de seguridad para cada PJ es úni«co y desencriptará y encriptará los datos de manera diferente. Por lo tanto, el hardware de seguridad no es transferible entre las diferentes sinfonolas. Sin embargo, si resultara dañado el hardware de seguridad de una sinfonola, deberá ser reparado con el fin de recuperar y desencriptar los VETs almacenados por ese hardware de seguridad. Se utiliza un juego de llaves públicas y privadas para encriptar y desencriptar VETs en el hardware de seguridad. El OSC puede mantener un índice apropiado para las llaves el cual pu«cde ser usado para reparar o substituir el hardware de seguridad dañado o defectuoso. De preferencia, se requerirá que una persona de mantenimiento accese los datos (después de la entrada de claves u otras medidas de seguridad apropiadas) en el OSC para cargar las llaves necesarias para corregir el hardware de seguridad. El proceso de inicialización para el hardware de seguridad se ilustra en las Figs. 6a y 6b. Según se ilustra en la Fig. 6a, un centro autorizado de el OSC genera una llave TI externa (Tepninal Inteligente o Sinfonola), una llave HS externa (hardware de seguridad), y un número de serie externo para el hardware de seguridad y la TI correspondiente (paso 101). Esta información es encriptada (paso 103) usando una llave HS secreta (paso 102) la cual es conocida exclusivamente en el OSC y el hardware de seguridad específico. La información encriptada llamada a un sobre inicializador, es después enviada al hardware de seguridad de la TI. El sobre de inicialización puede ser transferido de maneras diferentes, incluyendo discos físicos, módem, o a través de una transmisión a la TI específica. El hardware de seguridad desencripta el sobre inicializador (paso 106) para recuperar las llaves externas y el número de serie. Ninguna otra TI conoce la llave Int. HS (105 en la Fig. 6a) utilizada para encriptar el sobre de inicialización, por lo tanto el sobre puede ser desencriptado exclusivamente por la TI para la cual ha sido generado el sobre. Después, el hardware de seguridad determina si la inicialización fue apropiada comparando la llave HS externa con la llave HS interna. Si las llaves no coinciden, esto quiere decir que el sobre de inicialización ha sido corrompido (o no está autorizado) y termina el proceso (paso 109). Alternativamente, la TI puede ser desactivada debido al hecho de que se intentó hacer una modificación no autorizada. Si las llaves no coinciden, entonces la llave TI interna y el número de serie interno se actualizan con la nueva información del OSC (pasos 110, 113). Si el hardware de seguridad está siendo reparado o substituido, la llave TI externa seleccionada por el OSC corresponderá a la llave TI interna del dispositivo donde se encuentra el hardware seguro. Debido a que los VETs son encriptados y desencriptados utilizando la llave TI interna, el hardware de seguridad reparado o substituido puede desencriptar y tocar los VETs previamente almacenados. Los números de serie se utilizan para controlar los créditos monetarios como se «discute a continuación. El proceso para distribuir VETs en conexión con el sistema de seguridad se ilustra en las Figs. 7a, 7b, y 7c. Un VET 201 comprimido incluyendo el costo correspondiente, se encripta (paso 203) en el OSC utilizando una llave VET 202 para crear un sobre VET. La llave VET puede estar basada en el tiempo para prevenir que un código violado/roto sea usado continuamente. El sobre VET se transfiere después a las TIs apropiadas en donde son almacenadas en el almacenaje jerárquico. Puesto que los sobres VET se encriptan al ser almacenados, no pueden ser inadecuadamente copiados por otros. Los sobres VET pueden ser copiados a otras TIs u otros dispositivos de almacenaje pero se requiere de una llave apropiada para desencriptarlos. El hardware de seguridad se utiliza para desencriptar los sobres VET. Primero, se selecciona una llave VET adecuada (paso 216) basándose en la fecha del sobre VET. La llave VET se utiliza para desencriptar el contenido del sobre VET (paso 218). Si la TI cuenta con suficientes créditos monetarios (pasos 207-209), el VET desencriptado se encripta de nuevo, pero esta vez con la llave TI interna del hardware de seguridad (paso 224, Fig. 7b). El VET encriptado se guarda de nuevo en el almacenamiento jerárquico de la TI. Cuando se selecciona una canción para su reproducción, el VET es recuperado del dispositivo de almacenamiento y desencriptado utilizando la llave interna TI (paso 227) en el hardware de seguridad. En los pasos 228-229, el VET es descomprimido, convertido de digital a analógico, y sacado al audio amplificador 230. Los créditos monetarios se utilizan para desencriptar sobres VET. Esto asegura que se reciban los pagos para las canciones proporcionadas a la TI. Como se mencionó anteriormente, el sobre VET incluye un costo. La TI incluye un almacenaje interno 212 de los créditos monetarios disponibles. El costo del VET a desencriptar es comparado con el valor del almacenaje interno 212. Si los créditos internos son suficientes, entonces la cantidad en el almacenaje interno es reducida por el costo del VET (paso 209) y los VETs desencriptados se procesan más adelante, tal y como se discutió anteriormente. Si los créclitos internos no son suficientes, la desencripción es terminada (paso 210). La Fig. 7c ilustra un proceso para dar entrada a canciones desde fuentes diferentes a el OSC. El hardware de seguridad se utiliza para comprimir y encriptar una canción recibida como VET. El VET es dividido en bloqutcs (paso 232), cada uno de los cuales puede ser asociado con un costo. El costo y los datos del VET son multiplexados (paso 235) y encriptados (paso 238) usando la llave VET. El sobre VET resultante se almacena en el almacenamiento jerárquico (paso 240) de la TI para su procesamiicnto posterior. Las Figs. 8a-8c ilustran el proceso para incrementar los créditos monetarios en una TI. Los créditos monetarios se incrementan transfiriendo un certificado monetario a la TI desde el OSC. El certificado monetario es encriptado para prevenir modificaciones no autorizadas. En el paso 301, se crea el certificado con un importe y llaves apropiadas. El certificado monetario (con o sin importe monetario) puede incluir también una nueva llave VET para utilizarse en transferencias VET postfechadas. Después el certificado es encriptado mediante el uso de la llave TI interna de manera que la TI reciba el crédito (paso 303). Claro está que la transferencia de dinero a el OSC desde el propietario de la TI puede ser realizado de maneras diferentes, ¿será necesario mencionarlo?. Nosotros utilizamos satélite, teclado, módem y fax para transferir los créditos monetarios. El certificado se transfiere a la TI a través de un mecanismo de transferencia apropiado. Dichos mecanismos pueden incluir transmisiones directas o a través de transferencias de códigos apropiados para ser capturados en un teclado. La llave TI interna se utiliza para desencriptar el certificado (paso 322). Después, la autenticidad del certificado es probada mediante la comparación de la llave TI externa recibida con la llave TI interna (paso 325) y también comparando el número de serie extemo recibido con el número de serie interno (paso 331). En caso de haber diferencias, el certifícado se considera invalido. Cuando un certificado es invalidado, la transacción puede ser abortada o alternativamente la TI puede ser desactivada (paso 327). Los números de serie se utilizan para asegurar que los certificados no sean falsificados, duplicados o perdidos. Cada certificado cuenta con un número de serie establecido por el OSC. El número de serie en la TI corresponde al último número de serie enviado a la TI. El número de serie se inicializa desde el OSC en el hardware de seguridad como se discutió anteriormente. Cuando cada certificado es recibido, el número de serie es incrementado (paso 331) por una cantidad prdeterminada. Típicamente, los números de serie pueden ser incrementados por uno, pero se podrían utilizar otros valores para mayor protección. Si se determina que el certificado es auténtico, los créditos monetarios internos se incrementan por la cantidad de créditos en el certificado (paso 333). Los certificados monetarios también pueden ser utilizados para transmitir las nuevas llaves VET. Cuando se recibe un certificado, la llave VET se compara con la llave VET interna (paso 335). En «caso de ser diferente se proporciona una nueva llave. Después, el sistema guarda la llave VET junto con la fecha del certificado. La nueva llave VET se utiliza para los VETs recibidos después del certificado y hasta que se realiza el siguiente cambio de VET. Ya que los VETs pueden ser almacenados antes de ser desencriptados, las llaves VET para diversas fechas pueden ser guardadas en una memoria 334 del hardware de seguridad. El certifícado también puede ser utilizado para ajustar el costo del bloque para la creación de VETs que no provengan de el OSC. El costo del bloque interno se establece para el costo del bloque extemo recibido (paso 338). El costo del bloque interno se utiliza en el procesamiento de VET como se discutió anteriormente. El procesamiento termina una vez «que el certifícado ha sido completamente procesado. La Fig. 9 ilustra una segunda implementación del sistema de distribución de música de acuerdo con el presente invento. Igual que en la primera implementación, esta incluye una plataforma global de distribución musical 908 la cual se trata de un centro de servicio operacional. El centro de servicio operacional 908 se puede comunicar con las sinfonolas mechante una variedad de mecanismos. Por ejemplo, las comunicaciones se pueden llevar a cabo por medio de líneas telefónicas utilizando un módem 911, a través de sistemas móviles de almacenamiento 907, 916, como diskettes; o a través de transmisiones satelitales 901. Con las transmisiones satelitales se pueden transferir simultán«camente las canciones y otra información a una gran cantidad de sinfonolas reduciendo así el costo total de transferencia por canción. Una sinfonola Autónoma Escucha (Recibe) Solamente 927 puede ser conectada a un receptor satelital 919 y de esta manera únicamente recibir transmisiones satelitales. Podría no tener comunicación directa con el centro de servicio operacional 908. Alternativamente, una sinfonola Autónoma que Escucha y Habla 926 podrá recibir canciones a través del receptor satelital 918 y transferir información a través de una línea telefónica utilizando un módem 917. Típicamente, esta sería una «conexión telefónica de larga distancia por lo cual resultaría costoso transmitir canciones, pero podría ser utilizada para transferir datos de reproducciones los cuales tienen un volumen mucho menor. El sistema de almacenamiento removible 916; como los diskettes, pueden ser utilizados para la comunicación con sinfonolas Correo Autónomas 925. Las «canciones y los datos de reproducciones tocadas y almacenadas pueden ser transferidos mediante el envío de diskettes desde el centro de servicio operacional al local de la sinfonola en donde son cargadas por un operador. Los costos de distribución de música y los costos de recolección de datos de reproducciones pueden ser reducidos mediante el uso de una región de operador 902. Una de las sinfonolas en la región de operador 902 funciona como sinfonola maestra 906. La sinfonola maestra 906 opera de manera similar a los centros regionales de operación de servicios Rl. R2 de la primera implementación del invento ilustrada en la Fig. 1. Además, la sinfonola maestra 906 funciona como sinfonola de local normal. Por lo tanto, la sinfonola maestra 906 se puede comunicar con el centro de operación de servicio 908 a través de cualquiera de los métodos de distribución, incluyendo módems de línea telefónica 910, almacenamiento movible 907, o recepción satelital 903. La sinfonola maestra 906 también puede ser conectada a través de módems de línea telefónica 910, 913, 914, 915 a una pluralidad de sinfonolas esclavas 922, 923, 924. De preferencia, las sinfonolas esclavas 922, 923, 924 se localizan dentro de la región de llamado local de la sinfonola maestra 906. De esta manera, las canciones pueden ser distribuidas de manera menos costosa desde la sinfonola maestra a las sinfonolas esclavas. Alternativamente, el sistema removible de almacenamiento 912 se puede utilizar para transferir canciones a sinfonolas esclavas 920, 921. Las comunicaciones entre las sinfonolas esclavas y la sinfonola maestra también pueden ser bidireccional. De esta manera, la información relacionada con la reproducción de canciones y las selecciones de nuevas canciones puede ser transferida de regreso a la sinfonola maestra. Desde allí puede ser transferida al centro operacional de servicio 908. Aunque la Fig. 9 ilustra un nivel individual entre el centro operacional de servicio 908 y la sinfonola maestra 906, se puede utilizar cualquier cantidad de centros operacionales de servicio regionales u otras sinfonolas maestras en una estructura jerárquica. Ya que cada sinfonola maestra tencirá comunicación con solo una parte de las sinfonolas esclavas en el sistema, las comunicaciones mediante líneas telefónicas serán suficientes. Una sola lín«ca telefónica puede proporcionar 270 horas de comunicación por mes. Asumiendo que la transferencia de una canción dura aproximadamente 20 minutos, una sola línea telefónica podrá distribuir 2160 «canciones mensualmente. La sinfonola maestra 906 podría proporcionar un promedio de seis canciones nuevas por mes a 360 sinfonolas dedicadas. Con esta cantidad de canciones, a cada sinfonola esclava se le asignarán ventanas de tiempo para accesar a la sinfonola maestra. Al ser accesada, la sinfonola esclava es capaz de transferir la información estadística de reproducciones a la sinfonola maestra y cargar todas las canciones necesarias.
La Fig. 9 también ilustra el uso del presente invento en conexión con las tecnologías de las sinfonolas actuales. Es probable que muchos operadores de sinfonolas tengan un inventario significativo de discos compactos en los cuales hay una gran cantidad de música almacenada. Como se ilustra en la Fig. 9, una sinfonola 927 puede tener una interfase para conectarse a un cambiador de discos compactos 928. El inventario existente de discos compactos puede ser puesto en el cambiador de CD's. Además de seleccionar canciones alamcenadas en la memoria de la sinfonola 927, la sinfonola puede ser programada para operar el cambiador de discos compactos a través de la interfase. Por lo tanto, si el usuario desea escuchar una canción localizada en un CD dentro del cambiador de discos compactos, la sinfonola proporcionara una señal al cambiador de CD's para seleccionar y tocar la canción deseada. Con el fin de operar con el cambiador de discos compactos, se debe dar entrada en la sinfonola a la información sobre los CD's en el cambiador. Un scanner 929 puede ser conectado a la sinfonola para scannear portadas de álbums las cuales serán desplegadas durante el proceso de selección. Se puede utilizar un teclado 930 para dar entrada a la inforrnación de la canción, así como la localización específica de los CD's en el cambiador. Habiéndose descrito algunas implementaciones del invento, quedará claro a los especialistas en el arte que los precedentes son meramente ilustrativos y no limitados, habiéndose presentado únicamente a manera de ejemplo. Numerosas modifi«caciones y otras implementaciones que caen dentro del alcance de la invención se definen en las declaraciones adjuntas. Se declara que:

Claims (45)

R E I V I N D I C A C I O N E S
1. Un sistema de distribución musical para sinfonolas digitales electrónicas locales que comprende: un local central de almacenanuento incluyendo canciones disponibles, gráficos y títulos; un sistema de menú, este sistema de menú incluye el almacenar una parte del menú en una sinfonola de ubicación local y guardar un menú completo en el mencionado local central de almacenamiento; un medio de comunicación entre el mencionado local central de almacenamiento y las sinfonolas locales; y un programador para coordinar la transmisión desde el mencionado local central de almacenamiento a las sinfonolas locales.
2. Un sistema de distribución musical para sinfonolas digitales electrónicas locales de conformidad con la reivindicación 1, en donde el sistema de menú mencionado incluye un algoritmo estadístico de substitución para recuperar porciones adicionales de un menú basado en accesos locales a la mencionada sinfonola.
3. Un sistema de distribución musical para sinfonolas digitales electrónicas locales de conformiciad con la reivindicación 1 , en donde las canciones son colocadas en la sinfonola local en base a las solicitudes del usuario sobre la disponibilidad.
4. Un sistema de distribución musical para sinfonolas digitales electrónicas locales de conformidad con la reivindicación 1, en donde la música es recuperada automáticamente por la sinfonola local, basándose en las preferencias de los usuarios en diferentes locales.
5. Un sistema de distribución musical para sinfonolas digitales electrónicas locales de conformidad con la reivindicación 1, en donde el mencionado programador arregla la transmisión simultán«3a (broadc-ast) de canciones a una pluralidad de sinfonolas.
6. Un sistema de distribución musical para sinfonolas digitales electrónicas locales de conformidad con la reivindicación 1, en donde el mencionado programador retrasa la transmisión de música dentro de un período de tiempo solicitado para mejorar los tiempos de transmisión y p?ümizar los costos.
7. Un sistema de distribución musical para sinfonolas digitales electrónicas locales de conformidad con la reivindicación 1, en donde la mencionada transmisión se realiza automáticamente para las actualizaciones no-interactivas.
8. Un sistema de distribución musical para sinfonolas digitales electrónicas locales de conformiciad con la reivindicación 1, en donde la mencionada sinfonola local incluye un sistema de pago por adelantado para permitir el acceso automático al sistema de almacenamiento central.
9. Un método para distribuir música selectiva y óptimamente, incluyendo los pasos de: transmitir simultán«camente (broadcast) una lista de nuevas canciones disponibles desde una localidad de almacenamiento central a una pluralidad de sinfonolas; cargar la lista dentro de una sinfonola local; el capturar las demandas del usuario en la sinfonola local; procesar estadísticamente las demandas del usuario en la sinfonola local; determinar que nuevas canciones cargar utilizando los resultados del paso de procesamiento; cargar créditos a través de pagos en la sinfonola local; cargar automáticamente las canciones solicitadas desde la localidad de almacenamiento central dentro de la sinfonola local; disminuir el número de créditos correspondiente a la carga; y almacenar localmente una parte de la música disponible.
10. Un método para distribuir música selectiva y óptimamente de conformidad con la reivindicación 9, que incluye adicionalmente: recuperar música desde una jerarquía de clases de música, siendo la jerarquía completamente almacenada en la localización de alma«cenamiento central, y una parte almacenada en la sinfonola local.
11. Un método para distribuir música selectiva y óptimamente de conformidad con la reivindicación 9, que incluye adicionalmente: diferir transmisión de música basándose en las necesidades del usuario local; y transmitir la música solicitada, basándose en las necesidades del usuario local, desde la localización de almacenamiento central simultáneamente a múltiples sinfonolas, cuando los tiempos de entrega se traslapen.
12. Un método para transmitir óptimamicnte selecciones de música en un sistema de distribución musical que comprende: mantener estadísticas en una sinfonola electrónica digital, relacionadas con el número de veces que un nodo es revisado por el usuario en una jerarquía del menú; utilizar esas estadísticas para indicar cuando un nodo ha sido revisado un predeterminado número de veces; enviar una solicitud automáticamente para la música actualizada desde la sinfonola al local de almacenamiento central, basándose en las mencionadas estadísticas determinadas en la sinfonola; recibir la música solicitada dentro de un período específico de tiempo en dicha sinfonola; dicho paso de recepción incluyendo la transmisión de música desde el local de almacenamiento central simultáneamente a una pluralidad de sinfonolas; y almacenar una parte de la jerarquía del mencionado menú en la sinfonola.
13. Un método para transmitir óptimamente selecciones de música en un sistema de distribución musical de conformidad con la reivindicación 12, en donde la mencionada jerarquía del menú incluye niveles para tipos de música, subtipos, álbums y canciones.
14. Un método para transmitir óptimamente selecciones de música en un sistema de distribución de conformidad con la reivindicación 12, en donde las mencionadas estadísticas representan las preferencias reales del usuario en el local de la sinfonola.
15. Un método para transmitir óptimamente selecciones de música en un sistema de distribución de conformidad con la reivindicación 12, en donde la mencionada transmisión es coordinaida retardando algunos tiempos de transmisión dentro de un período de tiempo aceptable y de acuerdo a una programación para incrementar la eficiencia de transmisiones y nrúnimizar los costos.
16. Un sistema de seguridad para un sistema de distribución de música que cuenta con por lo menos un centro de distribución y una sinfonola, que comprende: medios para recibir los primeros datos encriptados, de acuerdo a una primera manera; primeros medios de desencripción para desencriptar los mencionados primeros datos para crear un segundo dato; medios de encripción para encriptar el mencionado segundo dato de una segunda manera para crear un tercer dato; segundos meciios de desencripción para desencriptar el mencionado tercer dato para generar un cuarto dato.
17. El sistema de seguridad de conformidad con la reivindicación 16, en donde el mencionado cuarto dato pueda ser ejecutado para producir sonidos, gráficos, texto e imágenes de video.
18. El sistema de seguridad de conformiciad con la reivindicación 16, en donde dichos medios de recepción, los primeros medios de desencripción, los medios de encripción y los segundos medios de desencripción se localizan en un hardware de seguridad en por lo menos una sinfonola.
19. El sistema de seguridad de conformiciad con la reivindi«cación 18, en donde dichos meciios de recepción, los primeros meciios de desencripción, los medios de encripción y los segundos medios de desencripción se localizan en un hardware de seguridad en por lo menos una smfonola.
20. El sistema de seguridad de conformidad con la reivindicación 18, en donde el sistema de distribución de música incluye una pluralidad de sinfonolas; en donde cada sinfonola incluye sus medios de recepción respectivos, los primeros medios de desencripción, medios de encripción y los segundos medios de desencripción; y en donde la segunda manera utilizada para encriptar los mencionados segundos datos es diferente para cada sinfonola.
21. El sistema de seguridad de conformiciad con la reivindicación 16, que comprende adicionalmente: medios de segunda encripción para encriptar datos en la mencionada primer manera para generar los primeros datos; y medios de transmisión para transmitir los mencionados primeros datos.
22. El sistema de seguridad de conformidad con la reivindicación 21, en donde los mencionados segundos medios de encripción y de transmisión se localizan en por lo menos un centro de distribución.
23. El sistema de seguridad de conformidad con la reivindicación la declaración 22, que comprende adicionalmente: meciios para cambiar la mencionada primera manera usada para encriptar ciatos para crear una nueva primera manera usada para que datos sean transmitidos después de que la primera manera es cambiada; medios para transmitir una nueva primera manera para encriptar datos a primeros medios de desencripción.
24. El sistema de seguridad de coriformkiad con la reivindicación, en donde los mencionados primeros medios de desencripción incluyen: meciios para determinar cuando los mencionados primeros datos son recibidos; medios para determinar si los mencionados primeros datos son encriptados en la primer manera o en la mencionada nueva primer manera, basándose en cuando los primeros datos son recibidos; y m«sdios para desencriptar los mencionados primeros datos, basándose en una de la mencionada primer manera y en la mencionada nueva primera manera.
25. El sistema de seguridad de conformidad con la reivindicación 23, en donde los mencionados medios para la primer desencripción incluyen medios para recibir la mencionada nueva primer manera, y medios para verificar que la mencionada nueva primer manera es auténtica.
26. El sistema de seguridad de conformidad con la reivindicación 16, que comprende adicionalmente: meciios para transmitir la mencionada segunda manera a los mencionados meciios de encripción y a los mencionados segundos medios de desencripción; medios para la recepción de la mencionada segunda manera; y medios para verificar que la mencionada segunda manera es auténtica.
27. El sistema de seguridad de conformidad con la reivindicación, en donde los mencionados primeros datos incluyen un costo asociado con los primeros datos; «sn donde los primeros medios de desencripción incluyen meciios para determinar si un crédito es mayor que el costo; y en donde los primeros medios de des«cncripción desencriptan los primeros datos solo cuando el crédito es mayor que el costo.
28. El sistema de seguridad de conformidad con la reivindicación 27 que comprende adicionalmente medios de crédito para incrementar el mencionado crédito.
29. El sistema de seguridad de conformidad con la reivindicación, en donde los mencionados medios de crédito incluyen: medios para recibir una cantidad para incrementar el crédito; medios para determinar si la cantidad es auténtica; y medios para incrementar el crédito en caso de que la cantidad sea auténtica.
30. Un dispositivo monolítico para proveer seguridad en un sistema para la distribución de paquetes electrónicos de datos, que comprende: un circuito para desencriptar un paquete electrónico de datos para generar un paquete desencriptado; un circuito para encriptar una parte del paquete desencriptado para generar un paquete encriptado; y un circuito para dar salida al paquete encriptado.
31. El dispositivo monolítico de conformidad con la reivindicación 30, que comprende adicionalmente un circuito para determinar si un nivel de crédito excede el nivel de crédito necesario; y en donde el mencionado circuito para encriptar y el circuito para dar salida solo se ejecuta si el nivel de crédito excede el nivel de crédito necesario.
32. Un dispositivo monolítico para proveer seguridad en un sistema para la distribución de paquetes electrónicos de datos, que comprende: un circuito para desencriptar un paquete encriptado para generar un paquete desencriptado; un circuito de conversión de digital a analógico para convertir los datos en el paquete desencriptado en datos analógicos; y un circuito para dar salida a los datos analógicos.
33. El dispositivo monolítico de conformidad con la reivindicación 32, que comprende adicionalmente un circuito para descomprimir el paquete desencriptado y así generar un paquete descomprimido; en donde los circuitos de conversión de digitales a analógicos conviertan los datos en paquetes descomprimidos en datos analógicos.
34. Un dispositivo monolítico para proveer seguridad en un sistema para la distribución de paquetes electrónicos de datos, que comprende: un circuito de conversión de digital a analógico para convertir los ciatos analógicos en datos digitales; un circuito para encriptar los datos digitales y generar un paquete de datos generales; y un circuito para dar salida al paquete de datos.
35. El dispositivo monolítico de conformiciad con la reivindicación 34, que comprende adicionalmente un circuito para la compresión de datos digitales; y en donde el circuito para encriptar encripta los datos digitales comprimidos.
36. El dispositivo monolítico de conformidad con la reivindicación 34, que comprende adicionalmente un circuito para determinar si un nivel de créaito excede el nivel de crédito necesario; y en donde el circuito para encriptar y el circuito para ciar salida solamente ejecuten en caso de que el nivel de crédito exceda el nivel de crédito necesario.
37. Un dispositivo monolítico para proveer seguridad en un sistema para la distribución de paquetes electrónicos de ciatos, que comprende: un circuito para desencriptar un paquete de datos para generar un paquete desencriptado; y un circuito para autenticar una fuente del paquete de ciatos, basándose en los datos del paquete desencriptado.
38. El dispositivo monolítico de conformidad con la reivindicación 37, que comprende adicionalmente: un circuito para ajustar un nivel de crédito basándose en los ciatos del paquete desencriptado y una salida del circuito para autenticarlo (o verificar su autenticidad).
39. Un sistema de distribución musical que comprende: un local de almacenamiento central incluyendo las canciones disponibles; una pluralidad de sinfonolas computarizadas; y por lo menos un local de almacenamiento regional comunicándose con el local de almacenamiento central y la pluralidad de las sinfonolas computarizadas, al menos un local de almacenamiento regional almacenando una parte de las canciones disponibles y transfiriendo canciones disponibles a las sinfonolas computarizadas.
40. El sistema de distribución musical de conformidad «con la reivindicación 39 que comprende adicionalmente: un primer sistema de comunicación entre el local de almacenamiento central y por lo menos un local de almacenamiento regional; y un segundo sistema de comunicaciones entre al menos un local de almacenamiento regional y cada pluralidad de sinfonolas computarizadas.
41. El sistema de distribución musical de conformidad con la reivindicación 40, en donde el primer sistema de comunicación incluye un sistema de transmisión satelital, una línea telefónica, y un diskette enviado por correo.
42. El sistema de distribución musical de conformidad con la reivindicación 40, en donde el segundo sistema de comunicaciones incluye un sistema de transmisión satelital, una línea telefónica y un disk«ctte enviado por correo.
43. El sistema de distribución musical de conformiciad con la reivindicación 40, en donde por lo menos un local de almacenamiento regional incluye una sinfonola maestra.
44. Una sinfonola computarizada que comprende: medios de recepción para recibir canciones desde un local de almacenamiento central; una memoria para almacenar canciones; medios de reproducción para tocar las canciones almacenadas; una interfase para dar salida a las señales que controlan el cambiador de discos compactos.
45. La sinfonola computarizada de conformidad con la reivindicación 44, que comprende adicionalmente: medios de selección del usuario para seleccionar una canción almacenada en la memoria y en un disco compacto en el cambiador de discos compactos adjunto; y medios para dar salida a las señales de control en el cambiador de discos compactos a través de se para ejecutar la canción seleccionada en el disco compacto.
MXPA/A/1997/007917A 1997-04-04 1997-10-14 Sistema para distribuir musica selectivamente MXPA97007917A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US833265 1997-04-04
US08/833,265 US5959945A (en) 1997-04-04 1997-04-04 System for selectively distributing music to a plurality of jukeboxes
US833,265 1997-04-04

Publications (2)

Publication Number Publication Date
MX9707917A MX9707917A (es) 1998-10-31
MXPA97007917A true MXPA97007917A (es) 1999-01-11

Family

ID=

Similar Documents

Publication Publication Date Title
US5959945A (en) System for selectively distributing music to a plurality of jukeboxes
US9591340B2 (en) Method for the distribution of audio-visual information and a system for the distribution of audio-visual information
EP0195098B1 (en) System for reproducing information in material objects at a point of sale location
EP0649121B1 (en) Digital information accessing, delivery, and reproduction
EP0786123A1 (fr) Procede de communication pour systeme de reproduction audiovisuelle numerique intelligent
EP0934565B1 (en) A digital information library and delivery system
EP1025498B1 (en) Method and apparatus for targeting a digital information playback device
US20020062252A1 (en) System and method for providing access to electronic works
US7917643B2 (en) Digital information library and delivery system
MX2007000900A (es) Metodo y aparato para peticiones de contenido interactivo en un lector multiple de discos compactos de computadora en red.
GB2364430A (en) System for selectively distributing music
MXPA97007917A (es) Sistema para distribuir musica selectivamente
GB2364431A (en) System for selectively distributing music
JP2004514974A (ja) コンピュータ・ネットワークを用いてデジタル・データを含むファイルを配布するためのシステム