MX2011007255A - Sistemas y metodos para establecer confianza entre entidades como apoyo a transacciones. - Google Patents

Sistemas y metodos para establecer confianza entre entidades como apoyo a transacciones.

Info

Publication number
MX2011007255A
MX2011007255A MX2011007255A MX2011007255A MX2011007255A MX 2011007255 A MX2011007255 A MX 2011007255A MX 2011007255 A MX2011007255 A MX 2011007255A MX 2011007255 A MX2011007255 A MX 2011007255A MX 2011007255 A MX2011007255 A MX 2011007255A
Authority
MX
Mexico
Prior art keywords
affiliate
information
grantor
rule
database
Prior art date
Application number
MX2011007255A
Other languages
English (en)
Inventor
James S Byrne
Cristopher W Middleton
Darrell S Geusz
Robert H Hux
Dawn M Orr
Original Assignee
James S Byrne
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 James S Byrne filed Critical James S Byrne
Publication of MX2011007255A publication Critical patent/MX2011007255A/es

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Los sistemas y métodos para determinar la identidad de afiliados quienes cumplan con los requisitos de confianza de un otorgante de privilegios incluye un sistema de administración de confianza e identificación incluyendo al menos un dispositivo de informática en comunicación con al menos un afiliado, al menos un otorgante de privilegios, y al menos una fuente autorizada. Se recibe al menos una regla de al menos un otorgante de privilegios que debe ser cumplida para que el otorgante de privilegio confíe en un afiliado; Se estableció una base de datos de al menos un afiliado con información acerca del afiliado; La fuente autorizada se consulta para determinar si al menos una porción de la informaron sobre el afiliado es correcta Se recibe una respuesta de la fuente autorizada de si la porción de información es correcta o no, La base de datos almacena un resultado de la consulta sin almacenar datos subyacentes al resultado; La información almacenada en la base de datos se compara con al menos una regla para determinar si el afiliado cumple con la regla se notifica al otorgante de privilegios si el afiliado cumple o no la regla basado en la comparación, sin suministrar al otorgante de privilegios datos del afiliado almacenados en la base de datos o los datos subyacentes al resultado.

Description

