MXPA03002027A - Metodo y sistema de publicidad computarizada. - Google Patents

Abstract

La publicidad se presenta en una pantalla de computadora (10) bajo la forma de un objeto multimedia animado al que nos referiremos en la presente como "Shoshkele(r)" almacenado en el servidor Web para shoshkeles (W). El Shoshkele(r) aparece en la pantalla (10) en forma intrusiva e impredecible para el usuario, y su aparicion esta totalmente fuera del control de este. El objeto Shoshkele(r) puede moverse a traves de toda la pantalla (20) y se encuentra en la capa mas alta del visualizador del programa de navegacion, de modo tal que no esta cubierto por ninguna ventana u objeto. Tambien, puede proveer sonido, incluyendo palabras, musica y efectos sonoros almacenados en la base de datos (20) de manera que basandose en esos datos, el generador de contenido de la pagina dinamica (3) puede generar una pagina web dinamica con shoshkele y su valor como entretenimiento llaman la atencion del usuario.

Description

MÉTODO Y SISTEMA DE PUBLICIDAD COMPUTARIZADA Campo da la Invención Esta invención se relaciona, en términos generales, con la publicidad en medios de comunicación nuevos, tales como Internet y programas de software y, en particular, con el método y sistema a implementar para llevar a cabo publicidad. Antecedentes de la Invención Los usuarios de Internet son conscientes del volumen creciente de material publicitario que aparece en ese medio, tipicamente en forma de banners (pancartas publicitarias) con el mensaje del anunciante. No obstante, la efectividad de estos parece decrecer en forma proporcional al aumento de su volumen. Y esto se debe a que esta forma de publicidad padece de una serie de deficiencias. Por un lado, los banners están siempre presentes y son todos demasiado similares, por lo cual no sólo es poco el interés que despiertan en el usuario sino que además es demasiado fácil ignorarlos. Por otro lado, el usuario puede simplemente avanzar en su pantalla (scroll) y hacerlos desaparecer. Además, los banners ocupan un espacio considerable de la pantalla y esta termina atiborrada de datos. Surge, entonces, la gran necesidad de una forma de publicidad más efectiva y con un contenido más atractivo.

Originariamente, la mayor parte de la publicidad en Internet eran simples fotos encuadradas en un marco rectangular (Banners, ventanas automáticas); a veces una sola imagen era suficiente, en otros casos el comercial consistía en una secuencia de imágenes (GIF animadas) . Luego, se fueron desarrollando nuevos tipos de publicidades que incluían sonido y a veces interactividad, y a las que se ha atribuido el nombre de rich media (medios enriquecidos o interactivos) . Estas incluyen banners Java; Interstitials, Superstitials, Flash banners, banners Shockowave y ventanas automáticas ("pop-up") que utilizan estas tecnologías u otras propietarias. Aunque abundan las definiciones, podría decirse que rich media es básicamente cualquier tipo de aviso publicitario que no se limita a imágenes estáticas. A la publicidad que incluye imágenes en movimiento, sonido e interactividad se le denomina generalmente rich media. No obstante, e independientemente de la tecnología utilizada, todos estos formatos poseen una característica en común: siempre existen en una forma predeterminada y frecuentemente dentro de un tamaño predeterminado. Ya sea en un marco dentro de una ventana, o que ocupe una ventana automática completa ("pop-up"), todas las unidades publicitarias anteriores a esta invención habitan un espacio rectangular. Según la presente invención, la publicidad se presenta en una pantalla de computadora en forma de objetos o figuras de multimedia animados a los que nos referiremos como objeto "Shoshkele®". Shoshkele® es una marca registrada y de servicio de United Virtualities, Inc., propietaria de la presente solicitud de patente. El objeto Shoshkele® irrumpe en la pantalla en forma intrusiva para el usuario, sin el menor control de éste. El objeto Shoshkele® puede moverse a través de toda la pantalla y se encuentra en la capa superior (top layer) del visualizador (display) del programa de aplicación, preferiblemente en una ventana de navegación, en un sistema operativo como Windows, de modo tal que no es cubierto por ninguna ventana u objeto. Claro que el Shoshkele® puede estar en una capa inferior si las que están por encima de éste son transparentes al menos en cierto grado. También puede proveer sonido, incluyendo palabras, música y efectos sonoros. La aparición esporádica del Shoshkele® y el entretenimiento que ofrece llaman la atención del usuario. Este concepto publicitario y la creación de los objetos Shoshkele® pueden llevarse a cabo con las tecnologías existentes . Los Shoshkele® son animaciones audio-visuales manipuladas por el navegador, agnósticas en cuanto a plataforma, de movimiento libre, de múltiples formas y tamaños, que no exigen la descarga de un conector (plug-in) para funcionar. Un objeto Shoshkele® es un aviso publicitario audio-visual: contiene imágenes y sonidos totalmente sincronizados; es de flotación libre; puede tomar cualquier forma, figura o tamaño, mezclándose o contrastándose así con el contenido; y su funcionamiento es independiente de un conector, ya que utiliza alguna de las numerosas soluciones técnicas disponibles en un momento determinado . Una característica que diferencia a los Shoshkele® de cualquier otra clase de aviso publicitario, es que todos los demás tienen forma y tamaño predefinido a los que el aviso debe ajustarse y restringirse. Funcionan dentro de un marco dado y están limitados a éste, ya sea un banner o una ventana de navegación independientemente del contenido y sin ninguna limitación en cuanto a forma, figura o tamaño. No tienen límites predeterminados. Los Shoshkele® habitan cualquier ventana de navegación, acompañando al contenido, pero funcionan con total independencia de éste. Esto significa que los Shoshkele® no necesitan ser tomados en cuenta al diseñar o modificar una página. Ni tampoco dependen del lanzamiento de su propia ventana exclusiva. Asimismo, la mayoría de los productos de rich media requieren la instalación de un conector para funcionar. Sin éste, el servidor del aviso publicitario lanza una versión no interactiva (non-ric media) de la misma, que básicamente consiste en una imagen animada GIF, jpeg o PNG. Todos los avisos publicitarios audio-visuales anteriores a la tecnología Shoshkele® exigían la presencia de un conector. Los de imagen solamente podrían no necesitarlo. Los de sonido solamente podrían no necesitarlo. Pero la interactividad y sincronización de ambos (imagen y sonido) ha dependido siempre de conectores o de Java applets. No así los Shoshkele®, lo que los hace universales. Conforman la única tecnología publicitaria de rich media que funciona independientemente de la presencia o ausencia de un conector específico, y lo único que requieren es un navegador compatible con JavaScript y Layers (más del 99% del mercado a partir de Agosto de 2001) . Esto se hace posible mediante un concepto básico apoyado por una serie de herramientas. Tal concepto es que todas las computadoras multimedia que utilizan una interfase gráfica de usuario son inherentemente capaces de exhibir un Shoshkele®, aunque no siempre a través de la misma tecnología. Entonces, se hace necesario determinar qué tecnología soporta una computadora determinada y cómo crear un aviso publicitario específico que se ajuste a esa(s) tecnología ( s ) . Los Shoshkele® pueden distribuirse en una variedad de medios informáticos tales como wrapware (software comercial) , freeware (software gratuito) y shareware (software parcialmente gratuito) y otras categorías de software, sitios web de Internet, así como superficies de pantalla, ya sean existentes o a ser desarrolladas (ventanas, tablas, paredes, parabrisas, prendas, etc.) Una cookie identifica al cliente y un script ordena los diferentes Shoshkele® de una base de datos, según los parámetros históricos de exposición al Shoshkele® del cliente. Se inserta el script de JavaScript en una página que ejecuta un objeto de FLASH o GIF animada y el sonido. La animación y el sonido estarán sincronizados. El formato de sonido podrá ser WAV, MP3, Quicktime, Real_Audio, AVI, patentado, etc. con o sin conector. Se inserta una etiqueta (tag) Shoshkele® en cada página web desde un proveedor de contenido. Cuando la etiqueta Shoshkele® es ejecutada dentro de una página web, el usuario se conecta a un servidor Shoshkele®, y una cookie transmite su identidad y la información Shoshkele® histórica. El servidor Shoshkele® selecciona el Shoshkele® apropiado en base al historial de visualización de Shoshkele® del cliente y a la tecnología disponible en su computadora. El modelo web de Shoshkele® también es aplicable a todas las tecnologías inalámbricas y sistemas operativos para aparatos eléctricos (PCS, Palm OS, Windows CE, Aperios Sony, General Magic, Set Top Boxes, etc.) Los Shoshkele® se comercializan con untamente con las agencias de publicidad, agencias de prensa, proveedores de Internet (ISPs) , proveedores de contenido, etc. En las Plataformas Web, el precio se puede determinar en base al Costo por cada Mil Impresiones (CPM) y de acuerdo con el tráfico en la página web en que aparece el Shoshkele®, o en base a "cliqueos" ( clickthroughs ) reales al sitio del patrocinador, o por segundo, por usuario, o en base a una combinación de estas variables. Los usuarios recibirán diversas formas de incentivo tales como: premios sorpresa para aquellos que opten por el cliqueo inmediatamente ("lo cliqueas o lo pierdes") , o para el usuario número un" que cliquee, etc. Para acrecentar el interés, los Shoshkele® pueden programarse de manera tal que cuenten una historia. Algunos programas de software pueden tener más de un patrocinador. Los programas de Shoshkele® pueden ejecutarse desde Windows, Macintosh o en la aplicación en cuestión. Los Shoshkele® aparecen de vez en cuando, por ejemplo, cuando se abre un menú, en lugar de los comandos. En otras Plataformas No Web, como por ejemplo un software pagado, los Shoshkele® pueden ser menos intrusivos, considerando que el usuario de hecho pagó por el software. En este caso, los Shoshkele® incrementarán la productividad en lugar de interferir con ésta (por ejemplo, un Asistente de Office que exhiba una camiseta con el producto promocionado) . En todos los casos los Shoshkele® pueden asemejarse a celebridades (voz y/o imagen) para aumentar la conciencia de marca del producto promocionado.

Breve Descripción de los Dibujos Tanto la descripción precedente como la de otros objetos, características y ventajas de esta invención serán comprendidas en su totalidad a partir de la siguiente descripción detallada de las representaciones preferidas actualmente, con referencia a los gráficos que se acompañan, en los cuales: La Figura 1 es un diagrama de bloques funcional que ilustra el sistema que utiliza la presente invención; La Figura 2 es un diagrama de flujo que ilustra la operación del monitor 10 del usuario de la Figura 1; La Figura 3 es un diagrama de flujo que ilustra el proceso que determina qué debe utilizarse para producir un Shoshkele® en la computadora de un usuario; La Figura 4 es un diagrama de bloques que ilustra el modelo comercial para administrar la publicidad computarizada de acuerdo con la presente invención; y La Figura 5 es un diagrama de bloques que ilustra el modelo comercial para administrar un servicio de saludo computarizado de acuerdo con la presente invención. Descripción detallada da las representaciones preferidas Con referencia los detalles de los gráficos, la Figura 1 es un diagrama de bloques funcional que ilustra un sistema que utiliza la presente invención. Una cantidad de usuarios U se comunica en calidad de clientes con uno o más servidores C de contenido por Internet I, para recibir contenido multimedia de un proveedor de contenido. Dentro de una página web enviada por un servidor C, el usuario encontrará una etiqueta que transferirá su computadora al servidor web del Shoshkele®. El servidor W coopera con el sistema ?, o lo incluye, siendo que dicho sistema S representa la presenten invención para llevar a cabo su método. El sistema comprende un monitor 10 de un usuario de un sitio web, una base de datos 20 y un generador 30 de contenido de páginas dinámicas. En la operación, el monitor 10 del usuario controla el acceso de todos los usuarios al servidor W web e identifica a los usuarios mediante el uso de cookies. La identidad del usuario es transmitida a la base de datos 20, que brinda información sobre el usuario al generador 30 de contenido de páginas dinámicas, el cual genera un Shoshkele® que será insertado en la página web que el usuario está visitando. El monitor 10, la base de datos 20 y el generador 30 de contenido de páginas dinámicas podrían, aunque no necesariamente necesitan, ser desarrollados como programas de software por separado que funcionen en la misma computadora que el servidor web W. La Figura 2 es un diagrama de flujo que ilustra la operación del monitor 10 de usuario. La operación comienza en el bloque 100 con la llegada del usuario que se detecta en el bloque 102. En este punto, el servidor W envia preferentemente un script al usuario. Esto hace que su computadora sea interrogada para localizar una cookie del Shoshkele® y asi determinar cuál es la tecnología presente (por ejemplo, la marca y versión de su software de navegación y qué conectores están instalados) . Luego, en el bloque 104 se determina si este es un usuario nuevo (este sería el caso, por ejemplo, si el usuario no tuviera cookies del Shoshkele©) y en ese caso, se envía a su computadora una cookie del Shoshkele® en el bloque 106. Esta cookie contiene información identificatoria para el usuario y un registro de los accesos recientes de este usuario al Shoshkele®. Así, antes de que la cookie sea enviada al usuario, sería actualizada con información sobre el Shoshkele® que se elabora para él. La operación finaliza en el bloque 116. Si en el bloque 104 se determinara que no se trata de un nuevo usuario, se extrae información de la cookie del Shoshkele® del usuario en el bloque 108 y se utiliza para actualizar la base de datos 20. En este punto, la base de datos recibiría la información completa almacenada en la cookie sobre los accesos del usuario al Shoshkele®. En el bloque 114, se provee información del usuario al servidor para la preparación de un Shoshkele®, luego de lo cual la operación finaliza en el bloque 116. Debe advertirse que antes de tal finalización. La información de acceso del usuario al Shoshkele® seria registrada en si cookie. El software de animación preferido para la producción de un Shoshkele® en una página web es Flash de Macromedia. Sin embargo, como se aclara a continuación, se considera que el Shoshkele® funciona en prácticamente cualquier computadora. La animación Shoshkele® se recrea en Flash y el audio que acompaña es codificado en P3 por el mismo programa Flash desde una web original. Luego, un script JavaScript de dominio público se modifica para permitir que soporte y contenga cualquier objeto, incluidas animaciones de diferentes tamaños y formas y que posiciones al Shoshkele® en cualquier punto de la pantalla. Ese script de JavaScript inserta un objeto de Flash en la capa superior del display de la ventana del navegador, tornándose imposible el desplazamiento sobre ésta (scroll) . Otro script es escrito e insertado con el fin de comunicarse con el objeto de Flash para medir el tiempo de ejecución (ejemplo activación a los veinte segundos de haber sido descargada la página) . Este sistema funcionará solamente sin interferir con la página de fondo en las versiones de Internet Explorer 4.0 o superiores, y debe tener instalado el conector de Flash. Como tecnología alternativa para producir un Shoshkele®, un script de JavaScript adquiere una imagen GIF animada como en el ejemplo anterior, pero en lugar de contener un objeto de Flash, contiene un objeto Gif. Asimismo, el código HTML adquiere un objeto de WAV. Para obtener la línea de tiempo deseada para el Shoshkele®, se utiliza una función del programa Dreamweaver llamada "linea de tiempo" (Time Line) . La sincronización entre los objetos GIF y WAV (animación y audio) se logra a través de aquella inserción. Toda el área que circunda al objeto GIF permanecerá transparente, revelando lo que yace en la capa inferior. De este modo. El navegante ve un objeto o una figura y no un rectángulo o una ventana rectangular. Esto funcionará tanto con Internet Explorer como con Netscape en sus versiones 4.0 y superiores, y con otros navegadores que posean tecnología de capas (layers). Las páginas HTML provistas por el servidor W pueden acceder a ambas tecnologías y activarán la primera opción si toda la tecnología requerida está presente en la computadora del usuario, o la segunda opción en caso contrario. El usuario jamás advertirá que se ha hecho una elección. La Figura 3 es un diagrama de flujo que ilustra el proceso por el cual se determina qué script utilizar. El proceso comienza ene 1 bloque 200, y en el bloque 210 se determina cuál es la tecnología disponible en la computadora del usuario que recibirá el Shoshkele®. Si la computadora tiene Internet Explorer 4.0 o superior y Flash, se creará un script en el bloque 11, el cual producirá una imagen Flash coordinada que contenga MP3 u otros archivos de sonido. Si la computadora carece de esta tecnología, se produce un script en el bloque 240 que genera un archivo GIF animado y un archivo WAV sincronizado, como se indica precedentemente. En el bloque 250, se genera el código apropiado para producir el Shoshkele® en la página HTML enviada al usuario desde el servidor. En este caso el proceso finaliza en el bloque 260. El script de JavaScript original en base al cual se generan los scripts que operan los Shoshkele® es de dominio público, pero todas las modificaciones fueron realizados a los fines de la presente invención y son innovadoras en su resultado, es decir que permiten cualquier animación, en diferentes tamaños, en cualquier punto de la pantalla, logrando así un resultado único: los Shoshkele®. La Figura 4 es un diagrama de bloques que ilustra un método comercial para la publicidad computarizada, Se estima que los Shoshkele® se podrían obtener a través de una organización 300 llamada MediaSource. Los Shoshkele® se pueden comercializar a través de agencias de publicidad 340 que podrían ofrecerlos a sus clientes (ejemplo, patrocinador 310) para producir comerciales ( "shoshmercials" ) . El patrocinador 310 le abonará a una compañía productora 310 por la elaboración de los Shoshkele®. En una primera etapa, los Shoshkele® se podrán solicitar a MediaSource, con scripts preparados. En una etapa posterior MediaSource ofrecerá un kit de herramientas -"el shoshkelizador" ("shoshkelizer") que permitirá a la productora 330 o a algún otro subcontratista la creación de un Shoshkele® pagando derechos de licencia a MediaSource. Una vez producido el Shoshmercial, éste se le enviará a un usuario en cualquier página a la cual el proveedor de contenido 320 proporcionará etiquetas para la inserción de un Shoshkele® en el contenido. Preferentemente, el anunciante pagarla a MediaSource una tarifa acordada por la creación del Shoshkele®, y otra por impresión (una impresión = una exhibición a un visitante) , que incluirla una tarifa por la duración de la impresión. MediaSource negociaría con el proveedor de contenido y le pagaría los cargos correspondientes. Alternativamente, el proveedor de contenido le pagaria a MediaSource un monto a determinar, por Shoshkele® y luego por impresión. Todos los códigos que activan el Shoshkele® permanecerían en los servidores de MediaSource de modo tal que el acceso a la fuente de la página no signifique poder copiar el código del Shoshkele®. Por ejemplo: la agencia de Budweiser podría volver a MediaSource por un Shoshkele® de cinco segundos de Magic Johnson bailando. La agencia podría solicitar exposición en el mercado del sudoeste estadounidense a través de Yahoo u otro portal (es decir, el proveedor del contenido 320) . La agencia 340 le proveería a MediaSource una animación en medios digitales (ejemplo, preparada por la productora 330) de acuerdo con las especificaciones de MediaSource. MediaSpurce prepararía la codificación necesaria para transformarlo en un Shoshkele® y el webmaster en Yahoo insertaría etiquetas en la página de Yahoo dirigidas al servidor de Shoshkele®. Por esto, MediaSource cobrará "X" dólares. El Shoshkele® se activaría hasta que ciertos códigos se envíen allí a través de Internet. Una vez activado el Shoshkele®, en cada visita a Yahoo por un visitante reconocido como del sudoeste estadounidense, y cada vez que se active el Shoshkele® se le pagará a MediaSource "Y" centavos. La agencia recibirá un porcentaje del ingreso que obtenga MediaSource por cada cliente que aquella le lleve a MediaSource. La Figura 5 es un diagrama de bloques que ilustra un sistema de salido computarizado mediante el uso de Shoshkele®. Actualmente, hay tarjetas de saludo en Internet pero nunca se utilizan conjuntamente con páginas de fondo (background) de publicidades pagas. Al crear un saludo a partir de una plantilla con opciones, cualquier usuario de Internet podrá enviar un saludo Shoshkele® a otro usuario de Internet. Este Shoshkele® aparecerá en el fondo de una página de Internet seleccionada por MediaSource, no por el visitante, de modo tal que MediaSource pueda cobrarle al sitio por tal concepto.

