MX2014002956A - Mercado digial para la distribucion a tiempo de datos de evento. - Google Patents

Abstract

Se describe el suministro de datos. Un método incluye determinar un valor monetario relativo de datos, con respecto al tiempo, en un punto en el tiempo particular. El método además incluye, basándose en el valor monetario determinado, proporcionar los datos a un grupo de datos de uno o más dispositivos de consumidor de usuario final correlacionados con el valor monetario.

Description

MERCADO DIGITAL PARA LA DISTRIBUCION A TIEMPO DE DATOS DE EVENTO ANTECEDENTES Antecedentes y Técnica Relacionada Las computadoras y sistemas de cómputo han afectado casi a cada aspecto de la vida moderna. Las computadoras generalmente están involucradas en el trabajo, recreación, cuidado de la salud, transporte, entretenimiento, manejo del hogar, etc.

Además, la funcionalidad de sistema de cómputo puede ser mejorada a través de una habilidad de sistema de cómputo que se interconectará a otros sistemas de cómputo a través de conexiones de red. Las conexiones de red pueden incluir, pero no se limitan a, conexiones a través de Ethernet mediante cable o inalámbrico, conexiones celulares, o aún conexiones de computadora a computadora mediante conexiones en serie, paralelas, USB, u otras conexiones. Las conexiones permiten a un sistema de cómputo tener acceso a servicios en otros sistemas de cómputo y recibir rápida y eficientemente datos de aplicación de otro sistema de cómputo.

Muchas computadoras están destinadas a ser utilizadas por una interacción directa del usuario con la computadora. Como tales, las computadoras tienen interfases de usuario de hardware y software para facilitar la interacción de usuario. Por ejemplo, una computadora de propósito general moderna puede incluir un teclado, ratón, almohadilla táctil, cámara, etc., para permitir a un usuario introducir datos a la computadora. Además, pueden estar disponibles varias interfases de usuario de software.

Ejemplos de interfases de usuario de software incluye interfases de usuario gráficas, inferíase de usuario basada en línea de comando de texto, interfases de usuario de tecla de función de tecla caliente, y similares.

Las aplicaciones conectadas a Internet están proporcionando un valor de usuario final en aumento al nivelar e interrelacionar grupos de datos. Los proveedores de datos geográficos, por ejemplo, derivan y tienen, durante mucho tiempo, ingresos importantes derivados de la proporción de información exacta de mapas y navegación. Para aplicaciones, especialmente también en el espacio móvil, la profundidad de valor de usuario en su mayoría corresponde directamente a que tanto y que tan exactos son los datos en donde las aplicaciones pueden confiar. Por ejemplo, una aplicación de navegación se beneficiará enormemente para nivelar no solo datos geográficos, sino que también será capaz de introducir información sobre hoteles, restaurantes, y estaciones de gas, sobre supermercados y almacenes y sus horarios, información sobre tráfico, avisos de clima, y todo lo que pueda ser de interés para alguien que se esté moviendo. Ya que el acceso a datos estructurados se está volviendo enormemente importante para la competitividad de aplicación y profundidad de valor de usuario, existen oportunidades de mercado crecientes para proveedores, propietarios, y generadores de datos para revender datos que tienen para tales propósitos y existe una enorme oportunidad para los proveedores de infraestructura para proporcionar infraestructuras de mercado digital que permita a los proveedores vender y distribuir dichos datos.

Al mismo tiempo, los proveedores de datos en tiempo real o casi en tiempo real han derivado enormemente ingresos importantes de la provisión de acceso a datos "recientes o frescos" que son particularmente valiosos ya que representan un hecho observable actual o muy reciente. Los ejemplos son datos de mercado financiero, negocios actuales y noticias mundiales, o resultados deportivos. Los datos de precios de mercado financiero, por ejemplo, son los más valiosos dentro de algunos segundos o aún milisegundos del precio que ha sido establecido. Pierde casi todo su valor después de 15 minutos y luego vuelve a ganar algo de valor ya que se vuelven datos históricos utilizados para graficar y otros propósitos de análisis.

La materia objeto aquí reclamada no está limitada a modalidades que resuelvan cualquier desventaja o que operen solo en ambientes tales como aquellos descritos anteriormente. Más bien, estos antecedentes solo se proporcionan para mostrar un área de tecnología ilustrativa en donde pueden practicarse algunas modalidades aquí descritas.

BREVE DESCRIPCION DE LA INVENCION Una modalidad aquí descrita está dirigida a un método practicado en un sistema de cómputo. El método incluye actos para suministrar datos. El método incluye determinar una valor de datos monetario relativo, con respecto al tiempo, en un punto particular en el tiempo. El método además incluye, basándose en el valor monetario determinado, proporcionar los datos al grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario.

Otra modalidad aquí ¡lustrada está dirigida a un método practicado en un sistema de cómputo. El método incluye actos para suministrar datos. El método incluye determinar una fila de consumidor para consumidores de datos. El método además incluye datos viejos antes de proporcionar los datos a los dispositivos de usuario final correlacionados con la fila de consumidor para coincidir con la fila de consumidor.

Esta Breve Descripción se proporciona para introducir una selección de conceptos en una forma simplificada que además se describe más adelante en la Descripción Detallada. Esta Breve Descripción no pretende identificar características calve o características esenciales de la materia objeto reclamada, ni pretende ser utilizada como un auxiliar para determinar el alcance de la materia objeto reclamada.

Características y ventajas adicionales se establecerán en la descripción que sigue, y en parte serán obvias a partir de la descripción, o se pueden aprender a través de la práctica de las enseñanzas de la presente. Las características y ventajas de la invención pueden ser realizadas y obtenidas a través de los instrumentos y combinaciones particularmente señaladas en las reivindicaciones anexas. Las características de la presente invención serán más completamente evidentes a partir de la siguiente descripción y reivindicaciones anexas, o pueden ser aprendidas a través de la práctica de la invención como se establece aquí más adelante.

BREVE DECRIPCION DE LOS DIBUJOS Con el fin de describir la manera en la cual las ventajas y características antes citadas y otras más pueden ser obtenidas, una descripción más particular de la materia objeto, brevemente descrita antes, será presentada con referencia a modalidades específicas, las cuales se ilustran en los dibujos anexos. Entendiendo que estos dibujos solo muestran modalidades típicas y, por lo tanto, no se consideran como limitantes del alcance, se describirán y explicarán modalidades con especificidad adicional y detalle a través del uso de los dibujos anexos en donde: La Figura 1 muestra una gráfica del valor de datos con el tiempo; La Figura 2 muestra un ambiente de marcado digital de datos de evento; La Figura 3 muestra una representación alterna de un ambiente de mercado digital de datos de evento; La Figura 4 muestra una representación alterna de un ambiente de mercado digital de datos de evento; La Figura 5 muestra una representación alterna de un ambiente de mercado digital de datos de evento; La Figura 6 muestra un sistema de adquisición y distribución de datos de evento; La Figura 7 muestra un ejemplo de un sistema de adquisición de datos de evento; La Figura 8 muestra un ejemplo de un sistema de distribución de datos de evento; La Figura 9 muestra un sistema de adquisición y distribución de datos de evento; La Figura 10 muestra un método para suministrar datos; y La Figura 11 muestra otro método para suministrar datos.

DESCRIPCION DETALLADA Algunos datos pueden derivar valor basándose en, y como resultado de su "frescura". Por ejemplo, los datos financieros, tales como, cotizaciones de acciones, pueden tener un valor que cae muy rápidamente a medida que el tiempo progresa. Al mismo tiempo, si los datos pueden ser provistos muy rápidamente, tal como en pocos milisegundos, los datos pueden tener un valor muy alto. De esta manera, los datos frescos pueden estar en alta demanda y pueden ser provistos en una forma similar a cómo los datos disponibles de depósitos de datos consultables y/o mercados digitales de datos proporcionan datos.

