KR20060015705A

KR20060015705A - 사용자 인터페이스 자동화 프레임워크 클래스 및 인터페이스

Info

Publication number: KR20060015705A
Application number: KR1020047010392A
Authority: KR
Inventors: 브랜단 맥케온; 로버트 신클레어; 패트릭치아 엠. 와고너; 폴 제이. 레이드; 마이클 에이. 프레드만; 해터 에스. 번즈
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-05-16
Filing date: 2003-05-17
Publication date: 2006-02-20
Also published as: RU2336557C2; EP1625494A2; CN1688970A; ZA200404790B; US7644367B2; MXPA04006404A; BR0306624A; CN101615122A; WO2004107164A2; JP2006526183A; CN101615122B; AU2003234590A1; WO2004107164A3; CN100538630C; RU2004119831A; US20040229200A1; CA2466184A1

Abstract

클라이언트에게 사용자 인터페이스 정보를 제공하는 방법 및 시스템이 설명된다. 이 방법 및 시스템은 액세스 가능 시스템(accessibility system)을 통해 클라이언트에게 사용자 인터페이스 정보를 제공하기 위한 한 세트의 애플리케이션 프로그램 인터페이스들을 구현한다. 액세스 가능 시스템은 제공자측으로부터 클라이언트측으로 사용자 인터페이스 정보를 전송하기 위한 메커니즘 및 사용자 인터페이스 정보를 선택적으로 보이는 논리 트리(logical tree)를 포함한다. 애플리케이션 프로그램 인터페이스 시스템은 사용자 인터페이스 정보 획득에 있어서 클라이언트를 돕기 위한 클라이언트측 애플리케이션 프로그램 인터페이스들을 포함한다. 클라이언트측 애플리케이션 프로그램 인터페이스들은 자동화 클래스(automation class), 논리 요소 클래스(logical element class), 미가공 요소 클래스(raw element class), 컨트롤 패턴 클래스들(control pattern class) 및 입력 클래스(input class)를 포함한다. 제공자측 애플리케이션 프로그램 인터페이스들은 제공자 자동화 클래스(provider automation class), 제공자 자동화 인터페이스(provider automation interface), 미가공 요소 인터페이스(raw element interface) 및 컨트롤 패턴 제공자 인터페이스(control pattern provider interface)를 포함한다.

클라이언트측 API, 제공자측 API, 액세스 가능 시스템, 논리 요소, 미가공 요소, 컨트롤 패턴, 자동화 클래스, 이벤트 메커니즘

Description

사용자 인터페이스 자동화 프레임워크 클래스 및 인터페이스{USER INTERFACE AUTOMATION FRAMEWORK CLASSES AND INTERFACES}

본 발명은 사용자 인터페이스 정보를 수집하는 보조 기술(Assistive Technology; AT), 자동화 테스팅, 그리고 기타 제품들의 분야 및 이들 제품의 사용자 인터페이스 정보와의 상호 작용에 관한 것이다.

AT 제품들은, 컴퓨터 소프트웨어 내에 포함되며 컴퓨터 소프트웨어에 의해 제공되는 정보에 대한 학습, 통신 및 액세스의 분야에서 도움을 필요로 하는 컴퓨터 사용자들을 돕기 위해 존재한다. 이들 제품은 컴퓨터 인터페이스에 관련된 정보를 필요로 한다. 이와 마찬가지로, 현존하는 자동화 테스팅 제품들 및 사용자 인터페이스 커맨딩(commanding) 유틸리티들 또한 사용자 인터페이스에 대한 정보를 필요로 한다. 현재, 이들 제품들은 사용자 인터페이스(UI) 정보의 충분한 소스가 없다. 이들 3가지 타입의 제품들(클라이언트들)은 이들이, (1) 애플리케이션의 사용자 인터페이스에 대한 정보를 모을 수 있게 하고, (2) UI를 만들기 위해 사용된 기술에 상관없이 UI 구성 요소들을 프로그램적으로 발견하고 문의할 수 있게 하며, (3) 키보드 및 프린터 입력을 생성할 수 있게 하고, (4) 어떤 타입의 행동(behavior) 또는 기능이 현재 이용 가능한 지를 알 수 있게 하기 위해, 다른 곳으로부터 필요한 지원을 받을 필요가 있다. AT 제품에 이러한 모든 능력을 제공하는 현재 이용 가능한 단일 기술은 없다. 더욱이, 현재의 AT 제품들은 모든 그래픽 운영 체제(OS) 기술들과 반드시 호환되는 것은 아니고, 중복된 통지 또는 혼동케 하는 통지를 중앙 집중 방식으로 필터링하고 조정하는 능력이 없다. 부가적인 단점은, 현재의 자동화 및 액세스 가능 인프라스트럭처(infrastructure)들은 확장 가능하지 않으므로, 새로운 기능을 추가하기 위해서는 OS 레벨의 변경들을 필요로 한다는 것이다.

더욱이, 현재, 애플리케이션의 사용자 인터페이스에 대한 정보를 모으기 위해, AT 제품은 애플리케이션에 특유한 코드를 기입해서 사용자를 위한 정보를 얻어야 한다. 이러한 애플리케이션에 특유한 코드를 기입하는 프로세스는 시간을 낭비하고, 계속적인 유지 보수를 필요로 한다. 현재의 자동화 인프라스트럭처는 또한 중복되거나 혼동케 하는 이벤트 통지들을 일관된 방식으로 필터링하고 조정하는 능력이 없다. 그러므로, 이벤트 소비자들은 정보를 독립적으로 필터링할 필요가 있다.

현재의 시스템은, AT 제품들이 (1) 데스크탑 상의 모든 것, (2) (워드 프로세서의 오프닝과 같은) 특정 프로세스, 또는 (3) 그 특정 프로세스 내의 스레드(thread)(그 프로세스 내에서 작업을 하는 다수의 객체들)의 세 개의 세분화된 레벨로 이벤트 통지들을 요청할 수 있도록 한다. 현재, 클라이언트가 이벤트를 수신할 때, 클라이언트는 그 이벤트가 발생했던 특정 윈도우에 대한 윈도우 핸들(handle), 및 그 이벤트가 어디서 발생했는지를 나타내기 위한 기타 정보 비트 들을 수신한다. 클라이언트는 이벤트에 관련된 UI 객체를 검색하기 위해 크로스 프로세스 호출(cross process call)을 할 수 있다. 이 객체에 대해, 클라이언트는 그 객체에 대한 정보를 요청하기 위해 추가적인 크로스 프로세스 호출들을 할 수 있다. 클라이언트가 5개의 정보를 필요로 한다면, 클라이언트는 5번의 크로스 프로세스 호출을 해야 한다. 크로스 프로세스 호출들은 매우 느리기 때문에, 현재 액세스 가능 인프라스트럭처(accessibility infrastructure)를 사용하여 UI 정보를 수집하는 수행 비용은 높다. 이러한 타입의 공지된 시나리오는 도 11에 도시되어 있다. 서버 애플리케이션(12)은 이벤트(6)를 발생시킨다. 커널(kernel)(14)은 어느 클라이언트가 통지 받아야 하는 지를 판정하고, 관계있는 클라이언트(10)에게 이벤트 통지(18)를 송신한다. 클라이언트(10)는 서버 애플리케이션(12)으로부터 프로세스 경계(2)를 지나 이벤트 통지(18)에 관련된 객체에 대한 요청(16)을 한다. 서버 애플리케이션(12)은 객체(20)를 반환하고, 그 후 클라이언트(10)는 이벤트를 발생시켰던 UI 컨트롤에 관한 정보에 대한 요청(16)의 송신을 시작할 수 있다. 서버 애플리케이션(12)은 프로세스 경계(2)를 지나 클라이언트(10)에게 요청된 정보(20)를 반환한다.

다른 현재의 옵션은 클라이언트 코드가 프로세스 내의 동적 링크 라이브러리(.DLL)로서 로딩(loading)될 수 있도록 한다. 이러한 옵션은 몇 가지 단점을 갖는다. 첫째, 이것은 클라이언트 코드를 프로세스 내로 로딩하기 위해서 시스템으로부터 협조를 필요로 한다. 둘째, 이것은, 일단 클라이언트 코드가 애플리케이션의 프로세스 내로 로딩되면, 클라이언트가 수집하는 정보를 제한하는 것은 곤란하기 때문에, 보안 문제를 야기한다. 셋째, 클라이언트에게 효과적인 기술이 되도록 하기 위해서는, 이것이 시스템 상의 모든 프로세스 내로 로딩되어야 한다. 최적으로는, 신뢰된 클라이언트들만이 다른 애플리케이션의 프로세스 내로 로딩되어야 한다.

더욱이, 클라이언트가 어떤 이벤트 통지를 수신하기를 원하는지를 지정하는 능력을 클라이언트에게 제공하는 시스템이 필요하게 된다. 공지된 시스템에서, 클라이언트는 다수의 크로스 프로세스 호출을 한 다음에, 정보를 분석해서 그것이 이벤트에 관계하고 있는 지를 판정할 필요가 있을 수 있다. 이러한 이벤트 필터링을 더욱 효율적인 방식으로 수행할 수 있고, 새로운 시스템 또는 애플리케이션 이벤트들을 지원하도록 용이하게 갱신될 수 있는 메커니즘이 필요하다. 더욱이, 보안 염려를 경감시키기 위해 신뢰된 컴포넌트들만을 사용하는 시스템이 필요하다.

현재, 사용자 인터페이스에 관한 정보를 찾는 경우, AT 제품은 특정 UI 프레임워크에 원시적인 트리(tree)들을 액세스할 필요가 있다. 따라서, 다수의 트리는 다수의 UI 프레임워크에 대한 사용자 인터페이스 정보를 전달할 필요가 있다. 이들 서로 다른 트리들은, 최종 사용자에 의해 조작되는 가시적 UI 컨트롤들을 관리하는 숨은 컨테이너 객체(hidden container object)들과 같은, 사용자에게 관계없거나 사용자에게 보이지 않는 정보를 포함할 수 있다. 그러므로, 사용자에게 관계있는 노드들만을 갖는 단일 통합 트리에 대한 필요성이 존재한다.

AT 제품들, 자동화 테스팅 툴들 및 커맨딩 유틸리티들의 요청을 다루는 해결책이 요구된다. 이러한 해결책은 모든 그래픽 OS 기술에 의해 사용될 수 있어야 되고, 모든 형태의 UI 및 UI 컴포넌트들이 액세스 가능하게 될 수 있도록 하여야 한다.

본 발명은 클라이언트에게 사용자 인터페이스 정보를 제공하기 위한 방법 및 컴퓨터 애플리케이션에 관한 것이다. 본 발명의 일 형태에 있어서, 클라이언트에게 사용자 인터페이스 정보를 제공하는 액세스 가능 시스템(accessibility system)에서 사용하기 위해 툴(tool)들의 시스템이 제공된다. 액세스 가능 시스템은 클라이언트측 및 제공자측을 포함한다. 툴들의 시스템은 사용자 인터페이스 정보를 찾기 위한 클라이언트 자동화 클래스(client automation class)를 포함하는 클라이언트측 자동화 툴(automation tool)들을 포함한다. 클라이언트 자동화 클래스는 이벤트 등록 툴들 및 논리 요소 발견 툴들을 포함한다. 툴들의 세트는 클라이언트에게 사용자 인터페이스 정보를 제공하기 위한 제공자측 자동화 툴들을 더 포함한다. 제공자측 자동화 툴들은 클라이언트에게 이벤트 정보를 제공하기 위한 툴들을 갖는 자동화 제공자 클래스(automation provider class)를 포함한다.

다른 형태에 있어서, 클라이언트측 툴들의 세트는, 제공자측으로부터의 사용자 인터페이스 이벤트 정보를 찾기 위한 클라이언트 자동화 클래스(client automation class)를 포함하는 클라이언트측 자동화 메커니즘, 및 논리 트리(logical tree)에서의 사용자 인터페이스 요소를 나타내기 위한 논리 요소 클래스(logical element class)를 포함하는 클라이언트측 논리 요소 메커니즘을 포함할 수 있다.

또 다른 부가적인 형태에 있어서, 제공자 툴들은, 클라이언트에게 이벤트 통지들을 제공하기 위한 툴들을 포함하는 제공자측 자동화 클래스, 및 사용자 인터페이스 특성(property)들을 노출시키기 위한 제공자측 자동화 인터페이스(automation interface)를 포함한다. 제공자측 툴들은 또한, 특정 상대 요소에 관련된 정보를 반환하기 위한 미가공 요소 인터페이스(raw element interface), 및 특정 요소에 관련되지 않은 기능 및 이벤트들을 관리하는 미가공 요소 컨텍스트 인터페이스(raw element context interface)를 포함한다.

부가적인 형태에 있어서, 본 발명은 액세스 가능 시스템을 통해 클라이언트에게 사용자 인터페이스 정보를 제공하기 위한 애플리케이션 프로그램 인터페이스 시스템을 포함한다. 액세스 가능 시스템은 사용자 인터페이스 정보를 제공자측에서 클라이언트측으로 전송하는 메커니즘, 및 사용자 인터페이스 정보를 선택적으로 보이기 위한 논리 트리를 포함한다. 애플리케이션 프로그램 인터페이스 시스템은, 사용자 인터페이스 정보를 획득하는데 있어서, 클라이언트를 돕기 위한 클라이언트측 애플리케이션 프로그램 인터페이스를 포함한다. 클라이언트측 애플리케이션 프로그램 인터페이스는 자동화 클래스, 논리 요소 클래스, 미가공 요소 클래스(raw element class), 컨트롤 패턴 클래스(control pattern class) 및 입력 클래스(input class)를 포함한다. 제공자측 애플리케이션 프로그램 인터페이스는 제공자 자동화 클래스, 제공자 자동화 인터페이스, 미가공 요소 인터페이스, 및 컨트롤 패턴 제공자 인터페이스를 포함한다.

부가적인 형태에 있어서, 본 발명은 액세스 가능 시스템을 통해 클라이언트 에게 사용자 인터페이스 정보를 제공하기 위한 컴퓨터 구현 방법을 포함한다. 이 방법은 사용자 인터페이스 정보를 획득하는데 있어서 클라이언트를 돕기 위한 클라이언트측 애플리케이션 프로그램 인터페이스를 제공하는 단계를 포함하는데, 클라이언트측 애플리케이션 프로그램 인터페이스는 자동화 클래스, 논리 요소 클래스, 미가공 요소 클래스, 컨트롤 패턴 클래스 및 입력 클래스를 포함한다. 이 방법은 또한, 클라이언트측 요청에 응답하기 위한 제공자측 애플리케이션 프로그램 인터페이스를 공급하는 단계를 포함하는데, 제공자측 애플리케이션 프로그램 인터페이스는 제공자 자동화 클래스, 제공자 자동화 인터페이스, 미가공 요소 인터페이스, 및 컨트롤 패턴 제공자 인터페이스를 포함한다.

또 다른 부가적인 형태에 있어서, 본 발명은 액세스 가능 시스템을 통해 클라이언트에게 사용자 인터페이스 정보를 제공하는 컴퓨터 구현 방법을 포함한다. 이 방법은 클라이언트 자동화 클래스로부터의 선택된 이벤트 핸들러(event handler)를 사용하여 사용자 인터페이스 정보를 요청하는 단계를 포함하고, 제공자가 대응하는 발생 이벤트 메소드(raise event method)를 사용하여 사용자 인터페이스 이벤트 통지들을 제공하기 위한 방법을 포함한다.