SISTEMAS Y MÉTODOS PARA ESTABLECER CONFIANZA ENTRE ENTIDADES COMO APOYO A TRANSACCIONES.
CAMPO La divulgación está dirigida a los sistemas 20 y métodos para establecer relaciones de confianza entre varias entidades y, más en particular, a los sistemas 20 y métodos para el establecimiento de comunidades, por los cuales, las entidades que requieran privilegios, pueden exponer sus características a las entidades que puedan otorgarles privilegios.
BREVE DESCRIPCIÓN DE LAS FIGURAS La Fig. 1 es un diagrama de bloques de una red 100 de identidad y de administración de la confianza de acuerdo a una declaración divulgada.
La Fig. 2 es un diagrama de esquemático de una red 200 de identidad y de la administración de la confianza de acuerdo a una declaración divulgada.
La Fig. 3 es un cuadro de flujo de un método 300 de identidad y de la administración de la confianza de acuerdo a una declaración divulgada.
DESCRIPCIÓN DETALLADA La Fig. 1 representa una red 100 de administración de la identidad y la confianza establecido por un acuerdo. La red 100 incluye uno o más afiliados 10 que están en comunicación con el sistema administrativo 20 de la identidad y de la confianza. El sistema administrativo 20 de la identidad y la confianza puede también estar en comunicación con uno o más otorgantes de privilegios 30 y una o más fuentes autorizadas 40.
A un nivel alto, un afiliado 10 puede suministrar información (e.g. características) acerca de si mismo al sistema 20. Esta información puede incluir datos personales [e.g. datos biográficos (nombres, fecha de nacimiento, contactos) ) identificación personal, (e.g. los datos de la licencia de conducir, del documento de identidad) , los datos profesionales, (e.g. los datos de la profesión, los certificados o títulos), fecha de vinculación (e.g., el empleador), y cualesquier otro dato que el afiliado 10 considere relevante, compartir con el sistema 20 con propósitos de establecer una relación de confianza con otorgantes de privilegios 30. Adicionalmente, el otorgante del privilegio 30 le puede suministrar al sistema 20 una o más reglas, que los afiliados 10 al cumplir, permiten el establecimiento de la relación de confianza entre los afiliados 10 y los otorgantes del privilegio 30.
En una declaración, la regla o las reglas establecidas por el otorgante del privilegio 30 en el sistema 20 puede ser un conjunto de criterios requeridos para posibilitar el establecimiento de una relación de confianza entre los afiliados 10 y los otorgantes del privilegio 30. Más aun, la confianza puede ser aprobada basada en la habilidad de los afiliados 10 para exponer la información suficiente que le permita al otorgante del privilegio 30, otorgar un permiso o un privilegio 10. Por ejemplo, en una declaración basada en una relación de confianza formada entre afiliados 10 y otorgantes de privilegios 30, el otorgante del privilegio 30 puede pre-aprobar (o subsiguientemente aprobarse en una fecha posterior) afiliados 10 para otorgarles ciertos privilegios en particular. Un privilegio puede ser el permiso para entrar a predios particulares en un momento en particular para suministrar uno o más servicios.
El sistema 20 puede determinar si lo afiliados 10 cumplen con una o más de las reglas establecidas por el otorgante del privilegio 30 por medio de evaluar la información suministrada por el afiliado 10 con respecto a las reglas suministradas por el otorgante del privilegio 30. Adicionalmente , el sistema 20 puede consultar con fuentes autorizadas 40 para determinar si la información suministrada por el afiliado 10 es válida y correcta. El sistema 20 puede recibir una respuesta de acuerdo a la fuente autorizada 40 y almacenar un resultado de la investigación, al igual que ningún resultado o algunos de ellos, o todos los datos subyacentes del resultado. El sistema 20 puede entonces comparar el resultado almacenado con la regla suministrada por el otorgante de privilegios 30 para determinar si el afiliado 10 satisface la regla. Basado en esta comparación, el sistema 20 puede notificar al otorgante del privilegio 30 y/o afiliado 10, si el afiliado 10 ha cumplido la regla y, por lo tanto, si una relación de confianza se puede formar entre el afiliado 10 y el otorgante del privilegio 30. El sistema 20 puede proveer dicha información al otorgante del privilegio 30 sin suministrar información acerca del afiliado 10 almacenada en el sistema 20, sin suministrar información recibida proveniente de la fuente autorizada 40, o los datos subyacentes de comparación al otorgante del privilegio 30.
En una declaración, los afiliados 10 pueden ser personas quienes puedan querer establecer un relación de confianza con el otorgante del privilegio 30. El afiliado 10 puede ser, por ejemplo, un oficial de la policía, un técnico médico de emergencias, un trabajador de una plataforma petrolera, un trabajador de Hazmat [materiales peligrosos] , un médico, una enfermera, o cualquier otra persona que quiera establecer una relación de confianza con un otorgante de privilegio 30, con el propósito de habilitar algún permiso o privilegio. Con este propósito, el afiliado 10 puede suministrar información al sistema 20. Esta información puede incluir datos personales (e.g., datos biográficos (nombre, fecha de nacimiento, contacto)) identificación personal, (e.g., los datos de la licencia de conducir, del documento de identificación) , información de la profesión u oficio (e.g., técnico médico en emergencias, Certificado por la Cruz Roja para Primeros Auxilios, operador Hazmat certificado) ; las organizaciones con las cuales podría estar asociado, (e.g., el Departamento de Policía de la ciudad de Alexandria, el Hospital INOVA Fairfax) , un hospital gue podría almacenar su información médica, bancos que podrían procesar su información financiera, o cualquier otra información que podría ayudar a establecer una relación de confianza entre un afiliado 10 y un otorgante de privilegio.
La información suministrada por el afiliado 10 al sistema 20 puede ser de varias clases, contra la cual el afiliado 10 puede permitir al sistema 20 consultar una fuente autorizada 40. Estas clases de información pueden incluir, por ejemplo, datos biográficos acerca del afiliado 10 (e.g., nombres, fecha de nacimiento, contacto) ; información del documento de identificación, acerca del afiliado 10, (e.g., datos de la licencia de conducir, del documento de identidad) , información de la capacidad acerca del afiliado 10, (e.g., agente de la ley, proveedor de servicios médicos, bombero, banquero, abogado) ; información médica acerca del afiliado 10, (e.g., tipo de sangre, secuencia del ADN) ; información de antecedentes financieros, acerca del afiliado 10, (e.g., información bancaria, información del puntaje de créditos); o cualquier otra clase de información que el afiliado 10, el sistema 20, el otorgante de privilegio 30, o cualquier combinación de ellos.
Alternativamente, el afiliado 10 puede definir las diferentes clases de información a través de los datos suministradas. Estas diferentes clases o grupos de información relativas al afiliado 10 pueden ser referidas a diferentes identidades del afiliado 10. En una declaración, cada identidad del afiliado 10 puede representar una capacidad separada de afiliado 10 o una recolección relevante a un privilegio especifico que sea suministrado por el otorgante del privilegio 30. Por ejemplo, información relacionada con el rol del afiliado 10 como persona que responde a una emergencia puede incluir información de la credencial de la identificación reconocida en escenarios de emergencia más las capacidades, las habilidades profesionales, y la membrecia a una organización reconocida, y potencialmente requerida en situaciones de emergencia. Adicionalmente, la información relacionada a las capacidades financieras, (e.g., información de la cuenta del banco) , que aunque insertada por el afiliado 10 en el sistema 20, no se incluirla en la identidad como si esta no se requiriera por lo(s) role(s) (e.g., permisos /privilegios), buscados, o que se desean compartir con los otorgantes de privilegios 30.
En una declaración, el sistema 20 puede permitirle a un afiliado 10 controlar que clases o recolecciones de información pueden ser asequibles por el otorgante del privilegio 30, por consiguiente garantizando que los otorgantes del privilegio 30 tengan acceso a la información adecuada al evaluar una relación de confianza con un afiliado 10 con base a la necesidad de saber. Por ejemplo, el afiliado 10 puede ser un técnico médico de emergencias de Arlington Virginia, quien desea establecer una relación de confianza con el otorgante de privilegios 30, el cual es el departamento del Sheriff de Nueva Orleáns para estar en la lista de emergencia de los que responden a los desastres en Nueva Orleáns. En este caso, el afiliado 10 puede suministrar instrucciones al sistema 20 para evaluar solamente el personal y la información profesional suministrada por el afiliado 10 contra una o más reglas establecidas por el otorgante del privilegio 30. Adicionalmente, el afiliado 10 puede también darle instrucciones al sistema 20 para solo compartir información personal y profesional concerniente al afiliado 10 con el otorgante del privilegio 30, si las reglas establecidas por otorgante del privilegio 30 asi lo requieren y si el afiliado 10 consiente a compartir dicha información. Esto es, debido a que el afiliado 10 no quiere que el otorgante del privilegio 30 tenga acceso a otra información acerca del afiliado 10 (e.g., información de antecedentes financieros, información de antecedentes médicos), el sistema 20 no puede utilizar dicha información al formar una relación de confianza entre el afiliado 10 y el otorgante del privilegio 30 y no puede tampoco compartir dicha información con el otorgante del privilegio 30.
Por otra parte, el mismo afiliado 10 (i.e., el técnico médico de emergencias de Arlington, Virginia) , puede querer formar una relación de confianza con el otorgante de privilegios 30 para un propósito diferente; en este caso aplicar por un trabajo con el departamento del Sheriff de Nueva Orleáns. En este caso, el afiliado 10 puede dar instrucciones al sistema 20 para compartir información de antecedentes financieros y médicos adicionales a la información profesional y personal del afiliado 10.
Este puede ser el caso debido a que la regla o el conjunto de reglas establecidos por el otorgante del privilegio 30 para el empleo pueda requerir la verificación de dicha información como parte del criterio de selección para el empleo. El afiliado 10 puede encontrar tal requisito razonable y por lo tanto, puede dar instrucciones al sistema 20 para utilizar dicha información al formar una relación de confianza con el otorgante del privilegio 30. Asi, el afiliado 10 puede suministrar múltiples clases o recolecciones de información al sistema 20 a fin de responder a las múltiples necesidades de confianza. Mientras que la declaración discutió las características antes mencionadas, las múltiples necesidades de confianza, entre el afiliado 10 y el mismo otorgante del privilegio 30, en el cual apreciará que el afiliado 10 puede tener necesidades múltiples de confianza con múltiples otorgantes de privilegio 30 que puedan ser llevadas a cabo por el sistema 20 sin apartarse del alcance de esta divulgación .
El afiliado 10 se puede comunicar con el sistema 20 utilizando técnicas de conexión múltiples. Por ejemplo, en una declaración, el afiliado 10 se puede comunicar con el sistema 20 utilizando una red de comunicación de datos. La red de comunicación puede ser una red pública tal como el Internet. Adicionalmente, el afiliado 10 se puede comunicar con el sistema 20 por Internet a través de un navegador que tenga acceso a un portal de Internet suministrándole acceso al sistema 20 y/o a un cliente específico entre el afiliado 10 y el sistema 20. El afiliado 10, bien sea comunicándose con el sistema 20, directamente, con el navegador o como parte de una aplicación del cliente, puede comunicarse con una conexión autorizada segura. La comunicación se puede asegurar con el SSL [Secure Socket Layer- Capa de Dispositivo de Seguridad] .
Adicionalmente o alternativamente, el afiliado 10 puede comunicarse con el sistema 20 a través de una red telefónica, como por ejemplo, la red telefónica pública conmutada (PTSN) o una red celular, o cualquier combinación de estos. El afiliado 10 se puede comunicar con el sistema 20 utilizando acceso de datos a lo ancho de redes telefónicas transmitiendo la información (enviar/recibir) via protocolos SMS/MMS. El afiliado 10 también puede comunicarse a través de mecanismos de acceso via voz que permitan al afiliado 10 suministrar información (enviar/recibir) con sistemas 20 de reconocimiento de vos automatizados (IVR) al igual que con el personal humano de soporte al cliente. En particular, el afiliado 10 puede proveer su información a un representante, el cual introduce al sistema 20 la información suministrada por afiliado 10.
El Sistema 20 de Manejo de Identidad y Confianza puede incluir uno o más dispositivos de cómputo configurados para suministrar las características discutidas en la presente divulgación. Los dispositivos de cómputo pueden incluir portátiles, estaciones de trabajo, servidores, dispositivos de cómputo manuales, teléfonos móviles y cualesquier otro dispositivo capacitado para realizar las características discutidas en la presente divulgación. Específicamente todas las características discutidas en la presente divulgación se pueden suministrar en un dispositivo de cómputo o en múltiples dispositivos que pueden estar interconectados entre sí a través de una Red de Área Local [LAN] , una Red de Área Metropolitana [MAN] , una Red de Área Amplia [WAN] y/o una Red de teléfono Celular y Datos.
En una declaración, el Sistema 20 de Manejo de Identidad y Confianza puede incluir componentes para que reciban información de un afiliado 10. Como se discutió anteriormente, esta información puede ser recibida a través de una red telefónica o una red de comunicación de datos como por ejemplo, el Internet. Con este fin, un sistema 20 de dispositivo de cómputo puede incluir un puerto de comunicación de datos tal como un puerto de fibra óptica, puerto coaxial, puerto de Cat5, o cualesquier otro puerto que pueda conectar el dispositivo de cómputo a los datos de la red de comunicación. Los afiliados 10 pueden también conectarse al sistema 20 a través de Reconocimiento de Voz Interactivo (IVR) que le permita al afiliado 10 recibir/suministrar la información dentro del sistema 20.
El sistema 20 puede incluir base de datos 22, motores de consulta 24, y motores de comparación 26. Generalmente, la información recibida de los afiliados 10, las reglas recibidas de los otorgantes de privilegios 30 y los resultados obtenidos de las fuentes autorizadas 40 de consulta se pueden almacenar en bases de datos 22. Los motores de consulta 24 pueden interrogar fuentes autorizadas 40 para determinar si la información concerniente al afiliado 10, o si hay múltiples afiliados 10, es correcta. El sistema 20 puede almacenar los resultados de las interrogaciones en la base de datos 22 sin almacenar ninguno de los datos subyacentes al resultado de la consulta. Adicionalmente, el motor de comparación 26 puede comparar los resultados en la base de datos 22 con una regla suministrada por el otorgante de privilegios 30para determinar si algún afiliado 10 satisface la regla. El Sistema 20 puede entonces notificar al otorgante del privilegio 30 si el afiliado 10 ha cumplido o no con la regla. El Sistema 20 puede entonces notificar también al afiliado 10 si ha cumplido o no con la regla y si no, cual información hace falta y se requiere. El Sistema 20 puede hacerlo sin suministrar datos almacenados en la base 22 de datos del afiliado 10 o datos subyacentes al resultado de la búsqueda realizada por el motor de búsqueda 24.
Específicamente, el sistema 20 puede recibir información del afiliado 10 y almacenar esta información en la base de datos 22. La base de datos 22, puede ser de cualquier tipo de base de datos comercialmente disponible que pueda almacenar información del afiliado 10. Esta puede incluir, por ejemplo, Oracle, MySQL o Sybase o una serie de sistema 20s y protocolos de almacenamiento de datos basado en archivos utilizados para soportar comunicaciones, aplicaciones e interacciones basadas en Web, tales como XML, XQL, RDF, y SPARQL. En una declaración, la información recibida puede ser agrupada en uno o más identidades para cada afiliado 10. Según lo anteriormente discutido, estas identidades pueden incluir, por ejemplo una identidad personal, una identidad profesional, una identidad médica, y una identidad financiera. Además, en una declaración, cierta información en una identidad del afiliado 10, puede ser incluida en una o más identidades del afiliado 10. Por ejemplo, la identidad personal de un abogado puede incluir el hecho de que el abogado también esté certificado para CPR, [Resucitación Cardio-Pulmonar ] . Mientras esta información puede ser parte de la identidad personal del abogado, también puede ser parte de su identidad profesional, porque puede ser relevante para un otorgante de privilegios 30 con el departamento del sheriff que puede necesitar que se le suministre acceso al personal certificado en CPR en el caso de un desastre.
En una declaración, el otorgante del privilegio 30 puede estar agrupado en las recolecciones de comunidades. Las comunidades representan un conjunto de otorgantes de privilegios comunes y potencialmente relacionados, quienes suministran privilegios similares o comunes a afiliados 10 a través de las mismas o diferentes áreas o geografías de privilegios. Las comunidades permiten a los afiliados 10 definir y seleccionar la información para habilitar relaciones confiables con un grupo de otorgantes de privilegio 30.
En una declaración, la base de datos 22 también puede almacenar reglas recibidas de un otorgante de privilegios 30. Un Otorgante de privilegios 30 puede ser una agencia federal, una agencia estatal, una agencia local (condado, ciudad, o pueblo) , o una entidad privada, o una combinación de estas que puedan tener la necesidad de suministrar acceso restringido a ciertas instalaciones o áreas manejadas por la agencia o la entidad. Algunos ejemplos de agencias federales incluyen la Junta de Seguridad de Transporte Nacional (NTSB) , la Agencia Federal de Administración de Emergencias (FEMA) , la Oficina de Investigación Federal (FBI), y otras agencias. Algunos ejemplos de agencias estatales incluyen, la policía estatal, juntas estatales de administración de emergencias, y otras agencias. Algunos ejemplos de agencias locales incluyen, la policía estatal (oficina del sheriff) la policía de la ciudad, la policía del pueblo y otras agencias. Algunos ejemplos de entidades privadas pueden incluir bancos, compañías comerciales, compañías de fabricación, firmas consultoras, firmas legales, · compañías de servicios públicos, compañías de petróleo y gas natural y cualquier otra entidad privada que pueda querer suministrar acceso restringido a sus predios.
El otorgante de privilegios 30 se puede comunicar con el sistema 20 utilizando técnicas de conexión similares a aquellas discutidas anteriormente con respecto a la comunicación entre el afiliado 10 y el sistema 20, y por lo tanto, una discusión repetitiva no se suministra aquí. Como parte de esta comunicación, el otorgante de privilegios 30 puede suministrar un sistema 20 con una o más reglas que necesite para que las cumpla un afiliado 10 para que se forme una relación de confianza entre el afiliado 10 y el otorgante de privilegios 30. En un escenario de muestra, un otorgante de privilegio 30 puede ser el Departamento del Sheriff de Nueva Orleans. El Departamento del Sheriff puede suministrar una regla para que un afiliado 10 esté en capacidad de formar una relación de confianza con el Departamento del Sheriff, el afiliado 10 necesita tener un historial como policía y debe estar domiciliado en el estado de Luisiana. Si hay más de una regla suministrada por el mismo otorgante de privilegio 30, puede haber una estructura como tal, por ejemplo, una jerarquía lógica entre la pluralidad de las reglas suministradas por el otorgante de privilegios 30. Por ejemplo, asumiendo que la regla anteriormente discutida es la primera regla, el Departamento del Sheriff de la ciudad de Nueva Orleans puede agregar una segunda regla al sistema 20 la cual requiere que para formar una relación confiable con él, el afiliado 10 necesita tener historial como policía, pero no solamente estar domiciliados en el estado de Luisiana sino de residir actualmente en la ciudad de Nueva Orleáns. Una tercera regla puede requerir que el afiliado 10 no solo cumpla los requisitos de la segunda regla si no que también el afiliado 10 debe ser un técnico médico certificado ("CMT") . De esta manera, según lo anteriormente discutido, hay una relación lógica entre cada una de las tres reglas, donde, un afiliado 10 quien cumple a cabalidad una tercera regla necesariamente cumple a cabalidad la primera y la segunda, pero un afiliado 10 quien cumple a cabalidad la primera regla puede no cumplir a cabalidad la segunda y la tercera. Es importante tener en cuenta que mientras la divulgación anterior discute tres reglas que comparten una relación entre sí, el otorgante de privilegios 30 puede proveer cualquier número de reglas del sistema 20, todas de las cuales pueden o no compartir una estructura entre sí, sin apartarse del alcance de esta divulgación.
[0024] Adicionalmente, o en otra declaración, el otorgante del privilegios 30 puede establecer reglas que también pueden tener una hora o componentes de fecha. Por ejemplo, mientras el otorgante de privilegios 30 puede haber suministrado al sistema 20 las tres reglas mencionadas anteriormente, el otorgante de privilegios 30 puede activar únicamente la tercera regla en la momentos posteriores a un desastre para que solo las personas que ejerzan funciones policiales que residan en el área de New Orleans y que sean CMT puedan ser autorizados para tener acceso al área de desastre. A medida que la necesidad de ayuda se incremente y la situación se convierta de un esfuerzo de rescate a una perspectiva de la ley y el orden, el otorgante de privilegios 30 puede activar la primera o la segunda regla y desactivar la tercera regla para permitir a más personal policial que hace cumplir la ley a estar autorizado a ingresar en el área de desastre. Adicionalmente , después de que la situación pueda estar bajo control desde una perspectiva de la ley y el orden, el otorgante de privilegios 30 puede activar otras reglas que puedan autorizar más individuos que puedan ayudar, como por ejemplo, doctores con entrenamiento especial, abogados, agentes de seguros, etc., a ingresar en la región de desastre para ayudar con la situación.
Adicionalmente, o en otra declaración, el otorgante del privilegios 30 puede definir condiciones entre las reglas que puedan incluir funciones Y, O, DE OTRA MANERA, que apoyen los criterios de evaluación complejos. Por ejemplo, mientras el otorgante de privilegios 30 ha definido reglas asociadas con la habilitación de acceso del afiliado 10 al Departamento del Sheriff, el otorgante de privilegios 30 puede definir condiciones dentro y a lo largo de las reglas para definir información y criterios necesarios para una evaluación exitosa.
Adicionalmente, o en otra declaración, el otorgante del privilegios 30 puede definir reglas asociadas con ubicación geográfica de afiliado 10, organizaciones de afiliado 10, u otros datos. Por ejemplo, si el otorgante de privilegios 30 quería definir una regla que únicamente evalúe al afiliado 10, cuando la dirección del afiliado 10 estaba dentro, o fuera de una ubicación geográfica específica, entonces el sistema 20 utilizaría la información suministrada del afiliado 10 en la comparación.
En una declaración, el otorgante de privilegios 30 puede activar (o desactivar) reglas sobre una interfaz de comunicación como tal. Por ejemplo, un navegador o una interfaz de administración de clientes si la comunicación entre el otorgante de privilegios 30 y el sistema 20 está sobre una red de comunicación de datos como el Internet. Alternativamente, la activación/desactivación de una regla puede ocurrir sobre una red de teléfonos según lo anteriormente discutido. Es importante tener en cuenta que los escenarios antes discutidos son para propósitos de ejemplo únicamente y que cualquier número y tipos de reglas pueden ser suministrados y activados a diferentes horas dependiendo de la necesidad del otorgante de privilegios 30, sin apartarse del alcance de esta divulgación.
Al momento del recibo de la información del afiliado 10, el motor de consulta 24 en el sistema 20 puede buscar fuentes autorizadas 40 para validar la información suministrada por el afiliado 10. El sistema 20 puede estar en comunicación con múltiples fuentes autorizadas 40. El tipo de fuentes autorizadas 40 interrogadas por el motor de consulta 24 puede depender del tipo de información del afiliado 10 que necesite ser validada. En una declaración, si la información de identificación de la credencial del afiliado 10 necesita ser validada, entonces el motor de búsqueda 24 puede hacer una búsqueda en la base de datos del Departamento de Vehículos Automotores ("DMV") relevante al afiliado 10, el cual es una fuente autorizada 40 de información personal. Por ejemplo, si el afiliado 10 es un residente de Nueva Orleans y provee información personal pertinente al (e.g., nombre, dirección, altura, etc.), entonces el motor de búsqueda 24 puede buscar en una base de datos del DMV de Luisiana. Alternativamente, si el afiliado 10 sostiene que es un médico con una especialización en radiología, entonces el motor de búsqueda 24 puede hacer una búsqueda en una base de datos de la Junta Americana de Radiología para determinar si el afiliado 10 está certificado por la Junta. En este caso, la base de datos mantenida por la Junta Americana de Radiología es una fuente autorizada 40 para este tipo de información en especialización médica.
En otro ejemplo, si el afiliado 10 asegura que tiene depósitos en el Banco Wachovia, N.A., entonces el motor de búsqueda 24 puede hacer una búsqueda en una base de datos de Wachovia Bank para determinar si el afiliado 10 efectivamente tiene cuentas con el Wachovia Bank. Adicionalmente, el motor de búsqueda también puede buscar en bases de datos de agencias de informe de crédito, como por ejemplo, Transunion, Experian, o Equifax. En otro ejemplo, si el afiliado 10 asegura que un hospital particular tiene su información médica, entonces el motor de búsqueda 24 puede hacer una búsqueda en una base de datos de ese hospital en particular para determinar si efectivamente tiene información médica perteneciente al afiliado 10. En otro ejemplo, si el afiliado 10 asegura que es un oficial de la policía del Condado Arlington, Virginia, entonces el motor de búsqueda 24 puede hacer una búsqueda en una base de datos del departamento de policía del Condado de Arlington en Virginia para determinar si el afiliado 10 es efectivamente un oficial de policía en el Condado de Arlington, Virginia. En todos estos ejemplos, cada base de datos constituye una fuente autorizada 40. Es importante tener en cuenta que las bases de datos anteriormente discutidas como fuentes autorizadas 40 son únicamente para propósitos de ejemplo. También se pueden realizar búsquedas en otras fuentes de información para validar información suministrada por el afiliado 10 y determinar si, basados en la información validada, el afiliado 10 cumple cabalmente con la regla establecida por el otorgante de privilegios 30.
La consulta entre el motor de consulta 24 del sistema 20 y la fuente autorizada 40 puede ocurrir en una comunicación establecida entre el sistema 30 y la fuente autorizada 40. En una declaración, el sistema 30 puede comunicarse con la fuente autorizada 40 sobre una red de comunicación de datos como tal, por ejemplo, el Internet. Adicionalmente , la comunicación entre el sistema 30 y la fuente autorizada 40 puede ser segura y confidencial. Con este fin, el sistema 30 y la fuente autorizada 40 pueden comunicarse sobre una Red Virtual Privada (VPN) , o puede utilizar tecnologías de encriptación como por ejemplo, AES-256, SSL-128, 3DES, o Two Fish.
En una declaración, el motor de consulta 24 puede buscar en una fuente autorizada 40 utilizando una estructura de consulta como por ejemplo, lenguaje de consulta estructurada (SQL) y/o Lenguaje de Definición de Servicio Web. El papel del motor de consulta 24 es verificar la información suministrada por el afiliado 10 a través de fuentes autorizadas identificadas 40. El sistema 20 puede definir la información que el afiliado 10 va recolectar en términos de estructuras de datos que habiliten el motor de consulta 26 para interactuar con la fuente autorizada 40 y verificar la información suministrada. El motor de consulta 24 puede suministrar a la fuente autorizada los datos requeridos, suministrados por el afiliado 10 para habilitar a la fuente autorizada 40 para que verifique los datos sin disponer ningún dato de más al sistema, asi habilitar la fuente autorizada 40 para que retenga la información de protección de privacidad del afiliado 10.
En una declaración, el sistema 20 puede recibir un resultado de una consulta iniciada por el motor de consulta 24 en forma de respuesta de una fuente autorizada 40. La respuesta recibida puede validar o invalidar una afirmación realizada por el afiliado 10. Por ejemplo, si el afiliado , 10 suministra información asegurando que tiene una licencia de conducir del Departamento de Vehículos Automotores y es residente, entonces el motor de consulta 24 puede iniciar una consulta a la base de datos del DMV relevante, el cual constituye una fuente autorizada para validar esta afirmación. En respuesta, la base de datos del DMV puede proveer diferentes niveles de información que podrían validar la consulta realizada por el afiliado 10. Por ejemplo, una clase de información provista por el DMV puede ser el número de la licencia del afiliado 10, confirmando que el afiliado 10 es en realidad el titular de una licencia de conducir del estado de Luisiana y también la dirección del domicilio, tal como está en la licencia, lo que confirma que el afiliado 10 es residente de Nueva Orleáns . Adicionalmente , el DMV puede también suministrar información al sistema 20 si la licencia del afiliado 10 indica alguna capacidad especial del afiliado 10 tal como, por ejemplo capacitación en ^Hazmat" [materiales peligrosos] o capacitación como técnico médico. Adicionalmente a esta clase de información, el DMV puede también suministrar otra clase de información- que de soporte a la información provista anteriormente. Esta clase de información podría incluir, por ejemplo, la fecha de expiración de la licencia. El DMV puede suministrar aun otro tipo de información que incluya unos datos más detallados del afiliado 10, que también hace parte de la información en la licencia del afiliado 10. Esta clase de información puede incluir, por ejemplo, si el afiliado 10 es un donante de órganos.
En una declaración, el sistema 20 puede almacenar los resultados de la consulta iniciada por el motor de consulta 24 en la base de datos 22. Además, el sistema 20 puede almacenar algunos de los datos subyacentes al resultado de la consulta basado en las reglas establecidas ente el sistema 20 y la fuente autorizada 40 en soporte de las reglas definidas por el otorgante de privilegios 30 y la exposición de datos aprobada por el afiliado 10. Por ejemplo, manteniendo el escenario anteriormente discutido, el sistema 20 puede almacenar el resultado de la validación de la información suministrada por el afiliado 10, i.e., que el afiliado 10 es un residente de Nueva Orleans, tiene una licencia de conducir válida y tiene entrenamiento en "Hazmat" [materiales peligrosos] , pero puede no almacenar el número de la licencia, dirección, fecha de vencimiento de la licencia, y la fecha cuando el afiliado 10 recibió la capacitación en "Hazmat". Similarmente, si el motor de consulta 24, consultó una base de datos de un banco para determinar si el afiliado 10 lleva a cabo transacciones con ese banco, basado en la información suministrada por el afiliado 10, el sistema 20 puede almacenar el resultado indicando que el afiliado 10 efectivamente posee una o más cuentas con ese banco pero puede no almacenar información real de la cuenta (ej . , saldo de la cuenta, lineas de crédito, etc.) en la base de datos 22.
Adicionalmente , en una declaración, la información suministrada por el afiliado 10 puede persistir en una manera tal que dicho motor de consulta 24 puede iniciar consultas en fuentes autorizadas 40 en una base periódica para asegurar que la validación de los resultados almacenados en el sistema 20 sean reales. De tal manera, por ejemplo, el sistema 20 puede ser configurado de tal modo que el motor de consulta 24 puede consultar fuentes autorizadas 40 a una hora establecida cada día, cada semana o cada mes dependiendo de la necesidad. En una declaración, la frecuencia de la consulta puede ser establecida por el sistema 20, el otorgante de privilegios 30, o una combinación de ambos componentes basado en los requisitos del otorgante de privilegios y el índice de cambio de la fuente autorizada 40. Alternativamente, el motor de consulta 24 puede consultar una fuente autorizada 40 justo antes de que los datos relevantes se comparen con una regla, en un motor de comparación 26. Además, el otorgante de privilegios 30 puede establecer diferentes frecuencias para la base de la consulta en el tipo de regla que requiera el tipo particular de consulta. Por ejemplo, una regla establecida por el otorgante de privilegios 30 puede requerir que el afiliado 10 sea un oficial de policía de New Orleans con entrenamiento "Hazmat" para que se forme una relación de confianza entre el otorgante de privilegios 30 y el afiliado 10. El otorgante del privilegio 30 puede especificar que las bases de datos relevantes, i.e., las fuentes autorizadas 40 relevantes, sean consultadas en una base semanal para validar dicha información. Por otra parte, otra regla suministrada por el otorgante de privilegios 30 concerniente a los doctores médicos puede no requerir validación frecuente. Por lo tanto, el otorgante del privilegio 30 puede especificar esas consultas para validar información médica relativa a esta regla que sea ejecutada solamente en bases semi-anuales o anuales. En una declaración, la frecuencia de la consulta puede ser especificada como parte de la regla establecida por el otorgante del privilegio 30. Alternativamente, la frecuencia de la consulta puede establecerse como parte de una comunicación separada entre el otorgante del privilegio 30 y el sistema 20.
En una declaración, el sistema 20 puede estar configurado de tal forma que el motor de comparación 26 puede comparar los resultados de la consulta almacenados en la base de datos 22 relacionados con el afiliado 10 con una o más de las reglas suministradas por el otorgante del privilegio 30. Por ejemplo, en una declaración, el afiliado 10 puede asegurar que es un oficial en el departamento de policía de Nueva Orleans, tiene una licencia de conducir emitida por el estado, y está certificado como técnico médico. Como se discutió anteriormente, el motor de consulta 24 puede consultar las fuentes autorizadas 40 relacionadas para que validen esta información. Las fuentes autorizadas 40 pueden incluir, por ejemplo, la base de datos del departamento de policía de Nueva Orleans y del DMV para el estado de Luisiana. Basado en la respuesta recibida proveniente de las fuentes autorizadas 40, el sistema 20 puede almacenar un resultado en la base de datos 22 indicando, si la información suministrada por el afiliado 10 es en realidad quien él afirma ser. Adicionalmente, el otorgante del privilegio 30, tal como, por ejemplo, la FEMA [Agencia Federal Administrativa en Casos de Emergencia] , puede establecer una regla en el sistema 20 que a fin de desarrollar una relación de confianza con FEMA, el afiliado 10 necesita ser un oficial de la policía de Nueva Orleans, que tenga una licencia de conducir del estado de Luisiana, y que también sea un técnico médico certificado. El motor de comparación 26 puede comparar la validación del resultado del afiliado 10 almacenado en la base de datos 22, a fin de determinar si el afiliado 10 cumple con esta regla para establecer una relación de confianza con el otorgante del privilegio 30. Si la validación almacenada resulta indicar que el afiliado 10 reúne todos los requisitos de la regla establecida por el otorgante del privilegio 30, entonces la relación de confianza se puede formar entre el afiliado 10 y el otorgante del privilegio 30.
Después de que dicha comparación se lleve a cabo, el sistema 20 puede notificar al otorgante del privilegio 30 si el afiliado 10 cumple con los requisitos establecidos en la regla suministrada por el otorgante del privilegio 30. En una declaración, esta notificación puede ser suministrada a través de la red de comunicación entre el sistema 20 y el otorgante del privilegio 30. En particular, la notificación puede presentarse en forma de un correo electrónico o una llamada telefónica (manual o automatizada) como indicador en una interface del cliente o portal, o cualquier combinación de ello. Además, o en una declaración alterna el sistema 20 puede también notificar al afiliado 10 la aprobación o rechazo de la solicitud por una relación de confianza con el otorgante del privilegio 30.
Adicionalmente , en una declaración mientras el sistema 20 pueda notificar al otorgante del privilegio 30 en cuanto a si el afiliado 10 reúne los requisitos establecidos en una regla provista por el otorgante del privilegio 30, el sistema 20 puede no compartir ninguno de los datos suministrados por el afiliado 10, o cualquiera de los datos subyacentes a su validación con el otorgante del privilegio 30. Por lo tanto, los datos suministrados por el afiliado 10 como parte de su afirmación y los datos obtenidos provenientes de la fuente autorizada 40 pueden permanecer confidenciales.
Después de la comparación anteriormente definida, el sistema 20 puede también suministrar los resultados de la comparación al afiliado 10 a través de los mecanismos descritos anteriormente. En caso que la comparación no sea fructífera el sistema 20 suministrará al afiliado 10 la información sobre la falla de la comparación e identificará la información necesaria para satisfacer la comparación.
Es importante tener en cuenta que mientras que la presente divulgación discute los ejemplos de un afiliado 10 individual, la base de datos 22 puede almacenar información acerca de múltiples afiliados 10 y puede validar la información acerca de múltiples afiliados 10 al consultar fuentes autorizadas 40 múltiples, sin apartarse del alcance de esta divulgación. Adicionalmente, el sistema 20 puede estar en comunicación con múltiples otorgantes de privilegios 30 y recibir múltiples reglas de varios otorgantes de privilegios sin apartarse del alcance de la divulgación. Además, el motor de comparación 26 puede comparar los resultados almacenados en la base de datos 22 con múltiples reglas suministradas por el otorgante del privilegio 30, sin apartarse del alcance de la divulgación.
En una declaración alterna, la base de datos 22 del sistema 20 puede ser poblada con información provista por múltiples afiliados 10. Adicionalmente, basado en la información suministrada por los afiliados 10, el motor de consulta 24 puede consultar con las fuentes autorizadas 40 relevantes para validar las afirmaciones hechas por los afiliados 10. Los resultados también se pueden almacenar en una base de datos 22. Al tener esta información pre-almacenada en el sistema 20, el sistema 20 puede, al momento del recibo de una regla proveniente de un otorgante del privilegio 30, ser capaz inmediatamente de identificar cuáles de los afiliados 10 pueden satisfacer la regla suministrada por el otorgante del privilegio 30 y, por lo tanto, elegible para formar una relación de confianza con el otorgante del privilegio 30. Por ejemplo, basado en la información provista por los afiliados 10 y las consultas llevadas a cabo basadas en la información provista por los afiliados 10, el sistema 20 puede tener un listado de los oficiales de policía (en este caso) , quienes son residentes del estado de Luisiana y están certificados en el manejo de Hazmat (materiales peligrosos) . Si en el caso de una emergencia en Luisiana la FEMA (el otorgante del privilegio 30 en este caso) decide utilizar personal con las características mencionadas anteriormente, el sistema 20 puede estar capacitado para formar una relación de confianza inmediatamente entre dicho personal (cuyos datos han sido validados por el sistema 20) y FEMA, al momento del recibo de dicha regla proveniente de FEMA. Alternativamente, FEMA puede tener dicha regla pre-almacenada en el sistema 20 en un estado de inhabilitada. Al momento en que se presente una necesidad, FEMA puede activar la regla e inmediatamente obtener un listado de los afiliados 10 quienes reúnen los criterios especificados en la regla.
La funcionalidad de la base de datos 22, el motor de consulta 24, y el motor de comparación 26 se pueden suministrar en un dispositivo de cómputo individual o puede ser distribuido a lo ancho de múltiples dispositivos de cómputo que pueden ser acoplados reciprocamente sin salir del alcance de esta divulgación. Adicionalmente, las características discutidas anteriormente se pueden implementar como uno o más programas ejecutables en un medio de lectura de computador, o como uno o más componentes de hardware, o cualquier combinación de estos, sin apartarse del alcance de esta divulgación.
Adicionalmente, mientras que el sistema descrito anteriormente se refiere a un afiliado 10 individual que suministra su información al sistema 20 a fin de formar una relación de confianza con el otorgante del privilegio 30, es importante tener en cuenta que la divulgación no se limita a ello. Más bien que un individuo solo suministre sus credenciales al sistema 20, una organización puede suministrar información con todos o una parte de sus afiliados 10 al sistema 20, a fin de crear relaciones con los otorgantes del privilegio 30. Por ejemplo, una compañía de petróleo como la Shell, BP, o la Exxon puede suministrar información al sistema 20, con respecto a las credenciales y las capacidades de algunos de sus ingenieros geólogos quienes se especializan en contener derramamientos de petróleo. Esta información pueden ser datos del grupo de recursos humanos de la compañía de petróleo. La razón detrás de esto puede ser que la compañía de petróleo quiera tener un grupo de Especialistas a quienes el otorgante del privilegio 30 haya validado y confían, como por ejemplo, La guarda Costera de los EE.UU., listos para servir en caso de un derramamiento de petróleo. Alternativamente, las organizaciones en si pueden suministrar información como afiliadas.
La Fig. 2 es un diagrama esquemático de una declaración de un sistema 20 de manejo de confianza, identidad y fuentes autorizadas 40. El motor 200 de manejo de confianza e identidad puede ser un servidor para que realice servicios de la red RESTful 202 (PUT/POSVGET/DELETE) que suministra apoyo a la autenticación y autorización, manejo del perfil, manejo de la persona, manejo de los datos de los afiliado 10s, manejo e informe de la confianza. Los servicios de la red RESTful 202 pueden ser hospedados en uno o más servidores de red y se pueden dividir en tres niveles generales: de servicio 204, comercial 206 y de datos 208. El nivel de servicios 204 puede proveer interfaces al motor 200 para los afiliados 10, los otorgantes del privilegio 40, los administradores, etc. El nivel comercial 206 puede procesar reglas y objetos comerciales. El nivel de datos 208 puede proveer el almacenamiento de datos y el manejo de la recuperación. El motor 200 puede incluir el dar apoyo a la optimización y el balanceo de la carga. Un almacenamiento de una sola clave 210 se puede utilizar para cada caso del servidor de los servicios. El almacenamiento de una clave 210 puede contener todas las claves criptográficas para un almacenamiento seguro de la información.
Se puede emplear un número de bases de datos 212 para dar apoyo al motor 200. Las bases de datos 212se pueden diseñar para operar en casos de servidores separados del servidor o los servidores del motor 200. Las bases de datos 212 pueden incluir una autenticación de las bases de datos 214 que almacena todos los datos relacionados a la autenticación y la autorización, una base de datos de auditoria 216 que almacena información de auditoria para el no repudio, una base de datos de operaciones 218, la cual actúa como la base de datos operacional para el motor 200, una base de datos de las métricas 220 la cual provee el almacenamiento de las métricas para las operaciones del motor 200. Las bases de datos 212 pueden ser escalonadas a través de agrupaciones. La comunicación entre las bases de datos 212 y el estrato de datos 208 se puede llevar a cabo sobre el SSL.
El acceso al motor 200 se puede suministrar a través de los API basados en la red como un software orientado a servicios. Las aplicaciones del cliente (el cual puede incluir las aplicaciones basadas en la red, las aplicaciones de usuario, aplicaciones móviles u otros sistemas) pueden interactuar con el motor 200 utilizando niveles de servicios 204. Todas las comunicaciones que involucren niveles de servicio 204 se pueden realizar a través de la SSL. Cada comunicación emitida para el motor 200 puede ser individualmente autenticada con el motor actuando como el servicio de la autenticación autorizada para el cliente. 0046] El controlador 200 puede ser una aplicación ASP.NET Las aplicaciones pueden ser albergadas en uno o más servidores de Red y se pueden utilizar por las organizaciones para llevar a cabo las interacciones con el motor 200. El apoyo para la optimización y el balanceo de la carga puede estar incluido. El controlador 220 se puede diseñar para que provea diferentes conjuntos de funcionalidades a las diferentes comunidades del motor 200 con pantallas especificas desarrolladas para cada comunidad. Finalmente, todo comportamiento es mapeado a los conceptos estándar de operación para el motor 200. El controlador 200 suministra diferentes funcionalidades basadas en el usuario que se haya registrado; con esas funcionalidades ya definidas en la que se encuentra el usuario, y como en que papel el usuario está registrado como (e.g., afiliado 10 o el otorgante del privilegio 30) . El controlador 200 puede dar soporte al acceso a través de uno o más navegadores de red 222 basados en un contenido de Javascript, Flash o alguno similar. Los clientes individuales también pueden tener acceso al motor 200, lo cual puede permitir a los afiliados 10 individuales o a los otorgantes de privilegios 30 a que se registren en el motor y manejar su información privada. También se puede gestionar un cliente administrativo que permita el manejo del motor 200. El cliente administrativo puede ser en la forma de una interface de usuario. Los sistemas 224 de terceros también pueden interactuar con el nivel de servicio 204 del motor 200 a través de las comunicaciones SSL.
Los Spider 206 [programa automatizado de rastreo] son servicios independientes de dominio [término del sistema 20 Unix que realizan una operación especifica] que operan en uno o más servidores que forman el motor 200 para que descarguen los datos de los afiliados y de la confianza asociada con el motor 200 para evaluar el estado de los datos (e.g., la comparación) . La comunicación con el nivel de datos 208 se lleva a cabo utilizando el mismo nivel de datos que se utiliza por los servicios REST 202 (diferentes casos, la misma base de código) . Las Comunicaciones con bases de datos 212 se llevan a cabo a través de SSL. Los Spider 226 pueden correrse en bases cronometradas para mirar a cada conjunto de datos de un afiliado y determinar si es válido o inválido. Esta determinación puede validar o invalidar las relaciones de confianza. Opcionalmente, los Spider 226 también pueden proactivamente crear relaciones entre los afiliados 10 y las reglas provenientes de los otorgantes de los privilegios 30 cuando todos los requisitos de las reglas se hayan cumplido. Debido a que los conjuntos de datos de cada afiliado que el Spider 226 encuentra podría estar contactando una fuente de datos externa para validación, una combinación de parámetros entre el Spider 226 y los conjuntos de datos se puede configurar para controlar qué tan a menudo el conjunto de datos se verifica. Esto podría ser útil si los datos de un afiliado están atados a un servicio que cobra por cada llamada de soporte.
El motor 200 busca y obtiene información acerca de los afiliados 10 de las fuentes autorizadas 40 a través de los adaptadores de la fuente de datos 228. Como se notó anteriormente, la información concerniente a los afiliados 10 se puede basar en los datos que está almacenada en sitios de terceros. Estos datos se pueden recuperar de dos tipos de localizaciones, de los servicios de red de terceros 230 o de centros de datos 232. Cada ítem de información concerniente a un afiliado 10 almacenado en el motor 200 y asociado a las bases de datos 212 puede incluir metadatos concernientes a donde validar los datos. Cuando un Spider 226 recibe estos datos, esta se re-direcciona para que contacte al adaptador 228 de datos apropiado, el cual, a su vez, puede pasar la solicitud a la fuente autorizada 40 para validar los datos.
Los adaptadores de la fuente de datos 228 pueden ser servicios de la red que están basados en uno o más servidores de red que dan soporte a las comunicaciones SSL desde y hacia el motor 200 y los Spider 226. Los adaptadores de la fuente de datos 228 fuente pueden presentar una interface unificada para ambos servicios de Spider 226 y de motor 200, de tal manera que los adaptadores de la fuente de datos 228 traducen datos de las fuentes autorizadas 40 a la interface unificada. Asi, cada adaptador de la fuente de datos 228 se personaliza por la fuente autorizada 40 en particular. Por ejemplo, los mismos adaptadores de la fuente de datos 228 se pueden emplear para acceder los datos de DMV para múltiples conductores.
Como se anotó anteriormente, el motor 200 puede obtener datos concerniente a los afiliados enfrentando servicios de red públicos 230 o de centros de datos 232. Para hacer una interface con los servicios de red públicos 230, los adaptadores de la fuente de datos 228 se pueden escribir de una manera personalizada para fuentes de datos externos particulares.
Cada centro de datos 232 es un servicio WEB suministrado a una fuente autorizada 40 que incluye los protocolos necesarios para' comunicarse con el motor 200. Cada centro de datos 232 es una aplicación virtual que lleva a cabo la función de sincronizar datos selectivamente y hace arreglos para su recuperación a través de los servicios Web por adaptadores de la fuente de datos 228. Los centros de datos 232 pueden obtener datos de un número de fuentes incluyendo, pero sin limitarse a, casi todas las bases de datos comerciales, SAP, Idap y exchange. Cada centro de datos 232 está ubicado dentro de la infraestructura IT. Un motor de transformación 234 rutinariamente copia y encripta los datos que se necesitan para apoyar datos asociados con los afiliados 10 a una base de datos interna 236. Toda encriptación se puede hacer utilizando la clave pública actual del motor 200 en el almacén de claves 210. Cada registro se puede identificar únicamente por un valor mezclado del que únicamente el motor 200 tiene una copia La comunicación entre los adaptadores de la fuente de datos 228 y los centros de datos 232 puede ser a través de una VPN. El tráfico puede estar basado en UDP, dándole al centro de datos 232 la habilidad de colocarse detrás de la mayoría de los firewall corporativos sin necesitar cambios de configuración a la infraestructura IT corporativa. El canal VPN puede estar encriptado por el proveedor, y el canal de comunicación al adaptador de la fuente de datos 228 puede estar asegurado por SSL. Todos los datos enviados pueden también estar encriptados por la clave pública del motor 200.
La Fig. 3 es una representación de diagrama de flujo de un método de administración 300 de identidad y confianza de acuerdo a la declaración divulgada. En el paso 302, un sistema como por ejemplo, el sistema 20 descrito en la Fig. 1, puede recibir en una red de comunicación, al menos una regla de al menos un otorgante de privilegios 30, como por ejemplo el otorgante de privilegios también descrito en la Fig. 1, que debe ser cumplida por al menos un otorgante de privilegios para autorizar un afiliado 10. En el paso 304, el sistema puede establecer una base de datos como por ejemplo, la base de datos 22 descrito en la Fig. 1, de al menos un afiliado como por ejemplo el afiliado 10 descrito en la Fig. 1. En el paso 306, el sistema 20 puede consultar, utilizando un motor 24 de consulta como por ejemplo, el motor de consulta descrita en la Fig. 1, en al menos una fuente autorizada como por ejemplo, la fuente autorizada 40 descrita en la Fig. 1, para determinar si la información acerca de al menos un afiliado es correcta. En el paso 308, el sistema puede también almacenar en la base de datos un resultado de la consulta sin almacenar datos subyacentes al resultado. En el paso 310, el sistema puede comparar el resultado almacenado en la base de datos con al menos una regla para determinar si al menos un afiliado cumple al menos una regla. En el paso 312, el sistema puede notificar al menos un otorgante de privilegios si al menos un afiliado cumple con al menos una regla basado en la comparación, sin suministrar al otorgante de privilegios ni datos almacenados en la base de datos para al menos un afiliado ni los datos subyacentes al resultado.
Siendo que varias declaraciones de la presente divulgación han sido anteriormente descritas, se debe entender que estas han sido presentadas únicamente como una forma de ejemplo, y sin limitación. Se entenderá la importancia de que varios cambios en forma y detalles pueden ser realizados sin apartarse del espíritu y alcance de la divulgación. De esta manera, la extensión y alcance de la divulgación no se deben limitar por ninguna de las declaraciones de los ejemplos anteriormente descritos.