Algunas modalidades aquí descritas pueden implementar un mercado digital para datos de evento. Algunas modalidades pueden proporcionar una plataforma y sistema de mercada digital de distribución de datos para datos en tiempo real. Algunas modalidades pueden incluir un sistema de suministro de evento de difusión múltiple eficiente con el fin de reducir el tiempo de suministro y mantener los datos más valiosos al proporcionarlos en un estado fresco. Algunas modalidades pueden permitir un suministro en sistemas de notificación de empuje. Algunas modalidades pueden incluir mecanismos para la recolección de datos de rastreo de estadística y distribución para escenarios de facturación y/o facturación a nombre de. Además, algunas modalidades pueden incluir nivelación de acuerdo de nivel de servicio de suministro (SLA).

La Figura 1 muestra una gráfica 100 que ilustra el valor de datos con el tiempo. Como se muestra, cuando se crean primero datos en tiempo real describiendo un hecho presente, los datos pueden tener un valor importante. El valor cae rápidamente con el tiempo a un punto en donde los datos están en o cerca de cero. Los datos luego vuelven a ganar algo de valor con el tiempo ya que tienen un valor como un hecho histórico que puede se logrado y buscado posteriormente. De esta forma, existe un valor que es capaz de proporcionar datos actuales a usuarios finales tan rápido como sea posible.

Una forma de proporcionar rápidamente datos es través de un sistema de notificación de evento, y en particular, utilizando un sistema de notificación de evento eficiente como se describe con mayor detalle a continuación. De esta forma, los datos pueden ser provistos a los usuarios tan rápidamente ya que el sistema de notificación de evento es capaz de obtener los datos para los usuarios finales. Así, si un usuario puede ser instantáneamente notificado y provisto con datos presentes, el valor de los datos puede ser mantenido. Esto además podría permitir la habilidad de recuperar una compensación superior (ya sea de un proveedor de datos o de un consumidor de datos) para proporcionar los datos.

La Figura 2 muestra un ejemplo de un mercado digital de datos 202 que puede utilizar un sistema de distribución de evento para proporcionar datos. La Figura 2 muestra que un proveedor de datos 204 puede proporcionar datos a un mercado digital de datos de evento 202. El proveedor de datos 204 puede ser cualquiera de un número de diferentes fuentes, tales como, pero no limitado a, proveedores de datos financieros, proveedores de datos de información deportiva, proveedores de información de noticias, etc. El mercado digital de datos de evento 202 puede ser un corredor de datos que recibe datos de un número de diferentes fuentes y distribuye los datos a consumidores finales (mostrados como receptores 206).

La Figura 2 muestra tres grupos de receptores, incluyendo suscriptores individuales a datos, suscriptores de grupo a datos, y suscriptores quienes reciben información como resultado de tener una aplicación o solución particular desplegada en un dispositivo de usuario final. Otros grupos de suscriptor, aunque no mostrados específicamente, además o alternativamente pueden ser implementados.

La compensación para el suministro de datos puede ser estructurada en un número de diferentes formas. Las Figuras 3 y 4 muestran dos ejemplos de cómo se puede lograr la monetización del suministro de datos.

En un primer ejemplo mostrado en la Figura 3, el suministro de datos es facturado a un proveedor de datos 204. El mercado digital de datos de evento 202 puede proporcionar estadísticas 208 con respecto al suministro de datos al proveedor de datos 204, y el proveedor de datos 204 puede facturar a los receptores 206 de los datos, independientemente.

En un segundo ejemplo mostrado en la Figura 4, el mercado digital de datos 202 puede facturar a los receptores 206 directamente. El mercado digital de datos 202 entonces puede hacer su compartición, y pasar cualquier fondo adicional al proveedor de datos.

Con referencia ahora a la Figura 5, como se observó previamente, los datos pueden ser más valiosos entre más rápidamente puedan ser suministrados. De esta manera, algunas modalidades pueden proporcionar datos basándose en una cantidad pagada por un suscriptor (tal como un receptor) o un proveedor de datos 204. Por ejemplo, los suscriptores que pagan más dinero por datos pueden tener sus datos suministrados utilizando una infraestructura diseñada u optimizada para suministrar datos a una velocidad más rápida que alguna otra infraestructura utilizada para suministrar datos a suscriptores quienes pagan menos dinero por sus datos. Esto puede incluir utilizar componentes de infraestructura (tal como servidores) que estén más cerca de los suscriptores para permitir que los datos sean suministrados más rápido.

Alternativamente o además, los datos puede ser movidos en el proveedor de datos 204, en donde el movimiento permite a los datos ser suministrados con un retraso variable. Por ejemplo, los suscriptores premium pueden ser capaces de recibir datos en tiempo real con poco o ningún retraso a partir de cuando los datos son generados a cuando los datos son suministrados, mientras los datos pueden ser intencionalmente retrasados para otros suscriptores, en donde en retraso depende de un nivel de servicio al que el suscriptor se ha suscrito. Por ejemplo, en algunas modalidades, los proveedores de datos pueden ofrecer un número limitado de acuerdos de servicio premium garantizando el suministro de datos en tiempo real en una cantidad de tiempo muy corta. Por la naturaleza de la exclusividad y escasez de estos acuerdos, el proveedor de datos puede potencialmente cargar un gran premium de estos acuerdos. Un segundo nivel de acuerdos limitados puede ser proporcionado para un premium inferior. Los datos en tiempo real pueden ser retrasados a partir de qué suscriptores del servicio premium son provistos. Se pueden proporcionar varios niveles, incluyendo niveles para proporcionar los datos para libertad después de un retraso introducido suficientemente largo.

Lo siguiente ahora muestra un ejemplo de un sistema de evento particularmente eficiente para proporcionar datos de evento en tiempo real.

Dicho ejemplo se muestra en la Figura 6. La Figura 6 muestra un ejemplo en donde la información de un gran número de diferentes fuentes es suministrada a un gran número de diferentes objetivos. En algunos ejemplos, la información de una fuente individual, o la información agregada de múltiples fuentes, puede ser utilizada para crear un evento individual que es suministrado a un gran número de los objetivos. Esto se puede lograr, en algunas modalidades, utilizando una topología de conductores de salida como se ¡lustra en la Figura 6.

La Figura 6 muestra fuentes 116. Como se discutirá aquí más adelante, las modalidades pueden utilizar particiones de adquisición 140. Cada una de las particiones de adquisición 140 puede incluir un número de fuentes 116. Puede haber un número potencialmente grande y una diversidad de fuentes 116. Las fuentes 116 proporcionan información. Dicha información puede incluir, por ejemplo, pero no se lilita a, correo electrónico, mensajes de texto, cotizaciones de acciones en tiempo real, marcadores deportivos en tiempo real, actualizaciones de noticias, etc.

La Figura 6 muestra que cada partición incluye un procesador de adquisición, tal como el procesador de adquisición 118 ilustrativo. El procesador de adquisición 118 recolecta información de las fuentes 116, y basándose en la información, genera eventos. En el ejemplo mostrado en la Figura 6, se ilustra un número de eventos siendo generados por procesadores de adquisición utilizando varias fuentes. Para ilustración se utiliza un evento 104-1. En algunas modalidades, el evento 104.1 puede ser normalizado como se explica más aquí. El procesador de adquisición 118 puede ser un servicio en una red, tal como Internet, que recolecta información de fuentes 116 en la red.

La Figura 6 muestra que el evento 104-1 es enviado a un tema de distribución 144. El tema de distribución 144 despliega los eventos a un número de particiones de distribución. La partición de distribución 120-1 se utiliza como un análogo para todas las particiones de distribución. Las particiones de distribución cada una sirven a un número de usuarios finales o dispositivos representados por suscripciones. El número de suscripciones que son servidas por una partición de distribución puede variar de aquel de otras particiones de distribución. En algunas modalidades, el número de suscripciones que son servidas por una partición puede ser dependiente de la capacidad de la partición de distribución.

Alternativamente o además, una partición de distribución puede ser seleccionada para dar servicio a usuarios basándose en proximidad lógica o geográfica a los usuarios finales. Esto puede permitir que se envíen alertas a los usuarios finales en una forma más precisa.