본 발명의 추가적인 장점들 및 새로운 특징들은 이하의 상세한 설명에서 설명될 것이며, 부분적으로는 다음의 상세한 설명의 검토시에 당해 기술 분야의 당업자에게 명백해지거나, 또는 본 발명의 실시에 의해 알 수 있게 된다.

도 1은 본 발명을 구현하는 경우, 사용하기에 적합한 컴퓨팅 시스템 환경의 블록도.

도 2는 액세스 가능 시스템, 클라이언트 환경 및 서버 환경 사이의 상호 작용의 블록도.

도 3은 액세스 가능 시스템 코어의 컴포넌트들을 나타낸 블록도.

도 4(a) 내지 도 4(d)는 원시 요소들로부터의 논리 트리의 생성을 나타낸 도면.

도 5는 논리 트리를 형성하기 위한 일련의 절차를 나타낸 흐름도.

도 6은 논리 요소들을 형성하는 다이얼로그 박스 및 그 컴포넌트들을 나타낸 도면.

도 7은 본 발명의 이벤트 메커니즘의 활성화에 관련된 절차들을 나타낸 흐름도.

도 8은 본 발명의 실시예에서의 클라이언트측 API들을 나타낸 블록도.

도 9는 본 발명의 실시예에서의 서버측 API들을 나타낸 블록도.

도 10은 본 발명의 액세스 가능 시스템의 실시예를 사용하는 클라이언트와 서버 간의 상호 작용을 나타낸 도면.

도 11은 이벤트 통지에 대한 공지된 시스템을 나타낸 도면.

이하, 첨부된 도면을 참조하여 본 발명에 대해 더욱 상세하게 설명한다.

예시적인 오퍼레이팅 환경

도 1은 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 예를 나타낸다. 컴퓨팅 시스템 환경(100)은 단지 적절한 컴퓨팅 환경의 일 예이며 본 발명의 사용 또는 기능의 범위에 제한을 가하도록 의도된 것은 아니다. 컴퓨팅 환경(100)은 예시적인 오퍼레이팅 환경(100)에 도시된 컴포넌트들 중의 임의의 하나 또는 조합에 관하여 임의의 종속성(dependency) 또는 요구사항(requirement)을 갖는 것으로 해석되어서는 안된다.

본 발명은 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령과 일반적으로 관련하여 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 더욱이, 당해 기술 분야의 당업자는 본 발명이, 핸드헬드(hand-held) 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 또는 프로그램가능한 가전제품(programmable consumer electronics), 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는 다른 컴퓨터 시스템 구성과 함께 실시될 수 있음을 이해할 것이다. 본 발명은 또한 통신 네트워크를 통해 링크된 원격 프로세싱 장치에 의해 태스크를 수행하는 분산형 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 국부 및 원격 컴퓨터 저장 매체 내에 위치할 수 있다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은, 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)를 포함하는 컴퓨터(110) 의 형태의 범용 컴퓨팅 장치를 포함한다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 시스템 메모리(130)는 ROM(131) 및 RAM(132)과 같은 휘발성 및/또는 비휘발성 메모리의 형태의 컴퓨터 저장 매체를 포함한다. 시동 중과 같은 때에 컴퓨터(110) 내의 구성 요소들간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133; BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 즉시 액세스될 수 있고 및/또는 프로세싱 유닛(120)에 의해 현재 작동되는 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, (한정하고자 하는 것은 아님) 도 1은 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시한다.

컴퓨터(110)는 또한 다른 착탈형/비착탈형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1에는 비착탈형 비휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(141), 착탈형 비휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광학 매체와 같은 착탈형 비휘발성 광학 디스크(156)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(155)가 도시되어 있다. 예시적인 오퍼레이팅 환경에서 사용될 수 있는 다른 착탈형/비착탈형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래시 메모리 카드, DVD(Digital versatile disk), 디지털 비디오 테이프, 고체 RAM, 고체 ROM 등을 포함하지만 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비착탈형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 착탈형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

앞서 기술되고 도 1에 도시된 드라이브 및 그 관련 컴퓨터 저장 매체는 컴퓨터(110)를 위한 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장 장소를 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이들 컴포넌트는 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다. 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 상이한 사본임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 일반적으로 마우스, 트랙볼, 또는 터치 패드라 불리우는 포인팅 장치(161) 및 키보드(162)와 같은 입력 장치를 통해 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. (도시되지 않은) 기타 입력 장치는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 입력 장치 및 그 외의 입력 장치는 대개 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 포트(USB)와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 타입의 디스플레이 장치는 또한 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터 외에도, 컴퓨터는 또한 출력 주변 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196)와 같은 기타 주변 출력 장치를 포함할 수 있다.

본 발명에서의 컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터일 수 있으며, 비록 도 1에는 메모리 저장 장치(181)만이 도시되어 있지만, 컴퓨터(110)에 관하여 상술한 구성 요소 중 다수 또는 모든 구성 요소를 일반적으로 포함할 수 있다. 도 1에 도시된 논리적 접속은 근거리 통신망(LAN; 171) 및 원거리 통신망(WAN; 173)을 포함하지만, 그 외의 네트워크를 포함할 수도 있다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 일반적으로 인터넷과 같은 WAN(173)을 통해 통신을 구축하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메커니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 예 로서 (한정하고자 하는 것은 아님), 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 도시한다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구축하는 다른 수단이 사용될 수 있다는 점이 인식될 것이다.

컴퓨터(110)의 다수의 다른 내부 컴포넌트들이 도시되지 않더라도, 당해 기술 분야의 당업자는 이러한 컴포넌트들 및 상호 접속은 잘 알려져 있다는 점을 인식할 것이다. 따라서, 컴퓨터(110)의 내부 구조에 관한 부가적인 세부 사항들은 본 발명과 관련하여 개시될 필요가 없다.

액세스 가능 시스템 구조

도 2에 도시된 바와 같이, 액세스 가능 시스템(accessibility system; 200)은 클라이언트 환경(300) 및 서버 환경(400)과 상호 작용한다. 액세스 가능 시스템(200)은 도 1과 관련하여 상술된 컴퓨터 환경(100)에서 구현될 수 있다. 액세스 가능 시스템(200)은 클라이언트(300)와의 상호 작용을 용이하게 하는 클라이언트측 액세스 가능 인터페이스(220), 서버측(400)과의 상호 작용을 용이하게 하는 서버측 액세스 가능 인터페이스(230), 및 액세스 가능 시스템 코어(201)를 포함한다. 본 발명의 액세스 가능 시스템(200)은 사용자 인터페이스(UI)를 프로그램적으로 액세스하기 위한 클라이언트측 애플리케이션 프로그램 인터페이스(Application Program Interface; API)들(305) 및 제공자측 API들(440)을 포함하는 새로운 API들을 제공한다. 액세스 가능 시스템(200)은, 애플리케이션들이 그들 자신, 및 그들이 사용하는 임의의 컴포넌트들을 액세스 가능하게 하도록 한다.

클라이언트 환경(300)은 바람직하게는 보조 기술(AT) 제품 또는 자동화된 UI 테스팅 툴을 포함한다. 서버측(400)은 도 2에 도시된 다양한 상이한 기술들을 구현할 수 있다. 서버 시스템(410)은 제1 타입의 UI에서 볼 수 있는 어댑터(412) 및 코어(414)를 포함한다. 서버 시스템(420)은 워싱턴 레이몬드에 있는 Microsoft 사의 Microsoft Operating System 제품들에서 이용 가능한 Win32 UI와 같은 제2 타입의 UI에서 볼 수 있는 프럭시(proxy) 컴포넌트(422) 및 컨트롤(424)을 포함한다. 서버 시스템(430)은 대안적인 제3 타입의 UI에서 볼 수 있는 어댑터(432) 및 내부 OM(434)을 포함한다.

도 3에 도시된 바와 같이, 액세스 가능 시스템(200) 내에 포함되는 이벤트 메커니즘(210)은 클라이언트 환경(300) 및 서버 환경(400)과의 상호 작용을 용이하게 하기 위해 UI 자동화 클라이언트(202) 및 UI 자동화 서버(204)에 의존한다. UI 자동화 클라이언트(202) 및 UI 자동화 서버(204)는 본 발명의 이벤트 메커니즘(210)과 관련하여 더욱 상세하게 후술된다. 본 발명의 액세스 가능 시스템(200)은 클라이언트(AT 제품)(300)에게, (1) 애플리케이션의 사용자 인터페이스에 관한 정보를 수집하는 능력, (2) UI를 만드는데 사용된 기술에 상관없이 UI 요소들을 프로그램적으로 발견하여 문의하는 능력, (3) 키보드 및 포인터 입력을 생성하는 능력, 및 (4) 어떤 타입의 행동 또는 기능이 현재 이용 가능한지를 알 수 있는 능력을 제공한다. 액세스 가능 시스템(200)은, 애플리케이션들이 그들 자신 및 그들의 컴포넌트들을 액세스 가능하게 한다. 도 2 및 도 3에 도시된 구조는 (1) 논리 UI 트리(logical UI tree), (2) 컨트롤 패턴들(Control Pattern), (3) 이 벤트 메커니즘(Event Mechanism), (4) 특성(property)들, 및 (5) 클라이언트 및 서버측 API들을 포함하는 액세스 가능 시스템(200)의 몇 가지 주요한 실시 형태들을 가능하게 하는데, 이하에서 이들 모두에 대해서 더욱 설명한다.

UI 액세스 논리 트리(222)

액세스 가능 시스템(200)의 필수 컴포넌트는 논리 트리(222)이고, 그 예는 도 4(d)에 도시되어 있다. 트리(222)는 클라이언트측 액세스 가능 인터페이스(220) 내에 포함된다.

논리 트리(222)는 UI 요소들의 근원적인 구조적 계층(structural hierarchy)의 필터링된 뷰이지, 컨트롤 또는 애플리케이션 개발자에 의해 구현되어야 하는 별도의 트리가 아니다. 그 대신에, 그것은 구조적 요소를 논리 트리(222)에 나타내야 하는지 여부를 나타내는, 소수의 잘 정의된 특성들(관계있는지 및 관계없는지 여부)을 조정한다. 액세스 가능 시스템 코어(201)는 이 정보를 필터링된 UI 논리 트리(222)를 생성하기 위해 사용하는데, 이 필터핑된 UI 논리 트리(222)는 AT 제품들 또는 테스트 스크립트(test script)에 차례로 제공된다.

논리 트리(222)는 요소들의 트리이며, 요소들의 각각은 컨트롤, 컨트롤 내의 아이템, 또는 다이얼로그, 창(pane) 또는 프레임일 수 있는 그룹핑 구조(grouping structure)를 나타낸다. 논리 트리(222)의 구조는 (컨트롤이 사실상 상이한 근본적인 구조를 사용하여 구현되더라도) 사용자에 의해 인지된 애플리케이션의 UI를 나타내야 한다. 트리는 시간에 걸쳐 안정적이어야 된다. 애플리케이션이 사용자에게 동일하게 보이는 한, 화면 뒤의 애플리케이션의 구현 세부 사항이 변경되었더 라도, 그 애플리케이션을 나타내는 논리 트리(222)는 여전히 동일한 상태를 유지하여야 한다. 구조상 및 구현상의 이유로 인해 존재하는, Microsoft OS 제품들 내의 셸(shell)의 "ShDocView" 윈도우와 같은 원시 요소들은, 사용자가 그들을 인지하지 못하기 때문에 이 트리 내에 나타나지 않아야 한다.

논리 트리(222)는, 복수의 상이한 프로세스가 클라이언트에게 동일하도록, 복수의 상이한 프로세스를 통합할 수 있는 복수의 단편들로부터 형성된 단일 트리이다. 논리 트리(222)는 대량(bulk) 검색을 가능하게 하며, 특성들의 리스트에 대한 값을 얻을 수 있다. 보통은 사용자가 값들을 요청하기 위해 크로스 프로세스 호출을 수행할 경우에, 액세스 가능 시스템(200)은 논리 트리(222)의 사용을 통해 그것들을 인출할 것이다.

공지된 시스템에서와 같이 한 단계로 구성되는 대신에, 논리 트리(222)는 미가공 트리(raw tree)를 형성하기 위해 사용되는 단편들로부터 구성된다. 도 5에 도시된 바와 같이, 3개의 주요 절차들이 논리 트리(222)를 형성한다. 절차(72)에서, 액세스 가능 시스템(200)은 근본적인 기술들의 원시 요소(native element)들을 알아내어, 도 4(a)에 도시된 원시 트리들을 형성한다. 절차(74)에서, 도 4(b)에 도시된 바와 같이, 액세스 가능 시스템(200)은 미가공 트리(20)를 형성하기 위해 원시 요소들을 결합한다. 최종적으로, 절차(76)에서는, 도 4(d)에 도시된 바와 같이, 미가공 트리(20) 내의 관계없는 컴포넌트들을 숨김으로써 논리 트리(222)가 얻어진다.

도 4(a)는 Win32 UI 또는 임의의 다른 이용 가능한 UI와 같은 근본적인 기술 들의 원시 요소들로부터 구성되는 2개의 원시 트리(10 및 14)를 나타낸다. 원시 트리(10)는 부모 노드(11), 및 서로 간에 다양한 관계를 갖는 복수의 자손(12)을 포함한다. 이와 마찬가지로, 원시 트리(14)는 복수의 자식 노드(16)를 갖는 부모 노드(15)를 포함한다. 자식 노드(16)들은 서로의 형제(sibling)로서 설명될 수 있다.

도 4(b)에 도시된 바와 같이, 원시 트리(10 및 14)는 미가공 트리(20)를 형성하기 위해 결합될 수 있다. 미가공 트리(20)는 2개의 자식 노드(22 및 30)를 갖는 부모 노드(21)를 포함한다. 자식 노드(22)는 자손(23 내지 29)을 가지며, 자식 노드(30)는 자손(31 내지 33)을 갖는다. 이 미가공 트리(20)는 원시 트리(10 및 14)의 결합인데, 원시 트리(10)의 노드들은 노드(22 내지 29)를 형성하고, 원시 트리(14)의 노드들은 노드(30 내지 33)를 형성한다.

도 4(c) 및 4(d)에 개괄적으로 도시된 방법을 통해, 미가공 트리(20)는 논리 트리(222)로 변환된다. 미가공 트리(20)에서 논리 트리(222)를 생성하기 위해, 개발자는 미가공 트리에 힌트를 삽입할 수 있다. 개발자는 미가공 트리(20) 내의 노드들을 "자신을 숨김" 또는 "자신 및 자식을 숨김" 또는 "노드의 자식을 숨김" 등으로 표시할 수 있다. 개발자는 또한 노드들을 옆쪽으로 이동시키거나 노드들을 자식 앞에 배치할 수 있다. 미가공 트리(20) 내에서의 이들 "힌트" 및 변경들은 논리 트리(222)를 형성하기 위해 사용된다. 예를 들어, 도 4(c)에서 블록(40 및 41)에 의해 지시된 바와 같이, 개발자는 미가공 트리(20)의 노드(24 내지 26 및 33)를 관계없는 것(uninteresting)으로 표시했다. 전형적으로, 사용자에게 가시 적이지 않을 요소들을 포함하는 노드들은 관계없는 것으로 표시된다. 가시적 UI에 관련된 노드들은 전형적으로 관계있는 것으로 간주되어, AT 클라이언트(300)가 사용하기 위한 논리 트리(222)에 포함될 것이다. 도 4(d)에 도시된 바와 같이, 관계없는 것으로 표시된 노드들은 논리 트리(222)에 포함되지 않는다.