Ej emplo : Un visitante 420 de Internet llega a la portada 400 (horaepage) del creador del saludo Shoshkele® (MediaSource) donde selecciona uno de una galería de objetos y figuras (incluyendo su propia foto) . Luego, elige acciones y mensajes orales, cantados o escritos de una galería de voces (incluida la suya propia) . Posteriormente, ingresa su propio nombre y dirección de correo electrónico e indica a qué persona desea enviarle el saludo Shoshkele® (nombre y dirección de correo electrónico) . De este modo el sistema automático de MediaSource envía un correo electrónico al destinatario 410 señalándole a éste una página web (en servidores de MediaSource) donde puede cliquear e ir a recibir el saludo Shoshkele® que lo está esperando. Una vez allí, el destinatario se encuentra con una página regular y/o diseñada especialmente, preparada por un proveedor de contenido o anunciante 430, por ejemplo Yahoo, y aparece el saludo Shoshkele®. MediaSource tendrá un acuerdo en base a cantidad de impresiones, que será abonado por el proveedor de contenido. MediaSource cobrará un monto adicional cuanto más larga sea la visita al sitio de fondo. Debe advertirse que la plantilla podría usarse para crear Shoshkele® para el público en general para hacer publicidades u otras cosas para sus propios sitios web o para otros. Shoshkele® instructivos u orlantatlvoa Los Shoshkele® pueden aparecer en sitios de Internet para conducir al usuario hacia secciones y/o áreas y/u otras páginas, así como para cooperar en la enseñanza de un idioma, técnicas comerciales o sexuales, una danza, artes marciales, en la lectura de noticias, etc. Asimismo, puede señalar errores en el uso de una computadora. Actualización da Softwarm Un Shoshkele® aparece en la pantalla ofreciendo la actualización de un software desactualizado, o un conector que está faltando o el reemplazo de uno viejo. Softwarm a costo rmducldo (que contimn publicidad) Un Shoshkele® se activa en un software bajado de Internet o provisto en los medios, reduciendo el costo de tal software . E emplos : • Un usuario descarga un programa de antivirus y su versión gratis. Cuando la ejecuta, se abre una ventana del navegador y aparece un Shoshkele®. Esto puede suceder por única vez o cada vez que el programa de antivirus sea actualizado . • Un navegante de Internet desea saber si determinada persona ha solicitado la protección del capítulo 11 y un sitio comercial que ofrezca esta información permite la descarga de la misma o se la envía en un disquete o CD ROM, que si bien no tendrá cargo alguno, se beneficia mediante la inclusión de un Shoshkele® en el mismo. • Se pueden realizar llamadas internacionales por Internet con un micrófono y parlantes a través de una almohadilla para discado (dial-pad) que se comunica con cualquier parte del mundo pero la conversación se entrelaza en ambos extremos mediante un Shoshkele® (puede ser de sonido solamente) . Los Shoshkele® representan para Internet lo que los comerciales para la televisión, en el sentido de que hasta el momento, toda la publicidad en Internet se realizó a través de pancartas (banners) - similares a los avisos en revistas o periódicos. Por otra parte, al hablar y tener una apariencia humana si se quiere, los Shoshkele® se parecen a los comerciales de televisión. Cualidades mapeciales d loa Shoshkol&s) en comparación con las Pancartas (banners) 1. No son desplazables (con el scroll). Esto significa que si, por ejemplo, el Shoshkele® entra y dice "Tómate una Coca" y el usuario no lo quiere ver, no lo puede desplazar como a las pancartas. Se quedará en la pantalla hasta que termine. 2. Sonido. Los dos únicos métodos utilizados actualmente en Internet para publicidad, si es que se utilizan, son: • música MIDI, que es sonido generado por computadora o • el uso de un programa especial que debe descargarse (conectores u otros) para poder escuchar sonido. Ejemplo: Flash, You don't know Jack. En tanto, los Shoshkele® generarán cualquier sonido, mono, estéreo, música o palabras, en cualquiera de los dos navegadores principales (Netscape y Explorer), en sus versiones 4.0 y superiores (97.5% de los usuarios actuales). 3. Contrariamente a las pancartas, los usuarios regulares no pueden anticipar la aparición de un Shoshkele®. Cuando se abre una página, hasta que se completa su descarga, el espacio del banner está marcado, en cambio el Shoshkele® se descarga en silencio y con toda discreción. 4. Transparencia. Las pancartas no son transparentes. Los Shoshkele® tampoco lo son, pero el área que los rodea inmediatamente sí lo es y cuando el Shoshkele® se va moviendo, cada lugar del cual se retira permanece totalmente visible (transparente) . Esto no sucede en el caso de las ventanas que se abren automáticamente (pop-up) . El Shoshkele® no aparece en una ventana especial. No se puede minimizar ni cerrar y se encuentra en la capa exterior de la página . 5. Los Shoshkele® son totalmente adaptables a cada necesidad . E emplos : • Podría ser una celebridad en video totalmente digital y de un tamaño adaptable a cualquier requerimiento. Por ejemplo, Ricky Martin, Magic Johnson, etc. Puede hablar ("Tomáte una Pepsi") o simplemente tener una Pepsi en sus manos sin decir nada. Podría cantar o hablar o tener efectos de sonido -dando pasos, cerrando una puerta, etc.- aún en estéreo (de un parlante a otro) . • Podría ser un personaje animado. Una celebridad como Bugs Bunny, un dibujo animado, la caricatura de una persona, con todos los efectos de sonido, como en el caso anterior . • Podría ser una aleta de tiburón navegando la página escrita con música de "Jaws" de fondo, emergiendo finalmente como el símbolo de velocidad de Nike. • Podrían ser las letras que bailan desde la página visitada, con o sin sonido. • Podría ser solamente sonido ("Tomáte una Coca") 6. Totalmente sincronizable. Esto significa que el Shoshkele® puede estar preconfigurado para aparecer una o varias veces y/o en cualquier espacio elegido. Por ejemplo: Ricky Martin entra y dice "Tomáte una Pepsi" y no vuelve a aparecer más, o reaparece cada tres minutos y/o la aleta del tiburón (ver arriba) puede aparecer a los veinte segundos que se haya ido Ricky Martin. Podría durar desde un segundo hasta cualquier periodo de tiempo seleccionado. Si la página en la que aparecen los Shoshkele® se minimiza, la imagen de los Shoshkele® desaparece con la página. Si la página se cierra, tanto la imagen como la voz desaparecen. 7. Fácil de ímplementar. Al webmaster le lleva menos de cinco minutos activar o desactivar una rutina de Shoshkele®. 8. Interacción con las cookies. Los Shoshkele® interactuarán con la tecnología de cookies de manera que: • El mensaje se puede personalizar ("Have a Pepsi, Mr. Smith) o (en español "Tómese una Pepsi, Sr. Smith") • Puede reconocer que esa persona ya ha visto este y/u otro Shoshkele® y cuándo, entonces le puede preguntar "¿Te asustó el tiburón?". Se puede utilizar para contar una historia en capítulos, sin aparecer con demasiada frecuencia para no resultar molesto. • Permite la introducción de cookies. La universalidad de los Shoshkele® se hace posible mediante un concepto básico apoyado por una serie de herramientas. Este concepto es que todas las computadoras multimedia que utilizan una interfase gráfica de usuario son inherentemente capaces de exhibir un Shoshkele®, aunque no siempre utilizando la misma tecnología. Se hace entonces necesario determinar cuáles de estos archivos son compatibles con una computadora determinada. Para realizar esta tarea, hay cuatro pasos a seguir: • Definir cuáles son las tecnologías admitidas • Desarrollar unidades publicitarias compatibles con cada tecnología ; • Determinar la tecnologia óptima a enviar a cada computadora; y • Enviar los archivos apropiados a cada computadora. En otros términos, los Shoshkele® se hacen posibles no por una única nueva tecnología, sino por la nueva y no obvia combinación de las existentes, junto con un código propio. Según la configuración y capacidades de la computadora del usuario, se elige, entrega y ejecuta una de las muchas arquitecturas tecnológicas para los Shoshkele®. Una de las principales dificultades encontradas durante la creación de los Shoshkele® es que cada tecnología o ser de tecnologías tiene limitaciones inherentes. Algunas, si bien son capaces de exhibir una imagen en movimiento, ésta se limita a una forma rectangular. Otras, no admiten sonido o sólo pueden describirlo. Otras aún requieren un conector (plug-in) , o tienen distintas capacidades según la plataforma sobre la que corren. El primer problema hallado es que cada uno de los objetos en una página web se define como un rectángulo, lo cual restringe a todas las imágenes a un rectángulo o a un cuadrado. Esto explica por qué antes de la tecnología de Shoshkele® todos los avisos publicitarios tenían esa forma particular. Esta limitación fue superada mediante el uso de la translucidez o transparencia, que tornan invisibles algunas pares del objeto, generalmente la porción exterior que bordea su periferia, dándole la apariencia de no ser rectangular. Esto, justo con la ubicación de los objetos en capas flotantes, crea la ilusión de una figura de libre movimiento de cualquier forma y tamaño. Ciertas tecnologías existentes ofrecen un modo translúcido (ejemplo, GIF89) , lo cual facilita el logro de dicha ilusión. No obstante, GIF89 posee otras limitaciones como la falta de sonido o interactividad, por lo cual no es una solución óptima para generar publicidad convincente. Otras, poseen otras limitaciones, a saber: • Flash 3 requiere un conector y no tiene modo de transparencia . • Flash 4 y 5 requieren un conector y no tienen modo de transparencia en algunas plataformas. • Java Applet no tiene modo de transparencia y tiene errores (bugs ) . • Shockwave requiere un conector y no tiene modo de transparencia en algunas plataformas. • WAV - no tiene imagen. • GIF - no tiene sonido. • JPEG - no tiene sonido ni transparencia. • PNG - no tiene sonido. Estas limitaciones, entre muchas otras, motivaron la explotación de nuevas alternativas mientras se utilizaban combinaciones de las tecnologías disponibles. Siempre comenzamos con la misma premisa básica: todas las computadoras multimedia son capaces de exhibir un aviso publicitario de flotación libre, multiforme, y animado que incluya sonido, aunque no siempre por los mismos medios. Los Shoshkele© se hacen posibles a través del proceso mediante el cual se selecciona su arquitectura. Esta selección se realiza evaluando cuál de todas las arquitecturas Shoshkele® posibles es la más adecuada para transmitir el mensaje específico del modo más eficaz, según cuál será el concepto publicitario y las tecnologías disponibles en la computadora del usuario final. El proceso que se describe a continuación se basa en la premisa de que cada computadora conectada a la Web contiene un gripo de herramientas que, combinadas correctamente, pueden utilizarse para operar un Shoshkele®. También, se describen las arquitecturas alternativas utilizadas para producir y manejar un Shoshkele®. Estas son diseñadas a efectos de superar las deficiencias de cualquier tecnología, tales como la falta de sonido sincronizado, transparencia o la dependencia de un conector específico. La arquitectura a utilizar se escoge en base a las características propias del Shoshkele® y la configuración real de la computadora del usuario.