En el ejemplo mostrado, la partición de distribución 120-1 incluye un procesador de distribución 122-1. El procesador de distribución 122-1 consulta una base de datos 124-1. La base de datos 124-1 incluye información sobre subscripciones con detalles sobre los objetivos de suministro asociados 102. En particular, la base de datos puede incluir información tal como información que describe plataformas para los objetivos 102, aplicaciones utilizadas por los objetivos 102, direcciones de red para los objetivos 102, preferencias de usuarios finales que utilizan los objetivos 102, etc. Al utilizar la información en la base de datos 124-1, el procesador de base de datos 124-1, el procesador de distribución 122-1 construye una agrupación 126-1, en donde la agrupación 126-1 incluye el evento 104 (o al menos información del evento 104) y un talón de remesa 128-1 identificando una pluralidad de objetivos 102 de entre los objetivos 102 a los cuales la información del evento 104-1 será enviada como una notificación. La agrupación 126-1 entonces es colocada en una cola 130-1.

La partición de distribución 120-1 puede incluir un número de procesadores de suministro. Los procesadores de suministro retiran de la cola las agrupaciones de la cola 103-1 y suministra notificaciones a los objetivos 102. Por ejemplo, un procesador de suministro 108-1 puede tomar la agrupación 126-1 de la cola 13-1 y enviar al evento 104 información a los objetivos 102 identificados en el talón de remesa 128-1. De esta manera, las notificaciones 134, incluyendo el evento 104-1, e información pueden ser enviadas de las varias particiones de distribución a los objetivos 102 en un número de diferentes formatos apropiados para los diferentes objetivos 102 y específicos a objetivos individuales 102. Esto permite que notificaciones individualizadas 134, individualizadas para objetivos individuales 102, sean creadas de un evento común 104-1 en el borde de un sistema de suministro en lugar de llevar grandes números de notificaciones individuales a través del sistema de suministro.

Lo siguiente muestra descripciones alternativas de colección de información y sistemas de distribución de evento que pueden ser utilizados en algunas modalidades.

Como una base, un sistema de la modalidad está utilizando una infraestructura de publicar/suscribir según provista por Windows Azure Service Bus disponible de Microsoft Corporation de Redmond Washington, pero que también existe en forma similar en varios otros sistemas de mensajería. La infraestructura proporciona dos capacidades que facilitan la implementación descrita del método presentado: Temas y Colas.

Una Cola es una estructura de almacenamiento para mensajes que permite que se agreguen mensajes (se formen en una cola) en orden secuencial y sean removidos (se quiten de la cola) en el mismo orden como fueron agregados. Los mensajes pueden ser agregados y removidos a través de cualquier número de clientes concurrentes, permitiendo la nivelación de carga en el lado de entrada de la cola y equilibrando la carga de procesamiento a través de receptores en el lado de salida de la cola. La cola también permite que entidades obtengan un bloqueo en un mensaje a medida que sale de la cola, permitiendo que el cliente consumidor tenga un control explícito sobre cuando el mensaje es en realidad eliminado de la cola o si puede ser restaurado en la cola en caso del procesamiento de las fallas de mensaje recuperado.

Un Tema es una estructura de almacenamiento que tiene todas las características de una Cola, pero permite múltiples "suscripciones", actualmente existentes, las cuales cada una permite una vista aislada, filtrada sobre la secuencia de mensajes dentro de la cola. Cada suscripción en un Tema produce una copia de cada mensaje dentro de la cola siempre que la condición(es) de filtro asociada con la suscripción positivamente coincida con el mensaje. Como resultado, un mensaje dentro de la cola en un Tema con 10 suscripciones, en donde cada suscripción tiene una condición de "pasaje" simple que coincide con todos los mensajes, producirá un total de 10 mensajes, uno para cada suscripción. Una suscripción puede, como una Cola, tener múltiples consumidores concurrentes proporcionando equilibrio de procesamiento de carga a través de receptores.

Otro concepto base es aquel del "evento", el cual es, en términos de la infraestructura de publicar/suscribir subyacente justo un mensaje. En el contexto de una modalidad, el evento es sometido a un grupo de restricciones simples que gobiernan el uso del cuerpo de mensaje y propiedades de mensaje. El cuerpo de mensaje de un evento generalmente fluye como un bloque de datos opacos y cualesquiera datos de evento considerados por una modalidad generalmente fluyen en propiedades de mensaje, el cual es un grupo de pares de clave/valor que es parte del mensaje que representa el evento.

Haciendo referencia ahora a la Figura 7, un objetivo de arquitectura de la modalidad es adquirir datos de evento de una amplia variedad de diferentes fuentes 116 a gran escala y enviar estos eventos a una infraestructura de publicar/suscribir para procesamiento adicional. El procesamiento puede incluir alguna forma de análisis, búsqueda en tiempo real, o redistribución de eventos a suscriptores interesados a través de mecanismos de notificación de tracción o empuje.

Una arquitectura de modalidad define un procesador de adquisición 118, un modelo para adaptadores de adquisición y normalización de evento, un almacenamiento dividido 138 para mantener metadatos sobre fuentes de adquisición 116, un modelo común de división y programación, y un modelo para cómo hacer fluir cambios iniciados por el usuario del estado de las fuentes de adquisición 116 en el sistema en un tiempo de ejecución y sin requerir de búsquedas adicionales de bases de datos.

En una implementación concreta, la adquisición puede soportar adaptadores de adquisición concreta para eventos de fuente de una amplia variedad de servicios en red públicos y privados, incluyendo alimentaciones RSS, Atom, y OData, buzones de correo electrónico incluyendo, pero no limitándose a tales que soportan los protocolos IMAP y POP3, fuentes de información de de social 116 como líneas de tiempo de Twitter o muros de Facebook, y suscripciones en infraestructuras externas de publicar/suscribir como Windows Azure Service Bus o Simple Queue Service de Amazon.

Normalización de Evento Los datos de evento son normalizados para hacer eventos prácticamente consumibles por los suscriptores en una infraestructura de publicar/suscribir que están manejando. Normalización significa, en este contexto, que los eventos son trazados en un modelo de evento común con una representación consistente de artículos de información que pueden ser de interés a un amplio grupo de suscriptores en una variedad de contextos. El modelo seleccionado aquí es una simple representación de un evento en la forma de una lista plana de pares de clave/valor que puede estar acompañada por un pedazo individual, opaco, binario de datos no interpretados más por el sistema. Esta representación de un evento es fácilmente representable en muchas infraestructuras de publicar/suscribir y también traza de forma muy limpia protocolos Internet comunes tales como HTTP.

Para ¡lustrar la normalización de evento, considerar el trazo de una entrada de alimentación RSS o Atom en un evento 104 (ver Figuras 1 y 2). RSS y Atom son dos estándares de Internet que son muy ampliamente utilizados para publicar noticias u otra información actual, por lo regular en un orden cronológico, y que ayuda a hacer que esta información esté disponible para procesamiento en programas de computadora en una forma estructurada. RSS y Atom comparten una estructura muy similar y un grupo de elementos de datos con diferentes nombres pero semánticamente idénticos. Por lo que un primer paso de normalización es definir nombres comunes como claves para dichos elementos semánticamente idénticos que se definen en ambos estándares, como un título o una sinopsis. En segundo lugar, los datos que solo ocurren en uno, pero no en el otro estándar, son usualmente trazados con el nombre 'nativo' respectivo. Más allá de esto, estos tipos de alimentaciones por lo general llevan 'extensiones', las cuales son artículos de datos que no están definidos en el estándar de núcleo, pero están utilizando instalaciones de extensibilidad en los estándares respectivos para agregar datos adicionales.

Algunas de estas extensiones, incluyendo, pero no limitándose a, GeoRSS, para la geo-localización u OData para embeber datos estructurados en alimentaciones Atom son trazadas en una forma común que es compartida a través de diferentes fuentes de evento 116, de manera que el suscriptor en la infraestructura de publicar/suscribir en donde los eventos son emitidos puede interceptar la información de geo-localización en una manera uniforme de si los datos han sido adquiridos de RSS o Atom o una línea de tiempo de Twitter. Continuando con el ejemplo de GeoRSS, una simple expresión de GeoRSS que representa un 'punto' de geografía de esta manera puede ser trazada a un par de propiedades numéricas de 'Latitud'/'Longitud' que representa las coordenadas WGS84.