액세스 가능 시스템(200)은 시스템의 상태, 객체들의 위치, 이벤트에 관한 정보 및 컨트롤에 관한 정보를 찾기 위해 논리 트리(222)를 사용한다. 공지된 시스템은 이들의 트리 내부를 살펴볼 수 있는 능력을 갖고 있지 않았다. 논리 트리(222)는 클라이언트(300)의 선호도에 기초하여 네비게이트팅될 수 있고, 사용 중인 서버측 애플리케이션에 상관없이 정보를 제공할 수 있다.

논리 트리(222)는, UI의 논리적 표현인 단일 통합 트리이고, 클라이언트(300)에 관계있는 요소들만을 포함하는 형태로 형성된다. 따라서, AT 제품들로 하여금 UI 요소들의 구조적 계층을 필터링하고 최종 사용자에게 제시되는 모델로 추정하게 하는 대신에, 논리 트리(222)는 최종 사용자에게 제시되는 구조에 근사하게 맵핑되는 계층을 제시한다. 이는, 사용자에게 UI를 기술하는 AT 제품들의 작업을 매우 단순하게 하고, 사용자가 애플리케이션과의 상호 작용하는 것을 돕는다.

이러한 논리 UI 트리(222)가 액세스 가능 시스템(200)의 기본적인 부분이기 때문에, 액세스 가능 시스템(200)의 다른 모든 컴포넌트들은 논리 트리(222)로부터 작업하도록 설계된다. 예를 들어, 도 6은 매우 단순한 구조를 갖는 것으로 보이는 단순한 다이얼로그 박스(60)를 도시한 것이다. 그러나, 현재 이용 가능한 액세스 가능 기술을 통해 볼 때, 이 다이얼로그 박스(60)의 구조는 이외로 복잡하다. 그것은, AT 제품이 최종 사용자에게 의미 있는 것들을 발견하기 위해 필터링해야 하는 264개의 객체들을 포함한다. 액세스 가능 시스템(200), 및 논리 UI 트리(222)에 대한 이 시스템의 지원에 의해, 이 다이얼로그 박스(60)를 소유하는 개발자는 도 6에 도시된 다음의 구조를 AT 제품(300)에 제시하기 위해 몇 가지 특성들을 설정할 수 있다.

도 6에 도시된 바와 같이, "Run" 다이얼로그의 경우, 개발자는 플라잉(flying) 윈도우 그래픽(62), 및 "Type the name of program, folder, document, or internet resource and windows will open it for you"(63)를 관계있는 것으로 나타낼 수 있다. 개발자는 또한 노트패드(notepad), 워드, 계산기 등을 포함하는 콤보 박스(64), 및 OK(65), 취소(cancel; 66) 및 브라우즈(browse; 67) 버튼들을 관계있는 것으로 나타낼 수 있다. 이것은, 요소 계층에 태깅(tagging)하고, 이로써 UI 액세스 가능 시스템(200)을 통해 이들의 애플리케이션의 UI에 관한 논리적 표현을 생성하는 저비용의 메커니즘을 개발자에게 제공한다. 도시된 특징들 각각은 논리 트리(222) 내의 각각의 다른 노드에 대해 특정 관계를 갖는 노드에 의해 표현될 수 있다. 이러한 논리적 표현은 테스팅 팀 및 AT 제품들 또는 클라이언트들(300)에게 직접적인 이점을 제공한다.

논리 트리(222)가 궁극적으로 사용자에게 관계있는 것이기는 하지만, 미가공 요소 트리(20) 또한 몇 가지 중요한 기능을 제공한다. 논리 트리(222)는 사용자에게 관련될 수 있는 요소들만을 포함하는 반면에, 미가공 요소 트리(20)는 근본적인 프레임워크의 구현 구조를 나타내는 노드(22)와 같은 노드들을 포함한다. 예를 들어, Win32 UI 단편에 대해, 이 트리는 HWND들을 나타내는 노드들을 포함할 것이다. 어떤 점에서, 미가공 요소 트리(20)는 논리 요소 트리(222)와 근본적인 프레임워크 고유의 원시 요소 트리들 사이의 "중간 하우스(half-way house)"이다. 미가공 요소 트리(20)는 논리 요소 트리(222)를 형성하는 토대로 사용되며, 원시 요소들이 시스템에 처음으로 접속되는 곳이다.

미가공 요소 트리(20)는 또한 디버깅 및 테스팅에 사용될 수 있다. 그것은 특정 문제 노드가 어디에 있는지를 정확히 지적하거나 기술하는데 유용하다. 기본 미가공 요소 노드 상에서의 기능은, 미가공 요소 트리를 네비게이팅하는 방법, (있다면) 대응하는 논리 요소로 점프하는 방법, 이 요소에 대한 '디버그 스트링(debug string)'(예컨대, HWND 노드에 대한 "HWND 0x483FE")을 포함하는 특성, 및 기타 '화면 뒤의 인프라스트럭처(behind the scenes infrastructure)' 방법들을 포함한다. 이들 기타 방법들은, 히트(hit) 테스팅 및 위치 선정, 이벤트들을 가능하게 하고, 프레임워크가 용이하게 제공할 수 있는 특성들(예컨대, 포커스드(focused), 인에이블드(enabled))의 노출을 가능하게 한다.

미가공 요소 트리(20)는 다양한 렌더링(rendering) 엔진으로부터의 요소들을 나타내는 노드(22 및 23)를 포함한다. 미가공 요소 트리는 렌더링 엔진들이 그들 자신을 액세스 가능 시스템(200) 내로 플러깅(plugging)하기 위한 시작점으로서 사용되며, Win32로부터의 HWND들과 같은 원시 요소들을 통합 논리 트리(222)로 개조하는 사소한 어댑터 객체들로부터 형성된다. 그것은 또한, 하나의 기술이 다른 기 술을 호스팅하는 호스팅 변환(hosting transition)을 처리하기 위해서도 사용된다. 미가공 요소 트리(20)는 논리 트리(222)가 형성되는 기초가 되기 때문에, 그것은 논리 트리(222)가 완성되어 연결되는 것을 검사하는데 사용될 수 있고, 설명되어 있지 않은 요소들에 대해 검사하기 위해 사용될 수 있다. 미가공 요소 트리(20)는 또한, 소정의 기본 요소 ID의 제공, 및 포커스드, 인에이블드 및 위치와 같은 소정의 기본 프레임워크 제공 요소 특성들의 제공과 같은 다른 인프라스트럭처와 같은 작업을 위해서도 사용될 수 있다.

미가공 요소 트리(20)는 AT 제품들 또는 클라이언트들(300)에 대한 1차적인 정보의 소스가 아니고, 논리 네비게이션을 위해 사용되지 않으며, 최종 사용자들에게 노출되지 않는다. 미가공 요소 트리(20)는 또한 어떤 장래의 시점에서 요소의 위치가 반환될 수 있도록 하기 위해 트리 내의 요소의 위치를 획득하는 데에 사용될 수 없다. 논리 요소 트리(222)가 이러한 모든 기능들을 수행한다.

전형적으로, 미가공 요소 트리(20)는, 표현되는 논리 요소에 관한 지식 없이 근원적인 렌더링 기술의 미가공 요소들(HWND, 요소(Element))로부터 기계적으로 형성될 수 있다. 그러므로, 그것은 논리 트리(222)에서 설명되지 않았던 미가공 요소들을 찾기 위해 사용될 수 있다. 미가공 트리(20)는, 노드 위치의 '스택 덤프(stack dump)'와 같은 설명이 획득될 수 있도록 하므로, 유용한 디버깅 및 진단(diagnostic) 툴이다. 더욱이, 공지된 시스템은 코드에 특유한 기준에 기초하여 이들의 트리를 형성하여, 다양한 기술들로 구현하기 곤란하다. 본 발명의 접근법은 임의의 근원적인 렌더링 기술에 의해 또는 그 기술을 위해 구현될 수 있는 일반 적인 추상적 '미가공 요소' 타입을 사용한다.

미가공 요소 트리를 얻기 위해, 미가공 요소 루트(root)를 호출하면 데스크탑 요소를 얻을 수 있는데, 미가공 요소 루트는, 그것의 부모가 NULL이고, 모든 다른 노드들이 그들의 근원적인 조상으로서 그것을 갖는다는 것을 확인함으로써 검증된다. 다른 요소들을 얻기 위해, 지정된 지점으로부터 미가공 요소를 얻기 위한 방법을 호출하면 유효한 스크린 좌표계를 사용하여 그 요소를 반환할 것이다. 미가공 요소 트리를 얻은 후에는, 요소들(부모들, 형제들 및 자식들)을 검사함으로써 그 미가공 요소 트리를 검사하고 검증할 수 있다.

동작에 있어서, 클라이언트(300)는 부모, 다음 형제, 이전 형제, 첫 번째 자식, 마지막 자식 등과 같은 관계를 사용하여 미가공 요소 트리(20)를 네비게이팅할 수 있다. 그 후, 클라이언트(300)는 미가공 요소로부터 논리 트리(222)에서의 대응 논리 요소로 점프할 수 있다.

이벤트 메커니즘

클라이언트(300)가 이벤트를 지속적으로 통보받고자 하는 경우에, 클라이언트(300)는 그 정보를 얻기 위해 도 3에 도시된 UI 자동화 클라이언트(UI automation client; 202)를 통해 등록할 수 있다. 클라이언트(300)는, 수신하기를 원하는 객체 정보, 그 정보가 가기를 원하는 장소, 반환받기를 원하는 특성들의 리스트를 명시한다. 클라이언트 요청은 UI 자동화 클라이언트(202)로 간다. UI 자동화 클라이언트(202)는 데스크탑 상의 임의의 프로세스를 모니터링할 수 있다. UI 자동화 서버(204)는, 어느 클라이언트(300)가 대기(listen)하고 있는지를 계속 추적하여, UI 자동화 클라이언트(202)에게로 반환하는 방법을 안다. UI 자동화 클라이언트(202)는 UI 엔진(206)에게 클라이언트 관심사를 보고하므로, UI 엔진(206)은 언제 이벤트를 UI 자동화 서버(204)에게 통보해야 하는지를 안다. UI 엔진은 클라이언트 보고를 이용할 필요는 없으며, 그 대신에, 항상 UI 자동화 서버(204)에게 이벤트들을 통지하거나, 클라이언트가 임의의 이벤트들에 대해 대기하고 있는 경우에만 UI 자동화 서버에게 통지하는 것으로 선택할 수 있다. 보고는, 이벤트들에 대해 대기하는 클라이언트가 있는 경우에만 UI 엔진이 UI 자동화 서버 통지를 작동시키기 원하는 경우에 유용하다. UI 엔진은 이렇게 함으로써, 있을 수 있는 UI의 속도 저하를 회피하고, 달리 필요로 하지 않는 코드 모듈들의 로딩을 회피한다.

그 다음, UI 엔진(206)은 UI 자동화 서버(204)에게 UI 이벤트를 통지한다. UI 자동화 서버(204)는 요청된 논리 요소를 클라이언트(300)에게 반환하고, 클라이언트(300)가 요청했던 이벤트의 특성을 포함하는 정보를 클라이언트(300)에게 송신한다. UI 자동화 서버(204)는 정보가 클라이언트 요청의 범위 내에 있는 지를 판정하여, 그 정보가 관계있는 경우에만 논리 요소를 형성한다. 논리 요소의 형성은 UI 자동화 서버측 상에서, 클라이언트가 이벤트를 처리할 때 사용할 것이라고 지시했던 특성들의 세트를 선인출(prefetching)하는 것을 포함한다. 예를 들어, UI 자동화 서버(204)는 콤보 박스에 대한 논리 요소를 발견할 수 있다. 범위는 콤보 박스 또는 그것의 자식이 될 것이다. 클라이언트(300)는 등록 단계 중에 범위를 정하기 위해 자식/부모/종속물들을 요청할 수 있다.

UI 자동화 서버(204)는 정보가 요청된 범위 내에 있는지 여부를 판정한 후에, 논리 요소를 형성한다. UI 자동화 클라이언트(202)는, UI 자동화 서버(204)로부터의 요청된 정보의 수신을 타겟 애플리케이션들에게 보고하고 객체들을 클라이언트(300) 상의 적절한 공간으로 라우팅함으로써 클라이언트(300)를 돕는다.

UI 자동화 서버(204)는, 클라이언트(300)가 이벤트 통지를 수신하기 위해 등록할 때 생성된다. 일례로서, UI 엔진(206)은 Microsoft Word 워드 프로세싱 애플리케이션을 실행하고 있다. 클라이언트(300)는 이름 특성 변경에 대해 등록한다. 클라이언트의 등록은 UI 자동화 서버(204)가 생성될 수 있도록 한다. 또한, 클라이언트의 등록은 UI 엔진(206)에게 이름 특성에 대해 UI 자동화 서버(204)에게 통지를 시작하라고 UI 엔진(206)에게 알려준다. UI 엔진(206)은 범위 정보를 얻지는 않는다. UI 엔진(206)은 서버측의 API들 중의 하나를 호출한다. UI 엔진(206)은 (1) 어떤 특성이 변경되는지, (2) 특성의 새로운 값, 및 (3) 아마도, 기존값을 명시한다. UI 자동화 서버(204)는 클라이언트(300)에 관계있는 이벤트들에 기초하여 생성되므로, 관계있는 이벤트들, 특성들, 클라이언트들 및 범위를 알고 있어서, 임의의 클라이언트(300)가 생성된 논리 요소에 관계하고 있는지를 안다. 만약 하나 보다 많은 클라이언트(300)가 특정 UI 자동화 서버(204)를 상대로 이벤트들에 대해 등록하였으며, 클라이언트들(300)이 동일한 이벤트에 대해 등록하고, 반환되는 논리 요소와 함께 대량 인출(bulk fetch)될 특성들을 요청했다면, UI 자동화 서버(204)가 클라이언트들(300)에게 이벤트를 다시 송신하는 경우, 각각의 클라이언트(300)는 논리 요소와 반환된 요청 대량 인출 특성들의 결합을 얻을 수 있다.

대기하고 있는 각 클라이언트(300)에 대해, UI 자동화 서버(204)는, 클라이언트에게 이벤트에 연관된 논리 요소를 전달함을 클라이언트(300)에게 통지한다. UI 자동화 서버(204)는 하나의 논리 요소만을 생성한다. 이것은 각 클라이언트(300)가 이벤트의 소스인 객체에 대한 자기 자신의 사본을 요청하라고 요구되는 현재의 기술보다 향상된 점이다.

만약 UI 엔진(206)이 클라이언트들이 이벤트들에 대해 등록할 때의 UI 자동화 클라이언트의 보고를 이용하지 않는다면, UI 엔진(206)은, UI 자동화 서버(204)에게, 대기하고 있는 임의의 액세스 가능 클라이언트들(300)이 있는지 물어보고, 하나도 없다면, 정보를 생성하여 그것을 UI 자동화 서버(206)에게 보내는 작업을 회피할 수 있다. 예를 들어, 스크린 독자는 클라이언트(300)이고, 정보가 가기를 원하는 장소, 이벤트들을 수신하는 포커스 변경 객체(focus change object), 및 관계있는 특성들의 특정 리스트를 명시한다. UI 엔진(206)은 보고받고, UI 자동화 서버(204)에게 이벤트들을 보내야 한다는 것을 안다. 포커스 변경의 검출 시에, UI 엔진(206)은 UI 자동화 서버(204)에게 통지한다. UI 자동화 서버(204)는 잘 알려진 인터페이스로 변환하여, 그 이벤트 및 객체를 UI 자동화 클라이언트(202)로 송신한다. UI 자동화 클라이언트(202)는 그 객체를 클라이언트(300) 상의 적절한 공간으로 라우팅한다.

