ES2930670T3 - Técnicas para el mecanismo de retransmisión de mensajes - Google Patents

Abstract

Las realizaciones de los Aparatos, Métodos y Sistemas del Mecanismo de Retransmisión de Mensajes ("MRM") transforman las solicitudes de aplicaciones para diarios de mensajes a través de componentes MRM en acceso acelerado a flujos de mensajes segmentados. En una implementación, el MRM puede obtener un diario de mensajes escritos por aplicaciones durante las operaciones del sistema y dividir el mensaje obtenido del diario de mensajes completo en segmentos de mensajes. En algunas implementaciones, el MRM puede proporcionar a las aplicaciones de recuperación acceso a dichos segmentos de mensajes para el consumo acelerado de mensajes. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Técnicas para el mecanismo de retransmisión de mensajes

Esta solicitud de título de patente divulga y describe varias innovaciones novedosas y aspectos inventivos del mecanismo de retransmisión de mensajes y las tecnologías de gestión del espacio de direcciones de memoria (en adelante, "divulgación") y contiene material que está sujeto a derechos de autor, trabajo de enmascaramiento y/u otra protección de propiedad intelectual. Los propietarios respectivos de dicha propiedad intelectual no tienen objeción a la reproducción facsímil de la divulgación por cualquier persona tal como aparece en los archivos/registros publicados de la Oficina de Patentes, pero se reservan todos los derechos.

Referencia cruzada a solicitudes relacionadas

La presente solicitud reclama prioridad de: (a) Solicitud Provisional de EE. UU. Número 61/951,364, presentada el 11 de marzo de 2014; y (b) Solicitud Provisional de EE. UU. Número 61/951,390, presentada el 11 de marzo de 2014. El objeto de la presente solicitud está relacionado con la Solicitud de Utilidad de EE. UU. Número 14/644,674 en tramitación junto con la presente, presentada el 11 de marzo de 2015, que reivindica la prioridad de la Solicitud Provisional de EE. UU. Número 61/951,374, presentada el 11 de marzo de 2014. El objeto de la presente solicitud también está relacionado con la Solicitud Internacional PCT Número PCT/US2013/059558, presentada el 12 de septiembre de 2013.

Campo

Las innovaciones presentes generalmente abordan técnicas para la gestión de registro (“journaling”) de mensajes de aplicación y, más particularmente, incluyen Aparatos, Métodos y Sistemas de Mecanismo de Retransmisión de Mensajes ("MRM").

Antecedentes

En un aspecto de un sistema informático, durante sus operaciones, las aplicaciones de software pueden escribir mensajes en un diario/registro (“journal”) mientras realizan acciones o reaccionan a eventos externos. Además de escribir sus propios mensajes, las aplicaciones de software a veces acceden a los mensajes escritos por otras aplicaciones.

Breve descripción de la invención

Los aspectos de la invención se exponen en las reivindicaciones adjuntas. Las enseñanzas de los Aparatos, Métodos y Sistemas del Mecanismo de Retransmisión de Mensajes ("MRM") transforman las solicitudes de aplicaciones para diarios de mensajes a través de componentes de MRM en acceso acelerado a flujos de mensajes segmentados. En una implementación, el MRM puede obtener un diario de mensajes de mensajes escritos por aplicaciones durante las operaciones del sistema y dividir el mensaje obtenido del diario de mensajes completo en segmentos de mensajes. En algunas implementaciones, el MRM puede proporcionar a las aplicaciones de recuperación acceso a dichos segmentos de mensajes para el consumo acelerado de mensajes.

De acuerdo con una enseñanza particular de la presente divulgación, un método de retransmisión de mensajes acelerados para un sistema informático puede comprender los pasos de mantener, en un medio de almacenamiento del sistema informático, un diario maestro de mensajes secuenciados generados a partir de una pluralidad de mensajes escritos por aplicaciones o procesos durante las operaciones del sistema informático, al menos un subconjunto de dichas aplicaciones o procesos que requieren acceso a dichos mensajes secuenciados para funcionar correctamente; determinar una demanda estimada de acceso a dichos mensajes secuenciados por dicho al menos un subconjunto de aplicaciones o procesos que pueden experimentar conmutaciones por error (“failovers”); generar, con base en dicha demanda estimada, una o más copias de diario y/o uno o más segmentos de diario mediante la duplicación del contenido de dicho diario maestro, siendo cada copia de diario o segmento de diario accesible de forma independiente por una sola aplicación o proceso en un momento dado; y asignar dichas una o más copias de diario y/o dichos uno o más segmentos de diario, a pedido, a algunos de dicho al menos un subconjunto de dichas aplicaciones o procesos que han experimentado conmutaciones por error o una brecha en dichos mensajes secuenciados, de modo que múltiples aplicaciones o procesos pueden acceder simultáneamente al contenido de dicho diario maestro, acelerando así el acceso a dichos mensajes secuenciados en dicho diario maestro por parte de dichas aplicaciones o procesos en su recuperación de dichas conmutaciones por error o dicha brecha en dichos mensajes secuenciados.

Según otra enseñanza particular de la presente divulgación, un sistema informático que implementa la retransmisión acelerada de mensajes puede comprender al menos un procesador informático y al menos un medio de almacenamiento dispuestos en comunicación con el al menos un procesador informático. El al menos un medio de almacenamiento puede almacenar instrucciones de ordenador para hacer que el al menos un procesador de ordenador: mantenga, en dicho al menos un medio de almacenamiento del sistema informático, un diario maestro de mensajes secuenciados generados a partir de una pluralidad de mensajes escritos por aplicaciones o procesos durante las operaciones del sistema informático, al menos un subconjunto de dichas aplicaciones o procesos que requieren acceso a dichos mensajes secuenciados para funcionar correctamente; determine una demanda estimada de acceso a dichos mensajes secuenciados por dicho al menos un subconjunto de aplicaciones o procesos que pueden experimentar conmutaciones por error; genere, con base en dicha demanda estimada, una o más copias de diario y/o uno o más segmentos de diario mediante la duplicación del contenido de dicho diario maestro, siendo cada copia de diario o segmento de diario accesible de forma independiente por una sola aplicación o proceso en un momento dado; y asigne dichas una o más copias de diario y/o dichos uno o más segmentos de diario, a pedido, a algunos de dicho al menos un subconjunto de dichas aplicaciones o procesos que han experimentado conmutaciones por error o una brecha en dichos mensajes secuenciados, de modo que múltiples aplicaciones o los procesos pueden acceder simultáneamente al contenido de dicho diario maestro, acelerando así el acceso a dichos mensajes secuenciados en dicho diario maestro por parte de dichas aplicaciones o procesos en su recuperación de dichas conmutaciones por error o dicha brecha en dichos mensajes secuenciados.

De acuerdo con otra enseñanza particular más de la presente divulgación, un medio legible por ordenador no transitorio puede tener instrucciones de ordenador que, cuando se ejecutan, provocan que un sistema informático implemente la retransmisión acelerada de mensajes. El medio legible por ordenador no transitorio puede comprender un código para: mantener, en un medio de almacenamiento del sistema informático, un diario maestro de mensajes secuenciados generados a partir de una pluralidad de mensajes escritos por aplicaciones o procesos durante las operaciones del sistema informático, al menos uno subconjunto de dichas aplicaciones o procesos que requieren acceso a dichos mensajes secuenciados para funcionar correctamente; determinar una demanda estimada de acceso a dichos mensajes secuenciados por dicho al menos un subconjunto de aplicaciones o procesos que pueden experimentar fallas; generar, con base en dicha demanda estimada, una o más copias de diario y/o uno o más segmentos de diario mediante la duplicación del contenido de dicho diario maestro, siendo cada copia de diario o segmento de diario accesible de forma independiente por una sola aplicación o proceso en un momento dado; y asignar dichas una o más copias de diario y/o dichos uno o más segmentos de diario, a pedido, a algunos de dicho al menos un subconjunto de dichas aplicaciones o procesos que han experimentado conmutaciones por error o una brecha en dichos mensajes secuenciados, de modo que múltiples aplicaciones o los procesos pueden acceder simultáneamente al contenido de dicho diario maestro, acelerando así el acceso a dichos mensajes secuenciados en dicho diario maestro por parte de dichas aplicaciones o procesos en su recuperación de dichas conmutaciones por error o dicha brecha en dichos mensajes secuenciados.

Un efecto técnico de la presente divulgación es acelerar el acceso y el consumo de un diario de mensajes secuenciados por parte de aplicaciones o procesos, lo que a su vez acelera significativamente la recuperación de aplicaciones o procesos fallidos.

Otro efecto técnico de la presente divulgación es el ajuste o control dinámico del acceso al diario por parte de múltiples aplicaciones o procesos, incluido el equilibrio de carga entre las copias/segmentos de diario en función de una demanda estimada de acceso al diario.

Otros beneficios, ventajas o efectos técnicos pueden ser apreciados por los expertos en la técnica que lean la descripción del presente documento y/o practiquen una o más enseñanzas de la presente descripción.

Breve descripción de los dibujos

Los apéndices, dibujos, figuras, imágenes, etc. adjuntos ilustran varios aspectos inventivos, enseñanzas y características ejemplares, no limitativos ("e.g." o "ejemplo(s)") de acuerdo con la presente divulgación:

La FIGURA 1 muestra diagramas de bloques que ilustran ejemplos del MRM que proporciona gestión del registro de mensajes de aplicación de acuerdo con una enseñanza de la presente divulgación.

La FIGURA 1A muestra un diagrama de flujo que ilustra un proceso ejemplar para la gestión del registro de mensajes según una enseñanza de la presente divulgación;

La FIGURA 2 muestra un diagrama que ilustra ejemplos de cómo proporcionar aplicaciones, a través de un componente MRM, duplicados de diarios de mensajes completos para su recuperación según las enseñanzas de la presente divulgación;

La FIGURA 3 muestra un diagrama de gráfico de datos que ilustra ejemplos de cómo proporcionar aplicaciones a través de un flujo de componentes de MRM, diarios de mensajes segmentados para la recuperación de acuerdo con las enseñanzas de la presente divulgación;

La FIGURA 4 muestra un diagrama de bloques que ilustra ejemplos de un controlador de MRM según las enseñanzas de la presente divulgación;

Descripción detallada de la invención

Las enseñanzas de los Aparatos, Métodos y Sistemas del Mecanismo de Retransmisión de Mensajes (en lo sucesivo, "MRM") pueden transformar las solicitudes de aplicaciones para diarios de mensajes, a través de componentes de MRM, en acceso acelerado a flujos de mensajes segmentados.

La FIGURA 1 muestra diagramas de bloques que ilustran ejemplos del MRM que proporciona gestión de registros de mensajes de aplicación a aplicaciones que necesitan acceso a diarios de mensajes. En algunas implementaciones, las aplicaciones escriben mensajes en un diario a medida que realizan acciones y/o reaccionan a eventos externos durante las operaciones normales del sistema. Por ejemplo, las aplicaciones pueden necesitar recibir y procesar mensajes que provienen de partes externas, como, entre otros, mensajes relacionados con transacciones y mercados de valores. Por ejemplo, las aplicaciones de software de un sistema de comercio electrónico pueden intercambiar y procesar mensajes con formato de intercambio de información financiera (FIX) tales como, entre otros, entrada, modificación, cancelación de pedidos, etc., mensajes de comercio, informes de confirmación de pedidos, datos de mercado mensajes y/o similares. En algunas realizaciones, las aplicaciones pueden escribir en un diario para registrar sus actividades a medida que intercambian mensajes con otras aplicaciones y/o terceros externos y procesan los mensajes y actúan sobre ellos. En algunas realizaciones, puede ser necesario informar a las aplicaciones de las actividades de algunas o todas las demás aplicaciones que se ejecutan durante el funcionamiento del sistema, y en algunas realizaciones puede ser necesario acceder al diario de mensajes que puede contener los mensajes escritos por todas las aplicaciones. Por ejemplo, una aplicación 101 puede tener una brecha en su consumo de mensajes de diario y puede necesitar acceder al diario para llenar la brecha. Por ejemplo, es posible que la aplicación se haya bloqueado y/o perdido mensajes como resultado de problemas de transmisión (por ejemplo, en la capa de red, etc.), y es posible que deba recuperar los mensajes faltantes del diario. En algunas realizaciones, también puede necesitar escribir sus propios mensajes en el diario.

