ES2917200T3 - Verificación de procesos de datos en una red de recursos informáticos - Google Patents

Verificación de procesos de datos en una red de recursos informáticos Download PDF

Info

Publication number
ES2917200T3
ES2917200T3 ES17175939T ES17175939T ES2917200T3 ES 2917200 T3 ES2917200 T3 ES 2917200T3 ES 17175939 T ES17175939 T ES 17175939T ES 17175939 T ES17175939 T ES 17175939T ES 2917200 T3 ES2917200 T3 ES 2917200T3
Authority
ES
Spain
Prior art keywords
broker
key
client
request
child
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17175939T
Other languages
English (en)
Inventor
Walter Michael Pitio
Philip Iannaccone
James Brown
Stephen Bain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Royal Bank of Canada
Original Assignee
Royal Bank of Canada
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Royal Bank of Canada filed Critical Royal Bank of Canada
Application granted granted Critical
Publication of ES2917200T3 publication Critical patent/ES2917200T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un método para administrar los procesos de datos en una red de recursos informáticos incluye: recibir al menos una solicitud de niño enrutada desde un dispositivo intermediario a al menos un dispositivo de destino correspondiente, al menos una solicitud de niños que solicita la ejecución de al menos un proceso de datos infantil correspondiente, cada uno de los al menos un proceso de datos infantiles para ejecutar al menos una parte del proceso de datos de al menos uno de los padres desde un dispositivo instructor, y cada una de las solicitudes de al menos un niño, incluida una clave de destino, se deriva al menos en parte del AT del AT al menos una clave de instructor; almacenar la solicitud de al menos un niño en al menos un dispositivo de almacenamiento; modificar la solicitud de al menos un niño al recibir una señal de modificación de solicitud de hijo; y generar señales para comunicar las solicitudes de los niños a uno o más dispositivos solicitantes. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Verificación de procesos de datos en una red de recursos informáticos
Campo
La presente descripción se refiere generalmente a sistemas, métodos, dispositivos y medios para la verificación o gestión de procesos de datos en varios recursos informáticos en red. En modalidades particulares, la descripción se refiere a la verificación de procesos de datos que involucran sistemas o dispositivos intermedios.
Los aspectos del material que se describe en esta solicitud se relacionan con el almacenamiento, transferencia y/o administración de activos y otros intereses financieros. Los aspectos de dicho almacenamiento, transferencia y/o administración pueden estar sujetos a regulaciones por parte de agencias gubernamentales y de otro tipo. La descripción en la presente descripción se realiza únicamente en términos de posibilidades lógicas, de programación y de comunicación, sin tener en cuenta las consideraciones legales, reglamentarias o de otro tipo. Nada en la presente descripción pretende ser una declaración o representación de que cualquier sistema, método o proceso que se propone o describe en la presente descripción, o el uso del mismo, cumple o no cumple con cualquier estatuto, ley, regulación u otro requerimiento legal en cualquier jurisdicción; ni debe tomarse o interpretarse como tal. Introducción
En varias formas de sistemas de procesamiento de datos en red o distribuidos de cualquier otra manera, los procesos relacionados complejos y/o múltiples en función de las órdenes de clientes a menudo se enrutan en múltiples recursos informáticos para su distribución, difusión o ejecución.
Algunos de estos sistemas de procesamiento de datos distribuidos manejan simultáneamente grandes volúmenes de procesos de datos para numerosos clientes. Las instrucciones de diferentes clientes pueden implicar procesos de datos similares y pueden requerir que los procesos de datos se comuniquen y/o ejecuten en los recursos informáticos sin revelar ninguna información con respecto al sistema del cliente de instrucciones original.
En dicho entorno, verificar los procesos de datos relacionados para un cliente puede ser un desafío.
El documento EP 1 510 951 muestra un producto de sistema, método y programa de computadora para el procesamiento de datos en la gestión de una cadena de suministro. Se usa un sistema central de procesamiento de datos para las solicitudes de clientes, que asigna identificadores únicos a los artículos del cliente y divide las solicitudes en subsolicitudes para el procesamiento individual, y se combinan los resultados de las subsolicitudes. El documento de Estados Unidos 2002/091533 muestra un producto de sistema, método y programa de computadora para llevar a cabo servicios de comercio electrónico mediante el uso de procesamiento de lenguaje de marcado estructurado. Se procesan múltiples parejas y documentos mediante el uso de un motor genérico de procesamiento de servicios.
El documento EP 0838056 muestra un método y un aparato para la gestión de las múltiples solicitudes del servidor y recopilar respuestas. Al recibir una solicitud de un cliente, un administrador de solicitudes envía una cantidad de solicitudes simultáneamente a diferentes servidores y recopila las respuestas para enviarlas de regreso al cliente. El documento de Estados Unidos 2002/128871 muestra un método, aparato y sistema para agregar, orientar y sincronizar el suministro de información de salud. Se procesa una solicitud de información para obtener información de una o más bases de datos, y se genera una respuesta en función de la agregación de la información.
Resumen
Los aspectos de la presente descripción proporcionan sistemas, métodos y mecanismos de instrucciones ejecutables por computadora (por ejemplo, estructuras de programación no transitorias legibles por máquina) como, por ejemplo, conjuntos de instrucciones y datos codificados por programas informáticos, para la gestión del procesamiento de datos por múltiples recursos informáticos en red.
Particularmente, por ejemplo, la presente descripción proporciona sistemas, métodos y conjuntos de instrucciones codificadas útiles para la verificación o el monitoreo de las órdenes o solicitudes enrutadas y/o que se enrutan para su procesamiento en varios recursos informáticos en red.
De acuerdo con un aspecto, se proporciona un sistema para la gestión de los procesos de datos en una red de recursos informáticos. El método comprende recibir, en un dispositivo informático, al menos una solicitud secundaria que se genera de una solicitud principal que se envía desde un dispositivo del instructor, la solicitud secundaria se enruta de un dispositivo intermediario a al menos un dispositivo de destino correspondiente, la al menos una solicitud secundaria solicita la ejecución de al menos un proceso de datos secundario correspondiente, cada uno de los al menos un proceso de datos secundario ejecuta al menos una porción del al menos un proceso de datos principal desde el dispositivo instructor, y cada una de las al menos una solicitud secundaria que incluyen una clave de destino derivada al menos en parte de al menos una clave de instructor, la clave de destino se asocia con la solicitud secundaria;
almacenar, mediante el dispositivo informático, la al menos una solicitud secundaria en al menos un dispositivo de almacenamiento;
modificar, mediante el dispositivo informático, la al menos una solicitud secundaria al recibir una señal de modificación de la solicitud secundaria; y
generar las señales para comunicar las solicitudes secundarias a uno o más dispositivos solicitantes;
en donde la señal de modificación de la solicitud secundaria incluye un mensaje de máscara, y la modificación de al menos una solicitud secundaria comprende enmascarar al menos un campo de al menos una solicitud secundaria, el al menos un campo que se identifica por el mensaje de máscara; y
en donde enmascarar el al menos un campo comprende: cifrar el al menos un campo de la al menos una solicitud secundaria con una clave secundaria asociada con el dispositivo intermediario.
En cualquiera de las modalidades anteriores, el método puede incluir cifrar al menos una solicitud secundaria modificada con su clave de destino correspondiente antes de generar las señales para comunicar las solicitudes secundarias.
En cualquiera de las modalidades anteriores, un dispositivo solicitante particular que tiene al menos una clave de destino particular puede decodificar la solicitud secundaria cifrada correspondiente para identificar al menos un proceso de datos secundario enrutado para ejecutar al menos un proceso de datos principal asociado con la clave de destino particular.
En cualquiera de las modalidades anteriores, modificar la al menos una solicitud secundaria puede comprender ocultar al menos un campo de la al menos una solicitud secundaria.
En cualquiera de las modalidades anteriores, el método puede incluir cifrar al menos una solicitud secundaria modificada que incluye al menos un campo enmascarado con su clave de destino correspondiente antes de generar las señales para la comunicación de las solicitudes secundarias.
En cualquiera de las modalidades anteriores, el método puede incluir recibir desde un dispositivo solicitante al menos uno de: una clave de instructor, una clave de intermediario, una clave de destino y una clave de índice; y generar señales para comunicar las solicitudes secundarias asociadas con al menos una de: la clave de instructor, la clave de intermediario, la clave de destino y la clave de índice para el dispositivo solicitante.
En cualquiera de las modalidades anteriores, el al menos un proceso de datos principal puede representar al menos una solicitud de una operación en un interés financiero.
De acuerdo con otro aspecto, se proporciona un medio de comunicación no transitorio legible por computadora para la gestión de los procesos de datos en una red de recursos informáticos, el medio de comunicación no transitorio legible por computadora que incluye instrucciones interpretables por máquina, que cuando se ejecutan, hacen que al menos un procesador realice cualquiera de los métodos que se describen en la presente descripción o un subconjunto de los mismos.
De acuerdo con otro aspecto, se proporciona un sistema que comprende al menos un dispositivo de almacenamiento y al menos un procesador que se configura para realizar cualquiera de los métodos que se describen en la presente descripción o un subconjunto de los mismos.
Muchas características adicionales y sus combinaciones relativas a las modalidades que se describen en la presente descripción aparecerán para los expertos en la técnica tras la lectura de la presente descripción.
Descripción de las figuras
En los dibujos acompañantes, los cuales ilustran una o más modalidades ilustrativas, se ilustran modalidades de la invención a manera de ejemplo. Debe entenderse expresamente que la descripción y los dibujos son solo para fines de ilustración y como ayuda para la comprensión, y no pretenden ser una definición de los límites de la invención. Las Figuras 1A y 1B muestran aspectos de un ejemplo de sistema y flujo de trabajo para la gestión de los procesos de datos en una red de recursos informáticos.
La Figura 2 muestra aspectos de un ejemplo de sistema y flujo de trabajo para la gestión de los procesos de datos en una red de recursos informáticos.
La Figura 3 muestra un formato de registro de ejemplo.
La Figura 4 muestra aspectos de un ejemplo de sistema y flujo de trabajo para la gestión de los procesos de datos en una red de recursos informáticos.
La Figura 5 muestra aspectos de un ejemplo de sistema y flujo de trabajo para la gestión de los procesos de datos en una red de recursos informáticos.
La Figura 6 muestra aspectos de un ejemplo de sistema y flujo de trabajo para la gestión de los procesos de datos en una red de recursos informáticos.
La Figura 7 muestra aspectos de un sistema y flujo de trabajo de ejemplo para la gestión de los procesos de datos en una red de recursos informáticos donde se usa más de un sistema intermediario entre un instructor y un destino.
La Figura 8 muestra aspectos de un sistema y flujo de trabajo de ejemplo para la gestión de los de datos en una red de recursos informáticos donde un sistema tiene múltiples sistemas internos sobre los cuales pueden procesarse órdenes.
La Figura 9 muestra aspectos de un sistema de ejemplo y un flujo de trabajo para la gestión de los procesos de datos en una red de recursos informáticos donde un sistema tiene múltiples sistemas internos sobre los cuales pueden procesarse órdenes.
La Figura 10 es una tabla que ilustra un posible escenario en donde un esquema de módulo 7 está en uso (por ejemplo, cuando se usa un divisor de 7 en el contexto de una operación de módulo) y 4 de las entidades estaban involucradas en el manejo de la orden.
La Figura 11 es un esquema de bloques que muestra aspectos de un sistema o dispositivo de ejemplo.
La Figura 12 es un flujo de trabajo de ejemplo que muestra aspectos de un método de ejemplo desde una perspectiva de intermediario.
La Figura 13 es un flujo de trabajo de ejemplo que muestra aspectos de un método de ejemplo desde la perspectiva de un supervisor.
La Figura 14 es un flujo de trabajo de ejemplo que muestra aspectos de un método de ejemplo desde la perspectiva del instructor.
La Figura 15 es un esquema de bloques que muestra aspectos de un sistema y flujo de trabajo de ejemplo. Descripción detallada
En un sistema de procesamiento de datos distribuidos o en red, un dispositivo de instrucciones puede enviar una solicitud de procesamiento de datos a un dispositivo intermediario para ejecutar la solicitud de procesamiento de datos en uno o más dispositivos de destino. Por ejemplo, en una modalidad, un dispositivo de instrucciones puede enviar una solicitud para ejecutar una carga de trabajo informática a un administrador de recursos distribuidos para su ejecución en uno o más recursos distribuidos. En otro ejemplo, un dispositivo de instrucciones puede enviar una solicitud para ejecutar una operación financiera a un dispositivo intermediario, tal como una agencia de corredores electrónica para su ejecución en uno o más dispositivos de comercio electrónico en red.
En algunas modalidades, los dispositivos intermediarios pueden hacer que la solicitud de procesamiento de datos del dispositivo de instrucciones se ejecute en cualquier cantidad de recursos de procesamiento de datos distribuidos. En algunas situaciones, cuando los dispositivos intermediarios son parte de, o comprenden sistemas independientes de los dispositivos cliente, los dispositivos intermediarios pueden tomar decisiones con respecto a la ejecución de la solicitud de procesamiento de datos del dispositivo de instrucciones sin ninguna supervisión directa del dispositivo del cliente. En algunos casos, una entidad asociada con el dispositivo intermediario puede tener motivaciones diferentes o en conflicto con una entidad asociada con el dispositivo de instrucciones. Por ejemplo, un administrador de recursos distribuidos que maneja las cargas de trabajo de múltiples dispositivos de instrucciones puede configurarse para dividir los recursos de procesamiento de datos entre las cargas de trabajo de muchos dispositivos de instrucciones, mientras que un dispositivo de instrucciones en particular preferiría que todos los recursos estuvieran dedicados a las cargas de trabajo del dispositivo de instrucciones.
De manera similar, un sistema electrónico de agencia de corredores puede mejorarse a partir de las diferentes comisiones, descuentos, ejecución de las solicitudes de operación de los dispositivos de instrucciones preferidos o más rentables. Estas motivaciones pueden afectar la forma en que un dispositivo intermedio se configura para manejar las solicitudes de procesamiento de datos que pueden no estar alineadas con las instrucciones o los mejores intereses de un dispositivo de instrucciones.
En términos generales, en algunas modalidades, la presente descripción proporciona sistemas, dispositivos, métodos y medios para verificar o de cualquier otra manera realizar la gestión de la ejecución de los procesos de datos en una red de recursos informáticos. En algunos casos, esta verificación puede proporcionar una indicación sobre el desempeño de un dispositivo intermediario en la ejecución de una solicitud de procesamiento de datos de un dispositivo de instrucciones y/o información relacionada con la forma en que el intermediario ha distribuido y/o enrutado la solicitud a uno o más recursos informáticos.
En algunas modalidades, los aspectos de los sistemas, dispositivos, métodos y medios que se describen en la presente descripción pueden proporcionar anonimato de la información relacionada con las solicitudes de procesamiento de datos de diferentes dispositivos de instrucciones. En algunos casos, los aspectos de la presente descripción pueden reducir la posibilidad de que un tercero pueda obtener información relacionada con las solicitudes de procesamiento de datos desde un dispositivo de instrucciones.
La Figura 1A muestra aspectos de un sistema de ejemplo 100A para verificar o de cualquier otra manera realizar la gestión de los procesos de datos en una red de recursos informáticos. En algunas modalidades, el sistema 100 puede incluir uno o más sistemas del instructor, como, por ejemplo, los sistemas informáticos cliente 102 en la Figura 1A. Un sistema del instructor puede incluir uno o más dispositivos del instructor (ordenador cliente) que se configuran para transmitir una solicitud de procesamiento de datos (por ejemplo, una solicitud principal) a un segundo sistema (por ejemplo, los sistemas informáticos del bróker 104). La solicitud de procesamiento de datos puede ejecutarse, en algunos ejemplos, por uno o más recursos informáticos (por ejemplo, sedes de comercio electrónico 108a..n).
En algunas modalidades, la solicitud de procesamiento de datos puede ser una solicitud u otro mensaje que incluye datos que incluyen uno o más parámetros o requerimientos que definen el proceso de datos que el sistema del instructor busca que se ejecute. El sistema del instructor 102 también puede configurarse para mantener un registro de transacciones (por ejemplo, dentro de una base de datos o varios dispositivos de almacenamiento de datos legibles por computadora).
El segundo sistema puede, en algunos ejemplos, ser un sistema intermediario que se configura para recibir la solicitud de procesamiento de datos desde el sistema del instructor; generar una o más solicitudes secundarias, cada una para ejecutar al menos una porción de la solicitud de procesamiento de datos recibida; y realizar el enrutamiento de la(s) solicitud(es) secundaria(s) para su ejecución en uno o más recursos informáticos. En algunas modalidades, el sistema intermediario puede ser un bróker electrónico, un sistema de gestión de recursos distribuidos o cualquier otro sistema o dispositivo que pueda actuar como intermediario, agente, proxy o nodo para ejecutar la solicitud de procesamiento de datos.
Debe entenderse que el término "sistema" al que se hace referencia, por ejemplo, como los sistemas del instructor, sistemas intermediarios, sistemas del supervisor, sistemas informáticos del cliente, sistemas informáticos del bróker, etcétera, puede referirse a uno o más dispositivos, sistemas, enlaces de comunicación o alguna combinación de los mismos. En algunos ejemplos, un único dispositivo físico puede incluir aspectos de múltiples sistemas, por ejemplo, un único dispositivo informático puede ejecutar un proceso de datos para un primer sistema y también albergar un servidor para un segundo sistema.
Por el contrario, el término "dispositivo" o "servidor" puede referirse a un único dispositivo, múltiples dispositivos, enlaces de comunicación, sistemas, procesos informáticos o cualquier combinación de los mismos.
Los términos sistemas y dispositivos "instructor", "intermediario" y "destino" se refieren a las relaciones entre los varios componentes del sistema general. Por ejemplo, un sistema informático del bróker 104 puede ser un sistema intermediario para un sistema informático del instructor cliente 102; sin embargo, para un proceso de múltiples saltos, el sistema informático del bróker 104 también puede ser un sistema del instructor que envía una solicitud a un segundo sistema del bróker intermediario. De manera similar, el segundo sistema del bróker puede ser un dispositivo de destino desde la perspectiva del sistema del instructor y también puede actuar como intermediario para el primer sistema del bróker.
En algunas modalidades, los sistemas y dispositivos del instructor, intermediario, destino y supervisor pueden referirse a componentes electrónicos dentro de un único sistema, como, por ejemplo, el sistema informático del bróker 104. Por ejemplo, como se describió en la presente descripción o de cualquier otra manera, el sistema informático del bróker puede incluir múltiples componentes informáticos internos, como por ejemplo, enrutadores inteligentes, que pueden denominarse como sistemas/dispositivos del instructor, intermediario, destino y/o supervisor.
Los aspectos de los sistemas y métodos que se describen en la presente descripción pueden aplicarse en varios campos, por ejemplo, el comercio financiero.
Por ejemplo, una solicitud de procesamiento de datos comerciales electrónicos puede incluir un(los) identificador(es) de interés (como por ejemplo un identificador usado por una o más bolsas de valores para identificar una acción, un Comité de Procedimientos Uniformes de Identificación de Valores (CUSIP), un conjunto de monedas que se intercambiarán, etcétera), un valor de cantidad (por ejemplo, montos o volúmenes) de los intereses que se van a negociar (que incluye, por ejemplo, cualquier cantidad total y/o de reserva), un tipo de ejecución (por ejemplo, compra, venta, propuesta, oferta, etcétera) para ejecutarse o solicitarse, el tiempo de vigencia (por ejemplo, bueno hasta que se cancele, inmediato o cancelar, rellenar o eliminar) y los términos de precio correspondientes. En algunos ejemplos, la solicitud de procesamiento de datos puede incluir datos que indiquen requerimientos y/o preferencias específicos para ejecutar el proceso de datos, por ejemplo, recursos informáticos preferidos o requeridos para usarse, límites en la cantidad de procesos de datos secundarios que pueden generarse a partir de la solicitud original, instrucciones de enrutamiento, parámetros de temporización y cualquier otra instrucción para ejecutar el proceso de datos y/o instruir a un sistema intermediario.
En otro ejemplo, una solicitud de procesamiento de datos de carga de trabajo puede enviarse desde un sistema del instructor a un sistema de gestión de recursos distribuidos intermediario para su ejecución en uno o más recursos distribuidos, que se administra o puede accederse mediante el sistema intermediario.
En otros ejemplos, los sistemas y métodos que se describen en la presente descripción pueden aplicarse a otros campos donde las instrucciones/órdenes se enrutan entre varias entidades, y un sistema de instrucciones general o intermediario puede desear validar y/o verificar que dicho enrutamiento se llevó a cabo de manera consistente y/o en interés del instructor o el intermediario. Si bien se describen varias modalidades en relación con el comercio financiero (por ejemplo, que tienen una terminología de cliente-bróker-sede), pueden usarse otras aplicaciones, en donde puede ser más aplicable una terminología de cliente-intermediario-destino. Por ejemplo, el cliente puede ser el "instructor" en tal caso, y el intermediario/destino puede ser uno o más agentes del "instructor" que pueden realizar varias tareas y/o enrutar a otros agentes. Puede haber varios niveles de intermediarios, etcétera, por ejemplo, múltiples niveles de brókers y/o componentes de enrutamiento dentro de los brókers individuales.
La información y/o las instrucciones pueden proporcionarse en forma de procesos de datos, que pueden enrutarse a través de varios enlaces de comunicación, por ejemplo, una red de recursos informáticos en donde los recursos informáticos pueden configurarse para realizar varias funciones, por ejemplo, a través de la ejecución de instrucciones interpretables por máquina.
En el contexto de una aplicación de comercio financiero de cliente-bróker-sede, el sistema puede comprender un sistema del cliente, un sistema del bróker, un sistema del supervisor y uno o más sedes (recursos de procesamiento de datos para el comercio financiero). Un sistema del cliente puede enviar una solicitud a un sistema del bróker para que se produzcan una o más transacciones financieras. La solicitud del cliente puede indicarse como una solicitud principal, que puede transmitirse a un sistema del bróker, que puede configurarse para proporcionar una o más solicitudes secundarias relacionadas, para producir el enrutamiento de una o más transacciones financieras.
La solicitud del cliente puede indicarse como una solicitud principal, que puede transmitirse a un sistema del bróker, que luego proporciona una o más solicitudes secundarias relacionadas, para provocar el enrutamiento de una o más transacciones financieras.
El enrutamiento de una o más transacciones financieras puede realizarse en el contexto del procesamiento de una o más transacciones financieras en una o más sedes. Puede haber solicitudes que, por ejemplo, se ejecutan, se llenan parcialmente, se cancelan, se rechazan, se confirman, etcétera.
En algunas situaciones, un sistema del instructor 102 y un sistema intermediario 104 pueden operarse mediante diferentes entidades o pueden configurarse de cualquier otra manera para operarse mediante el uso de reglas en función de los intereses opuestos. Como el sistema intermediario 104 puede tener alguna discreción u opciones para el enrutamiento de una solicitud principal para su ejecución en uno o más recursos informáticos.
Por ejemplo, cuando una solicitud principal incluye un proceso de datos que se relaciona con transacciones financieras, un sistema informático del bróker intermediario puede tener varias opciones disponibles para enrutar la solicitud para su ejecución o de cualquier otra manera procesar la solicitud. En algunas jurisdicciones, las regulaciones pueden estipular que los sistemas brókers deben enrutar las órdenes de clientes teniendo en cuenta los intereses del usuario (por ejemplo, al obtener el mejor precio para el cliente) y los brókers deben seguir las instrucciones explícitas de enrutamiento de clientes (por ejemplo, el mejor precio, la mejor ejecución, el uso de técnicas de enrutamiento de nivelación de latencia). Sin embargo, en función de la complejidad y el anonimato incorporados en los sistemas actuales, es difícil o imposible verificar que se siguieron las instrucciones o los mejores intereses de un cliente. Por otra parte, en algunas situaciones, las instrucciones de un sistema del instructor pueden cumplirse y al mismo tiempo permitir cierta discreción del sistema del bróker.
En algunas situaciones, puede incentivarse a un sistema del bróker para enrutar órdenes de una manera que puede ser beneficiosa para el sistema bróker, pero puede no ser óptima para el interés del instructor. Por ejemplo, uno o más recursos informáticos de comercio financiero pueden asociarse con bolsas de valores que ofrecen descuentos y/u otros incentivos a los brókers para ejecutar las operaciones en sus bolsas de valores. En este escenario, puede incentivarse a un sistema del bróker para enrutar al menos una porción de una solicitud a un equipo informático para cobrar un reembolso que se ofrece por las bolsas de valores correspondiente.
En algunos otros escenarios, un sistema del bróker puede enrutar órdenes a otros brókers y recibir pagos adicionales al vender el flujo de órdenes a varias empresas comerciales. Por ejemplo, algunas sedes proporcionan un reembolso para aumentar los volúmenes comerciales e implementar esquemas de reembolso, como por ejemplo, un "sistema fabricante-receptor". Puede proporcionarse un descuento a un bróker por "crear" un mercado y, por otro lado, se le puede cobrar una tarifa a un bróker por "tomar" un mercado. Pueden contemplarse otros esquemas de reembolso.
Puede surgir un conflicto potencial cuando un bróker tiene la opción de enrutar una solicitud de procesamiento a un equipo informático que ofrece un reembolso, pero el equipo informático que ofrece el reembolso puede no proporcionar la mejor ejecución para el sistema instructor. También pueden contemplarse otros conflictos (por ejemplo, brókers que delegan órdenes de manera subóptima a otros brókers, o que lo hacen de manera ineficiente). Por ejemplo, un equipo informático que proporciona reembolsos al bróker puede tener largos tiempos de ejecución o latencias, velocidades de llenado de operaciones más bajas o puede ser más probable que esté sujeto a comerciantes depredadores (por ejemplo, de alta frecuencia).
La metodología específica y/o el desempeño de un bróker en particular también puede ser importante para un cliente. Por ejemplo, un cliente puede desear comparar el desempeño de un bróker con otro, al elegir proporcionar más órdenes al bróker que parece tener un mejor desempeño que otro bróker.
Dado que una solicitud del sistema instructor puede enviarse a través de múltiples sistemas intermediarios, puede involucrar muchos componentes de enrutamiento independientes y recursos informáticos, y la generación de varias solicitudes secundarias y subsecundarias, puede ser difícil o imposible ver, verificar, validar, administrar o monitorear de cualquier otra manera el enrutamiento de una solicitud de cliente. Por otra parte, puede ser difícil determinar si el precio/cantidad resultante que se obtiene en la solicitud de cliente fue favorable para el cliente en vista de las condiciones prevalecientes en el mercado, si el sistema del bróker cumplió con los estándares de desempeño o si el bróker siguió las instrucciones establecidas por la solicitud de cliente.
Otro factor en la gestión o el monitoreo de los recursos informáticos en red es la capacidad de mantener la confidencialidad del procesamiento de datos de un sistema del instructor en relación con terceros. Por ejemplo, la relación entre las órdenes del bróker y las órdenes de cliente puede usarse por un tercero para determinar varias características y/o aspectos de las órdenes, que incluyen la identidad de las partes, la información de la solicitud de operación, los algoritmos usados, cómo se dividen y enrutan las órdenes, la relación entre órdenes, etcétera. La fuga de esta información puede tener impactos potencialmente nocivos en las velocidades de llenado de operaciones y la eficacia futura de la estrategia y/o el algoritmo de enrutamiento, ya que el tercero puede realizar operaciones oportunistas en función de esta información. Los clientes pueden ser particularmente sensibles a cualquier filtración de estrategia o posición de cartera.
En términos generales, en algunas modalidades, la presente descripción proporciona sistemas, dispositivos, métodos y medios para verificar o de cualquier otra manera realizar la gestión de la ejecución de los procesos de datos en una red de recursos informáticos. En algunos casos, esta verificación puede proporcionar una indicación sobre el desempeño de un dispositivo intermediario en la ejecución de una solicitud de procesamiento de datos de un dispositivo de instrucciones y/o información relacionada con la forma en que el intermediario ha distribuido y/o enrutado la solicitud a uno o más recursos informáticos.
En algunas modalidades, los aspectos de los sistemas, dispositivos, métodos y medios que se describen en la presente descripción pueden proporcionar anonimato de la información relacionada con las solicitudes de procesamiento de datos de diferentes dispositivos de instrucciones. En algunos casos, los aspectos de la presente descripción pueden reducir la posibilidad de que un tercero pueda obtener información relacionada con las solicitudes de procesamiento de datos desde un dispositivo de instrucciones.
Los aspectos de algunas modalidades pueden involucrar la configuración y/o provisión de un sistema computarizado para supervisar el enrutamiento de órdenes, donde la función de supervisión puede realizarse mediante el uso de una o más claves que pueden asociarse con las órdenes enrutadas.
Estas una o más claves pueden protegerse, codificarse, truncarse u ofuscarse de cualquier otra manera, de manera que las claves no afecten la confidencialidad de la solicitud o la información asociada con las solicitudes. En algunas modalidades, las claves pueden usarse para codificar metadatos y datos de solicitud.
Con referencia a la Figura 1A, un sistema del instructor, por ejemplo, el sistema informático de cliente 102 incluye uno o más procesadores que pueden distribuirse entre uno o más dispositivos. Los procesadores se configuran para transmitir a un sistema intermediario (como el sistema informático del bróker 104) una solicitud principal. La solicitud principal puede incluir al menos un proceso de datos principal que puede ejecutarse en uno o más recursos informáticos (como por ejemplo las sedes 108a..n).
En algunas modalidades, el procesador instructor envía una clave de instructor (CK) al sistema informático intermediario junto con la solicitud principal. La clave de instructor y la solicitud principal pueden enviarse en el mismo mensaje. Por ejemplo, la clave de instructor puede ser una etiqueta o un valor almacenado en un encabezado u otro campo asociado con el mensaje de solicitud principal. En otro ejemplo, la clave de instructor y la solicitud principal pueden enviarse en múltiples mensajes mediante el uso de cualquier mecanismo en el que el sistema informático intermediario pueda correlacionar los dos.
En algunos ejemplos, la clave de instructor (CK) puede generarse de una manera como se describió en la presente descripción o de cualquier otra manera. En algunas modalidades, la clave de instructor (CK) puede ser única para una solicitud principal en particular, con diferentes claves de instructor que se generan para diferentes solicitudes y para enviar a diferentes dispositivos intermediarios.
El sistema intermediario, por ejemplo, el sistema informático del bróker 104, puede incluir uno o más procesadores que pueden distribuirse entre uno o más dispositivos. Los procesadores se configuran para recibir la solicitud principal y la clave de instructor CK.
Los procesadores del sistema intermediario generan una o más solicitudes secundarias para el enrutamiento a uno o más dispositivos de destino. Las solicitudes secundarias incluyen procesos de datos secundarios para ejecutar al menos una porción del proceso de datos principal. Por ejemplo, una solicitud principal puede incluir un proceso de datos para ejecutar una operación por 10000 acciones de capital ABC, y los procesadores pueden generar múltiples solicitudes secundarias para ejecutar porciones de las 10000 acciones en dispositivos de destino diferentes (como por ejemplo, recursos informáticos en bolsas de valores, otros brókers, foros privados, etcétera). En otro ejemplo, una solicitud principal puede incluir un proceso de datos para calcular 10 000 millones de cómputos, y los procesadores pueden generar múltiples solicitudes secundarias para ejecutar porciones de los 10000 millones de cómputos en diferentes dispositivos de destino (por ejemplo, recursos informáticos compartidos o distribuidos, u otros servidores informáticos en la nube o sistemas de gestión de recursos distribuidos). Cada solicitud secundaria puede incluir o de cualquier otra manera asociarse con la clave de instructor CK.
Los procesadores intermediarios se configuran para enrutar cada solicitud secundaria a un dispositivo de destino correspondiente 108 junto con la clave de instructor CK (que, en este ejemplo, también puede denominarse clave de destino).
El sistema 100A incluye un servidor del supervisor o sistema 190 que obtiene las solicitudes secundarias a través del enrutamiento de las solicitudes secundarias desde el sistema intermediario 104 y los dispositivos de destino. El servidor del supervisor puede obtener las solicitudes secundarias a través de uno o más dispositivos supervisores 106.
En algunos ejemplos, los dispositivos supervisores 106 pueden incluir uno o más dispositivos de escucha que se configuran para interceptar, escuchar, extraer o acceder de cualquier otra manera a las comunicaciones en una ruta entre el sistema intermediario 104 y los dispositivos de destino. Por ejemplo, los dispositivos de escucha pueden incluir un programa interceptor, conexiones de acceso, interceptores, monitores, colectores, extractores y similares que pueden obtener datos de solicitudes secundarias en tiempo real, con retraso y/o de forma masiva. En algunos ejemplos, el dispositivo de escucha puede ser un dispositivo físico, por ejemplo, un dispositivo de conexiones de acceso en un enlace de comunicación físico. En otros ejemplos, el dispositivo de escucha puede ser un proceso que se ejecuta en un procesador en un nodo de red que puede escuchar y transmitir copias de datos de solicitudes secundarias a un servidor del supervisor 190. En algunas modalidades, el sistema del supervisor recibe lo interceptado desde un dispositivo de escucha existente y, en algunas modalidades, el sistema del supervisor incluye el dispositivo de escucha.
En algunos ejemplos, los dispositivos del supervisor 106 pueden incluir un dispositivo proxy o intermediario que recibe solicitudes secundarias y enruta las solicitudes tanto a los dispositivos de destino como al sistema del supervisor 190.
En algunas modalidades, los dispositivos supervisores 106 pueden configurarse para eliminar la información de la clave secundaria o de destino de las órdenes secundarias, reformatear y/o aplicar cualquier instrucción de procesamiento intermedio desde el dispositivo de instrucciones o intermediario antes del enrutamiento de la solicitud secundaria a los dispositivos de destino (por ejemplo, si el destino tiene requerimientos estrictos en cuanto a cómo se formatea y/o proporciona la información, de manera que los elementos adicionales de información harían que la información no cumpliera con los requerimientos del destino (por ejemplo, una sede que solo acepta mensajes que tienen un esquema estricto y rechaza otros mensajes por estar mal formados).
En algunas modalidades, los dispositivos de destino 108 pueden procesar, ignorar o manejar de cualquier otra manera la información de la clave de destino que se incluye en las órdenes secundarias, por lo que los dispositivos supervisores 106 pueden permitir que las solicitudes secundarias se enruten a los dispositivos de destino 106 con las claves de destino intactas.
Mientras que el servidor del supervisor 190 se ilustra como un sistema separado, en algunos ejemplos, el servidor supervisor 190 puede ser uno o más procesos o dispositivos que operan en un sistema intermediario y/o un dispositivo de destino. Por ejemplo, en algunas modalidades, el sistema del supervisor puede incluir un proceso (o dispositivo) que se ejecuta en el sistema intermediario, el cual escucha o maneja solicitudes secundarias a medida que se enrutan desde el sistema intermediario.
En otro ejemplo, el sistema del supervisor puede incluir un proceso o dispositivo que opere en el dispositivo de destino, como por ejemplo, un equipo informático de la bolsa de valores de acciones. En algunos ejemplos, los propios recursos informáticos, por ejemplo, los recursos informáticos de la bolsa de valores de acciones, pueden configurarse para manejar claves de destino y pueden enviar tanto solicitudes secundarias como mensajes de respuesta al sistema del supervisor junto con las claves de destino.
En algunos ejemplos, el sistema del supervisor puede ser un sistema que se distribuye con componentes en los sistemas instructor, intermediario y de destino o se integra de cualquier otra manera con los mismos.
El sistema del supervisor 190 puede recibir y almacenar datos de solicitudes secundarias y datos asociados con las solicitudes secundarias en uno o más dispositivos de almacenamiento de datos 110. En algunas modalidades, el sistema del supervisor puede recopilar, reunir, reformatear o procesar de cualquier otra manera los datos recibidos para que sean adecuados para el almacenamiento y el acceso.
El sistema del supervisor 190 almacena los datos de solicitud recibidos junto con la(s) clave(s) de destino correspondiente. Por ejemplo, en la Figura 1A, los datos asociados con cada solicitud secundaria 1..N se almacenan junto con la clave de destino CK.
En algunas modalidades, los datos asociados con una solicitud secundaria pueden codificarse con la clave de destino o algún derivado de la misma.
En algunas modalidades, además de los detalles de la solicitud secundaria (por ejemplo, la solicitud para procesar la orden de 100 acciones de ABC en la sede 108a), los datos asociados con una solicitud secundaria también pueden incluir metadatos. En algunos ejemplos, los datos asociados con una solicitud secundaria pueden incluir una o más marcas de tiempo de cuándo el sistema del supervisor recibió/envió/reenvió la solicitud secundaria.
En algunos ejemplos, los datos asociados con una solicitud secundaria pueden incluir un identificador para identificar un mecanismo mediante el cual el supervisor obtuvo los datos de la solicitud secundaria. Por ejemplo, el identificador puede indicar que los datos de la solicitud secundaria se obtuvieron a través de un dispositivo de escucha o un dispositivo proxy. En algunos casos, el identificador puede proporcionar una indicación de que si los datos de la solicitud secundaria se obtuvieron en vivo (por ejemplo, a través de un dispositivo de conexiones de acceso) o con un posible retraso (por ejemplo, se realiza en lotes) para evaluar potencialmente la precisión de las marcas de tiempo.
En algunos casos, el identificador puede indicar si los datos de la solicitud secundaria se recibieron de forma independiente por el sistema del supervisor (por ejemplo, mediante un dispositivo de conexiones de acceso) o mediante una copia u otro mecanismo a través del sistema intermediario. Esto puede, en algunos ejemplos, proporcionar una indicación sobre el nivel de confianza o el grado en que los datos tienen el potencial de manipularse mediante el dispositivo intermediario.
En algunos ejemplos, los metadatos asociados con una solicitud secundaria pueden incluir información de tiempo/datos, tipo de transacción en la solicitud (por ejemplo, participaciones, opciones, bonos, etcétera), tipo de mensaje en la solicitud (por ejemplo, compra, venta, cotización, confirmación, etcétera), información de protocolo, región, información requerida para interpretar el mensaje, o cualquier otra información para clasificar o de cualquier otra manera relevante para una solicitud.
En algunas modalidades, los datos de solicitudes secundarias pueden incluir los datos de uno o más mensajes de respuesta de los dispositivos de destino 108 asociados con las solicitudes secundarias correspondientes. Por ejemplo, los mensajes de respuesta pueden incluir acuses de recibo, rechazos, ejecuciones, confirmaciones, órdenes abiertas, etcétera. En algunos ejemplos, los datos pueden incluir velocidades de llenado de operaciones, precios, volúmenes o cualquier otro dato adecuado para evaluar o realizar el monitoreo de la ejecución de una solicitud de procesamiento de datos.
El(los) procesador(es) del sistema del supervisor puede configurarse para comunicar los datos de solicitudes secundarias almacenadas con uno o más dispositivos solicitantes. En algunos ejemplos, los dispositivos solicitantes pueden asociarse con un sistema del instructor 102, un cuerpo regulador o cualquier otra entidad.
En algunas modalidades, el(los) procesador(es) del sistema del supervisor puede configurarse para transmitir o de cualquier otra manera hacer que los datos solicitados estén disponibles públicamente.
En algunas modalidades, el sistema del supervisor puede configurarse para enviar datos de solicitudes a los dispositivos solicitantes a medida que estén disponibles. En otras modalidades, el sistema del supervisor puede configurarse para enviar datos solo cuando un dispositivo solicitante lo solicita explícitamente (extracción). Las combinaciones y variaciones de esto son posibles.
Con el fin de preservar la confidencialidad, en algunas modalidades, el sistema del supervisor solo puede enviar datos de solicitudes secundarias correspondientes a la(s) clave(s) de destino que se proporcionan mediante el dispositivo solicitante.
En modalidades en donde el sistema del supervisor codifica los datos de solicitudes recibidos con las claves de destino correspondientes, el sistema del supervisor puede transmitir o enviar de cualquier otra manera todos los datos codificados a cualquier cantidad de dispositivos solicitantes. En algunas modalidades, los dispositivos solicitantes pueden decodificar solo los datos codificados correspondientes a una clave de destino que posee el dispositivo solicitante. Por ejemplo, el sistema del instructor 102 que ha almacenado la clave de instructor CK y sabe que está asociada con la solicitud principal particular puede identificar las porciones de los datos codificados que están asociadas con las órdenes secundarias en función de la orden principal porque son las únicas porciones que pueden decodificarse con éxito con la clave de instructor CK.
En algunas modalidades, el sistema del supervisor puede configurarse para codificar solo las porciones de los datos asociados con una solicitud. Por ejemplo, los metadatos de la región o el tipo de metadatos de la transacción pueden almacenarse sin cifrar. En algunos ejemplos, las porciones de datos sin cifrar pueden usarse como un parámetro que un dispositivo solicitante puede usar para reducir el conjunto de datos que se reciben en una solicitud.
Como se ilustra en este ejemplo y en toda su extensión, la presente descripción puede, en algunas modalidades, proporcionar procesos, sistemas e interacciones técnicas particulares entre sistemas que proporcionan un rastro virtual de la raíz de navegación o clave(s) que pueden permitir el monitoreo o la gestión de una solicitud principal y solicitudes secundarias asociadas a medida que los diferentes sistemas informáticos las distribuyen para ejecutarlas en un equipo informático.
Puede haber varios enfoques disponibles. Por ejemplo: (1) el cliente puede proporcionar una clave a un bróker para que la use en relación con las órdenes del cliente, (2) un bróker puede crear una clave para enviarla de regreso al cliente y (3) un bróker puede crear una clave específica para el bróker y usar una combinación de la clave específica del bróker y la clave de cliente para proteger la información. En algunas modalidades, la clave de cliente puede considerarse una "clave de instructor" y el dispositivo informático del cliente puede considerarse el "dispositivo del instructor".
El sistema de ejemplo 100A de la Figura 1A ilustra una posible modalidad que verifica el enrutamiento de las solicitudes de clientes. Sin embargo, como se ilustra en parte en la siguiente conclusión, puede haber diferentes implementaciones técnicas que pueden tener diferentes ventajas y desventajas en términos de velocidad de procesamiento, requisitos computacionales, integridad de los datos, niveles de confidencialidad entre los sistemas, etcétera.
Las consideraciones pueden incluir ventajas y desventajas entre la solidez del seguimiento (especialmente en topologías más complejas donde puede haber múltiples niveles de sistemas intermediarios, o distribución de solicitudes principales entre componentes informáticos dentro de una entidad, por ejemplo, diferentes motores de enrutamiento dentro de un único sistema del bróker) y la necesidad de rendimiento computacional dentro de un umbral particular (por ejemplo, en un sistema comercial donde los precios y las oportunidades de ejecución pueden ser transitorios, las demoras de milisegundos para el procesamiento de claves pueden no ser aceptables) y la interoperabilidad (por ejemplo, algunos brókers en una serie de brókers pueden configurarse para interoperar con un supervisor, mientras que otros no).
Puede que no sea conveniente revelar una relación entre un sistema instructor y las órdenes secundarias asociadas con su solicitud principal en un equipo informático (por ejemplo, de manera que una bola de valores solo tiene conocimiento de qué ordenes provienen de un bróker en particular, pero no sabe a qué sistema del cliente corresponde cada orden) o a un tercero. De manera similar, un sistema de intermediario (por ejemplo, un sistema informático del bróker) puede no desear revelar a un destino cómo se enrutan y procesan las solicitudes principales a través de un enrutador algorítmico o de orden inteligente (SOR).
En algunas modalidades, un problema técnico a resolver puede incluir cómo administrar los datos (o identificadores de los mismos) que viajan en un sistema informático en red para no exponer la identidad de un sistema del instructor, el algoritmo de enrutamiento de un sistema intermediario o las relaciones entre solicitudes secundarias, mientras que aún se proporcionan un supervisor (como se describió en la presente descripción) y/o un equipo informático para procesar o ejecutar las respectivas solicitudes secundarias, y mientras se proporciona el sistema del instructor para verificar las actividades del intermediario con respecto a una solicitud del instructor. Se debe evitar que terceros recuperen, reconstruyan o extraigan la solicitud y el historial de procesamiento de un sistema instructor y/o intermediario. En un sistema financiero, la exposición de los datos de la solicitud puede presentar riesgos para el instructor o la información confidencial y/o de propiedad del intermediario, tal como las estrategias comerciales y/o enrutamiento, las sedes preferidas, la información de la orden, etcétera.
Las posibles ventajas asociadas con algunas modalidades pueden incluir la verificación de órdenes de clientes con una exposición mínima y/o reducida de identidades, actividades y/o estrategias; la verificación de las solicitudes del sistema de instrucciones sin revelar indebidamente estrategias intermediarias y/o algoritmos; y la capacidad de realizar verificaciones y/o correlaciones entre una gran cantidad de solicitudes del sistema de instrucciones.
Sin embargo, la verificación de las solicitudes de los sistemas de instrucciones de manera segura puede requerir un nivel de facilidad y conveniencia para implementar. Puede haber varias ventajas asociadas con la el uso de la infraestructura de comunicación existente y/o sin la necesidad de implementar una infraestructura de seguridad significativa. Por ejemplo, en algunas modalidades, puede no haber necesidad de una autoridad certificadora.
Algunas modalidades que se describen a lo largo de esta memoria descriptiva pueden proporcionar arquitecturas, sistemas, métodos y/o productos de sistemas informáticos que pueden ofrecer algunos o todos los siguientes beneficios potenciales:
• puede haber flexibilidad en la implementación y/o estructura de la arquitectura y el sistema, ya que las modalidades pueden ser adecuadas para usar con varias permutaciones y combinaciones de las relaciones de instructor/intermediario/destino;
• el uso de un registro de transacciones verificable que puede generarse mediante un sistema del supervisor operativo de manera independiente y que, en algunas modalidades, puede ser útil en varios aspectos, como por ejemplo, responder a consultas de auditoría, revisiones automáticas y/o informes sobre características de enrutamiento de órdenes, etcétera;
• algunas modalidades no requieren una integración significativa de los recursos informáticos (por ejemplo, las sedes de comercio financiero), que pueden ser significativos en dependencia del número de destinos contemplados;
• algunas modalidades incluyen integración mediante recursos informáticos, lo que puede reducir/evitar la necesidad de implementar un sistema del supervisor;
• varios métodos de codificación y/o encriptación pueden ser adecuados para el uso; por ejemplo, firmas digitales, códigos simples, cifrado básico/pares de claves, el algoritmo RSA, generación de números pseudoaleatorios, etcétera, pueden usarse entre el cliente/bróker/sede;
• en algunas modalidades, los parámetros de las claves seguras se han diseñado de manera que se proporcione privacidad (por ejemplo, en algunas modalidades, incluso si se usan funciones hash bien conocidas); y
• en algunas modalidades, los sistemas, arquitecturas y métodos que se describen a lo largo de la memoria descriptiva pueden desarrollarse en vista de la necesidad de tamaños de archivo manejables, complejidad computacional y/o tiempos computacionales con el fin de, por ejemplo, mantener comunicaciones que sean manejables y/o seguridad que sea computacionalmente factible (por ejemplo, los recursos están limitados por la cantidad de tiempo disponible y la potencia de procesamiento computacional; en algunos contextos, cada nano/microsegundo cuenta, mientras que en otros, puede ser importante que el procesamiento se realice de manera receptiva para garantizar la relevancia de análisis).
Los sistemas del instructor pueden asociarse con varias entidades que pueden generar solicitudes, como por ejemplo, clientes individuales, instituciones financieras, fondos de cobertura, fondos de pensión, fondos de capital soberanos, corporaciones, sociedades, propietarios únicos, inversores institucionales, etcétera.
Los sistemas intermediarios pueden asociarse a varias entidades que pueden concertar una o más transacciones financieras en función de las órdenes de clientes, por ejemplo, un corredor de bolsa, una agencia de valores, un representante registrado, un asesor de inversiones, una casa de cambio, una casa de bolsa, entre otros. Los sistemas informáticos del bróker pueden enviar solicitudes a los dispositivos de destino directa o indirectamente a través de otros sistemas intermediarios.
Los dispositivos de destino pueden incluir recursos informáticos que pueden asociarse con varias bolsas de valores de acciones, sistemas comerciales alternativos (ATS), foros privados, instalaciones de comercio multilateral, redes de traspasos, bolsas nacionales, bolsas regionales, redes de comunicación electrónica, plataformas de comerciantes simples u otras sedes registradas o no registradas, etcétera.
En algunos ejemplos, la información solicitada puede comunicarse a través de una variedad de técnicas y/o protocolos, como por ejemplo, el protocolo de intercambio de información financiera (FIX), archivos de texto, archivos planos, archivos de bases de datos, archivos binarios, cadenas de caracteres, etcétera. La información puede comunicarse, por ejemplo, mediante el uso de varios protocolos de propiedad y/o protocolos binarios, como los que usan las bolsas de valores y/o las sedes de comercio.
En algunas modalidades, los datos también pueden cifrarse antes de la comunicación para proporcionar otro nivel de seguridad. La arquitectura puede usar varios esquemas para cifrar datos, por ejemplo, pares de claves pública/privada, etcétera.
Debe entenderse que las variaciones de diferentes aspectos de los sistemas, dispositivos, métodos y medios de ejemplo que se describen en la presente descripción pueden aplicarse, cuando sea adecuado, a cualquiera de las otras modalidades en cualquier permutación o combinación.
La Figura 1B muestra aspectos de otro ejemplo de sistema 100B y el flujo de datos para la gestión de los procesos de datos en una red de recursos informáticos.
De manera similar al ejemplo de la Figura 1A, en la Figura 1B, un sistema del instructor 102 envía una solicitud principal a un sistema intermediario 104 junto con una clave de instructor CK1. Sin embargo, en lugar de generar solicitudes secundarias, cada una tiene la misma clave de destino CK que en la Figura 1A, el sistema intermediario 104 en la Figura 1B selecciona una secuencia de claves de destino (CKi ...CKn) y asocia cada clave de destino con una de las solicitudes secundarias.
En algunas modalidades, la selección de la secuencia de claves de destino puede incluir la generación de la segunda y subsecuentes claves de destino en la secuencia mediante la aplicación de una función de codificación, como por ejemplo, una función hash hf() a la clave anterior en la secuencia.
De esta manera, los datos asociados con cada solicitud secundaria se almacenan y/o codifican con una clave de destino diferente pero relacionada.
En algunas modalidades, cualquiera de las funciones de codificación que se describen o ilustran en la presente descripción (por ejemplo, hñ, hf2, hf3) puede incluir cualquier función o algoritmo que genere una cadena pseudoaleatoria en función de una entrada, de manera que la misma entrada resulte en la misma salida de cadena pseudoaleatoria. Al aplicar repetidamente la función de codificación a la salida de cadena pseudoaleatoria, puede generarse o volverse a generar una secuencia de claves. En algunos ejemplos, la función de codificación puede generar una salida con una longitud definida en función de cualquier entrada.
Un dispositivo solicitante como el sistema del instructor 102 puede acceder y/o decodificar cada solicitud secundaria al recrear la secuencia de claves de destino al aplicar la misma función de codificación usada por el dispositivo intermediario para la clave de instrucciones que se envió junto con la solicitud principal.
Para identificar los datos de la solicitud secundaria asociados con la solicitud principal, el sistema del instructor puede enviar solicitudes que incluyan cada una de las claves de destino recreadas para recibir un conjunto de datos que incluya los datos de la solicitud secundaria correspondientes a esas claves. Alternativamente o adicionalmente, el dispositivo solicitante puede intentar decodificar un conjunto de datos público, o más ampliamente disponibles del sistema del supervisor mediante el uso de las claves de destino recreadas y las porciones decodificadas satisfactoriamente asociadas con la solicitud principal.
Dado que el dispositivo solicitante puede no saber cuántas solicitudes secundarias generó el dispositivo intermediario, el dispositivo solicitante puede configurarse para continuar solicitando y/o decodificando conjuntos de datos asociados con claves de destino adicionales en la secuencia hasta que se tenga en cuenta la solicitud principal de procesamiento de datos completa.
En algunos casos, la aplicación de diferentes claves de destino puede ofuscar la relación entre las solicitudes secundarias a el(los) dispositivo(s) de destino y/o terceros que acceden a los datos del sistema del supervisor. En otras modalidades, pueden usarse otras técnicas de selección de clave de destino. Por ejemplo, en lugar de que una función hash se comparta o conozca comúnmente entre los sistemas de instrucciones e intermediarios, en algunas modalidades, los dos sistemas pueden compartir un generador de números aleatorios o un conjunto de números aleatorios, y las claves de destino pueden generarse en función de un valor inicial o índice que se comunica con la solicitud principal.
Pueden usarse otros mecanismos en donde las claves parecen no estar correlacionadas a un tercero, pero pueden usarse por el intermediario y/o el sistema de instrucciones para identificar o generar claves relacionadas.
En algunas modalidades, las claves pueden generarse mediante el uso varias técnicas, como por ejemplo, técnicas criptográficas, funciones de codificación, pares de claves de cifrado, individualmente o en combinación. En algunas modalidades, las claves se generan mediante el uso de varias combinaciones y/o permutaciones de diferentes técnicas, junto con la aplicación de varias técnicas de ofuscación adicionales, como por ejemplo, rellenar, saltear, etcétera.
Las claves (por ejemplo, "la raíz de navegación" o las secuencias aleatorias de símbolos) y/o las técnicas de codificación/cifrado, en algunas modalidades, pueden tener una codificación en cascada y/o sucesivamente en secuencia (por ejemplo, se derivan de "derivados") la codificación se realiza sobre ellos de manera que las propiedades de la codificación en capas pueden utilizarse ventajosamente. Por ejemplo, una clave "valor original" particular puede recodificarse (por ejemplo, volver a codificar) con una función de codificación repetidamente para generar varias claves relacionadas que serían difíciles de reproducir para un tercero sin conocer el "valor inicial" o una clave dentro de la cadena de claves y/o la técnica de codificación usada (y los esquemas de saltos/relleno de los mismos). De manera similar, puede combinarse más de una clave para crear "claves secundarias" a partir de más de una clave de "valor inicial" en cada nivel, lo que ofusca aún más la capacidad de que terceros identifiquen asociaciones. Dichas claves pueden considerarse "claves de índice" y, por ejemplo, pueden generarse mediante el uso de una "clave de instrucciones" (por ejemplo, una clave que proporciona un cliente) y una "clave de intermediario" (por ejemplo, una clave que proporciona un bróker).
En algunas modalidades, las claves de destino pueden, por ejemplo, establecerse al seleccionar (y/o generar) una secuencia de claves de un grupo de claves disponibles, que se seleccionan en función de una metodología y/o método particular. Dicha metodología y/o método puede, en algunas modalidades, compartirse entre un sistema del supervisor, un dispositivo del instructor (por ejemplo, un dispositivo del cliente), dispositivos del bróker, etcétera.
Las técnicas criptográficas que se usan incluyen el cifrado y/o el uso de la codificación segura. Pueden usarse varias funciones unidireccionales y/o bidireccionales, por ejemplo, en algunas modalidades, el texto cifrado puede procesarse para derivar la cadena de origen, mientras que en otras modalidades, el texto cifrado no puede usarse para derivar la cadena de origen (por ejemplo, una función hash unidireccional, donde los intentos de invertir la función hash a partir de un resultado, por ejemplo, una suma de comprobación puede producir uno o más resultados en conflicto). Como ejemplos, las funciones criptográficas pueden incluir algoritmos hash seguros (SHA), el algoritmo de resumen de mensajes (MD), etcétera.
La selección de una técnica criptográfica puede ser importante en dependencia del número de posibles entradas esperadas y salidas requeridas. Por ejemplo, las colisiones de hash pueden generar resultados de verificación inexactos o procesamiento adicional.
Las claves pueden comprender, por ejemplo, por una serie de códigos (por ejemplo, números aleatorios) que pueden generarse previamente y compartirse entre un cliente y un bróker. El bróker puede asociar una orden de salida o un conjunto de instrucciones que genera el bróker mediante el uso del código de acuerdo con su diseño. En algunas modalidades, el código es simplemente un conjunto de números generados predefinidos que se comparten entre un bróker y un cliente. Los números pueden ser aleatorios (por ejemplo, ambas partes pueden compartir libros de códigos) que se eligen en función de un cifrado y/o algoritmo matemático, etcétera, y se proporcionan en forma de tabla de consulta. Una debilidad potencial con tal enfoque puede ser la facilidad de descifrado y/o acceso malicioso en vista de las técnicas modernas de descifrado de códigos y predicción de códigos (por ejemplo, ataque de fuerza bruta mediante el uso de un diccionario). Sin embargo, las claves generadas previamente pueden reducir los tiempos de cálculo requeridos para seleccionar/generar claves de destino. No es raro que una solicitud principal se distribuya en miles de solicitudes secundarias, y la generación secuencial sobre la marcha de claves de destino puede generar demoras que no son aceptables, especialmente para las solicitudes de procesamiento de datos sensibles al tiempo, tal como las solicitudes de operaciones financieras. Para aumentar la seguridad, las secuencias de claves generadas previamente pueden cambiarse periódicamente, y la generación de estas claves puede, en algunas modalidades, realizarse fuera de horas de menor actividad u horas en las que no se procesan las solicitudes comerciales.
En algunas modalidades, el sistema 100B puede usar una única CK maestra inicial por instructor y continuar el uso de las claves subsecuentes en la secuencia de la CK maestra para órdenes subsecuentes. En algunas modalidades, ese sistema 100B puede usar una CK separada por solicitud principal. Con el fin de reducir la cantidad de tráfico de datos entre el instructor y el intermediario, solo puede comunicarse una sola CK entre el sistema instructor y el intermediario a partir de los cuales el sistema receptor puede determinar todas y cada una de las claves secundarias en función de la única CK. En algunos ejemplos, el sistema intermediario también puede comunicar al sistema del instructor una cantidad de solicitudes secundarias que se generaron para una solicitud principal, de manera que el sistema del instructor pueda determinar cuántas claves secundarias se deben volver a crear y/o cuántas solicitudes secundarias identificarse en un conjunto de datos del sistema del supervisor para la verificación del enrutamiento. En otra modalidad, un sistema del instructor puede enviar una solicitud principal junto con una secuencia de claves de instructor generadas previamente para usar en la selección de claves de destino. En algunos casos, esto puede reducir o eliminar el tiempo de procesamiento que requiere el sistema intermediario para generar claves de destino que pueden mejorar los tiempos de procesamiento y mejorar potencialmente los resultados de los procesos de datos ejecutados.
En algunas modalidades, donde se reduce o no se emplea el anonimato, las claves pueden estar disponibles públicamente o compartirse con terceros particulares, tal como en el caso en que se requiera la supervisión de un tercero, la supervisión del gerente de bróker u otro gerente, o se requiere o desea la supervisión pública del enrutamiento de solicitudes.
Un sistema del instructor 102 puede configurarse para recibir los datos de solicitud del sistema del supervisor, descifrar los datos y/o correlacionar los datos con los datos de la solicitud principal que se mantienen en el registro de solicitudes o transacciones del sistema del instructor (por ejemplo, en la base de datos). La correlación con los datos y las solicitudes principales puede incluir la determinación de las relaciones entre varias solicitudes secundarias y/o entre las solicitudes principales y las solicitudes secundarias.
En algunas modalidades, el sistema del instructor puede configurarse para determinar si las solicitudes secundarias enviadas por los sistemas intermediarios 104 se enrutaron de acuerdo con una o más instrucciones de enrutamiento, o de acuerdo con las condiciones para la mejor ejecución de la orden en relación con las condiciones del mercado predominante en torno al momento de la orden.
En algunas modalidades, el sistema del instructor 102 puede incluir uno o más dispositivos o procesadores que se configuran para gestionar las solicitudes de procesamiento de datos. Por ejemplo, los procesadores pueden, independientemente de cualquier entrada de un usuario del sistema del instructor, generar/seleccionar claves de instructor para enviar con solicitudes principales, acceder a datos del sistema del supervisor, asociar los datos de solicitudes secundarias con solicitudes principales en función de las claves de instructor, y generar informes de verificación. Por ejemplo, el sistema del instructor 102 puede incluir un programa informático o un dispositivo físico que puede realizar estas funciones de forma independiente o transparente a un sistema del instructor tradicional. En algunas modalidades, puede que no haya un componente del supervisor separado. Más bien, los sistemas informáticos de destino 108 (por ejemplo las sedes 108a..n) pueden configurarse para proporcionar datos de órdenes secundarias (por ejemplo, datos de mercado, instrucciones de órdenes) que se cifran mediante el uso de una o más claves de destino. Los sistemas informáticos de destino 108 pueden configurarse para comunicar la información a los sistemas del instructor 102. Por ejemplo, los sistemas informáticos de bolsas de valores pueden configurarse para publicar públicamente todas las transacciones (que incluyen órdenes, cancelaciones, reemplazos y rellenos) y también para cifrar las transacciones con las claves correspondientes que se reciben desde el bróker. Los sistemas del instructor pueden luego acceder a las transacciones publicadas públicamente, descifrarlas mediante el uso del conjunto de claves del sistema del instructor y/o identificar todas las transacciones relacionadas con el instructor.
Algunas modalidades pueden incentivar a varios participantes a desempeñar de sus respectivos roles, por ejemplo, un instructor puede generar claves para verificar que un intermediario está realizando las acciones especificadas (puede usarse para verificar no solo las sedes sino también cualquier otra directiva de orden). Un instructor puede, por ejemplo, usar el sistema por orden y/o incluir instructores de solicitud que indiquen si usar o no las funciones de supervisor del sistema 100A, o en qué medida.
Con respecto a los intermediarios, la negativa a generar las secuencias de claves y asignarlas a las solicitudes puede percibirse por los instructores como una admisión de no seguir las directivas del instructor y podría resultar en la pérdida del flujo de solicitudes/órdenes. Los intermediarios que pueden ser objeto de auditorías de infracciones reglamentarias pueden usar potencialmente el sistema para ayudar a satisfacer los requisitos reglamentarios y de auditoría. Con respecto a los recursos informáticos de destino, puede haber algunas sedes que deseen proporcionar capacidades a sus clientes para poder verificar que las solicitudes que el instructor pretendía enrutar al centro se enrutaron correctamente por el intermediario.
El sistema puede implementarse de varias maneras, por ejemplo, una implementación basada en proxy de red, en donde puede configurarse un proxy de red del lado del instructor, seleccionar una BK0 y generar acuses de recibo (ACK), y/o un proxy de red del lado del destino/sede que puede configurarse para generar una DK/AI, formar una clave (por ejemplo, una clave de cliente y/o varias claves de bróker) que se recibe y se inserta en la etiqueta saliente.
El sistema puede usarse junto con varios sistemas que pueden configurarse para proporcionar varias funciones de enrutamiento, como por ejemplo, algoritmos de enrutamiento inteligente o sincronización de órdenes. En algunos ejemplos, los instructores pueden incluir instrucciones para usar dichas funciones en las solicitudes principales. Aunque se describen en el contexto de la validación de que las órdenes secundarias se ejecutaron de acuerdo con las mejores prácticas de ejecución con respecto al cliente, algunas modalidades también pueden proporcionar la validación o verificación de que los términos de ejecución de las órdenes favorecieron a una parte distinta o adicional al cliente. Los términos de ejecución que favorezcan a una o más de las partes pueden incluir al menos una de las oportunidades para que la parte respectiva reciba un mejor precio que el cotizado actualmente, la velocidad de ejecución y la posibilidad de que se ejecute la operación.
La Figura 2 muestra aspectos de otro sistema 200 de ejemplo y los procesos de gestión de flujo de datos en una red de recursos informáticos.
La arquitectura de ejemplo en la Figura 2 puede proporcionar potencialmente un nivel adicional de seguridad que puede emplear el intermediario para aumentar el anonimato de la solicitud en el nivel de destino. En algunas modalidades, esto puede explicar que los sistemas del instructor seleccionen las claves de instructor potencialmente débiles.
Los sistemas intermediarios 104 pueden configurarse para asignar una clave de intermediario (BK1) a cada solicitud principal y comunicar esa clave de intermediario a los sistemas del instructor 102 (por ejemplo, junto con una comunicación de acuse de recibo de una solicitud principal).
De manera similar a la selección de claves en función de la clave de instructor como se describió anteriormente y en la presente descripción, los sistemas intermediarios 104 pueden configurarse para seleccionar una secuencia de claves de intermediarios en base a una función de codificación, por ejemplo, una función hash.
En algunas modalidades, el sistema intermediario puede seleccionar una clave de intermediario (BKi ,...,BKn) para cada solicitud secundaria que genera. Cada clave de intermediario puede fusionarse con la clave de instructor (CK1) recibida junto con la solicitud principal mediante el uso de una función de combinación. Los resultados de las combinaciones se convierten en las claves de destino (DKi ,...,DKn) para el enrutamiento con las respectivas solicitudes secundarias. En algunos ejemplos, cualquiera de las funciones de combinación que se describen en la presente descripción puede ser una función XOR, una concatenación, una función hash o cualquier otra función para la codificación dos claves juntas. En algunos ejemplos, las funciones de combinación que se describen en la presente descripción pueden simplemente agregar o combinar porciones de las dos claves para formar una única clave combinada.
Para identificar los datos de la solicitud del servidor del supervisor que está asociado con una solicitud principal, el dispositivo solicitante/instructor genera una secuencia de claves de destino en función de la clave de instructor de la solicitud principal y la clave de intermediario recibida del sistema intermediario. Con esta secuencia, el dispositivo solicitante/instructor puede intentar acceder y/o decodificar los datos del servidor del supervisor hasta que se identifiquen las solicitudes secundarias que representan la solicitud principal.
En otras modalidades, las claves de instructor de una secuencia de claves de instructor pueden combinarse con claves de intermediarios de una secuencia de claves de intermediarios para generar claves de destino. Por el contrario, en algunas modalidades, una única clave de intermediario puede fusionarse con cada una de una secuencia de claves de instructor para generar las claves de destino.
En algunos ejemplos, la combinación de dos claves, como se ilustra en el ejemplo de la Figura 2, puede disminuir la vulnerabilidad de múltiples claves y/o sus funciones de generación (por ejemplo, hf2y hf3) debe comprometerse para recrear las claves de destino.
Además, la arquitectura de ejemplo de la Figura 2 también puede evitar la exposición de la secuencia de solicitudes secundarias que pertenecen a una única solicitud del sistema de instructor, lo que podría reducir la exposición de los algoritmos de brókers y las técnicas de enrutamiento inteligente de órdenes (SOR) a los sistemas del supervisor o de destino.
La Figura 4 muestra otro ejemplo de sistema 400 en donde el dispositivo del instructor no genera ni comunica una clave de instructor al dispositivo intermediario. En su lugar, el sistema de intermediario 104 puede generar una clave de instructor (BK1) y comunicarla al sistema del instructor en un mensaje de acuse de recibo o de cualquier otra manera. El proceso/sistema operará de manera similar al sistema de la Figura 1B, con el sistema del instructor que se configura para acceder y/o decodificar los datos de la solicitud secundaria asociados con la solicitud principal mediante el uso de la clave de instructor/destino (BK1) que se recibe del sistema de intermediario o derivados del mismo (por ejemplo, hashes de la clave de instructor/destino original para obtener las claves subsecuentes en la secuencia).
Dado que el cálculo de las claves secundarias/derivadas puede requerir recursos computacionales significativos, en algunas modalidades, las claves pueden calcularse previamente. Por ejemplo, en algunas modalidades como se describe en la presente descripción o de cualquier otra manera, las secuencias de claves pueden generarse y compartirse entre el instructor y los sistemas de intermediarios antes de cualquier procesamiento de solicitud principal.
De manera similar, en algunas modalidades, una serie de claves iniciales de instructor (CK1) puede comunicarse entre los sistemas del instructor e intermediario al comienzo o al final de un día o de cualquier otra manera antes de las órdenes actuales, con lo cual el sistema de intermediario puede configurarse para precalcular series de CKN+1y almacenarlas para recuperarlas rápidamente.
Como se describió en los ejemplos de la Figura 2, en algunas modalidades, las secuencias de las claves de instructor (CK 1+1) no pueden usarse para generar claves de destino. En cambio, una única clave de instructor (CK) puede combinarse con una serie de claves de intermediarios (BKn) mediante el uso una función de combinación, como por ejemplo, la función hashhfi()para generar una serie de claves de destino (por ejemplo, DKn+1 = hfi (CK, BKn)). En estas modalidades, dado que las claves de intermediarios (BKn) no confían en la clave de instructor del sistema del instructor, el sistema de intermediario puede configurarse para precalcular secuencias de claves de intermediarios por adelantado.
La Figura 5 muestra otro ejemplo de sistema 500 en donde el dispositivo del instructor no genera ni comunica una clave de instructor al dispositivo intermediario. En esta modalidad de ejemplo, de manera similar a los ejemplos de la Figura 4, el sistema del instructor se configura para enviar una solicitud principal al sistema de intermediario sin una clave. El sistema de intermediario se configura para seleccionar tanto una clave de instructor (CK) como una secuencia de claves de intermediarios (BKn) con las que puede generarse una secuencia de claves de destino con una función de combinación. La clave de instructor (CK) y al menos una clave de intermediario inicial (BK1) se comunican de regreso al sistema del instructor con un acuse de recibo u otro mensaje. En algunas modalidades, esto puede aliviar la necesidad de configurar o actualizar un sistema del instructor para generar cualquier clave. En algunas modalidades, dado que tanto las claves de instructor como las claves de intermediarios se generan mediante el sistema de intermediario, el sistema de intermediario puede configurarse para precalcular secuencias de claves de destino, de esta manera se reduce o elimina cualquier retraso de tiempo de ejecución requerido para generar las claves de destino.
La Figura 6 muestra otro ejemplo de sistema 600 para la gestión de los procesos de datos en una red de recursos informáticos. En esta modalidad de ejemplo, no todo el flujo de órdenes de solicitud de los brókers a los dispositivos de destino pasará por el sistema del supervisor, ya que los brókers pueden optar por omitir el enrutamiento del supervisor y pueden enviar solicitudes directamente a las bolsas de valores y/u otras sedes.
Por ejemplo, los sistemas de intermediarios pueden pasar solicitudes internamente y/o enrutarlas a grupos foros privados. Sin embargo, puede ser ventajoso para el instructor tener acceso al mayor porcentaje posible de su flujo de solicitudes a través del sistema del supervisor.
En algunas modalidades, los sistemas de intermediarios se configuran para enviar copias de solicitudes secundarias que pueden enrutarse y/o procesarse internamente (como solicitudes de órdenes pasadas o de foros privados internos) al sistema del supervisor. En algunas modalidades, los dispositivos de destino, por ejemplo, las sedes de comercio financiero, pueden configurarse opcionalmente para enviar copias de las solicitudes secundarias recibidas y/o mensajes de respuesta a las solicitudes secundarias. Estas copias pueden contener las claves de destino que se envían con las solicitudes secundarias para que el mecanismo pueda procesarse y almacenarse como datos de solicitudes secundarias que se reciben a través de otros mecanismos. Como se describe en la presente descripción, los sistemas informáticos del supervisor 106 pueden configurarse para almacenar datos de solicitudes secundarias que incluyen un indicador que identifica la fuente de los datos. En algunos casos, estos indicadores pueden permitir que los clientes evalúen la confiabilidad y/o precisión de los datos.
En algunas modalidades, el uso de copias también puede usarse cuando los dispositivos de destino (como por ejemplo, sedes o brókers subsecuentes en un entorno de múltiples saltos) no se configuran para manejar claves de destino u otros datos de supervisión.
En algunas modalidades, las copias pueden ser el único mecanismo mediante el cual el sistema del supervisor 190 puede recibir datos de solicitud, por ejemplo, cuando no hay un proxy o dispositivo de escucha entre el sistema de intermediario 104 y el de destino 108 como es el caso, por ejemplo, de la solicitud secundaria 1 en la Figura 6. En algunos ejemplos, los sistemas de intermediario y/o de destino pueden configurarse para enviar copias incluso cuando hay un componente del supervisor 106 entre los dos sistemas.
Soporte Multisalto
En algunas modalidades, los aspectos de las modalidades que se describen en la presente descripción pueden aplicarse a escenarios donde puede haber más de un sistema de intermediario (por ejemplo, el de bróker) que actúa entre un sistema del instructor (por ejemplo, el de cliente) y un sistema del destino (por ejemplo, el de las sedes). La Figura 7 es un diagrama esquemático de bloques que muestra un sistema de ejemplo 700 que involucra múltiples sistemas de intermediarios 106 entre un sistema de instructor original y los recursos informáticos de destino final. En la Figura 7, pueden comunicarse varias claves entre diferentes sistemas junto con, o en asociación con diferentes solicitudes. En algunos ejemplos, las claves pueden incluirse como etiquetas o campos que se incluyen o transmiten junto con las solicitudes. Como referencia, las ETIQUETAS en la Figura 7 se han indicado como aguas abajo (TAGa) y aguas arriba (TAGb); por ejemplo, la TAGa incluye la CK, DK, Al que se transmiten hacia adelante desde un sistema del instructor (por ejemplo, desde un sistema del cliente o un sistema del bróker anterior en la cadena) a un sistema de intermediario (por ejemplo, un bróker siguiente); y la TAGb incluye la BK que se transmite hacia atrás desde un bróker (por ejemplo, a un sistema o componente de instructor 102, o a un bróker aguas arriba). Algunos de estos sistemas de intermediarios pueden configurarse para operar con los sistemas informáticos del supervisor 106 y, por lo tanto, es posible que deban ser capaces de proporcionar y/o generar información de identificación de la solicitud de orden (por ejemplo, en forma de claves de identificación cifradas) para ayudar en el seguimiento aguas abajo y/o análisis de órdenes relacionadas con la orden de origen del cliente.
"Multisalto" puede ser una capacidad del sistema, en donde el sistema facilita el enrutamiento de una solicitud a través de más de un sistema de intermediario.
Las solicitudes de procesamiento de datos derivados pueden asociarse entre sí, por ejemplo, una solicitud puede tener una "solicitud secundaria" relacionada, una "solicitud subsecundaria" relacionada, una "solicitud inferior a la subsecundaria" relacionada, etcétera. De manera similar, las solicitudes que se han usado para solicitudes secundarias derivadas pueden denominarse solicitudes principales, solicitudes primarias, etcétera.
En algunas modalidades, los sistemas en la ruta de múltiples saltos pueden configurarse para realizar las funciones de un dispositivo del instructor, un dispositivo intermediario y/o un dispositivo de destino. Por ejemplo, el sistema del cliente puede actuar como un sistema del instructor y generar solicitudes principales para el sistema del Bróker A que actúa como un sistema de intermediario y enruta las solicitudes secundarias resultantes al Bróker B que actúa como el dispositivo de destino. El sistema del Bróker A también actúa como un sistema del instructor y genera solicitudes secundarias/de instructor para el sistema del Bróker B que actúa como un sistema de intermediario y enruta las solicitudes subsecundarias/secundarias a las sedes que actúan como dispositivos de destino. Como se ilustra en la Figura 7, el sistema del supervisor puede obtener datos de solicitudes de uno o más dispositivos a través del enrutamiento entre estos saltos en el sistema 700.
Por ejemplo, el Bróker A podría recibir una orden de un cliente y luego enrutar la orden completa o una porción de la orden a través del Bróker B. En teoría, el sistema puede, por lo tanto, dar cuenta de un escenario de orden arbitrariamente complejo en el que el Bróker A enruta a múltiples brókers y luego uno o más de ellos se dirigen a otro bróker, etcétera. Las transacciones que involucran al Bróker A y al Bróker B pueden, por ejemplo, supervisarse mediante un servidor del supervisor, que puede incluir un sistema informático del supervisor 190 y/o componentes del supervisor 106 como se describió anteriormente o de cualquier otra manera. Aunque la estructura de la Figura 7 se ilustra como una estructura lineal de saltos múltiples por simplicidad, en otros ejemplos, la estructura puede ser similar a un árbol, cíclica o cualquier otra disposición de los nodos del sistema.
En algunas modalidades, un dispositivo del instructor puede configurarse para enviar una solicitud principal directamente a un recurso informático de las sedes de destino sin ningún sistema de intermediario en el medio. En algunos ejemplos, el sistema de supervisor puede recibir adicionalmente estos datos de solicitud para proporcionar una imagen más completa de las actividades y/o el rendimiento de la solicitud de un sistema del instructor. Por ejemplo, esto puede proporcionar una comparación de tiempo, eficacia del cumplimiento de solicitudes, etcétera. Los aspectos de saltos múltiples pueden proporcionarse a través de uno o más servidores proxy adaptados para facilitar la generación, asociación y/o seguimiento de varias claves criptográficas que pueden propagarse a través del enrutamiento de la orden y/o sus partes constituyentes. La propagación de las claves criptográficas puede incluir la derivación de las claves criptográficas aguas abajo, en donde en algunas modalidades, la derivación de las claves aguas abajo incluye al menos el procesamiento de una o más claves aguas arriba.
Por ejemplo, desde la perspectiva de un bróker arbitrario en la cadena de brókers, un bróker aguas arriba puede considerarse un "dispositivo del instructor", que luego se asocia con al menos una clave de instructor y una solicitud principal para la ejecución. El sistema informático de bróker puede recibir la clave de instructor y la solicitud principal para la ejecución, y el sistema informático del bróker puede generar al menos una solicitud secundaria para la ejecución que se proporcionará a un dispositivo de destino (que puede ser una sede, u otro bróker aguas abajo). Esta solicitud secundaria de ejecución puede asociarse con una "clave de destino", que se genera al menos en función de la "clave de instructor".
Como se describió en la presente descripción con respecto a otros ejemplos, la solicitud secundaria para la ejecución puede enrutarse al dispositivo de destino, y la solicitud secundaria para la ejecución puede, en algunas modalidades, enrutarse de manera que el servidor del supervisor pueda obtener la información asociada con la solicitud secundaria, que luego almacena y/o pone a disposición la información de ejecución (por ejemplo, acuses de recibo, órdenes enviadas, confirmaciones, marcas de tiempo, identificador para el mecanismo de recopilación del supervisor, etcétera) para análisis futuros.
En consecuencia, puede haber más de un bróker en una cadena de procesamiento de órdenes, donde un Bróker A podría enrutar órdenes a través de un segundo Bróker B. Puede haber cualquier cantidad de brókers, o "saltos", en tal cadena. Los sistemas informáticos del supervisor 106 pueden usarse, en algunas modalidades, para monitorear estas actividades que surgen de la orden inicial del cliente al Bróker A. Si el Bróker B no está habilitado para la operación con los sistemas informáticos del supervisor 106, la arquitectura puede configurarse para operar como si el Bróker B fuera la sede, y las actividades del Bróker A pueden monitorearse como se describió en algunas otras modalidades.
Sin embargo, si el Bróker B está habilitado para la operación con los sistemas informáticos del supervisor 106, entonces las acciones de llenado de órdenes del Bróker B deberían relacionarse con las acciones de llenado de órdenes del Bróker A en los sistemas informáticos de supervisores 106. Dicha solución debería ser capaz de funcionar dado que cada bróker no sabe necesariamente dónde se encuentra en la cadena de brókers, y la cadena de brókers puede ser un árbol de brókers, no una cadena lineal. Además, puede haber una importancia asociada con el mantenimiento de la confidencialidad del bróker (por ejemplo, evitar que un bróker aguas abajo pueda descifrar el algoritmo de enrutamiento de un bróker aguas arriba). Configurar los sistemas informáticos del supervisor 106 para que puedan soportar dicho escenario puede aumentar la complejidad en algunas implementaciones, pero también proporciona la oportunidad de desarrollar una solución robusta que proporcione verificación del enrutamiento de órdenes mientras mantiene la confidencialidad entre los brókers y/o el público en general.
Para proporcionar más detalles en algunas modalidades, el cliente y el Bróker A se comunican mediante el uso de una clave de cliente (CK). El Bróker A puede enviar órdenes al Bróker B mediante el uso de una clave de destino A (DKa). El Bróker B puede enviar órdenes al bróker C mediante el uso de una clave de destino B (DKb), etcétera. Pueden proporcionarse servidores proxy de puerta de enlace o dispositivos de escucha para monitorear la comunicación entre cada par de brókers, al guardar la información en los sistemas informáticos del supervisor 106. El proxy puede implementarse en forma de equipamiento o de programa informático (o una combinación de los mismos) y puede estar físicamente presente en la salida de un bróker, o en la entrada de otro bróker, o en ambos, o puede ubicarse de forma remota desde ambos (por ejemplo, a través de una red). La misma CK podría usarse entre cada salto, pero esto puede no ser tan efectivo para ocultar las actividades comerciales del cliente.
Cuando el Bróker A y el Bróker B están disponibles para usar con el sistema informático del supervisor 106, cualquier dato específico del sistema informático del supervisor 106 puede comunicarse entre los brókers en una etiqueta de metadatos específica para cada orden individual enviada desde el Bróker A al Bróker B.
Con referencia a la Figura 7, el Bróker A puede enviar una orden al Bróker B a través de los sistemas informáticos del supervisor 106. El Bróker A copia la DK en la TAGa (la misma etiqueta que usan los clientes para enviar la CK); esto indica a los sistemas informáticos del supervisor 106 que se trata de un mensaje de varios saltos y permite que el Bróker B lo trate como si fuera un mensaje de un cliente. El Bróker B puede transmitir una ACK del mensaje con una clave de intermediario BK.
En consecuencia, el sistema del instructor 102 puede recibir la BKa desde el Bróker A, calcular AIa y DKa , consultar el almacenamiento de datos del supervisor con IAa, descifrar las órdenes y respuestas entre el Bróker A y B, extraer del mensaje la ACK del Bróker B al Bróker A la clave BKb, y/o calcular AIb y DKb.
Cuando un cliente desea identificar las órdenes enrutadas en función de las instrucciones del cliente, los sistemas informáticos de cliente 102 pueden usar el componente informático de cliente para consultar el almacenamiento de datos asociado con los sistemas informáticos del supervisor 106 con IAb y descifrar las órdenes y respuestas entre el Bróker B y la(las) sede(s) 108a..108n.
En este ejemplo, inicialmente, el Bróker A recibe una orden de un cliente y recibe una etiqueta llamada TAGa del cliente, que incluye la CK de cliente, que a su vez puede generarse mediante el sistema informático del supervisor 106.
El Bróker A coloca una orden con el Bróker B para rellenar la solicitud de la orden del cliente. Al hacerlo, el Bróker A devuelve una etiqueta llamada TAGb al Cliente que contiene una clave de bróker para el Bróker A (BKa1). El bróker A también genera la DKa y la IAa (índice anónimo) en función de la CK y la BKa1, e incluye la DKa y la IAa en su propia nueva ETIQUETAa.
La ETIQUETA del brókerA luego se envía con la orden al Bróker B. El sistema informático del supervisor 106 registra la orden y la ETIQUETAa en su base de datos. El Bróker B recibe la orden y repite el proceso, mediante el uso de la DKa que se recibe como si fuera la CK.
El Bróker B luego genera la DKb y la IAb en función de la DKa y su propia clave de bróker BKb1. El Bróker B envía de regreso la ETIQUETAb que contiene BKb i , que se almacena en la base de datos del sistema informático del supervisor 106 como confirmación de que la orden se recibió o llenó, y el proceso continúa hasta que se alcanza la sede final.
Como cada DK subsecuente se relaciona con la DK o CK que le precedió inmediatamente, el cliente puede consultar la base de datos del sistema informático del supervisor 106 para encontrar cada mensaje de la orden relacionada. Si una BK se determina para asociarse con el mensaje Al almacenado en la base de datos, la computadora del cliente se configuraría para determinar la próxima DK y consultar la base de datos para el siguiente mensaje de la orden mediante el uso de la DK conocida y la BK asociada recuperada de la base de datos.
Clave del Bróker A, que se recibe en la primera ETIQUETAb del Bróker A puede usarse para consultar la base de datos del sistema informático del supervisor 106 para los Al del Bróker A. En respuesta, el cliente puede recibir todos los mensajes y acuses de recibo en la base de datos provenientes del Bróker A. La computadora del cliente, un proxy del sistema informático del supervisor 106 con el que interactúa, o la base de datos del sistema informático del supervisor 106 puede realizar una o más etapas de procesamiento (por ejemplo, extracción, transformación, carga, cálculo, determinación) para identificar cuáles de todos los mensajes y acuses de recibo están asociados con la orden inicial del cliente.
Como puede haber múltiples saltos de brókers, en una disposición de cadena lineal, ciclo o árbol ramificado, para cumplir con una orden de un único cliente, el sistema informático del supervisor 106 puede configurarse para seguir cada rama de la actividad del bróker en la base de datos del sistema informático de supervisor 106 para volver a crear todas las actividades del bróker para una orden de cliente en particular.
Por lo tanto, el sistema puede seguir una cadena de actividad de bróker en la base de datos hasta que la cadena termina en un recurso informático de destino, por ejemplo una sede (por ejemplo, un establecimiento de procesamiento de solicitudes de órdenes, una bolsa de valores de acciones, un foro privado, un sistema de comparación de ordenes). Esto podría ocurrir cuando no hay DK presente con un Al almacenado en la base de datos. Para las actividades de llenado de órdenes entre brókers, la respuesta de confirmación de un bróker que ejecuta una orden puede incluir la clave BK del bróker.
Es posible que las sedes no tengan necesariamente ninguna capacidad de verificación de órdenes, y es posible que no respondan al bróker inmediatamente anterior con ninguna confirmación que contenga una clave adicional. En estos escenarios, la base de datos del sistema informático del supervisor 106 solo habría almacenado la IA del bróker inmediatamente anterior a la sede sin IA asociada. Puede configurarse un proxy para interpretar esa situación como el punto final para esa orden en particular.
Como cada bróker puede enviar partes de la orden de un cliente a más de otro bróker para que la llenen, pero esto no necesariamente ha sido comunicado al cliente, el proxy puede configurarse para rastrear y/o monitorear (por ejemplo, buscar) múltiples órdenes secundarias mediante el uso de las mismas CK y BK iniciales y luego las mismas DK y BK. Puede haber múltiples entradas en la base de datos del sistema informático del supervisor 106 indexadas por la misma combinación de la DK/AI. Cada entrada puede recuperarse y analizarse mediante el proxy.
En algunos casos, puede haber lagunas en los mensajes de ordenes almacenados en la base de datos del sistema informático del supervisor 106. El proxy no necesariamente debe terminar de buscar mensajes de ordenes si no puede encontrarse un Al en la base de datos, especialmente en los casos en que el proxy pueda conocer o deducir la Al y/o la DK para mensajes de ordenes subsecuentes. Por ejemplo, cada bróker puede configurarse para comunicar las Al, BK, DK o cualquier combinación de las mismas al bróker o al cliente anterior en la cadena, posiblemente al reenviar en última instancia todo el camino de regreso al cliente.
Entonces, el cliente puede consultar la base de datos del sistema informático del supervisor 106 para todos los mensajes de órdenes que deberían haberse generado y almacenado en la base de datos. Si no puede encontrarse un mensaje de orden en particular, el cliente aún puede consultar todos los demás mensajes de órdenes esperadas. Ejemplos de posibles casos finales para consultar la base de datos para mensajes de órdenes pueden incluir:
(1) orden completada en su totalidad (se encontraron mensajes de relleno para cada orden)
a. si no, la orden no se rellena completamente (por ejemplo, no se rellena al 100%):
i. el bróker permite al cliente recrear las claves de bróker con hash
ii. consultar la base de datos hasta que deje de ver una clave 1. El bróker puede haber omitido una clave Ni. el bróker puede enviar al cliente un límite de clave de terminal para parar de buscar
(2) el período de tiempo de la orden ha expirado;
(3) la orden ha sido cancelada; y
(4) el cliente pierde la conectividad con el bróker.
Los mensajes del terminal pueden almacenarse en la base de datos o enviarse de regreso (por ejemplo, enviarse/transmitirse) al cliente. Generalmente, el cliente (o el proxy) puede continuar codificando las claves de bróker (por ejemplo, buscar) mensajes de órdenes en la base de datos mediante el uso de las claves hash hasta que se encuentre un espacio en la base de datos. El cliente/el proxy puede procesar otro número de (por ejemplo, 20-30) claves de bróker para ver si hay algo más, y luego detenerse si no se encuentra nada.
Si el bróker envía todas las claves de bróker usadas al cliente, en lugar de dejar que el cliente las vuelva a crear, entonces el cliente solo verá lo que el bróker quiere que vea el cliente. Es posible que otras actividades del bróker aún se almacenen en la base de datos, pero es posible que el cliente no las pueda localizar. Cuando el cliente se configura para generar o volver a crear claves de bróker, la arquitectura proporciona mayores oportunidades para que el cliente controle las actividades del bróker mediante el uso de varias claves.
Por ejemplo, el Bróker A podría eliminar una ruta de orden de la vista del cliente (por ejemplo, una ruta que proporcionó una ganancia al Bróker A) si el Bróker A solo envía las claves de bróker y no permite que el cliente regenere todas las claves que se habrían usado.
Si cada DK no estuviera relacionada de alguna manera con la DK anterior, o con la CK original, entonces el cliente requeriría otra forma de recuperar toda la actividad del bróker desde la base de datos para una orden determinada. Eso podría ser posible si solo se usara una única CK en lugar de todas las DK, pero luego las múltiples etapas del mismo cumplimiento de la orden serían más fácilmente identificables por terceros que revisan la base de datos del sistema informático del supervisor 106.
En algunas modalidades, cada bróker podría comunicar su DK respectivo al bróker anterior en la cadena y, finalmente volver al cliente, de manera que cada DK no tendría que ser necesariamente derivable de la CK original en este caso. Sin embargo, el sistema informático del cliente/supervisor 106 tendría entonces que mantener un registro mayor de DK para cada orden, y podría tener mayores dificultades para discernir la solicitud de los saltos en la cadena de brókers sin datos adicionales.
La clave y/o las técnicas de codificación/cifrado también pueden adaptarse para facilitar el cruce y la identificación aguas abajo (por ejemplo, por parte del supervisor y/o componente(s) informático(s) del cliente). Por ejemplo, las claves y/o las técnicas de codificación/cifrado pueden adaptarse de manera que sea más fácil identificar rápidamente la información que puede asociarse, por ejemplo, con una orden en particular. Un conjunto de técnicas descritas en la presente descripción incluyen el uso de técnicas de "índice anónimo", pero también pueden contemplarse otras técnicas.
En algunas configuraciones de un solo salto y de saltos múltiples, puede usarse un índice anónimo (AI) para indexar y localizar mensajes de órdenes en la base de datos del sistema informático del supervisor 106 que puede estar relacionado con las claves usadas. Por ejemplo, un AI puede ser un truncamiento o un hash de una DK. Otras relaciones entre las claves y un AI.
Cuando las DK y los AI se combinan en una etiqueta, la longitud de la etiqueta puede establecerse en una longitud particular para la ofuscación. Por ejemplo, si una clave usada es más corta que la longitud del campo, puede rellenarse delante.
En algunas modalidades, en la etiqueta resultante, el AI puede ser la parte más a la derecha y la DK puede ser la parte más a la izquierda. Puede haber superposición entre estas dos porciones de la etiqueta. De esta manera, es posible soportar mayores longitudes de bits para las claves y, al mismo tiempo, soportar claves heredadas más cortas.
En algunos ejemplos, el servidor/sistema del supervisor puede codificar los datos de solicitud con una DK y almacenarlos junto con un AI correspondiente.
En algunas modalidades, el cliente puede usar un índice tal como el AI para localizar los datos de solicitud almacenados en el servidor del supervisor. Por ejemplo, el cliente puede reconstruir el AI para cada orden secundaria con relación a la orden del cliente original mediante el uso de la(s) clave(s) del instructor y/o del bróker.
El cliente puede luego consultar al servidor del supervisor con cada AI reconstruido para recuperar los datos de la orden secundaria correspondiente al AI respectivo.
En algunos ejemplos, el uso de índices para almacenar los datos en el sistema del supervisor puede reducir los cálculos requeridos por un instructor u otro dispositivo solicitante para identificar los datos de solicitud asociados con sus claves. Por ejemplo, para un sistema de supervisión que recopila los datos de solicitud de numerosos brókers, clientes y/o sedes y maneja millones de solicitudes por día, intentar decodificar todos los datos de solicitud para identificar las solicitudes de un instructor es computacionalmente intensivo. El instructor u otros sistemas solicitantes pueden solicitar solo los datos de solicitud codificados correspondientes a sus Al regenerados, de esta manera se reduce el conjunto de datos que los sistemas deben intentar decodificar. Si bien puede haber colisiones de Al entre diferentes DK, dado que se requiere la DK completa para decodificar los datos, solo un dispositivo del instructor que tenga la DK completa tendrá acceso a los datos subyacentes.
En algunas modalidades, el dispositivo instructor/solicitante/proxy/ puede configurarse para solicitar los datos correspondientes a sus AI reales así como también AI aleatorios o señuelos. En algunos ejemplos, la adición de los AI señuelos puede ofuscar el número real de AI y/o solicitudes del cliente para que no puedan interceptar terceros.
Mientras en el ejemplo anterior se describe con respecto a la relación entre DK y AI, en otros ejemplos, el sistema del supervisor puede almacenar los datos de solicitud junto con las claves de instructor (CK), claves de intermediarios (BK), claves de destino (DK), un instructor identificador, o cualquier combinación o derivado de los mismos.
En algunas implementaciones, cualquier DK única usada por el sistema informático del supervisor 106 puede tener una longitud arbitraria y puede rellenarse para ocultar la longitud real de la clave o para ajustarse a una longitud de clave predeterminada. La longitud máxima de la clave puede aumentarse en cualquier momento, y las claves anteriores heredadas pueden rellenarse si es necesario. Las longitudes de las claves pueden definirse en función de los períodos de día/hora. La base de datos se configuraría para recordar qué claves de longitud se usaron a cuál hora. Puede ser ventajoso que la longitud de etiqueta clave supere el tamaño del contenido real de la DK y el AI almacenados en el mismo con el fin de proporcionar una mayor ofuscación de los mensajes de órdenes.
En algunos ejemplos, no cubiertos por las reivindicaciones, puede configurarse un sistema intermediario 104 para truncar, hash o codificar de cualquier otra manera una clave de destino antes de enrutarla con una solicitud secundaria. Por ejemplo, una DK de 512 bitsN generada a partir de un XOR de una clave de instructor CK y una clave de intermediario BKn puede truncarse a 256 bits para usarla como clave de destino. Esta DK truncada o codificada puede usarse de cualquier otra manera para codificar y/o almacenarse con los datos de solicitud secundaria en el sistema del supervisor. Al codificar la DK, un supervisor, destino y/o un tercero que tenga conocimiento de un hash u otra función BK o DK hf no podrá recrear otras claves en la secuencia porque la DK transmitida al supervisor/destino se ha truncado o codificado de manera que al aplicar la función hf no se proporcionará la siguiente clave en la secuencia. En algunos ejemplos, esto puede proporcionar otro nivel de protección de datos.
A cada usuario del sistema informático del supervisor 106 no se le puede conceder acceso a la base de datos completa del sistema informático del supervisor 106 para realizar consultas. Por ejemplo, un usuario puede prepararse para acceder a diferentes tipos de instrumentos, regiones (por códigos de región, por ejemplo, América del Norte, Europa, Asia, etcétera). Por lo tanto, cada entrada en la base de datos del sistema informático del supervisor 106 puede asociarse con una fecha, un código de región, un tipo de instrumento y un AI. Debido a las etiquetas de relleno, u otras razones, a veces los AI pueden duplicarse entre las órdenes. En ese caso, el sistema del cliente puede intentar decodificar cada mensaje cifrado que tenga un AI que el cliente crea que pertenece al cliente. Si el sistema del cliente no puede descifrar el mensaje de una entrada en particular, el sistema del cliente asumirá que ese mensaje no es el mensaje del cliente y continuará adelante. El sistema informático del supervisor 106 puede replicar los datos de los centros de datos en todo el mundo para que los usuarios puedan acceder a los datos en todo el mundo que se originan en otros centros de datos localmente, si el usuario tiene privilegios de acceso para hacerlo.
Si bien varias claves se analizan anteriormente, estas claves se usan principalmente para la indexación. El sistema informático del supervisor 106 puede no requerir que los propios mensajes de órdenes se cifren y, en muchos casos las órdenes no se cifren, lo cual se pretende. Sin embargo, en algunos casos, puede ser necesario o conveniente que los contenidos de mensajes de órdenes particulares entre brókers, y almacenados en la base de datos del sistema informático del supervisor 106, se cifren. Los medios para descifrar los contenidos de tales mensajes cifrados pueden preferentemente no ser conocidos por la base de datos del sistema informático del supervisor 106 o por terceros. Cualquier cifrado del contenido del mensaje puede ser completamente independiente del sistema CK/BK/DK/AI usado por el sistema informático del supervisor 106. En este caso, cada bróker necesitaría poder cifrar de manera que el bróker subsecuente, y también el cliente, pudieran descifrar.
Por lo tanto, tanto el Bróker A como el Bróker B pueden necesitar almacenar cualquier clave necesaria para descifrar los mensajes de los brókers anteriores y cifrar los mensajes subsecuentes, y el cliente también necesitará la(s) clave(s) de descifrado. El Bróker B puede comunicar una clave de cifrado o descifrado por adelantado del primer bróker de la cadena o del bróker anterior. Cualquier comunicación de claves de este tipo puede enviarse hacia adelante por un bróker anterior a través de un canal de comunicación separado de las comunicaciones monitoreadas por el sistema informático del supervisor 106, saltando de esta manera completamente el sistema informático del supervisor 106. Cada bróker puede usar la misma clave para una orden en particular, o cada bróker puede tener una clave única para cada orden, lo que requiere que el cliente reciba y almacene claves de decodificación (por ejemplo, descifrado) para cada salto en la cadena.
En algunas modalidades, el mismo bróker podría aparecer múltiples veces en la misma cadena. En tal escenario, el mismo bróker puede usar las mismos y/o diferentes DK.
En algunas modalidades, el bróker puede enviar una DK en una etiqueta al siguiente bróker y al sistema informático del supervisor 106, la existencia de la DK en la etiqueta puede usarse como un indicador al cliente de que esta orden va a otro bróker en una cadena.
En algunas modalidades, un proxy puede configurarse o no para procesar cada mensaje de orden recuperado como si se refiriera a un salto subsiguiente en la cadena de procesamiento de órdenes, por lo que la etiqueta del mensaje puede usarse como un indicador al cliente de que se va a aplicar el algoritmo de cadena de la recuperación de mensajes.
En algunas modalidades, el mensaje de acuse de recibo (ACK) de un bróker aguas abajo a uno aguas arriba puede incluir su BK, almacenada por la base de datos del sistema informático del supervisor 106 para que se pueda seguir la cadena. El ACK puede, por ejemplo, retornar una clave usada en un esquema de salto múltiple (por ejemplo, el Bróker B retorna su BK hacia el Bróker A en un ACK, filtrado por el proxy para que la BK se almacene en la base de datos del sistema informático del supervisor 106, pero no hace su camino de regreso al Bróker A.
Por ejemplo, el sistema informático del supervisor 106 puede consultar BKa1 CK para obtener: DKa AIa y buscar AIa para obtener BKb1.
Como otro ejemplo, el sistema informático del supervisor 106 puede consultar BKb1 DK1 para obtener DKb AIb. En algunas modalidades, el sistema informático del supervisor 106 puede configurarse para almacenar acuses de recibo en la base de datos del sistema informático del supervisor 106 además de los mensajes de solicitud de relleno de órdenes desde los brókers. Por ejemplo, los sistemas informáticos del bróker 104 podrían enviar un mensaje al sistema informático del supervisor 106 y proporcionar una copia directamente a la sede(por ejemplo, a través de una copia de entrega).
Soporte de Múltiples Trayectos dentro de un Sistema
En algunos casos, un bróker puede tener múltiples sistemas internos a través de los cuales se procesan las órdenes. De forma similar a los ejemplos en los que un sistema del supervisor y la comunicación de las claves entre los sistemas proporciona la gestión y el monitoreo de los recursos informáticos en red, estos aspectos pueden aplicarse de manera similar para monitorear la gestión de solicitudes secundarias dentro de un sistema tal como un sistema del bróker / intermediario único.
La Figura 8 es un diagrama esquemático de bloques que ilustra una implementación de ejemplo donde un único sistema, tal como un dispositivo intermediario, tiene múltiples sistemas internos 810, 820, 830 sobre los que pueden procesarse las solicitudes, de acuerdo con algunas modalidades.
Cuando un bróker tiene una estructura de cadena interna, donde cada computadora envía datos directamente a la siguiente computadora para finalmente rellenar las órdenes, la situación puede ser más simple y puede que no requiera que se tomen medidas específicas.
En una implementación base, BK0 se generaría por la entidad comercial electrónica del bróker 810 que genera una orden secundaria (por ejemplo, el enrutador de orden inteligente) y luego se comunicaría de regreso al cliente en el ACK a la orden del cliente. Entonces, la secuencia de BK generada por la entidad del bróker sería una simple lista única que también podría ser reproducida por un sistema del supervisor. Sin embargo, las diferentes estructuras del sistema intermediario pueden complicar este proceso.
En algunos ejemplos, los componentes de procesamiento 820 que generan las solicitudes secundarias pueden no estar procesando el componente que envía el ACK para la solicitud principal. El envío del ACK puede realizarse aguas arriba en una puerta de enlace orientada al cliente y, en consecuencia, esto podría requerir que haya algún tipo de sincronización de selección BK entre el sistema aguas arriba y el componente de procesamiento aguas abajo que genera solicitudes secundarias.
Los componentes de procesamiento 810, 820, 830 pueden incluir enrutadores inteligentes u otros dispositivos computacionales y/o de red para procesar y/o generar las solicitudes secundarias para el enrutamiento. En los ejemplos donde hay más de un componente de procesamiento/dispositivo informático que genera potencialmente las órdenes secundarias simultáneamente, se implementan mecanismos para evitar colisiones entre los dispositivos de procesamiento 810, 820, 830.
En algunos ejemplos, puede haber múltiples componentes de procesamiento 820 que generan órdenes secundarias que se ejecutan independientemente. Por ejemplo, una orden de cliente de 10K acciones puede dividirse de manera que un componente de procesamiento que ejecuta el algoritmo A opere 3K acciones y las 7K acciones restantes los opere otro componente de procesamiento que ejecute el algoritmo B. Otro enfoque de implementación puede ser gestionar la selección de BK y la inserción de DK/AI en las puertas de enlace. Dado que puede haber muchas puertas de enlace, la coordinación de las BK puede resultar poco práctica.
El sistema "de Múltiples Trayectos" 800 proporciona la capacidad de manejar una única orden principal que está siendo manejada o procesada por múltiples componentes de procesamiento que generan o manejan solicitudes secundarias dentro de un sistema. Este es un problema para la arquitectura porque, idealmente, cada entidad debería poder asignar la siguiente BKn en secuencia comenzando desde la BK0 inicial. Sin embargo, si las entidades están poco acopladas, como donde hay dos o más enrutadores algorítmicos o enrutadores de órdenes inteligentes, o dos o más puertas de enlace, etcétera, la coordinación puede ser un reto y puede generar una latencia adicional no deseada.
Pueden generarse grandes cadenas de BK simplemente ejecutando algoritmos de codificación o hash (por ejemplo, SHA512) en un lazo tantas veces como sea necesario. Sin embargo, esto puede ser computacionalmente costoso y no escala si hay muchos componentes de procesamiento "de múltiples trayectos".
De acuerdo con algunas modalidades, un enfoque para reducir el costo computacional de generar BK y al mismo tiempo reducir el tiempo computacional a una pequeña constante para generar una BK arbitraria (en lugar de requerir generar una cadena de BK) es generar una matriz multidimensional de BK donde cada entrada es un XOR de las BK a lo largo del eje de la matriz multidimensional. En algunas modalidades, seleccionar el número divisor y el tamaño de la dimensión del bloque BK para que sean primos relativos puede mejorar la posibilidad de que las BK generadas no se superpongan hasta que se hayan usado todas las BK en la matriz. Incluso cuando se produce una superposición, en algunas modalidades, enfoques adicionales, tal como rotar las BK a lo largo de una de las dimensiones del bloque en 1 byte cada vez que el bloque se envuelve, puede ayudar a generar más de 1 millón de matrices únicas a partir del mismo conjunto de BK precalculadas. Dado que calcular una entrada de BK requiere un tiempo de cálculo constante, independientemente del índice de BK, el divisor del esquema puede ser arbitrariamente grande (mayor que el número máximo de índices que pueden requerirse).
En algunas modalidades, el sistema puede configurarse para soportar el enfoque de múltiples trayectos mediante la asignación de una BK0 inicial a una orden principal, y luego permitir que todas las entidades que generan órdenes secundarias lo hagan independientemente asignándoles un índice de módulo único "i" y un divisor "m" donde "m" es igual o mayor que la "i" más grande en el grupo de entidades. También son posibles otras metodologías de numeración. Una entidad genera solicitudes secundarias y les asigna BK comenzando con la BK indexada por "i" y luego incrementando por "m". Entonces, la primera BK enviada sería "i", la segunda "i+m", la tercera "i+2m", y así sucesivamente.
Por ejemplo, un componente de procesamiento indexado como "3" en un grupo de entidades con el divisor "7" enviaría la siguiente secuencia de BK: 13, 10, 17, 24, 31.
En este ejemplo, un sistema informático del proxy/supervisor puede recibir el índice BK 0 y luego ser capaz de calcular todos las BK subsecuentes en la serie reproduciendo las mismas BK que usarían las entidades del bróker. En consecuencia, es posible que el sistema no pueda determinar el índice de las entidades que generaron órdenes secundarias y tendría que emplear un algoritmo heurístico para encontrarlas.
En algunas modalidades, si el bróker elige no implementar una estrategia de Múltiples Trayectos, entonces puede usar un ID de entidad/índice de módulo predeterminado (por ejemplo, 1) para todas las órdenes secundarias.
Cuando un bróker tiene múltiples componentes/computadoras para rellenar órdenes (enrutadores de órdenes) cada uno de los cuales puede rellenar parte de la solicitud de un cliente instructor, entonces puede haber un mayor desafío para el sistema informático del supervisor 106 para rastrear las actividades del bróker. Es posible que el instructor desee rastrear de todos los rellenos de órdenes realizadas por diferentes partes del bróker, manteniendo un buen nivel de anonimato y tiempos de ejecución razonables.
Por ejemplo, el cliente se conecta a un bróker, a través del proxy de un sistema informático del supervisor 106, el bróker envía órdenes a uno o más enrutadores algorítmicos para rellenar las órdenes. Un servidor proxy podría residir entre cada enrutador y la trayectoria fuera de la red interna del bróker. Puede surgir un desafío con respecto a cómo generar y asignar claves de bróker a cada acción de rellenar las órdenes por parte de cada enrutador.
El sistema informático del supervisor 106 podría revelar cuánto tarda en procesarse la orden de un cliente a través del bróker. La misma orden puede manejarse por uno o más enrutadores, o puede manejarse por diferentes enrutadores en diferentes momentos, a lo largo de un día u otro período de tiempo. Uno o más de los enrutadores del bróker que usan las mismas claves pueden ser suficientes para garantizar que la arquitectura funcione, pero para ofuscar mejor las actividades entre los brókers, puede ser una mejora que cada relleno de cada enrutador se configura para utilizar un BK diferente, lo que también tiene que ser verificable por el cliente (por ejemplo, para que el cliente pueda, al procesar los registros, determinar, mediante el uso de los BK, qué órdenes y/o solicitudes de procesamiento se relacionan con las órdenes del cliente, de manera que el cliente sea capaz de validar y/o analizar el desempeño del bróker).
En una modalidad, un primer método de ejemplo para rastrear un bróker que usa múltiples enrutadores de órdenes internas puede ser que cada enrutador (u hoja en el árbol) use la misma clave de bróker (BK) para la orden de un cliente en particular. En ese caso, la BK se debe comunicar a cada hoja. Esto puede lograrse enviando las BK reales a cada enrutador, o enviando un índice a una base de datos interna de BK, para que cada enrutador busque la BK que se usará para cada orden.
Rellenar las órdenes de esta manera puede dar como resultado múltiples entradas en la base de datos del sistema informático del supervisor 106 que tienen el mismo índice, lo que requiere un método descrito anteriormente para que un proxy recupere todos los mensajes de órdenes que se indexan por la misma AI (por ejemplo, el cliente no debe dejar de identificar coincidencias potenciales tan pronto como se encuentre un mensaje con ese índice).
Si bien en algunas modalidades, el sistema permite consultar múltiples mensajes de órdenes con la misma AI, este método puede exponer que el bróker está dividiendo una orden X número de formas. Un tercero podría contar cuántas AI duplicadas existen y extrapolar alguna información sobre las actividades de rellenar las órdenes en función de esa información.
En consecuencia, en otra modalidad, se aplica un método alternativo. En esta modalidad, cada enrutador de órdenes podría generar o tener asignado su propia BK. Esta BK sería comunicada de regreso al cliente. El sistema informático del bróker 104 se configuraría adecuadamente para enviar todas las claves de hoja de regreso al cliente. Las BK pueden transmitirse al cliente una a la vez o en lotes a medida que se rellena la orden. Las BK podrían comunicarse solo cuando la orden comience a rellenarse, o cuando la orden se rellene completamente.
En tal modalidad, un desafío a superar puede incluir la gestión del rendimiento informático en relación con la generación de las BK. La generación puede volverse compleja desde el punto de vista computacional, lo que puede dar lugar a problemas de rendimiento aguas abajo y/o generales. En consecuencia, en algunas modalidades, con el fin de mejorar el rendimiento de la generación de b K y permitir que el cliente vuelva a crear las BK, en lugar de tener que recibirlos individualmente, las BK pueden asignarse a cada enrutador de órdenes internas si el número de enrutadores de órdenes se conoce.
Si bien pueden usarse varias metodologías, una de ellas es asignar las BK mediante el uso de la división de módulo. Por ejemplo, suponiendo que el bróker usa 25 órdenes internas, los BK pueden asignarse a partir del número 1, por división de módulo 25, lo que significa que las siguientes BK se asignarían al primer enrutador de órdenes: 1, 26, 51, 76, etcétera, y las siguientes BK al segundo enrutador de órdenes: 2, 27, 52, 77, etcétera, y así sucesivamente. Por ejemplo, la división de módulo 10 asignaría 1, 11, 21, 31, 41, etcétera al primer enrutador de órdenes. En este caso, cada enrutador podría enviar de regreso el número de índice de la BK final usada para rellenar la orden de ese cliente.
Los índices podrían comunicarse al cliente para recrear las BK, lo que puede ser más eficiente que comunicar al cliente la totalidad de cada BK usada. Cada ramificación en el árbol de los enrutadores de órdenes podría comunicar de vuelta su valor de índice BK de terminal al cliente continuamente, pero puede ser preferible recopilar los valores de terminales de todos los enrutadores y enviarlos de regreso como acuse de recibo único al cliente.
Luego, el cliente tendrá que consultar la base de datos para todos los AI mediante el uso de todas las BK. Cuando el cliente examina la base de datos en busca de los AI, un AI faltante en este caso no significa necesariamente que haya una anomalía de la que preocuparse. Por ejemplo, el primer enrutador de órdenes puede usarse por las BK 1, 11, 21 y 31, mientras que el segundo enrutador solo puede usarse por las BK 2 y 12, dejando posiblemente muchas BK entre 1 y 31 sin usar.
Sin embargo, la división de módulo puede ser un desperdicio si uno o más enrutadores no usan muchas de sus claves. En el método de módulo, cada enrutador (o proxy del sistema informático del supervisor 106 conectado a cada enrutador) puede tener una ID única.
Las BK pueden precalcularse en un grupo para que cada proxy/enrutador extraiga o las claves pueden pasarse internamente. Donde hay una gran cantidad de enrutadores, esto puede volverse ineficiente. Una posible solución sería no generar las BK hasta que se necesiten. Después de una ronda de generación de BK, un enrutador / proxy puede consultar el sistema informático del supervisor 106 para ver qué BK se usaron, luego generar la siguiente clave para esas BK usadas (por ejemplo, si se usó BK01, generar BK11, pero si no se usó BK01, no generar BK11). Idealmente, uno puede desear infinitas BK, seleccionadas arbitrariamente. Si las BK se generan haciendo XOR de un conjunto de BK con otro, entonces se debe calcular previamente un número menor de BK. Por ejemplo, calcular previamente BK01 a 20, y XOR aquellos con BK21 a n según sea necesario. Cada hilera de la matriz resultante es entonces determinable por cualquiera de los enrutadores/servidores proxy. Además, cualquiera de los ejes de la matriz puede desplazarse o las BK pueden desplazarse en bits y volver a calcular una vez que se agota la matriz. Cada enrutador inteligente puede configurarse para realizar la generación de claves matricial de acuerdo con este algoritmo. Un proxy (por ejemplo, el cliente) también podría reproducir la clave conociendo los parámetros de la matriz. En algunas modalidades, el número divisor (por ejemplo, para operaciones de módulo) (número de enrutadores) debe ser un primo relativo de la matriz. Por ejemplo, en una matriz de 5x5, un divisor de 3 y un divisor de 7 pueden generar resultados superpuestos.
Se podría diseñar un proxy en cada enrutador de órdenes inteligente en lugar de ser un dispositivo separado.
En algunas modalidades, se usa un enfoque alternativo en lugar del enfoque de módulo para generar secuencias de BK. Se genera una BK específica de la entidad.
Por ejemplo, bajo este enfoque, cada entidad comienza con BK0 y luego genera una entidad específica BK E0= fSHA512(BK0, Entity_ID). Es posible que los clientes y brókers aguas arriba deban anticipar el ID de entidad (por ejemplo, en algunas modalidades, se establece como un número entero simple que comienza con 1). La secuencia de BK específicos de la entidad puede generarse mediante el uso de la codificación en cascada, por ejemplo: BKEn+1= fSHA512(BKEn).
Una ventaja de este enfoque es que garantiza que es improbable la superposición de las DK y Al entre diferentes entidades. El enfoque también usa cadenas secuenciales de BK con un bloque único de BK para cada entidad, en lugar de un esquema de módulo con todos los BK compartiendo el mismo bloque de BK. El enfoque no requiere que las entidades compartan bloques de BK precalculados. Cada entidad genera y mantiene su propio bloque de BK que puede precalcular otros BK; sin embargo, una lista de BK0 puede que sea necesaria compartir para facilitar el cálculo previo.
La entidad que asigna BK0 a una CK puede necesitar poder comunicar esa selección a las partes involucradas. Por ejemplo, A BK0 es posible que deba enviarse de regreso al cliente en el mensaje ACK; BK0 es posible que sea necesario comunicarlo hacia adelante a todas las entidades que generan las órdenes secundarias; esto puede comunicarse como el índice de la BK0 en la lista compartida de BK0 o puede comunicarse como la BK0 real.
Cuando una entidad aguas abajo recibe una BK0 puede generar un bloque de BK directamente desde él en tiempo real (el bloque puede generarse incrementalmente o en su totalidad) o puede buscar la BK0 en sus bloques de BK0 precalculados en función de una lista compartida anterior de BK0s.
Monitoreo Interno por parte del Bróker de los Sistemas Propios del Bróker Mediante el Uso de un Sistema Interno del Supervisor
En lugar de que el cliente use el sistema informático del supervisor 106 para monitorear y verificar las actividades del Bróker, que aún pueden tener lugar, independientemente de eso, el bróker puede monitorearse desde sus propios enrutadores internos mediante el uso de una base de datos interna y una aplicación similar a un proxy. Entonces, el bróker puede monitorear la actividad del enrutador de órdenes inteligente y posiblemente detectar anomalías, como un enrutador que rellena las órdenes de manera inesperada o no intencionada.
Por ejemplo, una solución de este tipo puede proporcionarse en forma de un conjunto de herramientas de implementación de bróker que incluye la gestión y configuración de entidades.
La Figura 9 es un diagrama esquemático de bloques que ilustra aspectos de una implementación del sistema de ejemplo 900 donde un único bróker tiene múltiples sistemas internos en los que pueden procesarse las órdenes, y el bróker utiliza una aplicación/componente del supervisor interno del lado del bróker para monitorear el desempeño del propio bróker, de acuerdo con algunas modalidades.
El sistema de monitoreo interno puede, por ejemplo, realizar varios análisis en relación con el rendimiento y/o el uso, como latencias asociadas con técnicas de nivelación de latencia, gestión de opciones, etcétera. La solución puede ayudar, por ejemplo, a delimitar la capacidad de verificación de riesgos, y utilizar estrategias clave (por ejemplo, estrategia CK/BK) para correlacionar las órdenes de clientes entrantes con las órdenes secundarias salientes.
Puede haber una aplicación o dispositivo informático del supervisor interno 112 que puede ser para varios fines, como comprobar si las cantidades salientes superan alguna vez las cantidades entrantes, comprobar si los parámetros de la orden saliente (precio, lado, cantidad, TIF,...) son no consistente con las órdenes entrantes o con los parámetros u opciones configurados, verificar la falta de actividad de salida, verificar la actividad de salida ineficaz - grandes cantidades de órdenes secundarias que no generan relleno, generar alertas electrónicas en tiempo real, proporcionar una capacidad de interruptor automático o manual, generar alertas electrónicas con múltiples niveles de activación y/o proporcionar una visualización GUI de las anomalías detectadas.
El dispositivo informático del supervisor interno o aplicación 112 puede configurarse para coordinarse con un sistema informático del supervisor 106, y el sistema informático del supervisor 106 puede colocarse en la entrada al sistema del bróker y las salidas de los enrutadores de órdenes inteligentes del sistema de bróker.
Cada proxy puede comunicarse con un servidor interno de manera similar a cómo el sistema informático del supervisor 106 recibe datos de bróker-bróker y bróker-sede. El servidor del sistema informático del supervisor interno puede ser privado, o también puede enrutarse a un servidor del sistema informático 106 del supervisor externo - el enrutamiento externo puede ser útil cuando el bróker es en sí mismo un cliente de otro bróker.
En algunas modalidades, dado que este sistema es interno, el cifrado puede no ser tan importante y puede no usarse. Solo los datos internos del bróker se almacenan y son accesibles.
Un problema a resolver es que a veces un enrutador de órdenes inteligente no está operando correctamente o se programa de una manera que resulta en un comportamiento inesperado. El enrutador podría realizar órdenes que no estaban previstos. Una implementación interna puede ayudar a detectar dichas actividades, por ejemplo, al determinar el número total de órdenes secundarias que ingresan al sistema y el total de órdenes que salen. Si hay una discrepancia, la implementación interna del bróker puede configurarse para indicar que hay un problema. Los factores que pueden examinarse pueden ser la cantidad total de órdenes, el tamaño de las órdenes, y los símbolos. Las órdenes pueden coincidir comparando/vinculando las BK salientes con los CK entrantes.
La implementación interna del supervisor puede configurarse para enviar alertas al detectar una anomalía. Las alertas también pueden procesarse. Por ejemplo, el supervisor interno puede bloquear órdenes adicionales que salen de un enrutador en particular para que no se envíen externamente desde el bróker, o el supervisor interno puede tener la capacidad de enviar un mensaje de control al enrutador de órdenes para dejar de rellenar las órdenes o apagarlo completamente.
A veces, el enrutador preciso con el problema puede no ser fácilmente identificable, o puede haber un problema con la forma en que se segmentó la orden en los enrutadores. En esos casos, el supervisor interno podrá impedir que se procesen las órdenes derivados de la concordancia de CK o DK. Se puede enviar un mensaje de control a todos los enrutadores salientes para que dejen de procesar órdenes de esa CK o DK, o los servidores proxy externos pueden bloquear las solicitudes de relleno de las órdenes que coincidan con esa CK o DK.
Las acciones de las alertas pueden ocurrir en tiempo real, pero también puede existir el peligro de reaccionar de forma exagerada a los problemas percibidos que en realidad funcionan según lo previsto. Actuar sobre falsos positivos puede ser tan problemático como perder problemas.
En algunas modalidades, un supervisor interno puede configurarse con un umbral para que solo se tomen medidas cuando las actividades de rellenar órdenes excedan la orden total del cliente más el umbral. Para ayudar a determinar un umbral adecuado, el supervisor interno podría configurarse inicialmente para operar en modo de solo alerta antes de habilitar las acciones en función de las alertas.
Puede haber otra información o parámetros para ser monitoreados en lugar de o además de las órdenes de entrada/salida. El supervisor interno podría monitorear la frecuencia de relleno de órdenes para identificar fallas en el algoritmo de enrutador de órdenes o un rendimiento subóptimo. Cada vez que entra o sale una orden, el supervisor interno puede correlacionar y verificar cualquier regla programada en el sistema.
En algunas modalidades, la gestión/supervisión interna de los procesos de datos dentro de un sistema puede proporcionar ventajas sobre las técnicas de monitoreo tradicionales. Por ejemplo, cuando los componentes de procesamiento individuales realizan el monitoreo y reportan su propio comportamiento, si un componente funciona mal o muere, su reporte puede fallar o dejar de generar una falta de información en un tiempo crítico. Adicionalmente, cualquier cambio en las topologías del enrutador o la adición o sustracción de componentes puede requerir cambios en el sistema de monitoreo.
Sin embargo, en las modalidades del sistema del supervisor descrito en la presente descripción, el monitoreo/gestión puede ser independiente de la tecnología y recibir continuamente datos de solicitud secundaria independientemente de si un nodo se cae o funciona mal. El sistema también puede proporcionar marcas de tiempo precisas a medida que las órdenes ingresan o salen del sistema, y a través de la gestión de las claves, puede rastrear las órdenes secundarias hasta sus dispositivos generadores.
Tanto el Cliente como el Bróker Conocen las Claves Completas, Algoritmo de Codificación
En algunas modalidades, el servidor del supervisor puede configurarse para mantener una base de datos pública de órdenes (secundarias) codificadas, que pueden indexarse (por ejemplo, mediante el uso de un Índice Anónimo (Al)). Cualquiera puede enumerar y recuperar las órdenes codificadas, pero requiere una copia de la clave X, o la clave de decodificación correspondiente, para descifrarlas. Opcionalmente, puede proporcionarse un proceso de inicio de sesión seguro para permitir que solo los usuarios registrados del servidor del supervisor consulten y recuperen cualquiera de las órdenes.
Con el fin de permitir que el cliente verifique/rastree las actividades del bróker, el bróker puede compartir sus claves de codificación completas y cualquier información segura relacionada con el cliente. En algunas modalidades, particularmente cuando solo se comparte una clave entre el bróker y el cliente, el cliente, mediante el uso de la información proporcionada por el bróker, puede regenerar una secuencia de claves secundarias hash usadas por el bróker con el fin de determinar qué órdenes secundarias se hicieron a partir de la orden principal original. El cliente puede regenerar las claves secundarias mediante el uso del mismo proceso usado por el bróker para generar las claves secundarias, donde el cliente conoce la clave del bróker, o la clave del cliente en el caso de que la clave del cliente se haya compartido originalmente con el bróker, y el algoritmo de codificación usado por el bróker. El cliente también puede determinar qué órdenes secundarias se relacionan con otras órdenes secundarias mediante el uso de este proceso.
En algunas modalidades, el bróker puede precalcular unas más claves de bróker o claves secundarias antes de recibir una orden de un cliente. Por ejemplo, puede ser ventajoso para el bróker realizar los cálculos requeridos para generar claves secundarias para una clave de bróker o cliente en particular por adelantado, para reducir la latencia o los gastos generales de procesamiento en el momento en que se solicita la orden del cliente, particularmente cuando se reciben muchas órdenes en el bróker simultáneamente o razonablemente al mismo tiempo.
En algunas modalidades, en lugar de que el bróker genere claves secundarias a partir de una clave de bróker o cliente, el bróker puede generar una o más claves aleatorias por adelantado o en el momento de la orden que son independientes entre sí, y asociar cada orden secundaria requerida con una de las claves generadas aleatoriamente. En esta implementación, el bróker puede compartir cada una de las claves asociadas con las órdenes secundarias para la orden del cliente de manera que el cliente pueda verificar la información de transacción de la orden con el servidor del supervisor mediante el uso de las claves secundarias recibidas. Si las claves secundarias no se generaron a partir de un bróker principal o una clave de cliente, es posible que no haya una relación perceptible entre las claves secundarias, de manera que el cliente no pueda derivar la colección completa de claves secundarias para una orden de cliente en particular. Por lo tanto el cliente puede requerir recibir la lista completa de claves secundarias del bróker en este caso.
En algunas modalidades, el bróker puede generar las claves secundarias necesarias para una orden de cliente en tiempo real o al recibir una solicitud para una orden de un cliente. Opcionalmente, el bróker puede confiar en hardware o software especializado o personalizado, aprovechando opcionalmente una o más unidades de procesamiento central ("CPU"), unidades de procesamiento acelerado ("APU") y/o unidades de procesamiento gráfico ("GPU"), para acelerar el cálculo en tiempo real de claves.
Opcionalmente, la información de relación puede proporcionarse en forma de parámetros de una función de codificación, una tabla de codificación, claves de codificación, información de la cadena de codificación, etcétera. A partir de ahí, el cliente puede solicitar las órdenes secundarias específicas por código Al al servidor del supervisor, opcionalmente a través de un canal de comunicaciones codificadas.
Dado que en última instancia puede ser posible descifrar la clave X, y por lo tanto, descifrar la información de la orden, solo el cliente o el bróker pueden conocer la clave completa Y, lo que solo permite que el cliente o el bróker determinen cuál de las órdenes secundarias recuperables públicamente fueron colocadas por el cliente/bróker como parte de la misma orden principal. Opcionalmente, la comunicación de claves entre bróker y cliente puede realizarse a través de un canal codificado. En algunas modalidades, el servidor del supervisor no puede determinar las interrelaciones entre las órdenes, incluso cuando ha recibido órdenes secundarias no codificadas del bróker. Por lo tanto, cuando el supervisor almacena los datos de la orden en su base de datos codificados con la clave X recibida del bróker, ninguna información de relación entre las órdenes secundarias puede almacenarse o discernirse desde el servidor del supervisor.
Cifrado y Codificación con una Clave Mayor que la Compartida para el Descifrado
El bróker puede cifrar y codificar las órdenes con una clave grande Y, pero puede transmitir solo una clave truncada X al supervisor/sede. Una porción de la clave puede usarse en el cifrado, mientras que otra porción puede usarse para la codificación.
La clave Y puede incluir: la clave de codificación X que se usó para cifrar la orden, un código de índice anónimo (Al) para identificar la orden y los bits adicionales para la codificación de la serie de claves de cliente para cada orden principal.
Al no transmitir la clave Y completa, el supervisor/sede puede descifrar y procesar cada orden secundaria, pero no podrá determinar cómo se codificaron las claves de la orden secundaria y, por lo tanto, no podrá determinar qué órdenes se relacionan entre sí. Esto puede proporcionar seguridad adicional con respecto al uso de un algoritmo de codificación confidencial, ya que es posible aplicar ingeniería inversa al algoritmo hash. En algunas modalidades, los algoritmos de codificación convencionales (por ejemplo, MD5, SHA-1, SHA-2, SHA-3 o varios algoritmos del Instituto Nacional de Estándares y Tecnología) pueden usarse y asociarse con los bits adicionales.
Incluso si el algoritmo de codificación fuera de ingeniería inversa, podría ser mucho más difícil descifrar la relación de hash cuando solo se comparte la clave truncada. Por ejemplo, la única forma de determinar prácticamente cómo se codificaron los órdenes secundarias es con la clave completa Y, que solo está disponible para el bróker y el cliente.
Por ejemplo, la clave Y puede tener una longitud de 384 bits, siendo la clave de codificación X de 256 bits y el código Al de 32 bits. Los 96 bits restantes se mantendrían en privado (por ejemplo, no se transmitirían a una sede o supervisor), aumentando la dificultad para que una sede o supervisor regenere la secuencia de claves secundarias a partir de la primera.
En algunas modalidades, la clave raíz de 384 bits puede transmitirse en su totalidad de regreso al cliente en el mensaje ACK. Esta clave puede facilitar la regeneración de la secuencia de claves hash que el bróker usó para procesar la orden. Por ejemplo, un cliente o varios sistemas informáticos usados por el cliente pueden usarse para regenerar esta secuencia (por ejemplo, una secuencia de hash repetidos, donde un hash anterior es la entrada a una función hash posterior) y, por lo tanto, determinar la relación entre varias órdenes secundarias y/o órdenes de clientes.
La regeneración de la secuencia puede, por ejemplo, permitir que un cliente o una parte asociada con el cliente identifique todas las órdenes secundarias que se generaron a partir de una orden de cliente, por ejemplo, para que el cliente pueda evaluar el desempeño del bróker. Por ejemplo, el desempeño del bróker puede evaluarse con respecto a las mejores prácticas de ejecución, que pueden evaluar las órdenes recibidas por un bróker y evaluar periódicamente si el bróker utilizó mercados competidores, creadores de mercado o redes de comunicaciones electrónicas (ECN) que ofrecieron las condiciones de ejecución más favorables en el momento de la ejecución. Algunos de los factores relacionados con la mejor ejecución pueden incluir: la oportunidad de obtener un precio mejor que el cotizado actualmente, la velocidad de ejecución y la posibilidad de que se ejecute la operación.
Un desafío potencial puede ser que terceros puedan monitorear varios elementos de la información para correlacionar estadísticamente a los clientes con las transacciones, por ejemplo, a través de una asociación temporal. Se pueden utilizar varias estrategias para ayudar en la ofuscación del cliente.
En algunas modalidades, la longitud exacta en bits de la clave Y también puede no divulgarse públicamente por el bróker, para la seguridad adicional.
La longitud en bits de la clave Y también puede variar de una orden a otra, para seguridad adicional. En algunas modalidades, pueden usarse bits rellenadores, de relleno o desechables, por ejemplo, para hacer que la longitud de bits de la clave Y parezca uniforme. La longitud de la clave Y puede configurarse y reconfigurarse según se requiera, incluyendo el aumento de la longitud de la clave según se requiera o recomiende de acuerdo con ciertos estándares de cifrado.
Este método también puede enmascarar la cantidad de órdenes secundarias en una orden principal ocultando de esta manera a las respectivas sedes si recibieron la orden principal completa o no.
En el contexto de la Figura 2, en este ejemplo, las claves de destino (DKn) pueden ser solo porciones de una clave completa, las claves de destino permiten el descifrado de la orden secundaria, pero no permiten que los sistemas informáticos del supervisor 106 determinen la relación entre varias órdenes secundarias recibidas de un bróker (por ejemplo, la clave completa puede requerirse para esto). La clave completa puede proporcionarse a los sistemas informáticos del cliente 102, que luego pueden usar la clave completa para descifrar y asociar la información de procesamiento de orden secundaria que puede recuperarse de los sistemas informáticos del supervisor 106. En algunas modalidades, la información de procesamiento de orden secundaria puede publicarse como un informe disponible públicamente, que incluye información de procesamiento asociada con varias órdenes. En algunas modalidades, la información de procesamiento se codifica.
Herramienta Informática
En algunas modalidades, puede proporcionarse una herramienta informática, la herramienta informática configurada para la correlación de claves con órdenes de clientes. La herramienta informática puede configurarse para el análisis y la elaboración de informes relacionados con el enrutamiento de órdenes a las sedes.
Por ejemplo, la herramienta informática puede configurarse para realizar análisis, como verificar que las órdenes se enrutaron de acuerdo con las instrucciones, las órdenes se enrutaron de acuerdo con la "mejor ejecución"; que determina las diferencias entre la "mejor ejecución" y el procesamiento de la orden tal como se enruta; que determina el tiempo promedio requerido para rellenar una orden; comparar precios y/o cantidades de órdenes procesadas en comparación con las órdenes deseadas, etcétera.
Esta información puede, por ejemplo, ser útil para proporcionar información sobre el enrutamiento y la eficiencia del procesamiento de sus órdenes. En algunas modalidades, la herramienta informática compara los registros de mensajes de órdenes del cliente con los registros de mensajes codificados de servicios para el cliente y genera un informe de discrepancias.
La herramienta informática puede implementarse como software, hardware, un servicio web, individualmente o en varias combinaciones.
La herramienta informática puede configurarse para, por ejemplo, recibir y/o acceder automáticamente a información codificada (información de transacciones, datos de mercado, etcétera, recibida de los sistemas informáticos de un supervisor o del sistema informático de una sede; en función de una copia de las órdenes del cliente (incluidas las claves de codificación/descodificación y/o la información del registro de transacciones), acceder a los datos codificados, decodificar y comparar la información con la información del cliente; y/o producir uno o más informes. En algunas modalidades, la herramienta informática puede configurarse para generar y/o proporcionar claves codificadas seguras para que el cliente y/o los sistemas informáticos del cliente 102 las usen al enviar las órdenes a los brókers y/o los sistemas informáticos del bróker 104. Por ejemplo, la herramienta de ordenador puede incluir un generador de números aleatorios que puede generar una serie de claves para cada cliente. Estos pueden, por ejemplo, basarse en la fecha/hora y/o un parámetro clave único según lo definido por el personal del cliente. La herramienta informática puede incluir funciones de gestión de claves: construcción de claves, actualización de claves, alertas para crear nuevas claves, etcétera.
La generación y/o suministro de claves de codificación/cifrado puede realizarse en un servicio de solicitud de clave individual y/o como un servicio de bloque.
Los beneficios potenciales de proporcionar una herramienta informática pueden ser requisitos de desarrollo reducidos y/o soporte técnico, facilidad de adopción del sistema y facilidad de actualización y/o modificación del sistema.
En algunas modalidades, la herramienta informática puede configurarse para proporcionar soporte analítico, como el desarrollo de puntos de referencia, informes, análisis estadísticos, análisis heurísticos, comparaciones con datos de condiciones de mercado, etcétera. La funcionalidad de soporte analítico puede admitir varios análisis en función de la información de enrutamiento histórica, métricas de enrutamiento estándar de la industria, indicadores clave de rendimiento, etcétera. Por ejemplo, la herramienta informática puede configurarse para realizar análisis de origen, análisis de regresión, modelado, predicción y/o previsión.
En algunas modalidades, la herramienta informática puede configurarse para emitir automáticamente notificaciones en función de, por ejemplo, las tendencias identificadas en función de las prácticas de enrutamiento de los brókers. Por ejemplo, la herramienta informática puede configurarse para enviar una notificación cuando la herramienta informática identifica que un bróker ha enrutado una orden en violación de las instrucciones de un cliente, o ha enrutado una orden en violación de las prácticas líderes.
Recuperación de Orden de Enmascaramiento
También debe enmascararse la actividad del cliente en la recuperación de las órdenes. Para ocultar aún más las órdenes reales, el cliente también puede solicitar una cantidad aleatoria de órdenes adicionales del servidor del supervisor, o puede solicitar órdenes periódicamente, continuamente o aleatoriamente del servidor del supervisor para enmascarar cuando el cliente solicita órdenes reales del servidor del supervisor. Por ejemplo, la computadora del cliente puede configurarse para solicitar datos del repositorio todos los días a una o varias horas en particular, independientemente de la actividad comercial real del cliente.
Repositorio de Órdenes Públicas Rellenado con Entradas Codificadas
En algunas modalidades, la información de una orden de retención de repositorio (que puede codificarse) puede exponerse al público. En consecuencia, varias características, como el número de órdenes, la fecha en que se añaden, la longitud de los datos correspondientes a las órdenes, etcétera, pueden usarse por un tercero para determinar aspectos de las órdenes.
El sistema puede configurarse para rellenar la base de datos/repositorio público con entradas codificadas formateadas para que no se distingan de otras entradas de órdenes codificadas reales, de manera que pueda ser más difícil determinar el origen o las interrelaciones entre las órdenes en función del volumen o el momento de la orden. Es posible que el servidor del supervisor no pueda distinguir las entradas de órdenes codificadas reales de las entradas codificadas rellenadas.
El servidor del supervisor puede lograr esto al crear y almacenar una cantidad suficiente de entradas codificadas para enmascarar una cantidad total de órdenes reales en el sistema o para enmascarar una cantidad de órdenes reales creados dentro de un período de tiempo particular.
El número de entradas codificadas creadas y el tiempo para la creación de las entradas codificadas pueden variar. El servidor del supervisor puede configurarse para generar un número fijo o aleatorio de entradas codificadas cuando se alcance un número umbral de órdenes reales, en intervalos de tiempo aleatorios, o en números umbral de órdenes reales aleatorios.
En algunas modalidades, el supervisor se configura para no registrar qué órdenes son reales y cuáles no.
También puede haber otras formas de generar las entradas codificadas para registrarlas en la base de datos distintas de la generación por el propio servidor del supervisor.
Como el bróker proporciona información de descifrado y relación, como se describió en la presente descripción, al cliente, el bróker y el cliente aún pueden determinar qué registros son reales y distinguir esos registros de otros registros codificados.
Búsqueda Heurística de Múltiples Trayectos
En algunas modalidades, el sistema informático del supervisor 106 o el componente informático del cliente pueden configurarse para varios tipos de consultas de datos. Los enfoques heurísticos pueden proporcionar varios beneficios técnicos, especialmente cuando hay que procesar un gran volumen de datos y los recursos informáticos y/o de tiempo disponibles pueden limitarse.
Por ejemplo, un componente informático del cliente puede consultar datos de la operación del sistema informático del supervisor 106 al solicitar bloques de Al. Los Al se calculan junto con las DK a partir de una combinación de las CK de los clientes asignados a la orden del cliente y la secuencia de BK asignados a las órdenes secundarias. En un caso de ejemplo de una única entidad de bróker que acusa recibo de las órdenes de clientes y genera las órdenes secundarias, el componente informático del cliente simplemente generaría BK0 a través de BKn y consulta las operaciones correspondientes mediante el uso de Al0 a través de AIn hasta que se contabilice la totalidad de la orden.
En un escenario de Múltiples Trayectos, solo puede usarse un subconjunto de BK posibles, en dependencia de cuáles entidades de bróker manejan la orden.
La Figura 10 es una tabla 1000 que ilustra un posible escenario en el que se usa un esquema de módulo 7 (por ejemplo, donde se usa un divisor de 7 para operaciones de módulo) y 4 de las entidades se involucraron en el manejo de la orden, de acuerdo con algunas modalidades. Pueden ser posibles otros esquemas y/o valores de módulo, y la Figura 10 se proporciona a manera de ejemplo.
Los cuadros sombreados en cruz representan índices BK usados para órdenes que no tenían ningún relleno asociado, y los cuadros sombreados longitudinalmente representan órdenes que resultaron en relleno.
Los siguientes ejemplos demuestran una posible heurística que podría usarse para buscar órdenes. La heurística puede usar varios parámetros configurables:
SWEEP = el número de columnas de BK que se barrerán o buscarán exhaustivamente (en este ejemplo se establece en 2).
BURST = los números de BK que se buscarán en una hilera para ver si hay órdenes adicionales para una entidad determinada una vez que se haya encontrado al menos una orden (en este ejemplo, se establece en 5).
MAX_SWEEPS - el número máximo de veces que se repetirá el barrido para encontrar la cantidad de relleno faltante (en este ejemplo, se establece en 3).
Buscar las BK del 1 al 14 (SWEEP x módulo = 2 x 7 = 14)- Encontradas las órdenes 2, 9 para la entidad 2 y 5, 12 para la entidad 5.
Repetir BURST a lo largo de la hilera para la entidad 2 hasta que la lista completa de BK no contenga órdenes. Buscar 16, 23, 30, 27, 44 (órdenes encontradas), buscar 51, 58, 65, 72, 79 (órdenes encontradas), buscar 86, 93, 100, 107, 114 (órdenes encontradas), buscar 121, 128, 135, 142, 149 (órdenes encontradas), busque 156, 163, 170, 177, 184 (órdenes no encontradas, dejar de buscar). Se encontraron rellenos pero la cantidad restante aún es > 0. Repetir BURST a lo largo de la hilera para la entidad 5: Buscar 5, 12, 19, 26, 33 (órdenes encontradas), buscar 40, 47, 54, 61, 68 (órdenes encontradas), buscar 75, 82, 89, 96, 103 (órdenes no encontradas, dejar de buscar). Se encontró relleno, pero aún queda cantidad.
Repetir los barridos hasta MAX_SWEEPS veces para intentar encontrar la cantidad de relleno que falta comenzando con las BK que aún no se han buscado: Buscar 15, 17, 18, 20, 21, 22, 24, 25, 27, 28 (no se encontró nada después del barrido 1), buscar 29, 31, 32, 34, 35, 36, 38, 39, 41, 42 (no se encontró nada después del barrido 2), 3ra y última búsqueda de barrido 43, 45, 46, 48, 49, 50, 52, 53, 55, 56 (orden encontrada en 55 - también Burst en la Entidad 6). Repetir BURST a lo largo de la hilera para la entidad 6: Buscar 62m 69, 76, 83, 90 (orden encontrada), buscar 97, 104, 111, 118, 125 (orden encontrada), buscar 132, 139, 146, 153, 160 (orden no encontrada, detener búsqueda). Cantidad de relleno restante = 0, Heurística completa.
En el ejemplo anterior no se encontró la orden con el índice BK 178. Si el parámetro SWEEP fuera mayor, como por ejemplo 15, se habría encontrado 178.
Los parámetros pueden mantenerse pequeños para minimizar la cantidad de datos a consultar y el tiempo de cálculo. Sin embargo, cuanto más pequeños son, mayor es la posibilidad de que se encuentre una orden con grandes espacios de orden faltante.
Tenga en cuenta que incluso con parámetros muy pequeños, las entidades que se comportan bien (sin espacios) se encontrarán por completo con una cantidad mínima de cálculos y consultas.
Es posible que la heurística no encuentre todas las cantidades de relleno si hay grandes espacios en los flujos de órdenes, pero eso se detectará si la cantidad de relleno restante > 0, pero se han agotado MAX_SWEEPS y no se han encontrado los rellenos.
La heurística no detectará en absoluto las órdenes sin rellenar después de grandes espacios si las órdenes que se encontraron representaron el 100 % de la cantidad de relleno.
En algunas modalidades, el dispositivo instructor/solicitante puede configurarse para intentar decodificar porciones del conjunto de datos recibidos de un servidor del supervisor mediante el uso de claves de al menos un conjunto de claves indexadas por módulo. Cada conjunto que contiene M claves consecutivas. Donde M representa el divisor o el número máximo de entidades computacionales en el sistema. En el ejemplo de la Figura 10, M es 7 y cada columna representa un conjunto.
Mientras que los procesadores pueden intentar decodificar uno o más conjuntos (es decir, las columnas en la Figura 10), en el ejemplo anterior, los procesadores barren dos conjuntos (SWEEP = 2).
En función de si las claves en el barrido correspondientes a un único módulo-índice decodifican con éxito porciones, los procesadores pueden intentar primero decodificar mediante el uso de solo las claves exitosas. Por ejemplo, en la Figura 10, los módulos 2 y 5 tuvieron éxito en el barrido inicial, por lo que los intentos de decodificación de ráfagas iniciales utilizan las claves en las filas correspondientes a las entidades 2 y 5 en la Figura 10.
Ejemplos de Técnicas, Variaciones y/o Algoritmos
Se pueden utilizar varios algoritmos y/o técnicas de cifrado en cualquiera de las modalidades descritas en la presente descripción, por ejemplo:
• Un algoritmo para generar claves aleatorias de una longitud específica (por ejemplo, un generador de números aleatorios que puede ejecutarse en modo de consulta/respuesta o llamada/retorno para generar claves individuales y/o puede ejecutarse para generar un bloque de claves). En algunas modalidades, el algoritmo para generar claves aleatorias puede configurarse para iniciarse con el fin de evitar la duplicación entre diferentes clientes (por ejemplo, pueden generarse claves pseudo únicas mediante el uso de información de fecha y hora, dirección IP de servidor, dirección MAC, nombre de servidor), cada cliente puede asociarse con un código inicial "secreto" que es la longitud de la clave, pueden usarse números pseudoaleatorios, no predecibles y no reproducibles para aleatorizar aún más el inicio, incluyendo el tamaño de los archivos temporales del sistema operativo, espacio de intercambio, recuentos de bytes de E/S en las interfaces de red y uso actual de memoria y recursos en el sistema, entre otros.
• Un algoritmo de cifrado/descifrado que utilice claves de -256 bits o más, dado que el tamaño de un registro puede ser relativamente pequeño (~1K bytes) o solo unas veinte veces más grande que la clave, el cifrado y el descifrado pueden realizarse mediante la codificación de la clave en un cadena aleatoria de 1 kilobyte o más y luego realizar una operación OR exclusiva (XOR) con una copia codificada del registro para el cifrado y la operación complementaria para el descifrado. Una ventaja potencial de tal esquema es la reducción potencial de la complejidad computacional de las funciones de cifrado/descifrado. En algunas modalidades, también pueden usarse claves de menos de 256 bits.
• Un algoritmo de codificación para generar una serie de claves a partir de una única clave principal. El algoritmo de codificación puede usarse para generar series de órdenes secundarias, cada uno con una clave única.
• Almacenar los datos codificados/cifrados/descifrados como caracteres imprimibles/visualizables, lo que puede reducir la complejidad asociada con la descarga de archivos binarios. Por ejemplo, puede utilizarse un esquema de codificación de 6 bits/caracteres, lo que solo puede resultar en un aumento del 33 % en el tamaño de archivo/datos. En algunas modalidades, los datos codificados/cifrados/descifrados almacenados como caracteres imprimibles/visualizables pueden usarse para representar claves en campos de etiqueta de mensaje FIX.
• Puede utilizarse una función para combinar múltiples claves en una única clave (por ejemplo, para permitir que un bróker genere una clave de procesamiento y luego genere una clave de destino a partir de la combinación de la clave de cliente y la clave de procesamiento).
• Puede proporcionarse un esquema de codificación que permita configurar el tamaño de la clave, potencialmente permitiendo la futura expansión del tamaño de la clave.
Como ejemplo adicional, las siguientes técnicas pueden utilizarse para la generación de claves secundarias, cifrado y descifrado de órdenes secundarias y/u otras entradas codificadas:
Puede utilizarse un generador de claves aleatorias (por ejemplo, suponiendo una clave de 256 bits) para generar un bloque de claves mediante el uso de un generador de números pseudoaleatorios a partir de un inicio no reproducible.
Puede proporcionarse una función de combinación de claves para combinar 2 claves en una única clave: Generar Kc = fFusionar (Ka, Kb). La función de combinación de claves debe ser una función computacionalmente liviana y debe configurarse de manera que sea difícil extraer las claves originales de la clave fusionada.
Es posible que el sistema deba tener una funcionalidad para la codificación de una primera clave en una segunda clave para generar potencialmente una lista arbitraria de claves que pueden generarse a partir de una clave inicial, generando Kn+1 = fHash (Kn). La codificación debe realizarse de manera que sea difícil determinar la clave Kn de la clave Kn+1 o para determinar que un conjunto de mensajes son parte de una única cadena de claves.
El sistema también puede incluir la funcionalidad para cifrar un registro mediante el uso de una clave (por ejemplo, Generar <Registro Cifrado> = fcfrado (K, <Registro Sin Cifrar>). Tal función también puede adaptarse para rellenar el registro para ofuscar la información relacionada extensamente.
El sistema puede incluir funcionalidad para extraer un índice anónimo de una clave (por ejemplo, Generar Al = fAi (K)), y llevar a cabo varias actividades de registro relacionadas con Al, como encontrar todos los registros que coincidan con un Al, clasificar un conjunto de registros en función de un Al, descifrar un registro (por ejemplo, Generar<Registro Sin Cifrar> =fDescifrado (K, <Registro de Cifrado>), rellenando un registro, generando una entrada cifrada y generando solicitudes Al.
Complejidad Computacional
Pueden utilizarse varias técnicas de cifrado. Una posible ventaja de usar claves aleatorias puede ser la relativa facilidad de generar grandes números aleatorios a partir de un inicio temporal no predecible.
Por ejemplo, la entidad generadora (por ejemplo, los sistemas informáticos de clientes o los sistemas informáticos del bróker) puede generar grandes bloques de números aleatorios por adelantado (por ejemplo, al inicio o como un proceso por lotes) de manera que no haya una complejidad computacional adicional durante el procesamiento de la orden.
Los sistemas informáticos del bróker pueden beneficiarse de un cálculo más rápido, ya que pueden generar claves para órdenes secundarias al recibir las claves de las órdenes principales.
La verificación de la información de enrutamiento puede realizarse después del horario comercial para reducir el impacto de las actividades computacionales durante las horas pico.
En algunas modalidades, el cliente puede desear verificar el enrutamiento de la orden en tiempo real, inmediatamente o poco tiempo después de que se procese la orden del cliente. Si bien esto también es posible, el anonimato del cliente puede verse comprometido si el cliente solicita al servidor del supervisor la verificación de la orden inmediatamente después de realizar las órdenes. Los observadores cercanos del servidor del supervisor pueden inferir razonablemente que las órdenes realizados inmediatamente antes de las consultas de verificación de la orden pueden asociarse con el cliente que realiza la consulta. En consecuencia, cuando se requiere verificación del enrutamiento de órdenes en tiempo real, la computadora o servidor del cliente puede configurarse para consultar constantemente al servidor del supervisor. La computadora del cliente podría descartar o ignorar cualquier orden no asociado con el cliente, mientras descifra el resto. En algunas modalidades, el servidor del supervisor, o un servidor separado conectado al servidor del supervisor, puede configurarse para transmitir todos los datos del servidor del supervisor a medida que se registran allí. Cualquier computadora cliente podría suscribirse a los datos transmitidos y extraer solo órdenes asociadas con el cliente respectivo, por ejemplo, mediante índices anónimos conocidos por el cliente.
Enmascaramiento de Órdenes
Las propias claves de codificación/cifrado también pueden proporcionar información a un tercero sin darse cuenta (por ejemplo, el tercero puede obtener información de longitudes de clave, patrones, etcétera). Lo mismo puede ocurrir debido a la longitud y los patrones de los mensajes codificados/cifrados.
En consecuencia, en algunas modalidades, las claves pueden tener 256 bits o más, ya sea como la clave de cliente sola o como una clave híbrida proporcionada por los sistemas informáticos del bróker.
En algunas modalidades, se usa un esquema de codificación de caracteres imprimibles con mensajes FIX, donde una clave de 256 bits podría representarse como una cadena de 43 caracteres.
En algunas modalidades, los mensajes de órdenes pueden utilizar técnicas de relleno para que el mensaje tenga una longitud estándar, lo que puede ayudar a ocultar información que puede extraerse de las longitudes de los mensajes.
En algunas modalidades, el número total de mensajes de órdenes puede enmascararse mediante la adición de un número aleatorio de entradas cifradas.
Verificación de Escalado
Al realizar la verificación de la información cifrada/texto cifrado, puede haber grandes volúmenes de datos involucrados. En consecuencia, la verificación puede ser computacionalmente intensiva y pueden aplicarse varias técnicas para reducir los requisitos computacionales.
Por ejemplo, si un cliente envió 1 millón de órdenes, es posible que el cliente deba intentar descifrar 1 millón de órdenes mediante el uso de 1 millón de claves de un grupo de 200 millones de órdenes, y tal actividad puede ser un reto informático. Un algoritmo de ejemplo puede requerir varios microsegundos de tiempo de CPU por intento de clave/mensaje, e incluso en un servidor central de ejemplo 16, puede haber solo 10 millones de intentos de clave/mensaje procesados por segundo. En este ejemplo, encontrar 1 millón de órdenes en un grupo de 200 millones requeriría 200 billones de cálculos o alrededor de 20 millones de segundos de tiempo de CPU (alrededor de 8 meses).
Las posibles soluciones a estos problemas pueden surgir a través de la creación de un índice.
En algunas modalidades, puede utilizarse una porción de la clave para establecer un índice (por ejemplo, de una clave de 48 caracteres de ejemplo, se extraería un índice de 5 caracteres, lo que daría como resultado un índice de 30 bits con alrededor de 1 billón de valores posibles).
El índice podría exponerse y asignarse a cada uno de los 200 millones de registros de mensajes y clasificarse previamente en función de los índices.
En este ejemplo, la clave real puede tener los 48 caracteres completos (288 bits) y la clave expuesta puede tener 5 caracteres que pueden exponerse. La clave aún es segura ya que los 43 caracteres restantes (258 bits) se ocultan. Dado que el cliente conoce el índice para 1 millón de órdenes, una primera etapa puede ser encontrar los registros coincidentes para cada uno del 1 millón de órdenes en función del índice. La mayoría de los índices solo obtendrían una única coincidencia, y un pequeño porcentaje obtendría 2 o más coincidencias por lo que el número total de descifrados probablemente sería un número reducido. En consecuencia, la verificación puede realizarse de manera factible ya que puede reducirse el cálculo en comparación con una implementación sin el uso del índice como se describió anteriormente.
En algunas modalidades, la herramienta computacional puede configurarse para proporcionar un servicio de consulta donde solo se descarguen los índices coincidentes a solicitud del cliente. El cliente puede consultar cualquier número de índices para descargar la información de la orden asociada respectiva para enmascarar las órdenes específicas y el número de órdenes que coinciden con el cliente (enmascaramiento de sobresuscripción). El servicio puede publicar una lista de índices existentes (no vacíos) junto con cada conjunto de datos para facilitar este enmascaramiento de sobresuscripción.
Formato del Registro
La Figura 3 muestra un formato del registro de ejemplo, de acuerdo con algunas modalidades.
En algunas modalidades, los datos del mensaje cifrado pueden almacenarse en un formato que permite delimitar registros individuales, expone la cadena de índice para cada registro y/o permite un número de secuencia de registro y una suma de comprobación (para garantizar que todos los registros se hayan descargado y que ninguno de ellos ha sido dañado o truncado).
El sistema del supervisor también puede almacenar los registros en un almacenamiento de datos, como una base de datos. En consecuencia, el almacenamiento de datos puede configurarse para retornar varios valores, como 1 ó 0 "registros" por consulta basada en AI. Cada "registro" puede contener cualquier número de "mensajes" concatenados, y cada mensaje puede cifrarse con su propia clave DK. Se puede realizar una "consulta", en donde se realiza una solicitud de 1 o más "registros" del almacenamiento de datos.
Dado que el tiempo de ida y vuelta del tiempo de consulta puede ser decenas de milisegundos o más incluso para un único registro, los servidores proxy, las herramientas informáticas y/u otras aplicaciones que acceden a los sistemas informáticos del supervisor 106 pueden mejorar la eficiencia al solicitar grandes bloques de registros (incluso miles a la vez).
Los datos que se almacenan en el sistema informático del supervisor 106 son una serie de registros de mensajes almacenados en función del código Al. Los datos pueden ser indexados/consultados por los siguientes campos: Fecha; Al; Código de región; y/o Tipo de instrumento/Tipo de datos.
El registro que se retorna puede tener la siguiente información de "encabezado" para el registro completo: Longitud del registro en bytes; y/o una suma de comprobación aritmética del registro (por ejemplo, la suma de comprobación de 32 bits).
Los datos pueden ser una serie concatenada de registros cada uno de los cuales tiene una porción sin cifrar y una porción cifrada. La porción no cifrada, por ejemplo, puede tener un esquema de delimitación de registro, una longitud de registro, una cantidad de mensajes y una suma de comprobación del registro (usada para validar la transmisión y el almacenamiento en búfer del registro - por ejemplo, la suma aritmética de 32 bits de todos los bytes en el registro). La porción cifrada, por ejemplo, puede incluir un mensaje de datos que tenga una copia sin formato del mensaje en su protocolo original (por ejemplo, FIX u otros protocolos como OUCH. SAIL); una marca de tiempo del mensaje de datos (marca de tiempo con resolución de nanosegundos); un tipo de protocolo de mensaje; y una suma de comprobación del mensaje (por ejemplo, una suma de comprobación que es independiente del protocolo, como una suma aritmética de 32 bits de todos los bytes en el mensaje que puede usarse para validar el descifrado).
El mensaje real de la orden/transacción puede incorporarse en una trama que también se cifra. Parte de la trama puede ser un código de inicio que puede usarse para indicar si la trama es probable que coincida con la clave de descifrado.
En otras palabras, la única forma automatizada de verificar el descifrado correcto del mensaje es verificar el mensaje en su formato nativo (FIX por ejemplo tiene un campo de suma de comprobación estándar y comienza con una cadena estándar como "8=FIX"). Sin embargo, requiere una suposición en cuanto al protocolo y formato del mensaje.
En algunas modalidades, la complejidad puede reducirse mediante el uso de un formato de trama que encapsule el mensaje de destino de manera que pueda usarse independientemente para verificar la validez del mensaje independientemente del formato.
Por ejemplo, una trama puede comenzar con la cadena "XX" y terminar con una suma de comprobación de 4 caracteres. En este ejemplo, todos los caracteres intermedios serían el mensaje cifrado original. Puede haber beneficios potenciales ya que tal implementación puede permitir el manejo de mensajes que no se formatean como mensajes FIX, tal como formatos de mensajes binarios que pueden utilizarse por algunos intercambios.
Los registros también pueden incluir, por ejemplo:
Una clave criptográfica - Esta etiqueta contiene las claves CK o DK/AI. Esta clave se usa por el servicio del Supervisor para cifrar e indexar el mensaje en el almacén de datos del Supervisor.
Una clave de bróker - proporcionada por los brókers aguas arriba en los rellenos de las órdenes/ACK para indicar la primera clave de una secuencia de claves asignadas a las órdenes secundarias. Esta etiqueta se requiere si un bróker está manejando una orden que tenía clave criptográfica configurada por el cliente y el bróker ha generado una o más claves de bróker para las órdenes secundarias salientes. Este campo puede ser, por ejemplo, una cadena que represente una clave BR de 512 bits codificada en BASE64. Puede usarse en el mensaje ACK enviado de regreso desde un bróker a un cliente/bróker tras recibir una nueva orden con un CK.
Esta etiqueta también puede usarse internamente dentro de una pila de brókers para comunicar las claves BK entre las entidades dentro de la pila.
Modo del bróker - esta etiqueta indica cómo el bróker está manejando las órdenes del Supervisor. Esta etiqueta es un carácter y puede tener uno de los siguientes valores: 'A' - el esquema completo de cifrado de claves CK.BK está en uso; 'C' - la clave está completamente controlada por el cliente; 'B' - la clave está completamente controlada por el bróker; 'P' - el cliente no está preparado para el almacenamiento de órdenes del supervisor; y 'X' - el cliente ha elegido no almacenar esta orden en un sistema informático del supervisor.
Convenios
La metodología del supervisor puede requerir que las claves criptográficas se transmitan entre los clientes, los brókers y el supervisor. Para simplificar esta metodología tanto como sea posible y permitir la implementación a través de una metodología simple de transferencia de etiquetas, pueden seguirse los siguientes convenios:
Si una entidad recibe una clave que es más corta de lo esperado, por ejemplo, si un bróker espera una clave CK de 256 bits, pero recibe solo una clave de 128 bits, el campo puede rellenarse delante con 0 para crear la longitud de la clave esperada. Por ejemplo, si se espera una clave de 8 dígitos y se recibe 12345, puede rellenarse con 00012345. Si una clave tiene dos porciones, como en el caso de DK y Al, luego la clave de codificación/cifrado, DK en este caso, es el lado izquierdo de la clave, y Al es el lado derecho de la clave.
Los siguientes son algunos ejemplos donde se espera un DK de 8 dígitos y se espera un Al de 2 dígitos: Si se recibe una clave de 10 dígitos, los 8 dígitos de la izquierda son el DK y los 2 dígitos de la derecha son el Al. Por ejemplo, si se recibe 1234567890, entonces, DK es 12345678 y Al es 90.
Si se recibe una clave más larga con 14 dígitos, luego, una vez más, DK son los 8 dígitos más a la izquierda y Al son los 2 dígitos más a la derecha. Por ejemplo, si se recibe 12345678909876, el DK es 12345678 y Al es 76. El 9098 en el medio se descarta.
Si se recibe una clave abreviada con 8 o 9 dígitos, luego se aplica la misma regla. Por ejemplo, si se recibe 87654321, luego la clave completa se usa para DK, 87654321, y los 2 dígitos más a la derecha, 21, son el Al.
Si se recibe incluso una clave abreviada con, por ejemplo, solo 5 dígitos, luego la clave se rellena y luego se aplican las reglas anteriores para DK y Al. Entonces, por ejemplo, si se recibe 54321, se rellena con 00054321 y se convierte en DK, y el Al son los 2 dígitos más a la derecha, 21.
Esta metodología potencialmente ayuda a eliminar problemas con los números 0 con relleno delante que se manejan incorrectamente. Básicamente, numéricamente 0123 es el mismo número aritmético que 123, pero criptográficamente son diferentes, por lo que si se rellena con 0 a la izquierda, este problema puede resolverse. El objetivo es que el sistema informático del supervisor funcione si el bróker pasa la clave CK de cliente al sistema informático supervisor sin asignar nunca los BK, y generando luego los d K y Al. Mediante el uso del convenio anterior, la metodología puede funcionar incluso si Ck es más pequeño o más grande que el DK y el Al requeridos. Esta metodología puede facilitar la compatibilidad hacia adelante y hacia atrás si las funciones de cifrado y codificación se modifican o mejoran en el futuro. Los despliegues de la nueva tecnología pueden ser gradual mientras se mantiene la compatibilidad hacia adelante y hacia atrás. Este protocolo de transferencia de claves se usa para los CK, BK, DK y Al, y para cualquier clave nueva en el futuro.
Bróker como Cliente
En algunos casos, el bróker puede estar recibiendo órdenes de un segundo cliente que es a su vez un bróker para un primer cliente. Puede ser conveniente que el segundo cliente sea capaz de verificar las acciones del bróker. También puede ser conveniente que el primer cliente sea capaz de verificar las acciones del bróker del primer cliente, y también del bróker del segundo cliente. En algunas modalidades, el servidor del supervisor de la presente invención puede usarse como supervisor entre los brókers además de usarse como supervisor entre el último bróker que coloca las órdenes y las sedes. Opcionalmente, el bróker del primer cliente puede compartir la clave de bróker del primer cliente con el primer cliente, y también puede transmitir esa clave al bróker del segundo cliente para que el bróker del segundo cliente pueda generar las órdenes secundarias mediante el uso de la clave compartida entre ambos clientes. De esta forma, tanto el bróker del primer cliente como el primer cliente podrían recuperar y descifrar la información de la orden del servidor del supervisor. Alternativamente, el segundo cliente y el bróker pueden usar una segunda clave no compartida con el primer cliente. Opcionalmente, la segunda clave puede basarse o derivarse de una primera clave compartida entre el primer cliente y el bróker del primer cliente.
Modalidades de ejemplo
La siguiente sección describe algunas modalidades. Pueden contemplarse otras modalidades y estas modalidades se proporcionan como ejemplos. Pueden incluirse elementos adicionales, iguales, diferentes, menores y/o alternativos en varias otras modalidades.
En algunas modalidades, puede haber una ventaja potencial en la implementación del servidor del supervisor como un servidor separado del bróker o la sede, ya que el supervisor puede estar mejor equipado para consolidar todas las órdenes en una base de datos, que de esta manera posiblemente logre un enmascaramiento más sólido de las órdenes del cliente que si cada intermediario o lugar mantuviera su propio servidor supervisor operando en hardware o software.
Ejemplo 1
En algunas modalidades, un cliente puede transmitir una orden sin cifrar junto con una clave de cliente que se proporciona por el cliente a través de un canal seguro a un bróker.
El propio canal seguro puede cifrarse, etcétera, pero la orden no se cifra con la clave de cliente. La clave de cliente puede incorporarse como una etiqueta o campo en la orden. El cliente mantiene un registro de claves y órdenes de cliente, por ejemplo, en una base de datos 110 mantenida por el cliente. La base de datos 110 puede implementarse mediante el uso de varias tecnologías de bases de datos, tal como bases de datos relacionales (por ejemplo, bases de datos SQL), bases de datos planas, hojas de cálculo de Excel, valores separados por comas, etcétera. Si la base de datos 110 se implementa mediante el uso de la tecnología de base de datos relacional, la base de datos de almacenamiento 110 puede configurarse para almacenar adicionalmente las relaciones entre varios registros de datos. La base de datos de almacenamiento 110 puede implementarse mediante el uso de varias tecnologías de hardware o software, tal como unidades de disco duro o de estado sólido, matrices redundantes de discos independientes, almacenamiento en la nube, dispositivos de almacenamiento virtual, etcétera.
El bróker puede generar las órdenes secundarias en función de la orden del cliente, y envía cada orden al supervisor con un hash de la clave de cliente para que cada orden pueda volver a vincularse de regreso con la orden original del cliente. El hash puede ser específico del cliente, específico del bróker, específico de la relación cliente-bróker, etcétera.
El supervisor puede mantener un registro con respecto a las órdenes enviadas a una o más sedes y su clave secundaria asociada, y enviar las órdenes a las sedes, de manera que las órdenes se despojan de cualquier información clave.
El supervisor puede luego publicar públicamente todas las transacciones (órdenes, cancelaciones, reemplazos, rellenos, etcétera), cifradas con la clave secundaria correspondiente.
Luego, un cliente puede acceder / recuperar la información de la transacción, y verificar las transacciones reales con las órdenes enviadas al bróker mediante el uso del registro mantenido por el cliente. En algunas modalidades, puede utilizarse una herramienta informática para la verificación y/u otro análisis de las órdenes.
Ejemplo 2
En algunas modalidades, en lugar de que un cliente proporcione una clave de cliente, un bróker, al recibir una orden del cliente de un cliente, genera una clave de cliente y la comunica de regreso al cliente. Por ejemplo, el bróker puede comunicar la clave de cliente mediante el uso en el curso de un mensaje de acuse de recibo.
Ejemplo 3
En algunas modalidades, puede que no haya supervisor y las sedes pueden recibir las órdenes secundarias y las claves. Las sedes pueden cifrar aún más la información de la transacción mediante el uso de las claves y los clientes pueden recuperar y acceder a esta información, descifrarla y usarla para verificar las características asociadas con el enrutamiento de sus órdenes. Por ejemplo, el cliente puede comunicarse directamente con la sede respectiva para obtener la información de enrutamiento de la orden. Por ejemplo, uno o más sedes pueden informar la información de enrutamiento de la orden a un servidor del supervisor después de haber recibido las órdenes de los brókers. El cliente luego puede recuperar la información de enrutamiento de la orden de una o más sedes del único servidor del supervisor.
Ejemplo 4
En algunas modalidades, pueden utilizarse claves asimétricas. Por ejemplo, un cliente puede exponer una clave pública que puede utilizarse para cifrar la información de la orden relacionada con las órdenes del cliente. El cliente puede mantener una copia de la clave privada asociada para su uso en el descifrado.
Ejemplo 5
En algunas modalidades, un bróker puede agregar un número de secuencias al final de la clave de cliente y luego codificarla para crear las claves secundarias. Tal implementación puede ser útil para que un cliente determine cuántas órdenes secundarias pueden asociarse con su orden principal.
Ejemplo 6
En algunas modalidades, el bróker asigna una clave de procesamiento a cada orden del cliente, comunica la clave de procesamiento al cliente y luego genera una clave de destino para cada orden secundaria al intercambio en función de una combinación de la clave de cliente y la clave de procesamiento.
Ejemplo 7
En algunas modalidades, se asocia un índice con la información de la transacción para ayudar en la identificación de qué órdenes pertenecen a un cliente. Por ejemplo, el índice puede establecerse a través de la exposición de una porción de la clave, o utilizando diferentes valores hash de la clave para que actúen como índice.
Un cliente puede descargar y/o solo procesar la información que tenga los índices adecuados, reduciendo potencialmente el tiempo computacional total requerido para la verificación.
Ejemplo 8
En algunas modalidades, el supervisor o la sede pueden almacenar los mensajes en el búfer y/o rellenar los mensajes de manera que los mensajes tengan un tamaño uniforme. En algunas modalidades, el supervisor o la sede pueden almacenar los mensajes en el búfer y/o rellenar los mensajes de manera que los mensajes tengan un tamaño aleatorio.
Ejemplo 9
En algunas modalidades, los clientes pueden configurarse para descargar los índices adicionales o todos los índices para enmascarar las órdenes.
Ejemplo 10
En algunas modalidades, el supervisor o la sede pueden agregar entradas cifradas aleatorias a la información proporcionada.
Ejemplo 11
En algunas modalidades, el supervisor puede configurarse para recopilar los datos de la solicitud para las rutas en las que no hay sistemas intermediarios (es decir, 0 saltos). En tales situaciones, el supervisor puede recibir los datos de la solicitud que se enrutan directamente desde un dispositivo del instructor a un dispositivo de destino sin intermediario. Si bien no necesariamente proporciona cualquier información desconocida con respecto a los detalles de la solicitud, los datos de la solicitud pueden incluir marcas de tiempo, velocidades de llenado de operaciones y otra información para comparar con el desempeño del intermediario, y/o simplemente para proporcionar una imagen más completa de las actividades de un sistema de instructor.
Parámetros Informáticos
La selección de los parámetros informáticos puede ser relevante para algunas modalidades en vista de la capacidad y/o la necesidad de escalar para manejar un gran número de órdenes y/o órdenes enrutadas. La complejidad y/o el volumen del cifrado provoca que las limitaciones de los recursos disponibles (por ejemplo, procesadores, memoria, tiempo) se conviertan en un problema no trivial a resolver. Además, una mayor complejidad computacional en relación con las claves de cifrado puede ser preferible para mejorar la capacidad de ofuscar y/o mantener la confidencialidad, pero puede haber efectos aguas abajo correspondientes cuando el descifrado de las claves es necesario para la verificación de la orden.
En algunas modalidades, los sistemas informáticos del bróker 104 o los sistemas informáticos del supervisor 106 pueden realizar la generación de varias claves criptográficas. Estas claves criptográficas pueden, como se describió en algunas de las modalidades anteriores, configurarse de manera que persista una relación entre las generaciones de claves que, si se conocen de antemano, pueden usarse para "reconstruir" claves si se conoce una "clave inicial". En algunas modalidades, varias claves de cifrado pueden precalcularse por varias entidades y/o sistemas informáticos asociados. Por ejemplo, pueden generarse bloques de CK mediante el uso de los números aleatorios / pseudoaleatorios independientes que pueden generarse automáticamente en un sistema informático del supervisor 106 o un proxy, para uso con clientes y/o brókers.
Puede establecerse y/o precalcular un número de claves, que puede corresponder al número de claves requeridas para un día, o en algunas modalidades, un número adicional de claves. Las claves sin usar pueden usarse en días subsecuentes (los números aleatorios no expiran) y, además, las claves BK pueden generarse en bloques de claves. Si bien la clave inicial en cada bloque puede ser un número aleatorio independiente, es posible que cada bloque necesite ser un bloque de tamaño prácticamente infinito de BK.
En lugar de calcular grandes números de BK ejecutando SHA512 repetidamente, puede generarse un número finito de BK que luego pueden disponerse en una matriz multidimensional para facilitar el manejo. Por ejemplo, un hipercubo de cuatro dimensiones de 29x29x29x29 requeriría la generación de 116 BK mediante el uso de SHA512 y, luego, podría generar 707,281 BK mediante la operación X-OR de cuatro BK para cada campo del hipercubo. Pueden usarse otros tipos de matrices, que tienen un número n de dimensiones, y se proporciona un hipercubo de 4 dimensiones simplemente como ilustración. En consecuencia, puede proporcionarse un gran número de BK disponibles para que, en el improbable caso de que se usen todos los BK, un algoritmo puede simplemente envolver y continuar mediante el uso de la matriz con un efecto limitado y/o nulo en la seguridad o el procesamiento de datos. Mediante el uso de un número primo tal como 31 para las dimensiones puede ayudar a mejorar el uso de los BK disponibles.
Mediante el uso del ejemplo anterior, un sistema podría precalcular los bloques BK de 100K (cada uno con 117 entradas - BK0+ BK1 hasta BK116.) Esto requeriría un poco más de 1 GB de almacenamiento (en RAM) y proporcionaría BK para las órdenes principales de 100K.
El número de bits utilizados para el cifrado también puede ser un factor y/o parámetro importante para la selección. Por ejemplo, pueden seleccionarse varios tipos de parámetros de cifrado, tales como los siguientes: CK - 128 bits, DK - 128 bits, BK - 256 bits, Al - 32 bits, s Ha 256 puede utilizarse para generar los bloques de BK, AES128 puede utilizarse para cifrar los mensajes mediante el uso de los DK.
Como otro ejemplo, el aumento de la potencia de cálculo disponible en procesadores de más de 32 bits (por ejemplo, procesadores de 64 bits y/o computadoras cuánticas) y, por lo tanto, pueden seleccionarse parámetros que aprovechen este aumento de la capacidad de procesamiento para mejorar la seguridad (por ejemplo, con aumento de la energía informática, las partes malintencionadas también pueden ser capaz de aplicar el aumento de la potencia de cálculo para descifrar claves criptográficas [por ejemplo, ataques de fuerza bruta, ataques de cumpleaños]).
Por ejemplo, el tiempo de cálculo para AES256 frente a AES128 en un procesador de 64 bits es solo un 30 % mayor y puede proporcionar un enfoque viable. Igualmente, calcular SHA512 frente a SHA256 en un procesador de 64 bits puede requerir menos del 25 % de tiempo de cálculo adicional.
En consecuencia, en algunas modalidades, una implementación puede utilizar los siguientes parámetros de cifrado: CK - 256 bits, DK - 256 bits, BK - 512 bits, Al - 40 bits, SHA512 para generar bloques de BK y AES256 para cifrar los mensajes mediante el uso de los DK.
Una motivación para este cambio puede ser mejorar la seguridad del cifrado mediante el uso de AES256 que puede proporcionar un estándar más sólido para el cifrado de claves simétricas. El esquema Al puede mejorarse para que los intermediarios puedan usar un subconjunto de dígitos significativos en un día determinado para crear una base de datos e indexar mensajes mediante el uso de los Al. Tal implementación puede ayudar a escalar el esquema de base de datos y búsqueda de Al sin necesidad de cambio del protocolo o la función de los juegos de herramientas del bróker o el proxy.
Con referencia a la implementación de ejemplo en la Figura 9, un sistema/dispositivo informático del cliente puede asociarse con un cliente que desea proporcionar instrucciones relacionadas con un resultado específico (por ejemplo, un deseo de comprar, vender un activo subyacente particular). Puede haber otras instrucciones asociadas, tal como los parámetros sobre cómo debe realizarse dicha transacción, o las limitaciones de la misma. Por ejemplo, el cliente puede desear el mejor precio posible, la mejor ejecución posible, el uso de solo ciertos tipos de enrutamiento y/o brókers, el uso de solo ciertas sedes, la ejecución escalonada y/o en función de una secuencia de tiempo (por ejemplo, para asegurar la llegada / ejecución sincronizada, ejecución retrasada), etcétera.
El cliente, a través de los sistemas informáticos del cliente 102, puede emitir tal solicitud a una institución financiera, quien, por ejemplo, puede actuar como un bróker o junto con un número de brókers en la ejecución de las instrucciones del cliente. En particular, la institución financiera y/o los brókers pueden tener una discreción considerable en cuanto a cómo debe llevarse a cabo la transacción, y la institución financiera y/o los brókers pueden, en algunas circunstancias, tener que elegir entre diferentes opciones y/o posibilidades en la ejecución de las transacciones y/o etapas de la transacción. En algunos enfoques convencionales, ha sido difícil para un cliente determinar si las instrucciones del cliente se llevaron a cabo de una manera que estaba alineada con los intereses del cliente.
En consecuencia, se han planteado algunas preocupaciones sobre la conveniencia de las acciones de los brókers y/o subordinados. Además, algunos brókers están bajo escrutinio regulatorio en relación con la ejecución de las órdenes de los clientes que recibe por el bróker y es posible que deseen reducir y/o simplificar la carga de los informes regulatorios mediante el uso de tal sistema. El sistema de verificación del enrutamiento también puede usarse en otros contextos, por ejemplo, para identificar dónde los dispositivos y/o procesos están fallando en los estándares de transacción (por ejemplo, fallando en transmitir las operaciones a tiempo, lo que lleva a órdenes sin llenar o precios desventajosos), para identificar dónde los dispositivos están funcionando mal, para identificar las diferencias en el rendimiento entre los brókers / sedes / enrutadores del bróker, entre otros.
En este ejemplo, los sistemas de la institución financiera pueden incluir una variedad de componentes diferentes, que pueden incluir, por ejemplo, sistemas de procesamiento previo o posterior, un sistema de enrutamiento inteligente (por ejemplo, tal como una plataforma que puede usarse para la normalización de la latencia), dispositivos de red/servidores proxy y similares. El cliente puede transmitir instrucciones a los sistemas de la institución financiera a través de un sistema informático del instructor vinculado a un sistema del supervisor, el sistema informático del supervisor que se configura para facilitar la verificación de las órdenes de enrutamiento en función de la información proporcionada por el sistema informático intermediario.
En algunas modalidades, el sistema informático del instructor puede incluir una capa de aplicación lógica, tal como una interfaz que puede configurarse para interoperar como una extensión del sistema informático intermediario. En algunas modalidades, el sistema informático intermediario se conecta a los sistemas informáticos del bróker (en este ejemplo, el centro de datos de la institución financiera) y se configura para obtener la información relacionada con las órdenes realizadas por los sistemas informáticos del bróker y enviados a los sistemas informáticos de la sede. El sistema informático intermediario puede recibir la información de la orden y luego pasar la orden a la sede, o en algunas modalidades, el sistema informático intermediario puede simplemente "intervenir" en las comunicaciones para recuperar la información que se comunica (por ejemplo, los sistemas informáticos del bróker interactúan directamente con los sistemas informáticos de la sede), y el sistema informático intermediario puede, por lo tanto, recibir la información de la operación que tiene varias etiquetas que encapsulan varias claves de cifrado que representan las etiquetas usadas para identificar qué orden pertenece a qué instrucción de cliente / bróker, etcétera. En algunas modalidades, también pueden capturarse los acuses de recibo de las órdenes y también puede extraerse la información, tal como etiquetas, de las señales de acuse de recibo.
Las claves/etiquetas criptográficas pueden generarse en varias etapas de la transacción y por varias partes, por ejemplo, por el cliente, por un proxy asociado con un cliente, un sistema informático del bróker, un sistema informático de la sede, etcétera. Estas etiquetas pueden usarse como se describió a lo largo de esta memoria descriptiva y, por ejemplo, puede haber una clave criptográfica de cliente que se recibiría de un cliente y luego se pasaría a través de una pila electrónica (por ejemplo, brókers, sedes, varios sistemas informáticos).
En dependencia del modo de operación, la etiqueta se pasaría a todas las órdenes de los clientes o las entidades generadoras de órdenes secundarias la usarían para generar claves DK, Al.
Una clave de bróker puede ser una etiqueta que se comunica de regreso al cliente para indicar la clave BK que fue asignada a la orden del cliente por el bróker. Esta etiqueta puede pasarse hacia adelante a través de la pila para indicar a todas las entidades que generan órdenes secundarias qué BK0 se seleccionó para esta orden del cliente. Puede haber una etiqueta de "modo del bróker" que también puede pasarse, lo que indica cómo una orden ser procesará por el bróker. La etiqueta "modo del bróker" puede ser, por ejemplo, un carácter que tenga varios valores que pueden ser indicativos de diferentes modos de operación.
Ejemplos de modos de operación pueden incluir: 'A' - el esquema completo de cifrado de claves CK.BK está en uso; 'C' - la clave está completamente controlada por el cliente; 'B' - la clave está completamente controlada por el bróker; 'P' - el cliente no está preparado para el almacenamiento de órdenes del intermediario; y 'X' - el cliente ha elegido por no almacenar esta orden en el intermediario.
Por ejemplo, si un bróker recibe una orden que no tiene una etiqueta de clave de cliente, hay tres opciones:
Es posible que el cliente no esté preparado para enviar las órdenes habilitadas para los intermediarios en esta sesión, por lo que la clave de bróker o las etiquetas de modo del bróker no deben proporcionarse en el mensaje ACK ni en ningún mensaje de retorno subsecuente.
El cliente está preparado para enviar las órdenes habilitadas para los intermediarios en esta sesión con CK proporcionados por el cliente. Por lo tanto, el cliente ha elegido por no enviar estas órdenes a través del intermediario al omitir la etiqueta de clave de cliente. El bróker no enviará de regreso la etiqueta de clave de bróker en el ACK. El bróker enviará de regreso la etiqueta de modo del bróker con un valor (por ejemplo, un valor de 'X'), lo que confirma que la orden no se almacenará en el sistema informático intermediario.
El cliente está preparado para enviar todas las órdenes a través del sistema informático intermediario, pero el cliente simplemente quiere que el bróker asigne las claves. El bróker debe retornar la BK0 asignada a la orden en la etiqueta de clave de cliente y un valor (por ejemplo, una 'B') en la etiqueta de modo del bróker que indica que la asignación de clave está controlada por el intermediario.
Si el bróker recibe una orden que tiene una etiqueta de clave de cliente, hay tres opciones:
Si el cliente no está preparado para enviar las órdenes habilitadas para los intermediarios en esta sesión, la etiqueta de clave de bróker no debe retornarse y la etiqueta de modo del bróker debe establecerse en un valor (por ejemplo, 'P') que indica que el cliente no está preparado para las órdenes habilitadas por los intermediarios.
Si el cliente está preparado para enviar las órdenes habilitadas para los intermediarios en esta sesión, es posible que el bróker solo desee pasar la etiqueta del cliente al servicio del intermediario. En este caso, la etiqueta de clave de bróker no se retornaría al cliente y la etiqueta de modo del bróker se establecería en un valor (por ejemplo, 'C') que indica que la clave asignada está completamente controlada por el cliente.
Alternativamente, el Bróker puede implementar la estrategia de clave de bróker. La etiqueta de clave de bróker se establecería en la clave BK0 que el bróker asignó a esta orden del cliente. La etiqueta de modo del bróker se establecería en un valor (por ejemplo, 'A') que indica que está en uso el esquema criptográfico CK, BK completo. Los datos pueden almacenarse en los sistemas informáticos intermediarios en varias formas, tal como en un almacenamiento de base de datos y/o almacenamiento de datos, que tiene varios registros. Por ejemplo, los registros pueden configurarse para realizar varias consultas asociadas con varias solicitudes.
En algunas modalidades, el sistema informático intermediario también puede recibir la información proporcionada por los sistemas informáticos de la sede, tal como datos de mercado, información de confirmación de la operación, etcétera. Esta información puede utilizarse por el sistema informático intermediario para determinar si la operación fue debidamente ejecutada por la sede, o si otros factores interfirieron con la operación (provocando que la operación no se cumpliera, el precio deseado no se alcanzara, etcétera). Por ejemplo, un bróker puede enrutar subrepticiamente una operación a una sede particularmente lento que proporcione un incentivo financiero importante para el bróker. La operación puede ejecutarse de manera subestándar y tal información puede transmitirse en la salida de los datos correspondiente por los sistemas informáticos de la sede.
Flujos de trabajo de ejemplo
La siguiente sección describe algunos flujos de trabajo de ejemplo 1300, 1400 y 1500 que pueden realizarse por varios sistemas, dispositivos, módulos y/o componentes, de acuerdo con algunas modalidades. Pueden ser posibles más, menos, diferentes y/o alternativas las etapas, en diferentes órdenes, permutaciones y/o combinaciones.
La Figura 12 es un flujo de trabajo de ejemplo que proporciona las etapas de un método de ejemplo desde la perspectiva de un bróker, de acuerdo con algunas modalidades. El flujo de trabajo 1200 puede realizarse, por ejemplo, en un sistema para la gestión de los procesos de datos en una red de recursos informáticos (por ejemplo, un dispositivo informático del bróker), el sistema que comprende al menos un procesador configurado para ejecutar las instrucciones interpretables por máquina.
En 1202, un dispositivo informático del bróker puede recibir, desde un dispositivo del instructor, una solicitud principal para la ejecución de un proceso de datos principal ejecutable por los recursos informáticos. En algunas modalidades, el dispositivo del instructor también puede proporcionar al menos una clave de instructor. En algunas modalidades, el dispositivo informático del bróker puede configurarse para generar al menos una clave de instructor y para generar las señales para la comunicación de al menos una clave de instructor al dispositivo del instructor. En 1204, el dispositivo informático del bróker puede generar las solicitudes secundarias para el enrutamiento a al menos un dispositivo de destino correspondiente cada dato secundario, cada una de las solicitudes secundarias para ejecutar al menos una porción de la solicitud principal e incluir una clave de destino derivada de al menos una clave de instructor. En algunas modalidades, generar la al menos una solicitud secundaria comprende generar una pluralidad de solicitudes secundarias.
En 1206, el dispositivo informático del bróker puede seleccionar una secuencia de claves de destino, cada clave de destino en la secuencia para incluir en una solicitud secundaria correspondiente de la pluralidad de solicitudes secundarias. Seleccionar una secuencia de claves de destino, por ejemplo, puede implicar la codificación de al menos una clave de instructor para generar una primera clave de destino en la secuencia y generar una clave de destino subsecuente en la secuencia al codificar una clave de destino anterior en la secuencia.
En algunas modalidades, al menos uno de (i) un algoritmo de codificación para seleccionar la secuencia de claves, (ii) y una secuencia predeterminada de claves a partir de la cual se selecciona la secuencia de claves de destino se comparten entre el sistema y el dispositivo del instructor.
En algunas modalidades, el dispositivo informático del bróker puede configurarse para la codificación de al menos una clave de instructor con una clave del intermediario para generar al menos una clave de destino y transmitir al dispositivo del instructor un mensaje que incluye la clave de intermediario.
El dispositivo informático del bróker también puede configurarse para codificar una secuencia de claves de intermediarios con al menos una clave de instructor o derivados de al menos una clave de instructor para generar al menos una clave de destino.
En 1208, el dispositivo informático del bróker puede enrutar cada una de las solicitudes secundarias a al menos un dispositivo de destino correspondiente.
La Figura 13 es un flujo de trabajo de ejemplo que proporciona las etapas de un método de ejemplo desde la perspectiva de un supervisor, de acuerdo con algunas modalidades. El flujo de trabajo 1300 puede realizarse, por ejemplo, en un sistema para la gestión de los procesos de datos en una red de recursos informáticos (por ejemplo, un dispositivo informático del supervisor), el sistema que comprende al menos un procesador configurado para ejecutar las instrucciones interpretables por máquina.
En 1302, un dispositivo informático del supervisor puede recibir al menos una solicitud secundaria que se enruta desde un dispositivo intermediario a al menos un dispositivo de destino correspondiente, la al menos una solicitud secundaria que solicita la ejecución de al menos un proceso de datos secundario correspondiente, cada uno de los al menos un proceso de datos secundario para ejecutar al menos una porción del al menos un proceso de datos principal desde un dispositivo del instructor, y cada una de las solicitudes secundarias que incluye una clave de destino derivada al menos en parte de la al menos una clave de instructor.
En algunas modalidades, el dispositivo informático del supervisor recibe de un dispositivo solicitante al menos uno de: una clave de instructor, una clave de intermediario y una clave de índice y genera las señales para la comunicación de las solicitudes secundarias asociadas con al menos uno de: (i) la clave de instructor, (ii) la clave de intermediario y (iii) la clave de índice del dispositivo solicitante.
La al menos una solicitud secundaria puede recibirse, por ejemplo, desde uno o más dispositivos de intervención en una o más rutas entre el dispositivo intermediario y el al menos un dispositivo de destino correspondiente.
En 1304, el dispositivo informático del supervisor puede almacenar la al menos una solicitud secundaria en al menos un dispositivo de almacenamiento 110. En algunas modalidades, el dispositivo informático del supervisor puede configurarse para almacenar la al menos una solicitud secundaria en asociación con un identificador que realiza la identificación de un mecanismo por el cual la al menos una solicitud secundaria se obtuvo por el sistema.
En 1306, el dispositivo informático del supervisor puede generar las señales para la comunicación de las solicitudes secundarias a uno o más dispositivos solicitantes. En algunas modalidades, el dispositivo informático del supervisor puede configurarse para cifrar cada una de las al menos una solicitud secundaria con su clave de destino correspondiente antes de generar las señales para la comunicación de las solicitudes secundarias.
En algunas modalidades, en 1308, la clave de destino y/o la clave de índice pueden eliminarse de la al menos una solicitud secundaria antes de transmitir la al menos una solicitud secundaria a al menos un dispositivo de destino correspondiente en 1310.
En algunas modalidades, el al menos un dispositivo de destino puede ser un dispositivo intermediario adicional, y el dispositivo informático del supervisor puede configurarse para recibir al menos una clave de intermediario del dispositivo intermediario adicional, y almacenar la al menos una clave de intermediario asociada con la al menos una solicitud secundaria asociada.
En algunas modalidades, un dispositivo solicitante particular que tiene al menos una clave de instructor particular puede decodificar la solicitud secundaria cifrada correspondiente para identificar el al menos un proceso de datos secundario enrutado para ejecutar al menos un proceso de datos principal particular asociado con la clave de destino particular.
La Figura 14 es un flujo de trabajo de ejemplo que proporciona las etapas de un método de ejemplo desde la perspectiva del cliente, de acuerdo con algunas modalidades. El flujo de trabajo 1400 puede realizarse, por ejemplo, en un sistema para la gestión de los procesos de datos en una red de recursos informáticos (por ejemplo, un dispositivo informático del cliente), el sistema que comprende al menos un procesador configurado para ejecutar las instrucciones interpretables por máquina.
En 1402, el dispositivo informático del cliente puede transmitir, desde un dispositivo del instructor a un dispositivo intermediario, al menos una clave de instructor y una solicitud principal para la ejecución de al menos un proceso de datos principal ejecutable por una pluralidad de recursos informáticos, la solicitud principal para el enrutamiento como al menos una solicitud secundaria por el dispositivo intermediario para su ejecución por al menos un destino.
En algunas modalidades, en lugar de transmitir la al menos una clave de instructor, el dispositivo informático del cliente recibe al menos una clave de intermediario desde el dispositivo intermediario.
En 1404, el dispositivo informático del cliente puede recibir, desde un servidor del supervisor, un conjunto de datos que incluye los datos asociados con una pluralidad de solicitudes.
En 1406, el dispositivo informático del cliente puede identificar las porciones del conjunto de datos asociados con la al menos una solicitud secundaria mediante el uso de la al menos una clave de instrucción o derivados de la al menos una clave de instrucción. En algunas modalidades, la identificación de las porciones del conjunto de datos asociado con la al menos una solicitud secundaria se basa al menos en parte en la al menos una clave de intermediario.
En 1408, el dispositivo informático del cliente puede intentar decodificar las porciones del conjunto de datos mediante el uso de la al menos una clave de instrucción o derivados de la al menos una clave de instrucción e identificar con éxito las porciones decodificadas del conjunto de datos.
En 1410, el dispositivo informático del cliente puede asociar una porción identificada del conjunto de datos con la al menos una solicitud principal.
En algunas modalidades, el dispositivo informático del cliente puede configurarse para generar al menos una de: al menos una clave de índice y al menos una clave de destino en función de la al menos una clave de instructor y la al menos una clave de intermediario; y la identificación de las porciones del conjunto de datos asociado con la al menos una solicitud secundaria se basa al menos en parte en la al menos una de la al menos una clave de índice y la al menos una clave de destino.
En algunas modalidades, el dispositivo informático del cliente puede configurarse para generar al menos una de (i) al menos una clave de índice y (ii) al menos una clave de destino en función de la al menos una de (i) la al menos una clave de instructor y (ii) la al menos una clave de intermediario; y enviar al servidor del supervisor una solicitud de un conjunto de datos correspondiente a la al menos una de: la al menos una clave de instructor y la al menos una clave de intermediario.
En algunas modalidades, cuando las porciones identificadas del conjunto de datos incluyen datos asociados con una solicitud secundaria para un segundo dispositivo intermediario, el dispositivo informático del cliente puede configurarse para identificar o solicitar las porciones adicionales del conjunto de datos que se asocian con las solicitudes subsecundarias enviadas por el segundo dispositivo intermediario.
En algunas modalidades, el dispositivo informático del cliente puede configurarse para generar o seleccionar derivados de al menos una de: la al menos una clave de instructor, al menos una clave de intermediario y al menos una clave de índice para la identificación de las porciones del conjunto de datos asociado con la al menos una solicitud secundaria.
Control de datos
Como se describió en los varios ejemplos en la presente descripción o de cualquier otra manera, los componentes del supervisor, como los sistemas informáticos del supervisor 190, los componentes internos del supervisor 112, los componentes del supervisor 106, los dispositivos de almacenamiento de datos 110 y/o cualquier otro aspecto o sistema del supervisor pueden recibir solicitudes secundarias para su ejecución y una o más claves asociadas u otra información relacionada con las solicitudes secundarias.
En algunas modalidades, los aspectos o sistemas del supervisor pueden almacenar las solicitudes secundarias y la información asociada en un dispositivo de almacenamiento de datos 110. En algunos ejemplos, las solicitudes secundarias y la información asociada pueden proporcionarse por un sistema del supervisor 190, 112 a un dispositivo solicitante de datos.
En algunas modalidades, el dispositivo solicitante de datos puede ser un dispositivo del cliente, como un dispositivo que opera una herramienta de auditoría de verificación del enrutamiento. En algunos ejemplos, el dispositivo del cliente puede asociarse con una parte instructora (por ejemplo, un cliente que solicita la solicitud principal original), un bróker (por ejemplo, un comerciante, una mesa de operaciones comerciales, un administrador, etcétera).
Los aspectos de la herramienta de verificación del enrutamiento pueden operar en el dispositivo del cliente, en un dispositivo del servidor o alguna combinación con algunas operaciones que ocurren en el dispositivo del cliente y otras en el dispositivo del servidor.
En algunas modalidades, los aspectos de la herramienta de verificación del enrutamiento pueden manejarse por un servidor de control de datos. La Figura 15 muestra aspectos de un sistema de ejemplo 1500 que incluye un servidor de control de datos 1510. En algunos ejemplos, el servidor de control de datos 1510 recibe o tiene acceso a las solicitudes secundarias y a la información asociada, controla el acceso a los datos y, en algunas modalidades, solicita y/o gestiona las credenciales de los dispositivos solicitantes de datos.
En algunas modalidades, el servidor de control de datos puede gestionarse/operarse por un tercero de confianza, tal como un cuerpo regulador/independiente. En otras modalidades, el servidor de control de datos puede gestionarse/operarse por brókers, sedes de destino o cualquier otra parte. En algunos ejemplos, el servidor de control de datos puede estar física y/o lógicamente separado del servidor del supervisor y sus componentes.
Además de controlar el acceso a los datos relacionados con las solicitudes secundarias y los datos asociados cliente por cliente, en algunas modalidades, el servidor de control de datos se configura para controlar el acceso a los dispositivos/perfiles asociados con diferentes partes dentro de una organización del cliente. Por ejemplo, es posible que una empresa del lado de la compra no desee permitir que los comerciantes y/o las mesas de operaciones comerciales tengan visibilidad de las actividades comerciales entre sí.
En algunas modalidades, cada comerciante/escritorio puede tener su propio perfil único y/o credenciales de inicio de sesión. Estos perfiles pueden incluir datos que permiten la identificación de la lista de comerciantes/mesas para las que el perfil puede ver la actividad comercial. En algunas modalidades, en función del perfil de un usuario/grupo, el servidor de control de datos puede permitir o restringir la capacidad de ver la actividad la comercial asociada con uno o más brókers y/o con uno o más destinos. En algunas modalidades, en función del perfil de un usuario/grupo, el servidor de control de datos puede permitir o restringir la capacidad de generar y/o ver diferentes visualizaciones, informes, funciones de interfaz gráfica de usuario, algoritmo de acceso o funciones de seguimiento de la operación, y similares.
En algunas modalidades, los sistemas y/o componentes descritos en la presente descripción (por ejemplo, sistemas informáticos del bróker 104, dispositivos de procesamiento 810), pueden rastrear las claves de bróker, claves de destino, etiquetas y similares y asociarlos con uno o más perfiles para uso del servidor de control de datos para controlar el acceso a la información.
En algunas situaciones, los aspectos de una o más solicitudes secundarias y/o los mecanismos por los cuales se generan y/o enrutan esas solicitudes secundarias pueden ser patentadas, pueden proporcionar información que podría explotarse por los comerciantes oportunistas, o pueden ser confidenciales o de cualquier otra manera contener información para protegerse. En algunas situaciones, las solicitudes secundarias y los datos asociados pueden tener errores tales como copias duplicadas, errores operativos, datos dañados y similares.
En algunas modalidades, los aspectos de los sistemas, dispositivos y métodos descritos en la presente descripción pueden proporcionar la protección de la información confidencial y/o corregir los errores dentro del sistema de supervisión descrito en la presente descripción. En algunas modalidades, el sistema debe mantener la fidelidad de la información confidencial original y/o los datos sin corregir para mantener la confianza en el sistema y/o proporcionar un registro de auditoría para verificar cualquier redacción y/o corrección.
En algunas situaciones, pueden ocurrir errores en los datos informados al sistema del supervisor. Por ejemplo, pueden introducirse errores o entradas de solicitudes secundarias duplicadas mediante copias sueltas, un algoritmo de operación comercial puede cometer un error comercial que subsecuentemente se revierte a través de un relleno interno, los mensajes pueden asociarse o cifrarse con una clave incorrecta, o cualquier otra tecnología o error operativo que provoque que la información de solicitud secundaria no refleje qué actividad comercial realmente se ha producido.
Un componente del supervisor o una herramienta de verificación del enrutamiento recibe una señal de modificación de la solicitud secundaria. La señal de modificación de solicitud secundaria incluye un mensaje de máscara.
En algunas modalidades, un procesador u otro dispositivo en el sistema informático del bróker se configura para enviar un registro de corrección al sistema informático del supervisor 190. En algunas modalidades, el registro de corrección incluye uno o más campos que se corrigen en la(s) solicitud(es) secundaria(s) correspondiente(s). En algunas modalidades, el registro de corrección puede ser un reemplazo completo para una o más solicitudes secundarias correspondientes.
En algunas modalidades, los registros de corrección pueden incluir adicionalmente campos de datos que realicen la identificación de las fechas de corrección, los tiempos de corrección, las fuentes de corrección, los tipos de corrección, los motivos de corrección, los campos de comentarios, cualquier otro campo relevante y/o cualquier subconjunto o la combinación de los mismos.
En algunas modalidades, un registro de corrección incluye o se envía de cualquier otra manera al sistema informático del supervisor con uno o más identificadores para asociar el registro de corrección con su(s) solicitud(es) secundaria(s) asociada(s). En algunas modalidades, el registro de corrección incluye o se envía con la misma clave de destino que las solicitudes secundarias asociadas. En algunas modalidades, el registro de corrección puede enviarse con el mismo índice de mensaje que la(s) solicitud(es) secundaria(s) asociada(s).
En algunas modalidades, el sistema informático del bróker se configura para mantener una lista interna de las solicitudes secundarias recientes y sus claves de destino asociadas y/o índices de mensajes (por ejemplo, índices usados en los mensajes de solicitud y respuesta/acuse de recibo enviados y recibidos de las sedes). Buscando la(s) solicitud(es) secundaria(s) con las que va a asociarse un registro de corrección, el sistema informático del bróker puede determinar las claves de destino correspondientes y/o los índices de mensajes para enviar o junto con el registro de corrección al sistema del supervisor.
En algunas modalidades, en lugar del sistema informático averiado, los registros de corrección pueden recibirse de otros sistemas, tal como un sistema de destino (por ejemplo, la sede 108).
En algunas modalidades, el sistema del supervisor se configura para almacenar los registros de corrección recibidos en asociación con la clave de destino correspondiente como la(s) solicitud(es) secundaria(s) relacionada(s).
En algunas modalidades, el sistema del supervisor y/o la herramienta de verificación del enrutamiento se configuran para enmascarar las solicitudes secundarias corregidas con los datos de los registros de corrección. En algunas modalidades, el sistema del supervisor y/o la herramienta de verificación del enrutamiento pueden configurarse para cifrar, redactar, ocultar o de cualquier otra manera no proporcionar los campos de las solicitudes secundarias que se corrigen. En algunos ejemplos, la solicitud secundaria completa que debe corregirse puede cifrarse, redactarse, ocultarse o de cualquier otra manera no proporcionarse a una parte solicitante.
En algunas modalidades, los registros de corrección se agregan, vinculan o de cualquier otra manera almacenan de manera que puedan asociarse con las solicitudes secundarias correspondientes sin eliminar o sobrescribir las solicitudes secundarias originales. En algunos casos, esto puede mantener un registro permanente de todas las solicitudes secundarias originales, así como también un registro de cualquier corrección o cambio realizado a esas solicitudes originales. En algunos ejemplos, los registros de corrección pueden almacenarse o asociarse de manera que todas las solicitudes secundarias y los registros de corrección asociados con la misma solicitud principal inicial se agrupen juntos.
En algunas modalidades, cuando la herramienta de verificación del enrutamiento recibe una solicitud para recuperar un conjunto de datos que incluye los datos asociados con una pluralidad de solicitudes, la herramienta de verificación del enrutamiento se configura para proporcionar y/o visualizar solo las versiones corregidas de los datos solicitados. En algunos ejemplos, las versiones corregidas de los datos solicitados incluyen un indicador, los datos de campo corregidos u otros datos que indican que los datos proporcionados/visualizados han sido corregidos. En algunos casos, esto comunica que los datos se han modificado sin revelar necesariamente la versión original sin corregir de los datos.
En algunos casos, tras visualizar la indicación de que los datos de la solicitud secundaria se han corregido, la herramienta de verificación del enrutamiento y/o el sistema del supervisor pueden configurarse para recibir las solicitudes para visualizar/proporcionar las solicitudes secundarias tal como aparecían antes de que se corrigieran. Dado que se han mantenido las solicitudes secundarias originales, con las autorizaciones o permisos adecuados otorgados por el sistema informático del bróker u otro sistema que emita el registro de corrección, la herramienta de verificación del enrutamiento y/o el sistema del supervisor pueden proporcionar y/o visualizar las solicitudes secundarias originales.
En algunas modalidades, en lugar de un registro de corrección específico, el sistema informático del bróker, el sistema de destino u otro sistema puede enviar un registro de reemplazo. El registro de reemplazo puede tener el mismo formato que una solicitud secundaria. En algunas de tales modalidades, el sistema del supervisor y/o la herramienta de verificación del enrutamiento pueden configurarse para asociar el registro de reemplazo con una solicitud secundaria correspondiente en función de las claves, índices y/o contexto del registro de reemplazo (por ejemplo, tiempo, detalles de la orden, etcétera). En algunas modalidades, el sistema del supervisor y/o la herramienta de verificación del enrutamiento pueden configurarse para determinar si un dato recibido es un registro de reemplazo o una solicitud secundaria nueva pero similar.
De manera similar o junto con los registros de corrección, en algunas modalidades, los sistemas del supervisor y/o las herramientas de verificación del enrutamiento pueden configurarse para controlar, redactar o de cualquier otra manera no visualizar y/o proporcionar la información confidencial.
En algunas modalidades, el sistema informático del bróker puede enviar un mensaje de máscara al sistema del supervisor. En algunos ejemplos, el mensaje de máscara puede ser similar a un registro de corrección, pero en lugar de corregir un error, el mensaje de máscara puede incluir una versión enmascarada de una orden secundaria que tiene campos cifrados, redactados, en blanco o de cualquier otra manera indescifrables.
En otra modalidad, el mensaje de máscara puede incluir una o más indicadores o identificadores que indican al sistema del supervisor y/o a la herramienta de verificación del enrutamiento qué campos o porciones de las solicitudes secundarias no deben visualizarse o proporcionarse al dispositivo del cliente en un formato descifrable. formato.
En algunas modalidades, al recibir una solicitud de datos de solicitud secundaria asociada con una o más claves, el sistema del supervisor y/o la herramienta de verificación del enrutamiento se configuran para recuperar los datos de la solicitud secundaria y cualquier registro de corrección y/o mensajes de máscara asociados con una o más claves. Tras la detección de un mensaje de máscara, el sistema del supervisor y/o la herramienta de verificación del enrutamiento redacta, codifica, elimina o de cualquier otra manera oculta los campos o porciones de las solicitudes secundarias según lo indicado por los mensajes de máscara. En algunas modalidades, el sistema del supervisor y/o la herramienta de verificación del enrutamiento pueden simplemente no visualizar o enviar al dispositivo del cliente ningún campo o porciones de las solicitudes secundarias identificadas por los mensajes de máscara.
En algunas modalidades, después de la codificación o de cualquier otra manera ofuscar los campos enmascarados o las porciones de las solicitudes secundarias con una clave no proporcionada a un dispositivo solicitante, las solicitud(es) secundaria(s) que incluyen los campos enmascarados pueden cifrarse con la clave de destino.
En algunos casos, esto puede permitir que un sistema informático del bróker tenga la granularidad para gestionar el enmascaramiento de los datos de la solicitud en una solicitud cliente por cliente, clave por clave, solicitud principal por solicitud principal, solicitud secundaria por solicitud secundaria, y/o cualquier otra base.
En algunas modalidades, el sistema del supervisor y/o la herramienta de verificación del enrutamiento pueden tener un perfil de sistema informático del bróker que identifica los campos predeterminados o las porciones de las solicitudes secundarias que deben enmascararse o de cualquier otra manera no proporcionarse a un dispositivo solicitante de forma predeterminada. En algunas modalidades, el perfil del sistema informático del bróker puede identificar alternativamente o adicionalmente los campos predeterminados o las porciones de las solicitudes secundarias que deben visualizarse y/o proporcionarse a un dispositivo solicitante de forma predeterminada.
En algunos ejemplos, el sistema del supervisor y/o la herramienta de verificación del enrutamiento pueden proporcionar una indicación de que parte o la totalidad de una solicitud secundaria se ha enmascarado.
Los campos o porciones de las solicitudes secundarias que pueden enmascararse pueden incluir, pero no se limitan a, tipos de órdenes (por ejemplo, para ocultar tipos de órdenes patentadas), datos que pueden proporcionar la información sobre un algoritmo de enrutamiento patentado, etcétera.
En algunas modalidades, un mensaje de máscara puede identificar uno o más campos o porciones de una solicitud secundaria que van a redactarse, truncarse o redondearse parcialmente. Por ejemplo, las marcas de tiempo pueden modificarse para mostrar tiempos con una precisión de 10, 50, 100 o 200 microsegundos o cualquier otro grado de precisión. En algunos ejemplos, las marcas de tiempo pueden modificarse para mostrar el tiempo en milisegundos o microsegundos en lugar de nanosegundos. Puede usarse cualquier otro nivel de granularidad. Este nivel de detalle puede, en algunos casos, mostrar que las solicitudes secundarias se envían de acuerdo con los requisitos de puntualidad sin proporcionar los tiempos exactos para proteger los algoritmos de enrutamiento u otras estrategias de enrutamiento patentadas.
En algunas modalidades, con el fin de evitar que un tercero modifique la herramienta de verificación del enrutamiento para visualizar los datos de la solicitud secundaria sin aplicar las correcciones o máscaras, en lugar de operar en un dispositivo del cliente, la herramienta de verificación del enrutamiento puede alojarse en un servidor de control de datos, y puede accederse iniciando sesión desde el dispositivo del cliente.
En algunos casos, el servidor de control de datos sería operado por un tercero confiable porque el servidor de control de datos podría potencialmente tener acceso a todas las solicitudes asociadas con cada cliente y potencialmente a los datos sin procesar. En algunas modalidades, el servidor de control de datos puede configurarse para no almacenar datos sin cifrar en un almacenamiento persistente, y cualquier clave para acceder a los datos almacenados se recibiría de los dispositivos del cliente y/o bróker.
En algunas modalidades, el servidor de control de datos y/o la herramienta de verificación del enrutamiento se configuran para realizar análisis en todas las solicitudes asociadas con un dispositivo del cliente o bróker. En algunas modalidades, el servidor de control de datos y/o la herramienta de verificación del enrutamiento pueden generar análisis mediante el uso de los datos sin enmascarar, sin redondear, pero pueden configurarse para no proporcionar o visualizar los datos sin procesar (sin enmascarar/sin redondear) al dispositivo solicitante.
En algunas modalidades, el servidor de control de datos recibe los datos de la solicitud de un dispositivo del cliente con el fin de proporcionar la verificación y/o análisis de la solicitud asociada con el dispositivo del cliente.
En algunos casos, el servidor de control de datos puede actuar como un dispositivo intermedio de confianza que tiene acceso potencialmente ilimitado a los datos para realizar el análisis y generar los informes, pero también controla el acceso a los datos solo proporcionando el resultado de los análisis, los informes y/o datos enmascarados a los dispositivos del cliente.
En algunos ejemplos, el servidor de control de datos se configura para permitir que solo un dispositivo del cliente acceda a un número definido de solicitudes por período de tiempo definido.
En un enfoque alternativo o adicional, en algunas modalidades, el sistema informático del bróker 104 se configura para generar un bróker secundario y/o una clave de destino para cifrar los campos y/o las porciones de los datos de la operación. Por ejemplo, el bróker puede cifrar uno o más campos y/o porciones de un campo de marca de tiempo con una clave antes de enviarlo al sistema del supervisor. En otros ejemplos, el bróker puede enviar la clave al sistema del supervisor, y el sistema supervisor o la herramienta de verificación del enrutamiento pueden cifrar los campos identificados y/o las porciones de los datos de la operación antes de que se proporcionen/visualicen en un dispositivo del cliente.
En algunas modalidades, esta clave secundaria puede retenerse del dispositivo del cliente. En algunos casos, al realizar el enmascaramiento de los datos de la operación antes de que se almacenen en el sistema del supervisor, una herramienta de verificación del enrutamiento modificada no podría ser capaz de acceder a la información enmascarada. En algunos casos, la clave secundaria puede proporcionarse al sistema del supervisor, al servidor de control de datos u otro sistema de confianza para proporcionar a los auditores, consultores u otros usuarios autorizados el acceso a la información enmascarada.
En algunos ejemplos, puede usarse la misma clave secundaria para cifrar múltiples porciones/campos de una solicitud. En otros ejemplos, pueden usarse múltiples claves secundarias para cifrar los diferentes campos/porciones de una solicitud. En algunos casos, diferentes claves pueden utilizarse por diferentes partes autorizadas para proporcionar el acceso a diferentes porciones de los datos enmascarados a diferentes partes. En algunos casos, algunos campos/porciones de una solicitud pueden codificarse, mediante el uso de múltiples claves secundarias, de manera que algunos campos pueden requerir el acceso a dos o más claves secundarias para acceder a los datos subyacentes.
En algunos ejemplos, puede usarse la misma clave secundaria en múltiples solicitudes secundarias para proporcionar el acceso y la gestión de claves.
En algunas modalidades, las claves secundarias pueden correlacionarse para mejorar la gestión de claves. Por ejemplo, en algunas modalidades, una clave privada (aleatoria) puede fusionarse con una clave de bróker para generar una clave secundaria para un particular marco de tiempo, cliente, etcétera.
En algunas modalidades, los sistemas informáticos del cliente 102 o los sistemas informáticos del bróker 104 pueden enviar mensajes/solicitudes que no deben almacenarse por el sistema del supervisor. En algunos ejemplos, un sistema del cliente puede marcar los mensajes o de cualquier otra manera incluir una indicación de que una solicitud enviada a un sistema informático del bróker no debe monitorearse. En algunas modalidades, la indicación es un indicador o un campo que indique que un mensaje no debe supervisarse. En otra modalidad, la ausencia de una clave de cliente enviada junto con un mensaje/solicitud es una indicación de que el mensaje no debe supervisarse. En otra modalidad, un sistema informático del bróker puede tener un perfil de cliente que indica qué tipos de solicitudes van a supervisarse. A medida que llegan, uno o más campos del mensaje entrante del dispositivo del cliente se comparan con los datos del perfil del cliente para determinar si el mensaje entrante debe supervisarse. En algunas modalidades, el perfil del cliente puede indicar que los mensajes no deben supervisarse para tipos de órdenes particulares, horas del día, identificadores de clientes específicos, etcétera.
En algunas modalidades, un sistema informático del bróker puede enviar mensajes que no deben supervisarse en las sesiones de destino específicas que no envían mensajes a un destino a través de un componente del supervisor. En algunas modalidades, un sistema informático del bróker puede enviar las solicitudes secundarias sin ninguna clave de destino/bróker/cliente. En algunas de estas situaciones, el sistema del supervisor se configura para ignorar o de cualquier otra manera no almacenar las solicitudes sin claves asociadas.
En algunas modalidades, los sistemas informáticos del bróker pueden manejar y generar claves de cliente, bróker y/o de destino, pero pueden eliminar las claves antes del enrutamiento de las solicitudes secundarias.
En algunas modalidades, los sistemas informáticos del bróker pueden manejar y generar las claves de cliente, bróker y/o de destino, pero pueden acusar recibo de las solicitudes principales sin enviar de regreso un BK/CK al cliente. Con este enfoque, el sistema del supervisor recibe y almacena los datos de solicitud secundaria a los que solo puede accederse por el sistema supervisor pero no por el dispositivo del cliente (que no tiene las claves). Esto puede permitir al sistema del supervisor monitorear o de cualquier otra manera auditar su propio enrutamiento sin poner esos datos disponibles al cliente.
General
Aunque varias modalidades descritas en la presente descripción se refieren específicamente a la verificación del enrutamiento de las órdenes entre clientes y brókers, la presente invención puede aplicarse a varias partes para proporcionar la verificación de las transacciones entre otros tipos de partes en una cadena de relación. Por ejemplo, la verificación de una variedad de pedidos o fuentes de materiales, bienes o servicios en nombre de un cliente puede ser posible de acuerdo con la presente invención.
Las modalidades de los dispositivos, sistemas y métodos descritos en la presente descripción pueden implementarse en una combinación de hardware y software. Estas modalidades pueden implementarse en computadoras programables, cada computadora que incluye al menos un procesador, un sistema de almacenamiento de datos (incluyendo memoria volátil o memoria no volátil u otros elementos de almacenamiento de datos o una combinación de los mismos) y al menos una interfaz de comunicación.
El código del programa puede aplicarse a la entrada de datos para realizar las funciones descritas en la presente descripción y generar la información de salida. La información de salida se aplica a uno o más dispositivos de salida. En algunas modalidades, la interfaz de comunicación puede ser una interfaz de comunicación de red. En modalidades en las que pueden combinarse elementos, la interfaz de comunicación puede ser una interfaz de comunicación de software, como las de comunicación entre procesos. En aún otras modalidades, puede haber una combinación de interfaces de comunicación implementadas como hardware, software y una combinación de los mismos.
A lo largo de la siguiente discusión anterior, se harán numerosas referencias a servidores, servicios, interfaces, portales, plataformas u otros sistemas formados a partir de dispositivos informáticos. Se apreciará que el uso de tales términos se considera que representa uno o más dispositivos informáticos que tienen al menos un procesador configurado para ejecutar instrucciones de software almacenadas en un medio no transitorio, tangible y legible por computadora. Por ejemplo, un servidor puede incluir uno o más computadoras que operen como un servidor web, servidor de base de datos u otro tipo de servidor informático de manera que cumpla los roles, responsabilidades o funciones descritos.
Se apreciará que los sistemas y métodos descritos en la presente descripción pueden proporcionar un cálculo más eficiente, una posibilidad reducida de compromiso, etcétera.
La siguiente discusión proporciona muchas modalidades de ejemplo. Aunque cada modalidad representa una única combinación de elementos inventivos, otros ejemplos pueden incluir todas las combinaciones posibles de los elementos descritos. Por lo tanto, si una modalidad comprende los elementos A, B y C, y una segunda modalidad comprende los elementos B y D, también pueden usarse otras combinaciones restantes de A, B, C o D.
El término "conectado" o "acoplado" puede incluir tanto el acoplamiento directo (en el cual dos elementos que se acoplan entre sí entran en contacto uno con el otro) y el acoplamiento indirecto (en el cual al menos un elemento adicional se localiza entre los dos elementos).
La solución técnica de las modalidades puede adoptar la forma de un producto de software. El producto de software puede almacenarse en un medio de almacenamiento no volátil o no transitorio, que puede ser un disco compacto de memoria de solo lectura (CD-ROM), un disco flash USB o un disco duro extraíble. El producto de software incluye un número de instrucciones que permiten que un dispositivo informático (computadora personal, servidor o dispositivo de red) ejecute los métodos proporcionados por las modalidades.
Las modalidades descritas en la presente descripción se implementan por hardware informático físico, incluidos los dispositivos informáticos, servidores, receptores, transmisores, procesadores, memoria, pantallas y redes. Las modalidades descritas en la presente descripción proporcionan máquinas físicas útiles y disposiciones de hardware de computadora particularmente configuradas. Las modalidades descritas en la presente descripción se dirigen a máquinas electrónicas y métodos implementados por máquinas electrónicas adaptadas para procesar y transformar señales electromagnéticas que representan varios tipos de información. Las modalidades descritas en la presente descripción se relacionan de manera generalizada e integral a las máquinas y sus usos; y las modalidades descritas en la presente descripción no tienen significado ni aplicabilidad práctica fuera de su uso con hardware informático, máquinas y varios componentes de hardware. Sustituir el hardware físico particularmente configurado para implementar varios actos por hardware no físico, mediante el uso de etapas mentales por ejemplo, puede afectar sustancialmente la forma en que funcionan las modalidades. Tales limitaciones de hardware de computadora son claramente elementos esenciales de las modalidades descritas en la presente descripción, y no pueden omitirse ni sustituirse por medios mentales sin tener un efecto material en la operación y estructura de las modalidades descritas en la presente descripción. El hardware de la computadora es esencial para implementar las varias modalidades descritas en la presente descripción y no se usa simplemente para realizar las etapas de manera expedita y eficiente.
Los sistemas informáticos del supervisor 106 pueden implementarse mediante el uso de varios dispositivos informáticos. Los sistemas informáticos del supervisor 106 pueden incluir al menos un procesador, un dispositivo de almacenamiento de datos 110 (que incluye memoria volátil o memoria no volátil u otros elementos de almacenamiento de datos o una combinación de los mismos) y al menos una interfaz de comunicación. Los componentes del dispositivo informático pueden conectarse de varias maneras, incluidos acoplados directamente, acoplados indirectamente a través de una red y distribuidos en un área geográfica amplia y conectados a través de una red (lo que puede denominarse "computación en la nube").
Por ejemplo, y sin limitación, los sistemas informáticos del supervisor pueden ser un servidor, un dispositivo de red, una computadora personal, una computadora portátil, un asistente de datos personales, un teléfono celular, un teléfono inteligente, una terminal de visualización de video, una consola de juegos, un dispositivo de lectura electrónica y un dispositivo hipermedia inalámbrico o cualquier otro dispositivo informático capaz de configurarse para llevar a cabo los métodos descritos en la presente descripción.
La Figura 11 es un diagrama esquemático 1100 a modo de ejemplo de un supervisor, instructor, intermediario y/o sistemas/dispositivos informáticos de destino 106, ilustrativo de una modalidad. Como se representa, los sistemas informáticos del supervisor 106 incluyen al menos un procesador 1102, una memoria 1104, al menos una interfaz de E/S 1106 y al menos una interfaz de red 1108.
Cada procesador 1102 puede ser, por ejemplo, cualquier tipo de microprocesador o microcontrolador de propósito general, un procesador de procesamiento de señal digital (DSP), un circuito integrado, una matriz de puertas programables en campo (FPGa ), un procesador reconfigurable, un procesador de solo lectura programable memoria (PROM), o cualquier combinación de los mismos.
La memoria 1104 puede incluir una combinación adecuada de cualquier tipo de memoria de computadora que se ubique interna o externamente tal como, por ejemplo, memoria de acceso aleatorio (RAM), memoria de solo lectura (ROM), memoria de solo lectura de disco compacto (CDROM ), memoria electro-óptica, memoria magneto-óptica, memoria de solo lectura programable y borrable (EPROM) y memoria de solo lectura programable y borrable eléctricamente (EEPROM), RAM ferroeléctrica (FRa M) o similares.
Cada interfaz de E/S 1106 permite que los sistemas informáticos del supervisor de los dispositivos informáticos 106 se interconecten con uno o más dispositivos de entrada, tal como un teclado, un mouse, una cámara, una pantalla táctil y un micrófono, o con uno o más dispositivos de salida, tal como una pantalla de visualización y un altavoz. Cada interfaz de red 1108 permite que los sistemas informáticos del supervisor de los dispositivos informáticos 106 se comuniquen con otros componentes, intercambien datos con otros componentes, accedan y se conecten a los recursos de red, sirvan aplicaciones y realicen otras aplicaciones informáticas conectándose a una red (o redes múltiples) capaz de transportar datos, incluidos Internet, Ethernet, línea de servicio telefónico antiguo (POTS), red telefónica de conmutación pública (PSTN), red digital de servicios integrados (ISDN), línea de suscriptor digital (DSL), cable coaxial, fibra óptica, satélite, móvil, inalámbrica (por ejemplo, Wi-Fi, WiMAX), red de señalización SS12, línea fija, red de área local, red de área amplia y otras, incluida cualquier combinación de estas.
Aunque las modalidades se han descrito en detalle, debe entenderse que pueden hacer varios cambios, sustituciones y alteraciones en la presente descripción sin apartarse del alcance como se define por las reivindicaciones adjuntas.
Por otra parte, el alcance de la presente solicitud no pretende limitarse a las modalidades particulares del proceso, máquina, fabricación, composición de la materia, medios, métodos y etapas descritas en la memoria descriptiva. Como un experto en la técnica apreciará fácilmente a partir de la descripción de la presente invención, los procesos, las máquinas, la fabricación, las composiciones de la materia, los medios, los métodos o las etapas, actualmente existentes o que se desarrollarán más adelante, que realizan sustancialmente la misma función o lograr sustancialmente el mismo resultado que las modalidades correspondientes descritas en la presente descripción. En consecuencia, las reivindicaciones adjuntas pretenden incluir dentro de su alcance tales procesos, máquinas, fabricación, composiciones de materia, medios, métodos o etapas
Como puede entenderse, los ejemplos descritos e ilustrados anteriormente pretenden ser solo ilustrativos. Las modalidades descritas en la presente descripción no tienen significado ni aplicabilidad práctica fuera de su uso con hardware informático, máquinas y varios componentes de hardware. Sustituir el hardware físico particularmente configurado para implementar varios actos por hardware no físico, mediante el uso de etapas mentales por ejemplo, puede afectar sustancialmente la forma en que funcionan las modalidades. Tales limitaciones de hardware de computadora son claramente elementos esenciales de las modalidades descritas en la presente descripción, y no pueden omitirse ni sustituirse por medios mentales sin tener un efecto material en la operación y estructura de las modalidades descritas en la presente descripción. El hardware de la computadora es esencial para implementar las varias modalidades descritas en la presente descripción y no se usa simplemente para realizar las etapas de manera expedita y eficiente.
Los sistemas informáticos del supervisor 106 pueden implementarse mediante el uso de varios dispositivos informáticos. Los sistemas informáticos del supervisor 106 pueden incluir al menos un procesador, un dispositivo de almacenamiento de datos 110 (que incluye memoria volátil o memoria no volátil u otros elementos de almacenamiento de datos o una combinación de los mismos) y al menos una interfaz de comunicación. Los componentes del dispositivo informático pueden conectarse de varias maneras, incluidos acoplados directamente, acoplados indirectamente a través de una red y distribuidos en un área geográfica amplia y conectados a través de una red (lo que puede denominarse "computación en la nube").
Por ejemplo, y sin limitación, los sistemas informáticos del supervisor pueden ser un servidor, un dispositivo de red, una computadora personal, una computadora portátil, un asistente de datos personales, un teléfono celular, un teléfono inteligente, una terminal de visualización de video, una consola de juegos, un dispositivo de lectura electrónica y un dispositivo hipermedia inalámbrico o cualquier otro dispositivo informático capaz de configurarse para llevar a cabo los métodos descritos en la presente descripción.
La Figura 11 es un diagrama esquemático 1100 a modo de ejemplo de un supervisor, instructor, intermediario y/o sistemas/dispositivos informáticos de destino 106, ilustrativo de una modalidad. Como se representa, los sistemas informáticos del supervisor 106 incluyen al menos un procesador 1102, una memoria 1104, al menos una interfaz de E/S 1106 y al menos una interfaz de red 1108.
Cada procesador 1102 puede ser, por ejemplo, cualquier tipo de microprocesador o microcontrolador de propósito general, un procesador de procesamiento de señal digital (DSP), un circuito integrado, una matriz de puertas programables en campo (FPGa ), un procesador reconfigurable, un procesador de solo lectura programable memoria (PROM), o cualquier combinación de los mismos.
La memoria 1104 puede incluir una combinación adecuada de cualquier tipo de memoria de computadora que se ubique interna o externamente tal como, por ejemplo, memoria de acceso aleatorio (RAM), memoria de solo lectura (ROM), memoria de solo lectura de disco compacto (CDROM ), memoria electro-óptica, memoria magneto-óptica, memoria de solo lectura programable y borrable (EPROM) y memoria de solo lectura programable y borrable eléctricamente (EEPROM), RAM ferroeléctrica (FRa M) o similares.
Cada interfaz de E/S 1106 permite que los sistemas informáticos del supervisor de los dispositivos informáticos 106 se interconecten con uno o más dispositivos de entrada, tal como un teclado, un mouse, una cámara, una pantalla táctil y un micrófono, o con uno o más dispositivos de salida, tal como una pantalla de visualización y un altavoz. Cada interfaz de red 1108 permite que los sistemas informáticos del supervisor de los dispositivos informáticos 106 se comuniquen con otros componentes, intercambien datos con otros componentes, accedan y se conecten a los recursos de red, sirvan aplicaciones y realicen otras aplicaciones informáticas conectándose a una red (o redes múltiples) capaz de transportar datos, incluidos Internet, Ethernet, línea de servicio telefónico antiguo (POTS), red telefónica de conmutación pública (PSTN), red digital de servicios integrados (ISDN), línea de suscriptor digital (DSL), cable coaxial, fibra óptica, satélite, móvil, inalámbrica (por ejemplo, Wi-Fi, WiMAX), red de señalización SS12, línea fija, red de área local, red de área amplia y otras, incluida cualquier combinación de estas.
Aunque las modalidades se han descrito en detalle, debe entenderse que pueden hacer varios cambios, sustituciones y alteraciones en la presente descripción sin apartarse del alcance como se define por las reivindicaciones adjuntas.
Por otra parte, el alcance de la presente solicitud no pretende limitarse a las modalidades particulares del proceso, máquina, fabricación, composición de la materia, medios, métodos y etapas descritas en la memoria descriptiva. Como un experto en la técnica apreciará fácilmente a partir de la descripción de la presente invención, los procesos, las máquinas, la fabricación, las composiciones de la materia, los medios, los métodos o las etapas, actualmente existentes o que se desarrollarán más adelante, que realizan sustancialmente la misma función o lograr sustancialmente el mismo resultado que las modalidades correspondientes descritas en la presente descripción. En consecuencia, las reivindicaciones adjuntas pretenden incluir dentro de su alcance tales procesos, máquinas, fabricación, composiciones de materia, medios, métodos o etapas
Como puede entenderse, los ejemplos descritos e ilustrados anteriormente pretenden ser solo ilustrativos.

Claims (9)

REIVINDICACIONES
1. Un método para la gestión de los procesos de datos en una red de recursos informáticos, el método que comprende:
recibir, en un dispositivo informático (106), al menos una solicitud secundaria generada para una solicitud principal enviada desde un dispositivo del instructor (102), la solicitud secundaria que se enruta desde un dispositivo intermediario (104), a al menos un dispositivo de destino correspondiente ( 108a ... 108n), la al menos una solicitud secundaria solicita la ejecución de al menos un proceso de datos secundario correspondiente, cada uno de los al menos un proceso de datos secundario para ejecutar al menos una porción del al menos un proceso de datos principal del dispositivo del instructor, y cada una de las al menos una solicitud secundaria que incluye una clave de destino derivada al menos en parte de al menos una clave de instructor, la clave de destino que se asocia con la solicitud secundaria;
almacenar, por el dispositivo informático (106), la al menos una solicitud secundaria en al menos un dispositivo de almacenamiento (110);
modificar, por el dispositivo informático (106), la al menos una solicitud secundaria tras recibir una señal de modificación de la solicitud secundaria; y
generar las señales para la comunicación de las solicitudes secundarias a uno o más dispositivos solicitantes; en donde la señal de modificación de la solicitud secundaria incluye un mensaje de máscara, y la modificación de al menos una solicitud secundaria comprende el enmascaramiento de al menos un campo de al menos una solicitud secundaria, el al menos un campo que se identifica por el mensaje de máscara; y en donde el enmascaramiento de el al menos un campo comprende: cifrar el al menos un campo de la al menos una solicitud secundaria con una clave secundaria asociada con el dispositivo intermediario.
2. El método de acuerdo con la reivindicación 1 que comprende cifrar la al menos una solicitud secundaria modificada con su correspondiente clave de destino antes de generar las señales para comunicar las solicitudes secundarias.
3. El método de acuerdo con la reivindicación 2, en donde un dispositivo solicitante particular que tiene al menos una clave de destino particular puede decodificar la solicitud secundaria cifrada correspondiente para identificar el al menos un proceso de datos secundario enrutado para ejecutar al menos un proceso de datos principal particular asociado con la clave de destino particular.
4. El método de una cualquiera de acuerdo con las reivindicaciones 1 a 3, en donde modificar al menos una solicitud secundaria comprende ocultar al menos un campo de al menos una solicitud secundaria.
5. El método de acuerdo con la reivindicación 1 que comprende: cifrar la al menos una solicitud secundaria modificada que incluye el al menos un campo enmascarado con su correspondiente clave de destino antes de generar las señales para la comunicación de las solicitudes secundarias.
6. El método de una cualquiera de acuerdo con las reivindicaciones 1 a 5 que comprende recibir desde un dispositivo solicitante al menos una de: una clave de instructor, una clave de intermediario, una clave de destino y una clave de índice; y generar las señales para la comunicación de las solicitudes secundarias asociadas con la al menos una de: la clave de instructor, la clave de intermediario, la clave de destino y la clave de índice para el dispositivo solicitante.
7. El método de una cualquiera de acuerdo con las reivindicaciones 1 a 6, en donde al menos un proceso de datos principal representa al menos una solicitud para una operación en un interés financiero.
8. Un medio legible por computadora no transitorio para la gestión de los procesos de datos en una red de recursos informáticos, el medio legible por computadora no transitorio que incluye instrucciones interpretables por máquina, que cuando se ejecutan, provocan que al menos un procesador realice el método de una cualquiera de acuerdo con las reivindicaciones 1 a 7.
9. Un sistema que comprende al menos un dispositivo de almacenamiento y al menos un procesador configurado para realizar el método de una cualquiera de acuerdo con las reivindicaciones 1 a 7.
ES17175939T 2016-06-14 2017-06-14 Verificación de procesos de datos en una red de recursos informáticos Active ES2917200T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201662349880P 2016-06-14 2016-06-14

Publications (1)

Publication Number Publication Date
ES2917200T3 true ES2917200T3 (es) 2022-07-07

Family

ID=59077854

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17175939T Active ES2917200T3 (es) 2016-06-14 2017-06-14 Verificación de procesos de datos en una red de recursos informáticos

Country Status (3)

Country Link
EP (2) EP3260979B1 (es)
CA (1) CA2970686A1 (es)
ES (1) ES2917200T3 (es)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3160095A1 (en) 2012-09-12 2014-03-20 Iex Group, Inc. System, apparatuses, and methods for managing orders with minimum quantity instructions in electronic trading systems
JP6542800B2 (ja) 2014-04-16 2019-07-10 アイイーエックス グループ，インコーポレーテッド トランザクションの最新情報を提供するシステム及び方法
WO2016028416A1 (en) 2014-08-22 2016-02-25 Iex Group, Inc. Dynamic peg orders in an electronic trading system
US10706470B2 (en) 2016-12-02 2020-07-07 Iex Group, Inc. Systems and methods for processing full or partially displayed dynamic peg orders in an electronic trading system
US10311515B2 (en) 2014-09-17 2019-06-04 Iex Group, Inc. System and method for a semi-lit market
WO2018044334A1 (en) 2016-09-02 2018-03-08 Iex Group. Inc. System and method for creating time-accurate event streams
CN108510254B (zh) * 2018-02-09 2020-11-20 北京欧链科技有限公司 链式双向区块链结构、数据处理方法和装置
CN110475372B (zh) * 2018-05-10 2021-09-24 维沃移动通信有限公司 一种上行传输方法及终端
CN110224811B (zh) * 2019-05-13 2022-05-06 中国联合网络通信集团有限公司 物联网加密处理方法、装置及***
CN112269797B (zh) * 2020-10-28 2024-02-27 国家卫星气象中心(国家空间天气监测预警中心) 一种卫星遥感数据在异构计算平台上的多维查询方法
US11537455B2 (en) 2021-01-11 2022-12-27 Iex Group, Inc. Schema management using an event stream
CN114780595B (zh) * 2022-05-09 2023-08-15 马上消费金融股份有限公司 核验方法、装置及***

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5479514A (en) * 1994-02-23 1995-12-26 International Business Machines Corporation Method and apparatus for encrypted communication in data networks
US5649103A (en) * 1995-07-13 1997-07-15 Cabletron Systems, Inc. Method and apparatus for managing multiple server requests and collating reponses
US20020128871A1 (en) * 2000-12-07 2002-09-12 Dan Adamson Method, apparatus, and system for aggregating, targeting, and synchronizing health information delivery
US7634726B2 (en) * 2001-01-05 2009-12-15 International Business Machines Corporation Technique for automated e-business services
EP1510951A1 (en) * 2003-08-27 2005-03-02 Sap Ag A data processing method, system and computer program

Also Published As

Publication number Publication date
CA2970686A1 (en) 2017-12-14
EP4083798A1 (en) 2022-11-02
EP3260979A1 (en) 2017-12-27
EP3260979B1 (en) 2022-03-09

Similar Documents

Publication Publication Date Title
ES2917200T3 (es) Verificación de procesos de datos en una red de recursos informáticos
ES2957843T3 (es) Verificación de procesos de datos en una red de recursos informáticos
US11477135B2 (en) Verification of data processes in a network of computing resources
US11038679B2 (en) Secure multi-party computation method and apparatus, and electronic device
US9614814B2 (en) System and method for cascading token generation and data de-identification
ES2620962T3 (es) Sistemas y procedimientos para asegurar datos en movimiento
WO2019007396A1 (zh) 基于智能合约进行加密交易的方法和装置以及区块链
US20160358264A1 (en) Equity income index construction transformation system, method and computer program product
US11741247B2 (en) Smart privacy and controlled exposure on blockchains
CN111339201B (zh) 基于区块链的测评方法及***
CN111476573A (zh) 一种账户数据处理方法、装置、设备及存储介质
US20220191034A1 (en) Technologies for trust protocol with immutable chain storage and invocation tracking
US20240259328A1 (en) Verification of data processes in a network of computing resources
JP2023505686A (ja) パートナーの匿名化
Johansson Assessing blockchain technology for transport data logger
Keerthana et al. Slicing, Tokenization, and Encryption Based Combinational Approach to Protect Data-at-Rest in Cloud Using TF-Sec Model
Rekha et al. A holistic blockchain based IC traceability technique
Zhang et al. Decentralized and secure deduplication with dynamic ownership in MLaaS
JOHANSSON et al. Using Blockchain Techniques to Create an Opinion-Based Whitelisting Procedure
Alm Nilsson et al. Using Blockchain Techniques to Create an Opinion-Based Whitelisting Procedure
Kumar et al. Using Blockchain in IoT for Pharmaceutical Drug Supply
Rudd A Low-Energy Security Solution for IoT-Based Smart Farms
Wilbert et al. “Meta Cloud Discovery” Model: An Approach to Integrity Monitoring for Cloud-Based Disaster Recovery Planning