상술된 컴포넌트들은 이벤트들에 대한 커널 내의 중앙 저장소를 제거함으로써 공지된 시스템보다 향상된다. 그 대신에, UI 자동화 서버(204)는 실행 중인 문맥에 대한 정보 획득에 관계있는 모든 클라이언트(300)를 안다. 커널 저장소의 제 거는 또한, UI 자동화 서버(204)가 이전에 커널에서 수행되는 기능을 수행하기 때문에, 더 많은 피어-투-피어(peer-to-peer) 상호 작용이 생기게 한다. 본 발명의 액세스 가능 시스템(200)은, 클라이언트(300)에게 클라이언트가 보고 싶은 것을 명시하는 능력을 제공하여, 필터링이 UI 자동화 서버(204)를 사용하여 서버측에서 달성되도록 한다.

도 7은 이벤트 등록 및 통지 방법에 관련된 절차들을 도시한 흐름도이다. 단계(80)에서, 클라이언트(300)는 이벤트 통지를 요청한다. 단계(82)에서, UI 자동화 클라이언트(202)는 UI 자동화 서버(204)에게 그 요청을 통신한다. 단계(84)에서, UI 자동화 클라이언트(202)는 통지를 원하고 있다는 것을 UI 엔진(206)에게 알려준다. 단계(86)에서, UI 자동화 서버(204)는 UI 엔진(206)으로부터 통지를 수신한다. 단계(88)에서, UI 자동화 서버(204)는 수신된 정보를 필터링한다. 만약 단계(90)에서, 수신된 정보가 사용자에게 관계없는 것으로 밝혀지면, UI 자동화 서버(204)는 그 정보를 폐기하고, 단계(92)에서 계속적으로 통지를 대기한다. 대안적으로, 단계(90)에서, 정보가 관계있는 것으로 밝혀지면, 단계(94)에서 UI 자동화 서버(204)는 논리 요소를 생성하여 그것을 UI 자동화 클라이언트(202)에게 송신한다. 단계(96)에서, UI 자동화 클라이언트(202)는 수신된 정보를 클라이언트(300) 상의 적절한 장소에 놓는다.

액세스 가능 시스템(200)의 이벤트 메커니즘(210)은, 클라이언트(300)로 하여금 UI에서의 특성 변경들, 컨트롤 구조에서의 트리 변경들, 멀티미디어 이벤트들 및 관련 정보에 대해 이벤트 통지들을 수신하기 위해 등록할 수 있게 한다. 이러 한 능력이 없다면, 클라이언트(300)는 임의의 정보, 구조 또는 상태가 변경되었는지 알아보기 위해 시스템에서의 모든 UI 요소들을 계속 폴링(polling)해야 한다. 액세스 가능 시스템(200) 이벤트 메커니즘은 또한 클라이언트(300)들로 하여금 프로세스 외의(out-of-process) 이벤트를 수신하고, 이벤트 통지와 함께 반환되어야 하는 특성들의 집합을 요청하며, 다수의 요소들에 관한 이벤트들에 대해 등록할 수 있게 한다.

이벤트 메커니즘(210)은, AT 제품 또는 테스트 애플리케이션이 이벤트들에 대해 등록하기 위해 사용하는 인터페이스들, AT 제품이 이벤트 통지를 수신하기 위해 사용되는 객체들에 대해 구현한 인터페이스들, 및 컨트롤 구현자들이 이벤트 엔진에게 UI 이벤트들을 통지하기 위해 사용하는 인터페이스들을 노출시킨다. 이벤트 메커니즘(210)은, AT 제품들 및 테스트 애플리케이션들이 UI를 렌더링하기 위해 사용된 UI 엔진에 상관없이 이벤트를 수신할 수 있게 하고, AT 제품들 및 테스트 애플리케이션들이 최상위 레벨의 애플리케이션 윈도우들 및 포커스를 근원적인 기술들에 상관없이 추적할 수 있게 하기 위해 사용된다.

적용 가능한 경우, 이벤트들은 애플리케이션의 논리 요소 트리(222)로부터의 논리 요소에 연관된다. 논리 요소들이 적용 가능하지 않는 경우, 이벤트들은 이벤트의 소스를 나타내는, 사람이 판독 가능한 스트링 또는 다른 널리 알려진 객체에 연관된다. 이벤트 메커니즘(210)은 이벤트 등록 중에 사용자가 공급한 선호도에 기초한 필터링을 제공한다. 서버에서 클라이언트의 필터링 선호도를 사용함으로써, 이벤트 관련 데이터를 생성하여 그 크로스 프로세스를 클라이언트에게 보내기 전에, 이벤트 메커니즘(210)은 크로스 프로세스 호출의 개수를 감소시킴으로써 프로세스 외의 성능을 본질적으로 향상시킨다. 이벤트 메커니즘(210)은 이벤트 등록중에 이벤트에 대해 관계하고 있는 논리 요소의 특성들을 명시하는 방식을 제공한다. 이것은 크로스 프로세스 호출의 개수를 더욱 감소시킨다. 이벤트 메커니즘(210)은 주요 운영 체제(OS) 변경을 필요로 하지 않으면서 확장 가능하다. 이벤트 메커니즘(210)이 관리된 코드(managed code)를 사용하여 구현될 수 있더라도, 관리되지 않은 애플리케이션(unmanaged application)은 COM 상호 운용성을 통해 그것을 액세스할 수 있다.

이벤트 메커니즘(210)은 클라이언트가 다수의 타입의 이벤트에 관해 지속적으로 통지 받도록 할 수 있다. 한 가지 타입의 이벤트는 최상위 레벨 윈도우 이벤트이다. 최상위 레벨 윈도우 이벤트들은 메뉴 및 콤보 박스 드롭다운(dropdown), 또는 부모로서의 데스크탑을 갖는 임의의 특징에 관련된 이벤트들을 포함한다. 다른 타입의 이벤트는 포커스 이벤트이다. 클라이언트(300)는 대개 포커스를 추적하는 메소드를 필요로 한다. 부가적인 타입들의 이벤트들은 특성 변경 이벤트들(property change event) 및 논리 구조 변경 이벤트(logical structure change event)들을 포함한다. 특성 변경 이벤트들은 논리 요소들의 특성들이 변경될 때 발생된다. 논리 구조 변경 이벤트들은 논리 요소 트리 구조가 변경될 때 발생된다.

이벤트들은 또한 컨트롤 패턴들로부터 발생될 수 있다. 컨트롤 패턴들로부터 발생된 이벤트들은 확대 가능하게 될 필요가 있으므로, 이들 이벤트들은 GUID에 의해 식별된다. 임의의 GUID 값은 등록할 때 수용된다. 임의의 새로운 컨트롤 패턴에 대해, 그것이 제공하는 이벤트들은 유일한 GUID들이 될 필요가 있다. AT 제품들은 새로운 컨트롤 패턴 이벤트들을 대기하기 위해 수정될 필요가 있을 수 있다. 또한 대기자(listener)는 이들 이벤트들의 범위를 정할 수 있어야 한다. 예를 들어, 명령된 테스팅은 이들 이벤트들을 특정 애플리케이션 또는 애플리케이션 내의 특정 컨트롤로 제한하기를 원할 수 있다. 컨트롤 패턴은 소스가 무엇인지 정의하고, 이벤트 소비자들은 소스 요소(source element) 및 이벤트 인수 객체(event argument object)의 사용법을 알기 위해 그 기록의 일부를 참조할 필요가 있을 것이다.

다른 타입의 이벤트는 멀티미디어 이벤트이다. 멀티미디어는 사운드, 비디오 및 애니메이션을 포함할 수 있다. 메소드들은 멀티미디어 이벤트들을 지원하고, "정지(stopped)", "일시정지(paused)", "고속감기(fastforwarded)", "되감기(rewound)", "무음(muted)"을 포함하는 동작들을 클라이언트에게 통지할 것이다. 단순한 사운드 이벤트들은 멀티미디어 이벤트들과 별도로 처리될 수 있다. 단순한 사운드 이벤트는, 사운드 자체 이외의 소정의 이벤트를 사용자에게 전달하기 위해 존재하는, 단순하며 길이가 짧은 사운드를 나타낸다. 단순한 사운드 이벤트들은 새로운 메일이 도착했을 때 나오는 사운드, 랩탑 상의 배터리가 부족할 때 발생되는 사운드, 또는 메시지 박스가 IconExclamation형으로 표시될 때 나오는 사운드를 포함할 수 있다.

다른 타입의 이벤트는 소프트 포커스(soft focus) 이벤트이다. 소프트 포커 스 이벤트들은 데스크탑 상에 나타나지만, 백그라운드에 머문다. 소프트 포커스 이벤트들의 몇몇 예들은, 통지 영역(notification area) 내에서 "새로운 갱신이 이용 가능하다"는 것을 나타내는 벌룬 헬프 윈도우(balloon help window), 포커스를 얻기를 원하는 백그라운드 애플리케이션에 대한 태스크바(task bar)에서의 플래싱(flashing) 아이콘, 및 프린팅 개시 및 종료 시에 통지 트레이(notification tray)로부터 나타나고 사라지는 프린터 아이콘이 있다. 이들 이벤트들은 다른 이벤트 카테고리들과 다소 중첩되는 것으로 보일 수 있다(멀티미디어는 소프트 포커스와 마찬가지로 애니메이션 이벤트들을 포함할 수 있음). 그러나, 이벤트는 어떻게 전달되는지 보다는 사용자에게 무엇을 전달하는지에 기초하여 분류될 것이다.

클라이언트측 API(310) 및 제공자측 API(440)는 앞서 열거된 타입들의 이벤트들을 지원하는 이벤트 통지를 위한 메소드들을 제공한다. 이들 메소드들은 도 8 내지 도 10과 관련하여 이하에서 더욱 설명될 것이다.

컨트롤 패턴들

액세스 가능 모델은 특정 UI 요소 또는 컨트롤에 의해 지원된 기능을 분류하고 노출하는 유일한 접근법을 제공한다. 종래 기술에서와 같이 기능을 특정 컨트롤 타입(예컨대, 버튼, 편집 박스, 또는 리스트 박스)과 연관시키는 대신에, 액세스 가능 모델은 한 세트의 공통 컨트롤 패턴들을 정의하는데, 이들 각각은 UI 행동의 일 형태를 정의한다. 이들 패턴들은 서로 독립적이기 때문에, 특정 UI 요소에 의해 지원된 기능의 완전한 세트를 기술하기 위해 결합될 수 있다.

예를 들어, Button과 같은 클래스 이름에 의해 요소를 기술하는 대신에, 액 세스 가능 시스템(20)은 호출 가능한 컨트롤 패턴(invokable control pattern)을 지원하는 것으로서 요소를 기술한다. 컨트롤 패턴은 요소에 의해 지원되는 구조, 특성, 이벤트 및 메소드를 정의한다. 그러므로, 이들 패턴은 클라이언트가 컨트롤의 행동을 질의할 수 있게 할 뿐만 아니라, 특정 패턴으로 설계된 인터페이스들을 사용함으로써 컨트롤을 프로그램적으로 조작할 수 있게 한다. 예를 들어, 선택 컨테이너(SelectionContainer) 패턴은, 선택된 아이템에 대해 질의하거나, 특정 아이템을 선택 또는 선택 해제하거나, 컨트롤이 단일의 또는 다수의 선택 모드를 지원하는 지를 판정하기 위한 메소드들을 제공한다.

액세스 가능 시스템(300)을 위해 현재 정의된 컨트롤 패턴들은 (1) 선택 컨테이너, (2) 계층(Hierarchy), (3) 호출 가능(Invokable), (4) 단순 그리드(Simple Grid), (5) 텍스트(Text), (6) 값(Value), (7) 객체 표현(Represents Object), (8) 스크롤 가능(Scrollable), (9) 소트 가능(Sortable), (10) 드로잉(Drawing), 및 (11) 그 밖의 컨테이너(Other Container)를 포함한다.

이러한 기술은, 컨트롤 개발자들로 하여금 AT 제품들 및 테스트 스크립트들에게 새로운 타입의 컨트롤의 행동을 노출시키기 위한 잘 정의된 접근법을 여전히 가지면서, 새로운 타입의 컨트롤을 구현할 수 있게 한다. 새로운 타입의 행동이 도입되면, 새로운 컨트롤 패턴이 요구된 기능을 표현하기 위해 정의될 수 있다.

이제, 보조 기술 제품들 및 테스트 스크립트들은 각각의 UI 컨트롤 대신에 각각의 패턴으로 작업하는 방법을 이해하도록 작성될 수 있다. 컨트롤 클래스들보다 훨씬 적은 컨트롤 패턴들이 있기 때문에, 이러한 기술은 필요한 코드를 최소화 한다. 또한 이러한 접근법은 (새로운 컨트롤들이 공지된 컨트롤 패턴들을 지원하는 한) 새로운 컨트롤들을 효율적으로 문의하고 조작할 수 있는 보다 유연한 아키텍처가 되도록 한다.

다음의 표는 공통 컨트롤 및 그 공통 컨트롤이 지원할 패턴의 몇 가지 예들을 제공한다.

컨트롤	관련 컨트롤 패턴
버튼	호출가능
체크박스, 라디오버튼	값
리스트박스	선택 컨테이너, 스크롤 가능
콤보박스	선택 컨테이너, 스크롤 가능, 값
트리 뷰	선택 컨테이너, 스크롤 가능, 계층
리스트 뷰	선택 컨테이너, 스크롤 가능, 소트 가능
텍스트 박스, 편집	값, 텍스트, 스크롤가능

더욱 특정한 인터페이스들이 공통 컨트롤 패턴들과 연관된 기능을 노출시키기 위해 사용될 것이다. 이들 패턴의 예는, (1) 선택 관리 컨테이너(selection managing container), (2) 그리드 레이아웃 컨테이너(grid layout container), (3) 값을 포함하는 UI 요소, (4) 객체(파일, 이메일 등)를 표현하는 아이콘, 및 (5) 호출될 수 있는 UI 요소를 포함한다. 일반적으로, 이들 패턴들은 특정 컨트롤에 엄격하게 한정되지 않으며, 상이한 컨트롤들이 동일한 패턴을 구현할 수 있다. 예를 들어, 리스트 박스(listbox), 콤보 박스(combo box) 및 트리 뷰(treeview)는 모두 '선택 관리 컨테이너' 패턴을 구현할 수 있다. 몇몇 컨트롤들은, 적절한 경우에 다수의 패턴을 구현할 수 있는데, 선택 그리드(selection grid)는 '그리드 레이아웃 컨테이너' 패턴 및 '선택 관리 컨테이너' 패턴 모두를 구현할 수 있다.

이전의 애플리케이션에서와 같이 하나의 '역할(role)'의 특성은 존재하지 않는다. 그 대신에, 2개의 분리된 메커니즘이 사용된다. 컨트롤 패턴들은 컨트롤의 이용 가능한 기능을 결정하고, 사람이 판독할 수 있는 국소화 가능 특성은 '버튼', '리스트 박스' 등과 같이 사용자가 이해할 수 있는 컨트롤 타입 이름을 제공한다.

시스템 API