Claims (1)

  1. REIVINDICACIONES Un sistema de determinación de la identidad de los afiliados quienes cumplan los requisitos de confianza de un otorgante de privilegios incluye: • Un sistema de administración de confianza e identificación incluyendo al menos un dispositivo de informática en comunicación con al menos un afiliado, al menos un otorgante de privilegio y al menos una fuente autorizada; el dispositivo de informática está configurado para: • Recibir al menos una regla de al menos un otorgante de privilegios que cumpla con el otorgante de privilegio para verificar y autorizar a un afiliado; • Establecer una base de datos de al menos un afiliado con información acerca del afiliado; la consulta de al menos una fuente autorizada para determinar si al menos una porción de la información acerca del afiliado es correcta; • Recibir una respuesta de la fuente autorizada de si la porción de información es correcta o no; • Almacenar en la base de datos un resultado de la consulta sin almacenar datos subyacentes al resultado; • Comparar la información almacenada en la base de datos con al menos una regla para determinar si el afiliado cumple con la regla; y • Notificar al otorgante de privilegios si el afiliado cumple o no la regla basado en la comparación, sin suministrar al otorgante de privilegios datos del afiliado almacenados en la base de datos o los datos subyacentes al resultado. El sistema de argumentaciones, en donde existe una estructura entre una pluralidad de reglas suministradas por al menos un otorgante de privilegios. El sistema de argumentaciones, en donde al menos un dispositivo de informática está configurado para consultar al menos una fuente autorizada concerniente a la porción de información en una base periódica. El sistema de argumentaciones, en donde al menos una regla puede ser basada en una hora, una fecha, una ubicación geográfica o una combinación de ellos. El sistema de argumentaciones, en donde al menos un dispositivo de informática está configurado para recibir de al menos un afiliado 10 información contra la cual el afiliado 10 permita al sistema consultar la fuente autorizada. El sistema de argumentaciones 5, en donde la información representa diferentes clases de información. El sistema de argumentaciones 5, en donde la base de datos está configurada para almacenar múltiples personajes para al menos un afiliado en donde cada personaje representa un grupo diferente de información acerca de al menos un afiliado el cual el personaje del afiliado permita ser comparado con la regla para un otorgante de privilegios en particular. Un método de determinación de la identidad de los afiliados quienes cumplan con los requisitos de confianza de un otorgante de privilegios comprende: Recibir, sobre una red de comunicación, al menos una regla de al menos un otorgante de privilegios que debe ser cumplida para que el otorgante de privilegios confie en un afiliado; Establecer una base de datos de al menos un afiliado con información acerca del afiliado; Consultar, utilizando un motor de consulta, en al menos una fuente autorizada para determinar si al menos una porción de la información acerca del afiliado es correcta; Recibir, en una red de comunicación, una respuesta de la fuente autorizada de si la porción de información es correcta o no; almacenar en la base de datos un resultado de la consulta sin almacenar datos subyacentes al resultado; Comparar, utilizando un motor de comparación, la información almacenada en la base de datos con al menos una regla para determinar si el afiliado cumple con la regla; y Notificar al otorgante de privilegios si el afiliado cumple o no la regla basado en la comparación, sin suministrar al otorgante de privilegios datos del afiliado almacenados en la base de datos o los datos subyacentes al resultado. El método de argumentaciones 8, en donde existe una estructura entre una pluralidad de reglas suministradas por el otorgante de privilegios. El método de argumentaciones 8, en donde la consulta y la comparación ocurren en una base periódica. 11. El método de argumentaciones 8, en donde al menos una regla puede ser basada en una hora, una fecha, una ubicación geográfica o una combinación de ellos. 12. El método de argumentaciones 8, además de incluir recepción de información de al menos un afiliado contra la cual el afiliado permita la consulta de al menos una fuente autorizada . 13. El método de argumentaciones 12, en donde la información representa diferentes clases de información. 14. El método de argumentaciones 12, en donde la base de datos almacena múltiples identidades para al menos un afiliado 10 donde cada identidad representa una recolección diferente de información acerca del afiliado, y el método además comprende la recepción de información de al menos un afiliado para el cual la identidad del afiliado permita ser comparada con una regla por un otorgante de privilegios en particular.