La creación de un Shoshkele® consta de dos etapas (de dos pasos cada una) , que aunque son claramente diferentes, dependen entre si y están totalmente integradas: • Autoría - Definición de las tecnologías admitidas - Desarrollo de las unidades publicitarias compatibles con cada tecnología • Servicio - Determinación de la tecnología óptima a enviar a cada usuario - Envío de los archivos apropiados a cada usuario. Estos pasos están íntimamente relacionados entre sí y deben ser cuidadosamente coordinados para que un Shoshkele® pueda funcionar correctamente. Asimismo, estos pasos se incluyen en el método descrito en la presente y cuentan con el apoyo de una serie de herramientas o procesos determinados . Autoría Definición de IAB tmcnología.8 a.dmltlda.3 Aún considerando las numerosas combinaciones de plataformas tecnológicas posibles en uso, los numerosos sistemas operativos, navegadores y conectores, la presente invención logra reducir al mínimo la cantidad de arquitecturas Shoshkele® requeridas. Los sistemas operativos compatibles son muy diversos: Windows 95, Windows 98, Windows ME, Windows NT 4.0, Windows 2000, Macintosh System 7, Mac OS 8, Mac OS 9, Mac OS X, distintas variantes del Linux y aún los sistemas operativos de determinados dispositivos de la web La mayoria de los navegadores disponibles para cada sistema operativo también son adaptables. La capacidad y compatibilidad fueron las principales cuestiones a considerar . Los Shoshkele® pueden ser agrupados en cuatro grandes tipos o grupos clasificados según la disponibilidad del conector de Flash y su capacidad o no para exhibir translucidez en una combinación especifica de navegador/plataforma. Los cuatro tipos básicos (con sub-categorias) son: a. Flash con translucidez y con compresión MP3 1) Flash 4 en Internet Explorer 4.0 o superior en Windows 2) Flash 5 en Internet Explorer 4.0 o superior en Windows b. Flash sin translucidez y con compresión MP3 1) Internet Explorer 4.0 o superior en Mac 2) Netscape Navigator 4.0 en todas las plataformas 3) Opera c. Flash sin translucidez y sin compresión MP3 d. Sin Flash El tipo a. y sus subcategorias habilitan la forma más simple de crear y ver los Shoshkele®. El único requerimiento es un archivo swf y algunos códigos propios de JavaScript . El tipo b. y sus subcategorias requieren varias soluciones, dependiendo de las características técnicas y artísticas inherentes a los Shoshkele®. La solución adoptada será una de las siguientes: Flash 4 o 5 (El Shoshkele® se limita a un cuadrado o rectángulo en su propia capa, que luego se oculta y descarga una vez terminada la publicidad. Todo el movimiento es interno, es decir que el objeto exterior se mantiene estático. El Shoshkele® aparece, hace su animación y desaparece. Se pueden lograr entradas graduales (fades) a través del canal alpha dentro del objeto de Flash 4). Flash 4 o 5/Línea de tiempo (timeline) (Igual que #1 excepto que la capa se mueve por el código JavaScript, con lo cual los Shoshkele® cuadrados se pueden mover libremente por la ventana del navegador. El Shoshkele® puede entrar y salir de la ventana) . Flash 4 0 5/GIF/Llnea de tiempo (timeline) (Igual que #2, excepto que en este caso el objeto cuadrado de Flash está envuelto en imágenes GIF que se mueven en sincronización con éste, y como GIF soporta transparencias, el contorno puede ser de cualquier forma, o al menos, aparentarlo) . Flash 4 o 5/GIF (Igual que #3 pero sin el movimiento de la capa) . GIF/Línea de tiempo/Flash 4 o 5 (Este es un tipo de Shoshkele® totalmente diferente. La imagen está totalmente construida a partir de imágenes GIF, ya sea estáticas o movibles. Estas se ubican en su/s propia/s capa/s que se anima mediante la línea de tiempo (timeline) y se sincroniza con el sonido. Junto con Win/Exp/Flash 4 o 5 esta es la única opción que otorga libertad total en cuanto a la forma del Shoshkele®. El tipo c. incluye a todo navegador que soporte Flash, en cualquier plataforma. Esta combinación tiene las mismas limitaciones, problemas y posibilidades que Flash 4, excepto la ausencia de compresión P3, lo que implica que el archivo swf es un poco más grande. Las soluciones son las mismas que para Flash 4 y 5 en las plataformas que no ofrecen translucidez, excepto que utiliza Flash 3. En cuanto al tipo d., la falta de conector implica la sincronización del formato original de sonido del sistema, junto con la línea de tiempo y una o más imágenes animadas GIF en una o más capas. A continuación, se detalla un enfoque diferente de estas clasificaciones. Se definen los Shoshkele® pero no según su tipo sino en base a las combinaciones de plataforma/conector . 1. Windows (95 o superior) 1.1 Explorer (4.0 o superior) 1.1.1 Flash 4 (Existe transparencia, no requiere soluciones alternativas: el Shoshkele® puede tomar cualquier forma y moverse dentro de un objeto de Flash transparente situado en la capa superior. Cuando la animación termina, la capa se oculta y se descarga) . El aviso publicitario se carga y descarga en su propia capa, independientemente de lo que haya en el resto de la página, lo cual otorga libertad total para su diseño y administración, 1.1.2 Flash 3 (Sin transparencia, el Shoshkele® se limita a un cuadrado o rectángulo en su propia capa, que luego se oculta y descarga una vez finalizado el aviso) . 1.1.3 Flash 3/Linea de tiempo (Igual que 1.1.2. salvo que la capa se mueve por el código JavaScript, con lo cual los Shoshkele® cuadrados se pueden mover por la pantalla) . 1.1.4. Flash 3/Linea de tiempo/GIF (Igual que 1.1.3. pero en este caso el objeto cuadrado de Flash está envuelto en imágenes GIF, y como GIF soporta transparencias, el contorno puede ser de cualquier forma, o al menos, aparecer de esa forma) . 1.1.5. GIF/Linea de tiempo/sonido (Este es un tipo de Shoshkele® totalmente diferente. La imagen está totalmente construida a partir de imágenes GIF, ya sea estáticas o movibles. Estas se ubican en una capa por separado que se anima mediante la linea de tiempo (timeline) y se sincroniza con el sonido. 1.1.5.1 GIF/Linea de tiempo/WAV 1.1.5.2 GIF/Línea de tiempo/Flash 3 (Igual que 1.1.5.1. con mejor compresión). 1.1.6. GIF/WAV (Similar a 1.1.5. salvo que GIF es una imagen simple animada; no se mueve por la pantalla) . 1.1.7 Flash 3 "El parche" ("The Patch") (Este método compensa la falta de transparencia al colocar una copia exacta de la página web como telón de fondo para el objeto de Flash. Asi, cuando la capa que contiene el Shoshkele® se aproxima, el usuario sigue viendo la misma imagen, sin darse cuenta de que fuera cubierta por el Shoshkele®) . 1.2. Netscape 1.2.1 Flash 4 (Sin transparencia, el Shoshkele® se limita a un cuadrado o rectángulo en su propia capa, que luego se oculta y descarga una vez terminado el aviso publicitario) . 1.2.2 Flash 4/Linea de Tiempo (Igual que 1.2.1. salvo que la capa se mueve por el código JavaScript, con lo cual los Shoshkele® cuadrados se pueden mover por la pantalla) . 1.2.3. Flash 4/Linea de tiempo/GIF (Igual que 1.2.2. pero en este caso el objeto cuadrado de Flash queda envuelto en imágenes GIF, y como GIF soporta transparencias, el contorno puede ser de cualquier forma, o al menos, aparecer de ese modo) . 1.2.4. Flash 4/GIF (Igual que 1.2.3. sin el movimiento de la capa) 1.2.5. Flash 3 (Igual que 1.2.1.) 1.2.6. Flash 3/Llnea de tiempo (Igual que 1.2.2.) 1.2.7. Flash 3/GIF/Línea de tiempo (Igual que 1.2.3. ) 1.2.8. Flash 3/GIF (Igual que 1.2.4.) 1.2.9. GIF/Linea de tiempo/sonido (Este es un tipo de Shoshkele® totalmente diferente. La imagen está totalmente construida a partir de imágenes GIF, ya sea estáticas o movibles. Estas se ubican en una capa por separado que se anima mediante la linea de tiempo (linetime) y se sincroniza con el sonido. Junto con Win/Exp/Flash 4 esta es la única opción que permite libertad total en cuanto a la forma del Shoshkele®. 1.2.9.1. GIF/Linea de tiempo/WAV 1.2.9.2. GIF/Linea de tiempo/Flash 3 (Igual que 1.2.9.1. con mejor compresión) 1.2.9.3. GIF/Linea de tiempo/Flash 4 (Igual que 1.2.9.2. con compresión MP3) 1.2.10. GIF/WAV (Similar 1.2.9., excepto que GIF es una imagen simple animada; no se mueve en la pantalla) 1.3. Opera (Igual que Netscape) 1.4. AOL (Igual que Netscape) 2. Macintosh (Igual que Windows/Netscape, excepto por una pequeña demora que debe incluirse en la linea de tiempo) . 3. Playstation 4. Web TV Desarrollo dm Unidades Publicitarias CompAtihl s con el uso do cada, tmcnologia Una vez completo el análisis, el siguiente paso es crear las versiones necesarias o arquitecturas Shoshkele® para que la unidad publicitaria funcione en todas las plataformas deseadas. Tomando en cuenta las consideraciones artísticas para el trabajo creativo, el 99% del universo de la web actual solamente puede ser adaptado por 9 arquitecturas, aunque se incluyan miles de combinaciones de plataforma/navegador/conector . El punto de partida para todas las versiones es un Shoshkele® que funcionan en Internet Explorer versión 4.0 o más nuevas con Flash Plug-in versión 4 o más nueva (en adelante denominada WE4F4 ) . Dada la habilidad de esta combinación para describir gráficos de vectores y mapas de bits, animaciones, sonido y translucidez, es el Patrón de Oro en base al cual se evalúan todas las demás versiones. Esta arquitectura es, sin lugar a dudas, la más fácil de crear e implementar. Todas las demás han sido desarrolladas para emular las capacidades de ésta.

Si el objetivo fuera desarrollar un Shoshkele® que funcione solamente en una página HTML como se ve en un navegador IE 4.0 o en un navegador más nuevo con un conector de Flash 4 o más nuevo (WE4F4) en una computadora que opera en Windows, se puede lograr simplemente configurando un parámetro denominado wmode en "transparente", en la etiqueta que inserta el objeto de Flash en la página. <param name="wmode" value="transparent"> Dado que ninguna otra plataforma permite esta solución, todas las demás llevan una vía de acceso (path) muy diferente. Las imágenes y sonidos contenidos en el archivo de Flash se exportan a una variedad de formatos. Una línea de tiempo de JavaScript controla estos archivos exportados (Archivos Multimedia o MMFs) creando capas dentro del documento HTML, cargando las imágenes y el sonido a esas capas, sincronizándolas y animándolas. Estas son la materia prima para todas las versiones de Shoshkele® excepto WE4F4, los MMFs y el código de JavaScript. Los siguientes nueve casos definen el universo de las arquitecturas de Shoshkele®: 1. Windows IE v. 4.0 o más nuevo con Flash v. 4.0 o más nuevo: [ E4F4] 2. Windows IE v. 4.0 o más actual sin Flash: [WE4F0] 3. Windows Netscape v. 4.1 o más actual sin Flash: [WN4F0] 4. Macintosh Netscape v. 4.0 o más actual sin Flash: [MN4F0] 5. Windows Netscape v. 4.1 o más actual con Flash v. 4.0 o más actual: [WN4F4] 6. Macintosh Netscape v. 4.0 o más actual con Flash v. 4.0 o más actual: [ 4F4] 7. Windows Netscape v. 6.0 o más actual con Flash v. 4.0 o más actual: [WN6F4] 8. Macintosh Netscape v. 6.0 o más actual con Flash v. 4.0 o más actual: [MN6F4] 9. Macintosh IE v. 5.0 o más actual con Flash v. 4.0 o más actual: [ME5F4] 1. WE4F4 Esta arquitectura se implementa mediante una plantilla en la que todo lo que cambia es el nombre del archivo y el tamaño. Excepto esta versión, todas las demás tienen una estructura que comprende archivos de Imagen, de Sonido y el código de control o la linea de tiempo de JavaScript . 2. WE4F0 El primer paso para tener una amplia variedad de Shoshkele® que cubren todas las plataformas es convertir la arquitectura WE4F4 en una de las arquitecturas Imagen/Sonido/JavaScript . A efectos de la estandarización del proceso, la primera que se debe crear es WE4F0. A esta la llamamos Base HTML y los formatos de archivo de sus MMFs son GIF/GIF Animados y WAV. Se construirán variaciones de esta Base HTML para cubrir las plataformas soportadas restantes . Lo primero que se debe hacer es cambiar la Base HTML a un archivo externo JavaScript para poder incluirla dentro de la etiqueta del script y transmitirla a la página mediante le método de escritura de documentos. A tal efecto, todas las capas de la Base HTML deben pegarse inmediatamente después de la etiqueta <script language = "JavaScript"> : <div id="skltrama" style="position .. [etc, etc, etc...] <div id="sklbanner" style="position : absolute ; left:499px; top:63px; width:21px; height:5px; z-index:5; visibility: hidden"Xa href= http : //www . aimovie . co"ximg src="skl_gjvariety_aibanner . jpg" width="202" height=,,44" border="0"X/a></div> function MM_findObj (n, d) { //v4.0 var ?,?,?; if(!d) d=document; if ( (p=n. indexOf ("?") ) >0&&parent . frames . length) { d=parent . frames [n. substring (p+1) ] .document; n=n. substring (0, p) ;} [etc, etc, etc...] El objetivo es preservar las capas escribiéndolas no desde HTML sino desde JavaScript.

Luego, se ubica la capa en una variable: var ?? Lay=,<div id=" skitrama" style="position: absolute; left:268px; top:37px; width:26px; height : 21px; z-index:l visibility: hidden"Ximg src="skl_g_aicircu01. gif" width="413" height="413" name=sklimgtrama"X/div> , document . rite (SH_Lay) ; Esta es la línea de tiempo básica de JavaScript. Todas las versiones se desarrollarán a partir de ésta. Lo que se agrega a continuación es una nueva variable dirigida a los archivos MMFs, y que se denominan "theSRC" . Var theSRC= 'http : //akamai . com/imágenes/' var SH_Lay= div id="skltrama" style="position: absolute; left:268px; top:37px; width:26px; height : 21px z-index:l; visibility: hidden"Ximg src="skl_g_aicircuQl . gif" width="413" height="413" name=,,sklimgtrama"X/div> " En este ejemplo, vemos que la imagen llamada skl_g_aicircu01.gif no tiene una ubicación asignada. Para poder dirigir al navegador hacia un URL o directorio en particular, la variable theSRC se antepone al nombre de la imagen. var SH_Lay=,<div id="skltrama" style="position: bsolute; left:268px; top:37px; width: 26px; height : 21px; z-index:l; visibility :hidden"ximg src="+theSRC+' skl_g_aicircu01. gif" width="413" height=v413" name="sklimgtrama"X/div> " Al hacer esto con todas las imágenes y sonidos, se logra finalmente un archivo muy flexible que puede localizar sus MMFs con facilidad. Dado que el código JavaScript llama a los MMFs externos, no solamente es necesario cargar la linea de tiempo sino que también para que los MMFs completen la carga antes de comenzar la ejecución. Esto se garantiza agregando el siguiente código: window. onload=shcreate Este le da la orden al navegador de ejecutar la función shcreate sólo cuando la página está completamente cargada, de modo tal de evitar la visualización de un Shoshkele® antes de que todos los MMFs estén disponibles . El problema radica en que el navegador disparará la función en cuanto cargue los elementos que conoce, que no son todos. Algunos MMFs que aún no están en una capa, no serán alcanzados por este comando. El truco aqui es que algunas imágenes no están todavía dentro de las capas, por lo cual debemos implementar alguna forma de precarga. Una vez identificadas, podemos instruir al navegador para que las precargue con la siguiente modificación en nuestra línea de tiempo : var theSRC= ; var SH_JLay= div id="skltrama" [etc, etc...]Ximg src=" +theSRC+' skl_g_aicircu01. gif" [etc, etc... ] >/div> ' +'<div id="sklpibe" [etc, etc...]Ximg src=" ,+theSRC+' skl_g_ai secuencia . gif" [etc, etc... ]border="0"X/div>' +'<div id="sound" [etc, etc ... ] xembed src=" ,+theSRC+' skl_s_ail2. wav" autostart="false"x/embedx/div> ? + '<div id="texto" [etc, etc...]Xfont size="5">ARTIFICIAL INTELLIGENCE</fontX/fontx/fontX/p></div> ? +'<div id="sklbanner" [etc, etc...]<img src=" ,+theSRC+' skl_g_variety_aibanner . jpg" width="202" he></a></div> ? ; document . write ( SH_Lay ) ; MM_preloadImages ( theSRC+' skl_g_aicircu05. gif' , theSRC+' skl_g_aicircu04. gif ' , theSRC+' skl_g_aicircu02. if ' , theSRC+' skl_g_aicircu03. gif' , theSRC+' skl_g_aicircu06. gif' ) ; El manejo y precarga de los archivos de sonido presentan otras cuestiones a considerar. A través de la función EMBED (insertar) , insertamos el archivo de audio en la página, y como debemos controlar el playback (reproducción), la propiedad AUTOSTART (autoinicio) debe estar configurada en FALSE (falso) . Para que el playback comience, el conector de Flash habilita el método playO, por lo tanto: <HTML> <EMBED NA E="soyunsonido" src="elSonido . wav" autostart="false"X/EMBED> <SCRIPT LANGUAGE="JavaScript"> document . soyunsonido . play ( ) ; </SCRIPT> </HTML> Para aquellos casos que no soportan el comando play () (aquellos en los que el archivo de sonido está en otro formato) , la solución es sobrescribir la capa cambiando la configuración de AUTOSTART, de FALSE (falso) a TRUE (verdadero) . Original <EMBED SRC="thebeatles . wav" autostart="false"> Sobreescrito <EMBED SRC="thebeatles . wav" autostart="true"> La falla de este método es que el sonido insertado no puede ser sobrescrito, la solución es hacerlo dentro de una capa (layer) . <div id="sound"Xembed src="skl_s_ail2. wav" width="32" height="32" autostart="f lse"x/embedx/div> Esta es la etapa en que se realiza la mayoria de los ajustes necesarios para hacer las diferentes versiones.

Para que la operación anterior funcione en Netscape, la capa debe ser visible, por lo cual debe ubicarse fuera de la pantalla para que el controlador de sonido permanezca oculto. <div id="sound" style="position: absolute; left:0px; top:-300px; visibility: isible; "> <embed src=" ^íneSRe!' skl_s_ail2. wav" width="32" height="32" name="snd" autostart="false"X/embed> </div> El archivo de sonido está ahora listo para ser ejecutado. Hay diferentes métodos para sobrescribir los contenidos de una capa según cuál sea el navegador. 3. WN4F0 Aunque es muy similar a la versión del Explorer, en este caso la etiqueta <DIV> debe ser reemplazada por la etiqueta <LAYER>. Teóricamente, en los navegadores Netscape 4.0 o superiores se aceptan ambas etiquetas, pero la experiencia nos ha demostrado que cuando se utiliza el método de escritura e documentos la etiqueta <DIV> puede producir errores . var SH_Lay='l<layer id="skltrama" style="position: absolute; left:268px; top:37px; width:26px; height:21px; z-index:l; visibility: hidden"ximg src= ,+theSRC+' skl_g_aicircu01. gif" width="413" height="413" name="sklimgtrama"x/layer> 1 Dado que la etiqueta <LAYER> no soporta STYLE, es eliminada . var SH_Lay= x<layer id="skltrama"Ximg src=x ,+theSRC+' s)l_g_aicircu01. gif" width="413" height="413" name="sklimgtrama"x/layer> ' A continuación, se configuran las propiedades, var SH_Lay= x<layer id="skltrama" LEFT:"268" TOP:"37" WIDTH:"26" HEIGHT:"21" Z-INDEX:"1" VISIBILITY="VISIBLE"Ximg src=" ,+theSRC+' skl_g_aicircu01. gif" width="413" height="413" name="sklimgtrama"x/layer> ? Adviértase que en Netscape todas las capas tienen posición absoluta, por lo que debe eliminarse dicha configuración. Asimismo, las variables top/left/ width/height (superior/izquierda/ancho/altura) se miden en pixeles, suprimiendo "px". Finalmente, HIDDEN (oculto) se reemplaza por HIDE (ocultar) . Estos cambios deben realizarse en todas las capas según los códigos de la versión WN4F0: var theSRC= ? ' ; var SH_Lay='<LAYER id="skltrama" LEFT:"268" TOP:"37" WIDTH:"26" HEIGHT:"21" Z-INDEX:"1" VISIBILITY="HIDEE"><img src=" ,+theSRC+' skl_g_aicircu01. gif" width="413" height="413" name="sklimgtrama"X/LAYER> ? +¾<LAYER id="sklpibe" LEFT:"390" T0P:"139" WIDTH:"15" HEIGHT:"20" Z-INDEX:"2" VISIBILITY="HIDE"Ximg src=" ,+theSRC+' skl_g_aisecuencia.gif" width="166" height="169" name="skliragpibe" border="0"x/LAYER> ? + VLAYER id="sound" LEFT : "0" TOP:"300" WIDTH:"11" HEIGHT:"11" Z-INDEX:"3" VISIBILITY="VISIBLE"Xembed src=" ,+theSRC+' skl_s_ail2.wav" width="32" height="32" name="snd" autostart="false"X/embedx/LAYER> ' +'<LAYER id="texto" LEFT:"335" TOP:"295" WIDTH:"283" HEIGHT:"14" Z-INDEX:"4" VISIBILITY= HIDE"Xp align="center"xfont face="Times New Román, Times, serif" size="2" color=" # FFFFFF"XbXfont size="4">A STEVEN SPIELBERG FILM<brX/fontx/bxfont size="4 "><font size="5">ARTIFICIAL INTELLINGENCE</fontx/fontx/fontX/p></LAYER> ? + VLAYER id="sklbanner" LEFT:"499" TOP:"63" WIDTH:"21" HEIGHT : "5" Z-INDEX:"5" VISIBILITY="HIDE"Xa href="http : //www . aimovie . com"Ximg src=" ,+theSRC+' skl_g__variety . aibanner . jpg" width="202" height="44" border=" 0"x/ax/LAYER> ? ; 4. MN4F0 Esta versión es exactamente igual a la anterior con la salvedad de que los archivos de sonido deben estar en el formato AIFF en lugar de WAV. La capa se debe ver de la siguiente manera: + <LAYER id="sound" LEFT : "0" TOP:"300" WIDTH:"11" HEIGHT:"11" Z-INDEX:"3" VISIBILITY="VISIBLE"Xembed src=" ^+theSRCt' skl_s_ail2. aif" width="32" height="32" name="snd" autostart="false"x/embedx/LAYER y la linea de tiempo, del siguiente modo: document.MM Time[0] [15] .value= "MM_showHideLayers ( 'sklpibe' , " , ' show' ) ;MM_setTextOfLayer ( 'sound' , " , ' %3Cembed src=%22' +theSRC+' skl_s_ail2. aif%22 autostart=%22true%22 hidden=%22true%22%3E%3C/embed%3E' ) "; 5. N4F4 Para esta versión, en lugar de usar un sonido WAV, se aprovecharán las capacidades del conector de Flash 4 o uno nuevo para codificar en MP3. Enviando el sonido en un archivo swf (Flash) es posible reducir su tamaño y el tamaño total del archivo Shoshkele® combinado. Debe recordarse que aunque esta versión utilice el conector de Flash no soporta la opción TRANSPARENTE en esta plataforma, lo que nos obliga a usar imágenes GIF para visualizar objetos no rectangulares. Para implementar esto, se agrega una precarga al archivo swf que contiene la banda sonora (soundtrack) y desde adentro de éste, se realiza un llamado a la función «h_aar¾jar ( ) . En la función shcreate ( ) , la capa de sonido se escribe dinámicamente utilizando el sonido swf. Luego, se crea la función sh_create y se la instruye para comenzar la ejecución de la linea de tiempo en cuanto ésta es implementada . Asi es como se lee la función shcreate en código original de JavaScript: function shcreate () { MM_timelinePlay ( 'shtimeline' ) ; } y así es como debe leerse en la arquitectura Shoshkele®: function shcreate() { MM__setTextOfLayer ( sound' ,' ' ,' <embed src=" +theSRC+' skl_s_ail2. swf" quality=high pluginspage="http: //www. macromedia. com/shockwave/download /inde . cgi? Pl_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="152" height="115" loop="false"X/embed> ^ ) ; Las propiedades dentro de EMBED son simplemente indicarle al navegador el formato del archivo. La función shcreate carga el archivo swf a la capa SOUND (Sonido) . Tal como está codificado, este archivo llama a la función sh_cargar una vez completa su carga, y lo único que resta es programar tal función para que active la línea de tiempo cuando comienza el playback. function sh carga () { MM_timelinePlay ( ^ shtimeline' ) ; } En otros términos, la función sh_cargar realiza la misma tarea que shcreate en otras versiones. ONLOAD--> shcreate--> swf sound--> sh_cargar--> Timeline execution. Una vez modificada shcreate y agregada sh^cargar, deben borrarse el contenido original de la capa SOUND y el llamado a MM_setTextOfLayer que se encuentra en Frame (marco) +,<LAYER id="sound" LEF : "0" TOP:"300" WIDTH:"11" HEIGHT:"11" Z-INDEX:"3" VISIBILITY="VISIBLE"X/LAYER> ? 6. MN4F4 Compatible con WN4F4 7. WN6F4 Esta arquitectura es un híbrido entre E4F4 y WN4F4. Comparte código con ambas, pero aún más con el Explorer. Por este motivo, al comenzar con E4F0, debe ser modificada para usar un archivo swf para el formato del sonido. Esto se realiza del mismo modo que antes. Además, debe borrarse el contenido insertado en la capa SOUND. <embed src=" ,+theSRC+' skl_s_ail2. wav" width="32" height="32" name="snd" autostart="false"x/embed> La capa se debe leer de este modo: +'<div id="sound" style="position : absolute; left:0px; top:-300px; width:llpx heightrllpx; z-index:3; visibility : visible"x/div> ¾ A continuación, borrar el llamado a M _settextOfLayer en Frame 1 de la línea de tiempo: MM_setTextOfLayer ( 'sound' , ' ' , ' %3Cembed src=%22' +theSRC+' skl_s_ail2. av%22 autostart=%22true%223E%3C/embed%3E' ) Y así es como debe quedar: document . MM_Time [ O ] [15] = new String ("behavior") ; document .MM_Time [0] [15] . frame = 1; document . MM_Time [ 0 ] [15] .valué = "MM_showHideLayers ( 'sklpibe' , " , 'show' ) ;"; document .MM_Time [0] [16] = new String ("behavior") ; Modificar la función shcreate y agregar sh_cargar ( ) para que el código resultante se lea del siguiente modo: function shcreate () { MM_setTextOfLayer ( ^sound' , ' ' , ' <embed src=x,+theSRC+' skl_s_ail2.swf" quality=high pluginspage="http : //www . macromedia . com/shockwave/dowload /index. cgi?Pl Prod Version=ShockwaveFlash" type="application/x-shockwave-flash" width=" 152" height= 115" loop="false"x/embed>0 ) } function sh_cargar() { M _timelinePlay ( ^htimeline' ) ; } 8. MNgF4 Igual que WN6F4. 9. ME5F4 Como punto de partida, tomar cualquiera de las versiones de Netscape 6. En lugar de VISIBILITY (visibilidad), se usa DISPLAY (exhibir) junto con los parámetros NONE (ninguno) o INLINE (en linea) . Adviértase que no es necesario modificar la capa de sonido, ya que su visibilidad no cambia. var SH_Lay=,<div id="skltrama" style="position:absolute; left : 268px; top:37px; width : 26px; height:21px; z-index:l; display: none"ximg src=" ,+theSRC+' skl_g_aicircu01. gif" width=x 13" height= 13" name="sklimgtrama"X/div> +'div id="sklpibe" style="position : absolute; left:390px; top:139px; width: 15px; height:20px; z-index:2; display: none"Ximg src=" ,+theSRC+' skl_g_aisecuencia . gif" width="166" height="169" name="sklimgpibe" border="0"x/div> ? +'div id="sound" style="position : absolute; left:0px; top:300px; width: llpx; height:llpx; z-index:3; visibility: visible"Xembed src=" ,+theSRC+' skl_s_ail2.wav" width="32" height="32" name=wsnd" autostart="false"x/embedx/div> ? +'div id="texto" style="position : absolute ; left:335px; top:295px; width : 283px; height : 14px; z-index:4; display: none"Xp align="center"Xfont face="Times New Román, Times, serif" size="2" color="#FFFFFF"xbXfont size="4">A STEVEN SPIELBERG FILM<brX/fontx/bxfont size="4"Xfont size="5">ARTIFICIAL INTELLIGENCE</fontX/fontX/fontx/pX/div> ? + '<div id="sklbanner" style=,"position : absolute ; left: 499px; top: 63px; width:21px; height: 5px; z-index:5; display: none"Xa href="http: //www. aimovie. com"><img Src=" x+theSRC+' skl_g_variety_aibanner . pg" width="202" height= 4" border=" 0 "></a></div> " Luego de modificar las capas, lo único que queda por hacer es reemplazar la función M _showHideLayers por la siguiente : Opción de capa subyacente (underlayer) A continuación, hay una variación de la técnica descrita que permite que la publicidad flote por debajo del contenido, en lugar de hacerlo sobre él. Esta capacidad se suma al arsenal de opciones que soporta la tecnología del Shoshkele®. A fin de lograr esto, usamos el parámetro z-index e instruimos al navegador para que coloque el Shoshkele® detrás del contenido. <STYLE TYPE="text/css">body { position : absolute ; z-index:l; }</STYLE> <DIV ID="PEPSI" STYLE="position: absolute; z~index=-1;"TEXT OR IMAGES HERE</DIV> Servicio A fin de que la unidad publicitaria funcione, después de definir y crear los archivos Shoshkele®, es necesario seleccionarlos y servirlos a la computadora para la cual fueron diseñados. Este paso es tan crucial como el de su creación, ya que un error aquí causaría el mal funcionamiento del Shoshkele® o incluso de toda la página que lo contiene. Para asegurar la operación, se deben llevar a cabo dos procedimientos: establecer la tecnología óptima para determinado usuario y suministrar los archivos apropiados a este usuario. Estos procedimientos se pueden efectuar mediante muchos procesos lógicos y varias tecnologías diferentes. Ambas capacidades han sido incorporadas en un solo sistema denominado Shoshkele® Serving System se divide en cuatro subsistemas: Subsistema del Driver del Shoshkele®; Subsistema Administrativo; Subsistema de Control y Estadística; y Subsistema Financiero. De ellos, el primero ocupa el centro de la tecnología del Shoshkele®. Determina qué publicidad se debe entregar a cada usuario en cada página. El Subsistema del Driver del Shoshkele® se ocupa de todas las funciones pertenecientes a la selección y transmisión de los verdaderos Shoshkele®. Elige la publicidad a ser enviada, y la arquitectura del Shoshkele® que se utilizará. La Figura 7, que comprende las Figuras 7A y 7B, es un diagrama en bloques resumido que ilustra la operación del sistema para servir los Shoshkele® a los usuarios. Se supone que cada usuario está conectado al servidor web de un proveedor de contenido, a través del cual se le proporcionará un Shoshkele® desde un servidor web del Shoshkele®. Éste es un resumen del subsistema del driver 604 de la Figura 6.

En el bloque 750, el usuario realiza una solicitud de HTML para recibir contenido. La solicitud 752 es transferida al servidor web. Éste recupera o genera un archivo HTML con el contenido solicitado en el bloque 754, y el archivo HTML 756 es transferido al navegador de la web. Además del pedido de contenido, el archivo HTML 756 contiene etiquetas de shoshkelización 760 al servidor web de Shoshkele®. Al recibir el pedido de archivo, el servidor web de Shoshkele® recupera los archivos de shoshkelización, diseñados para probar la máquina del usuario de modo de determinar la tecnología disponible en ella, y los archivos de shoshkelización 764 se envían al navegador de la web del usuario. En el bloque 766, el archivo de shoshkelización se ejecuta en la computadora del usuario, y se envía un pedido de proceso del lado del servidor 768 al servidor de Shoshkele® informando cuáles son las tecnologías disponibles en la computadora del usuario, indicando qué aviso publicitario ya ha visto la persona y la información demográfica sobre ella. En el bloque 770, el servidor procesa la información recibida y determina qué tipo de código Shoshkele® y qué aviso publicitario serán enviados. Entonces, el código Shoshkele® 772 necesario es transmitido al navegador de la web. En el bloque 774, el navegador ejecuta el código que ha recibido y envía un pedido de archivo de medios para el servidor web de Shoshkele®. En el bloque 778, este último recibe el pedido de archivo de medios, ubica las imágenes y el código ejecutable necesarios y envía estos archivos multimedia 780 al navegador de la web. En el bloque 782, el navegador de la web ejecuta luego el código ejecutable y reproduce los archivos de multimedia. Preferentemente, al realizar el código ejecutable y exhibir el archivo multimedia, el navegador de la web notificará la servidor del Shoshkele® que los avisos publicitarios necesarios han sido completados, y el servidor de Shoshkele® enviará al usuario una cookie actualizada. Los pasos básicos asociados con la Figura 7 (que comprenden las Figuras 7A y 7B) son los siguientes: 1. Solicitud del Shoshkele® La solicitud se origina en el navegador del usuario mediante una línea de código incluida en el archivo HTML (que se agrega a cualquier página web sobre la cual se exhibe un Shoshkele®) . 2. Selección del Shoshkele® Este proceso selecciona el Shoshkele® a ser enviado. Considera dos clases de parámetros para tomar dos decisiones básicas: la arquitectura que se utilizará (Figura 8, que comprende las Figuras 8A, 8B, 8C y 8D) ; y qué aviso publicitario será enviado (Figura 9).

Las Figuras 8A-8D, también mencionadas colectivamente como Figura 8, constituyen diagramas de flujo que ilustran cómo se selecciona el Shoshkele® apropiada para un usuario en particular. La operación comienza en el bloque 650 y el subsistema del driver escoge el aviso siguiente en el bloque 652. En los bloques 654, 658, 662 y 666 se realizan pruebas para determinar cuál es el sistema operativo que funciona en la computadora del usuario. El control recorre los bloques hasta encontrar el sistema operativo, y en ese momento el control se desvia al bloque que está inmediatamente a la derecha. Por ejemplo, si el usuario tiene un sistema operativo Macintosh, la prueba en el bloque 654 producirá un resultado "no", tras lo cual se realizará la prueba en el bloque 658. Esta prueba producirá un resultado "si", con lo cual el control se transferirá al bloque 660. Los bloques 656, 660, 664 y 668 representan subprogramas específicos en los cuales se activa un Shoshkele® que corresponde a un sistema operativo en particular. Cuando uno de estos subprogramas es ejecutado, este programa finaliza en el bloque 670. El programa también terminará en el bloque 670 si todas las pruebas producen un resultado negativo. El diagrama de bloques de la Figura 8B ilustra un subprograma que se realiza para ejecutar un Shoshkele® de Windows (es decir, el bloque 656 en la Figura 8A) . La operación comienza en 672, y en los bloques 674, 678, 682 y 686 se realizan pruebas consecutivas para determinar qué navegador está siendo empleado por el usuario. El flujo operativo prosigue por estos bloques hasta encontrar el navegador correcto, momento en el cual el flujo se traslada al bloque que está inmediatamente a la derecha. Por ejemplo, si el usuario emplea el navegador Netscape, la prueba en 674 producirá un resultado "no", con lo cual se realizará la prueba en 678. En este caso, se obtiene un resultado "si", de modo que el control se traslada al bloque 680. Los bloques 676, 680 y 688 corresponden a subprogramas separados que se ejecutan cuando el usuario utiliza un navegador en particular. En cada caso, cuando se ejecuta el subprograma, el programa de la Figura 8B finaliza en el bloque 690. El programa también termina si no se encuentra ninguno de los navegadores (es decir, si fallan todas las pruebas). La Figura 8C es una representación de diagrama de bloques del subprograma que, ejecutado en la computadora del usuario, opera el sistema operativo Windows con el navegador Internet Explorer de Microsoft (es decir el subprograma del bloque 676 de la Figura 8B) . La ejecución del subprograma comienza en el bloque 700, y en 702 se lleva a cabo una prueba para determinar si la computadora del usuario tiene Flash 4. De ser asi, el control se transfiere al bloque 704 mientras se ejecuta un subprograma que selecciona un Shoshkele® que opera con Flash 4, y este subprograma termina en el boque 712. Si la computadora del usuario no tiene Flash 4, se lleva a cabo una prueba en el bloque 706 para determinar si la computadora del usuario tiene Flash 3 o no. De ser asi, el control se transfiere al bloque 708, donde se lleva a cabo un subprograma que determina una de las cuatro combinaciones de tecnología a ser utilizadas, según lo que se encuentre disponible en la computadora del usuario. Entonces, este subprograma termina en el bloque 712. Si la computadora del usuario no tiene Flash 3, el Shoshkele® utilizará una de dos tecnologías alternativas (bloque 710) , según lo que esté disponible en la computadora del usuario, y este subprograma termina en 612. La Figura 8D es un diagrama de flujo que ilustra el subprograma ejecutado sí la computadora del usuario opera con el sistema operativo Windows y su navegador es Netscape. La operación es bastante similar a la Figura 8C, salvo por el hecho de que en los bloques 724 y 728 se deben hacer elecciones alternativas, como ocurría en el bloque 708. La Figura 9 es la descripción de un diagrama de bloques que ilustra cómo se utilizan las tablas de bases de datos para determinar el aviso publicitario a ser exhibido. El bloque 1000 representa una lista de todos los sistemas anfitriones (host) disponibles proveedores de contenido. El bloque 1002 representa un parámetro par.url que corresponde a la página específica del sitio del proveedor de contenido que está siendo visitada por el usuario. Ese parameter . url se aplica a la tabla 1000 de modo de ubicar un código para esa página en particular. Si no se encuentra el par.ur., el proceso no continúa. Los códigos proporcionados desde el bloque 1000 (Id-hosts) se aplican a otra tabla 1004. También, se aplica a la tabla 1004 una palabra clave o una serie de palabras clave que corresponden al tema que está siendo examinado por el usuario, o a la información sobre el usuario. La información proporcionada a la tabla 1004 genera un nuevo código de Id-page que se aplica a la tabla 1008. También, se aplica a esta tabla una cantidad de información 110, conseguida del usuario y de la base de datos que describe la información conocida acerca del usuario y de la campaña de interés particular. Todo esto resulta en la generación de un nuevo código Id-mp, el cual se aplica a la tabla 1012. El código Id-mp contiene información acerca del usuario y de la página a la cual ha accedido, además del plan de medios activo en ese momento. También, se aplica a la tabla 1012 la información sobre los antecedentes de la campaña relacionados con el usuario, los cuales se obtienen de su cookie. La tabla 1012 produce otro código Id-campaign, que representa la siguiente campaña que deberla ver este usuario, y este código se aplica a la tabla 1016. La tabla 1016 produce un Id-Shosh variable que identifica el siguiente Shoshkele® que será enviado a este usuario.

La elección de la arquitectura se basa en datos obtenidos de la computadora del usuario. Depende del sistema operativo, el navegador, los conectores instalados, la velocidad de conexión, etc. La elección de la unidad creativa se realiza sobre la base de datos tanto del usuario como de los parámetros predeterminados de la campaña. 2.1 Procesamiento y datos del lado del usuario Los datos se obtienen dinámicamente cada vez que un usuario ejecuta un pedido de Shoshkele®. Pueden incluir información almacenada en una cookie o no. 2.2 Procesamiento y datos del lado del servidor Los datos del lado del servidor están formados por parámetros y lógica específicos de la campaña. 2.3 Envío del Shoshkele® La operación llevada a cabo por la cabeza (front-end) del servidor web de Shoshkele® una vez que se ha decidido qué Shoshkele® y arquitectura serán enviadas. 2.4 Carga de Shoshkele® 2.5 Descarga Estas dos operaciones son realizadas por el navegador. A continuación se amplía la explicación de ambos procesos . Ahora se analizarán mejor cada uno de los pasos básicos . 1. Solicitud da Shoshkele® El envió y la ejecución de un Shoshkele® se inicia mediante un código previamente insertado en un portador (carrier) , por ejemplo en una página web o en un e-mail HTML. En la representación preferida de este método, el código de inicio o la etiqueta del Hoshkele® consiste en una sola linea de JavaScript, que solicita otro código de Shoshkele® Serving System. Esto permite una mayor simpleza en el momento de implementar la etiqueta. El código necesario para la navegación exitosa de un Shoshkele® podria requerir docenas de páginas y, para evitarlo, se puede insertar alternativamente por completo en la página, pero esto seria más difícil de manejar para los profesionales de la web sin experiencia en esta técnica. En lugar de ello, lo único que debe ser manejado por los sitios es la línea única de JavaScript . La etiqueta de Shoshkele® se puede insertar en la página mediante uno de varios métodos. Es posible pegarla simplemente en una página HTML estática, colocarla en una plantilla, colocarla dinámicamente mediante una aplicación, o incluso enviarla a través de un tercero que actúa como servidor de publicidad. Esta última opción no implica el envío del Shoshkele® por parte del tercero. Esto no sería posible debido a que el proceso de toma de decisiones para servir este tipo de unidad publicitaria es muy complejo. Como ya hemos analizado, el proceso de servicio de un Shoshkele® está intimamente ligado a su funcionalidad, considerando la gran cantidad de plataformas y archivos involucrados. Lo único que puede ser suministrado por un tercero es el código que inicia el envió del Shoshkele®. El servicio de etiqueta por parte de un tercero también permite mejorar el objetivo (target) , si se trata de un contexto donde el tercero tiene más información sobre el usuario que la que maneja el Shoshkele® Serving System. La etiqueta del Shoshkele® se ve de este modo: <SCRIPT LANGUAGE="JavaScript" TYPE="text/j avascript" AME : "hdyrt=vipl234567 &KWl=0&KW2=nikkeiTba" STYLE="http; / /64.59.136.70/web/tags/direct . j s"x/SCRIPT> SCRIPT llama a un script LANGUAGE = "JavaScript" indica el lenguaje de programación TYPE indica el tipo MIME ÑAME define variables STYLE aborda cuestiones de compatibilidad SRC indica el archivo a ser recuperado SCRIPT marca el final de la llamada al script Se debe observar que esta solicitud puede resultar en una impresión de Shoshkele® o no, según cuáles sean los parámetros del objetivo que delinean una campaña. De hecho, la etiqueta no pide un Shoshkele® sino la negociación y la posible bajada de un Shoshkele®. 2. Selección del Shoshkele® La selección del Shoshkele® implica tomar dos decisiones por separado: qué arquitectura de Shoshkele® utilizar y qué unidad creativa enviar. Ambas elecciones dependen de la información y la lógica que proviene tanto de la computadora del usuario como del servidor. La selección de un Shoshkele® es el paso más complejo de todo el proceso, y se inicia por parte del usuario con la ejecución de la etiqueta del Shoshkele®. 2.1 Procesamiento y datos del lado del usuario Cuando se ejecuta la etiqueta del Shoshkele®, se solicita un archivo JavaScript que a su vez se ejecuta e inicia un proceso que resulta en la verdadera solicitud de un Shoshkele®. Este proceso consiste en la exploración de los recursos del sistema del usuario, la obtención de su información especifica y el establecimiento de una conexión con el Shoshkele® Server. Para obtener la información necesaria sobre el usuario y transmitirla al Shoshkele® Server que toma las decisiones, el archivo JavaScript lleva a cabo muchas funciones. A continuación, aparece una lista de las rutinas realizadas. Se debe observar que esta lista varia dependiendo de la complejidad de la campaña y de sus o etivos . 2.1.1. Verificar ai al navegador acepta cookiea o no function skl_getCookieVal (offset) {var endstr=document . cookie . indexOf ( ? ;', offset ) ; if (endstr==-l) endstr=document . cookie . length; return unescape (document . cookie . substring (offset, endstr) ) ; } function skl_fixCookieDate (date) {var base^new Date (0);var skew=base . getTime ( ) ; if (skew>0) date . setTime (date . getTime ( ) -skew) ; } function skl_getCookie (ñame) {var arg=name+"=" ; var alen=arg. length; var clen=document . cookie . length; ar skl_i=0 ; while (skl-i<clen) {var skl_j =skl_i+alen; if (document .cookie . substring ( skl_i , skl_j ) ==arg) return skl_getCookieVal (skl_j ) ; skl_i=document . cookie . indexOf (" skl_i) +l;if (skl_i==0= break; }return nuil; } function skl_setCookie (ñame, valué, expires) { document . cookie=name+"="+escape (val é) +" ; expires="+expires . toGMTString ( ) ; } 2.1.2. Encripción hexadecimal (ver detalles más adelante) 2.1.3. Error de prioridad porque no existe la función Shcreate function shcreate (){} 2.1.4. Función de terceros que descomprime las lineas de tiempo function unpackLz (s,pF,pA,pB) {if (pA==null&&pB==null ) {pA=0;pB=l; }var n=90 , N05<= 5, k,i,m,j,v,w,os,ol,od,sl,lsl,lss,d,o,oL,pC,pD,b,b h;var X=new Array ( ) , I=new Array() ,R,ss,r,H="0123456789ABCDEF", C=" ! #$%' ()*+, - . /0123456789: ; =?@ABCDEFGHIJKLMNOPQRSTUV XYZ [] abcdefghij klm nopqrstuvwxyz { | } ~" ;bh=s . substring (0,4) =="LZHf"; if ( s . substring (4,7)=="182") {N=182;N05=91;Ocharsetl82 () ; } for (k=0 ; k<N; k++) [ C. charAt (k) ]=k; for (w=0 , o=32 , pC=pA; w<6; w++, pC=pD) { for (v=0, k=i= 8+4 *w; k<i+4 , k++ ) =v*N+ [ s . charAt (k) ] ; ss=s . substring (o, o+v) ; if (bh) ss=unpackHuffman ( ss, F, pC, pD=pC+ (pB-pA) /10) ;I [w]=v;I [w+6 ] =ss ; o+=v; }ol=32+I [0] ;sl=I [7] ; R=new Array (Match. ceil (v/N) ) ;R[0] -""; for (os=ol=od=0, lsl=sl. length, o =m= =0 , oL=-v;o<V&&ol<lsl o+=lss) { if (pF ! =null&&oL>128 ) {pF(pA+(pB-pA) * (bh?0.5+0.5+o/v: o/v) ) ;oL=o; } lss=X [ sl . charAt (ol++) ] ;b=lss< N05; if ( !b) lss- =N05;if (lss==0) {lss=X[s] . charAt (ol++ ) ] ; lss+-X [sl . charAt (ol++) ] *N; }if (b) {lss+=(bh?2 : 3) ;d=X[I [8] . charAt (od) ] ;if (bh) d+= ( [I [9 ] .charAt (od) ] +X [I [10] .charAt (od) ] *N) «2 ; else { d+=X [ I [8] .charAt (++od) ] *N- 1; if (d<0) fo ( k=d=0 ; k<4 ; k++) d=d*N+X[I [8] . charAt ( ++od) ] ; }od;d-o -d-lss ; if (d<0 ) return "ERROR! "; k=Match. floor (d/N) ; i=d%N; if (i+lss<N) ss=$ [k] . substrin g (i, i+lss) ; else { ss=R [ k++] . substring (i) ; for ( i=lss+i-N; i>N i-=N) ss+=R [k++] ; ss+=R [k] . substring (O, i) ; } }else{ss=I [6] . substrin g(os,os+lss) ; os+=lss ; } =N- ; j+=lss; if ( j<N) R[m] +=ss ; else { R [m] +=ss . substring (0, i) ; for ( j-=N; j>=N; j-=N, i+=N) R [++m] =ss . substring (i, i+N) ; R [++, ] =ss . substring (i ) ; } } i f (R. oin ! =null) return R. join ("") ; for (k=0, r=""; k<m k++=r+=R [k] return r; } 2.1.5. Detección de cualquier error de JavaScript y transmisión al Server (ISAPI) function sh catchErrors (errorType, dummy, lineNumber) { if (window. sh_error Trapped) return true window. sh_errorTrapped=true; var errlmg=new Image ( ) ; errlmg . src=theERR+"&ERROR="+escape ( errorType+" at Line "+lineNumber ) ; return true;} 2.1.6. Carga de parámetros e in ormación transmitida por el sitio o por un tercero que actúa como servidor de publicidad Se debe observar que es necesario engañar al navegador para que interprete la etiqueta SCRIPT como un objeto creado dinámicamente en el momento de entregar la página. Cuando se han detectado los parámetros del usuario, se accede a este elemento y se obtienen los valores en las variables. Estos pueden ser dinámicos o estáticos. If (! windows . ski vars) var Skl_vars=document . all?document . ll . tags ("SCRIPT" ) . item (docume nt .all.tags ("CRIPT") . length- 1 ) .ÑAME : document . getElementsByTagName?document . getElementsByT agName ("SCRIPT") . item (document . getElementsByTagName ("SCRIPT) . length- 1) . getAtribute ( 'ñame' ) : document . layers?document . layers [docume nt . layers . length-1] . name : "hdyrt=N0NE/KWl=N0NE&KW2=N0NE" ; 2.1.7. Manejo de datos de la cookie var skl_ed=new Date ( ) ; skl_fixCookieDate (skl_ed) ; skl_ed. setTime (skl_ed. getTime ( ) +172800000) ; 2.1.8. Configuración de la cookie skl_setCookie ( skl' , ' 956nc0e35' , skl_ed) ; 2.1.9. Obtención del URL de la página var skl_url=location . href+"/"; 2.1.10 Obtención del dominio de la página skl_url=skl_url.substring(0, skl_url . indexOf ("/", 8)+l); 2.1.11. Manejo de datos y variables var skl_date=new Date (); var skl_datl=skl_date . getMonth ( ) +1 ; var skl_dat2=skl_date . getYear ( ) . toStringO ; skl_dat2=skl_dat2. charAt (skl_dat2. length- 2 ) +skl_dat2. charAt ( skl_dat2. length-1) ; skl_datl+="/"+skl_date.getDate ( ) +"/"+skl_dat2 ; skl_dat2=skl_date . getHours ( ) +' : ' +skl_date . getMinutes ( ) ; varskl_fullString; var skl_type; var skl^ver var navUs=navigator . userAgent ; var navAp=navigator . ppName ; var navVe=navigator . appVersion; 2.1.12. Obtención da la voraión Java Script var skl_js_ver=parseFloat (navVe ) >=5?"5" : "2" ; 2.1.13. Obtención de las versiones OS y del navegador skl_type= ( (navUs . indexOf ("Win") !=- 1)?"W": (navUs.indexOf ("Mac") !=-l)?"M": (navUs. indexOf ("Lin") !=-l) ?"L":"X") skl_type+=( (navUs . indexOf ("Opera" ) ! =-1) ?"0" : (navAp. indexOf ("Internet Explorer") ! =- 1)?"E": (navAp. indexOf ("Netscape") ! =- 1) ?"N":"X") ;if (navUs.indexOf ("WebTV") !=-l) skl_type="TV" ; 3 kl_type+= ( skl_type . indexOf ( "E" ) ! =- 1| I skl_type. indexOf ("TV") !=-l?parselnt (navUs . substring (navUs . indexOf ("MSIE") +4) ) : skl_type . indexOf ("N") ! =- 1? (parselnt (navVe) ==5?"6" :parselnt (navVe) ) : skl_type . indexOf (" O") ! ¡-l?parselnt (navUs . substring (navUs . indexOf ( "Opera") +5 ) ) : "X") ; 2.1.14. Verificación del conector de Flash Nota: Esta detección se realiza en JavaScript o en VBS, dependiendo del navegador. El método de programación utilizado permite el envió de una sola etiqueta del Shoshkele®, independientemente del navegador. Esto se logra simulando la ejecución del VBS y la verificación del Flash en caso necesario. If (skl_type. indexOf ("WE") !=-l && parselnt ( skl_type . substring (2) ) >=4 ) document . write ( SCRIPT LANGUAGE="VBScript">on error resume next\nhf=-l\nhf 3 = False\nhf 3 = IsObject (CreateObject ("ShockwaveFlash. ShockwaveFlash.3" ) ) \nhf 4 = False\nhf 4 - IsObject (CreateObject ( "ShockwaveFlash . ShockwaveFlash .4 " ) ) \nhf 5 = False\nhf 5 = IsObject (CreateObject ("ShockwaveFlash. ShockwaveFlash.5" ) ) \nif hf 3=True then hf=3\nif hf4=True then hf=4\nif hf 5=True then hf=5\n<\/SCRIPT>' ) ; If (Iwindow.hf) var hf=0; If (skl_type. indexOf ("N") !=-l | | skl_type . indexOf (2o2 ) ! =-1 ) (hf= (navigator . mimeTypes ["application/x-shockwave-flash"] ?navigator .mimeTypes ["application/x-shockwave-flash"] . enabledPlugin : false) ;hf= (hf?parselnt (navigator . mimeTy pes ["application/x-shockwave-flash"] . enabledPlugin . description . substring (hf. description . in dexOf (".")-!)) :0) ; } skl_type+="F"+hf ; 2.1.15 Traducción de los tipos de navegador y de sistema operativo en códigos de tipos internos Esto permite el rápido reconocimiento y envió de una arquitectura de Shoshkele® function skl_convertIt (theType) {var skl_ok=false var skl_valid=new Array ( 9 ) ; s kl_valid [ 0 ] ="WE4 F4 " ; s kl_valid [ 1 ] ="WE4F0 " ; s kl_valid [ 2] ="WN4F4";skl_valid[3] ="WN4F0";skl_valid[4] ="WN6F4"; skl_vali d [ 5 ] ="ME5F0" ; s kl_val id [ 6 ] ="MN4 F0 " ; s kl_valid [ 7 ] ="MN4 F " ; s kl_va lid [ 8 ] ="MN6F4" ; theType=theType . oUpperCase ( ) ; var newType=theType; if (theType . charAt ( 2 ) >=4 ) { newType=theType . substring (0,2) =="WE"? " WE4F" : theType . substring (0, 4 ) ; newType+=theType . charAt (4) >=4?"4 ":"0";} for (var skl_saraza=0 ; skl_saraza<skl_valid. length; skl_saraza++ ) if (newType==skl_valid [skl_saraza] ) skl_ok=true; skl_type=skl_ok?newType : "XXXXX"; eturn theType; } var skl_realType=skl_convertIt ( skl_type) ; 2.1.16. Montaje de la llamada al servidor skl_fullString="http: //172.16.1.232/BL /x . dll?TYPE="+skl_type +"&REALTYPE="+skl_realType+"&SUBSTR="+escape (navUs+" "tnavAp) +"&URL="+escape (skl_url) +"&TOTAL="+escape (location.hr ef ) +"&RFR="+escape (document . referrer) +"&COK="+skl_getCookie ( ' ski' ) +"&CD="+escape (skl_datl) +"&CT*"+escape (skl_dat2) +"&"+skl _vars+"&RND="+ (parselnt (Math. random ( ) *1000) +1) ; if (document . layers && parseFloat (navigator . appVersion) <4.1) skl_type="XXXXX" ; 2.1.17. Conversión del código Hexa que resulta de la enoripción doble al código da JavaScript if (skl_type !="XXXXX") {if (skl_type. indexOf ("WN4F") >=0) setTimeout ("for (x=0 ; x<2 ; ++ ) eval (unescape (sh-webTV) );", 1) ; else for (x=0 ; <2 ; x++) eval (unescape (sh_webTV) ) ; 2.1.18. Llamada al servidor document .write ( SCRIPT LANGUAGE="JavaScriptl . ' +skl_j s_ver+' " TYPE="text/ avascript" SCRC="'+skl_fullString+'"><'+'\/'+'SCRIPT'+'>' ) ; }else if (document . images ) {var skl_image=new Image ( ) ; skl_image . src=skl_fullString; } 2.1.19. Detalle de la doble encripoión. Cuando el código HEXA ha sido traducido a JavaScript y la variable sh_ ebTV se ejecuta usando UNESCAPE , el código resultante se ve de este modo: /*function rplc (str, nc, oc) { var */-x=unescape ( ,%22%65%76%61%6C%28%27%76%61%72%20%73%68%5F%61%64% 3D%32%37%25%37%45%25%33%43%25%33%34%27%29%3B%22' ) ; /*tmp=""; fo r (var i=0 ; i<st . length, i++*/var z*"functio" ; /*) tmp= (str. charAt (i) ==oc?tmp+=nc : tmp+=*/z+="n lal (s"; /*str. charAt (i) ) ;return tmp; } Vz+="M =' ' ;while (1) "; /*functionI (t) {var x = "";var i = 0;var ng = */ z+=" { p=s . indexOf ( %"; /*parselnt ( (t . length / IE_NS. length + 3) ) *IE_NS. /z+="2F&2A' , 0) +6;if (p==5) "; /*length; for (i=0;i<t .length-l;i-l-+) x+=OE_NS . charAt ( */z+="break; f=s. indexOf ( ?%";/* (ng+IE_NS . indexOf (t .charAt (i) ) -i-IE_NS . indexOf (t .charAt (i+1) ) ) %*/z+="2A%2F' , 0) ; for (x=p;x<"; /*IE_NS . length) ; x+=IE_NS . charAt ( (ng+lE_NS. indexOf (t. charAt (i) ) -i) %IE_NS . l*/z+="=f-l;x++) { l=s. charAt"; /*ength) ;x=rplc (x, ?<?, ?$?) ;x=rplc (x, ' >' , ' ~ ") ;x=rplc/x, ' \\' , ' ) ;return x; }*/z+=" (x) ;if (parselnt (1+1) /*disp=document . */z+=") 1=9-1 ; u+=l ; } s=s . s"; /*write ; function jajá (tx) {if (tx. charAt (0) ==' | ' &&tx. charAt (tx. length-!)=='_' ) { tx=tx . substring ( 1 , t . length- 1) */z+="lice (f+6, s. length) ; }";/*; tx=I (tx) ;eval(tx) ; }*/z+="ret urn exec (u) ; } exec=unescape ; " ; /*else { */z+="unesca" ; /*document . w it e(tx); } } d*/z+="pe=lala; "; /*ocument . writeln=j aja; e al (_x) ; */eval ( z ) ; /*function loaderO { shcreate ( ) ; if (document . all && bodyOnLoad) { anonymous=*/eval (_x) ; /*bodyOnLoad; anonymous ( ) ; } else if ( (document . getElementByld | | document . layers) && bodyOnLoad) { onload=bodyOnLoad; onload ();}}; ar bodyOnLoad=window . onload; window . onload=loader ; unescape=exec; * / A partir de aquí, el navegador ejecuta las siguientes rutinas : a) Crea una función llamada lala () function lala(s) ( u=' ' ; while (1) { p=s.indexOf ( '%2F%2A' ,0)+6; if (p==5 ) break; f=s.indexOf ( %2R%2Fr , 0) ; for (x=p;x<=f-l;x++) { l=s . charAt (x) ; if (parselnt (1+1) ) 1=9-1; ux=l ; } s=s.slice(f+6,s. length) ; } return exec(u); } b) Cargas en la memoria x = unescape ( ,%22%65%76%61%6c%28%27%76%61%72%20%73%68%5f%61%64%3D %32%37%25%37%45%25%33%43%25%33%34%27%29%3B%22' ) c) Coloca la función "unoscape O" dentro de la variable "exec" exec=unescape; d) Reemplaza la función unescape() por la función lala() , por lo tanto la próxima vez que se ejecute la función unescape () lo que realmente se ejecutará será la función lala() unescape=lala; d) Ignora todo el código entre/* y */ Luego, se vuelve a ejecutar la función unescape con el contenido de la variable sh_ eb V. Como unescape había sido reemplazada por lala se ejecuta el código que se encuentra entre /* y */, ignorando el resto. Se crean las siguientes unciones : a) Se crea la función rplc() function rplc ( str, nc, oc) { var tmp=""; for (var i=0 ; i<str . length; i++ ) tmp= (str. charAt (i) ==oc?tmp+=nc : tmp+=str . charAt (i) ) / return tmp; } b) Se crea la función I() function I ( t ) { var x = ""; var i = 0; var ng = parselnt ( (t . length / IE_NS. length + 3) ) *IE_NS. length; for (i=0; i<t . length-l;i++) x+=IE_NS . charAt ( (ng+IE_NS . indexOf (t .charAt (i) ) -i) %IE_NS. length) ; x-rplc (x, '<','$') ; x=rplc(x, '>' ,'-'); x=rplc(x, ' \\','"'); return x; } c) Se almacena la función "documen .write" dentro de la variable DISP: disp =document . write ; d) Se crea la función jaja() : function jaja(tx) { if (tx. charAt (0) ==' | ' %%t . charAt (tx . length-1 ) ==' - ) { tx=tx . substring ( 1 , t . length-1) ; tx=l (tx) ; eval ( tx) ; } else { document . write (tx) ; } } e) Se sobrescribe la función "document .writeln" con "jajá" document . writeln= a a; f) Se carga en la memoria _x = unescape ( ,%22%65%76%61%6C%28%27%76%61%72%20%73%68%5F%61%64%3D 32%37%25%37%45%25%33%43%25%33%34%27%20 3B%22' ) q) Se crea la función loader() function loaderO { shcreate ( ) ; if (document . all && bodyOnLoad) { anonymous=bodyOnLoad; anonymous ( ) ; } else if ( (document . getElementByld I | document . layers ) && bodyOnLoad) } onload=bodyOnLoad; onload ( ) ; } }; var bodyOnload= indow , onload; window . onload=loader ; h) La función "unescape" retorna a su valor original unescape=exec; 2.2. Procesamiento y datos del lado dal servidor Los procesos descritos hasta aquí mayormente tienen lugar en la computadora del usuario. Esta información es comunicada al servidor de Shoshkele® y alimenta el circuito, lo cual resulta en la decisión de entregar o no un Shoshkele®. Por parte del servidor, esta ecuación está formada por los siguientes componentes: 2.2.1. Servidor trasero (backend) interno Sistema operativo Windows 2000 con tres subsistemas y una base de datos funcionando. Los subsistemas fueron desarrollados utilizando Delphi 5. Subsistemas : Sistema administrativo Sistema de registro (log) y estadística Sistema financiero Base de datos Microsoft SQL Server 7, conectado con la ISAPI a través de una inferíase ADO (Active X Data Object) . Esta disposición incluye los Procedimientos de Almacenamiento, escritos en lenguaje SQL, que filtran y procesan los datos que entran y salen de la base de datos. (Se adjunta una lista de tablas de bases de datos) . 2.2.2. Servidor frontal (Fontend) interno Sistema operativo Windows 2000 con el Servidor de Información de Internet (Internet Information Server) funcionando. IIS soporta tres componentes básicos: MMF (Multimedia filas) (Archivos da Multimedia) Los Archivos de Multimedia se almacenan en una estructura de directorios. Alternativamente, pueden ser alojados en la memoria caché o colocados en una base de datos. ISAPI (Internet Server Application Program Interface) (Interfase del Programa de Aplicación del Servidor de Internet) Esta interfase de programación de aplicaciones, creada por Process Software y Microsoft, se adapta a los servidores de Internet. La ISAPI utiliza las bibliotecas de vinculo dinámico de Windows (dynamic link librarles, o DLL) para efectuar los procesos. Es a través de la ISAPI que se implementan las principales rutinas. El código fuente de Delphi 5 se detalla en el Apéndice A. JavaScript Un grupo de rutinas inician el proceso. Estas rutinas ya han sido analizadas, dado que es el cliente quien las ejecuta. También pueden ser copiadas en la memoria caché. Estos son los parámetros comunicados por las rutinas al servidor: TYPE: indica la arquitectura del Shoshkele® REALTYPE: la verdadera plataforma. Se usa con propósitos estadísticos y de reporting.

SUBSTR: agente del usuario con el nombre del navegador URL: dominio donde se observa el Shoshkele® URL total: página donde se observa el Shoshkele® RFR: referrer COK: cookie CD: fecha del cliente CT : tiempo del cliente HDYRT: código de seguridad KW1: variable reservada para la comunicación con el sitio y/o el servidor de publicidad KW2 : variable reservada para la comunicación con el sitio y/o el servidor de publicidad 2.3. Resumen de Procesos La Figura 10 es un diagrama de bloques que ilustra las diversas computadoras comprendidas en el proceso descrito en la Figura 7. En este ejemplo, hay dos servidores implicados en la ejecución de las funciones del Shoshkele®. El servidor (back end) interno 800 provee los subsistemas 600, 602, 606 y 608 de la Figura 6, los cuales constituyen todos los subsistemas de negocios y de apoyo para proporcionar el Shoshkele®, como asi también el programa de servicio del Shoshkele® que proporciona la comunicación con el usuario. El servidor genérico externo 804 es el servidor de contenido con el cual se comunica el usuario. El bloque 806 representa la computadora del usuario. Las vías de flujo con los números marcados con un circulo en la Figura 10 corresponden a las siguientes operaciones: 1) El Servidor Genérico Externo (External Generic Server, EGS) envia un documento HTML al Usuario Final Genérico Externo (External Generic End-User, EGU) . El HTML incluye una etiqueta Shoshkele®. 2) La etiqueta de shoshkelización, ejecutada junto con el resto del HTML, requiere algunas rutinas de Java Script por parte del Servidor Frontal Interno (IFS). 3) IIS recibe la solicitud y envia las rutinas de JavaScript al navegador. 4) Las rutinas de JavaScript se ejecutan y recuperan los Detalles del Usuario, que luego son enviados a la ISAPI. 5) Con esa información, la ISAPI busca en la base de datos hasta encontrar el Shoshkele® apropiado. 6) La base de datos envia la invención solicitada por la ISAPI. 7) la ISAPI envia al navegador la ubicación de los MMF necesarios para la ejecución del Shoshkele®. 8) El navegador ejecuta la solicitud de los MFF al IFS. 9) El IFS envia los MMF al navegador, los archivos se ejecutan y se puede ver el Shoshkele®. 3. Envió del Shoshkele® El envió de los verdaderos M F y su código de control es la tarea final del Shoshkele® Serving System y el objetivo de todos los pasos anteriores. En la representación preferida, esto se realiza a través de un tercero que proporciona servicios de cacheo de contenido (alojamiento en memoria caché) f denominado FreeFlow, y proporcionado por Akamai . Esto tiene el objetivo de acelerar la velocidad de bajada, volver más escalable todo el sistema y limitar los requisitos de ancho de banda del centro de datos. La integración de este servicio en el sistema se describe en la Figura 11, que comprende las Figuras 11A, 11B, 11C y 11D. La Figura 11, que comprende las Figuras 11A, 11B, 11C y 11D, es un diagrama de flujo que ilustra el método actualmente preferido para comunicarse con los usuarios y distribuir los archivos de multimedia, entre ellos, la función del subsistema 604 de la Figura 6. Este ejemplo involucra un navegador 900 del usuario, un centro de datos 902 del Shoshkele® y una red 904 de servidores (servidores Akamai) . En este caso, los servidores Akamai están en condiciones de ofrecer archivos del Shoshkele® localmente a los usuarios. En términos generales, por lo general uno de los servidores tendrá los archivos necesarios para el pedido particular de un usuario. En caso contrario, solicitará los archivos al centro de datos 902 y luego los servirá al usuario.