도 8은 본 발명의 실시예에서 클라이언트측 API(305)의 상세를 나타낸다. 클라이언트측 API(305)는 한 세트의 코어 클래스(310)를 포함할 수 있다. 코어 클래스(310)는 하나 이상의 자동화 클래스(automation class, 312), 논리 요소 클래스(logical element class, 314) 및 미가공 요소 클래스(raw element class, 316)를 포함할 수 있다. 클라이언트측 API(305)는 또한 하나 이상의 컨트롤 패턴 클래스(control pattern class, 320), 입력 클래스(input class, 340) 및 보조 클래스(auxiliary class, 350)를 포함할 수 있다. 이들 타입의 클래스의 각각은 이하 더욱 설명된다.

클라이언트 자동화 클래스(312)는 UI 자동화 메소드를 클라이언트(300)에게 제공한다. 클라이언트 자동화 클래스(312)는 임의의 UI 요소에 특유하지 않은 메소드를 포함한다. 클라이언트 자동화 클래스(312)는 포인트, 윈도우 핸들 또는 데스크탑 루트 요소로부터 논리 또는 미가공 요소를 얻기 위한 메소드를 제공한다. 클라이언트 자동화 클래스(312)는 또한 논리 요소 기반 입력 기준을 찾기 위한 메소드를 제공할 수 있다. 클라이언트 자동화 클래스(312)는 또한 바람직하게는 이벤트 통지에 대한 등록 및 등록 해제를 위한 메소드를 포함한다. 자동화 클래스(312)는 또한 바람직하게는, 프럭시 DLL을 로딩하고, 특성 및 컨트롤 패턴의 국소화된 이름을 검색하며, 요소 비교를 수행하기 위한 헬퍼(helper) 함수를 제공한다. 클라이언트 자동화 클래스(312)는 또한 클라이언트(300)가 이벤트들을 대기하기 위한 메소드를 포함한다. 자동화 클래스(312)에 의해 제공된 몇 가지 메소드들은 이하의 표에 요약된다.

동작에 있어서, 만약 클라이언트(300)가 애플리케이션에 대한 사용자를 위한 정보를 얻을 필요가 있다면, 클라이언트(300)는 누름 버튼을 찾아, 그 버튼 상의 텍스트를 주시한다. 클라이언트(300)는 표 2에서 앞서 도시된 논리 요소를 찾기 위한 메소드(FindLogicalElement)와 같은 메소드를 호출할 수 있다. 클라이언트측 API(305)는 클라이언트측 인터페이스(220)의 논리 트리(222)에서의 위치에 관련된 값을 반환할 것이다. 논리 트리(222)를 통해, 액세스 가능 시스템(200)은 사용 중인 애플리케이션에 상관없이 UI의 추상 뷰를 클라이언트(300)에게 제공한다. 추상 모델은, 리스트 박스, 버튼 또는 다른 UI 컴포넌트가 서로 공통으로 갖는 것으로 기대할 수 있는 구조, 특성, 이벤트 및 기능을 포함한다.

클라이언트측 API(305)는 또한 논리 요소 클래스(314)를 포함할 수 있다. 논리 요소 클래스(314)는 요소들의 공통 특성들을 얻기 위한 필드, 메소드 및 특성을 제공할 수 있다. 상술된 바와 같이, 논리 요소는 바운딩 사각형(bounding rectangle), 포커스, 인에이블드, 클릭 가능 포인트, 런타임 및 지속(persistent) 식별자, 및 이름과 같은, 논리 트리(222)에서의 UI 요소를 나타낸다. 논리 요소 클래스(314)는 또한 첫째 자식, 마지막 자식, 다음 형제 및 부모와 같은 요소들 사이에서의 네비게이팅을 위한 툴들을 제공할 수 있다. 논리 요소 클래스(314)는 또한 요소에 대한 특정 패턴을 얻거나 또는 그 요소에 의해 지원되는 모든 패턴들을 얻기 위한 툴들을 제공할 수 있다. 논리 요소 클래스(314)는 논리 요소 트리(222)에서의 요소에 대해 사용되는 필드, 특성 및 메소드를 포함한다.

클라이언트측 API(305)는 또한 미가공 요소 클래스(316)를 포함할 수 있다. 미가공 요소 클래스(316)는 미가공 요소 트리를 순회하기 위해 유사한 기술들을 제공한다. 미가공 요소 클래스(316)는 미가공 요소 트리에서의 요소를 액세스하는데 사용되는 필드, 특성 및 메소드를 포함한다.

클라이언트측 API(305)는 또한 입력 클래스(340)를 포함한다. 입력 클래스(340)는 마우스, 키보드 및 다른 타입들의 입력을 시뮬레이팅하는데 사용될 수 있다. 입력 클래스는 키보드, 펜 및 마우스와 같은 입력 방법을 통한, 프로그램에 따른 입력을 가능하게 한다. 예시적인 입력 클래스는 이하의 표에 표시된다.

클라이언트측 API(305)는 또한 UI 자동화 컨트롤 패턴 클래스(320)를 포함한다. UI 자동화 컨트롤 패턴 클래스(320)는 논리 요소에 의해 노출된 특정 기능에의 프로그램에 따른 액세스를 위한 필드, 특성 및 메소드를 노출시킬 수 있다. UI 자동화 컨트롤 패턴 클래스(320)는 UI 액세스 가능 시스템(200) 내에 정의된 컨트롤 패턴과 상호 작용하도록 사용자를 돕는다. 예를 들어, 애플리케이션 윈도우 패턴 메소드는 애플리케이션과 함께 프로그램적으로 작업하기 위한 기능을 노출시킨 다. 그 기능은 자식 윈도우들을 정렬할 수 있게 하거나, 또는 애플리케이션 내의 툴바, 메뉴, 스크롤바, 및 시스템 메뉴를 나타내는 논리 요소의 위치를 알아낼 수 있게 할 수 있다.

컨트롤 패턴 클래스(320)는 애플리케이션 윈도우 패턴(ApplicationWindowPattern) 클래스를 포함할 수 있다. ApplicationWindowPattern 클래스는 전형적으로 최상위 레벨 애플리케이션 윈도우에 연관된 행동 및 정보를 노출시킨다. 클라이언트(300)는 이 클래스를 사용해서, 애플리케이션의 다중 문서 인터페이스(multiple document interface; MDI) 자식을 타일링(tiling) 또는 캐스케이딩(cascading)하고, 태스크바 상에서 그것의 버튼을 찾고, 툴바 및 메뉴와 같은 그것의 사용자 인터페이스의 잘 알려진 섹션들의 위치를 알아낼 수 있다. 다음 표는 본 발명의 실시예의 ApplicationWindowPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한 이들의 컨텐트를 보이고 숨기는 메커니즘을 제공하는 요소들을 확대하고 및 축약하기 위한 클래스(ExpandCollapsePattern)를 포함할 수 있다. ExpandCollapsePattern 클래스는 ExpandCollapse 패턴을 위한 래퍼(wrapper) 클래스로서 기능한다. ExpandCollapsePattern 클래스는 확대되거나(표시되거나) 또는 축약될 수 있는(숨겨질 수 있는) 컨텐트를 조작하기 위해 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 ExpandCollapsePattern 클래스의 실시예를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한, 발견된 아이템이 그리드의 일부인지를 클라이언트가(300)가 신속히 판정할 수 있게 하는 그리드 아이템 패턴(GridItemPattern) 클래스를 포함할 수 있다. 만약 아이템이 그리드의 일부분이라면, GridItemPattern 클래스는, 아이템이 행/열 좌표 및 범위에 관하여 그리드 내에 있는지 판정하는 것을 돕는다. GridItemPattern 클래스는 바람직하게는 그리드 내의 셀의 기능을 노출시키는 컨트롤을 조작하기 위해 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 GridItemPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한 트리 뷰(TreeView) 컨트롤 내의 요소들과 같은, 서로에 대한 계층 관계를 갖는 요소들을 표현하는 계층 아이템 패턴(HierarchyItemPattern) 클래스를 포함할 수 있다. HierarchyItemPattern 클래스는 논리 트리(222) 내에서의 이들의 관계에 상관없이 UI 요소들간의 계층 관계를 노출시키는 컨트롤을 조작하기 위해 자동화 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 HierarchyItemPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한, 객체들에 연관된 하나의 명백한 동작을 갖는 객체들을 나타내는 인보크 패턴(InvokePattern) 클래스를 포함할 수 있다. 관 련 UI 컴포넌트들의 예는, 푸시 버튼, 하이퍼링크, 메뉴 아이템, 라디오 버튼, 및 체크 박스를 포함한다. InvokePattern 클래스는, 호출될 때 하나의 명백한 동작이 발생되도록 하는 요소를 조작하기 위해 자동화 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 예시적인 InvokePattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한 다중 뷰 패턴 요소를 위한 래퍼 클래스로서 기능하는 다중 뷰 패턴(MultipleViewPattern) 클래스를 포함할 수 있다. 다중 뷰 패턴 요소는 하나의 정보 세트(information set)의 다수의 표현들 사이에서 전환할 수 있는 요소이다. MultipleViewPattern 클래스는 동일한 정보 세트의 다수의 표현들 사이에서 전환하기 위한 기능을 갖는 요소를 조작하기 위해 자동화 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 MultipleViewPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한, 유한 범위 내의 값을 관리하는 컨트롤의 능력을 반영하는 특성들의 관련 세트를 노출시키는 범위 값 패턴(RangeValuePattern) 클래스를 포함할 수 있다. RangeValuePattern 클래스는 컨트롤의 유효 최소 및 최대 값과 그것의 현재 값을 전달한다. RangeValuePattern 클래스는 요소의 현재 값 및 값의 범위를 얻기 위해 자동화 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 RangeValuePattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한, 요소들의 볼 수 있는 영역을 변경할 수 있는 UI 요소들을 나타내는 스크롤 패턴(ScrollPattern) 클래스를 포함할 수 있다. ScrollPattern 클래스는 스크롤링에 의해 보이는 영역의 부분을 변경하는 능력을 갖는 요소를 조작하기 위해 자동화 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 ScrollPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한 선택을 관리하는 컨테이너들을 나타내는 선택 패턴(SelectionPattern) 클래스를 포함할 수 있다. 관련 선택 아이템 패턴(SelectionItemPattern) 클래스는 선택 및 선택 해제될 수 있는 요소를 조작하기 위해 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 예시적인 SelectionPattern 클래스 및 SelectionItemPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한, 소트 패턴(SortPattern) 클래스를 포함할 수 있다. SortPattern 클래스는 컨테이너 요소의 서브 요소(sub element)를 정렬할 수 있는 컨테이너 요소를 조작하기 위해 자동화 클라이언트에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 SortPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한 값을 표현하는 UI 요소들을 나타내기 위한 값 패턴(ValuePattern) 클래스를 포함할 수 있다. ValuePattern 클래스는 요소에 연관된 값을 갖는 요소를 조작하기 위해 클라이언트(300)에 의해 사용될 수 있는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 ValuePattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 사용자에게 정보를 전달하고 있는 이미지 또는 애니메이션에 관한 정보를 표현하는데 사용될 수 있는 가시 정보 패턴(VisualInformationPattern) 클래스를 더 포함할 수 있다. VisualInformationPattern 클래스는 사용자에게 정보를 전달하고 있는 이미지 또는 애니메이션을 갖는 요소를 조작하기 위해 자동화 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 VisualInformationPattern 클래스를 나타낸 것이다.

컨트롤 패턴 클래스(320)는 또한 윈도우 패턴에 대한 래퍼 클래스로서 기능하는 윈도우 패턴(WindowPattern) 클래스를 포함할 수 있다. WindowPattern 클래스는 사용자의 데스크탑 상의 윈도우를 조작하기 위해 자동화 클라이언트(300)에 의해 사용되는 필드, 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 WindowPattern 클래스를 나타낸 것이다.

클라이언트측 API(300)는 또한 보조 클래스(auxiliary class; 350)를 포함할 수 있다. 보조 클래스는 이벤트 메커니즘 및 입력 특징을 사용하기 위한 헬퍼 클래스뿐만 아니라 특성, 이벤트 및 패턴 식별자를 나타내는 복수의 클래스를 포함할 수 있다.

보조 클래스(350)는 자동화 식별자(AutomationIdentifier) 클래스를 포함할 수 있다. AutomationIdentifier 클래스는 객체 신원 기반의 식별자(object identity-based identifier)에 대한 베이스 클래스이다. 이 클래스는 파생 클래스들만이 인스턴스화되기 때문에 사실상 추상화된다. 보조 클래스(350)는 또한, 액세스 가능 시스템(200)에서의 이벤트들을 식별하기 위해 사용되는 타입을 나타내는 자동화 이벤트(AutomationEvent) 클래스를 포함할 수 있다. 보조 클래스(350)는 또한, 액세스 가능 시스템(200)에서의 컨트롤 패턴들을 식별하기 위해 사용되는 타 입을 나타내는 자동화 패턴(AutomationPattern) 클래스를 포함할 수 있다. 보조 클래스(350)는 또한, 액세스 가능 시스템(200)에서의 특성들을 식별하기 위해 사용되는 타입을 나타내는 자동화 특성(AutomationProperty) 클래스를 포함할 수 있다.

보조 클래스(350)는 이벤트와 함께 사용되는 커스텀 이벤트 인수(custom event argument) 또는 컨트롤 패턴을 나타내는 자동화 이벤트 인수(AutomationEventArgs) 클래스를 더 포함할 수 있다. 클라이언트(300)는 커스텀 이벤트와 함께 이 클래스의 인스턴스를 수신한다. AutomationEventArgs는 클라이언트(300)에게 자동화 이벤트에 관한 정보를 전달하기 위해 사용된다.

보조 클래스(350)는 또한, UI 이벤트들과 함께 사용되는 자동화 특성 변경 이벤트 인수(AutomationPropertyChangedEventArgs) 클래스를 포함할 수 있다. 클라이언트(300)는 특성 변경 이벤트와 함께 이 클래스의 인스턴스를 수신한다. AutomationPropertyChangedEventArgs는 클라이언트(300)에게 특성 변경 이벤트에 관한 정보를 전달하기 위해 사용된다.

보조 클래스(350)는 논리 구조 변경 이벤트 인수 클래스를 더 포함할 수 있다. LogicalStructureChangedEventArgs 클래스는 클라이언트(300)에게 논리 트리 변경 이벤트와 함께 이 클래스의 인스턴스를 제공하기 위해, UI 이벤트와 함께 사용될 수 있다. LogicalStructureChangedEventArgs는 클라이언트(300)에게 논리 구조 변경에 관한 정보를 전달하기 위해 사용된다.

보조 클래스(350)는 또한, 최상위 레벨 윈도우 이벤트 인수(TopLevelWindowEventArgs) 클래스를 포함할 수 있는데, TopLevelWindowEventArgs 클래스는 커스텀 이벤트와 함께 이 클래스의 인스턴스를 클라이언트(300)에게 제공하기 위해 UI 이벤트와 함께 사용될 수 있다. TopLevelWindowEventArgs는 클라이언트(300)에게 최상위 레벨 윈도우 이벤트에 관한 정보를 전달하기 위해 사용된다. 최상위 레벨 윈도우는 그 부모가 데스크탑인 윈도우이다. "열림(opened)"라는 용어의 사용은 새로운 최상위 레벨 윈도우가 사용자에게 나타났다는 것을 나타낸다. "닫힘(closed)"라는 용어의 사용은 최상위 레벨 윈도우가 사라졌다는 것을 나타낸다.