En algunas implementaciones, una aplicación 101 puede necesitar acceder al diario regularmente para volver a acceder a los mensajes perdidos y llenar cualquier brecha en su consumo de mensajes de diario. En algunas implementaciones, las solicitudes repetidas de una aplicación a los mensajes de un diario pueden interferir con otras solicitudes de acceso al mismo diario de otras aplicaciones 102. Por ejemplo, una solicitud de una aplicación 101 puede competir con las solicitudes de otras aplicaciones 102 y dar como resultado una cola de aplicaciones que esperan su turno para acceder al diario, por ejemplo, 103. En algunas implementaciones, las aplicaciones en espera pueden estar tratando de recuperar los mensajes perdidos y, mientras esperan que el diario esté disponible, pueden terminar retrasándose aún más en su recuperación. Por ejemplo, otras aplicaciones pueden estar escribiendo en el diario mientras una aplicación está esperando, lo que resulta en un mayor tiempo de recuperación para la aplicación en espera, ya que puede necesitar acceder a los mensajes escritos en el diario cuando la aplicación estaba en una cola, por ejemplo, 104. En algunas implementaciones, esto puede crear una reacción en cadena de aumento del tiempo de espera y recuperación para las aplicaciones en espera posteriores y puede resultar en un rendimiento degradado para las aplicaciones en espera y/o el sistema en su conjunto.

En algunas implementaciones, el MRM puede proporcionar a las aplicaciones un acceso acelerado a los diarios a través de la generación de múltiples copias duplicadas y la segmentación del diario de mensajes completo, por ejemplo, 106. Por ejemplo, el MRM puede poner a disposición de las aplicaciones una serie de diarios que proporcionen a las aplicaciones más de una fuente para recuperarse. En estas realizaciones, el proceso de acceso a los diarios puede tener una carga más equilibrada porque puede haber más colas, pero más cortas.

Sin embargo, en algunas realizaciones, incluso las colas más cortas pueden tener un tiempo de espera prolongado. Por ejemplo, una aplicación en recuperación puede tener una gran cantidad de mensajes para ponerse al día y, como tal, puede llevar mucho tiempo en un diario, lo que provoca una gran demora para otras aplicaciones en la cola, sin importar cuán corta sea la cola. En consecuencia, el MRM puede proporcionar además un cambio acelerado en un punto de acceso al diario dividiendo el diario de mensajes completo en varios segmentos y aprovechando los segmentos para varias aplicaciones simultáneamente. Por ejemplo, las aplicaciones pueden pasar de un diario segmentado a otro obteniendo los mensajes relevantes que necesitan para la recuperación, pero sin perder mucho tiempo en un diario y causar demoras a otras aplicaciones que necesitan acceso a los diarios para la recuperación.

Con referencia a la FIGURA 2, en algunas implementaciones, las aplicaciones 207 pueden escribir mensajes en un diario 201 mientras realizan acciones o reaccionan a eventos externos. En algunas implementaciones, las aplicaciones 208-209 pueden leer los mensajes de otras aplicaciones y mantenerse al tanto de todas las actividades durante las operaciones del sistema. Por ejemplo, la aplicación A puede escribir mensajes en las primeras tres filas del diario 201, y una aplicación B posterior puede leer estos mensajes, ya que también está escribiendo sus propios mensajes en el siguiente lote de filas disponibles en el diario (por ejemplo, las próximos tres filas). En algunas implementaciones, una aplicación 210 puede haber experimentado una brecha en su consumo de los mensajes registrados. Por ejemplo, la aplicación puede haber perdido mensajes como resultado de problemas de transmisión en la capa de red y ahora puede necesitar un medio para recuperar los mensajes perdidos, por ejemplo, 211. En algunas implementaciones, puede haber otras aplicaciones que busquen acceso al diario para sus propias necesidades de recuperación y se puede formar una cola si solo hay un diario, o si la cantidad de copias de diarios disponibles no es suficiente para satisfacer las demandas de las aplicaciones en cola. En algunas implementaciones, el MRM puede proporcionar copias duplicadas 202-204 del diario de mensajes completo para permitir que las aplicaciones accedan rápidamente a los mensajes perdidos, por ejemplo, 213. Por ejemplo, si una aplicación determinada ocupa un diario, otras aplicaciones pueden recuperar mensajes perdidos de uno de los otros diarios disponibles que pueden ser duplicados del primer diario, por ejemplo, 212.

En algunas implementaciones, incluso con varios diarios duplicados, se puede formar una cola si una aplicación ocupa un diario durante un período de tiempo prolongado. Por ejemplo, una aplicación puede estar iniciando desde cero y/o puede haber perdido una gran cantidad de mensajes. Por ejemplo, es posible que la aplicación se haya iniciado más tarde en el día y que deba ponerse al día con todos los mensajes que ya se hayan procesado. En algunas implementaciones, la aplicación puede tardar mucho tiempo en recuperar y procesar todos los mensajes perdidos, ocupando un solo diario y provocando una cola y una recuperación retrasada para otras aplicaciones que pueden necesitar acceso al diario.

Con referencia a la FIGURA 3, en algunas realizaciones, las aplicaciones 307-309 pueden escribir mensajes en un diario 301 mientras realizan acciones o reaccionan a eventos externos, y también pueden necesitar mantenerse al día con los mensajes escritos por otras aplicaciones en el diario, como se describe en detalle arriba con referencia a la FIGURA 2. En algunas realizaciones, una aplicación que recupera mensajes perdidos puede ocupar el diario durante un tiempo prolongado y competir con las solicitudes de otras aplicaciones para acceder al mismo diario. En algunas realizaciones, el MRM puede proporcionar a las aplicaciones un acceso acelerado a los diarios a través de la segmentación del diario de mensajes completo y/o sus múltiples copias duplicadas, por ejemplo, 311. Por ejemplo, el MRM puede dividir el diario de mensajes completo en segmentos 302-304 y asignar segmentos específicos a diarios específicos para aprovechar los segmentos de mensajes para varias aplicaciones simultáneamente, por ejemplo, 313.

En algunas realizaciones, una aplicación desconectada 310 que busca recuperar mensajes perdidos puede obtener un segmento del mensaje de diario completo de un segmento, antes de pasar al siguiente diario para obtener otro segmento del mensaje completo original. En tales realizaciones, el tiempo que la aplicación pasa en cada diario puede ser menor que el que habría pasado obteniendo el mensaje completo de un solo diario. Por ejemplo, una vez que la aplicación desconectada obtiene el segmento de mensaje de un diario, puede pasar a otro diario, lo que permite que otras aplicaciones accedan más rápido a dicho diario. En algunas realizaciones, si la aplicación desconectada aún tiene una brecha en el mensaje, puede pasar a otros diarios que contienen los segmentos de mensajes relevantes y acceder a esos mensajes desde estos diarios. En algunas realizaciones, el tiempo que cada aplicación pasa en un diario determinado puede ser limitado, lo que permite colas más cortas y rápidas de aplicaciones que esperan acceder a los mensajes almacenados en los diarios. Por ejemplo, con los diarios de mensajes segmentados, el tiempo que cada aplicación dedica a un diario determinado puede ser menor que el que hubiera dedicado a un diario con un mensaje completo y, como tal, puede conducir a un llenado más rápido de la brecha del mensaje para las aplicaciones que intentan recibir mensajes perdidos. mensajes, por ejemplo, 312.

La FIGURA 1A muestra un diagrama de flujo que ilustra un proceso ejemplar para la gestión del registro de mensajes de acuerdo con una realización de la presente invención. El proceso ejemplar o sus variaciones pueden implementarse en cualquier sistema informático donde el orden o la secuencia en que ocurren los eventos es importante. Por ejemplo, el sistema informático puede ser un sistema de comercio electrónico, un sistema de venta basado en subastas o un sistema de juegos. A modo de ilustración, las realizaciones preferidas se describen en el contexto de un sistema de comercio electrónico tal como uno implementado por una bolsa de valores.

En el paso 110, el sistema informático puede mantener un diario maestro de mensajes secuenciados en su medio de almacenamiento. Por ejemplo, en un sistema de comercio electrónico para instrumentos financieros como acciones y bonos, las aplicaciones de software centrales, como entradas de pedidos/puertas de acceso de negociación FIX, motor de comparación, aplicaciones de datos de mercado, aplicaciones de datos de referencia y aplicaciones de integración post-negociación pueden estar ejecutándose en uno o más servidores informáticos simultáneamente, y todas las aplicaciones se comunican a través de un bus de mensajería central y, por lo tanto, generan una gran cantidad de mensajes en un momento dado. Estos mensajes pueden incluir, entre otros, pedidos, intercambios, cotizaciones, comunicación entre aplicaciones, etc. Todos los mensajes no secuenciados se enrutan a través de un secuenciador que los organiza en un flujo secuenciado de acuerdo con el orden en que fueron procesados/secuenciados. Como resultado, el secuenciador continúa generando un registro determinista de alta fidelidad (también conocido como el "diario") de todos los mensajes en el orden correcto.

Luego, el diario se vuelve a publicar o se pone a disposición de los componentes del sistema comercial que, para realizar sus respectivas funciones, necesitan acceso a los mensajes secuenciados. Si uno de los componentes (por ejemplo, una aplicación o proceso, denominado en lo sucesivo simplemente "aplicación") tiene que recuperarse de una conmutación por error, debe ponerse al día con la secuencia cada vez mayor de mensajes, accediendo al diario de mensajes, a fin de para volver a su estado de funcionamiento previsto. Por ejemplo, un bloqueo de solo 10 segundos podría hacer que una aplicación pierda varios millones de mensajes, tiene que ponerse al día con esos millones de mensajes antes de que pueda volver a funcionar. Por lo tanto, el diario de mensajes es fundamental para la recuperación y la redundancia del sistema. El diario de mensajes también ayuda a un intercambio a cumplir con sus requisitos de libros y registros.

Sin embargo, si una cantidad significativa de aplicaciones ha fallado, por ejemplo, durante la falla del hardware de un servidor que admite varias aplicaciones, la demanda de acceso al diario de mensajes aumentaría, especialmente durante las horas de mayor actividad comercial. Con tantas aplicaciones que desean ponerse al día con el flujo de mensajes, tienen que esperar en una cola: si una aplicación está "en el pozo" leyendo el diario, otra tiene que esperar en la cola detrás de ella. Mientras esperan ponerse al día, la cantidad de mensajes registrados sigue creciendo, lo que hace que esas aplicaciones (que intentan recuperarse rápidamente) se retrasen aún más.