Las extensiones que llevan datos estructurados, complejos, tales como OData pueden implementar un modelo de trazo que conserva la estructura de tipo complejo y datos sin complicar el modelo de evento base. Algunas modalidades normalizan a una representación de datos canónicos y compactos complejos como JSON y trazan una propiedad de datos complejos, por ejemplo, una propiedad de OData 'Residente' de un tipo de datos complejos 'Persona' a un par de clave/valor, en donde la clave es el nombre de propiedad 'Residente' y el valor es los datos complejos que describen la persona con nombre, información biográfica, e información de dirección representada en una forma en serie JSON. Si la fuente de datos es un documento XML como es el caso de RSS Atom, el valor puede ser creado al transcribir los datos XML a JSON conservando la estructura provista por XML, pero colocando las particularidades como atributos y elemento, significando que tanto los atributos como los elementos XML que son subordinados del mismo nodo de elemento XML son trazados a las propiedades de JSON como 'hermanos' sin ninguna diferenciación.

Fuentes v División Una arquitectura de modalidad captura metadatos sobre fuentes de datos 116 en registros de 'descripción de fuente', los cuales pueden ser almacenados en la base de datos de fuente 138. Una descripción de fuente' puede tener un grupo de elementos comunes y un grupo de elementos específicos a una fuente de datos. Los elementos comunes pueden incluir el nombre de fuente, un período de tiempo durante el cual la fuente 116 se considera válida, una descripción legible por el humano, y el tipo de la fuente 116 para diferenciación. Los elementos específicos de fuente dependen del tipo de la fuente 116 y puede incluir una dirección de red, credenciales u otro material clave de seguridad para ganar acceso al recurso representado por la dirección, y metadatos que instruyen al adaptador de adquisición de fuente ya sea a realizar la adquisición de datos en una forma particular, como proveer un periodo de tiempo para verificar una alimentación de RSS, o para realizar el envío de eventos en una forma particular, tal como separar eventos adquiridos de una alimentación de noticias de eventos actuales durante al menos 60 segundos de manera que los receptores de notificación tienen la oportunidad de ver cada articulo de noticias en una superficie de pantalla restringida si esa es la experiencia de extremo a extremo que será construido.

Las descripciones de fuente son mantenidas en uno o más almacenamientos, tales como la base de datos de fuente 138. Las descripciones de fuente pueden ser divididas a través de y dentro de estos almacenamientos a lo largo de dos diferentes ejes.

El primer eje es una diferenciación por el residente de sistema. Los residentes de sistema o 'espacios de nombre' son un mecanismo para crear alcances aislados para entidades dentro de un sistema. Ilustrando un caso concreto, si "Fred" es un usuario de un sistema que implementa una modalidad, Fred será capaz de crear un alcance de residente, el cual le proporciona a Fred un ambiente aislado, virtual que puede mantener descripciones de fuente y configuración y estado completamente independiente de otras fuentes 116 en el sistema. Este eje puede servir como un factor de diferenciación para diseminar las descripciones de fuente a través de almacenamientos, específicamente también en casos en donde un residente requiere del aislamiento de los metadatos almacenados (que pueden incluir datos sensibles a seguridad tales como contraseñas), o por razones técnicas, reguladoras o de negocios. Un residente de sistema también puede representar afinidad a un centro de datos particular en donde los datos de descripción de fuente son mantenidos y de donde se va a realizar la adquisición de datos.