보조 클래스(350)는 트리 로드 이벤트 인수(TreeLoadEventArgs) 클래스를 더 포함할 수 있다. TreeLoadEventArgs 클래스는 UI 이벤트와 함께 사용되는 커스텀 이벤트 인수 클래스이다. 클라이언트(300)는 트리 로드 이벤트와 함께 이 클래스의 인스턴스를 수신할 수 있다. TreeLoadEventArgs는 클라이언트(300)에게 트리 로딩 이벤트에 관한 정보를 전달하기 위해 사용될 수 있다.

보조 클래스(350)는 또한 입력 관련 메소드에 대한 상수를 제공하는 VKey 클래스를 포함할 수 있다. 보조 클래스(350)는 또한 NoClickablePointException을 포함할 수 있다. 클릭 가능한 포인트에 있는 논리 요소 내에서 에러가 발생하는 경우에 예외 상황(exception)이 생성된다. 에러는, 바운딩 사각형이 비어 있거나, 아무런 폭 또는 높이를 갖지 않거나, 그 포인트에서의 논리 요소가 변경되었을 때 발생할 수 있다.

보조 클래스(350)는 또한 이벤트 통지를 수신하기 위한 몇 개의 클래스를 구현할 수 있다. 포커스 변경 이벤트 인수(FocusChangedEventArgs) 클래스는 클라이 언트에게 포커스 변경 이벤트에 관한 정보를 전달하기 위해 사용된다.

도 9에 도시된 바와 같이, 제공자측 API(440)는 제공자 자동화 클래스(provider automation class; 442), 제공자 자동화 인터페이스(provider automation interface; 448) 및 제공자 미가공 요소 인터페이스(provider raw element interface; 450)를 포함한다. 제공자측 API(440)는 또한 컨트롤 패턴 제공자 인터페이스(control pattern provider interface; 460) 및 보조 클래스(480)를 포함할 수 있다. 보조 클래스들(480 및 350)은, 특성 식별자, 이벤트 식별자, 패턴 식별자와 같은 정보를 사용하고 통신하기 위한 타입들, 및 사각형이나 포인트를 나타내는 클래스와 같은 기본 타입들을 공유할 수 있다. 다른 특징들은 제공자 보조 클래스(480) 또는 클라이언트 보조 클래스(350)에 대해 유일할 수 있다. 예를 들어, VKey 클래스는 클라이언트 보조 클래스(350)로서만 지정될 수 있다.

제공자 자동화 클래스(442)는 바람직하게는 도 10에 도시된 바와 같이, 자동화 상호 운용성 제공자(AutomationInteropProvider) 클래스(502)를 포함한다. AutomationInteropProvider 클래스(502)는 Win32 또는 제3자 자동화 구현물과 더불어 액세스 가능 시스템(200)에 의해 사용되는 메소드를 포함할 수 있다. AutomationInteropProvider 클래스(502)는 Win32 또는 제3자 UI 자동화 제공자측 구현물에 의해 사용되는 특성 및 메소드를 포함한다. 다음 표는 본 발명의 실시예에 따른 AutomationInteropProvider 클래스(502)를 나타낸 것이다.

자동화 제공자(AutomationProvider) 클래스(500)는 윈도즈 클라이언트 플랫폼(Windows Client Platform)과 함께 액세스 가능 시스템(200)에 의해 사용될 수 있는 메소드를 포함하는 유사 클래스이다.

제공자측 API(440)는 또한 제공자 자동화 인터페이스(448)를 포함한다. 제공자 자동화 인터페이스(448)는, 액세스 가능 시스템(200)이 디폴트로 노출시키는 특성들 외의 부가적인 특성을 노출하기 위해 Win32 또는 제3자 제공자에 의해 구현되는 자동화 특성 상호 운용성 제공자(IAutomationPropertyINteropProvider) 인터페이스(447)를 포함할 수 있다. 제공자 자동화 인터페이스(448)는 또한 자동화 특성 제공자(IAutomationPropertyProvider) 인터페이스(449)를 포함할 수 있다. 이 인터페이스(449)는 인터페이스(447)와 유사하지만, 액세스 가능 시스템(200)에 의해 디폴트로 노출되는 특성들 이외의 특성들을 노출시키기 위해 원시 윈도즈 클라이언트 플랫폼 제공자(native Windows Client Platform provider)에 의해 구현될 수 있다.

제공자 미가공 요소 인터페이스(450)는 미가공 요소 제공자(IRawElementProvider) 인터페이스(456)를 포함할 수 있다. IRawElementProvider 인터페이스(456)는, 원시 윈도즈 클라이언트 플랫폼, Win32 또는 제3자 제공자에 의해 구현되고, 첫 번째 자식, 마지막 자식, 다음 형제 및 부모와 같은 상대 요소를 반환하고 특정 또는 모든 원시 및 UI 자동화 특성을 반환하기 위해 액세스 가능 시스템(200)에 의해 호출되는 메소드를 정의한다. IRawElementProvider 인터페이스(456)는 또한 컨트롤 패턴에 대한 제공자 객체를 반환한다. IRawElementProvider 인터페이스(456)는 액세스 가능 시스템(200)에 의해 구현되며, 특정 요소에 관련된 기능을 위해 제공자와 상호 작용한다. IRawElementProvider 인터페이스(456)의 실시예의 한 예는 다음 표에 제공된다.

부가적인 제공자 미가공 요소 인터페이스(450)는 미가공 요소 컨텍스트 상호 운용성 제공자(IRawElementContextInteropProvider) 인터페이스(452)를 포함할 수 있다. 이 인터페이스(452)는 Win32 또는 제3자 제공자에 의해 구현될 수 있다. 이 인터페이스(452)는 임의의 특정 요소에 관련되지 않는 이벤트들 및 다른 기능을 관리하게 위해 사용될 수 있다. 또한, 부가적인 미가공 요소 인터페이스(450)는 미가공 요소 컨텍스트 제공자(IRawElementContextProvider) 인터페이스(458)를 포함할 수 있고, 원시 윈도즈 클라이언트 플랫폼 제공자에 의해 구현될 수 있으며, 임의의 특정 요소에 관련되지 않는 이벤트들 및 기타 기능을 관리하기 위해 사용될 수 있다. IRawElementContextProvider 인터페이스(458)의 실시예는 다음 표에 표시된다.

제공자측 API(440)는 또한 컨트롤 패턴 제공자 인터페이스(460)를 포함할 수 있다. 각각의 컨트롤 패턴은 액세스 가능 시스템(200)에게 컨트롤 패턴을 노출시키는 객체에 의해 구현되는 제공자 인터페이스(460)를 갖는다. 예를 들어, 애플리케이션 윈도우 제공자(IApplicationWindowProvider) 인터페이스는 애플리케이션의 최상위 레벨 윈도우에 연관된 행동 및 정보를 노출시킨다. 후술되는 컨트롤 패턴 제공자 인터페이스(460)는 HWND 기반 및 제3자 제공자들에 의해 구현될 수 있는 상 호 운용성 제공자(InteropProvider) 인터페이스를 포함한다. 컨트롤 패턴 제공자 인터페이스(460)는 또한 윈도즈 클라이언트 플랫폼 제공자에 의해 원시적으로 구현될 수 있는 제공자 인터페이스를 포함할 수 있다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 애플리케이션 윈도우 제공자(IApplicationWindowProvider) 인터페이스를 포함할 수 있다. IApplicationWindowProvider 또는 IApplicationWindowInteropProvider 인터페이스는 전형적으로 최상위 레벨 애플리케이션 윈도우에 연관된 행동 및 정보를 노출시킬 수 있다. 이 인터페이스는 전형적으로 애플리케이션의 메인 윈도우를 조작하기 위한 기능을 노출시키도록 제공자에 의해 구현된다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 확대 및 축약 제공자(IExpandCollapseProvider) 인터페이스 또는 IExpandCollapseInteropProvider 인터페이스를 포함할 수 있다. 이 인터페이스는 더 많은 컨텐트를 표시하기 위해 확대하거나, 컨텐트를 숨기기 위해 축약하는 컨트롤의 능력을 노출시킬 수 있다. IExpandCollapseProvider 인터페이스는 트리와 같은 행동을 제공하기 위해 HierarchyItem 패턴(후술됨)과 함께 지원될 수 있지만, 열고 닫는 개별적인 컨트롤들에 대해서도 관련된다. 툴바, 콤보 박스 및 메뉴와 같은 UI 요소들은 관련 구현물을 포함할 수 있다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 그리드 제공자(IGridProvider) 인터페이스 또는 IGridInteropProvider 인터페이스를 포함할 수 있다. IGridProvider 인터페이스는 그리드 크기 및 특정 셀로의 정보의 이동을 포함하는 기본적인 그리드 기능을 노출시킨다.

그리드 아이템 제공자(IGridItemProvider) 또는 IGridItemInteropProvider는 부가적인 컨트롤 패턴 제공자 인터페이스(460)를 제공할 수 있다. IGridItemProvider 인터페이스는 그리드 내에 있는 아이템을 나타낸다. 이 인터페이스는 메소드없이 특성들만을 포함할 수 있다. IGridItemProvider 또는 IGridItemInteropProvider 인터페이스는 그리드에서의 셀의 기능을 노출시키는 컨트롤을 조작하는 기능을 노출시키도록 제공자에 의해 구현된다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 계층 아이템 제공자(IHierarchyItemProvider) 또는 IHierarchyItemInteropProvider 인터페이스를 포함할 수 있다. IHierarchyItemProvider 또는 IHierarchyItemInteropProvider 인터페이스는, UI 요소들 간의 계층적 관계를 노출하여, 클라이언트(300)가 논리 트리(222)에서의 요소들의 관계와 무관하게 UI 요소들 간의 계층적 관계를 순회할 수 있게 한다. 계층 관계는 당연히 비순환적이다. 이 인터페이스를 구현할 수 있는 UI 요소들은 메뉴 및 리스트 뷰 컨트롤을 포함한다.

부가적인 컨트롤 패턴 제공자 인터페이스(460)는 인보크 제공자(IInvokeProvider) 또는 IInvokeInteropProvider 인터페이스를 포함할 수 있다. 인보크 제공자 인터페이스는 객체들에 연관된 하나의 명백한 동작을 갖는 객체들에 의해 구현될 수 있다. 이들 객체들은 보통 상태가 없으며(stateless), 그들을 호출하는 것은 그들 자신의 상태를 변경시키지는 않지만, 애플리케이션의 보다 큰 문맥에서 변화를 야기한다. IInvokeProviderInterface를 구현할 수 있는 UI 요소들은 푸시 버튼 및 하이퍼링크 메뉴 아이템을 포함한다.

다중 뷰 제공자(IMultipleViewProvider 또는 IMultipleViewInteropProvider) 인터페이스는 부가적인 컨트롤 패턴 인터페이스(460)를 제공한다. 다중 뷰 제공자 인터페이스는 동일한 세트의 정보, 데이터 또는 자식의 다수의 표현들 사이에서 전환하는 요소의 능력을 노출시킬 수 있다. 이 패턴은 컨텐트의 현재의 뷰를 제어하는 컨테이너 상에 구현되어야 된다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 범위 값 제공자(IRangeValueProvider) 또는 (IRangeValueInteropProvider) 인터페이스를 포함할 수 있다. 범위 값 제공자 인터페이스는 유한 범위 내의 값을 관리하는 컨트롤의 능력을 반영하는 특성들의 관련 세트를 노출시킬 수 있다. 이 인터페이스는 컨트롤의 유효 최소 및 최대 값들 및 그것의 현재 값을 전달할 수 있다. 이 인터페이스를 구현할 수 있는 UI 요소들은 프로그레스 바(progress bar) 및 스크롤 바 상의 수치 스피너(spinner)를 포함할 수 있다.

스크롤 제공자(IScrollProvider 또는 IScrollInteropProvider) 인터페이스는 부가적인 컨트롤 패턴 제공자 인터페이스(460)로서 제공될 수 있다. 이 인터페이스는 컨트롤의 컨텐트를 스크롤링함으로써 사용자에게 보이는 가시 영역의 부분을 변경하는 컨트롤의 능력을 노출시킨다. 이 인터페이스는, 리스트 박스, 트리 뷰, 또는 컨트롤의 가시 영역보다 큰 컨텐트 영역을 유지하는 다른 컨테이너들과 같은 컨텐트를 스크롤하는 UI 요소들을 나타낸다. IScrollInteropProvider 인터페이스의 실시예는 다음 표에 제공된다.

부가적인 컨트롤 패턴 제공자 인터페이스(460)는 식별에 의한 선택 제공자(ISelectionByIDProvider 또는 ISelectionByIDInteropProvider) 인터페이스를 포함한다. 이 인터페이스는, 포함하는 아이템들 사이의 선택을 제공하는 컨테이너 요소를 나타낸다. 식별에 의한 선택 제공자 인터페이스는 논리 요소 자식을 갖지 않는 컨트롤들을 위한 제공자측 인터페이스이다. 클라이언트들은, 마치 컨트롤이 논리 요소들을 자식으로서 가지는 것처럼 동일한 메소드들을 볼 것이다. 이 인터페이스는 선택 및 선택 해제될 수 있는 컨테이너에서의 요소를 조작하는 기능을 노출하는데 있어서 제공자를 돕도록 구현된다. 인터페이스의 실시예는 다음 표에 제공된다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 선택 제공자(ISelectionProvider 또는 ISelectionInteropProvider) 인터페이스를 포함할 수 있다. 선택 제공자 인터페이스는 선택을 관리하는 컨테이너들을 나타낼 수 있 고, 선택될 수 있는 요소들을 포함하는 요소를 조작하는 기능을 노출시키도록 제공자에 의해 구현된다. 이 인터페이스의 실시예는 다음 표에 표시된다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 선택 아이템 제공자(ISelectionItemProvider 또는 ISelectionItemInteropProvider) 인터페이스를 포함할 수 있다. 이 인터페이스는 선택 가능 아이템을 정의할 수 있고, 그 아이템이 선택 및 선택 해제될 수 있도록 그 아이템의 기능을 노출시킬 수 있다.

컨트롤 패턴 제공자 인터페이스(460)는 또한 소트 제공자(ISortProvider 또는 ISortInteropProvider) 인터페이스를 포함할 수 있다. 이 인터페이스는 컨테이너의 현재의 소트 순서를 노출시킬 수 있고, 클라이언트로 하여금 그 요소들을 프로그램적으로 다시 소트하게 할 수 있게 할 수 있다.

값 제공자(IValueProvider 또는 IValueInteropProvider) 인터페이스는 관련 값을 갖는 요소들을 나타내고 조작하기 위해 컨트롤 패턴 제공자 인터페이스(460)에 의해 구현될 수 있다.

가시 정보 제공자(IVisualInformationProvider 또는 IVisualInformationInteropProvider) 인터페이스는 사용자에게 정보를 전달하고 있는 이미지 또는 애니메이션에 관한 정보를 표현하기 위해 컨트롤 패턴 제공자 인터 페이스(460) 내에 포함될 수 있다.

윈도우 제공자(IWindowProvider 또는 IWindowInteropProvider) 인터페이스 또한 컨트롤 패턴 제공자 인터페이스(460) 내에 포함될 수 있다. 이 인터페이스는 요소의 스크린 상의 위치 또는 크기를 변경시킬 뿐만 아니라, 가시 상태를 변경시키고 요소를 닫는 요소의 능력을 노출시킬 수 있다. 이 인터페이스의 예는 다음 표에서 제공된다.

