검색결과
-
[기획-디지털 ID 기술] ㊳ 토론토도미니언뱅크, '엔티티 아이디 데이터에 대한 액세스를 관리하기 위한 방법 및 시스템' 명칭의 미국 특허 등록 (US 11636225)캐나다 금융서비스 기업 토론토도미니언뱅크(Toronto-Dominion Bank)에 따르면 2023년 4월25일 '엔티티 아이디 데이터에 대한 액세스를 관리하기 위한 방법 및 시스템(Method and system for managing access to entity identity data)' 명칭의 미국 특허(US 11636225)가 등록됐다.본 등록 특허는 2020년 5월22일 출원(US16/881088)된 후 미국 특허청에 의해 심사를 받았다. 본 등록 특허의 패밀로 특허로 미국 특허(US 2023-0222243)가 2023년 3월21일 계속 출원돼 심사 중이다.본 등록 특허의 일 실시예에 따르면 통신 모듈, 프로세서 및 메모리를 포함한다. 메모리는 프로세서에 의해 실행되는 명령을 저장하고, 프로세서는 통신 모듈과 결합된다. 프로세서는 엔터티(entity)와 관련된 원격 장치를 인증한다. 프로세서는 통신 모듈을 통해 원격 장치로부터 엔터티에 대한 엔터티 아이디 데이터에 액세스하도록 허용된 하나 이상의 제3자를 식별하는 사전 동의 데이터를 수신한다.프로세서는 통신 모듈을 통해 디지털 아이디 네트워크로부터 엔터티 아이디 데이터를 제3자에게 공개하라는 리퀘스트를 나타내는 신호를 수신한다.프로세서는 사전 동의 데이터를 기반으로 엔터티 아이디 데이터가 제3자에게 공개되도록 결정한다. 프로세서는 제3자와 관련된 컴퓨팅 장치에 대한 엔터티 아이디 데이터의 공개를 개시한다.
-
[기획-디지털 ID 기술] ㊲ 마스터카드 인터내셔널, '자격 증명 프로비저닝에 사용되는 시스템 및 방법' 명칭의 미국 특허 등록 (US 11646895)미국 글로벌 결제 서비스 기업 마스터카드 인터내셔널(MASTERCARD INTERNATIONAL INCORPORATED)에 따르면 2023년 5월9일 '자격 증명 프로비저닝에 사용되는 시스템 및 방법(Systems and methods for use in provisioning credentials)' 명칭의 미국 특허(US 11646895)가 등록됐다.본 등록 특허는 2020년 6월 1일에 출원(US 16/889374)된 후 미국 특허청에 의해 심사를 받았다. 본 등록 특허의 패밀리 특허로 미국 특허(US 2023-0239161)가 2023년 3월30일 출원돼 심사 중이다.본 등록 특허는 검증된 또는 신뢰할 수 있는 사용자와의 상호 작용에 기초해 아이디 증명서를 프로비저닝하기 위한 시스템 및 방법에 관한 특허다.본 등록 특허의 일 실시예에 따르면 사용자로부터 디지털 아이디에 대한 리퀘스트를 수신한다. 리퀘스트는 사용자 및 검증된 사용자 식별자에 대한 정보를 식별한다.검증된 사용자 식별자와 관련된 검증된 사용자에게 해당 사용자에 대한 증명 리퀘스트를 전송한다. 검증된 사용자로부터, 사용자에 대한 식별 정보의 적어도 일부에 대한 증명 리퀘스트에 응답하여 증명을 수신한다.사용자에 대한 식별 정보의 다수의 증명을 기초로 사용자에 대한 디지털 아이디를 생성한다. 사용자에 대한 식별자를 포함하는 사용자와 디지털 아이디 통지를 공유한다. 사용자는 식별자를 통해 신뢰 당사자와 디지털 아이디를 공유할 수 있다.
-
[기획-디지털 ID 기술] ㊱ 피델리티 인포메이션 서비스, '범용 디지털 아이디 인증 서비스' 명칭의 미국 특허 등록 (US 11652820)미국 금융 정보 기업 피델리티 인포메이션 서비스(Fidelity Information Services)에 따르면 2023년 5월16일 '범용 디지털 아이디 인증 서비스(Universal digital identity authentication service)' 명칭의 미국 특허(US 11652820)가 등록됐다.본 등록 특허는 모출원 특허(US 11095643)를 기초로 2021년 7월9일 계속 출원돼 미국 특허청에 의해 심사를 받았다.모출원 특허(US 11095643)는 2017년 2월17일 가출원(US 62/460611)된 후 2018년 2월16일 출원(US 16/322705)되어 2021년 8월 17일에 등록됐다.본 등록 특허의 패밀리로서 뉴질랜드 특허(NZ 755143), 브라질 특허(BR 112019017075), 오스트레일리아 특허(AU 2022206815), 캐나다 특허(CA 3053957), 유럽 특허(EP 3937456), 미국 특허(US 2023-0254311)가 심사 중이다. 오스트레일리아 특허(AU 2018222744), 유럽 특허(EP 3583758), 미국 특허(US 11095643)가 등록됐다.본 등록 특허는 사용자 로그인을 위한 프록시로서 신뢰할 수 있는 모바일 장치를 사용해 다수의 기관에 걸쳐 아이디 인증을 위한 시스템과 방법에 관한 특허다.본 등록 특허의 일 실시예에 따르면 디지털 아이디 네트워크에서 제 1 엔티티와 연관된 특정 사용자를 신뢰하기 위한 리퀘스트를 식별한다.사용와 연관된 개인 아이디 정보 (PII)세트가 제 1 엔티티를 통해 획득되고 아이디 검증 (IDV)/사기 위험 분석(fraud risk anaylysis)이 실시된다.상기 분석의 만족에 응답해 관련 모바일 장치상의 모바일 신뢰 애플리케이션을 통해 아이디를 검증하기 위해 사용자에게 지시가 전송된다.검증시, 모바일 장치는 특정 사용자와 연관된 디지털 아이디와 함께 디지털 아이디 네트워크 내의 사용자에 바인딩된다. 디지털 아이디는 디지털 아이디 네트워크 내에 등록된 다른 엔티티에 의해 사용돼 사용자를 인증할 수 있다.
-
[기획-디지털 ID 표준] ⑯산업단체와 포럼 - SOG-IS(Senior Officials Group-Information Systems Security)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.SOG-IS(Senior Officials Group-Information Systems Security)는 유럽연합(EU) 또는 유럽 자유 무역 연합(European Free Trade Association, EFTA) 국가의 정부 조직 또는 정부기관간 협정으로 이사회 결정 92/242/EEC (12) 및 후속 이사회 권장 사항 95/144/EC (13)에 따라 작성됐다.SOG-IS 암호 워킹그룹(Crypto Working Group)이 발행한 'SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms' 문서는 주로 개발자와 평가자를 대상으로 작성됐다.어떤 암호화 메커니즘이 동의된 것으로 인식되는지, 즉 SOG-IS 암호화 평가 체계의 모든 SOG-IS 참가자가 수락할 순비가 됐는지 지정하는 것을 목적으로 하고 있다.'SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms' 문서의 목차를 살펴보면 다음과 같다.목차(Table of contents)1. Introduction1.1 Objective1.2 Classification of Cryptographic Mechanisms1.3 Security Level1.4 Organization of the Document1.5 Related Documents2. Symmetric Atomic Primitives2.1 Block Ciphers2.2 Stream Ciphers2.3 Hash Functions2.4 Secret Sharing3. Symmetric Constructions3.1 Confidentiality Modes of Operation: Encryption/Decryption Modes3.2 Specific Confidentiality Modes: Disk Encryption3.3 Integrity Modes: Message Authentication Codes3.4 Symmetric Entity Authentication Schemes3.5 Authenticated Encryption3.6 Key Protection3.7 Key Derivation Functions3.8 Password Protection/Password Hashing Mechanisms4. Asymmetric Atomic Primitives4.1 RSA/Integer Factorization4.2 Discrete Logarithm in Finite Fields4.3 Discrete Logarithm in Elliptic Curves4.4 Other Intractable Problems5. Asymmetric Constructions5.1 Asymmetric Encryption Scheme5.2 Digital Signature5.3 Asymmetric Entity Authentication Schemes5.4 Key Establishment6. Random Generator6.1 Random Source6.2 Deterministic Random Bit Generator6.3 Random Number Generator with Specific Distribution7. Key Management7.1 Key Generation7.2 Key Storage and Transport7.3 Key Use7.4 Key Destruction8. Person AuthenticationA Glossary
-
[기획-디지털 ID 표준] ⑮산업단체와 포럼 - 오픈ID(OpenID)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.오픈ID(OpenID)는 개인 및 기업의 비영리 국제 표준화 조직으로 OpenID(개방형 표준 및 분산 인증 프로토콜)를 활성화, 홍보, 보호하기 위해 노력하고 있다.오픈ID 코넥트 코어(OpenID Connect Core)는 핵심 OpenID 기능을 정의하고 있다. OpenID 기능은 OAuth 2.0 기반에 구축된 인증과 최종 사용자에 대한 정보를 전달하기 위한 클레임의 사용이다. 추가적인 기술 사양 문서는 검증 가능한 자격 증명 및 검증 가능한 프리젠테이션의 발급을 확장하기 위해 작성됐다. 또한 OpenID Connect 사용에 대한 보안 및 개인 정보 보호 고려 사항에 대해 설명하고 있다.아래는 오픈ID가 발행한 'OpenID Connect Core 1.0 incorporating errata set 1' 목차 내용이다.■ 목차(Table of Contents)1. Introduction1.1. Requirements Notation and Conventions1.2. Terminology1.3. Overview2. ID Token3. Authentication3.1. Authentication using the Authorization Code Flow3.1.1. Authorization Code Flow Steps3.1.2. Authorization Endpoint3.1.2.1. Authentication Request3.1.2.2. Authentication Request Validation3.1.2.3. Authorization Server Authenticates End-User3.1.2.4. Authorization Server Obtains End-User Consent/Authorization3.1.2.5. Successful Authentication Response3.1.2.6. Authentication Error Response3.1.2.7. Authentication Response Validation3.1.3. Token Endpoint3.1.3.1. Token Request3.1.3.2. Token Request Validation3.1.3.3. Successful Token Response3.1.3.4. Token Error Response3.1.3.5. Token Response Validation3.1.3.6. ID Token3.1.3.7. ID Token Validation3.1.3.8. Access Token Validation3.2. Authentication using the Implicit Flow3.2.1. Implicit Flow Steps3.2.2. Authorization Endpoint3.2.2.1. Authentication Request3.2.2.2. Authentication Request Validation3.2.2.3. Authorization Server Authenticates End-User3.2.2.4. Authorization Server Obtains End-User Consent/Authorization3.2.2.5. Successful Authentication Response3.2.2.6. Authentication Error Response3.2.2.7. Redirect URI Fragment Handling3.2.2.8. Authentication Response Validation3.2.2.9. Access Token Validation3.2.2.10. ID Token3.2.2.11. ID Token Validation3.3. Authentication using the Hybrid Flow3.3.1. Hybrid Flow Steps3.3.2. Authorization Endpoint3.3.2.1. Authentication Request3.3.2.2. Authentication Request Validation3.3.2.3. Authorization Server Authenticates End-User3.3.2.4. Authorization Server Obtains End-User Consent/Authorization3.3.2.5. Successful Authentication Response3.3.2.6. Authentication Error Response3.3.2.7. Redirect URI Fragment Handling3.3.2.8. Authentication Response Validation3.3.2.9. Access Token Validation3.3.2.10. Authorization Code Validation3.3.2.11. ID Token3.3.2.12. ID Token Validation3.3.3. Token Endpoint3.3.3.1. Token Request3.3.3.2. Token Request Validation3.3.3.3. Successful Token Response3.3.3.4. Token Error Response3.3.3.5. Token Response Validation3.3.3.6. ID Token3.3.3.7. ID Token Validation3.3.3.8. Access Token3.3.3.9. Access Token Validation4. Initiating Login from a Third Party5. Claims5.1. Standard Claims5.1.1. Address Claim5.1.2. Additional Claims5.2. Claims Languages and Scripts5.3. UserInfo Endpoint5.3.1. UserInfo Request5.3.2. Successful UserInfo Response5.3.3. UserInfo Error Response5.3.4. UserInfo Response Validation5.4. Requesting Claims using Scope Values5.5. Requesting Claims using the "claims" Request Parameter5.5.1. Individual Claims Requests5.5.1.1. Requesting the "acr" Claim5.5.2. Languages and Scripts for Individual Claims5.6. Claim Types5.6.1. Normal Claims5.6.2. Aggregated and Distributed Claims5.6.2.1. Example of Aggregated Claims5.6.2.2. Example of Distributed Claims5.7. Claim Stability and Uniqueness6. Passing Request Parameters as JWTs6.1. Passing a Request Object by Value6.1.1. Request using the "request" Request Parameter6.2. Passing a Request Object by Reference6.2.1. URL Referencing the Request Object6.2.2. Request using the "request_uri" Request Parameter6.2.3. Authorization Server Fetches Request Object6.2.4. "request_uri" Rationale6.3. Validating JWT-Based Requests6.3.1. Encrypted Request Object6.3.2. Signed Request Object6.3.3. Request Parameter Assembly and Validation7. Self-Issued OpenID Provider7.1. Self-Issued OpenID Provider Discovery7.2. Self-Issued OpenID Provider Registration7.2.1. Providing Information with the "registration" Request Parameter7.3. Self-Issued OpenID Provider Request7.4. Self-Issued OpenID Provider Response7.5. Self-Issued ID Token Validation8. Subject Identifier Types8.1. Pairwise Identifier Algorithm9. Client Authentication10. Signatures and Encryption10.1. Signing10.1.1. Rotation of Asymmetric Signing Keys10.2. Encryption10.2.1. Rotation of Asymmetric Encryption Keys11. Offline Access12. Using Refresh Tokens12.1. Refresh Request12.2. Successful Refresh Response12.3. Refresh Error Response13. Serializations13.1. Query String Serialization13.2. Form Serialization13.3. JSON Serialization14. String Operations15. Implementation Considerations15.1. Mandatory to Implement Features for All OpenID Providers15.2. Mandatory to Implement Features for Dynamic OpenID Providers15.3. Discovery and Registration15.4. Mandatory to Implement Features for Relying Parties15.5. Implementation Notes15.5.1. Authorization Code Implementation Notes15.5.2. Nonce Implementation Notes15.5.3. Redirect URI Fragment Handling Implementation Notes15.6. Compatibility Notes15.6.1. Pre-Final IETF Specifications15.6.2. Google "iss" Value15.7. Related Specifications and Implementer's Guides16. Security Considerations16.1. Request Disclosure16.2. Server Masquerading16.3. Token Manufacture/Modification16.4. Access Token Disclosure16.5. Server Response Disclosure16.6. Server Response Repudiation16.7. Request Repudiation16.8. Access Token Redirect16.9. Token Reuse16.10. Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)16.11. Token Substitution16.12. Timing Attack16.13. Other Crypto Related Attacks16.14. Signing and Encryption Order16.15. Issuer Identifier16.16. Implicit Flow Threats16.17. TLS Requirements16.18. Lifetimes of Access Tokens and Refresh Tokens16.19. Symmetric Key Entropy16.20. Need for Signed Requests16.21. Need for Encrypted Requests17. Privacy Considerations17.1. Personally Identifiable Information17.2. Data Access Monitoring17.3. Correlation17.4. Offline Access18. IANA Considerations18.1. JSON Web Token Claims Registration18.1.1. Registry Contents18.2. OAuth Parameters Registration18.2.1. Registry Contents18.3. OAuth Extensions Error Registration18.3.1. Registry Contents19. References19.1. Normative References19.2. Informative ReferencesAppendix A. Authorization ExamplesA.1. Example using response_type=codeA.2. Example using response_type=id_tokenA.3. Example using response_type=id_token tokenA.4. Example using response_type=code id_tokenA.5. Example using response_type=code tokenA.6. Example using response_type=code id_token tokenA.7. RSA Key Used in ExamplesAppendix B. AcknowledgementsAppendix C. Notices§ Authors' Addresses
-
[기획-디지털 ID 기술] ㉟ 아웃리드스, 오프라인 데이터와 온라인 활동을 연관시키기 위한 시스템' 명칭의 미국 특허 등록 (US 11671397)미국 데이터 분석 기업 아웃리드스(Outleads)에 따르면 2023년 6월6일 '오프라인 데이터와 온라인 활동을 연관시키기 위한 시스템(System for associating offline data with online activity)' 명칭의 미국 특허(US 11671397)가 등록됐다.본 등록 특허는 미국 모출원 특허(US 9137360) 및 분할출원 특허(US 10798046)를 기초로 2020년 10월6일 계속 출원(US 17/064394)된 후 미국 특허청에 의해 심사를 받았다.미국 모출원 특허(US 9137360)는 2013년 10월25일 가출원(US 61/895544)된 후 2014년 10월27일 본출원(US 14/524949)되어 2015년 9월15일 등록됐다.본 등록 특허의 패밀리 특허로서 이스라엘 특허(IL 245269, IL 252867), 브라질 특허(BR 112016009199, BR 112017013138)가 심사 중이다. 캐나다 특허(CA 2927971), 미국 특허(US 9342843, US 9491249, US 9762529, US 10218666, US 10523627, US 10798046)이 등록됐다.본 등록 특허는 외부 컴퓨터 시스템에서 생성되고 제공된 고유 식별자와 데이터 파일을 연관시켜 데이터를 수집하고 인덱싱하기 위한 시스템에 대한 특허이다.본 등록 특허의 일 실시예에 따르면 데이터 파일은 사용자 조작 컴퓨터 시스템으로부터 획득된다. 컴퓨터 시스템은 네트워크를 통해 서로 신호 통신에 제공된 일련의 컴퓨터를 포함한다.데이터 파일은 웹 서버에 의해 호스팅된 웹 사이트에 의해 제공된 형태에 의해 수집된 데이터를 포함할 수 있다. 에이전트에 의해 동작되는 컴퓨터 시스템과 같은 다른 소스에서 수집된 추가 데이터는 문의 관리회사가 수집한 데이터 파일과 연관된다.수집된 데이터 및 관련 레코드는 온라인 사용자/방문자를 추적하는 컴퓨터 시스템으로 전달된다. 프로세스는 웹 사이트 활동에 대한 컴퓨터 수집된 데이터를 웹 사이트와 독립적인 활동으로 표시할 수 있다.
-
[기획-디지털 ID 기술] ㉞ 메타플랫폼스,사용자 변경을 위해 온라인 시스템에 의한 콘텐츠 선택을 위해 사용된 특성 식별' 명칭의 미국 특허 등록 (US 11676177)미국 기술기업 메타플랫폼스(META PLATFORMS)에 따르면 2023년 6월13일 '사용자 변경을 위해 온라인 시스템에 의한 콘텐츠 선택을 위해 사용된 특성 식별(Identifying characteristics used for content selection by an online system to a user for user modification)' 명칭의 미국 특허(US 11676177)가 등록됐다.본 등록 특허는 모출원 특허(US 10755316)를 기초로 2020년 6월25일 계속 출원(US 16/912473)돼 미국 특허청에 의해 심사를 받았다. 모출원 특허(US 10755316)는 2016년 4월1일 출원(US 15/089464)된 후 2020년 8월25일 등록됐다.본 등록 특허는 온라인 시스템 사용자가 온라인 시스템에 의해 사용되는 특성을 수정해 사용자에게 프리젠테이션을 위한 콘텐츠를 선택하도록 허용하는 특허에 관한 것이다.본 등록 특허의 일 실시예에 따르면 온라인 시스템의 사용자에게 제시되는 콘텐츠는 사용자가 광고 콘텐츠를 사용자에게 제시하는 하나 이상의 이유, 사용자의 하나 이상의 특성을 볼 수 있게 하는 옵션과 함께 제시된다. 이때 타겟팅 기준을 충족하는 사용자의 하나 이상의 선택된 특성을 식별하는 설명이 콘텐츠와 함께 표시된다.온라인 시스템은 컨텐츠에 포함된 타겟팅 기준을 만족하는 사용자의 특성에 하나 이상의 룰을 적용해 컨텐츠와 함께 제시되는 하나 이상의 특성을 선택한다.상기 룰은 사용자가 특성, 온라인 시스템이 받는 수익, 사용자 간의 특성 보급 또는 콘텐츠의 타겟팅 기준을 가지고 있는지 여부를 결정하는 데 사용되는 모델의 정확성을 설명할 수 있다. 온라인 시스템은 다양한 특성을 식별하는 타겟팅 기준과 관련된 콘텐츠를 제시한다.
-
[기획-디지털 ID 기술] ㉝ 미네랄어쓰사이언스, '고고도 디지털 이미지의 시간적 시퀀스로부터 합성 고고도 디지털 이미지의 생성' 명칭의 미국 특허 등록 (US 11688036)미국 인공지능 및 인식 기술 기업 미네랄어쓰사이언스(MINERAL EARTH SCIENCES)에 따르면 '고고도 디지털 이미지의 시간적 시퀀스로부터 합성 고고도 디지털 이미지의 생성(Generation of synthetic high-elevation digital images from temporal sequences of high-elevation digital images)' 명칭의 미국 특허(US 11688036)가 등록됐다.본 등록 특허는 원출원 등록 특허(US 10891735) 및 계속출원 등록 특허(US 11501443)를 우선권 주장해 2022년 10월12일 계속 출원되어 미국 특허청에 의해 심사를 받았다.원출원 등록 특허(US 10891735)는 2018년 10월19일 가출원(US 62/748296)된 후 2019년 1월8일 본 출원(16/242873)돼 2021년 1월12일 등록됐다.계속출원 등록 특허(US 11501443)는 2020년 12월2일 원출원 등록(US 10891735)를 기초로 계속 출원되어 2022년 11월15일 등록됐다.본 등록 특허의 패밀리 특허로서 브라질 특허(BR 112021007417), 캐나다 특허(CA 3117082, CA 3117084), 미국 특허(US 2023-0140138, US 2023-0274391)가 심사 중이다. 유럽 특허(EP 3853767, EP 3853807), 미국 특허(US 10949972, US 11562486, US 11676244)가 등록됐다.본 등록 특허는 고고도 디지털 이미지로부터 일시적인 장애물을 검출/대체하고, 서로 다른 공간적, 시간적 및/또는 스펙트럼 해상도를 갖는 고고도 디지털 이미지의 데이터를 융합하는 특허에 관한 것이다.본 등록 특허의 일실시예에 따르면 지리적 영역을 캡쳐하는 고도 디지털 이미지의 제1 및 제2 시간적 시퀀스가 획득될 수 있다.이와 같은 시간적 시퀀스는 서로 다른 공간적, 시간적, 및/또는 스펙트럼 해상도(또는 주파수)를 가질 수 있다. 제2 시간 시퀀스의 고고도 디지털 이미지의 픽셀을 제1 시간 시퀀스의 각각의 서브 픽셀에 매핑할 수 있다.이 시점에 지리적 영역의 합성 고고도 디지털 이미지가 선택될 수 있다. 합성 고고도 디지털 이미지는 매핑 및 기타 데이터를 기반으로 특정 시점에 생성될 수 있다.
-
[기획-디지털 ID 기술] ㉜ 다임러, '차량의 적어도 하나의 드라이빙 환경 센서를 점검하기 위한 방법' 명칭의 미국 특허 등록 (US 11787424)독일 글로벌 자동차 제조업체 다임러(Daimler AG)에 따르면 2023년 10월17일 '차량의 적어도 하나의 드라이빙 환경 센서를 점검하기 위한 방법(Method for checking at least one driving environment sensor of a vehicle)' 명칭의 미국 특허(US 11787424)가 등록됐다.본 등록 특허는, 2018년 10월30일 원출원된 독일 특허(DE10-2018-127059)건을 기초로 2019년 9월26일 PCT 국제 출원(WO2020-088857)된 후 미국 국내단계에 진입되어 미국 특허청에 의해 심사를 받았다.본 등록 특허의 패밀리 특허로서 중국 특허(CN 112955775)가 심사 중이고, 독일 특허(DE10-2018-127059)도 심사를 받고 있다.본 등록 특허의 일 실시예에 따르면 차량은 디지털 지도상에 위치되고 차량의 환경은 드라이빙 환경 센서를 이용하여 감지된다.이때, 드라이빙 환경 센서에서 인식할 것으로 예상되는 차량 내 환경에 저장된 정지 물체의 특징은 디지털 지도에서 식별된다. 주행 환경 센서의 성능 저하는 하기의 경우에 추론된다.기대에 따라 인식되어야 할 특징이 드라이빙 환경 센서에 의해 인식되지 않는 경우이거나, 드라이빙 환경 센서에 의해 실제로 인식되는 특징이 기대에 따라 인식되는 특징으로부터 크게 벗어나는 경우이다.만약 인식이 예상되는 특징이 적어도 하나의 동적 객체에 의해 은닉되어 드라이빙 환경 센서에 의해 인식되지 않는 것으로 판단되면 드라이빙 환경 검출 센서의 열화는 추론되지 않는다.
-
[기획-디지털 ID 표준] ⑭산업단체와 포럼 - 오아시스(OASIS)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.구조화 정보 표준 개발기구(Organization for the Advancement of Structured Information Standards, OASIS)는 공급업체와 사용자의 컨소시엄으로 시작됐다.오늘날 사이버보안(cybersecurity), 블록체인(blockchain), 사물인터넷(internet of things, IoT), 비상 경영(emergency management), 클라우드 컴퓨팅(cloud computing) 등 프로젝트를 발전시키는 대규모 비영리 표준 조직이다.오아시스는 '디지털 서명 서비스 핵심 프로토콜, 요소, 바인딩'과 같은 디지털 서명과 관련된 프로토콜, 프로필 등 기술 사양을 개발해왔다.오아시스는 ISO에 협력하고 있는 조직으로 각 기술위원회(TC) 또는 분과위원회(SC)가 다루는 문제에 대해 기술위원회(TC) 또는 분과위원회(SC)의 업무에 효과적으로 기여하는 조직(A liaisons)이다.기여하고 있는 기술위원회 및 분과위원회는 다음과 같다.▷ISO/IEC JTC 1/SC 6 시스템 간 통신 및 정보 교환▷ISO/IEC JTC 1/SC 34 문서 설명 및 처리 언어▷ISO/IEC JTC 1/SC 38 클라우드 컴퓨팅 및 분산 플랫폼▷ISO/IEC JTC 1/SC 40 IT 서비스 관리 및 IT 거버넌스▷ISO/TC 12 수량 및 단위▷ISO/TC 37 언어 및 용어▷ISO/TC 37/SC 5 번역, 통역 및 관련 기술▷ISO/TC 46/SC 4 기술적 상호 운용성▷ISO/TC 154 상업, 산업 및 행정 분야의 프로세스, 데이터 요소 및 문서▷ISO/TC 184/SC 4 산업 데이터▷ISO/TC 211 지리정보/지리학또한 오아시스는 2005년 10월 21일 Working Draft 34에서 Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0을 발표했다.이후 2019년 12월 11일 'Digital Signature Service Core Protocols, Elements, and Bindings Version 2.0 Committee Specification 02'가 발표됐다.버전 2.0의 목차를 살펴보면 다음과 같다.■ 목차(Table of Contents) 1 Introduction 1.1 IPR Policy 1.2 Terminology 1.2.1 Terms and Definitions 1.2.2 Abbreviated Terms 1.3 Normative References 1.4 Non-Normative References 1.5 Typographical Conventions 1.6 DSS Overview (Non-normative) 2 Design Considerations 2.1 Version 2.0 goal [non-normative] 2.2 Transforming DSS 1.0 into 2.0 2.2.1 Circumventing xs:any 2.2.2 Substituting the mixed Schema Attribute 2.2.3 Introducing the NsPrefixMappingType Component 2.2.4 Imported XML schemes 2.2.5 Syntax variants 2.2.6 JSON Syntax Extensions 2.3 Construction Principles 2.3.1 Multi Syntax approach 2.4 Schema Organization and Namespaces 2.5 DSS Component Overview 2.5.1 Schema Extensions 3 Data Type Models 3.1 Boolean Model 3.2 Integer Model 3.3 String Model 3.4 Binary Data Model 3.5 URI Model 3.6 Unique Identifier Model 3.7 Date and Time Model 3.8 Lang Model 4 Data Structure Models 4.1 Data Structure Models defined in this document 4.1.1 Component NsPrefixMapping 4.1.1.1 NsPrefixMapping – JSON Syntax 4.1.1.2 NsPrefixMapping – XML Syntax 4.2 Data Structure Models defined in this document 4.2.1 Component InternationalString 4.2.1.1 InternationalString – JSON Syntax 4.2.1.2 InternationalString – XML Syntax 4.2.2 Component DigestInfo 4.2.2.1 DigestInfo – JSON Syntax 4.2.2.2 DigestInfo – XML Syntax 4.2.3 Component AttachmentReference 4.2.3.1 AttachmentReference – JSON Syntax 4.2.3.2 AttachmentReference – XML Syntax 4.2.4 Component Any 4.2.4.1 Any – JSON Syntax 4.2.4.2 Any – XML Syntax 4.2.5 Component Base64Data 4.2.5.1 Base64Data – JSON Syntax 4.2.5.2 Base64Data – XML Syntax 4.2.6 Component SignaturePtr 4.2.6.1 SignaturePtr – JSON Syntax 4.2.6.2 SignaturePtr – XML Syntax 4.2.7 Component Result 4.2.7.1 Result – JSON Syntax 4.2.7.2 Result – XML Syntax 4.2.8 Component OptionalInputs 4.2.8.1 OptionalInputs – JSON Syntax 4.2.8.2 OptionalInputs – XML Syntax 4.2.9 Component OptionalOutputs 4.2.9.1 OptionalOutputs – JSON Syntax 4.2.9.2 OptionalOutputs – XML Syntax 4.2.10 Component RequestBase 4.2.10.1 RequestBase – JSON Syntax 4.2.10.2 RequestBase – XML Syntax 4.2.11 Component ResponseBase 4.2.11.1 ResponseBase – JSON Syntax 4.2.11.2 ResponseBase – XML Syntax 4.3 Operation requests and responses 4.3.1 Component SignRequest 4.3.1.1 SignRequest – JSON Syntax 4.3.1.2 SignRequest – XML Syntax 4.3.2 Component SignResponse 4.3.2.1 SignResponse – JSON Syntax 4.3.2.2 SignResponse – XML Syntax 4.3.3 Component VerifyRequest 4.3.3.1 VerifyRequest – JSON Syntax 4.3.3.2 VerifyRequest – XML Syntax 4.3.4 Component VerifyResponse 4.3.4.1 VerifyResponse – JSON Syntax 4.3.4.2 VerifyResponse – XML Syntax 4.3.5 Component PendingRequest 4.3.5.1 PendingRequest – JSON Syntax 4.3.5.2 PendingRequest – XML Syntax 4.4 Optional data structures defined in this document 4.4.1 Component RequestID 4.4.1.1 RequestID – JSON Syntax 4.4.1.2 RequestID – XML Syntax 4.4.2 Component ResponseID 4.4.2.1 ResponseID – JSON Syntax 4.4.2.2 ResponseID – XML Syntax 4.4.3 Component OptionalInputsBase 4.4.3.1 OptionalInputsBase – JSON Syntax 4.4.3.2 OptionalInputsBase – XML Syntax 4.4.4 Component OptionalInputsSign 4.4.4.1 OptionalInputsSign – JSON Syntax 4.4.4.2 OptionalInputsSign – XML Syntax 4.4.5 Component OptionalInputsVerify 4.4.5.1 OptionalInputsVerify – JSON Syntax 4.4.5.2 OptionalInputsVerify – XML Syntax 4.4.6 Component OptionalOutputsBase 4.4.6.1 OptionalOutputsBase – JSON Syntax 4.4.6.2 OptionalOutputsBase – XML Syntax 4.4.7 Component OptionalOutputsSign 4.4.7.1 OptionalOutputsSign – JSON Syntax 4.4.7.2 OptionalOutputsSign – XML Syntax 4.4.8 Component OptionalOutputsVerify 4.4.8.1 OptionalOutputsVerify – JSON Syntax 4.4.8.2 OptionalOutputsVerify – XML Syntax 4.4.9 Component ClaimedIdentity 4.4.9.1 ClaimedIdentity – JSON Syntax 4.4.9.2 ClaimedIdentity – XML Syntax 4.4.10 Component Schemas 4.4.10.1 Schemas – JSON Syntax 4.4.10.2 Schemas – XML Syntax 4.4.11 Component IntendedAudience 4.4.11.1 IntendedAudience – JSON Syntax 4.4.11.2 IntendedAudience – XML Syntax 4.4.12 Component KeySelector 4.4.12.1 KeySelector – JSON Syntax 4.4.12.2 KeySelector – XML Syntax 4.4.13 Component X509Digest 4.4.13.1 X509Digest – JSON Syntax 4.4.13.2 X509Digest – XML Syntax 4.4.14 Component PropertiesHolder 4.4.14.1 PropertiesHolder – JSON Syntax 4.4.14.2 PropertiesHolder – XML Syntax 4.4.15 Component Properties 4.4.15.1 Properties – JSON Syntax 4.4.15.2 Properties – XML Syntax 4.4.16 Component Property 4.4.16.1 Property – JSON Syntax 4.4.16.2 Property – XML Syntax 4.4.17 Component IncludeObject 4.4.17.1 IncludeObject – JSON Syntax 4.4.17.2 IncludeObject – XML Syntax 4.4.18 Component SignaturePlacement 4.4.18.1 SignaturePlacement – JSON Syntax