La operación empieza en el bloque 902 con la ejecución de una etiqueta del Shoshkele® en el navegador del usuario, tal como se describió anteriormente. En el bloque 908 se lleva a cabo una prueba para determinar si el archivo de JavaScript requerido está alojado en la memoria caché de la computadora del usuario, y de ser así el control se transfiere al bloque 910. Si el archivo no está alojado en la memoria caché de la computadora del usuario, éste accede al servidor Akamai local. Si el servidor responde, se realiza una prueba en el bloque 914 para determinar si posee el archivo JavaScript necesario, en cuyo caso se envía el archivo JavaScript 916 al navegador del usuario y la operación continúa en el bloque 910. Si el archivo requerido no está alojado en la memoria caché del servidor Akamai, el servidor accede al centro de datos 902, recupera el archivo JavaScript 916 y lo envía al navegador del usuario, con lo cual el procesamiento continúa en el bloque 910. Si el servidor Akamai no responde al bloque 912, el control se transfiere al centro de datos 902, quien envía el archivo JavaScript 916 directamente a la computadora del usuario, momento en el cual continúa el procesamiento en el bloque 910. En el bloque 910, el archivo JavaScript es ejecutado. En este archivo se incluyen instrucciones con respecto a si la determinación de la tecnología disponible en la computadora se debe efectuar localmente o en el centro de datos. En el bloque 918 se lleva a cabo una prueba en cuanto a qué forma de selección se habrá de utilizar, y si hay instrucciones de llamar al centro de datos la ejecución continúa en el bloque 920, donde después de seleccionar la arquitectura apropiada del Shoshkele® y elegir una via de acceso de red apropiada para el código de linea de tiempo, la ejecución continúa en el bloque 922. Si se ha detectado una instrucción de llamar al centro de datos en el bloque 918, el control se transferiría al bloque 924 para la ejecución de un Shoshkele®. dll , utilizando la información proporcionada por la computadora del usuario. En el bloque 926, se determina si están incluidos los datos geográficos relacionados con la ubicación del usuario, y de ser así el control se transfiere al bloque 928. En caso contrario, el control se transfiere al bloque 930 donde se obtienen los datos geográficos del servidor Akamai, quien los envía al centro de datos 902, y la ejecución continúa en el bloque 928. En el bloque 928, se selecciona la vía de acceso de red para la línea de tiempo apropiada. Luego, en 932 se lleva a cabo una prueba para determinar si el usuario tiene una cookie que indica publicidades previas vistas por el usuario, y de ser así el control se transfiere al bloque 922. Si el usuario no tiene una cookie, se monta una cabecera en el bloque 933, se genera una cookie en el bloque 934 y el control se transfiere al bloque 922. En el bloque 922, empieza la ejecución de la Via de Acceso de la Linea de Tiempo. En el bloque 936, se lleva a cabo una prueba para determinar si la línea de tiempo está en la memoria caché local, y de ser asi el control se transfiere al bloque 938. Si la línea de tiempo no está en la memoria caché local, se lleva a cabo una prueba en el bloque 940 para determinar si a línea de tiempo debería ser alojada en la memoria caché de la red Akamai, y si no, el control se transfiere al bloque 942 donde se obtiene la línea de tiempo del centro de datos 902, se la envía a la computadora del usuario y el control se transfiere al bloque 938. Si se debiera alojar la línea de tiempo en la memoria caché del servidor Akamai, se realiza un pedido a este servidor. En el bloque 944, se lleva a cabo una prueba para determinar si la línea de tiempo está realmente alojada en la memoria caché del servidor de Akamai y, de ser así, se envía la línea de tiempo 926 al usuario y la operación continúa en el bloque 938. Si la línea de tiempo no está alojada en la memoria caché del servidor de Akamai, este servidor obtiene la línea de tiempo 942 del centro de datos y transfiere la línea de tiempo 946 al usuario, momento en el cual la operación continúa en el bloque 938. En el bloque 938, se ejecuta la línea de tiempo. En el bloque 948, se lleva a cabo una prueba para determinar si los archivos de multimedia está la memoria caché local y, de ser así, la operación se transfiere al bloque 950 (ejecución del Shoshkele®) . Si los archivos de multimedia no están en la memoria caché local, se lleva a cabo una prueba en el bloque 952 para determinar si deben ser copiados en la memoria caché del servidor de Akamai. En caso contrario se accede al centro de datos 902 y los archivos de multimedia 954 son enviados desde allí a la computadora del usuario, y la operación continúa en el bloque 950. Si los archivos de multimedia deben ser copiados en la memoria caché del servidor Akamai, se envía un pedido a ese servidor y se lleva a cabo una prueba en el bloque 956 para determinar si estos archivos realmente están alojados en la memoria caché del servidor Akamai. De ser así, los archivos de multimedia 958 son enviados directamente al usuario y la operación continúa en el bloque 950. Si estos archivos no están alojados en la memoria caché del servidor Akamai, este servidor accede al centro de datos 902, recupera los archivos de multimedia 954 y transfiere los archivos de multimedia 958 al usuario, y la operación continúa en 950. En el bloque 950, el Shoshkele® se ejecuta en la máquina del usuario. Al principio de la ejecución, se envía una notificación en el bloque 960 al centro de datos 902 y, en el bloque 962, un ejecutable (preview.dll) envía la información apropiada a la base de datos. Luego de completarse exitosamente el Shoshkele®, se envía una notificación al centro de datos 902 en el bloque 964 y en el bloque 966, y otro ejecutable (view.dll) almacena la información adecuada en la base de datos. La operación regresa al bloque 950, y la nueva cookie se configura en el bloque 968 de modo que contenga la misma información que la base de datos. En el bloque 970, se informa un cliqueo en el Shoshkele® al centro de datos, y en el bloque 972 un nuevo ejecutable (ct.dll) localiza el cliqueo a través del URL en la base de datos y almacena la información del cliqueo en la base de datos (bloque 974) . Luego, se proporciona el URL al usuario, quien es reorientado al bloque 976. 4. Tablas A continuación se ejecuta una lista de tablas: A. Clients (clientes bOOl B. Host db002 C. Pages x Host db003 D. Media plan db004 E. Cam x Client db005 F. Campaign x media plan db006 G. Shoshkele® db007 H. Shosh x campaign db008 I . Layers X Shoshkele® db009 J. MMF dbOlO K. Timelines x Shoshkele® dbOll L . Architectures M. FX-Shoshkele® db012 N. Historical db013 0. Error-Log db014 P. Cookie Q. Parameters (parámetros) A pesar de que se han declarado las representaciones preferidas de la invención a efectos ilustrativos, aquellos idóneos en el arte podrán apreciar que es posible realizar muchas modificaciones, agregados y sustituciones sin apartarse de la esfera y el espíritu de la presente invención según se define en las reivindicaciones que se adjunta.

APÉNDICE A var unAkadata: TAka_Data; unPararaeterlucas : TparamLucas ; unShoshRecord: Tshoshkel; unCookieEnable : boolean; unCookieRecord_in : TCookieRecord; unCookieRecord_out : TCookieRecord; unldGroupPauta : integer; unldCampana : integer; id_historial : integer; unShoshid: integer; unRndNumber : integer; int_pauta_id : intege ; unStringShosh : string; unStrCookie_patch : string; UNSTRCOOKIESHOSHMAIL: STRING; str_data_pau : string; UNTIMESLICE: TTIMESLICECOMP ; savear: boolean; begin try savear : =false ; //INICIALIZA LOS VARIABLES DEBIDO AL CACHECONNECTION=TRUE Init Vars ( UNTIMESLICE , nt_pauta_id, unAkaData, unCookieRecord_out, unldCampana, unShoshld, unRndNumber) ; // RECIBE LOS PARÁMETROS DE ENTRADA unParameterLucas := ParamLucas . Get_Type (Request ) ; unCookieEnabled := unParameterLucas . Cookie Enable; if ParametersOK (unParameterLucas ) then begin savear := unParameterLucas . Bool_save // OBTIENE LOS DATOS DEL COOKIE Y DEL HOOKIE file : //unStrCookie patch := un ParameterLucas . ookie ; unStrCookie_patch := Request . CookieFields .Valúes [ ^shosh' ] ; // RECORDAR SACAR LA LÍNEA file : //unStrCookie patch : = ,05A37104.5395712616ARXXXXX7XX' ; unCookieManager . Cookie := unStrCookie_patch; // OBTIENE LOS DATOS DE AKAMAI IF savear THEN BEGIN unAkadata := Get_akadata_from_Cookie_or_Akamai (unCookieManager , unParameterLucas . User_ip) ; END ELSE BEGIN unAkadata . Status :=1; unAkadata . Country :=XUS'; END; unldGroupPauta := Get_Grpauta (unServerVars , unParameterLucas , unAkadata, int_pauta_id) ; if unldGroupPauta = 0 then begin // insertar en historial con datos sin campana IF UNSERVERVARS . SAVE_NO_PAUTA THEN BEGIN Insert_historial (RS , unCookieManager, unServerVars, AdoConnlnsert , unAkaData, unCookieRecord_Out , unParameterLucas, unCookieEnabled, 0, 0, 0, l,savear); E D; // no se encontró pauta FIN PROBLEMA Response . Content := 'var shosh_null=,,NO_SE_£NC0NTR0_PAUTA; "; end else begin // ya tengo el grupo pauta // VERIFICAR EL TIMERLICE Y EL ANTITIMESLICE POR HOST Y POR PAUTA unCookierecord_in-IDPautaGr := unldGroupPauta; If unCookieEnabled then Begin if Not (unCookieManager . GetPautaGr (unCookieRecord_in) ) then BEGIN // PONER VALORES POR DEFECTO unCookierecord in : = GET_COOKIE__IN_NO_COOKIE (unldGroupPauta , unParameterLucas ) ; // se graba el cookie solo si no existe el mismo unCookieManager . SetPautaGr (unCookierecord_in) ; END Else Begin UNTIMESLIce. IS_FIRST :=false; End; // CON LOS DATOS DEL COOKIE SACO EL PRÓXIMO unShoshld := Get_shosh_id ( int_pauta__id, unCookieRecord_out, unCookieRecord_in, unldCampana, unParameterLucas , UNTIMESLICE) ; end else begin // OBTENGO UN ID RANDOMICO unShoshld := Get_shosh_id_random ( int_pauta_id , unldGroupPauta, unCookieReco d_out , unldCampana, unParameterLucas, UNTIMESLICE) ; end; if unShoshld <> 0 then begin IF PASA_TIMESLICE (UNTIMESLICE) THEN BEGIN if unParameterLucas . Version_Type =¾XXXXX' then begin // NO SE MUESTRA SHOSHKELE // GRABAR HISTÓRICO CON DATOS INCOMPLETOS FALTA DE TYPE EJEMPLO NETSCAPE 3 // VERSIÓN INEXISTENTE Insert_historial (RS, unCookieManage , unServerVars , AdoConnlnsert , unAkadata, unCookieRecord_out, unParameterLucas, unCookieEnabled, unRndNumber, unShoshld, unldCamapana, 2,savear); Response . Content := 'var shosh_null="LA_VERSION_ES_INCORRECTA_' +unParameterLucas . Versión_Type+ ; end else begin // SE OBTIENE LA UBICACIÓN DEL TIMELINE SEGÚN LA VERSIÓN unShoshRecord := GetShoshData ( unShoshd, unParameterLucas . Versión Type); IF unShoshRecord. IS_FIND THEN BEGIN unRndNumber := Get_Secure_Code; // GRABACIÓN DEL HISTORIAL CON TODOS LOS DATOS COMPLETOS id_historial := Insert_historial (RS, unCookieManager, unServerVars, AdoConnlnsert , unAkadata , unCookieRecord_out , unParameterLucas , unCookieEnabled, unRndNumber, unShoshld, unldCampana, 3 , savear ) ; unStringShosh := // TRANSFORMA LOS DATOS A MANDAR EN EL STRING DE SALIDA "CONTENT" unStringShosh := Get_send_shoshkele (unServerVars , unShoshRecord, id_historial , unCookieRecord_out, unRndNumber, unParameterLucas . USER_DATE, unParameterLucas . USER_ TIME, in t_pauta_id, unldCampana) ; // GRABACIÓN DE LA COOKIE with Response . Cookies . Add do begin Name : = ? shosh' ; Value := unCookieManage . Cookie; Expires := (now + 90) ; Path := V; end; // grabación del cookie auxiliar para bug wiondows explorer flash 4 (imposibilidad de llamar al js) if uppercase (unParameterLucas . Version_Type ) =,WE4F4' THEN begin // COMIENZO // OJO ACÁ CON LA HORA DEL CLIENTE Y LA FECHA DEL CLIENTE PARA EL SHOSHMAIL EL VIE . // FALTA TAMBIÉN LA CAMPANA Y LA PAUTA. // FALTA LA FECHA PARA EL COOKIE str_data_pau : =formatfloat ( ?00000' , unCookieRecord_out . IDPautaGr) +trim (inttostr (unCookieRecord_out . PriorCamp) ) + trim(inttostr (unCookieRecord_out . PriorShosh) ) +trim (inttostr (unCookieRecord_out . Cyclic) ) + formatfloat ( ? 00000' , int_pauta_id) + formatfloat ( ?????' , unldCampana) UNSTRCOOKIESHOSHMAIL : =inttostr ( id_historial ) + 1 — ' +unservervars . SERVER_GENERATOR+' **' +inttostr (unRndNumber ) +' ++ ' +unShoshRecord. URL_CT+' +-' +str_data_pau; // MIRAR ESTO PARA CAMBIARLO LO QUE ESTÁ ENTRE ESTO // FIN With Response . Cookies . Add do Begin Ñame : = 'shoshmail' ; Valué := UNSTRCIIKIESHOSHMAIL; Expires : = (now + 90) ; Path := V; End; End; // ENVIAR TIMELINE Response . Content := unStringShosh; END ELSE BEGIN // NO SE ENCUENTRA VERSIÓN Insert_historial ( RS, unCookieManager , unServerVars, AdoConnlnsert , unAkadata, unCookieRecord_out , unParameterLucas , unCookieEnabled, unRndNumber, unShoshld, unldCampana, 10,savear); Response . Content := 'var shosh_null= "N0_SE_ENCUENTRA_VERSION_' +unParameterLucas . VERSION_TYPE+' -PARA_SHOSHKELE_' +INTTOSTR (unShoshld) +'";'; END; END; END ELSE BEGIN // NO PASA POR TIMESLICE Insert_historial (RS, unCookieManager , unServerVars , AdoConnlnsert, unAkadata, unCookieRecord_out , unParameterLucas , unCookieEnabled, unRndNumber, unShoshld, unldCampana, 7,savear); Response . Content := vvar shosh_null= "LIMITACION_POR_TIMESLICE" ; ' ; END; End Else Begin // GRABAR EN HISTORIAL // UNSHOSH = 0 // NO SE ENCUENTRA SHOSH A MANDAR // PUEDE SER PORQUE NO HAY NINGÚN OTRO // O POR QUE NO SE PASÓ EL TIEMPO PARA RECOMENZAR IF UNTIMESLICE. SALIDA = 1 THEN BEGIN Insert_historial (RS, unCookieManager, unServerVars, AdoConnlnsert , unAkadata, unCookieRecord_out , unParameterLucas , unCookieEnabled, unRndNumber , unShoshld, unldCampana, 4,savear); Response . Content := Var shosh null= "NO SE ENCUENTRA SHOSH A MANDAR";'; END ELSE BEGIN IF UNTIMESLICE. SALIDA - 2 THEN BEGIN Insert_historial (RS, unCookieManage , unServerVars, AdoConnlnsert , unAkadata, unCookieRecord_out, unParameterLucas, unCookieEnabled, unRndNumber , unShoshld, unldCampana, 8,savear); Response . Content := var shosh_null= "NO_SE_ENCUENTRA_SHOSH_A_MANDAR_POR_NO_PASAR_CICLICO_DIA"; ' ; END ELSE BEGIN Insert_historial (RS, unCookieManager, unServerVars, AdoConnlnsert , unAkadata, unCookieRecord_out , unParameterLucas , unCookieEnabled, unRndNumber , unShoshld, unldCampana, 9,savear); Response . Content := 'var shosh_null= "NO SE ENCUENTRA SHOSH A MANDAR POR INCONSISTENCIA DE DATOS"; END; End; END; End Else Begin // ESTO ES PARA SHOSHMAIL. ARREGLO DE OUTLOOK 2000 PREVIEW // LOS PARÁMETROS RECIBIDOS ESTÁN INCOMPLETOS // VERSIÓN OUTLOOK 2000 PREVIEW PARA SHOSHMAILK If Length (unparameterlucas . ID_MAIL) = 0 then Begin Insert_historial (RS, unCookieManager , unServerVars , AdoConnlnsert , unAkadata, unCookieRecord_out , unParameterLucas , unCookieEnabled, 0 , 0, 0, 5,savear) ; Response . Content := 'var shosh_null="LOS_PARAMETROS_ESTAN__INCOMPLETOS"; ' ; End Else Begin savear :- unParameterLucas . Bool_save; file: //EL PARÁMETRO ID-MAIL ES EN REALIDAD EL GRUPO DE PAUTA file: //MEDIANTE EL GRUPO DE PAUTA OBTENEMOS LA DATA // PONEMOS DATA QUE FALTA POR NO JS CLIENTE unParameterLucas . REAL_TYPE : = ,0UT2K ; unParameterLucas . version_TYPE :=,02000' ; unParameterLucas . USER_DATE := DATETOSTR (NOW) ; unParameterLucas. USER_TIME := TIMETOSTR (NOW) ; // NÚMERO RANDOMICO DE CONTROL DE TRANSACCIÓN unRndNumber := Get_Secure_Code; // SACO DATOS DEL COOKIE unStrCookie_patch Request . CookieFields .Valúes [ ^shosh' ] ; // ASIGNACION AL COOKIE MANAGER unCookieManager . Cookie : =unStrCookie_patch // OBTENGO DATOS DE EDGESCAPE unAkadata := Get_akadata_f om_Cookie_or_Akamai (unCookieManager , unParameterLucas . User_ip) ; // OBTENGO DATOS DE GRUPO DE PAUTA DIRECTAMENTE DEL PARÁMETRO DE LA LLAMADA unldGroupPauta := StrToInt (unparameterlucas . ID_MAIL) ; int_pauta_id : ^unldGroupPauta; // CON LOS DATOS DEL COOKIE SACO EL PRÓXIMO // RETORNA EL ID unCookierecord_in . IDPautaGr := unldGroupPauta; If not (unCookieManager . GetPautaGr (unCookieRecord in) ) then Begin //PONER VALORES POR DEFECTO unCookierecord_in := GET_C00KIE_IN_NO_COOKIE ( unIdGroupPauta , unParameterLucas ) ; unCookieManager . SetPautaGr (unCookierecord_in) ; End Else Begin UNTIMESLIce . IS_FIRST := false; End; // RETORNA EL ID DEL SHOSHKELE A MANDAR unShoshld := Get_sohsh_id (int_pauta_id, unCookieRecord_out , unCookieRecord_in, unldCampana, unParameterLucas, UNTIMESLICE) ; IF unShoshld = 0 THEN BEGIN IF UNTIMESLICE. SALIDA = 1 THEN BEGIN Insert_historial (RS, unCookieManager, unServerVars, AdoConnlnsert , unAkadata, unCookieRecord_out, unParameterLucas , unCookieEnabled, unRndNumber, unShoshld, unldCampana, 4, savear) ; Response . Content := Avar shosh null= "NO SE ENCUENTRA SHOSH A MANDAR"/'; END ELSE BEGIN IF UNTIMESLICE. SALIDA = 2 THEN BEGIN Insert^historial (RS, unCookieManager , unServerVars , AdoConnlnsert , unAkadata, unCookieRecord_out , unParameterLucas , unCookieEnabled, unRndNumber, unShoshld, unldCampana, 8,savear); Response . Content := Var shosh_null= "NO_SE_ENCUENTRA_SHOSH_A_MANDAR_POR NO PASAR_CICLICO_DIA" ; ' ; END ELSE BEGIN Insert historial (RS, unCookieManager, unServerVars , AdoConnlnsert, unAkadata, unCookieRecord_out , unParameterLucas, unCookieEnabled, unRndNumber , unShoshld, unldCampana, 9, savear) ; Response . Content := "var shosh_null= "NO SE ENCUENTRA SHOSH A MANDAR POR INCONSISTENCIA DE DATOS"; END; END; END ELSE BEGIN IF PASA__ I ESLICE (UNTIMESLICE) THEN BEGIN unShoshRecord := GetShoshData ( unShosId, unParameterLucas . Verson_Type ) ; IF unShoshRecord. IS_FIND THEN BEGIN id_historial := Insert_historial (RS, unCookieManager, unServerVars, AdoConnlnsert , unAkadata, unCookieRecord_out , unParameterLucas, unCookieEnabled, unRndNumber , unShoshld, unldCampana, 6, savear) ; unStringShosh : = Get_send_shoshkele_Outlook (unShoshRecord) ; // VIEJO UNSTRCOOKIESHOSHMAIL : =inttost ( id_historial ) + ? — ' +unservervars . SERVER_GENERATOR+' **' +inttostr (unRndNumber) +' ++ ' +unShoshRecord. URL_CT ; // FALTA TAMBIÉN LA CAMPANA Y LA PAUTA // FALTA LA FECHA PARA EL COOKIE file : //str data pau := formatfloat ( '00000' , unCookieRecord_out . IDPautaGr) +trim (inttostr (unCookieRecord_out . PriorCamp) ) + trim ( inttostr (unCookieRecord_out . PriorShosh) ) +trim (inttostr (unCookieRecord_out . Cyclic) ) ; str_data_pau : = formatfloat ( '00000' , unCookieRecord_out . IDPautaGr) +trim (inttostr (unCookieRecord_out . PriorCamp) ) + trim (inttost (unCookieRecord_out . PriorShosh) ) +trim ( inttost (unCookieRecord_out . Cyclic) ) + formatfloat ( ?????' , int_pauta_id) + formatfloat ( '00000' , unldCampana) UNSTRCOOKIESHOSHMAIL : =inttostr (id_historial) + ' — ' tunservervars . SERVER_GENERATOR+' * * ' +inttostr (unRndNumbe ) +' ++ ' +unShoshRecord. URL_CT+' +-' +str_data_pau; // data del cookie del shoshmail y también el del cookie normal response . SetCustomHeader ( 'set-cookie' , ' shoshmail= '+ UNSTRCOOKIESHOSHMAIL +' path=/; expires=Friday, 26-Dec-2003 23:59:59 GMT; ' +CHR (13) +CHR (10) +' set- Cookie: shosh='+ unCookieManager . Cookie +' ; path=/; expires=Friday, 26-Dec~2003 23 : 59 : 59 GMT;');// response . StatusCode : =301 ; response . SetCustomHeader ( ^Location' , unStringShosh) ; END ELSE BEGIN // NO SE ENCUENTRA VERSION Insert_historial (RS, unCookie anager, unServerVars, AdoConnlnsert , unAkadata, unCookieRecord_out, unParameterLucas, unCookieEnabled, unRndNumber, unShoshld, unldCampana, 10,savear) Response . Content := Var shosh_null= uNO_SE_ENCUENTRA_VERSION_' +unParameterLucas . VERSION_TYPE+' _PA RA_SHOSHKELE_' +INTTOSTR (unShoshld) +"';'; END END ELSE BEGIN // NO PASA POR TIMESLICE Insert_historial (RS, unCookieManager, unServerVars, AdoConnlnsert, unAkadata, unCookieRecord out, unParameterLucas, unCookieEnabled, unRndNumber , unShoshld, unldCampana, 7,savear); Response . Content := 'var shosh_null= "LIMITACION_PORJTIMESLICE" ; ' ; END; END; End; End; Except On E : EXCEPCION DO //SI OCURRE CUALQUIER EXCEPCIÓN EN EL SISTEMA INESPERADO // SE MANDA EL MENSAJE DE ERROR. PARA NO GENERAR EL ERROR=500. // VER LA REALIZACIÓN DEL TRAPEO DE ERROR SOBRE LA CONEXIÓN // SI CONECTADO ENTONCES NADA // SI DESCONECTADO CONECTARSE RESPONSE. CONTENT := 'var shosh_null=,ERROR_DE_SISTEMA_' +TRIM (E . Message ) +' "; ' End; End;

Claims (16)

REIVINDICACIONES

1. Un método para modificar una imagen producida por un programa de aplicación en el monitor de una computadora, el sistema de computación que ejecuta el programa de aplicación bajo un sistema operativo con una interfase gráfica de usuario, el método que comprende los pasos mediante los que se introduce en la pantalla un objeto animado de multimedia, donde tal objeto es una imagen cambiante que irrumpe en forma intrusiva en la pantalla de manera impredecible para el usuario de la computadora y que está completamente fuera del control de éste, y es producido por un código ejecutable provisto al sistema de computación, el cual es determinado por otros códigos ejecutables que estuvieran disponibles en dicho sistema.

2. El método según la reivindicación 1, por el cual tal objeto se mueve por traslación en la pantalla de una computadora .

3. El método de acuerdo con cualquiera de las reivindicaciones precedentes, empleado en un sistema operativo que produce imágenes en ventanas de capas múltiples en la pantalla, y donde el objeto o figura se ubica en la capa más alta de la ventana del programa de aplicación, de modo que el usuario no pueda eliminarlo de la pantalla o cubrirlo con otros objetos.

4. El método de acuerdo con cualquiera de las reivindicaciones precedentes, donde el objeto o figura es acompañado por sonido sincronizado.

5. El método de acuerdo con cualquiera de las reivindicaciones precedentes, donde el objeto o figura recubre una imagen existente producida por el programa de aplicación en la pantalla, siendo transparente una porción del mismo, de modo tal que se pueda ver una porción de la imagen existente.

6. El método de acuerdo con cualquiera de las reivindicaciones precedentes, donde la creación de dicho objeto o figura es controlada por señales almacenadas en una base de datos en respuesta a un intercambio de información desde la computadora del usuario.

7. El método según la reivindicación 6, donde dichas señales almacenadas en la base de datos definen múltiples objetos que se seleccionan y controlan en base a la información obtenida de la computadora del usuario, que está fuera de su control y características técnicas disponibles en la misma.

8. El método de la reivindicación 6 o 7, donde la computadora del usuario está conectada a una red a la cual también está conectado un servidor de control de objetos (character contolling server), en comunicación con la computadora del usuario, y donde el servidor tiene acceso a la base de datos. Dicho método comprende además los pasos para producir una serie de instrucciones ejecutadas en el servidor a través de un proceso interactivo entre la computadora del usuario y el servidor, para determinar una secuencia de comandos que selecciona señales de control correspondientes a uno de los objetos de dicha base de datos, y envía los comandos a la computadora del usuario para ser utilizados en la introducción del objeto en la imagen del programa de aplicación.

9. El método de la reivindicación 8, en que el programa de aplicación es un navegador y los comandos se proveen a la computadora del usuario dentro de una página HTML visitada por el usuario.

10. El método de la reivindicación 9 en que la página HTML visitada por el usuario fue recibida desde el servidor de un proveedor de contenido y el objeto es introducido allí a través de etiquetas que el proveedor de contenido dejó en la página.

11. El método de la reivindicación 1, en el cual el código ejecutable para el objeto o figura es incorporado a uno de los medios de instalación y en un archivo de instalación para el programa de aplicación, y donde tal código ejecutable se instala al miso tiempo que el programa de aplicación.

12. Un método para introducir material publicitario en el contenido multimedia que está siendo visto por el usuario a través de una red de computadoras en la cual la computadora del usuario es un cliente que ejecuta un programa de aplicación bajo un sistema operativo con interfase gráfica del usuario, donde el contenido es recibido de un proveedor de contenido, y donde también se encuentra conectada a la red una computadora operada por una fuente de medios que actúa como servidor de control de objetos (character controlling server). Este método comprende los siguientes pasos: enviar el contenido desde el servidor de contenido al cliente e incluir en él una etiqueta que se comunica con el servidor de control de objetos; y - en el servidor de control de objetos, al ser contactado por el cliente, transferir al cliente aquellas señales de control que produzcan en el monitor del usuario la exhibición del contenido de un objeto animado de multimedia, siendo tal objeto una imagen cambiante que irrumpe en el contenido en forma imprevista e impredecible para la computadora del usuario y completamente fuera del control de éste; asimismo, las señales de control son determinadas por todo código ejecutable que estuviera disponible en la computadora del usuario.

13. El método de la reivindicación 12, donde la fuente de medios recibe un pago en base a la cantidad de accesos al objeto y su duración.

14. El método según la reivindicación 12 o 13, donde dicho objeto se mueve por traslación en la pantalla de la computadora.

15. El método según cualquiera de las reivindicaciones 12-14, utilizado en un sistema operativo que produce imágenes en ventanas de capas múltiples en la pantalla, donde el objeto se ubica en la capa más alta de la ventana del programa de aplicación, de modo que el usuario no pueda eliminarlo de la pantalla o cubrirlo con otros objetos.

16. El método según cualquiera de las reivindicaciones 12-15, donde le objeto está acompañado por sonido sincronizado. 1 . El método de acuerdo con cualquiera de las reivindicaciones 12-16, donde el objeto recubre una imagen existente producida en la pantalla por el programa de aplicación, siendo transparente una porción del mismo, de modo tal que se pueda ver una porción de la imagen existente. 18. El método de acuerdo con cualquiera de las reivindicaciones 12-17, donde dichas señales de control se generan en base a información almacenada en una base de datos en respuesta a un intercambio de información desde la computadora del usuario. 19. El método de acuerdo con cualquiera de las reivindicaciones 12-18, donde las señales almacenadas en la base de datos definen una variedad de tales objetos, que son seleccionados y controlados en base a información obtenido de la computadora del usuario, que está fuera de su control y características técnicas disponibles en la computadora del usuario . 20. El método según las reivindicaciones 7 o 19, donde la información obtenida de la computadora del usuario se deriva de una cookie almacenada en la computadora. 21. Un método para proveer un saludo electrónico de un remitente a un destinatario a través de una red en la cual las computadoras de ambos son clientes que ejecutan un programa de aplicación bajo un sistema operativo con inferíase gráfica del usuario, donde el saludo es producido por una computadora de una fuente de medios que funciona como un servidor de medios que actúa como un servidor de control de objeto, habiendo además otra computadora conectada a la red, operada por un proveedor de contenido. Este método comprende los siguientes pasos: - desde la computadora del remitente, seleccionar las características del saludo, incluir un objeto para presentar el saludo, indicar el destinatario y el mensaje a enviar; - en el servidor de control de objetos, al ser contactado por el remitente, enviar al control del destinatario señales de control que producirán en la computadora del mismo un objeto animado de multimedia que entrega el mensaje, siendo tal objeto una imagen cambiante que irrumpe en el contenido en forma intrusa e impredecible para el destinatario y está completamente fuera del control de éste; las señales de control son determinadas por todo código ejecutable que estuviera disponible en la computadora del usuario; el servidor también envía una señal al destinatario que llamará a una página proporcionada por el proveedor de contenido, la cual actuará como fondo para el objeto y permanecerá una vez expresado el mensaje. 22. El método de la reivindicación 21, en que la fuente de medios recibe un pago del proveedor del contenido en base a la cantidad de veces que la página del proveedor de contenido es entregada como fondo de un saludo. 23. Un sistema para modificar una imagen producida por un programa de aplicación en la pantalla de una computadora, la computadora que ejecuta el programa de aplicación bajo un sistema operativo con una interfase gráfica de usuario, que comprende: - un generador de señales de medios configurados para producir en el monitor del usuario del programa de aplicación, un objeto animado de multimedia, siendo los contenidos de las señales de medios determinados por los códigos ejecutables disponibles en la computadora del usuario, y siendo tal objeto una imagen cambiante que irrumpe en la pantalla de manera intrusa e impredecible para el usuario de la computadora y que está completamente fuera del control de éste; y - medos para introducir el objeto o figura en el monitor de la computadora del usuario. 24. El sistema según la reivindicación 23, por el cual dichas señales de medios se configuran para producir un objeto o figura que se mueve por traslación en la pantalla de la computadora. 25. El sistema de cualquiera de las reivindicaciones 23 o 24, donde el sistema operativo produce imágenes en ventanas de capas múltiples en la pantalla, donde las señales de medios están configuradas para ubicar el objeto o figura en la capa más alta de la ventana del programa de aplicación, de modo que el usuario no pueda eliminarlo de la pantalla o cubrirlo con otros objetos. 26. El sistema de acuerdo con cualquiera de las reivindicaciones 23-25, donde dichas señales de medios se configuran de tal modo que el objeto o figura es acompañado por sonido sincronizado. 27. El sistema de acuerdo con cualquiera de las reivindicaciones 23-26, donde la señal de medios está configurada de tal modo que el objeto recubre una imagen existente producida en la pantalla por el programa de aplicación, y una porción del objeto es transparente, de modo tal que se pueda ver a través de dicho objeto una porción de la imagen existente. 28. El sistema de acuerdo con cualquiera de las reivindicaciones 23-27, donde la señal de medios se generará en base a información almacenada en una base de datos en respuesta a un intercambio de información desde la computadora del usuario. 29. El sistema según la reivindicación 28, donde la información almacenada en la base de datos define múltiples objetos, y que también comprende un selector que responde a la información de la computadora del usuario que está fuera del control de éste y a las características técnicas disponibles en la computadora del usuario, para seleccionar señales de medios correspondientes a uno de los objetos. 30. El sistema de la reivindicación 28 o 29, que comprende además una red, a la cual también está conectado un servidor de control de objetos en comunicación con la computadora del usuario, donde el servidor tiene acceso a la base de datos y donde el generador de señales de medios está controlado mediante un proceso de comunicación interactiva entre la computadora del usuario y el servidor. 31. El sistema de la reivindicación 30, en que el programa de aplicación es un navegador y las señales de medios se proveen a la computadora del usuario junto con una página HTNL que está siendo procesada por el usuario. 32. El sistema de la reivindicación 31 que comprende además un servidor del proveedor de contenido conectado a la red para comunicarse con la computadora del usuario, donde la página HTML visitada por el usuario es recibida del servidor de un proveedor de contenido y el objeto es introducido allí a través de etiquetas que el proveedor de contenido deja en la página. 33. El sistema de la reivindicación 1, en el cual el generador comprende un programa de computación que es instalado en la computadora del usuario al mismo tiempo que el programa de aplicación desde los medios de instalación o un archivo de instalación para el programa de aplicación. 34. El método de cualquiera de las reivindicaciones 1 a 11, en que el código ejecutable provisto al sistema de computación incluye una combinación de tecnologías que simulan la operación de Internet Explorer 4 (y superiores) con Flash 4 (y superiores) , al menos en la medido en que se logre la sincronización de sonido y video, y la libertad de movimiento del objeto o figura y la habilidad de darle cualquier forma al mismo. 35. El método de la reivindicación 34, donde la combinación de tecnologías incluya alguna de las siguientes: Windows IE v. 4.0 o superior con Flash v. 4.0 o superior Windows IE v. 4.0 o superior sin Flash Windows Netscape v. 4.1 o superior sin Flash Macintosh Netscape v. 4.0 o superior sin Flash Windows Netscape v. 4.1 o superior con Flash v. 4.0 o superior Macintosh Netscape v. 4.0 o superior con Flash v. 4.0 o superior Windows Netscape v. 6.0 o superior con Flash v. 4.0 o superior Macintosh Netscape v. 6.0 o superior con Flash v. 4.0 o superior Macintosh IE v. 5.0 o superior con Flash v. 4.0 o superior 36. El método de cualquiera de las reivindicaciones 12 a 22, donde las señales de control incluyan una combinación de tecnologías que simulen la Operación de Internet Explorer 4 (y superiores) con Flash 4 (y superiores), al menos en la medida que se logre la sincronización de sonido y video, y la libertad de movimiento del objeto o figura y la habilidad de darle cualquier forma al mismo. 37. El método de la reivindicación 36, donde la combinación de tecnologías incluye una de las siguientes: Windows IE v. 4.0 o superior con Flash v. 4.0 o superior Windows IE v. 4.0 o superior sin Flash Windows Netscape v. 4.1 o más nueva sin Flash Macintosh Netscape v. 4.0 o más actual sin Flash Windows Netscape v. 4.1 o más actual con Flash v. 4.0 o más actual Macintosh Netscape v. 4.0 o más actual con Flash v. 4.0 o más actual Windows Netscape v. 6.0 o más actual con Flash v. 4.0 o más actual Macintosh Netscape v. 6.0 o más actual con Flash v. 4.0 o más actual Macintosh IE v. 5.0 o más actual con Flash v. 4.0 o más actual 38. El sistema de cualquiera de las reivindicaciones 23 a 33, donde el código ejecutable incluye una combinación de tecnologías que simula la Operación de Internet Explorer 4 (y superiores) con Flash 4 (y superiores), al menos en la medida que se logra la sincronización de sonido y video, y la libertad de movimiento del objeto o figura y la habilidad de darle cualquier forma al mismo. 39. El sistema de la reivindicación 38, donde la combinación de tecnologías incluye una de las siguientes: Windows IE v. 4.0 o superior con Flash v. 4.0 o superior Windows IE v. 4.0 o superior sin Flash Windows Netscape v. 4.1 o superior sin Flash Macintosh Netscape v. 4.0 o superior sin Flash Windows Netscape v. 4.1 o superior con Flash v. 4.0 o superior Macintosh Netscape v. 4.0 o superior con Flash v. 4.0 o superior Windows Netscape v. 6.0 o superior con Flash v. 4.0 o superior Macintosh Netscape v. 6.0 o superior con Flash v. 4.0 o superior Macintosh IE v. 5.0 o superior con Flash v. 4.0 o superior