MX2011007255A 2010-07-06 2011-07-06 Sistemas y metodos para establecer confianza entre entidades como apoyo a transacciones. MX2011007255A (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US36175810P 2010-07-06 2010-07-06

Publications (1)

Publication Number Publication Date
MX2011007255A true MX2011007255A (es) 2012-10-02

Family

ID=45439541

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2011007255A MX2011007255A (es) 2010-07-06 2011-07-06 Sistemas y metodos para establecer confianza entre entidades como apoyo a transacciones.

Country Status (6)

Country Link
US (1) US8549622B2 (es)
EP (1) EP2591438B1 (es)
BR (1) BR112013000438A2 (es)
CO (1) CO6350200A1 (es)
MX (1) MX2011007255A (es)
WO (1) WO2012006242A2 (es)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130247146A1 (en) * 2005-03-17 2013-09-19 Dennis Lyon Authentication system and method
US20090157491A1 (en) * 2007-12-12 2009-06-18 Brougher William C Monetization of Online Content
US9185169B2 (en) 2011-07-29 2015-11-10 Avaya Inc. Methods, systems, and computer-readable media for self-learning interactive communications privileges for governing interactive communications with entities outside a domain
US8966589B2 (en) * 2011-08-24 2015-02-24 Avaya Inc. Methods, systems, and computer-readable media for exception handling of interactive communications privileges governing interactive communications with entities outside a domain
US9264534B2 (en) * 2011-10-18 2016-02-16 Avaya Inc. Methods, systems, and computer-readable media for self-maintaining interactive communications privileges governing interactive communications with entities outside a domain
US8528043B2 (en) * 2011-12-06 2013-09-03 Sap Ag Systems and methods for generating trust federation data from BPMN choreography
US9443021B2 (en) * 2011-12-30 2016-09-13 Microsoft Technology Licensing, Llc Entity based search and resolution
US9910929B2 (en) * 2012-10-24 2018-03-06 International Business Machines Corporation Web browser-based content management system
US9872137B2 (en) * 2014-07-07 2018-01-16 Lg Electronics Inc. Method and apparatus for providing location information in a wireless access system supporting a mission critical push to talk service
US10192067B2 (en) 2016-05-26 2019-01-29 Microsoft Technology Licensing, Llc Self-described security model for resource access
CN108121733B (zh) * 2016-11-29 2021-10-15 北京国双科技有限公司 一种数据的查询方法及装置
US10601855B2 (en) * 2017-06-01 2020-03-24 International Business Machines Corporation Source verification device
US11503037B2 (en) 2019-11-04 2022-11-15 Microsoft Technology Licensing, Llc Nested access privilege check for multi-tenant organizations
LU101757B1 (en) * 2020-04-28 2021-10-28 Microsoft Technology Licensing Llc Encrypted verifiable credentials
US12074879B2 (en) * 2021-09-14 2024-08-27 Juniper Networks, Inc. Inferring trust in computer networks

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6158010A (en) * 1998-10-28 2000-12-05 Crosslogix, Inc. System and method for maintaining security in a distributed computer network
US6931419B1 (en) 2000-02-11 2005-08-16 Hallmark Cards Incorporated Data management system for automatically accessing, maintaining, propagating user data among plurality of communities, each of which contains plurality of members
AU7182701A (en) * 2000-07-06 2002-01-21 David Paul Felsher Information record infrastructure, system and method
US8381287B2 (en) * 2006-07-19 2013-02-19 Secure Exchange Solutions, Llc Trusted records using secure exchange
US20080097999A1 (en) 2006-10-10 2008-04-24 Tim Horan Dynamic creation of information sharing social networks
US20090070128A1 (en) 2007-09-11 2009-03-12 Author Solutions Inc. Community-based community project content creation system and method
US20100076987A1 (en) 2008-09-10 2010-03-25 Benjamin Schreiner Trust Profile Aggregation from Various Trust Record Sources
US8464313B2 (en) * 2008-11-10 2013-06-11 Jeff STOLLMAN Methods and apparatus related to transmission of confidential information to a relying entity

Also Published As

Publication number Publication date
BR112013000438A2 (pt) 2016-05-17
WO2012006242A2 (en) 2012-01-12
US8549622B2 (en) 2013-10-01
CO6350200A1 (es) 2011-12-20
EP2591438A2 (en) 2013-05-15
WO2012006242A3 (en) 2012-04-19
EP2591438A4 (en) 2015-04-22
US20120011587A1 (en) 2012-01-12
EP2591438B1 (en) 2016-11-23

Similar Documents

Publication Publication Date Title
MX2011007255A (es) Sistemas y metodos para establecer confianza entre entidades como apoyo a transacciones.
US11928197B2 (en) Method for providing an authenticated digital identity
US11023604B1 (en) Systems and methods to track, store, and manage events, rights and liabilities
US11805131B2 (en) Methods and systems for virtual file storage and encryption
US10032039B1 (en) Role access to information assets based on risk model
US9805213B1 (en) Identity validation and verification system and associated methods
Hiller et al. Privacy and security in the implementation of health information technology (electronic health records): US and EU compared
Rezgui et al. Preserving privacy in web services
US11412002B2 (en) Provision of policy compliant storage for DID data
JP6785808B2 (ja) ポリシー強制遅延
US20180197145A1 (en) Multi-stage service record collection and access
US20200296102A1 (en) User choice in data location and policy adherence
Silva et al. A fog computing‐based architecture for medical records management
CA3024158C (en) Method and apparatus for issuing a credential for an incident area network
US20080312962A1 (en) System and method for providing services via a network in an emergency context
Jansen et al. Guiding principles to maintain public trust in the use of mobile operator data for policy purposes
Chen et al. Time-space companions: Digital surveillance, social management, and abuse of power during the covid-19 pandemic in china
WO2019148248A1 (en) Personal record repository arrangement and method for incentivised data analytics
Majumder Cyberbanks and other virtual research repositories
Hernandez et al. TIKD: A Trusted Integrated Knowledge Dataspace for Sensitive Data Sharing and Collaboration
Uthmani et al. Novel information sharing syntax for data sharing between police and community partners, using role-based security
US20230185954A1 (en) Transmission of Sensitive Data in a Communication Network
JP2010539563A (ja) 警備代理業務
Omary Context-Based Access for Infrequent Requests in Tanzania's Health Care System
by this Policy 11.18-Secure Data Export Policy

Legal Events

Date Code Title Description
FA Abandonment or withdrawal