제공자측 API(440)는 또한 보조 클래스(480)를 포함할 수 있다. 보조 클래스(480)는 클라이언트측 API(305) 내에서 이용된 것과 실질적으로 동일할 수 있다. 상술된 바와 같이, 클라이언트 및 제공자는 보조 클래스를 공유할 수 있다. 이러한 특징은 도 10과 관련하여 더욱 설명된다.

도 10은 클라이언트측 API(305), 액세스 가능 시스템 코어(200) 및 서버측 API(440) 간의 상호 작용을 도시한다. 클라이언트 애플리케이션(300)은 액세스 가능 시스템 코어(201)를 통해 정보를 얻기 위해, 자동화 클래스(312), 논리 요소 클래스(314), 미가공 요소 클래스(316) 또는 컨트롤 패턴 클래스(320)를 구현한다. 클라이언트 애플리케이션(300)은 또한 클라이언트 보조 클래스(350) 및 입력 클래스(340)를 구현할 수 있다.

도 10은, Win32 Run(12)을 사용하는 구현 A(10) 및 WCP Run을 사용하는 구현 B(20)와 관련하여 제공자측 API(440)를 도시한다. 구현 A는 자동화 상호 운용성 제공자 인터페이스(502), 미가공 요소 제공자 인터페이스(456), 미가공 요소 컨텍스트 상호 운용성 제공자 인터페이스(452) 및 컨트롤 패턴 인터페이스(460)를 필요에 따라 사용한다. 구현 B는 자동화 제공자(500), 미가공 요소 제공자 인터페이스(456), 자동화 특성 제공자 인터페이스(448), 미가공 요소 컨텍스트 제공자 인터페이스(458) 및 컨트롤 패턴 인터페이스(460)를 필요에 따라 사용한다. 구현(10 및 20)은 모두 제공자 보조 클래스(480)를 사용할 수 있다. 상술된 바와 같이, 제공자 보조 클래스는 클라이언트 보조 클래스(350)와 실질적으로 동일할 수 있거나, 또는 공유 보조 클래스(510)에 의해 도시된 바와 같이 클라이언트 보조 클래스(350)와 타입을 공유할 수 있다. 상술된 바와 같이, 공유 보조 클래스(510)는 특성 식별자, 패턴 식별자 및 이벤트 식별자와 같은 정보를 통신하기 위해 클라이언트 및 제공자가 공유하는 타입을 포함할 수 있다.

동작에 있어서, 클라이언트측 API(305)는 클라이언트(300)가 논리 트리에 접근할 수 있도록 한다. 기능은, (1) 포인트에서 포인트로의 논리 요소, (2) 이벤트로부터의 논리 요소, 및 (3) 현재 포커싱된 논리 요소를 포함한다. 상술된 바와 같이, 논리 요소는, UI 컴포넌트, 형편에 따른 컨트롤, 컨트롤의 일부, 또는 컨테이너나 논리적 그룹핑(즉, 다이얼로그, 창 또는 프레임)을 나타낸다. 컨트롤들은 이들의 기능의 점에서 상당히 서로 다를 수 있다. 따라서, 상이한 인터페이스들이 특정 타입의 컨트롤에 연관된 기능을 나타내는데 사용된다. 그러나, 이들 컨트롤 에 특유한 인터페이스들은 모든 컨트롤에 공통적인 기능을 나타내는 공통 기본 인터페이스(common base interface)로부터 파생된다. 공통 기본 인터페이스는, (1) 논리 트리(222)를 네비게이팅하기 위한 메소드, (2) 특성 값을 얻기 위한 일반적인 메소드, 및 (3) 지원되는 컨트롤에 특유한 인터페이스를 액세스하기 위한 메소드를 포함하는 코어 클래스(310)를 포함한다. 논리 트리(222)를 네비게이팅하는데 있어서, 각각의 근원적인 애플리케이션 UI 기술은 네비게이션을 위해 고유의 기술을 제공할 것이다.

애플리케이션에서의 액세스 가능 시스템 이벤트들을 사용하기 시작하기 위해서, 클라이언트(300)는, (1) 데스크탑 상에 나타나고 그 이벤트에 대한 핸들러(handler)에 나타나는 새로운 UI를 발견하고, 다른 이벤트들에 대해 등록하며, 이것에 의해 임의의 프로세스로부터 이벤트들을 수신하기 위해, 자동화 클래스(312)로부터의 "AddTopLevelWindowEventHandler" 메소드의 사용, (2) 관계있는 UI를 알아내고 UI의 특정 부분을 타겟으로 하기 위해, 자동화 클래스(312)로부터의 "Find" 메소드들 중의 하나의 사용, (3) 스크린 상의 포인트나 윈도우 핸들을 찾는 것과 같이 관계있는 UI를 발견하고, 그 핸들이나 포인트를 사용하여 이벤트들을 대기하기 위한 참조로서 사용하기 위한 논리 요소를 획득하기 위해, 자동화 클래스(312)로부터의 소정의 다른 메소드의 사용, 또는 (4) 입력 포커스를 추적하고, 현재 포커를 갖는 UI 상의 이벤트들에 대해 등록하기 위해, 자동화 클래스(312)의 "AddFocusChangedEventHandler" 메소드의 사용 중에서 하나를 수행할 수 있다.

클라이언트측 API(305) 및 서버측 API(440)는 클라이언트(300)의 요구를 수 행하도록 동작한다. 다음 예들은, 클라이언트가 클라이언트측 API(305)를 사용하는 메소드, 및 클라이언트(300)에게 사용자 인터페이스 정보를 제공하기 위해 서버측 API(440)가 후속적으로 호출되는 방법을 나타내기 위해 제공된다.

최상위 레벨 윈도우 이벤트들은, 메뉴 및 콤보 박스 드롭다운에 관련된 이벤트들 또는 데스크탑을 부모로서 갖는 임의의 특징에 관련된 이벤트들을 포함한다. 본 발명의 실시예에서, AddTopLevelWindowEventHandler 메소드는 최상위 레벨 윈도우의 열림과 닫힘의 통지를 수신하기 위해 사용된다. AddTopLevelWindowEventHandler를 호출함으로써, 현재의 데스크탑 상에서의 새로운 최상위 레벨 윈도우의 열림, 또는 최상위 레벨 윈도우의 닫힘에 대한 통지를 얻을 수 있을 것이다. RemoveTopLevelWindowEventHandler 메소드드는 데스크탑 상에서의 최상위 레벨의 윈도우의 열림과 닫힘에 대한 통지의 수신을 중단하기 위한 메커니즘을 제공한다. 이 메소드는 이러한 대기자를 식별하기 위해 콜백 객체(callback object)를 사용한다. 그러므로, RemoveTopLevelWindowEventHandler 메소드에 전달되는 객체는 AddTopLevelWindowEventHandler에 전달된 것과 동일하다. 열리는 각각의 새로운 최상위 레벨 윈도우에 대해, 제공자측 API(440)로부터 메소드가 호출된다. 이와 마찬가지로, 한번 최상위 레벨 윈도우가 닫힌 경우에 액세스 가능 시스템(200)에 의해 메소드가 호출될 수 있다. 이들 통지를 수신하기 위해, 클라이언트(300)는 AddTopLevelWindowEventHandler 메소드를 호출한다.

다른 타입의 이벤트는 포커스 이벤트이다. 클라이언트(300)는 대개 포커스를 추적하기 위한 메소드를 필요로 한다. Microsoft Windows OS에서는 포커스를 추적하기 어렵다. 예를 들어, 메뉴가 드롭 다운되는 경우에(예컨대, Micorosoft Word에서의 File 메뉴), 메뉴에서의 아이템들은 사용자가 커서를 아래로 하나씩 이동함에 따라 포커스를 얻는다. 메뉴가 닫히는 경우에(예컨대, 사용자가 ESC 키를 누름), 현재는 송신되는 포커스 이벤트가 존재하지 않는다. 그 대신에, 포커스 변경에 관심 있는 클라이언트는 다수의 이벤트를 감지하여, 이들 중의 어느 것이 논리적으로 포커스 변경을 나타내는지 알아내야 한다. 본 발명의 실시예에서는, 자동화 클래스(312)로부터의 AddFocusChangedEventHandler 메소드가 대기자에게 포커스 변경 이벤트를 통지하기 위해 사용될 수 있다. 클라이언트(300)는 이러한 이벤트 등록 메소드 및 다른 이벤트 등록 메소드들과 함께 반환되어야 할 한 세트의 특성들을 명시할 수 있다. 클라이언트(300)는 포커스 변경에 대한 통지의 수신을 중단하기 위해 RemoveFocusChangedEventHandler 메소드를 호출할 수 있다. 이 메소드는 이러한 대기자를 식별하기 위해 콜백 객체를 사용할 수 있는데, 이러한 경우에 RemoveFocusChangedEventHandler 메소드에 전달되는 객체들은 AddFocusChangedEventHandler 프로시져에 전달되는 것과 동일할 것이다. 액세스 가능 시스템(200)은, 포커스가 변경된 경우에 클라이언트(300)에게 통지하기 위해 제공자측 자동화 클래스(442)로부터 RaiseFocusChangedEvent와 같은 메소드를 호출할 수 있다.

특성 변경 이벤트는 논리 요소의 특성들이 변경될 때 발생된다. 본 발명의 실시예에서, 클라이언트(300)는 특성 변경에 대한 통지를 수신하기 위해 자동화 클래스(312)로부터 AddPropertyChangedEventHandler 메소드를 호출한다. 액세스 가 능 시스템(200)은, 특성의 값이 AddPropertyChangedEventHandler에서 명시된 논리 요소 트리 내의 논리 요소에 관해 변경되었을 때, 제공자측 API(440)로부터 제공자측 메소드를 호출한다. 범위 파라미터는 어떤 요소들에 이벤트가 발생되어야 하는지를 나타낸다. 예를 들어, 윈도우의 루트 논리 요소 및 자손들에 대한 요청의 전달은 특성 변경 콜백을 그 윈도우로 제한한다. 만약 범위 파라미터가 트리에서의 모든 요소들로 설정되면, 범위는 무시되고, 데스크탑 상에서 발생하는 지정된 특성에 대한 모든 변경들이 송신된다. 클라이언트(300)는 상이한 세트의 특성들 및/또는 상이한 콜백 객체로 AddPropertyChangedEventHandler를 여러 번 호출할 수 있다. 액세스 가능 시스템(200)에 의해 제공되는 통지는, 변경된 특성, 새로운 특성 값, 및 이용 가능하다면 기존의 특성 값을 나타낸다. 클라이언트(300)는 특성 변경에 대한 통지의 수신을 중단하기 위해 RemovePropertyChangedEventHandler 메소드를 호출할 수 있다. 이 메소드는 이러한 대기자를 식별하기 위해 범위 요소 및 콜백 객체를 사용할 수 있는데, 이러한 경우에 전달되는 객체들은 AddPropertyChangedEventHandler에 전달되는 것과 동일해야 된다. 제공자 자동화 클래스(442)는 자동화 특성 변경을 클라이언트(300)에게 알려주기 위한 RaiseAutomationPropertyChangedEvent 메소드를 포함한다.

클라이언트 자동화 클래스(312)로부터의 AddAutomationEventHandler 메소드는 클라이언트(300)로 하여금 컨트롤에 대한 이벤트를 수신할 수 있도록 할 것이다. 어떤 요소들에 이벤트를 발생시킬 것인지를 나타내기 위해 범위 파라미터가 사용될 수 있다. 예를 들어, 윈도우의 루트 논리 요소 및 자손의 요청의 전달은 이벤트를 그 윈도우로 제한할 것이다. 만약 트리에서의 모든 요소가 요구되면, 데스크탑 상의 모든 이벤트가 송신될 것이다. RemoveAutomationEventHandler 메소드는 컨트롤에 대한 이벤트의 수신을 중지하기 위해 사용될 수 있다. 이 메소드는 범위 요소, 콜백 객체, 및 대기자를 식별하기 위한 이벤트 식별자를 사용할 수 있다. 이러한 경우에, 전달되는 객체들은 AddAutomationEventHandler 메소드에 전달되는 것과 동일하여야 한다. 제공자 자동화 클래스(442)는 클라이언트(300)에게 이벤트를 알려주기 위한 RaiseAutomationEvent 메소드를 포함한다.

클라이언트 애플리케이션(300)이 AddAutomationEventHandler 메소드를 호출한 경우, 액세스 가능 시스템(200)은, 컨트롤에 특유한 이벤트가 발생되고 그 이벤트의 소스가 AddAutomationEventHandler에서 명시된 논리 요소 트리 내의 논리 요소인 경우에 제공자측 API(440)로부터 메소드를 호출한다. 컨트롤에 대한 이벤트가 발생되는 경우에는, 대개 이용 가능한, 이벤트에 특유한 정보가 존재한다. RemoveAllEventHandler 메소드는 모든 이벤트들의 수신을 중단하기 위해 호출될 수 있다. 이것은 클라이언트 애플리케이션이 닫히기 전에 정리(clean up)하기 위한 빠른 방법이다. 이 제거 메소드는 애플리케이션 종료시에 최적으로 사용될 수 있다.

논리 구조 변경 이벤트는 논리 요소 트리 구조가 변경될 때 발생된다. AddLogicalStructureChangedEventHandler 메소드는 논리 요소 트리에서의 구조적 변경에 대한 통지를 수신하도록 구현될 수 있다. 논리 요소가 추가되거나, 제거되거나, 또는 무효화될 때, 명시된 콜백 객체 상의 메소드가 호출된다. RemoveLogicalStructureChangedEventHandler 메소드는 논리 요소 트리 변경에 대한 이벤트의 수신을 중단하기 위해 호출될 수 있다. 이 메소드는 이러한 대기자를 식별하기 위해 콜백 객체 및 범위 요소를 사용할 수 있는데, 이러한 경우에 전달되는 객체는 AddAutomationEventHandler에 전달되는 것과 동일하여야 한다. 제공자 자동화 클래스(442)는 논리 구조 변경을 클라이언트(300)에게 알려주기 위한 RaiseLogicalStructureChangedEvent 메소드를 포함한다.

UI 자동화 서버 또는 제공자측 API(440)는, 서버 또는 근원적인 UI 엔진이 특성 변경 통지를 달성하기 위해 호출할 수 있는 메소드를 포함한다. 서버(400)는 UI가 변경되는 경우에 적합한 파라미터들을 생성하기 위해 이들 통지 메소드를 호출할 수 있다.

본 발명은 특정 실시예들과 관련하여 설명되었는데, 이들은 본 발명을 제한하기보다는 오히려 모든 점에 있어서 예시적인 것으로 의도된다. 대안적인 실시예들이 본 발명의 범위를 벗어나지 않으면서 본 발명이 속하는 당해 기술 분야의 당업자에게 명백해질 것이다.

상기 설명으로부터, 본 발명은, 시스템 및 방법에 고유하고 명백한 다른 장점들과 더불어 전술된 모든 목적들을 달성하도록 잘 적응된 것이라는 것을 알 수 있을 것이다. 소정의 특징들 및 부분 조합들이 유용하며, 다른 특징들 및 부분 조합들과 관계없이 사용될 수 있다는 점을 이해할 수 있을 것이다. 이것은 청구범위 내에서 고려된다.

Claims

클라이언트에게 사용자 인터페이스 정보를 제공하며, 클라이언트측 및 제공자측을 포함하는 액세스 가능 시스템(accessibility system)에서 사용하기 위한 툴(tool)들의 시스템에 있어서,