El segundo eje puede ser una diferenciación por un identif icador de partición numérico seleccionado de una escala de identificador predefinida. El identif icador de partición puede derivarse de invariantes contenidas en la descripción de fuente, tal como, por ejemplo, el nombre de fuente y el identificador de residente. El identificador de partición puede derivarse de estas invariantes utilizando una función hash (una de muchos candidatos es Jenkins hash, ver http://www.burtle. net/hash/doobs. html) y el valor hash resultante es calculado en la escala de identificador de partición, posiblemente utilizando una función de módulo a través del valor hash. La escala de identificador se selecciona más ser mayor (y puede ser substancialmente mayor) que el número más grande de particiones de almacenamiento que se espera que sean necesarias para almacenar todas las descripciones de fuente que serán siempre mantenidas en el sistema.

La introducción de particiones de almacenamiento es comúnmente motivada por límites de capacidad, los cuales tanto están inmediatamente relacionados con cuotas de capacidad de almacenamiento en el almacenamiento de datos subyacente como relacionados con límites de capacidad afectando al procesador de adquisición 118 tal como restricciones de ancho de banda para un centro de datos dado o sección de centro de datos, que pueden dar como resultado modalidades que crean particiones de adquisición 140 que están utilizando capacidad a través de diferentes centros de datos o segmentos de centro de datos para satisfacer el ingreso de necesidades de ancho de banda. Una partición de almacenamiento posee un subgrupo de la escala total de identificador y la asociación de un registro de descripción de fuente con una partición de almacenamiento (y los recursos necesarios para tener acceso) de esta forma puede ser directamente inferido de su identificador de partición.

Más allá de proporcionar un eje de división de almacenamiento, el identificador de partición también se utiliza para trabajos de programación o adquisición y claramente define la relación de propiedad de una partición de adquisición 140 a una descripción de fuente dada (la cual es potencialmente diferente de la relación con la partición de almacenamiento).

Particiones de Propiedad y Adquisición Cada descripción de fuente en el sistema puede ser poseída por una partición de adquisición específica 140. Se utiliza propiedad clara y única ya que el sistema no adquiere eventos de la misma fuente 116 exacta en múltiples lugares en paralelo ya que esto puede ocasionar que eventos por duplicado sean omitidos. Para hacer esto más concreto, una alimentación RSS definida dentro del alcance de un residente es poseída exactamente por una partición de adquisición 140 en el sistema y dentro de la partición hay una adquisición programada en la alimentación particular en cualquier punto en el tiempo dado.

Una partición de adquisición 140 obtiene la propiedad de una descripción de fuente a través de ganar la propiedad de una escala de identificador de partición. La escala de identificador puede ser asignada a la partición de adquisición 140 utilizando un sistema de división externo y especializado que puede tener capacidades de tolerancia a fallos y puede asignar propietarios maestros/respaldo, o utilizando un mecanismo más simple en donde la escala de identificador de partición es uniformemente diseminada a través del número de diferentes casos de cómputo asumiendo el papel de procesador de adquisición. En una implementación más sofisticada con un sistema de división externo, el propietario maestro seleccionado para una partición es responsable de sembrar la programación de trabajos si el sistema comienza a partir de un estado 'frío', que significa que la partición no tuvo un propietario previo. En el escenario más simple, el caso de cómputo que posee la partición posee el sembrado de la programación.

Programación Las necesidades de programación para trabajos de adquisición dependen de la naturaleza de la fuente concreta, pero en general existen dos tipos de modelos de adquisición que se realizan en algunas modalidades descritas.

En un primer modelo, el propietario inicia alguna forma de conexión o solicitud de red de larga ejecución en el servicio de red de la fuente y espera que los datos serán regresados en la conexión en la forma de datagramas o una corriente. En el caso de una solicitud de larga ejecución, comúnmente también denominada como consulta constante ("polling") larga, el servicio de red de fuente mantendrá la solicitud hasta que ocurre un tiempo expirado o hasta que los datos se hacen disponibles, a su vez, el adaptador de adquisición esperará a que la solicitud se complete con o sin un resultado de carga útil y después emitir de nuevo la solicitud. Como resultado este modelo de programación de adquisición tiene la forma de un bucle "hermético" que se inicia a medida que el propietario de la fuente 116 aprende sobre la fuente, y en donde la nueva solicitud o conexión es iniciada inmediatamente a medida que la conexión o solicitud actual se completa o temporalmente queda interrumpida. Ya que el propietario está en control inmediato del bucle hermético, el bucle puede ser fácilmente mantenido vivo mientras el propietario está ejecutando. Si el propietario se detiene y vuelve a empezar, el bucle también vuelve a empezar. Si la propiedad cambia, el bucle se detiene y el nuevo propietario empieza el bucle.

En un segundo modelo, el servicio de red de la fuente no soporta solicitudes de ejecución larga o conexiones que produzcan datos ya que se vuelven disponibles, pero son servicios regulares de solicitud/respuesta que regresan inmediatamente cada vez que se consultan. En tales servicios, y esto se aplica a muchos recursos web, la solicitud de datos en un bucle hermético continuo ocasiona una enorme cantidad de carga en la fuente 116 y también ocasiona un tráfico significativo de red que ya sea meramente indica que la fuente 116 no ha cambiado, o que, en el peor de los casos, lleve los mismos datos una y otra vez. Para equilibrar las necesidades de adquisición a tiempo de evento y no sobrecargar la fuente 116 con tráfico de consulta infructuoso, el procesador de adquisición 118, por lo tanto, ejecutará solicitudes en un bucle 'en tiempo', en donde las solicitudes en la fuente 116 son ejecutadas periódicamente basándose en un intervalo que equilibra aquellas consideraciones y también toma en cuenta indicaciones de la fuente 116. El bucle 'en tiempo' se inicia a medida que el propietario de la fuente 116 aprende sobre la fuente.

Existen dos variantes notorias de implementación para el bucle en tiempo. La primera variante es para escenarios de mejor esfuerzo, de baja escala y utiliza un local, en objetos de tiempo en memoria para programación, lo cual ocasiona las características de escala, control y reinicio que serán similares a aquellas de un bucle hermético. El bucle se inicia e inmediatamente programa una llamada de regreso de tiempo haciendo que se ejecute la primera iteración del trabajo de adquisición. A medida que ese trabajo se completa (aún con un error) y se determina que el bucle puede continuar la ejecución, otra llamada de regreso de tiempo se programa para el caso en donde el trabajo deba se ejecutado después.

La segunda variante utiliza "mensajes programados", la cual es una característica de varios sistemas de publicar/suscribir, incluyendo Windows Azure™ Service Bus. La variante proporciona una escala significativamente más alta de adquisición al costo de una complejidad un poco más alta. El bucle de programación se inicia por el propietario y se coloca un mensaje en la cola de programación de la partición de adquisición. El mensaje contiene la descripción de fuente. Subsecuentemente, se recoge por un trabajador que realiza el trabajo de adquisición y luego se forma en la cola el evento resultante en el sistema objetivo de publicar/suscribir. Finalmente, también se coloca en la cola un nuevo mensaje "programado" en la cola de programación. El mensaje es llamad "programado" ya que está marcado con un caso de tiempo en el cual se hizo disponible para recuperación por cualquier consumidor en la cola de programación.

En este modelo, una partición de adquisición 140 puede ser escalada pero teniendo un papel de "propietario" que principalmente siembra la programación y que puede emparejarse con cualquier número de papeles de "trabajador" que realizan los trabajos de adquisición reales.

Actualizaciones de Fuente A medida que el sistema está ejecutando, las particiones de adquisición 140 necesitan ser capaces de aprender sobre nuevas fuentes 116 para observar y sobre qué fuentes 116 ya no deben ser observadas. La decisión sobre esto típicamente yace en el usuario, excepto en el caso de poner en la lista negra una fuente 116 (como se describe más adelante) debido a un error no recuperable o temporal detectado, y es el resultado de una interacción con un servicio de manejo 142. Para comunicar dichos cambios, el sistema de adquisición mantiene un tema de "actualizar fuente" en la infraestructura de publicar/suscribir subyacente. Cada partición de adquisición 140 tiene una suscripción dedicada en el tema con la suscripción que tiene una condición de filtro que restringe los mensajes elegibles a aquellos que llevan un identificador de partición dentro de la escala perteneciente a la partición de adquisición. Esto permite que el servicio de manejo 142 establezca actualizaciones sobre fuentes 116 nuevas o retiradas y enviarlas a la partición correcta 140 sin requerir el reconocimiento de la distribución de propiedad de partición.

El servicio de manejo 142 presenta comandos de actualización al tema que contiene la descripción de fuente, el identificador de partición (para el propósito de filtración antes mencionado), y un identificador de operación que indica si la fuente 116 va a ser agregada o si la fuente 116 es removida del sistema.

Una vez que el propietario de partición de adquisición 140 ha recuperado un mensaje de comando, ya sea programará un nuevo bucle de adquisición para una nueva fuente 116 o interrumpirá y suspenderá o aún retirará el bucle de adquisición existente.

Lista Negra Las fuentes 116 para las cuales las fallas de la adquisición de datos pueden ser temporal o permanentemente colocadas en una lista negra. Una colocación en lista negra temporal se realiza cuando el recurso de red de la fuente 116 no está disponible o regresa un error que no está inmediatamente relacionado con la solicitud de adquisición emitida. La duración de una colocación en lista negra temporal depende de la naturaleza del error. La colocación en lista negra temporal se realiza al interrumpir el bucle de programación regular (hermética o en tiempo) y al programar la siguiente iteración del bucle (a través de una llamada de regreso o mensaje programado) durante un tiempo cuando se espera que la condición de error sea resuelta por la otra parte.

La colocación en la lista negra permanente se realiza cuando el error se determina como un resultado inmediato de la solicitud de adquisición, significando que la solicitud está ocasionando un error de autenticación o de autorización o la fuente remota 116 indica algún otro error de solicitud. Si un recurso es permanentemente colocado en la lista negra, la fuente 116 es marcada como estando en la lista negra en el almacenamiento de partición y el bucle de adquisición es inmediatamente abortado. La reintegración de una fuente 116 permanentemente en la lista negra requiera remover el marcador de lista negra en el almacenamiento, presumiblemente junto con cambios de configuración que ocasionan un cambio de comportamiento para la solicitud, y reiniciar el bucle de adquisición a través del tema de actualización de fuente.

Distribución de Notificación Las modalidades pueden ser configuradas para distribuir una copia de información de un evento de entrada dado para cada uno de un número de "objetivos 102" que están asociados con cierto alcance y hacer esto en un tiempo mínimo para cada objetivo 102. Un objetivo 102 puede incluir una dirección de un dispositivo o aplicación que está acoplada al identificador de un adaptador a algún sistema de notificación de tercera parte o alguna infraestructura externa accesible de red y datos auxiliares para tener acceso a ese sistema de notificación o infraestructura.

Algunas modalidades pueden incluir una arquitectura que se divide en tres distintos papeles de procesamiento, los cuales se describen a continuación con detalle y se pueden entender haciendo referencia a la Figura 8. Como se observa en la Figura 8 por el "1", las elipses, y "n", cada uno de los papeles de procesamiento puede tener uno o más casos del papel de procesamiento. Observar que el uso de "n" en cada caso debe ser considerado distinto de cada caso según aplicado a los papeles de procesamiento, significando que cada uno de los papeles de procesamiento no necesita tener el mismo número de casos. El "procesador de distribución" 112 acepta eventos y los agrupa con talones de remesa (ver, por ejemplo, talón de remesa 128-1 en la Figura 6) conteniendo grupos de objetivos 102. El "procesador de suministro" 108 acepta estas agrupaciones y procesa los talones de remesa para suministro a las ubicaciones de red representadas por los objetivos 102. El "papel de manejo" ilustrado por el servicio de manejo 142 proporciona una API externa para manejar los objetivos 102 y también es responsable de aceptar datos estadísticos y de error del procesador de suministro 108 y para procesamiento/almacenamiento de esos datos.

El flujo de datos es anclado sobre un "tema de distribución" 144 en donde los eventos son presentados para distribución. Los eventos presentados son marcados, utilizando una propiedad de mensaje, con el alcance con el que están asociados, que puede ser una de las restricciones antes mencionadas que distinguen a los eventos y mensajes en bruto.

El tema de distribución 144, en el ejemplo ilustrado, tiene una suscripción de pasaje (no filtrada) por "partición de distribución" 120. Una "partición de distribución" es un grupo aislado de recursos que es responsable de distribuir y suministrar notificaciones a un subgrupo de los objetivos 102 para un alcance dado. Una copia de cada evento enviada al tema de distribución está disponible a todas las particiones de distribución actualmente configuradas al mismo tiempo efectivo a través de sus suscripciones asociadas, permitiendo la paralelización del trabajo de distribución.

La paralelización a través de la división ayuda a obtener a tiempo la distribución. Para entender esto, considerar un alcance con 10 millones de objetivos 102. Si los datos de objetivos se mantuvieron en un almacenamiento no dividido, el sistema podría tener que atravesar un grupo de resultado de base de datos individual, grande en secuencia o, si los grupos de resultado fueron adquiridos utilizando consultas de división en el mismo almacenamiento, la producción para adquirir los datos objetivo al menos podría ser contenida por el techo de producción de la infraestructura de compuerta de red frontal del almacenamiento dada, como resultado, la latencia de suministro del suministro de notificaciones a los objetivos 102 cuyos registro de descripción ocurren muy tarde en los grupos de resultado dados probablemente será no satisfactorio.

Más bien, si los 10 millones de objetivos 102 son distribuidos a través de 1,000 almacenamientos que cada uno mantiene 10,000 registros objetivo y esos almacenamientos son emparejados con una infraestructura de cómputo dedicada ("procesador de distribución" 122 y "procesador de suministro" 108 como aquí se describe) realizando las consultas y procesando los resultados en la forma de divisiones como aquí se describe, la adquisición de las descripciones objetivo puede ser paralelizada a través de una amplio grupo de recursos de cómputo y de red, reduciendo significativamente la diferencia de tiempo para la distribución de todos los eventos medidos desde el primero hasta el último evento distribuido.

El número real de divisiones de distribución no está técnicamente limitado. Puede variar de una división individual a cualquier número de divisiones mayores que uno.

En el ejemplo ilustrado, una que vez que el "procesador de distribución" 122 para una partición de distribución 120 adquiere un evento 104, primero calcula el tamaño de los datos de evento y después calcula el tamaño del talón de remesa 128, el cual puede ser calculado basándose en la delta entre el tamaño del evento y el más pequeño del tamaño de mensaje máximo permisible del sistema de mensaje subyacente y un techo de tamaño absoluto. Los eventos están limitados de tal manera que existe algo de espacio mínimo para datos de "talón de remesa".

El talón de remesa 128 es una lista que contiene descripciones de objetivo 102. Los talones de remesa son creados por el procesador de distribución 122 al realizar una consulta de búsqueda que coincide con el alcance de evento contra los objetivos 102 mantenidos en el almacenamiento 124 de partición, regresando todos los objetivos 102 que coinciden con el alcance de evento y un grupo de más condiciones estrechando la selección basándose en las condiciones de filtración de los datos de evento. Las modalidades pueden incluir aquellas condiciones de filtro de una condición de ventana de tiempo que limitará el resultado a aquellos objetivos 102 que se consideran válidos en el instante actual, significando que el tiempo UTC real está dentro de una ventana de tiempo de validez de inicio/fin contenida en el registro de descripción objetivo. Esta instalación se utiliza para poner en la lista negra, lo cual se describe más adelante en este documento. A medida que el resultado de búsqueda es atravesado, el procesador crea una copia del evento 104, llena el talón de remesa 128 hasta el tamaño máximo con descripciones objetico recuperadas del almacenamiento 124, y después pone en cola la agrupación resultante de evento y el talón de remesa en la "cola de suministro" 130 de la partición.

La técnica de talón de remesa asegura que la velocidad de flujo de evento de los eventos del procesador de distribución 122 al procesador(es) de suministro 108 es mayor que la velocidad de flujo de mensaje real en la infraestructura subyacente, significando que, por ejemplo, si 30 descripciones objetivo pueden ser empaquetadas en un talón de remesa 128 a lo largo de los datos de evento, la velocidad de flujo de pares de evento/objetivo es 30 veces más grande que si los pares de evento/objetivo fueran inmediatamente agrupados en mensajes.

El procesador de suministro 108 es el consumidor de agrupaciones de evento/talón de remesa 126 de la cola de suministro 130. El papel del procesador de suministro 108 es sacar de la cola a estas agrupaciones, y suministrar el evento 104 a todos los destinos listados en el talón de remesa 128. El suministro comúnmente sucede a través de un adaptador que formatea el mensaje de evento en un mensaje de notificación entendido por la infraestructura objetivo respectiva. Por ejemplo, el mensaje de notificación puede ser suministrado en un formato MPNS para Windows® 7 phone, formatos APN (Apple Push Notification) para dispositivos ¡OS, formatos C2DM (Mensajería de Nube a Dispositivo) para dispositivos Android, formatos JSON (Java Script Object Notation) para navegadores en dispositivos, HTTP (Protocolo de Transferencia de Hipertexto), etc.

El procesador de suministro 108 comúnmente paralelizará el suministro a través de objetivos independientes 102 y hará serial el suministro a objetivos 102 que comparten un alcance forzado por la infraestructura objetivo. Un ejemplo para este último es que un adaptador particular en el procesador de suministro puede seleccionar enviar todos los eventos focalizados en una aplicación objetivo particular en una plataforma de notificación particular a través de una conexión de red individual.

Los procesadores de distribución y suministro 122 y 108 se desacoplan utilizando la cola de suministro 130 para permitir la escalada independiente de los procesadores de suministro 108 y para evitar tener que regresar movimientos lentos del suministro y bloquear la etapa de cola/empaque de distribución.

Cada partición de distribución 120 puede tener cualquier número de casos de procesador de suministro que concurrentemente observan la cola de suministro 130. La longitud de la cola de suministro 130 puede ser utilizada para determinar cuantos procesadores de suministro están concurrentemente activos. Si la longitud de cola cruza cierto umbral, se pueden agregar nuevos casos de procesador de suministro a la partición 120 para incrementar la producción de envío.

Las particiones de distribución 120 y los casos de distribución y procesador de suministro asociados pueden ser escalados de manera ascendente en una forma virtualmente no limitada con el fin de lograr una paralelización óptima a gran escala. Si la infraestructura objetivo es capaz de recibir y enviar un millón de solicitudes de evento a dispositivos en una forma en paralelo, el sistema descrito es capaz de distribuir eventos a través de su infraestructura de suministro, potencialmente nivelando la infraestructura de red y anchura de banda a través de centros de datos, en una forma que puede saturar la infraestructura objetivo con presentaciones para un suministro de todos los objetivos 102 deseados que sean a tiempo ya que la infraestructura objetivo se permitirá bajo carga y se dará cualquier cargo de suministro otorgado.

A medida que los mensajes son suministrados a los objetivos 102 a través de sus adaptadores de infraestructura respectivos, en algunas modalidades, el sistema toma nota de un rango de artículos de información estadística. Entre aquellos están los períodos de tiempo medidos para la duración entre la recepción de la agrupación de suministro y el suministro de cualquier mensaje individual y la duración de la operación de envío real. También parte de la información de estadística está un indicador de si un suministro tiene éxito o ha fallado. Esta información se recolecta dentro del procesador de suministro 108 y se enrolla en promedios en una base por alcance y en una base de aplicación por objetivo. La "aplicación objetivo" es un identif icador de agrupación introducido para el propósito específico de paquete acumulativo estadístico. Los promedios calculados son enviados a la cola de estadísticas de suministro 146 es intervalos definidos. Esta cola es drenada por un (grupo de) trabajador(es) en el servicio de manejo 142, el cual presenta los datos de evento en un almacén de datos para una escala de propósitos. Estos propósitos pueden incluir, además de verificación operacional, facturación del residente para el cual los eventos han sido suministrados y/o la descripción de las estadísticas para el residente para su propia facturación de terceras partes.

A medida que se detectan errores de suministro, estos errores se clasifican en condiciones de error temporal y permanente. Las condiciones de error temporal pueden incluir, por ejemplo, fallas de red que no permiten que el sistema alcance el punto de suministro de la infraestructura objetivo o la infraestructura objetivo que reporta que una cuota de suministro ha sido temporalmente alcanzada. Las condiciones de error permanente pueden incluir, por ejemplo, errores de autenticación/autorización en la infraestructura objetivo u otros errores que no pueden ser curados sin intervención manual y condiciones de error en donde la infraestructura objetivo reporta que el objetivo ya no está más disponible o desea aceptar mensajes en una base permanente. Una vez clasificado, el reporte de error se presentado en la cola de falla de suministro 148. Para condiciones de error temporal, el error también puede incluir el sello de tiempo UTC absoluto hasta cuando la condición de error se espera que sea resuelta. Al mismo tiempo, el objetivo es localmente colocado en la lista negra por el adaptador objetivo para cualquier suministro local adicional por este caso de procesador de suministro.

La cola de falla de suministro 148 es drenada por un (grupo de) trabajador(es) en el papel de manejo. Los errores permanentes pueden ocasionar que el objetivo respectivo sea inmediatamente eliminado de su almacenamiento de partición de distribución 124 respectivo al cual el papel de manejo tiene acceso. "Eliminación" significa que el registro en realidad es removido o alternativamente que el registro es meramente removido fuera de la vista de las consultas de búsqueda al establecer el sello de tiempo de "fin" de su periodo de validez al sello de tiempo del error. Las condiciones de error temporal pueden ocasionar que el objetivo será desactivado durante el periodo indicado por el error. La desactivación puede ser realizada moviendo el inicio al período de validez del objetivo hasta el sello de tiempo indicado en el error al cual la condición de error se espera que será curada.

La Figura 9 muestra una ilustración de resumen de sistema en donde una partición de adquisición 140 está acoplada a una partición de distribución 120 a través de un tema de distribución 144.

La siguiente discusión ahora se refiere a un número de métodos y actos de método que pueden ser realizados. Aunque los actos de método pueden ser discutidos en cierto orden o ilustrados en un cuadro de flujo como ocurriendo en un orden particular, no se requiere ningún orden particular a menos que específicamente se establezca, o requiera ya que un acto depende de oro acto que se completa antes de que el acto sea realizado.

La Figura 10 muestra un método 1000. El método 1000 puede ser practicado en un sistema de cómputo. El método 1000 incluye actos para suministrar datos. El método incluye determinar un valor monetario relativo de datos, con respecto al tiempo, en un punto de tiempo particular (acto 1002). Los datos pueden ser determinados como una función de tiempo. Por ejemplo, con referencia a la Figura 1, los datos tienen su valor más alto en el tiempo t=0, y su valor más bajo en el t=15 minutos. Des esta forma, en un tiempo particular, los datos tienen un valor particular. Para un punto de tiempo particular, este valor puede ser determinado.

El método 1000 además incluye, basándose en el valor monetario determinado proporcionando los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados al valor monetario (acto 1004). Por ejemplo, algunos consumidores pueden pagar un premium para datos, y de esta manera el suministro de los datos se intentará tan cerca al tiempo t=0 como sea posible. Otros consumidores pueden pagar menos por los datos, y, por lo tanto, se intentará que los datos sean suministrados a cierto tiempo después t = 0 que corresponde a un nivel para aquellos consumidores que pagan menos.

El método 1000 puede ser practicado en donde se proporcionan los datos como un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario, comprende proporcionar datos a dispositivos de consumidor de usuario final de acuerdo con acuerdos de nivel de servicio con usuarios finales.

El método 1000 puede ser practicado en donde se proporcionan los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores relacionados con el valor monetario, comprende proporcionar datos a diferentes dispositivos de consumidor de usuario final de acuerdo con diferentes niveles de unión. Por ejemplo, la Figura 5 muestra cómo diferentes grupos de frescura de datos pueden ser utilizados para proporcionar datos a consumidores a través de sus dispositivos de consumidor.

El método 1000 puede ser practicado en donde se proporcionan los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario, comprende poner compuerta a los datos para retrasar ¡ntencionalmente el suministro de los datos. Por ejemplo, los datos pueden ser ¡ntencionalmente retrasados para reducir su valor basándose en un nivel de servicio o un nivel de preferencia de un consumidor.

El método 1000 puede ser practicado en donde se proporcionan los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario, comprende proporcionar datos a un dispositivo de usuario final basándose en una cantidad pagada por un suscriptor. Por ejemplo, algunos consumidores pueden recibir datos frescos basándose en haber pagado una cantidad de dinero. Similarmente, pagos más altos pueden dar como resultado el suministro de datos más frescos a un dispositivo de consumidor.

El método 1000 puede ser practicado en donde se proporcionan los datos a un grupo de uno o más dispositivos de consumidores de usuario final para consumidores correlacionados con el valor monetario, comprende proporcionar datos al seleccionar una infraestructura de entre una pluralidad de infraestructuras para suministrar los datos a uno o más dispositivos de consumidor de usuario final, en donde la selección de una infraestructura se realiza para seleccionar una infraestructura preferida para suscriptores preferidos. Por ejemplo, algunas infraestructuras pueden ser preferidas sobre otras infraestructuras en que las infraestructuras preferidas tienen características que permiten que los datos será suministrados a través de ellas más rápidamente que otras infraestructuras. De esta forma, suscriptores más unidos o más preferidos, según comparado con suscriptores menos unidos o menos preferidos, pueden recibir datos a través de infraestructuras preferidas según opuesto a recibir los datos a través de otras infraestructuras.

El método 1000 además puede incluir proporcionar estadísticas sobre cómo fueron provistos los datos a dispositivos de consumidor de usuario final a un proveedor de datos. Por ejemplo, como se ilustra en la Figura 3, las estadísticas 208 pueden ser provistas al proveedor de datos 204. Esto puede permitir que el proveedor de datos facture a los suscriptores para datos de acuerdo con cómo les fueron provistos los datos.

Haciendo referencia ahora a la Figura 11, se ilustra otro método 1100. El método 1100 puede ser practicado en un sistema de cómputo. El método 1100 incluye actos para suministrar datos. El método 1100 incluye determinar una unión de consumidor para un consumidor de datos (acto 1102). Por ejemplo, la Figura 5 muestra una unión diferente de diferentes consumidores. El método 1100 además incluye añejar los datos antes de proporcionar los datos a dispositivos de usuario final correlacionados a la unión de consumidor para coincidir con la unión de consumidor (acto 1104). Por ejemplo, los datos pueden ser ¡ntencionalmente no enviados a los consumidores hasta que hayan sido suficientemente retrasados para coincidir con una unión de consumidor. Esto puede ser entendido con referencia a la Figura 1, la cual muestra los datos deteriorándose en valor con el tiempo. De esta manera, los consumidores en una unión más baja pueden recibir datos de valor inferior que fueron valorados de manera inferior al retrasar su suministro. Similarmente, los métodos pueden incluir degradar intencionalmente la calidad de los mismos datos externos para a datos degradados como siendo caducados, para suministrar a consumidores de unión inferior.

El método 1100 puede ser practicado en donde el añejamiento de datos comprende añejar datos para dispositivos de consumidor de usuario final de acuerdo con acuerdos de nivel de servicio con usuarios finales.

El método 1100 puede ser practicado en donde el añejamiento de datos comprende añejar datos para diferentes dispositivos de consumidor de usuario final de acuerdo con diferentes niveles de unión. Por ejemplo, la Figura 5 muestra cómo diferentes uniones de frescura de datos pueden ser utilizadas para proporcionar datos a consumidores a través de sus dispositivos de consumidor.

El método 1100 puede ser practicado en donde el añejamiento de datos comprende poner compuerta a los datos para retrasar intencionalmente el suministro de los datos. Por ejemplo, los datos pueden ser intencionalmente retrasados para reducir su valor basándose en un nivel de servicio o un nivel de preferencia de un consumidor.

El método 1100 puede ser practicado en donde el añejamiento de los datos comprende añejar los datos para un dispositivo de consumidor de usuario final basándose en una cantidad pagada por un suscriptor. Por ejemplo, algunos consumidores pueden recibir datos frescos basándose en haber pagado una cantidad de dinero. Similarmente, pagos más altos pueden dar como resultado datos más frescos que son suministrados a un dispositivo de consumidor.

El método 1100 puede ser practicado en donde el añejamiento de datos comprende seleccionar una infraestructura de entre una pluralidad de infraestructuras para suministrar los datos a uno o más dispositivos de consumidor de usuario final, en donde la selecciona de una infraestructura se realiza para seleccionar una infraestructura preferida para suscriptores preferidos y una infraestructura menos preferida para suscriptores menos preferidos. Por ejemplo, algunas infraestructuras pueden ser preferidas sobre otras infraestructuras en que las infraestructuras preferidas tienen características que permiten que los datos sean suministrados a través de ellas más rápidamente que otras infraestructuras. De esta manera, los suscriptores de unión superior o de preferencia superior, según comparado con suscriptores de unión inferior o preferencia inferior, pueden recibir datos a través de infraestructuras preferidas según opuesto a recibir los datos a través de otras infraestructuras.

El método 100 además puede incluir proporcionar estadísticas sobre cómo se proporcionaron los datos a dispositivos de consumidor de usuario final para un proveedor de datos. Por ejemplo, como se muestra en la Figura 3, las estadísticas 208 pueden ser provistas al proveedor de datos 204. Esto puede permitir que el proveedor de datos facture a los suscriptores para datos de acuerdo a cómo los datos fueron provistos a ellos.

Además, los métodos pueden ser practicados a través de un sistema de cómputo que incluya uno o más procesadores y medios legibles por computadora tales como memoria de computadora. En particular, la memoria de computadora puede almacenar instrucciones ejecutables por computadora que cuando se ejecutan por uno o más procesadores ocasionan que se realicen varias funciones, tales como los actos descritos en las modalidades.

Las modalidades de la presente invención pueden comprender o utilizan una computadora de propósito especial o propósito general, incluyendo hardware de computadora, como se discute con mayor detalle más adelante. Las modalidades dentro del alcance de la presente invención también incluyen otros medios legibles por computadora físicos y otros más para realizar o almacenar instrucciones ejecutables por computadora y/o estructuras de datos. Dichos medios legibles por computadora pueden ser cualquier medio disponible que puede ser accedido por un sistema de computadora de propósito general o de propósito especial. Los medios legibles por computadora que almacenan instrucciones ejecutables por computadora son medios de almacenamiento físico. Los medios legibles por computadora que llevan instrucciones ejecutables por computadora son medios de transmisión. De esta forma, a manera de ejemplo, y no de limitación, las modalidades de la invención pueden comprender al menos dos tipos totalmente distintos de medios legibles por computadora: medios de almacenamiento legibles por computadora físicos y medios legibles por computadora de transmisión.

Los medios de almacenamiento legibles por computadora físicos incluyen RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico (tal como CD, DVD, etc.), almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio, el cual puede ser utilizado para almacenar medios de código de programa deseados en la forma de instrucciones ejecutables por computadora o estructuras de datos y que puede ser accedidas por una computadora de propósito general o de propósito especial.

Una "red" se define como uno o más enlaces de datos que permiten el transporte de datos electrónicos entre sistemas de computadora y/o módulos y/u otros dispositivos electrónicos. Cuando se transfiere o se proporciona información a través de una red u otra conexión de comunicaciones (ya sea por cable duro, inalámbrica, o una combinación de cable duro o inalámbrica) a una computadora, la computadora apropiadamente ve la conexión como un medio de transmisión. Los medios de transmisión pueden incluir una red y/o enlaces de datos, los cuales pueden ser utilizados para llevar medios de código de programa deseados en la forma de instrucciones ejecutables por computadora o estructuras de datos y que puede ser accedidos por una computadora de propósito general o de propósito especial. Las combinaciones de los anteriores también se incluyen dentro del alcance de los medios legibles por computadora.

Además, después de recibir varios componentes de sistema de computadora, los medios de código de programa en la forma de instrucciones ejecutables por computadora o estructuras de datos pueden ser transferidos automáticamente desde los medios legibles por computadora de transmisión a medios de almacenamiento legibles por computadora físicos (o viceversa). Por ejemplo, las instrucciones ejecutables por computadora o estructuras de datos recibidas a través de una red o enlace de datos pueden ser guardadas en una memoria intermedia en RAM dentro de un módulo de inferíase de red (por ejemplo, un "NIC"), y después finalmente transferidas a una RAM de sistema de computadora y/o medios de almacenamiento físicos legibles por computadora menos volátiles en un sistema de computadora. De esta manera, los medios de almacenamiento físicos legibles por computadora pueden ser incluidos en componentes de un sistema de computadora que también (o aún principalmente) utilizan medios de transmisión.

Las instrucciones ejecutables por computadora comprenden, por ejemplo, instrucciones y datos que hacen que una computadora de propósito general, computadora de propósito especial, o dispositivo de procesamiento de propósito especial realicen cierta función o un grupo de funciones. Las instrucciones ejecutables por computadora pueden ser, por ejemplo, instrucciones de formato binario, intermedias, tales como un lenguaje de ensamble, o aún un código de fuente. Aunque la materia objeto ha sido descrita en un lenguaje específico a características estructurales y/o actos metodológicos, se debe entender que la materia objeto definida en las reivindicaciones anexas no necesariamente está limitada a las características o actos descritos anteriormente. Más bien, las características y actos descritos se describen como formas ilustrativas para ¡mplementar las reivindicaciones.

Aquellos expertos en la técnica apreciarán que la invención puede ser practicada en ambientes de cómputo de red con muchos tipos de configuraciones de sistema de computadora, incluyendo, computadoras personales, computadoras de escritorio, computadoras portátiles, procesadores de mensaje, dispositivos portátiles, sistemas de procesadores múltiples, electrónica de consumidor basada en microprocesador o programable, PC de red, minicomputadoras, computadoras centrales, teléfonos móviles, PDA, mensáfono, enrutadores, conmutadores, y similares. La invención también puede ser practicada en ambientes de sistema distribuido, en donde sistemas de computadora locales y remotos, los cuales están enlazados (ya sea a través de enlaces de datos de cable duro, enlaces de datos inalámbricos, o a través de una combinación de enlaces de datos de cable duro e inalámbricos) a través de una red, ambos realizan tareas. En un ambiente de sistema distribuido, los módulos de programa pueden ser localizados en dispositivos de almacenamiento de memoria tanto locales como remotos.

La presente invención puede ser modalizada en otras formas específicas sin apartarse de su espíritu o características. Las modalidades descritas deben ser consideradas en todos los aspectos como ilustrativas y no restrictivas. El alcance de la invención, por lo tanto, es indicado por las reivindicaciones anexas en lugar de por la descripción anterior. Todos los cambios que vienen dentro del significado y escala de equivalencia de las reivindicaciones serán abarcados dentro de su alcance.

Claims (7)

REIVINDICACIONES

1. En un sistema de cómputo, un método para suministrar datos, el método comprende: determinar un valor monetario relativo de datos, con respecto al tiempo, en un punto en el tiempo particular; y basándose en el valor monetario determinado proporcionar los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario.

2. El método de acuerdo con la reivindicación 1, en donde la provisión de los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario comprende proporcionar datos a dispositivos de consumidora de usuario final de acuerdo con acuerdos de nivel de servicio con usuarios finales.

3. El método de acuerdo con la reivindicación 1, en donde la provisión de los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario comprende proporcionar datos a diferentes dispositivos de consumidor de usuario final de acuerdo con diferentes niveles de unión.

4. El método de acuerdo con la reivindicación 1, en donde la provisión de los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario comprende poner compuerta a los datos para retrasar intencionalmente el suministro de los datos.

5. El método de acuerdo con la reivindicación 1, en donde la provisión de los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario comprende proporcionar datos a un dispositivo de consumidor de usuario final basándose en una cantidad pagada por un suscriptor.

6. El método de acuerdo con la reivindicación 1, en donde la provisión de los datos a un grupo de uno o más dispositivos de consumidor de usuario final para consumidores correlacionados con el valor monetario comprende proporcionar datos al seleccionar una infraestructura de entre una pluralidad de infraestructuras para suministrar los datos a uno o más dispositivos de consumidor de usuario final, en donde la selección de una infraestructura se realiza para seleccionar una infraestructura preferida para suscriptores preferidos.

7. El método de acuerdo con la reivindicación 1, que además comprende proporcionar estadísticas sobre cómo los datos fueron provistos a dispositivos de consumidor de usuario final para un proveedor de datos.