En consecuencia, es deseable estimar (en el Paso 112) la demanda de acceso al diario de mensajes por parte de las aplicaciones fallidas. Se puede predecir o pronosticar, en función del rendimiento actual y/o pasado del sistema informático, qué componente(s) de hardware y/o software podría(n) experimentar una falla y cuáles o cuántas aplicaciones podrían verse afectadas por la falla. Se pueden considerar varios factores para determinar la demanda estimada de acceso al diario, incluidos, entre otros, fallas de software conocidas o potenciales, fallas de hardware conocidas o potenciales, la cantidad de aplicaciones o procesos afectados por una falla de software o hardware, la velocidad a el cual una aplicación o proceso accede a mensajes en el diario, una copia del diario o un segmento del diario, el tiempo de recuperación deseado para una aplicación o proceso fallido (por ejemplo, carga de trabajo del sistema informático (que puede variar según la hora del día o el día de la semana, por ejemplo).

Con base en la demanda estimada, el sistema informático puede configurarse para generar una o más copias de diario (en el Paso 114) duplicando el contenido del diario maestro y/o generar uno o más segmentos de diario (en el Paso 116) duplicando el contenido del diario maestro. De acuerdo con las realizaciones de la presente invención, los segmentos de diario pueden generarse directamente desde la copia maestra (o "copia dorada") del diario de mensajes o desde una de las copias de diario creadas en el Paso 114. La generación de copias de diario y/o segmentos de diario puede lograrse con un módulo de software o hardware dedicado tal como un repetidor.

A continuación, en el paso 118, las copias de diario y/o los segmentos de diario pueden asignarse a aplicaciones fallidas para acelerar su recuperación. La asignación podría lograrse de varias maneras. Por ejemplo, las copias o los segmentos de diario pueden preasignarse a las aplicaciones fallidas o las aplicaciones a las copias/segmentos de diario. Alternativamente (y más preferiblemente), una aplicación puede simplemente solicitar acceso a una porción específica del contenido del diario y esperar hasta que encuentre una copia/segmento de diario desocupado, muy parecido a algunas líneas de pago de supermercados donde los clientes forman una sola cola servida colectivamente por múltiples cajeros y la primera persona en la fila se dirige al cajero que queda disponible a continuación. Preferiblemente, el número de copias/segmentos de diario es lo suficientemente grande como para acomodar el número total de solicitudes fallidas, de modo que ninguna de las solicitudes tenga que esperar en una larga cola para recibir su turno. De acuerdo con una realización, las copias/segmentos de diario pueden ser suficientes para permitir el acceso inmediato de cada una de las aplicaciones fallidas o para ser asignados a colas con no más de 2-3 aplicaciones en cada cola.

Para un ejemplo más específico, si se elige un microsegundo (es decir, 1000 nanosegundos) como el tiempo máximo de recuperación y se estima que 10 aplicaciones fallidas tienen que recuperarse para ponerse al día con el diario, entonces, en promedio, no debería tomar más de 100 nanosegundos para que cada aplicación complete su acceso al diario. La cantidad de tiempo que tarda una aplicación en acceder a un mensaje puede calcularse o estimarse en función de (un) el tamaño de los mensajes en términos de X bits y/o bytes y (b) la cantidad de nanosegundos que tomaría procesar X bits o bytes. El número máximo de mensajes que podrían procesarse en 100 nanosegundos puede calcularse como una limitación en el tamaño de los segmentos de diario.

Puede haber varias opciones disponibles para configurar el número de copias de diario o segmentos de diario. Por ejemplo, en lugar de tener una sola cola con 10 aplicaciones donde solo la primera aplicación podría acceder al diario, el contenido del diario se puede replicar en una copia del diario para que se puedan asignar 2 copias del mismo diario a las 10 aplicaciones-2 colas con 5 aplicaciones por cola. Mejor aún, 5 copias del mismo diario podrían estar disponibles para las 10 aplicaciones: 5 colas con 2 aplicaciones por cola, lo que permite que 5 aplicaciones accedan a los diarios. Como resultado, el tiempo de recuperación de las 10 aplicaciones puede acortarse significativamente.

Alternativamente, en la medida en que las 10 aplicaciones necesiten acceder a diferentes partes del diario de mensajes, una o más copias de diario pueden dividirse en segmentos de diario donde cada segmento contiene un subconjunto del diario de mensajes que tiene un flujo más corto de mensajes secuenciados. Por ejemplo, con las 10 solicitudes fallidas, se pueden crear 3 copias de diario y una de las copias de diario se puede dividir en tres segmentos de diario. En consecuencia, se pueden formar 5 colas con 2 aplicaciones en cada cola, donde dos colas de aplicaciones acceden a dos de las copias completas del diario mientras que tres colas acceden a los tres segmentos de diario. En cualquier enfoque (con o sin segmentos de diario), se puede aplicar un equilibrio de carga adicional a las colas de aplicaciones, por ejemplo, para ajustar sus asignaciones respectivas de las copias de diario y/o segmentos de diario.

Después de que las copias de diario y/o los segmentos de diario hayan sido generados y asignados a las aplicaciones (por ejemplo, ya sea preasignados a las aplicaciones o asignados a pedido), el sistema informático continúa acumulando más mensajes en la secuencia registrada. Por lo tanto, mientras que la "copia dorada" del diario de mensajes se actualiza constantemente con los últimos mensajes secuenciados.

Sin embargo, el contenido de las copias/segmentos de diario creados anteriormente puede quedar desactualizado e incompleto.

En el caso de múltiples copias de diario completas, cada copia de diario puede continuar leyendo el flujo secuenciado, agregando a su propio diario, y puede hacerlo sin preocuparse por perder la sincronización con otras copias de diario porque el flujo está secuenciado y, por lo tanto, es determinista, todos los diarios tienen todos los mensajes en el mismo orden según sus números de secuencia. Si se pierde algún mensaje, se volverá a solicitar una copia del diario desde otra copia del diario para reponer los mensajes faltantes. Una vez que se completan los mensajes, vuelve a comenzar la lectura de la secuencia en tiempo real.

En el caso de los diarios segmentados, cada segmento de diario, una vez completado, se volverá estático y solo estará activo el siguiente segmento de creación/construcción activa. Por ejemplo, si cada segmento contiene 10 mensajes y se han escrito 35 mensajes en la secuencia, tendrá 3 segmentos completos y estáticos, y un segmento de creación activa con 5 de sus 10 mensajes llenos. Si lee con éxito los 5 mensajes restantes, se vuelve estático y comienza un quinto segmento. Si pierde algún mensaje, digamos que perdió el mensaje número 8, volverá a solicitar el mensaje número 8 y, una vez que lo reciba, continúe con los mensajes número 9 y número 10. Puede haber condiciones de carrera en las que, mientras se vuelve a solicitar el número 8, el número 9 se secuencia y también se pierde el número 9, por lo que debe volver a solicitar el número 9. Eventualmente, corre para ponerse al día y vuelve a hacer la transición a la transmisión en tiempo real.

Por lo tanto, la única forma en que una copia de diario completa o un segmento de diario se vuelve incompleto es típicamente cuando pierde un mensaje, que debe volver a solicitar. En el caso de segmentos de diario, el registro de diario agregado completo puede estar incompleto si el segmento de creación activa más reciente tiene mensajes perdidos y está incompleto.

En el Paso 120, para que las copias/segmentos de diario se pongan al día con el diario de mensajes en constante crecimiento, el contenido de al menos una de las copias/segmentos de diario puede actualizarse o sincronizarse con el contenido del diario maestro (es decir, la copia dorada) o el contenido de otra copia/segmento de diario (más actualizado).

Las copias de diario (no segmentadas) pueden actualizarse dinámicamente en tiempo real y, por lo tanto, crecer continuamente en longitud. Para segmentos de diario, si la cantidad de mensajes se limita a 1000 por segmento de diario, se iniciarán nuevos segmentos con cada mensaje número 1001-ésimo y se actualizarán dinámicamente hasta el mensaje número 1000-ésimo. Si una aplicación necesita volver a solicitar desde un segmento de diario que se está actualizando dinámicamente, solo deberá solicitar hasta el número de secuencia de mensaje más reciente antes de que se "ponga al día" y pueda comenzar a leer desde la transmisión al mismo tiempo que el segmento de diario.

De acuerdo con algunas realizaciones de la presente invención, las copias de diario y/o los segmentos de diario pueden organizarse en una jerarquía de múltiples niveles y una copia/segmento de diario puede ser capaz de ponerse al día con otra copia/segmento de diario. Por ejemplo, las copias/segmentos de diario pueden designarse como Nivel 1, Nivel 2, Nivel 3, etc. Una copia/segmento de diario de Nivel 1 siempre está actualizada con la "copia dorada" y solo las copias/segmentos de diario de Nivel 2 y/o Nivel 3 pueden acceder a ella cuando tienen que ponerse al día. Una copia/segmento de diario de Nivel 2 solo puede ponerse al día con otras copias/segmentos de diario de Nivel 2 y, si es necesario, con una copia/segmento de diario de Nivel 1; una copia/segmento de diario de nivel 3 solo puede ponerse al día con otras copias/segmentos de diario de nivel 3 y, si es necesario, con una copia/segmento de diario de nivel 2 o de nivel 1.

Controlador de MRM

La FIGURA 4 muestra un diagrama de bloques que ilustra ejemplos de un controlador de MRM 401. En esta realización, el controlador de MRM 401 puede servir para agregar, procesar, almacenar, buscar, servir, identificar, instruir, generar, emparejar y/o facilitar interacciones con un ordenador a través de diversas tecnologías y/u otros datos relacionados.

Los usuarios, por ejemplo, 433a, que pueden ser personas y/u otros sistemas, pueden utilizar sistemas de tecnología de la información (por ejemplo, ordenadores) para facilitar el procesamiento de la información. A su vez, los ordenadores emplean procesadores para procesar la información; dichos procesadores 403 pueden denominarse unidades centrales de procesamiento (CPU). Una forma de procesador se conoce como microprocesador. Las CPU usan circuitos comunicativos para pasar señales codificadas binarias que actúan como instrucciones para permitir varias operaciones. Estas instrucciones pueden ser instrucciones operativas y/o de datos que contengan y/o hagan referencia a otras instrucciones y datos en varias áreas accesibles y operables del procesador de la memoria 429 (por ejemplo, registros, memoria caché, memoria de acceso aleatorio, etc.). Dichas instrucciones comunicativas pueden almacenarse y/o transmitirse en lotes (por ejemplo, lotes de instrucciones) como programas y/o componentes de datos para facilitar las operaciones deseadas. Estos códigos de instrucciones almacenados, por ejemplo, programas, pueden activar los componentes del circuito de la CPU y otros componentes de la placa base y/o del sistema para realizar las operaciones deseadas. Un tipo de programa es un sistema operativo de ordenador, que puede ser ejecutado por la CPU en un ordenador; el sistema operativo habilita y facilita a los usuarios acceder y operar recursos y tecnología de la información informática. Algunos recursos que pueden emplearse en los sistemas de tecnología de la información incluyen: mecanismos de entrada y salida a través de los cuales los datos pueden entrar y salir de un ordenador; almacenamiento de memoria en el que se pueden guardar datos; y procesadores por los cuales la información puede ser procesada. Estos sistemas de tecnología de la información pueden usarse para recopilar datos para su posterior recuperación, análisis y manipulación, lo que puede facilitarse a través de un programa de base de datos. Estos sistemas de tecnología de la información proporcionan interfaces que permiten a los usuarios acceder y operar varios componentes del sistema.

En una realización, el controlador de MRM 401 puede conectarse y/o comunicarse con entidades tales como, entre otras: uno o más usuarios de dispositivos de entrada de usuario 411; dispositivos periféricos 412; un dispositivo procesador criptográfico opcional 428; y/o una red de comunicaciones 413. Por ejemplo, el controlador de MRM 401 puede estar conectado y/o comunicarse con los usuarios, por ejemplo, 433a, operar dispositivo(s) de cliente, por ejemplo, 433b, incluyendo, pero sin limitarse a, ordenador(es) personal(es), servidor(es) y/o varios dispositivos móviles, incluidos, entre otros, teléfonos celulares, teléfonos inteligentes (por ejemplo, iPhone®, Blackberry®, teléfonos con sistema operativo Android, etc.), tabletas (por ejemplo, Apple iPad™, HP Slate™, Motorola Xoom™, etc.), lectores de libros electrónicos (por ejemplo, Amazon Kindle™, Barnes and Noble's Nook™ eReader, etc.), ordenador(es) portátil(es), notebook(s), netbook(s), consola(s) de juegos (por ejemplo, XBOX Uve™, Nintendo® DS, Sony PlayStation® Portable, etc.), escáner(es) portátil(es) y/o similares.

Comúnmente se piensa que las redes comprenden la interconexión e interoperación de clientes, servidores y nodos intermediarios en una topología gráfica. Cabe señalar que el término "servidor", como se usa en esta solicitud, se refiere generalmente a un ordenador, otro dispositivo, programa o combinación de los mismos que procesa y responde a las solicitudes de usuarios remotos a través de una red de comunicaciones. Los servidores sirven su información a los "clientes" que la solicitan. El término "cliente", tal como se usa en este documento, se refiere generalmente a un ordenador, programa, otro dispositivo, usuario y/o combinación de los mismos que es capaz de procesar y realizar solicitudes y obtener y procesar cualquier respuesta de los servidores a través de una red de comunicaciones. Un ordenador, otro dispositivo, programa o combinación de los mismos que facilita, procesa información y solicitudes, y/o promueve el paso de información de un usuario de origen a un usuario de destino se denomina comúnmente "nodo". En general, se cree que las redes facilitan la transferencia de información desde los puntos de origen a los destinos. Un nodo encargado específicamente de promover el paso de información desde un origen a un destino se denomina comúnmente "enrutador". Existen muchas formas de redes, como redes de área local (LAN), redes Pico, redes de área amplia (WAN), redes inalámbricas (WLAN), etc. Por ejemplo, Internet se acepta generalmente como una interconexión de una multitud de redes mediante el cual los clientes y servidores remotos pueden acceder e interoperar entre sí.

El controlador de MRM 401 puede basarse en sistemas informáticos que pueden comprender, entre otros, componentes tales como: una sistematización informática 402 conectada a la memoria 429.

Sistematización Informática

Una sistematización informática 402 puede comprender un reloj 430, una unidad central de procesamiento ("CPU(s)" y/o "procesador(es)" (estos términos se usan indistintamente a lo largo de la divulgación a menos que se indique lo contrario)) 403, una memoria 429 (por ejemplo, una memoria de solo lectura (ROM) 406, una memoria de acceso aleatorio (RAM) 405, etc.), y/o un bus de interfaz 407, y con mayor frecuencia, aunque no necesariamente, todos están interconectados y/o se comunican a través de un bus de sistema 404 en una o más placas base (madre) 402 que tienen rutas de circuito conductoras y/o de transporte a través de las cuales pueden viajar instrucciones (por ejemplo, señales codificadas en binario) para efectuar comunicaciones, operaciones, almacenamiento, etc. La sistematización informática puede estar conectada a una fuente de alimentación 486; por ejemplo, opcionalmente la fuente de alimentación puede ser interna. Opcionalmente, un procesador criptográfico 426 y/o transceptores (por ejemplo, circuitos integrados, IC) 474 pueden conectarse al bus del sistema. En otra realización, el procesador criptográfico y/o los transceptores pueden conectarse como dispositivos periféricos internos y/o externos 412 a través del bus de interfaz de entrada/salida (E/S, I/O). A su vez, los transceptores pueden conectarse a la(s) antena(s) 475, efectuando así la transmisión y recepción inalámbrica de varios protocolos de comunicación y/o sensor; por ejemplo, la(s) antena(s) puede(n) conectarse a: un chip transceptor WiLink WL1283 de Texas Instruments (por ejemplo, proporcionando 802.11n, Bluetooth 3.0, FM, sistema de posicionamiento global (GPS) (permitiendo así que el controlador de MRM determine su ubicación)); Chip transceptor Broadcom BCM4329FKUBG (por ejemplo, proporciona 802.11n, Bluetooth 2.1 EDR, FM, etc.), BCM28150 (HSPA) y BCM2076 (Bluetooth 4.0, GPS, etc.); un chip receptor Broadcom BCM4750IUB8 (por ejemplo, GPS); un Infineon Technologies X-Gold 618-PMB9800 (por ejemplo., que proporciona comunicaciones 2G/3G HSDPA/HSUPA); XMM 7160 de Intel (LTE y DC-HSPA), CDMA de Qualcom (2000), módem de estación/datos móviles, Snapdragon; y/o similares. El reloj del sistema puede tener un oscilador de cristal y genera una señal base a través de las vías del circuito de sistematización del ordenador. El reloj puede estar acoplado al bus del sistema y varios multiplicadores de reloj que aumentarán o disminuirán la frecuencia operativa base para otros componentes interconectados en la sistematización informática. El reloj y varios componentes en una sistematización informática manejan señales que incorporan información en todo el sistema. Dicha transmisión y recepción de instrucciones que incorporan información a través de una sistematización informática puede denominarse comunicaciones. Estas instrucciones comunicativas pueden además transmitirse, recibirse y pueden comprender comunicaciones de retorno y/o respuesta más allá de la sistematización informática instantánea a: redes de comunicaciones, dispositivos de entrada, otras sistematizaciones informáticas, dispositivos periféricos y/o similares. Debe entenderse que, en realizaciones alternativas, cualquiera de los componentes anteriores puede conectarse directamente entre sí, conectarse a la CPU y/u organizarse en numerosas variaciones empleadas, como lo ejemplifican varios sistemas informáticos.

La CPU comprende al menos un procesador de datos de alta velocidad adecuado para ejecutar componentes de programa para ejecutar solicitudes generadas por el usuario y/o el sistema. A menudo, los propios procesadores incorporarán varias unidades de procesamiento especializadas, tales como, entre otras: unidades de coma/punto flotante, unidades de procesamiento de enteros, controladores de sistemas integrados (bus), unidades de operaciones lógicas, unidades de control de gestión de memoria, etc., e incluso subunidades de procesamiento como unidades de procesamiento de gráficos, unidades de procesamiento de señales digitales y/o similares. Además, los procesadores pueden incluir una memoria interna direccionable de acceso rápido y ser capaces de mapear y direccionar la memoria 429 más allá del propio procesador; la memoria interna puede incluir, entre otros: registros rápidos, varios niveles de memoria caché (por ejemplo, nivel 1,2, 3, etc.), RAM, etc. El procesador puede acceder a esta memoria mediante el uso de un espacio de dirección de memoria al que se puede acceder a través de la dirección de instrucción, que el procesador puede construir y decodificar, lo que le permite acceder a una ruta de circuito a un espacio de dirección de memoria específico que tiene un estado/valor de memoria. La CPU puede ser un microprocesador como: Athlon, Duron y/o Opteron de AMD; Procesadores clásicos (por ejemplo, ARM7/9/11), integrados (Cortex-M/R), de aplicación (Cortex-A) y seguros de ARM; DragonBall de Motorola y/o PowerPC de IBM; el procesador Cell de IBM y Sony; Intel Atom, Celeron (móvil), Core (2/Duo/i3/i5/i7), Itanium, Pentium, Xeon y/o XScale; y/o procesador(es) similar(es). La CPU interactúa con la memoria a través de instrucciones que pasan a través de conductos conductores y/o de transporte (por ejemplo, circuitos ópticos y/o electrónicos (impresos)) para ejecutar instrucciones almacenadas (es decir, código de programa). Tal paso de instrucciones facilita la comunicación dentro del controlador de MRM y más allá a través de varias interfaces. En caso de que los requisitos de procesamiento dicten una mayor cantidad de velocidad y/o capacidad, se pueden emplear arquitecturas de procesadores distribuidos (por ejemplo, Distributed MRM), mainframe, multinúcleo, paralelo y/o de superordenadores. Alternativamente, si los requisitos de implementación exigen una mayor portabilidad, se pueden emplear dispositivos móviles más pequeños (por ejemplo, teléfonos inteligentes, asistentes personales digitales (PDA), etc.).

Dependiendo de la implementación particular, las características del MRM pueden lograrse implementando un microcontrolador como el microcontrolador R8051XC2 de CAST; MCS 51 de Intel (es decir, microcontrolador 8051); y/o similares. Además, para implementar ciertas funciones del MRM, algunas implementaciones de funciones pueden basarse en componentes integrados, como: Circuito integrado de aplicación específica ("ASIC"), procesamiento de señales digitales ("DSP"), arreglo de compuertas programable en campo ("FPGA") y/o tecnología integrada similar. Por ejemplo, cualquiera de la colección de componentes de MRM (distribuidos o no, por ejemplo, IMAS 341, etc.) y/o funciones pueden implementarse mediante el microprocesador y/o mediante componentes integrados; por ejemplo, a través de ASIC, coprocesador, DSP, FPGA y/o similares. Alternativamente, algunas implementaciones del MRM pueden implementarse con componentes incorporados que se configuran y utilizan para lograr una variedad de características o procesamiento de señales.

Dependiendo de la implementación particular, los componentes incorporados pueden incluir soluciones de software, soluciones de hardware y/o alguna combinación de ambas soluciones de hardware/software. Por ejemplo, las características de MRM discutidas aquí pueden lograrse mediante la implementación de FPGA, que son dispositivos semiconductores que contienen componentes lógicos programables llamados "bloques lógicos" e interconexiones programables, como la serie FPGA Virtex de alto rendimiento y/o la serie Spartan de bajo costo fabricada por Xilinx. El cliente o el diseñador puede programar los bloques lógicos y las interconexiones, después de fabricar la FPGA, para implementar cualquiera de las características de MRM. Una jerarquía de interconexiones programables permite que los bloques lógicos se interconecten según lo necesite el diseñador/administrador del sistema MRM, algo así como una placa de prueba programable de un chip. Los bloques lógicos de una FPGA se pueden programar para realizar la operación de puertas lógicas básicas como AND y XOR, u operadores combinacionales más complejos como decodificadores u operaciones matemáticas simples. En la mayoría de los FPGA, los bloques lógicos también incluyen elementos de memoria, que pueden ser circuitos biestables o bloques de memoria más completos. En algunas circunstancias, el MRM puede desarrollarse en FPGA normales y luego migrarse a una versión fija que se parece más a las implementaciones de ASIC. Las implementaciones alternativas o coordinadas pueden migrar las funciones del controlador de MRM a un ASIC final en lugar de o además de los FPGA. Dependiendo de la implementación, todos los componentes integrados y microprocesadores antes mencionados pueden considerarse la "CPU" y/o el "procesador" para el MRM.

Fuente de alimentación

La fuente de alimentación 486 puede ser de cualquier forma estándar para alimentar pequeños dispositivos de placa de circuito electrónico tales como las siguientes celdas de energía: alcalina, hidruro de litio, iones de litio, polímero de litio, níquel cadmio, celdas solares y/o similares. También se pueden utilizar otros tipos de fuentes de alimentación de CA o CC. En el caso de las celdas solares, en una realización, la carcasa proporciona una abertura a través de la cual la celda solar puede capturar energía fotónica. La celda de energía 486 está conectada a al menos uno de los componentes subsiguientes interconectados del MRM proporcionando así una corriente eléctrica a todos los componentes interconectados. En un ejemplo, la fuente de alimentación 486 está conectada al componente de bus del sistema 404. En una realización alternativa, se proporciona una fuente de alimentación externa 486 a través de una conexión a través de la interfaz E/S 408. Por ejemplo, una conexión USB y/o IEEE 1394 transporta datos y energía a través de la conexión y, por lo tanto, es una fuente de energía adecuada.

Adaptadores de interfaz

Los buses de interfaz 407 pueden aceptar, conectarse y/o comunicarse con varios adaptadores de interfaz, con frecuencia, aunque no necesariamente en forma de tarjetas adaptadoras, tales como, entre otros: interfaces de entrada y salida (E/S) 408, interfaces de almacenamiento 409, interfaces de red 410 y/o similares. Opcionalmente, las interfaces de procesador criptográfico 427 pueden conectarse de manera similar al bus de interfaz. El bus de interfaz proporciona la comunicación de los adaptadores de interfaz entre sí, así como con otros componentes de la sistematización informática. Los adaptadores de interfaz están adaptados para un bus de interfaz compatible. Los adaptadores de interfaz pueden conectarse al bus de interfaz a través de una arquitectura de expansión y/o ranura. Se pueden emplear varias arquitecturas de expansión y/o ranuras, tales como, entre otras: Puerto de gráficos acelerado (AGP), Bus de tarjeta, ExpressCard, Arquitectura estándar de la industria (extendida) ((E)ISA), Arquitectura de microcanal (MCA), NuBus, Interconexión de componentes periféricos (extendida) (PCI(X)), PCI Express, Asociación Internacional de Tarjetas de Memoria para Ordenadores Personales (PCMCIA), Thunderbolt y/o similares.

Las interfaces de almacenamiento 409 pueden aceptar, comunicarse y/o conectarse a una serie de dispositivos de almacenamiento tales como, entre otros: dispositivos de almacenamiento 414, dispositivos de disco extraíbles y/o similares. Las interfaces de almacenamiento pueden emplear protocolos de conexión como, entre otros: (Ultra) (Serie) Accesorio de tecnología avanzada (interfaz de paquetes) ((Ultra) (Serie) ATA(PI)), Electrónica de unidad integrada (mejorada) ((E)IDE), Instituto de ingenieros eléctricos y electrónicos (IEEE) 1394, Ethernet, canal de fibra, interfaz de sistemas informáticos pequeños (SCSI), Thunderbolt, bus de serie universal (USB) y/o similares.

Las interfaces de red 410 pueden aceptar, comunicarse y/o conectarse a una red de comunicaciones 413. A través de una red de comunicaciones 413, los usuarios 433a pueden acceder al controlador de MRM a través de clientes remotos 433b (por ejemplo, ordenadores con navegadores web). Las interfaces de red pueden emplear protocolos de conexión como, entre otros: conexión directa, Ethernet (grueso, delgado, par trenzado 10/100/1000 Base T y/o similar), Token Ring, conexión inalámbrica como IEEE 802.11a-x , y/o similares. Si los requisitos de procesamiento dictan una mayor cantidad de velocidad y/o capacidad, las arquitecturas de controlador de red distribuida (por ejemplo, Distributed 4) pueden emplearse de manera similar para agrupar, equilibrar la carga y/o aumentar el ancho de banda comunicativo requerido por el controlador de MRM. Una red de comunicaciones puede ser cualquiera y/o la combinación de las siguientes: una interconexión directa; la Internet; una red de área local (LAN); una Red de Área Metropolitana (MAN); una Misión Operativa como Nodos en Internet (OMNI); una conexión personalizada segura; una red de área amplia (WAN); una red inalámbrica (por ejemplo, que emplea protocolos tales como, entre otros, un Protocolo de aplicación inalámbrica (WAP), modo I y/o similares); y/o similares. Una interfaz de red puede considerarse como una forma especializada de una interfaz de entrada y salida. Además, se pueden usar múltiples interfaces de red 410 para interactuar con varios tipos de redes de comunicaciones 413. Por ejemplo, pueden emplearse múltiples interfaces de red para permitir la comunicación a través de redes de difusión, multidifusión y/o unidifusión.

Las interfaces de entrada y salida (E/S) 408 pueden aceptar, comunicarse y/o conectarse a dispositivos de entrada de usuario 411, dispositivos periféricos 412, dispositivos de procesador criptográfico 428 y/o similares. Las E/S pueden emplear protocolos de conexión como, entre otros: datos de audio: analógico, digital, monoaural, RCA, estéreo y/o similares: Apple Desktop Bus (ADB), Bluetooth, IEEE 1394a-b, serie, bus de serie universal (USB); infrarrojo; palanca de mando; teclado; medio; óptico; PC AT; PS/2; paralelos; radio; interfaz de vídeo: Apple Desktop Connector (ADC), BNC, coaxial, componente, compuesto, digital, Display-Port, interfaz visual digital (DVI), interfaz multimedia de alta definición (HDMI), RCA, antenas RF, S-Video, VGA y/ o similar; transceptores inalámbricos: 802.11a/b/g/n/x; Bluetooth; celular (por ejemplo, acceso múltiple por división de código (CDMA), acceso a paquetes de alta velocidad (HSPA(+)), acceso a paquetes de enlace descendente de alta velocidad (HSDPA), sistema global para comunicaciones móviles (GSM), evolución a largo plazo (LTE), WiMax, etc.); y/o similares. Un dispositivo de salida puede ser una pantalla de video, que puede tomar la forma de un tubo de rayos catódicos (CRT), pantalla de cristal líquido (LCD), diodo emisor de luz (LED), diodo emisor de luz orgánico (OLED), plasma y/o el monitor similar con una interfaz (por ejemplo, VGA, circuito y cable DVI) que acepta señales de una interfaz de video. La interfaz de video compone información generada por una sistematización informática y genera señales de video basadas en la información compuesta en un marco de memoria de video. Otro dispositivo de salida es un televisor, que acepta señales de una interfaz de video. A menudo, la interfaz de video proporciona la información de video compuesta a través de una interfaz de conexión de video que acepta una interfaz de pantalla de video (por ejemplo, un conector de video compuesto RCA que acepta un cable de video compuesto RCA; un conector DVI que acepta un cable de pantalla DVI, HDMI, etc.) .

Los dispositivos de entrada de usuario 411 a menudo son un tipo de dispositivo periférico 412 (ver a continuación) y pueden incluir: lectores de tarjetas, dongles, lectores de huellas digitales, guantes, tabletas gráficas, palancas de mando, teclados, micrófonos, ratón (ratones), controles remotos, lectores de retina, pantallas táctiles (por ejemplo, capacitivas, resistivas, etc.), bolas de seguimiento, paneles de seguimiento, sensores (por ejemplo, acelerómetros, de luz ambiental, GPS, giroscopios, de proximidad, etc.), lápices ópticos y/o similares.

Los dispositivos periféricos 412 pueden conectarse y/o comunicarse con E/S y/u otras instalaciones similares, como interfaces de red, interfaces de almacenamiento, directamente al bus de interfaz, bus del sistema, la CPU y/o similares. Los dispositivos periféricos pueden ser externos, internos y/o parte del controlador de MRM. Los dispositivos periféricos pueden incluir: antenas, dispositivos de audio (por ejemplos, entrada de línea, salida de línea, entrada de micrófono, parlantes, etc.), cámaras (por ejemplos, fijas, de video, cámara web, etc.), dongles (por ejemplos, para protección contra copia, lo que garantiza transacciones seguras con una firma digital y/o similares), procesadores externos (para capacidades adicionales; por ejemplo, dispositivos criptográficos 428), dispositivos de retroalimentación forzada (por ejemplo, motores vibratorios), dispositivos de comunicación de campo cercano (NFC), dispositivos de interfaces de red, impresoras, identificadores de radiofrecuencia (RFID), escáneres, dispositivos de almacenamiento, transceptores (por ejemplos, celular, GPS, etc.), dispositivos de video (por ejemplos, gafas, monitores, etc.), fuentes de video, visores y/o similares. Los dispositivos periféricos a menudo incluyen tipos de dispositivos de entrada (por ejemplo, micrófonos, cámaras, etc.).

Cabe señalar que, aunque se pueden emplear dispositivos de entrada de usuario y dispositivos periféricos, el controlador de MRM puede incorporarse como un dispositivo integrado, dedicado y/o sin monitor (es decir, sin cabezal), donde el acceso se proporcionaría a través de una conexión de interfaz de red.

Las unidades criptográficas tales como, pero no limitadas a, microcontroladores, procesadores 426, interfaces 427 y/o dispositivos 428 pueden conectarse y/o comunicarse con el controlador de MRM. Un microcontrolador MC68HC16, fabricado por Motorola Inc., puede usarse para y/o dentro de unidades criptográficas. El microcontrolador MC68HC16 utiliza una instrucción de multiplicación y acumulación de 16 bits en la configuración de 16 MHz y requiere menos de un segundo para realizar una operación de clave privada RSA de 512 bits. Las unidades criptográficas admiten la autenticación de las comunicaciones de los agentes que interactúan, además de permitir transacciones anónimas. Las unidades criptográficas también se pueden configurar como parte de la CPU. También pueden usarse microcontroladores y/o procesadores equivalentes. Otros procesadores criptográficos especializados disponibles comercialmente incluyen: CryptoNetX de Broadcom y otros procesadores de seguridad; nShield de nCipher (por ejemplo, Solo, Connect, etc.), serie Luna PCI de SafeNet (por ejemplo, 7100); Roadrunner 184 de 40 MHz de Semaphore Communications; sMIP (por ejemplo, 208956); Aceleradores criptográficos de Sun (por ejemplo, Tarjeta Accelerator 6000 PCIe, Tarjeta Secundaria Accelerator 500); / (por ejemplo, L2100, L2200, U2400), que es capaz de realizar 500+ MB/s de instrucciones criptográficas; 33 MHz 6868 de VLSI Technology; y/o similares.

Memoria

En general, cualquier mecanización y/o realización que permita que un procesador afecte el almacenamiento y/o la recuperación de información se considera memoria 429. Sin embargo, la memoria es una tecnología y un recurso fungible, por lo tanto, se puede emplear cualquier número de realizaciones de memoria en lugar de o en concierto entre sí. Debe entenderse que el controlador de ^m R^m y/o una sistematización informática pueden emplear diversas formas de memoria 429. Por ejemplo, se puede configurar una sistematización informática donde el funcionamiento de la memoria de la CPU en el chip (por ejemplo, los registros), la RAM, la ROM y cualquier otro dispositivo de almacenamiento se proporciona mediante un mecanismo de cinta perforada de papel o tarjeta perforada de papel; sin embargo, tal realización daría como resultado una velocidad de operación extremadamente lenta. En una configuración, la memoria 429 incluirá la ROM 406, la RAM 405 y un dispositivo de almacenamiento 414. Un dispositivo de almacenamiento 414 puede emplear cualquier número de dispositivos/sistemas de almacenamiento informático. Los dispositivos de almacenamiento pueden incluir un tambor; una unidad de disco magnético (fija y/o extraíble); un accionamiento magnetoóptico; una unidad óptica (es decir, Bluray, CD ROM/RAM/Grabable (R)/Reescribible (RW), D^v D R/RW, HD DVD R/RW, etc.); un arreglo de dispositivos (por ejemplo, arreglo redundante de discos independientes (RAID)); dispositivos de memoria de estado sólido (memoria u Sb , unidades de estado sólido (SSD), etc.); otros medios de almacenamiento legibles por procesador; y/u otros dispositivos similares. Así, una sistematización informática generalmente requiere y hace uso de la memoria.

Colección de componentes

La memoria 429 puede contener una colección de programas y/o componentes de base de datos y/o datos tales como, pero no limitados a: componente(s) del sistema operativo 415 (sistema operativo); componente(s) del servidor de información 416 (servidor de información); componente(s) de interfaz de usuario 417 (interfaz de usuario); componente(s) del navegador web 418 (navegador web); bases de datos 419; componente(s) del servidor de correo 421; componente(s) de cliente de correo 422; componente(s) del servidor criptográfico 420 (servidor criptográfico); el(los) componente(s) MRM 435; y/o similares (es decir, colectivamente una colección de componentes). Estos componentes pueden almacenarse y accederse desde los dispositivos de almacenamiento y/o desde los dispositivos de almacenamiento accesibles a través de un bus de interfaz. Aunque los componentes de programas no convencionales, como los de la colección de componentes, pueden almacenarse en un dispositivo de almacenamiento local 414, también pueden cargarse y/o almacenarse en la memoria, como: dispositivos periféricos, RAM, instalaciones de almacenamiento remoto a través de una red de comunicaciones, ROM, varias formas de memoria, y/o similares.

Sistema operativo

El componente de sistema operativo 415 es un componente de programa ejecutable que facilita la operación del controlador de MRM. El sistema operativo puede facilitar el acceso a E/S, interfaces de red, dispositivos periféricos, dispositivos de almacenamiento y/o similares. El sistema operativo puede ser un sistema altamente tolerante a fallas, escalable y seguro como: Apple Macintosh OS X (servidor); Plan 9 de AT&T; Be OS; Distribuciones de sistemas Unix y similares a Unix (como UNIX de AT&T; variaciones de Berkley Software Distribution (BSD) como FreeBSD, NetBSD, OpenBSD y/o similares; distribuciones de Linux como Red Hat, Ubuntu y/o similares); y/o sistemas operativos similares. Sin embargo, también se pueden emplear sistemas operativos más limitados y/o menos seguros, como Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (Servidor), Palm OS y/o similares. Además, se pueden emplear sistemas operativos móviles como iOS de Apple, Android de Google, WebOS de Hewlett Packard, Windows Mobile de Microsoft y/o similares. Cualquiera de estos sistemas operativos puede integrarse en el hardware del controlador de MRM y/o almacenarse/cargarse en la memoria/almacenamiento. Un sistema operativo puede comunicarse con y/o con otros componentes en una colección de componentes, incluido él mismo y/o similares. Lo más frecuente es que el sistema operativo se comunique con otros componentes del programa, interfaces de usuario y/o similares. Por ejemplo, el sistema operativo puede contener, comunicar, generar, obtener y/o proporcionar componentes de programa, sistema, usuario y/o comunicaciones de datos, solicitudes y/o respuestas. El sistema operativo, una vez ejecutado por la CPU, puede permitir la interacción con redes de comunicaciones, datos, E/S, dispositivos periféricos, componentes de programa, memoria, dispositivos de entrada de usuario y/o similares. El sistema operativo puede proporcionar protocolos de comunicaciones que permitan que el controlador de MRM se comunique con otras entidades a través de una red de comunicaciones 413. El controlador de MRM puede utilizar varios protocolos de comunicación como un mecanismo de transporte de subportadora para la interacción, tales como, entre otros: multidifusión, TCP/IP, UDP, unidifusión y/o similares.

Servidor de información

Un componente de servidor de información 416 es un componente de programa almacenado que es ejecutado por una CPU. El servidor de información puede ser un servidor de información de Internet como, entre otros, Apache de Apache Software Foundation, Internet Information Server de Microsoft y/o similares. El servidor de información puede permitir la ejecución de componentes del programa a través de recursos tales como Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# y/o .n Et , scripts de Common Gateway Interface (CGI), lenguaje de marcado de hipertexto dinámico (D) (HTML), FLASH, Java, JavaScript, lenguaje práctico de informes de extracción (PERL), preprocesador de hipertexto (PHP), pipes, Python, protocolo de aplicación inalámbrica (WAP), WebObjects y/o similares. El servidor de información puede admitir protocolos de comunicaciones seguras como, entre otros, el Protocolo de transferencia de archivos (FTP); Protocolo de transferencia de hipertexto (HTTP); Protocolo seguro de transferencia de hipertexto (HTTPS), Secure Socket Layer (SSL), protocolos de mensajería (por ejemplo, America Online (AOL) Instant Messenger (AIM), iMessage de Apple, Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Servicio de mensajería de red de Microsoft(MSN), Protocolo de mensajería instantánea y de presencia (PRIM), Protocolo de inicio de sesión (SIP) del Grupo de trabajo de ingeniería de Internet (IETF), SIP para mensajería instantánea y Extensiones de aprovechamiento de presencia (SIMPLE), Protocolo Extensible de Mensajería y Presencia (XMPP) basado en XML abierto (es decir, Jabber o el Servicio de Mensajería Instantánea y Presencia (IMPS) de la Open Mobile Alliance (OMA)), Servicio de Mensajería Instantánea de Yahoo!, y/o similares. El servidor de información proporciona resultados en forma de páginas web a los navegadores web y permite la generación manipulada de las páginas web a través de la interacción con otros componentes del programa. Después de que una porción de la resolución del Sistema de nombres de dominio (DNS) de una solicitud HTTP se resuelva en un servidor de información particular, el servidor de información resuelve las solicitudes de información en ubicaciones específicas en el controlador de MRM con base en el resto de la solicitud HTTP. Por ejemplo, una solicitud como http://123.124.125.126/my- Information.html podría tener la porción de IP de la solicitud "123.124.125.126" resuelta por un servidor DNS a un servidor de información en esa dirección IP; ese servidor de información podría, a su vez, analizar aún más la solicitud http para la porción 7mylnformation.html" de la solicitud y resolverla en una ubicación en la memoria que contenga la información "mylnformation.html". Además, se pueden emplear otros protocolos de servicio de información a través de varios puertos, por ejemplo, comunicaciones FTP a través del puerto 21 y/o similares. Un servidor de información puede comunicarse con y/o con otros componentes en una colección de componentes, incluido él mismo y/o instalaciones similares. Lo más frecuente es que el servidor de información se comunique con la base de datos 419 de MRM, los sistemas operativos, otros componentes del programa, las interfaces de usuario, los navegadores web y/o similares.

El acceso a la base de datos MRM se puede lograr a través de una serie de mecanismos puente de base de datos, como a través de lenguajes de secuencias de comandos como se enumeran a continuación (por ejemplo, CGI) y a través de canales de comunicación entre aplicaciones como se enumeran a continuación (por ejemplo, CORBA, WebObjects, etc.). Todas las solicitudes de datos a través de un navegador web se analizan a través del mecanismo de puente en las gramáticas apropiadas según lo requiera el MRM. En una realización, el servidor de información proporcionaría un formulario web accesible mediante un navegador web. Las entradas realizadas en los campos proporcionados en el formulario web se etiquetan como si se hubieran ingresado en los campos particulares y se analizan como tales. Los términos ingresados luego se pasan junto con las etiquetas de campo, que actúan para indicarle al analizador que genere consultas dirigidas a las tablas y/o campos apropiados. En una realización, el analizador puede generar consultas en SQL estándar instanciando una cadena de búsqueda con los comandos de combinación/selección adecuados basados en las entradas de texto etiquetadas, donde el comando resultante se proporciona a través del mecanismo de puente al MRM como una consulta. Al generar los resultados de la consulta a partir de la consulta, los resultados pasan por el mecanismo de puente y pueden analizarse para formatear y generar una nueva página web de resultados mediante el mecanismo de puente. A continuación, dicha página web de nuevos resultados se proporciona al servidor de información, que puede suministrarla al navegador web solicitante.

Además, un servidor de información puede contener, comunicar, generar, obtener y/o proporcionar componentes de programa, sistemas, usuarios y/o comunicaciones de datos, solicitudes y/o respuestas.

Interfaz de usuario

Las interfaces de ordenador en algunos aspectos son similares a las interfaces de operación de automóviles. Los elementos de la interfaz de operación del automóvil, como volantes, cambios de marcha y velocímetros, facilitan el acceso, la operación y la visualización de los recursos y el estado del automóvil. Los elementos de la interfaz de interacción con el ordenador, como casillas de verificación, cursores, menús, desplazadores y ventanas (denominados en conjunto y comúnmente como widgets), facilitan de manera similar el acceso, las capacidades, la operación y la visualización de datos y los recursos y estado del sistema operativo y hardware del ordenador. Las interfaces de operación se denominan comúnmente interfaces de usuario. Interfaces gráficas de usuario (GUI) como Aqua del sistema operativo Apple Macintosh y Cocoa Touch de iOS, OS/2 de IBM, interfaz de usuario móvil Android de Google, Windows 2000/2003/3.1/95/98/CE/MÍNenium/Mobile/NT/XPNista de Microsoft /7/8 (es decir, Aero, Metro), X-Windows de Unix (por ejemplo, que puede incluir bibliotecas y capas adicionales de interfaz gráfica de Unix como K Desktop Environment (KDE), mythTV y GNU Network Object Model Environment (GNOME)), bibliotecas de interfaz web (por ejemplo, ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc. bibliotecas de interfaz como, entre otras, Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject, interfa de usuario de Yahoo!, cualquiera de ellas puede ser utilizada y proporcionar una línea de base y medios de acceso y visualización de la información gráficamente a los usuarios.

Un componente de interfaz de usuario 417 es un componente de programa almacenado que es ejecutado por una CPU. La interfaz de usuario puede ser una interfaz de usuario gráfica proporcionada por, con y/o sobre sistemas operativos y/o entornos operativos como los ya discutidos. La interfaz de usuario puede permitir la visualización, ejecución, interacción, manipulación y/u operación de componentes de programa y/o funciones del sistema a través de funciones textuales y/o gráficas. La interfaz de usuario proporciona una facilidad a través de la cual los usuarios pueden afectar, interactuar y/u operar un sistema informático. Una interfaz de usuario puede comunicarse con y/o con otros componentes en una colección de componentes, incluida ella misma y/o instalaciones similares. Lo más frecuente es que la interfaz de usuario se comunique con los sistemas operativos, otros componentes del programa y/o similares. La interfaz de usuario puede contener, comunicar, generar, obtener y/o proporcionar componentes de programa, sistemas, usuarios y/o comunicaciones de datos, solicitudes y/o respuestas.

Navegador de red

Un componente de navegador de red 418 es un componente de programa almacenado que es ejecutado por una CPU. El navegador de red puede ser una aplicación de visualización de hipertexto como Chrome (móvil) de Google, Microsoft Internet Explorer, Netscape Navigator, Safari (móvil) de Apple, objetos de navegador de red integrados como la clase de objeto Cocoa (táctil) de Apple y/o similares. La navegación de red segura se puede proporcionar con un cifrado de 128 bits (o superior) a través de HTTPS, SSL y/o similar. Los navegadores de red que permiten la ejecución de componentes de programas a través de instalaciones como ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, complementos API de navegadores web (por ejemplo, complemento de Chrome, FireFox, Internet Explorer, Safari y/o las API similares) y/o similares. Los navegadores de red y herramientas de acceso a la información similares pueden integrarse en ^p D^a , teléfonos celulares, teléfonos inteligentes y/u otros dispositivos móviles. Un navegador web puede comunicarse hacia y/o con otros componentes en una colección de componentes, incluido él mismo y/o instalaciones similares. Con mayor frecuencia, el navegador de red se comunica con servidores de información, sistemas operativos, componentes de programas integrados (por ejemplo, complementos) y/o similares; por ejemplo, puede contener, comunicar, generar, obtener y/o proporcionar componentes de programa, sistemas, usuarios y/o comunicaciones de datos, solicitudes y/o respuestas. Además, en lugar de un navegador web y un servidor de información, se puede desarrollar una aplicación combinada para realizar operaciones similares de ambos. La aplicación combinada efectuaría de manera similar la obtención y el suministro de información a usuarios, agentes de usuario y/o similares desde los nodos equipados con MRM. La aplicación combinada puede ser inútil en sistemas que emplean navegadores web estándar.

Servidor de correo

Un componente de servidor de correo 421 es un componente de programa almacenado que es ejecutado por una CPU 403. El servidor de correo puede ser un servidor de correo de Internet como, entre otros, el servidor de correo de Apple (3), dovecot, sendmail, Microsoft Exchange y/o similares. El servidor de correo puede permitir la ejecución de componentes del programa a través de recursos como ASP, ActiveX, (ANSI) (Objective-) C (++), C# y/o .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects y/o similares. El servidor de correo puede admitir protocolos de comunicación como, entre otros: Protocolo de acceso a mensajes de Internet (IMAP), interfaz de programación de aplicaciones de mensajería (MAPI)/Microsoft Exchange, protocolo de oficina de correos (POP3), protocolo de transferencia de correo simple (SMTP) y/o similares. El servidor de correo puede enrutar, reenviar y procesar mensajes de correo entrantes y salientes que han sido enviados, retransmitidos y/o de otro modo atravesados a través y/o hacia el MRM.

El acceso al correo MRM se puede lograr a través de una serie de API ofrecidas por los componentes individuales del servidor de red y/o el sistema operativo.

Además, un servidor de correo puede contener, comunicar, generar, obtener y/o proporcionar componentes de programas, sistemas, usuarios y/o comunicaciones de datos, solicitudes, información y/o respuestas.

Cliente de correo

Un componente de cliente de correo 422 es un componente de programa almacenado que es ejecutado por una CPU 403. El cliente de correo puede ser una aplicación de visualización de correo como Apple (Mobile) Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird y/o similares. Los clientes de correo pueden admitir varios protocolos de transferencia, como: IMAP, Microsoft Exchange, POP3, SMTP y/o similares. Un cliente de correo puede comunicarse hacia y/o con otros componentes en una colección de componentes, incluido él mismo y/o instalaciones similares. Lo más frecuente es que el cliente de correo se comunique con servidores de correo, sistemas operativos, otros clientes de correo y/o similares; por ejemplo, puede contener, comunicar, generar, obtener y/o proporcionar componentes de programa, sistemas, usuarios y/o comunicaciones de datos, solicitudes, información y/o respuestas. Generalmente, el cliente de correo proporciona una facilidad para redactar y transmitir mensajes de correo electrónico.

Servidor criptográfico

Un componente de servidor criptográfico 420 es un componente de programa almacenado que es ejecutado por una CPU 403, un procesador criptográfico 426, una interfaz de procesador criptográfico 427, un dispositivo de procesador criptográfico 428 y/o similares. Las interfaces del procesador criptográfico permitirán la expedición de solicitudes de cifrado y/o descifrado por parte del componente criptográfico; sin embargo, el componente criptográfico, alternativamente, puede ejecutarse en una CPU. El componente criptográfico permite el cifrado y/o descifrado de los datos proporcionados. El componente criptográfico permite el cifrado y/o descifrado tanto simétrico como asimétrico (por ejemplo, Pretty Good Protection (PGP)). El componente criptográfico puede emplear técnicas criptográficas tales como, entre otras: certificados digitales (por ejemplo, marco de autenticación X.509), firmas digitales, firmas duales, ensobrado, protección de acceso con contraseña, gestión de claves públicas y/o similares. El componente criptográfico facilitará numerosos protocolos de seguridad (cifrado y/o descifrado) como, entre otros: suma de comprobación, Estándar de cifrado de datos (DES), Cifrado de curva elíptica (ECC), Algoritmo internacional de cifrado de datos (IDEA), Resumen de mensajes 5 (MD5, que es una operación hash unidireccional), contraseñas, Rivest Cipher (RC5), Rijndael, RSA (que es un sistema de cifrado y autenticación de Internet que utiliza un algoritmo desarrollado en 1977 por Ron Rivest, Adi Shamir y Leonard Adleman) , algoritmo hash seguro (SHA), capa de conexión segura (SSL), protocolo de transferencia de hipertexto seguro (HTTPS) y/o similares. Empleando tales protocolos de seguridad de encriptación, el MRM puede encriptar todas las comunicaciones entrantes y/o salientes y puede servir como un nodo dentro de una red privada virtual (VPN) con una red de comunicaciones más amplia. El componente criptográfico facilita el proceso de "autorización de seguridad" mediante el cual se inhibe el acceso a un recurso mediante un protocolo de seguridad donde el componente criptográfico efectúa el acceso autorizado al recurso protegido. Además, el componente criptográfico puede proporcionar identificadores únicos de contenido, por ejemplo, empleando un hash MD5 para obtener una firma única para un archivo de audio digital. Un componente criptográfico puede comunicarse con y/o con otros componentes en una colección de componentes, incluido él mismo y/o instalaciones similares. El componente criptográfico admite esquemas de cifrado que permiten la transmisión segura de información a través de una red de comunicaciones para permitir que el componente MRM participe en transacciones seguras si así lo desea. El componente criptográfico facilita el acceso seguro a recursos en el MRM y facilita el acceso a recursos seguros en sistemas remotos; es decir, puede actuar como cliente y/o servidor de recursos asegurados. Lo más frecuente es que el componente criptográfico se comunique con servidores de información, sistemas operativos, otros componentes de programas y/o similares. El componente criptográfico puede contener, comunicar, generar, obtener y/o proporcionar comunicaciones de componente de programa, sistema, usuario y/o datos, solicitudes y/o respuestas.

La base de datos MRM

El componente de base de datos MRM 419 puede incorporarse en una base de datos y sus datos almacenados. La base de datos es un componente de programa almacenado, que es ejecutado por la CPU; la porción del componente del programa almacenado que configura la CPU para procesar los datos almacenados. La base de datos puede ser cualquiera de varias bases de datos seguras, escalables, relacionales y tolerantes a fallos tales como DB2, MySQL, Oracle, Sybase y/o similares. Las bases de datos relacionales son una extensión de un archivo plano. Las bases de datos relacionales consisten en una serie de tablas relacionadas. Las tablas están interconectadas a través de un campo clave. El uso del campo clave permite la combinación de las tablas mediante la indexación contra el campo clave; es decir, los campos clave actúan como puntos de pivote dimensional para combinar información de varias tablas. Las relaciones generalmente identifican enlaces mantenidos entre tablas al hacer coincidir las claves primarias. Las claves primarias representan campos que identifican de forma única las filas de una tabla en una base de datos relacional. Más precisamente, identifican de forma única las filas de una tabla en el lado "uno" de una relación "uno a muchos".

Alternativamente, la base de datos MRM puede implementarse utilizando varias estructuras de datos estándar, como una matriz, un hash, una lista (enlazada), una estructura, un archivo de texto estructurado (por ejemplo, XML), una tabla y/o similares. Tales estructuras de datos pueden almacenarse en la memoria y/o en archivos (estructurados). En otra alternativa, se puede utilizar una base de datos orientada a objetos, como Frontier, ObjectStore, Poet, Zope y/o similares. Las bases de datos de objetos pueden incluir varias colecciones de objetos que se agrupan y/o vinculan entre sí mediante atributos comunes; pueden estar relacionados con otras colecciones de objetos por algunos atributos comunes. Las bases de datos orientadas a objetos funcionan de manera similar a las bases de datos relacionales, con la excepción de que los objetos no son solo piezas de datos, sino que pueden tener otros tipos de capacidades encapsuladas dentro de un objeto determinado. Si la base de datos MRM se implementa como una estructura de datos, el uso de la base de datos MRM 419 puede integrarse en otro componente como el componente MRM 435. Además, la base de datos se puede implementar como una combinación de estructuras de datos, objetos y estructuras relacionales. Las bases de datos pueden consolidarse y/o distribuirse en innumerables variaciones a través de técnicas estándar de procesamiento de datos. Las porciones de bases de datos, por ejemplo, tablas, pueden exportarse y/o importarse y, por lo tanto, descentralizarse y/o integrarse.

En una realización, el componente de base de datos 419 incluye varias tablas 419a-e. Una tabla de Usuarios 419a puede incluir campos tales como, entre otros: id_usuario, ssn, fecha de nacimiento, nombre, apellido, edad, estado, dirección_primera línea, dirección_segunda línea, código postal, lista_dispositivos, información_contacto, tipo_contacto, información_contacto_alt, tipo_contacto_alt y/o similares . La tabla de Usuarios puede soportar y/o rastrear múltiples cuentas de entidades en un MRM. Una tabla de Clientes 419b puede incluir campos tales como, entre otros: ID_dispositivo, nombre_dispositivo, IP_dispositivo, MAC_dispositivo, tipo_dispositivo, modelo_dispositivo, versión_dispositivo, SO_dispositivo, lista_aplicaciones_dispositivo, clave_segura_dispositivo y/o similares. Una tabla de aplicaciones 419c puede incluir campos tales como, entre otros: ID de aplicación, nombre_de_aplicación, tipo_de_aplicación, lista_de_respaldo_de_aplicación, sincronización_de_aplicación y/o similares. Una tabla de Mensajes 419d puede incluir campos tales como, pero no limitado a: id_mensaje, aplicación_mensaje, marca de tiempo, lista_detalles_mensaje, tamaño_mensaje, origen_mensaje, diario_mensaje, detalle_lectura_mensaje, y/o similares. Una tabla de Diarios 419e puede incluir campos tales como, pero sin limitación: ID_diario, marca de tiempo_diario, fuente_mensaje, aplicaciones_acceso_diario, lista_mensaje_segmentado, y/o similares.

En una realización, la base de datos MRM puede interactuar con otros sistemas de bases de datos. Por ejemplo, el empleo de un sistema de base de datos distribuida, consultas y acceso a datos mediante el componente MRM de búsqueda puede tratar la combinación de la base de datos MRM, una base de datos de capa de seguridad de datos integrada como una única entidad de base de datos.

En una realización, los programas de usuario pueden contener varias primitivas de interfaz de usuario, que pueden servir para actualizar el MRM. Además, varias cuentas pueden requerir tablas de bases de datos personalizadas según los entornos y los tipos de clientes que el MRM deba atender. Cabe señalar que cualquier campo único puede designarse como un campo clave en todo momento. En una realización alternativa, estas tablas se han descentralizado en sus propias bases de datos y sus respectivos controladores de bases de datos (es decir, controladores de bases de datos individuales para cada una de las tablas anteriores). Empleando técnicas estándar de procesamiento de datos, se pueden distribuir además las bases de datos entre varias sistematizaciones informáticas y/o dispositivos de almacenamiento. De manera similar, las configuraciones de los controladores de base de datos descentralizados pueden variarse consolidando y/o distribuyendo los diversos componentes de base de datos 419a-e. El MRM se puede configurar para realizar un seguimiento de varias configuraciones, entradas y parámetros a través de controladores de base de datos.

La base de datos MRM puede comunicarse hacia y/o con otros componentes en una colección de componentes, incluida ella misma y/o instalaciones similares. Lo más frecuente es que la base de datos MRM se comunique con el componente MRM, otros componentes del programa y/o similares. La base de datos puede contener, retener y proporcionar información sobre otros nodos y datos.

Los MRM

El componente MRM 435 es un componente de programa almacenado que es ejecutado por una CPU. En una realización, el componente MRM incorpora cualquiera y/o todas las combinaciones de los aspectos del MRM discutidos en las figuras anteriores. Como tal, el MRM afecta el acceso, la obtención y el suministro de información, servicios, transacciones y/o similares a través de diversas redes de comunicación.

¡El componente MRM puede transformar Error! Fuente de referencia no encontrada. a través de componentes MRM en Error! Fuente de referencia no encontrada. y/o similares y utilizar el MRM. En una realización, el componente MRM 435 toma entradas (por ejemplo, diarios de mensajes completos 201 y 301; y/o similares), etc., y transforma las entradas a través de varios componentes MRM en salidas (por ejemplo, copias duplicadas de los diarios de mensajes completos 202-204; diarios que contienen segmentos del mensaje completo 302-304; y/o similares).

El componente MRM que permite el acceso a la información entre nodos puede desarrollarse empleando herramientas y lenguajes de desarrollo estándar como, entre otros: Componentes de Apache, ensamblado, ActiveX, ejecutables binarios, (ANSI) (Objective-) C (++), C# y/o .NET, adaptadores de bases de datos, scripts CGI, Java, JavaScript, herramientas de mapeo, herramientas de desarrollo orientadas a objetos y procedimientos, PERL, PHP, Python, scripts de shell, comandos SQL, extensiones de servidor de aplicaciones de red, bibliotecas y entornos de desarrollo web (por ejemplo, ActiveX de Microsoft; Adobe AIR, FLEX y ^f L^a SH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI) ; MooTools; Prototype; script.aculo.us; Protocolo simple de acceso a objetos (SOAP); SWFObject; interfaz de usuario de Yahoo!; y/o similares) WebObjects, y/o similares. En una realización, el servidor MRM emplea un servidor criptográfico para cifrar y descifrar comunicaciones. El componente MRM puede comunicarse hacia y/o con otros componentes en una colección de componentes, incluido él mismo y/o instalaciones similares. Lo más frecuente es que el componente MRM se comunique con la base de datos MRM, los sistemas operativos, otros componentes del programa y/o similares. El MRM puede contener, comunicar, generar, obtener y/o proporcionar componentes de programa, sistemas, usuarios y/o comunicaciones de datos, solicitudes y/o respuestas.

MRM distribuidos

La estructura y/o el funcionamiento de cualquiera de los componentes del controlador de nodos MRM pueden combinarse, consolidarse y/o distribuirse de varias maneras para facilitar el desarrollo y/o la implementación. De manera similar, la colección de componentes se puede combinar de varias maneras para facilitar la implementación y/o el desarrollo. Para lograr esto, uno puede integrar los componentes en una base de código común o en una instalación que pueda cargar dinámicamente los componentes bajo demanda de manera integrada.

La colección de componentes puede consolidarse y/o distribuirse en innumerables variaciones a través de técnicas estándar de procesamiento y/o desarrollo de datos. Múltiples instancias de cualquiera de los componentes del programa en la colección de componentes del programa pueden ser instanciadas en un solo nodo, y/o a través de numerosos nodos para mejorar el rendimiento a través de técnicas de balanceo de carga y/o procesamiento de datos. Además, las instancias únicas también pueden distribuirse entre múltiples controladores y/o dispositivos de almacenamiento; por ejemplo, bases de datos. Todas las instancias de componentes de programa y los controladores que trabajan en conjunto pueden hacerlo a través de técnicas estándar de comunicación de procesamiento de datos.

La configuración del controlador de MRM dependerá del contexto de implementación del sistema. Factores como, entre otros, el presupuesto, la capacidad, la ubicación y/o el uso de los recursos de hardware subyacentes pueden afectar los requisitos de implementación y la configuración. Independientemente de si la configuración resulta (i) en componentes de programa más consolidados y/o integrados, (ii) en una serie más distribuida de componentes de programa, y/o (iii) en alguna combinación entre una configuración consolidada y distribuida, los datos pueden ser comunicados, obtenidos y/o proporcionados. Las instancias de los componentes consolidados en una base de código común de la colección de componentes del programa pueden comunicar, obtener y/o proporcionar datos. Esto se puede lograr a través de técnicas de comunicación de procesamiento de datos dentro de la aplicación tales como, entre otras: referencias de datos (por ejemplo, punteros), mensajería interna, comunicación de variable de instancia de objeto, espacio de memoria compartido, paso de variable y/o similares.

Si los componentes de la colección de componentes son discretos, separados y/o externos entre sí, entonces la comunicación, la obtención y/o el suministro de datos con y/o a otros componentes se puede lograr a través de técnicas de comunicación de procesamiento de datos entre aplicaciones tales como, pero no limitado a: Pasaje de información de interfaces de programa de aplicación (API); Modelo de objetos de componentes (distribuidos) ((D)COM), Enlace e incrustación de objetos (distribuidos) ((D)OLE), y/o similares), Arquitectura de corredores de solicitud de objetos comunes (CORBA), interfaces de programa de aplicación local y remota Jini, Notación de objetos JavaScript (JSON), Invocación de métodos remotos (RMI), SOAP, tuberías de proceso, archivos compartidos, y/o similares. Los mensajes enviados entre componentes discretos para la comunicación entre aplicaciones o dentro de los espacios de memoria de un componente singular para la comunicación dentro de la aplicación pueden facilitarse mediante la creación y el análisis de una gramática. Una gramática se puede desarrollar utilizando herramientas de desarrollo como lex, yacc, XML y/o similares, que permiten la generación de gramática y capacidades de análisis, que a su vez pueden formar la base de mensajes de comunicación dentro y entre componentes.

Por ejemplo, se puede organizar una gramática para que reconozca los tokens de un comando de publicación HTTP, por ejemplo: w3c-post http://... Valuel

donde Value1 se considera un parámetro porque "http://' es parte de la sintaxis gramatical y lo que sigue se considera parte del valor de la publicación. De manera similar, con una gramática de este tipo, una variable "Valuel" puede insertarse en un comando de publicación "http://" y luego enviarse. La sintaxis de la gramática en sí puede presentarse como datos estructurados que se interpretan y/o se utilizan de otro modo para generar el mecanismo de análisis (por ejemplo, un archivo de texto de descripción de sintaxis procesado por lex, yacc, etc.). Además, una vez que se genera y/o instancia el mecanismo de análisis, el propio mecanismo de análisis puede procesar y/o analizar datos estructurados como, entre otros: texto delineado con caracteres (por ejemplo, pestañas), HTML, secuencias de texto estructurado, XML y /o datos estructurados similares. En otra realización, los propios protocolos de procesamiento de datos entre aplicaciones pueden tener analizadores integrados y/o fácilmente disponibles (por ejemplo, JSON, SOAP y/o analizadores similares) que pueden emplearse para analizar datos (por ejemplo, comunicaciones). Además, la gramática de análisis puede usarse más allá del análisis de mensajes, pero también puede usarse para analizar: bases de datos, colecciones de datos, almacenes de datos, datos estructurados y/o similares. Una vez más, la configuración deseada dependerá del contexto, el entorno y los requisitos de la implementación del sistema.

Por ejemplo, en algunas implementaciones, el controlador de MRM puede estar ejecutando un script PHP que implementa un servidor de socket de capa de sockets seguros ("SSL") a través del servidor de información, que escucha las comunicaciones entrantes en un puerto del servidor al que un cliente puede enviar datos. por ejemplo, datos codificados en formato JSON. Al identificar una comunicación entrante, la secuencia de comandos PHP puede leer el mensaje entrante del dispositivo cliente, analizar los datos de texto codificados en JSON recibidos para extraer información de los datos de texto codificados en JSON en variables de secuencia de comandos PHP y almacenar los datos (por ejemplo, información de identificación, etc.) y/o información extraída en una base de datos relacional accesible mediante el lenguaje de consulta estructurado ("SQL"). A continuación, se proporciona una lista ejemplar, escrita sustancialmente en forma de comandos PHP/SQL, para aceptar datos de entrada codificados en JSON desde un dispositivo cliente a través de una conexión SSL, analizar los datos para extraer variables y almacenar los datos en una base de datos:

<?PHP

header('Content-Type: text/plain');

// establecer la dirección ip y el puerto de escucha para los datos entrantes

$address = '192.168.0.100';

$port = 255;

// crear un socket SSL del lado del servidor, escuchar/aceptar la comunicación entrante

$sock = socket_create(AF_INET, SOCK_STREAM, 0);

socket_bind($sock, $address, Sport) or die('No se ha podido enlazar con la dirección');

socket_listen($sock);

$client = socket_accept($sock);

// leer los datos de entrada del dispositivo cliente en bloques de 1024 bytes hasta el final del mensaje

do{

$input = “”;

$input = socket_read($client, 1024);

$data .= $input;

} while ($input != “”);

// analizar los datos para extraer las variables

$obj = json_decode($data, true);

// almacenar los datos de entrada en una base de datos

mysql_connect("201.408.185.132”, $DBserver, $password); // accede al servidor de base de datos mysql_select("CLIENT_DB.SQL”); // seleccione el servidor de base de datos

mysql_query("INSERT INTO UserTable (transmission)

v Al Ue S ($data)”); // add data to UserTable table in a CLIENT database

mysql_close("CLIENT_DB.SQL”); // cierra la conexión con la base de datos

?>

Además, los siguientes recursos se pueden utilizar para proporcionar realizaciones de ejemplo con respecto a la implementación del analizador SOAP:

http://www.xav.com/perl/site/lib/SOAP/Parser.html http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBM-DI.doc/referenceguide295. htm

y otras implementaciones del analizador: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1index.jsp?topic=/com.ibm.IBMDI.doc/referenceguide259.htm

todos los cuales se incorporan aquí expresamente como referencia en este documento.

Con el fin de abordar varios problemas y avanzar en la técnica, la totalidad de esta solicitud (incluida la portada, el título, los encabezados, el campo, los antecedentes, el resumen, la breve descripción de los dibujos, la descripción detallada, las reivindicaciones, el resumen, las figuras, los apéndices y/o otros) muestra, a modo de ilustración, varios ejemplos de realización en los que se pueden poner en práctica las innovaciones reivindicadas. Las ventajas y características de la solicitud son solo una muestra representativa de realizaciones, y no son exhaustivas y/o exclusivas. Se presentan solo para ayudar a comprender y enseñar los principios reivindicados. Debe entenderse que no son representativos de todas las innovaciones reivindicadas. Como tal, ciertos aspectos de la divulgación no se han discutido aquí. El hecho de que no se hayan presentado realizaciones alternativas para una porción específica de las innovaciones o que otras realizaciones alternativas no descritas puedan estar disponibles para una porción no debe considerarse una renuncia a esas realizaciones alternativas. Se apreciará que muchas de esas realizaciones no descritas incorporan los mismos principios de las innovaciones y otras son equivalentes. Por tanto, debe entenderse que pueden utilizarse otras realizaciones y pueden realizarse modificaciones funcionales, lógicas, operativas, organizativas, estructurales y/o topológicas sin apartarse del alcance de la descripción. Como tal, todos los ejemplos y/o realizaciones se consideran no limitativos a lo largo de esta divulgación. Además, no debe hacerse ninguna inferencia con respecto a las realizaciones discutidas en este documento en relación con las no discutidas en este documento, excepto que es como tal con el fin de reducir el espacio y la repetición. Por ejemplo, debe entenderse que la estructura lógica y/o topológica de cualquier combinación de secuencia(s) de flujo de datos, componentes de programa (una colección de componentes), otros componentes y/o cualquier conjunto de características presente como se describe en el las cifras y/o en todas partes no se limitan a un orden y/o arreglo operativo fijo, sino que cualquier orden divulgada es ejemplar y todos los equivalentes, independientemente del orden, están contemplados por la divulgación. Además, debe entenderse que dichas funciones no se limitan a la ejecución en serie, sino a cualquier número de subprocesos, procesos, procesadores, servicios, servidores y/o similares que pueden ejecutarse de forma asíncrona, concurrente, en paralelo, simultáneamente, sincrónicamente, y/o similares también se contemplan en la divulgación. Como tal, algunas de estas características pueden ser contradictorias entre sí, ya que no pueden estar presentes simultáneamente en una sola realización. De manera similar, algunas características son aplicables a un aspecto de las innovaciones e inaplicables a otros. Además, la divulgación incluye otras innovaciones no reivindicadas actualmente. El solicitante se reserva todos los derechos sobre aquellas innovaciones actualmente no reivindicadas, incluido el derecho a reivindicar dichas innovaciones, presentar solicitudes adicionales, continuaciones, continuaciones en parte, divisiones y/o similares. Como tal, debe entenderse que las ventajas, las realizaciones, los ejemplos, las funciones, las características, los aspectos lógicos, operativos, organizacionales, estructurales, topológicos y/u otros aspectos de la divulgación no deben considerarse limitaciones a la divulgación tal como se define en las reivindicaciones. o limitaciones sobre equivalentes a las reivindicaciones. Debe entenderse que, dependiendo de las necesidades y/o características particulares de un usuario individual y/o empresarial de MRM, la configuración de la base de datos y/o el modelo relacional, el tipo de datos, la transmisión de datos y/o el marco de trabajo de la red, la estructura sintáctica y/o o similares, pueden implementarse varias realizaciones del MRM que permiten una gran flexibilidad y personalización. Mientras que varias realizaciones y discusiones del MRM se han dirigido a la gestión del diario de mensajes de la aplicación, sin embargo, debe entenderse que las realizaciones descritas aquí pueden ser fácilmente configuradas y/o personalizadas para una amplia variedad de otras aplicaciones y/o implementaciones.

Claims (15)

REIVINDICACIONES

1. Un método de retransmisión acelerada de mensajes para un sistema informático, que comprende:

mantener, en un medio de almacenamiento del sistema informático, un diario maestro de mensajes secuenciados generados a partir de una pluralidad de mensajes escritos por aplicaciones o procesos durante las operaciones del sistema informático, al menos un subconjunto de dichas aplicaciones o procesos que requieren acceso a dichos mensajes secuenciados para funcionar correctamente;

determinar una demanda estimada de acceso a dichos mensajes secuenciados por dicho al menos un subconjunto de aplicaciones o procesos que pueden experimentar conmutaciones por error;

generar, con base en dicha demanda estimada, una o más copias de diario y/o uno o más segmentos de diario mediante la duplicación del contenido de dicho diario maestro, siendo cada copia de diario o segmento de diario accesible de forma independiente por una sola aplicación o proceso en un momento dado; y

asignar dichas una o más copias de diario y/o dichos uno o más segmentos de diario, a pedido, a algunos de dicho al menos un subconjunto de dichas aplicaciones o procesos que han experimentado conmutaciones por error, de modo que múltiples aplicaciones o procesos puedan acceder simultáneamente al contenido de dicho diario maestro, acelerando así el acceso a dichos mensajes secuenciados en dicho diario maestro por parte de dichas aplicaciones o procesos en su recuperación de dichas conmutaciones por error.

2. El método de acuerdo con la reivindicación 1, donde dicha pluralidad de mensajes escritos por dichas aplicaciones o procesos durante las operaciones del sistema informático son transformados en dichos mensajes secuenciados por un secuenciador.

3. El método de acuerdo con la reivindicación 2, donde dicho secuenciador vuelve a publicar dicha pluralidad de mensajes secuenciados en dichas aplicaciones o procesos.

4. El método de acuerdo con la reivindicación 1, donde dichas una o más copias de diario y/o dichos uno o más segmentos de diario son generados por un módulo de software o hardware dedicado.

5. El método de acuerdo con la reivindicación 1, que comprende, además: actualizar el contenido de dichas una o más copias de diario y/o dichos uno o más segmentos de diario con contenido actualizado de dicho diario maestro.

6. El método de acuerdo con la reivindicación 1, que comprende, además:

actualizar o recuperar contenido de una primera de dichas una o más copias de diario y/o dichos uno o más segmentos de diario con base en el contenido de una segunda de dichas una o más copias de diario y/o dichos uno o más segmentos de diario.

7. El método de acuerdo con la reivindicación 1, que comprende, además:

dividir dichas una o más copias de diario y/o dichos uno o más segmentos de diario en al menos un primer nivel y un segundo nivel; y

restringir la actualización o recuperación de contenido por parte de una copia/segmento de un diario de segundo nivel para que se base en el contenido de otra copia/segmento de un diario de segundo nivel o una copia/segmento de un diario de primer nivel.

8. Un sistema informático que implementa la retransmisión acelerada de mensajes, que comprende:

al menos un procesador de ordenador; y

al menos un medio de almacenamiento dispuesto en comunicación con al menos un procesador de ordenador y almacenar instrucciones de ordenador para hacer que al menos un procesador de ordenador:

mantenga, en dicho al menos un medio de almacenamiento del sistema informático, un diario maestro de mensajes secuenciados generados a partir de una pluralidad de mensajes escritos por aplicaciones o procesos durante las operaciones del sistema informático, al menos un subconjunto de dichas aplicaciones o procesos que requieren acceso a dichos mensajes secuenciados para funcionar correctamente;

determine una demanda estimada de acceso a dichos mensajes secuenciados por dicho al menos un subconjunto de aplicaciones o procesos que pueden experimentar conmutaciones por error;

genere, con base en dicha demanda estimada, una o más copias de diario y/o uno o más segmentos de diario mediante la duplicación del contenido de dicho diario maestro, siendo cada copia de diario o segmento de diario accesible de forma independiente por una sola aplicación o proceso en un momento dado; y

asigne dichas una o más copias de diario y/o dichos uno o más segmentos de diario, a pedido, a algunos de dicho al menos un subconjunto de dichas aplicaciones o procesos que han experimentado conmutaciones por error, de modo que múltiples aplicaciones o procesos puedan acceder simultáneamente al contenido de dicho diario maestro, acelerando así el acceso a dichos mensajes secuenciados en dicho diario maestro por parte de dichas aplicaciones o procesos en su recuperación de dichas conmutaciones por error.

9. El sistema informático de acuerdo con la reivindicación 8, donde dicha pluralidad de mensajes escritos por dichas aplicaciones o procesos durante las operaciones del sistema informático se transforman en dichos mensajes secuenciados mediante un secuenciador, o donde dicho secuenciador vuelve a publicar dicha pluralidad de mensajes secuenciados en dichas aplicaciones o procesos.

10. El sistema informático de acuerdo con la reivindicación 8, donde dichas una o más copias de diario y/o dichos uno o más segmentos de diario son generados por un módulo de software o hardware dedicado.

11. El sistema informático de acuerdo con la reivindicación 8, configurado además para:

actualizar el contenido de dichas una o más copias de diario y/o dichos uno o más segmentos de diario con contenido actualizado de dicho diario maestro, o para actualizar o recuperar el contenido de una primera de dichas una o más copias de diario y/o dichos uno o más segmentos de diario con base en el contenido de una segunda de dichas una o más copias de diario y/o dichos uno o más segmentos de diario.

12. El sistema informático de acuerdo con la reivindicación 8, configurado además para:

dividir dichas una o más copias de diario y/o dichos uno o más segmentos de diario en al menos un primer nivel y un segundo nivel; y

restringir la actualización o recuperación de contenido por parte de una copia/segmento de un diario de segundo nivel para que se base en el contenido de otra copia/segmento de un diario de segundo nivel o una copia/segmento de un diario de primer nivel.

13. El método de acuerdo con la reivindicación 1 o el sistema informático de la reivindicación 8, donde dicho sistema informático se selecciona de un grupo que consiste en: un sistema de comercio electrónico; un sistema de venta basado en subastas; y un sistema de juego.

14. El método de acuerdo con la reivindicación 1 o el sistema informático de la reivindicación 8, donde la demanda estimada se determina con base en uno o más factores seleccionados de un grupo que consiste en:

fallas de software conocidas o potenciales; fallas de hardware conocidas o potenciales;

una serie de aplicaciones o procesos afectados por una falla de software o hardware;

una velocidad a la que una aplicación o proceso accede a un mensaje en dicho diario, una copia de diario o un segmento de diario;

un tiempo de recuperación deseado para una aplicación o proceso fallido; y la carga de trabajo esperada del sistema informático.

15. Un medio legible por ordenador no transitorio que tiene instrucciones de ordenador que, cuando se ejecutan, hacen que un sistema informático implemente la retransmisión acelerada de mensajes de acuerdo con el método de cualquiera de las reivindicaciones 1 a 7, 13 y 14.