사용자 인터페이스 정보를 찾기 위한 클라이언트 자동화 클래스(client automation class)를 포함하는 클라이언트측 자동화 툴들 - 상기 클라이언트 자동화 클래스는 이벤트 등록 툴들 및 논리 요소(logical element) 발견 툴들을 포함함 -; 및

상기 클라이언트에게 사용자 인터페이스 정보를 제공하기 위한 제공자측 자동화 툴들 - 상기 제공자측 자동화 툴들은 상기 클라이언트에게 이벤트 정보를 제공하기 위한 툴들을 갖는 자동화 제공자 클래스(automation provider class)를 포함함 -

을 포함하는 시스템.
제1항에 있어서, 사용자 인터페이스 요소를 나타내기 위한 클라이언트측 논리 요소 툴들을 더 포함하는 시스템.
제2항에 있어서, 미가공 요소 트리(raw element tree)에서의 요소를 나타내기 위한 클라이언트측 미가공 요소 툴들을 더 포함하는 시스템.
제1항에 있어서, 입력을 시뮬레이팅(simulating)하기 위한 메소드(method)들을 제공하기 위한 클라이언트측 입력 클래스(input class)를 더 포함하는 시스템.
제4항에 있어서, 마우스 입력 및 키보드 입력을 시뮬레이팅하기 위한 툴들을 더 포함하는 시스템.
제2항에 있어서, 상기 클라이언트로 하여금 액세스 가능 시스템 컨트롤 패턴(control pattern)들과 상호 작용할 수 있도록 하기 위한 클라이언트측 컨트롤 패턴 클래스(control pattern class)들을 더 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은 애플리케이션의 메인 윈도우에 연관된 정보를 노출시키기 위한 애플리케이션 윈도우 패턴 클래스(application window pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은, 표시되고 숨겨질 수 있는 컨텐트를 조작하기 위한 확대 및 축약 패턴 클래스(expand and collapse pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은, 아이템이 그리 드(grid)의 일부인지를 알아내기 위한 그리드 아이템 클래스(grid item class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은, 상기 논리 트리에서의 요소들의 관계와 무관한 UI(user interface) 요소들간의 계층 관계를 노출시키는 UI 요소들을 나타내기 위한 계층 아이템 패턴 클래스(hierarchy item pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은 단일한 관련 동작을 갖는 객체들을 나타내기 위한 인보크 패턴 클래스(invoke pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은 다수의 표현들 사이에서 전환할 수 있는 요소를 조작하기 위한 다중 뷰 패턴 클래스(multiple view pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은 컨트롤의 최소 및 최대 값들을 노출시키기 위한 범위 값 패턴 클래스(range value pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은 스크롤링(scrolling)을 통해 가시성(visibility)을 변경할 수 있는 요소를 조작하기 위한 스크롤 패턴 클래스(scroll pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은, 선택되고 선택 해제될 수 있는 컨테이너(container)에서의 요소들을 조작하기 위한 선택 패턴 클래스(selection pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은 서브 요소(sub-element)들을 정렬할 수 있는 컨테이너 요소를 조작하기 위한 소트 패턴 클래스(sort pattern class)를 포함하는 시스템.
제6항에 있어서, 상기 클라이언트측 컨트롤 패턴 클래스들은, 값을 표현하는 사용자 인터페이스 요소들을 나타내기 위한 값 패턴 클래스(value pattern class)를 포함하는 시스템.
제6항에 있어서, 사용자 데스크탑(desktop) 상의 윈도우를 조작하기 위한 윈도우 패턴 클래스(window pattern class)를 더 포함하는 시스템.
제1항에 있어서, 부가적인 기능들을 수행하기 위한 보조 툴(auxiliary tool) 들을 더 포함하는 시스템.
제1항에 있어서, 부가적인 특성(property)들을 노출시키기 위한 제공자측 자동화 인터페이스(provider side automation interface)를 더 포함하는 시스템.
제1항에 있어서, 미가공 요소 트리로부터의 상대 요소(relative element)들을 반환하기 위한 제공자 미가공 요소 인터페이스(provider raw element interface)를 더 포함하는 시스템.
제1항에 있어서, 정의된 컨트롤 패턴들에 연관된 행동(behavior) 및 정보를 노출시키기 위한 컨트롤 패턴 제공자 인터페이스(control pattern provider interface)들을 더 포함하는 시스템.
클라이언트에게 사용자 인터페이스 정보를 제공하며, 제공자측으로부터 클라이언트측으로 사용자 인터페이스 정보를 전송하기 위한 메커니즘 및 사용자 인터페이스 정보를 선택적으로 보이기 위한 논리 트리를 포함하는 액세스 가능 시스템에서 구현되는 클라이언트측 툴들의 시스템에 있어서,

상기 클라이언트측 툴들은

상기 제공자측으로부터의 사용자 인터페이스 이벤트 정보를 찾기 위한 클라이언트 자동화 클래스(automation class)를 포함하는 클라이언트측 자동화 메커니 즘; 및

상기 논리 트리에서의 사용자 인터페이스 요소를 나타내기 위한 논리 요소 클래스(logical element class)를 포함하는 클라이언트측 논리 요소 메커니즘

을 포함하는 시스템.
제23항에 있어서, 상기 클라이언트 자동화 클래스는 자동화 이벤트 핸들러(automation event handler)를 추가하기 위한 툴들 및 상기 자동화 이벤트 핸들러를 제거하기 위한 툴들을 포함하는 시스템.
제23항에 있어서, 상기 클라이언트 자동화 클래스는 자동화 특성 변경 이벤트 핸들러(automation property changed event handler)를 추가하기 위한 툴들 및 상기 자동화 특성 변경 이벤트 핸들러를 제거하기 위한 툴들을 포함하는 시스템.
제23항에 있어서, 상기 클라이언트 자동화 클래스는 포커스 변경 이벤트 핸들러(focus changed event handler)를 추가하기 위한 툴들 및 상기 포커스 변경 이벤트 핸들러를 제거하기 위한 툴들을 포함하는 시스템.
제23항에 있어서, 상기 클라이언트 자동화 클래스는 최상위 레벨 윈도우 이벤트 핸들러(top level window event handler)를 추가하기 위한 툴들 및 상기 최상위 레벨 윈도우 이벤트 핸들러를 제거하기 위한 툴들을 포함하는 시스템.
제23항에 있어서, 상기 클라이언트 자동화 클래스는 논리 구조 변경 이벤트 핸들러(logical structure changed event handler)를 추가하기 위한 툴들 및 상기 논리 구조 변경 이벤트 핸들러를 제거하기 위한 툴들을 포함하는 시스템.
제23항에 있어서, 상기 클라이언트 자동화 클래스는 논리 요소를 찾는 툴들 및 미가공 요소를 찾는 툴들을 포함하는 시스템.
제23항에 있어서, 미가공 요소 트리에서의 요소를 나타내기 위한 클라이언트측 미가공 요소 클래스(raw element class)를 더 포함하는 시스템.
제23항에 있어서, 상기 논리 요소 클래스는 요소에 의해 지원되는 모든 패턴들을 얻기 위한 툴들을 더 포함하는 시스템.
제23항에 있어서, 입력을 시뮬레이팅하기 위한 메소드(method)들을 제공하기 위한 입력 클래스를 더 포함하는 시스템.
제32항에 있어서, 상기 입력은 마우스 입력 및 키보드 입력을 포함하는 시스템.
클라이언트에게 사용자 인터페이스 정보를 제공하며, 제공자측으로부터 상기 클라이언트에게 사용자 인터페이스 정보를 전송하기 위한 메커니즘 및 사용자 인터페이스 정보를 선택적으로 보이기 위한 논리 트리를 포함하는 액세스 가능 시스템에서 구현되는 제공자측 툴들의 시스템에 있어서,

상기 제공자측 툴들은,

상기 클라이언트에게 이벤트 통지들을 제공하기 위한 툴들을 포함하는 제공자측 자동화 클래스(provider automation class);

사용자 인터페이스 특성들을 노출시키기 위한 제공자측 자동화 인터페이스(provider automation interface);

특정 상대 요소에 관련된 정보를 반환하기 위한 미가공 요소 인터페이스(provider raw element interface); 및

특정 요소에 관련되지 않은 이벤트들 및 기능을 관리하기 위한 미가공 요소 컨텍스트 인터페이스(raw element context interface)

를 포함하는 시스템.
제34항에 있어서, 상기 제공자측 자동화 클래스는 자동화 이벤트를 발생시키기 위한 툴을 포함하는 시스템.
제34항에 있어서, 상기 제공자측 자동화 클래스는 특성 변경 이벤트를 발생시키기 위한 툴을 포함하는 시스템.
제34항에 있어서, 상기 제공자측 자동화 클래스는 포커스 변경 이벤트를 발생시키기 위한 툴을 포함하는 시스템.
제34항에 있어서, 상기 제공자측 자동화 클래스는 논리 구조 변경 이벤트를 발생시키기 위한 툴을 포함하는 시스템.
제34항에 있어서, 컨트롤 패턴 제공자 인터페이스(control pattern provider interface)들을 더 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 최상위 레벨 애플리케이션 윈도우에 연관된 행동 및 정보를 노출시키기 위한 애플리케이션 윈도우 제공자 인터페이스를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 컨텐트를 숨기고 표시하기 위한 확대 및 축약 인터페이스(expand and collapse interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 기본적인 그리드 기능을 노출시키기 위한 그리드 제공자 인터페이스를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 상기 클라이언트로 하여금 사용자 인터페이스 요소들 간의 계층 관계를 순회(traverse)할 수 있도록 하기 위한 계층 아이템 제공자 인터페이스(hierarchy item provider interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 단일 동작을 수행하는 객체들에 의한 사용을 위해 인보크 제공자 인터페이스(invoke provider interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 다수의 표현들 사이에서 전환하는 객체의 능력을 노출시키기 위한 다중 뷰 제공자 인터페이스(multiple view provider interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 유한 범위의 값들을 관리하는 능력을 허용하는, 한 세트의 특성들을 노출시키기 위한 범위 값 제공자 인터페이스(range value provider interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 가시 영역을 변경하는 능력을 노출시키기 위한 스크롤 제공자 인터페이스(scroll provider interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 아이템들 사이의 선택을 제공하는 요소를 노출시키기 위한, 식별에 의한 선택 제공자 인터페이스(selection by identification provider interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 선택을 관리하는 컨테이너를 나타내기 위한 선택 제공자 인터페이스(selection provider interface)를 포함하는 시스템.
제39항에 있어서, 상기 컨트롤 패턴 제공자 인터페이스들은 크기 및 위치를 변경하는 능력을 노출시키기 위한 윈도우 제공자 인터페이스(window provider interface)를 포함하는 시스템.
제공자측으로부터 클라이언트측으로 사용자 인터페이스 정보를 전송하기 위한 메커니즘 및 사용자 인터페이스 정보를 선택적으로 보이기 위한 논리 트리를 포함하는 액세스 가능 시스템을 통해 클라이언트에게 사용자 인터페이스 정보를 제공하기 위한 애플리케이션 프로그램 인터페이스 시스템에 있어서,

사용자 인터페이스 정보를 획득하는데 있어서 상기 클라이언트를 돕기 위한 것으로, 자동화 클래스, 논리 요소 클래스, 미가공 요소 클래스, 컨트롤 패턴 클래 스들 및 입력 클래스를 포함하는 클라이언트측 애플리케이션 프로그램 인터페이스들; 및

클라이언트 요청에 응답하기 위한 것으로, 제공자 자동화 클래스, 제공자 자동화 인터페이스, 미가공 요소 인터페이스 및 컨트롤 패턴 제공자 인터페이스들을 포함하는 제공자측 애플리케이션 프로그램 인터페이스들

을 포함하는 애플리케이션 프로그램 인터페이스 시스템.
제51항에 있어서, 상기 제공자측 및 상기 클라이언트측에 의해 사용되는 보조 클래스들을 더 포함하는 애플리케이션 프로그램 인터페이스 시스템.
제공자측으로부터 클라이언트측으로 사용자 인터페이스 정보를 전송하기 위한 메커니즘 및 사용자 인터페이스 정보를 선택적으로 보이기 위한 논리 트리를 포함하는 액세스 가능 시스템을 통해 클라이언트에게 사용자 인터페이스 정보를 제공하는 컴퓨터 구현 방법에 있어서,

사용자 인터페이스 정보를 획득하는데 있어서 상기 클라이언트를 돕기 위한 것으로, 자동화 클래스, 논리 요소 클래스, 미가공 요소 클래스, 컨트롤 패턴 클래스들 및 입력 클래스를 포함하는 클라이언트측 애플리케이션 프로그램 인터페이스들을 제공하는 단계; 및

클라이언트 요청에 응답하기 위한 것으로, 제공자 자동화 클래스, 제공자 자동화 인터페이스, 미가공 요소 인터페이스 및 컨트롤 패턴 제공자 인터페이스들을 포함하는 제공자측 애플리케이션 프로그램 인터페이스들을 공급하는 단계

를 포함하는 컴퓨터 구현 방법.
제53항에 있어서, 상기 제공자측 및 상기 클라이언트측에 의해 사용하기 위한 보조 클래스들을 제공하는 단계를 더 포함하는 컴퓨터 구현 방법.
제공자측으로부터 클라이언트측으로 사용자 인터페이스 정보를 전송하기 위한 메커니즘 및 사용자 인터페이스 정보를 선택적으로 보이기 위한 논리 트리를 포함하는 액세스 가능 시스템을 통해 클라이언트에게 사용자 인터페이스 정보를 제공하기 위한 컴퓨터 구현 방법에 있어서,

클라이언트 자동화 클래스로부터의 선택된 이벤트 핸들러를 사용하여 사용자 인터페이스 정보를 요청하는 단계; 및

대응하는 발생 이벤트 메소드(raise event method)를 사용하여 사용자 인터페이스 이벤트 통지들을 제공하기 위해 제공자 자동화 클래스를 호출하는 단계

를 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 사용자 인터페이스 요소 정보를 얻기 위해 논리 요소 툴들을 사용하는 단계를 더 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 미가공 요소 트리에서의 요소에 관한 미가공 요소 정보를 얻기 위해 클라이언트측 미가공 요소 툴들을 사용하는 단계를 더 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 입력을 시뮬레이팅하기 위한 메소드를 제공하기 위해 클라이언트측 입력 클래스를 이용하는 단계를 더 포함하는 컴퓨터 구현 방법.
제58항에 있어서, 마우스 입력 및 키보드 입력을 시뮬레이팅하는 단계를 더 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 상기 클라이언트가 액세스 가능 시스템 컨트롤 패턴들과 상호 작용할 수 있게 하기 위해 클라이언트측 컨트롤 패턴 클래스들을 사용하는 단계를 더 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 부가적인 기능들을 수행하기 위한 보조 툴들을 구현하는 단계를 더 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 부가적인 특성들을 노출시키기 위해 제공자측 자동화 인터페이스를 이용하는 단계를 더 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 미가공 요소 트리로부터의 상대 요소들을 반환하기 위한 제공자 미가공 요소 인터페이스를 구현하는 단계를 더 포함하는 컴퓨터 구현 방법.
제55항에 있어서, 정의된 컨트롤 패턴들에 연관된 행동 및 정보를 노출시키기 위한 컨트롤 패턴 제공자 인터페이스들을 구현하는 단계를 더 포함하는 컴퓨터 구현 방법.