KR101829406B1

KR101829406B1 - 버그 클리어링 하우스

Info

Publication number: KR101829406B1
Application number: KR1020177029725A
Authority: KR
Inventors: 야첵 스라즈스키; 제이슨 비. 파크스; 데이비드 두다
Original assignee: 구글 엘엘씨
Priority date: 2010-05-19
Filing date: 2011-05-19
Publication date: 2018-02-19
Also published as: EP2572282A4; WO2011146750A3; US8898637B2; WO2011146750A2; US8381189B2; US20150234699A1; CA2798759C; AU2011255477A1; JP5937577B2; CN103038752B; KR20170119725A; JP2013531839A; US20110314438A1; KR101789266B1; US9323598B2; JP6165922B2; CN103038752A; US20160299756A1; CN105868039A; EP2572282A2

Abstract

소프트웨어 문제 레포트들을 관리하기 위한 컴퓨터 구현 시스템으로서, 다수의 다른 개발자 조직으로부터 소프트웨어 개발자들을 등록하기 위하여 컴퓨터 서버 시스템에 있는 등록 서브시스템; 복수의 애플리케이션 개발자로부터의 복수의 애플리케이션을 일반 회원들이 구입(acquisition)할 수 있게 하는 애플리케이션 스토어; 상기 애플리케이션 스토어를 이용하여 배포된 애플리케이션들에 대한 문제들의 레포트들을 수신하고, 상기 문제들에 관한 데이터를 수신하고, 및 상기 데이터를 특정 애플리케이션 또는 상기 특정 애플리케이션의 개발자와 연관시키도록 프로그램된 애플리케이션 버그 추적기(application bug tracker); 및 하나 이상의 애플리케이션을 제공한 개발자를 위하여 하나 이상의 문제 레포트(problem report)를 생산하는 레포트 생성기를 포함하고, 상기 문제 레포트들은 상기 개발자에 의해 상기 애플리케이션 스토어에 제출(submit)된 특정 애플리케이션들에 관련된 상기 문제들에 관한 상기 데이터에 대한 정보를 포함한다.

Description

버그 클리어링 하우스{BUG CLEARING HOUSE}

본 출원은 2010년 5월 19일에 가출원되고, 그 명칭이 "버그 클리어링 하우스"인 미국 가출원번호 제61/346,453에 대해 우선권을 주장하며, 이 미국 출원의 모든 내용은 본 명세서에 참조로서 포함된다.

본 명세서는 소프트웨어 애플리케이션들의 문제(problem)에 관한 정보의 관리 및 배포(distribution)에 관한 것이다.

소프트웨어 개발은 어려운 일이다. 예비 소프트웨어 개발자는 먼저 소프트웨어를 구조화하고 프로그래밍하는데 스스로를 단련시켜야만 한다. 이어, 그들은 끊임없이 변화하는 프로그래밍 언어와 기술에 대해 최신으로 유지해야만 한다. 그들은 아이디어를 가지고 있어야만 한다. 이어, 개발자들은 타겟 컴퓨팅 플랫폼에서 사용할 수 있고, 자신의 시간과 재정적 제약 내에서의 프로그래밍을 통해 그 아이디어를 구현하는 방법을 알아낼 필요가 있다. 이에 더하여, 그들은 사람들이 다른 설정으로 프로그램을 테스트하게 하여, 그 프로그램에 있는 버그(bug)들을 해결하기 위해 수정들을 행할 필요가 있다. 개발자는 이어 그 소프트웨어의 가격을 결정하고 배포하며, 사람들이 그 프로그램에 흥미를 갖도록 하는 방법을 알아내야만 한다.

어드밴스드 프로그래밍 환경(advanced programming environments)은 이러한 문제들 중 일부의 해결하도록 돕는다- 즉, 그들은 코드의 구조화 및 타이핑을 더욱 자동화한다. 이에 더하여, 최근 출현한 무선 컴퓨팅 디바이스(예컨대, 스마트 폰 및 넷북)를 위한 온라인 앱 스토어들은 소규모 개발자들이 소프트웨어를 거래하고 판매하는 것을 보다 쉽게 하였다. 이러한 양측의 발전은 소프트웨어 개발자들과 그들의 소프트웨어를 구매하는 사람들이 더 나은 삶을 살 수 있게 하였다. 하지만, 소프트웨어 개발자의 삶은 힘든 삶이다. 예를 들어, 프로그램의 사용자들로부터 피드백을 얻고, 효율적인 방식으로 그 피드백을 분석하는데는 여전히 어려움이 있다. 예를 들어, 많은 개발자들은 구매자들이 피드백을 제공할 수 있게 하는 이메일 링크를 애플리케이션과 함께 제공한다.

본 명세서는 소프트웨어 개발자들, 및 특히 무선 모바일 컴퓨팅 디바이스(예컨대, 스마트폰)의 사용자들을 위한 3자 온라인 앱 스토어를 통해 애플리케이션들을 판매하고 배포하는 소프트웨어 개발자들을 위하여, 문제 또는 버그의 레포트(report)를 관리하기 위한 시스템 및 기술들을 논의한다. 예를 들어, 개발자는 공용 앱 스토어(public app store)를 제공하는 시스템에 등록된 개인 프로그래머로서, 친숙하고 잘 알려진 모든 방식으로, 앱 스토어로부터 구매를 하기 위해 등록되어 있는 일반 회원(members of public)들을 대상으로 애플리케이션들을 배포하기 위해 앱 스토어에 애플리케이션들을 업로드할 수 있다. 하나 이상의 모바일 컴퓨팅 디바이스에 실행하는 운용 시스템 및/또는 특정 소프트웨어 애플리케이션들은 문제 또는 버그(예컨대, 애플리케이션이 기능을 크래쉬(crash), 프리즈(freeze)하거나, 과도한 양의 전력을 소비하거나, 또는 디바이스의 사용자가 수동으로 문제를 보고하거나 또는 그 애플리케이션을 개선하기 위한 아이디어를 보고하는 것)가 있을 때, 정보를 수집하도록 프로그램될 수 있고, 그 앱 스토어와 연관되어 그 앱 스토어를 운영하는 동일한 조직에 의해 운영되는 보고 서브-시스템에 그 문제에 관한 데이터를 전송할 수 있다.

레포팅 서브-시스템은 이러한 각 입력 버그 레포팅 제출(디바이스에 의해 자동으로 생성되거나 또는 디바이스의 사용자에 의해 수동으로 생성되었지 여부)과 문제가 관련되는 컴퓨터 애플리케이션(예컨대, 열렸던 애플리케이션 또는 동작 정지하거나 기능 멈춤이 발생했을 때 운영 시스템의 진원지(focus))을 상관시키고, 그 문제를 특성화하는 정보를 저장할 수 있다. 정보는 그 애플리케이션과 연관되도록, 확장에 의해, 애플리케이션의 개발자와 함께 저장될 수 있다. 개발자(앱 스토어에 그 소프트웨어를 제공한 개인 또는 그 개인의 에이전트일 수 있음)가 그 시스템에 다음에 로그온하면, 개발자는 그들이 업로드한 소프트웨어 애플리케이션들에 관한 레포트들을 풀업할 수 있는데, 상기 레포트는 이러한 각 소프트웨어 애플리케이션에 대한 모든 레포팅된 문제들에 대한 모든 데이터를 수집하고, 또한 그 애플리케이션들이 갖는 문제의 본질 및 정도를 보여준다.

이러한 레포트들은 예컨대, 그 문제를 경험하고, 상응하는 데이터를 생성한 모바일 컴퓨팅 디바이스의 사용자에 대해 프라이버시를 보호하기 위하여, 레포팅 서브-시스템에 의해 그 레포트들로부터 제거되는 특정 정보를 가질 수 있다. 서브 시스템이 개발자에게 제공하는 정보의 레벨은 또한 서브 시스템이 갖는 개발자와의 신뢰 레벨(level of trust)에 따라 달라질 수 있다. 또한, 사용자들은 공유될 수 있는 정보의 관련 레벨을 통지받을 수 있고, 정보의 이러한 사용을 허용 또는 거부할지를 선택할 수 있다.

레포트들은 하나의 애플리케이션 또는 애플리케이션들에 대한 문제들의 발생 빈도를 나타내는 요약 레포트들, 애플리케이션에 대한 특정 유형의 모든 문제를 목록화하고, 그 문제를 기술하는 데이터를 제공하는 에러 레포트(예컨대, 코드의 어느 부분에서 문제가 발생되었는지), 및 문제가 디바이스상에서 발생했을 때, 각 컴퓨팅 디바이스의 상태에 대한 정보를 보여주는 스택 트레이스(stack trace) 등과 같은 다양한 형식을 취할 수 있다.

이에 더하여, 시스템은 3자 제공자들을 위해, 보다 폭넓게 유용한 다수의 애플리케이션들 전역에서 데이터를 생성할 수 있다. 예를 들어, 앱 스토어를 운영하고 또한 앱 스토어를 액세스하는 모바일 디바이스용 운영 시스템을 제공하는 기관의 경우, 다수의 애플리케이션들을 위한 문제 데이터는 수집 데이터 및 운영 시스템에 대해 문제가 있는지 여부를 판단하기 위한 결과 레포트들을 생성하기 위한 다양한 방식으로 "롤드 업(rolled up)" 될 수 있다. 예를 들어, 이러한 데이터가 다수의 다른 애플리케이션들이 특정 운영 시스템 서비스 또는 인터페이스를 액세스할 때 동작 정지를 경험했다는 것을 나타내면, 3자-제공자는 그 서비스 또는 인터페이스에 대한 문제일 수 있다는 경보를 받을 수 있다.

일 구현예에서는, 소프트웨어 문제 레포트들을 관리하기 위한 컴퓨터 구현 시스템이 논의된다. 이 시스템은 다수의 다른 개발자 조직으로부터 소프트웨어 개발자들을 등록하기 위한 등록 서브시스템을 포함한다. 이 시스템은 복수의 애플리케이션 개발자로부터의 복수의 애플리케이션을 일반 회원들이 구입할 수 있게 하는 애플리케이션 스토어를 더 포함한다. 이 시스템은 또한 상기 애플리케이션 스토어를 이용하여 배포된 애플리케이션들에 대한 문제들의 레포트들을 수신하고, 상기 문제들에 관한 데이터를 수신하고, 및 상기 데이터를 특정 애플리케이션 또는 상기 특정 애플리케이션의 개발자와 연관시키도록 프로그램된 애플리케이션 버그 추적기(application bug tracker)를 포함할 수 있다. 추가적으로, 이 시스템은 하나 이상의 애플리케이션을 제공한 개발자를 위하여 하나 이상의 문제 레포트를 생산하는 레포트 생성기―상기 문제 레포트들은 상기 개발자에 의해 상기 애플리케이션 스토어에 제출된 특정 애플리케이션에 관련된 상기 문제들에 관한 상기 데이터에 대한 정보를 포함함―를 포함한다.

구현예들은 후술하는 특징 중 임의 또는 모두 포함하거나, 아무것도 포함하지 않을 수 있다. 문제들의 레포트는 애플리케이션 크래쉬, 애플리케이션 프리즈, 과다 배터리 사용, 및 수동으로 인보크된 컴퓨팅 디바이스 사용자 코멘트들로 구성되는 그룹으로부터 선택되는 문제들을 포함할 수 있다. 또한 이 시스템은 문제들의 레포트가 특정 컴퓨팅 디바이스 모델 또는 컴퓨터 운영 시스템에 대한 문제들을 나타내는지 여부를 식별하기 위해, 다수의 애플리케이션의 전체에 걸쳐 문제들의 레포트들을 분석하도록 프로그램된 버그 분석기를 포함할 수 있다. 버그 분석기는 특정 컴퓨팅 디바이스 모델 또는 운영 시스템 버전에 대해 통계적으로 더 높은 레포팅 빈도수를 식별함으로써, 문제들의 레포트들이 특정 컴퓨팅 디바이스 모델들 또는 컴퓨터 운영 시스템에 대한 문제들을 나타낸다는 것을 더 식별할 수 있다. 상기 시스템은 신뢰 레벨(trust level)에 기초하여 상기 개발자에게 제공되는 정보를 제한하도록 마련(arrange)될 수 있는데, 상기 신뢰 레벨은 상기 특정 애플리케이션의 사용자들에 관하여 얼마나 많은 정보를 식별하는 것이고, 상기 특정 애플리케이션은 상기 개발자가 획득하도록 인증받은 것이다. 시스템은 추가로 상기 개발자가 특정 문제가 발생된 디바이스용 운영 시스템을 관리하는 조직으로부터의 코어 애플리케이션의 개발자인지 여부에 기초하여 상기 개발자에게 제공되는 정보를 제한하도록 프로그램될 수 있다.

또한, 시스템은 문제의 종류에 따라서 문제들에 관한 정보를 그룹화하도록 마련될 수 있다. 시스템은 특정 문제가 발생된 디바이스에 대한 운영 시스템 식별자 및 디바이스 유형을 나타내는 정보를 제공하도록 마련될 수 있다. 이 시스템은 개발자들로부터 애플리케이션들의 업로드를 수락하고, 상기 업로드된 애플리케이션들의 각 애플리케이션과 상기 애플리케이션이 업로드된 개발자 계정을 상관시키는 개발자 업로드 인터페이스를 더 포함할 수 있다. 시스템은 특정 개발자들에 대한 다른 버그들이 발생한 비율(rate)로부터 결정되는 강도 레벨(severity level)에 의해 분류된 버그들을, 상기 개발자에게 제시하도록 프로그램될 수 있다.

일 양태는, 소프트웨어 문제 레포트들을 관리하기 위하여 컴퓨터로 구현하는 방법은 중앙 서버 시스템에서, 상기 중앙 서버 시스템으로부터 떨어져 있는 복수의 다른 컴퓨팅 디바이스로부터 복수의 소프트웨어 애플리케이션 문제 레포트를 수신하는 단계를 포함한다. 이 방법은 상기 문제 레포트들 중 특정한 하나를 특정 소프트웨어 개발자들에 의해 제공된 특정 애플리케이션과 연관시키는 단계를 더 포함한다. 이에 더하여, 이 방법은 상기 특정 개발자들 중 한 명의 개발자로부터 식별 정보(identification information)을 수신하는 단계를 포함한다. 또한, 이 방법은 상기 식별 정보의 수신에 응답하여, 상기 특정 개발자 중 한 명에게 상기 한명의 개발자에 의해 상기 중앙 서버 시스템으로 관리되는 상기 특정 애플리케이션들에 대한 문제 레포트들을 기술하는 정보를 제공하는 단계를 포함한다.

구현예들은 후술하는 특징들 중 임의 또는 모두 포함할 수 있고, 아무것도 포함하지 않을 수도 있다. 소프트웨어 애플리케이션 문제 레포트들은 프리즈, 크래쉬, 및 사용자 생성 코멘트들에 관련된 레포트들을 포함할 수 있다. 추가로 소프트웨어 애플리케이션 문제 레포트들은 특정 문제 레포트를 생성한 디바이스에 대한 트레이스 데이터, 및 상기 디바이스의 구성에 관한 정보(information about configuration)를 포함할 수 있다. 본 발명은 복수의 소프트웨어 개발자로부터 소프트웨어 애플리케이션 업로드들을 수신하는 단계, 각 애플리케이션을 상기 애플리케이션에 대한 개발자 계정에 상관시키는 단계를 더 포함할 수 있다.

하나 이상의 실시에 대한 상세 설명은 첨부 도면과 후술하는 상세한 설명에서 개시된다. 다른 특징들 및 장점들은 상세한 설명 그리고 도면, 및 청구 범위로부터 명백해질 것이다.

특정 구현예에서, 이러한 시스템들 및 기술들은 하나 이상의 이점을 제공할 수 있다. 예를 들어, 개발자들은 단지 특정 개발 환경을 사용함으로써, 자신의 버그 트래킹 시스템들을 셋업해 놓은 높은 수준의 회사(sophisticated company)에서만 가능할 수 있는 진단 능력(diagnostic capabilities)을 제공받을 수 있다. 디바이스들의 사용자들은 다양한 개발자들로부터 개량된 애플리케이션을 수신할 수 있고, 다수의 다른 개발자로부터 다수의 다른 애플리케이션 전체에 일관되는 편리한 방식으로 버그들을 보고받을 수 있다. 그리고 운영 시스템 및/또는 연관된 앱 스토어와 같은 플랫폼의 제공자는 개발자 및 디바이스의 다른 사용자들에게 그것의 플랫폼에 대한 바람직성(desirability)을 향상시킬 수 있다.

도 1a은 다수의 개발자로부터의 소프트웨어를 배포하고, 소프트웨어의 동작에 대한 정보를 수집하기 위한 시스템(100)을 나타내는 개념도이다.
도 1b는 소프트웨어 애플리케이션들의 동작에 대한 피드백을 제공하기 위한 동작들을 나타내는 플로우 다이어그램이다.
도 2는 디바이스상의 소프트웨어 애플리케이션들의 동작에 관한, 컴퓨팅 디바이스들로부터의 제출들을 추적하기 위한 시스템(200)의 개략도이다.
도 3은 소프트웨어 문제 레포트들을 관리하기 위한 프로세스의 순서도이다.
도 4는 복수의 개발자들로부터 소프트웨어와 함께 문제들의 제출들을 관리하는 프로세스의 스윔 레인 다이어그램이다.
도 5a와 도 5b는 소프트웨어 애플리케이션의 동작적 문제들을 경험하고 있는 모바일 컴퓨팅 디바이스의 예시적 스크린샷들이다.
도 6a-도 6c는 소트프웨어 트래킹 시스템에 의해 생성된 개발자 레포트들의 예시적 스크린샷이다.
도 7은 본 명세서에서 설명된 기술들에 사용될 수 있는 일반적인 컴퓨터 디바이스와 일반적인 모바일 컴퓨터 디바이스의 예시를 나타낸다.

본 명세서는 소프트웨어 애플리케이션들의 동작에 대한 피드백을 제공하기 위해 사용될 수 있는 다양한 시스템들 및 기술들을 논의한다. 특정 예시로서, 서로 독립적인 분산된 그룹의 소프트웨어 개발자들(예컨대, 같은 회사에서 근무하지 않거나, 동일한 도메인으로부터 운용하지 않거나, 공통 소프트웨어 개발 시스템을 공유하지 않음)이 컴퓨팅 디바이스의 다양한 사용자들이 자주 애플리케이션을 구매하거나 라이센싱하기 위해 지불하면서, 애플리케이션을 검토하고 다운로드하는 앱 스토어(각각의 개발자들은 그 결제의 몫을 받음)에 자신의 소프트웨어 애플리케이션들을 업로드할 수 있다. 디바이스상의 운영 시스템은 스택 트레이스를 유지하고, 디바이스에 버그와 같은 문제가 있을 때, 중앙 서버 시스템에 이러한 정보를 보고하는 것을 포함하여, 디바이스상의 전형적인 에러 처리를 수행할 수 있다. 이러한 정보는 구제 조치(remedial measures)가 행해지고, 관련 소프트웨어 코드가 수정되어 업데이트될 수 있도록 하기 위해, 프로그램의 소스를 진단하기 위한 시도로 훈련된 개인들에 의해 일반적으로 사용된다.

본 명세서에 설명된 예시에서는, 다양한 컴퓨팅 디바이스로부터 제출된 데이터의 일부는 문제를 야기하였거나 문제가 발생했을 때 활성화된 코드를 제출한 개발자에 의해 검토할 수 있도록 만들어질 수 있다. 이러한 동작은 문제가 발생했을 때, 관련 애플리케이션 또는 애플리케이션들을 식별하고, 중앙 서버 시스템에, 애플리케이션 또는 애플리케이션들을 식별하는 정보와 함께 문제에 대한 정보를 제출하는 운영 시스템에 의해 발생할 수 있다. 중앙 서버 시스템은 이어 소프트웨어 애플리케이션 식별자와 연관지어 데이터를 저장할 수 있고, 이러한 식별자는 애플리케이션의 개발자를 식별하기 위하여 추가로 사용될 수 있다. 이러한 개발자(앱 스토어 또는 운영 시스템의 운영자와 완전하게 다른 개인 또는 기관일 수 있음)가 시스템에 로그(log)하여, 자신의 코드에 대한 문제 레포트를 요구하면, 시스템은 특정 개발자들에 대한 모든 데이터를 찾기 위하여, 문제 데이터가 저장된 데이터베이스를 쿼리할 수 있고, 다양한 방식으로 그 데이터를 필터링 및 그룹화한 하나 이상의 레포트들을 생성할 수 있다. 일 예시로서, 개인 식별가능 정보는 그 레포트에 대해 제공되는 데이터로부터 제거되거나 익명화(obscured)될 수 있다. 또한, 데이터는 각 애플리케이션에 따라 분류될 수 있어, 개발자가 많은 이러한 애플리케이션을 가지고 있다면, 자신이 가지고 있는 애플리케이션 각각의 관련 동작에 대한 이해를 빠르게 획득할 수 있게 한다.

도 1a은 다수의 개발자로부터의 소프트웨어를 배포하고, 소프트웨어의 동작에 대한 정보를 수집하기 위한 시스템(100)을 나타내는 개념도이다. 일반적으로, 시스템(100)은 개발자 그룹과 사용자 그룹(여기서, 물론 특정 개발자는 사용자일 수 있고, 그 반대의 경우도 가능함)의 사이에 있는 중앙 서버 시스템을 포함한다. 중앙 서버 시스템은 개발자로부터 소프트웨어 코드 업로드들을 수신하고, 사용자들에게 코드 다운로드를 제공하고, 그 사용자들로부터 오류 또는 문제 데이터를 수신하고, 개발자들에게 제시하기 위해 이러한 정보를 필터링하고 체계화한다.

지금부터 이 도면을 보다 자세하게 참조하면, 이 도면에서 중앙 서비스 시스템은 애플리케이션 센터(102)의 형태로 도시되어 있다. 애플리케이션 센터(102)는 사용자 센터(108)와 개발자 센터(110)를 구성하는 물리적 및 논리적 구성요소들을 포함한다. 이러한 구성요소들은 예를 들어, 사용자들 및 개발자들 각각에게 서비스를 제공하기 위한 사용자 인터페이스들을 생성하는 프론드 앤드 또는 웹서버들을 포함할 수 있다. 사용자 센터(108)는 이 예시에서 애플리케이션 센터(102)의 운영자에 의해 개발된 특정 소프트웨어 운영 시스템을 구동하는 모바일 전화기 또는 앱 폰을 갖고 있는 각 개인인 사용자들(104)과 통신한다. 운영 시스템와 함께 제공되는 서비스의 일부 또는 전체로서, 운영자는 모바일 디바이스용 소프트웨어 애플리케이션의 검토 및 구매가 가능한 애플리케이션 센터(102)를 만든다. 따라서 예를 들어, 사용자 A(10대)는 많은 비디오 게임을 다운로드할 수 있고, 사용자 B(예컨대, 비지니스 여성)은 호스트되는 클라우드 기반 컴퓨팅 플랫폼을 사용하는 다양한 비지니스 애플리케이션을 다운받을 수 있으며, 사용자 C(예컨대, 대학생)은 수학 모델링 애플리케이션과 함께, 전자책(e-book) 리더 애플리케이션(많은 전자책 텍스트북과 함께) 및 다양한 테스트 준비 애플리케이션들을 다운받을 수 있다. 각각의 경우, 관련 사용자는 자신의 다운로드된 애플리케이션들 각각을 실행시키고(자신의 전화에 탑재된 애플리케이션들을 보완할 수 있음) 친숙한 방식으로 그 애플리케이션들과 상호 동작할 수 있다. 또한, 필요가 생김에 따라, 추가 애플리케이션을 찾아 다운로그하기 위해, 애플리케이션 센터(102)를 재방문할 수 있다.

가끔, 문제들이 사용자들(104) 디바이스의 각각에서 발생할 수 있다. 예를 들어, 사용자는 동시에 다수의 애플리케이션을 구동할 수 있고, 그 애플리케이션들 중 하나가 크래쉬되게 하는 메모리 오버플로우 상태를 만들 수 있다. 대안적으로, 애플리케이션은 자신을 락업하게 하는 동작을 수행하여, 사용자가 애플리케이션이 실행되고 있는 프로세서를 닫게 할 필요가 있을 것이다. 대안적으로, 디바이스의 사용자는 문제 제출 프로세스를 인보크(invoke) 할 수 있는데, 이 문제 제출 프로세스는 사용자가 애플리케이션에 있는 에러를 식별하거나 그 애플리케이션에 대해 개선된 특징들을 제안하기 위한 양식을 적을 수 있게 한다. 이러한 인스턴스 각각 및 유사한 인스턴스들은 그것들이 그 애플리케이션에 대하여 그 애플리케이션의 개발자들에게 제공해야 할 문제들을 나타낸다는 점에서(사용자단에서, 운용 체제, 디바이스 하드웨어, 또는 다른 애플리케이션에 기인하는지가 결정됨으로써), 본 명세서에서 버그들로 집합적(collectively)으로 기술될 수 있다.

본 명세서에서 제시된 바와 같이, 애플리케이션들은 예컨대, 웹 사이트와 같은 친숙한 방식을 갖는 앱 스토어(112)로부터 획득될 수 있는데, 이 웹 페이지에는 3자에 의해 제출된 애플리케이션들이(앱 스토어(112)의 운영자에 의해 제출된 1단계(first-tier) 애플리케이션들 외에도) 웹 페이지의 일부로서 디스플레이될 수 있으며, 그 웹 페이지에는 컨트롤(control)들도 함께 디스플레이된다. 이 컨트롤들은 사용자에 의해 선택되었을 때, 시스템(100)에 사용자의 계정으로 로그인되어 있는 디바이스에, 특정 선택된 애플리케이션이 공급되게 하거나 다운로드되게 한다.

또한, 사용자 센터(108)는 버그 수집기(116)를 포함하는데, 버그 수집기(116)는 직접, 또는 애플리케이션들의 인스턴스들의 동작에 대해 보고하는 운영 시스템 구성요소들을 통해 사용자들(104)의 디바이스에 배포되는 애플리케이션의 인스턴스들과 자동적으로 통신하기 위한 구성요소들을 포함한다. 또한, 버그 수집기는 예컨대, 제출 시간과 날짜, 디바이스의 운영 시스템 및 버전, 디바이스의 제조사 및 모델, 문제 이벤트가 발생했을 때 디바이스에서 실행하고 있었던 다른 애플리케이션들, 최근 디바이스 액티비티의 트레이스들, 디바이스에 대한 구성 데이터, 및 다른 유사한 정보와 같은 정보들을 포함하는 하나 이상의 데이터 베이스에 데이터를 마련(arrange)함으로써, 고정식 저장소(persistent storage)를 위해 수집된 정보를 리포맷할 수 있다.

애플리케이션 센터(102)의 다른 "측면"은 사용자들(104)과 같이, 다수이면서 지리적으로 흩어져 있을 수 있는 개발자들(106)을 향한 것이다. 특히, 사용자들(104)과 개발자들(106)은 전세계에 흩어져 있을 수 있으며, 인터넷을 포함하는 다양한 네트워크들을 통해서 애플리케이션 센터(102)에 액세스할 수 있다. 일 예시로서, 시스템(100)은 수천 또는 수만의 액티브 개발자들(106)을 가질 수 있고, 수십만 또는 수백만(또는 심지어 수억)의 액티브 사용자들(104)을 가질 수도 있다. 본 명세서에서 기술된 기술들은 더 많은 사용자 데이터를 각 개발자들에게 제공할 수 있기 때문에, 대규모 개발자 베이스들을 갖는 이러한 시스템에서 특히 잘 동작하는데, 이러한 시스템에 있는 개발자들은 소규모일 가능성이 높고, 자신의 버그 레포팅 시스템들을 개발할 수 없을 가능성이 높다.

개발자 센터(110)에 있는 제1 주요 구성요소는 앱 관리자(114)이다. 이 구성요소는 사용자들을 위한 앱 스토어(112)의 다른 면(flip-side)일 수 있다. 특히, 앱 관리자(114)는 웹 서버와 연관된 소프트웨어를 포함할 수 있는데, 이 소프트웨어는 개발자 스스로 시스템(100)의 정당한 개발자 회원들로서 등록하고, 후에 자신들이 제작하고 그들이 상업적 배포를 관리하고 있는 애플리케이션의 코드를 업로드하기 위해, 개발자들이 액세스하여 상호 동작할 수 있다. 또한, 앱 관리자(114)는 개발자들과 상호 동작하여 그 개발자들이 자신의 애플리케이션들을 편리하게 관리할 수 있게 하기 위한, 일반적으로 잘 알려진, 다수의 추가 서비스들을 제공할 수 있다.

버그 레포터(118)는 버그 수집기(116)에 대한 개발자측 상대로서 기능하고, 소프트웨어 배포와 개발자들(106)에서 시작하고, 앱 관리자(114)와 앱 스토어(112)로 이동하고, 이어서 그 애플리케이션을 획득하고 실행하는 사용자들(104)에게 이동한 후, 소프트웨어에 문제가 발생했을 때(긍정적인 개발자들이 기회로서, 그것들을 참조할 수 있지만) 버그 수집기(116), 버그 레포터(118), 및 개발자들(106)에 되돌려주는 피드백 사이클(feedback cycle)을 완료한다.

특히, 버그 레포터(118)는 웹 서버 시스템이 개발자들(106)과 상호 동작하게 하고, 각각의 개발자들에게 상응하는 애플리케이션에 관하여, 사용자들(104)의 디바이스들에 의해 경험된 문제들에 대한 데이터를 제공할 수 있는 레포트 생성 기능을 제공할 수 있다. 레포트들은 표준(standard) 또는 맞춤 포맷(custom format)으로 된 것일 수 있다. 표준 레포트들은 애플리케이션 센터(102)의 운영자에 의해 개발될 수 있고(여기에서는 단일 엔티티로 도시되었지만, 서로가 협업(cooperation)하여 작업하는 복수의 서로 다른 조직들에 의해 운영될 수도 있음), 그들의 애플리케이션 각각이 어떻게 수행되고 있는지를 확인하고자 하는 개발자들에 의해 액세스되어 쉽게 생성될 수 있다. 맞춤 레포트들은 각각의 개별 개발자들에 의해 형성될 수 있고, 잘 알려진 그래픽 레포트 개발 도구들을 사용할 수 있다. 예를 들어, 개발자는 자신의 레포트들에서 보고자하는 데이터의 특정 필드들을 선택할 수 있고, 자신의 레포트들의 시각적 스타일(visual look)을 정의할 수 있다. 또한, 그들은 로우 데이터(raw data)의 형태로 된 레포트들을 수신할 수 있고(레포팅 사건(reporting incidents)으로서 배치 형태(batch form) 및 실시간으로 사용자들(114) 사이에서 발생함), 데이터를 조작 및 레포트할 수 있는 자신만의 기능들을 사용할 수 있다. 또한, 개발자들(106)은 자신이 확인하고 싶은 집합한 레포트(aggregate report)들을 정의할 수 있다. 예를 들어, 개발자들이 제품의 묶음(suite of product)(예컨대, 비지니스 생산성 제품군(business productivity suite))을 개발하였으면, 그들은 그 제품군의 구성요소 각각에 공통하는 파라미터들에 대한 섹션을 포함하는 레포트를 원할 수 있고, 구성요소들 각각 및 특정 구성요소에 대해 특정(specific)되는 데이터를 위해 세션들을 분리시키고 싶어할 수 있다.

이러한 방식들에서, 시스템(100)은 개발자들(106)에게 주의가 필요할 수 있는 개발자들의 소프트웨어에 있는 버그들에 관련된, 광범위(extensive)하고 유용하게 포맷된 데이터를 제공할 수 있다. 특정 개발자는 소정 데이터를 얻기 위하여(운영 시스템이 애플리케이션이 실행되었을 때, 그 애플리케이션을 식별할 수 있는 메카니즘을 제공하는 것 외에) 자신의 소프트웨어에 대하여 아무것도 하지 않아도 된다. 소정 경우들에, 개발자들은 추가 데이터가 예컨대, API를 통해 레포트되도록 할 수 있지만, 다시 말하지만, 개발자가 버그 제출(bug submission)들을 수신하고, 클라이언트 디바이스상에서 데이터를 모으고, 전체 애플리케이션 유지관리 시스템을 달리 구현하기 위하여 전체 시스템을 구현할 필요가 없다. 그 결과, 초보 개발자들은 자신의 애플리케이션들을 개선시키는 프로그램의 혜택을 받을 수 있고, 결국 그 애플리케이션의 소비자들도 이득이 된다.

도 1b는 소프트웨어 애플리케이션들의 동작에 대한 피드백을 제공하기 위한 동작들을 나타내는 플로우 다이어그램이다. 일반적으로, 여기에는 예시를 설명하기 위하여 왼쪽 상단 코너에서 시작하여 오른쪽 아래 코너에서 끝나는 그래픽 시간선(timeline)이 도시되어 있는데, 그 예시는 애플리케이션 개발자가 대중들이 이용할 수 있는 자신의 소프트웨어 애플리케이션을 만들 수 있고, 그 애플리케이션의 동작에 대한 피드백을 수신할 수 있고, 그로써 그 애플리케이션을 빠르고 신속하게 향상시킬 수 있는 것이다.

동작(120)에서, 애플리케이션 개발자는 애플리케이션을 모바일 애플리케이션 마켓에 제출(submit)한다. 제출은 다양한 적절한 형태로 발생할 수 있고, 개발자는 애플리케이션을 합법화하고, 시스템에 보안을 제공하는데 도움을 주는 자체-서명 인증서(self-signed certificate)를 애플리케이션에 제공할 수 있다. 동작(122)는 동일한 개발자 또는 다른 개발자들에 의해 이전에 업로드되었을 수 있는 3개의 다른 애플리케이션과 함께, 모바일 애플리케이션 마켓에 애플리케이션이 있음을 나타낸다. 애플리케이션들의 "소유권"은 그 애플리케이션과 그 애플리케이션을 업로드한 사용자의 계정을 상관시킴으로써 유지관리될 수 있는데, 그 사용자는 일반적으로 실제 개발자 또는 그 개발자를 대신하여 작업하는 임의 사람일 수 있다.

동작(124)에서, 모바일 컴퓨팅 디바이스(예컨대, 스마트폰 또는 앱 폰)의 사용자는 모바일 애플리케이션 마켓을 방문하여, 자신의 계정으로 시스템에 로그인 함으로써 자신을 확인하였다. 이어, 사용자는 동작(120)에서 업로드된 애플리케이션을 선택하고, 이 분야에서 잘 알려진 방식으로, 그 애플리케이션을 설치(install)하여 모바일 디바이스의 사용자가 실행할 수 있는 준비가 되었다.

동작(126)에서, 폭발 아이콘은 애플리케이션이 모바일 디바이스상에서 구동하는 동안, 에러의 발생을 나타낸다. 에러는 크래쉬(crash) 또는 락킹 상황(locking situation)을 관계된 것이거나 애플리케이션에 관련되는 피드백을 제공할 의도를 수동적으로 나타내는 디바이스의 사용자로부터의 결과일 수 있다. 이러한 이벤트는 예컨대, 디바이스상에서 실행하는 운영 시스템 구성요소에 의해, 이벤트에 대한 진단 정보(diagnostic information)가 디바이스상에 모아지게 할 수 있다.

동작(128)에서, 에러에 관련된 레포트가 모바일 디바이스(128)상에서 생성된다-모바일 디바이스의 동작 및 그 디바이스상의 다양한 애플리케이션의 동작을 관리하였던 운영 시스템의 컨트롤 하에서 발생할 수 있는 액션. 예를 들어, 운영 시스템은 프로세스가 디바이스상에서 성공적이지 않게 끝났을 때를 인식하도록 프로그램될 수 있고, 이러한 이벤트는 운영 시스템이 동작들을 모아서 포맷팅하는 복수의 데이터를 트리거할 수 있다. 예를 들어, 다른 앤티티, 레스터들, 스택들, 또는 트레이스들의 현재 내용은 에러가 발생했을 때, 디바이스상에서 실행중이던 모든 소프트웨어 구성요소들에 대한 식별자로서, 판단될 수 있다. 이어, 이러한 정보는 동의한 표준(agreed-upon standard)에 따라서 정보의 기정의된 패킷 내에 함께 모아질 수 있다.

동작(130)에서, 레포트 또는 제출은, 적어도 개념적으로, 이러한 레포트들을 추적하고 레포팅을 담당하는 중앙 서버 시스템상에 존재하는 것으로 도시되어 있다. 이 예시에서, 레포트는 애플리케이션에 대한 특정 버그에 상응하는 것으로 분류될 수 있는데, 여기서는 3개의 다른 버그들이 식별된다. 이러한 분류는, 특정 레포트들이 버그 레포트를 생성할 때 함께 결합되도록 하기 위해, 예를 들어, 관련 에러가 발생되었을 때 코드의 어떤 부분이 실행중이었는지를 식별하고, 그 코드의 해당 부분에 대한 식별자를 제공함으로써 행해질 수 있다. 특정 에러 제출에 부과되어야 할 버그들의 식별은 또한, 버그 추적 시스템의 사용자에 의한 수동 분류에 의한 것을 포함하는 다른 방식들로 수행될 수 있다. 여기에서 도시된 것처럼, 2개의 버그들이 식별되었고, 그것들의 버그에 대해서 각각 2 및 3개의 에러 제출이 있었다. 따라서, 이 예시에서는, 시간 기간이 경과하면, 초기 애플리케이션이 8개의 다른 에러 제출에 상응하는 것으로 식별된다.

*이러한 정보는 애플리케이션의 개발자들이 알아야할 중요한 것일 수 있다. 예를 들어, 3개의 버그 중 하나는 애플리케이션의 사용자들의 만족도에 대해 중요할 수 있다. 만약 개발자가 이러한 버그들의 본질(nature)을 쉽게 알 수 있다면, 개발자는 그것을 빠르게 수정하여 코드를 위한 "패치(patch)"를 제공할 수 있을 것이며, 그 패치는 그 애플리케이션을 다운로드한 모든 사용자들에게 자동적으로(사용자들이 이러한 업데이트를 거부할 기회를 갖을 수도 있음) 푸쉬아웃될 수 있다.

동작(132 또는 134)에서, 이러한 개발자들은 자신들의 모든 버그 제출에 관한 레포트를 확인하는 것을 선택하였다. 이 예시에서는, 전체 시스템에서 추적되고 있는 3개의 버그가 존재하지만, 동작(134)에서 도시된 것에는, 단지 2개의 버그만이 동작(120)로부터의 애플리케이션에 연관되어 있다. 이 예시에서, 모바일 애플리케이션 마켓 또는 유사한 서브-시스템은 시스템에 의해 추적되고 있는 버그의 본질을 개발자들에게 식별시키는 정보 및 특정 에러들에 대한 정보를 보여주는 레포트를 신속하게 생성할 수 있다.

소정 경우에, 최종 레포트에 제공된 데이터는 모바일 디바이스로부터의 제출들에 업로드된 데이터와는 실질적으로 다를 수 있다. 예를 들어, 개발자들이 디바이스들의 사용자들에 대하여 특정 판단들을 행할 수 없도록 하기 위해, 개인적으로 식별가능한 정보는 업로드된 데이터로부터의 제거될 수 있다. 일 예시에서, 크래쉬 시점에 디바이스에 대한 유사한 정보 및 스택 트레이스들만이 다른 정보(예컨대, 문제가 발생했을 때 사용자가 조작하고 있었던 데이터를 반영할 수 있는 정보)를 제외하고 제공될 수 있으며, 그것들은 전달되지 않을 것이다. 또한, 상세 내용의 소정 레벨이 중앙 시스템에 관련될 수 있지만, 대부분의 개발자들에게는 관련되지 않을 수 있으며, 따라서 동작(134)에서 레포트에서 제거될 수 있다.

도 2는 이 디바이스들상의 소프트웨어 애플리케이션들의 동작에 관한 컴퓨팅 디바이스들로부터의 제출들을 추적하기 위한 시스템(200)의 개략도이다. 시스템(200)은 상술된 도 1a와 도 1b에 관련하여 논의된 것과 같은 액션들을 실행하기 위해 사용될 수 있다. 시스템(200)은 명료화를 위해 매우 간략한 형태로 도시되어 있으며, 특정 물리적 구현예는 다수의 추가 구성요소들을 포함할 수 있다.

이제 도면을 참조하면, 예를 들어 랩탑 및 데스크탑 컴퓨터를 사용하는 것으로 도시된 다양한 개발자(212)들로 시스템(200)을 도시하고 있는데, 그 개발자들은 앱 서버 시스템(202)에 애플리케이션들을 제출할 수 있고, 자신의 특정한 각각의 제출된 애플리케이션의 동작에 관한 피드백과 반환금(return money)을 수신할 수 있다. 이러한 애플리케이션들은 구매되거나 또는 다양한 사용자들(210)에 의해 획득될 수 있는데, 사용자(210)는 도 2에서 애플리케이션을 다운로드하여 실행시킬 수 있는 무선 모바일 디바이스를 통하는 것으로 도시되어 있다.

개발자들(212) 및 사용자들(210)(또는 자신의 디바이스들에 대해 더 기술적인)은 일반적으로 서로 직접적으로 통신하지 않지만, 대신에 인터넷과 같은 네트워크(204)를 사용하여 앱 서버 시스템(202)을 통해 통신할 수 있다. 이러한 개방형 통신(open communication)은 광범위한 개발자 유형들 및 사용자들이 시스템(200)을 사용할 수 있도록 허용할 수 있다.

앱 서버 시스템(202)에 있는 특정 구성요소들은 시스템(200)이 소프트웨어 애플리케이션들을 효율적으로 사용(deploy)하게 하고 그 소프트웨어 애플리케이션의 사용을 추적할 수 있는 기능을 제공할 수 있다. 예를 들어, 마켓플레이스 프론트앤드(214)는 사용가능한 애플리케이션들을 사용자들(210)에게 디스플레이하는 사용자 인터페이스를 생성할 수 있고, 그 사용자가 이러한 애플리케이션들을 검토, 사용 시도(try), 및 다운로드하도록 허용할 수 있다. 마켓플레이스 관리자(218)는 구매들을 추적하고, 사용자들(210)에 대한 청구서 발행과 개발자들(212)에 대한 송금(remittance), 및 앱 스토어 구현의 잘 알려진 다른 기능들을 생성함으로써, 마켓플레이스 프론트 앤드(214)를 위한 백앤 서포트(backend suppore)를 제공할 수 있다.

개발자 프론트 앤드(216)는 개발자들이 시스템(200)에 등록할 수 있도록 승인하는 사용자 인터페이스를 생성할 수 있고, 애플리케이션들을 업로드할 수 있으며, 자신의 애플리케이션들을 관리(예컨대, 애플리케이션들을 업데이트, 추가, 및 제거하고, 애플리케이션들을 판매한 금액이 얼마나 되는지를 확인함)할 수 있고, 상기 및 하기에 설명된 것처럼, 자신의 애플리케이션의 동작에 대한 피드백을 수신할 수 있다. 이러한 피드백을 제공하는 것은, 개발자 프론트 앤드(216)가 버그 레포트 생성기(220)에 액세스할 수 있는데, 이 버그 레포트 생성기는 버그가 발생(예컨대, 상호 동작, 동작 정지, 및 수동 사용자 레포트들로서 식별되는 것처럼)한 모바일 디바이스로부터 업로딩된 데이터를 관리할 수 있다. 예를 들어, 버그 레포트 생성기는 사용자 디바이스로부터 버그 레포트 데이터를 수신하고, 그 데이터를 예컨대, 버그 저장소(222)에 저장하기 위하여 적절하게 포맷팅한 후, 개발자가 자신의 특정 애플리케이션들에 관한 레포트들의 확인을 요청하였을 때, 저장된 데이터의 모든 또는 일부를 검색하는 책임이 있을 수 있다.

버그 레포트 생성기(220) 또는 개발자 프론트 앤드(216), 또는 이 둘의 조합은 이러한 데이터를 개발자에게 전달하기에 적절하게 필터링하고 포맷할 수 있다. 예를 들어, 2개의 구성요소들이 웹 페이지를 생성하고, 그 레포트에 대한 개발자들의 요청에 응답하여 그 개발자에게 그 페이지를 전송하기 위해 협업(cooperate)할 수 있다. 마찬가지로, 개발자가 자신이 시스템(200)에 접속하고 있는 동안에, 실시간으로 버그 레포트들을 확인할 수 있도록 하기 위해, 그 데이터는 데이터의 연합된 피드(syndicated feed of data)를 요구한 개발자에게 효율적 스트림될 수 있다. 이러한 실시간 레포팅은 예컨대, 개발자에게 SMS 메시지 보내기, XML 변환들(예컨대, 개발자들이 다양한 버그 레포트들을 체계화하기 위하여 자신의 시스템에 분석 도구를 사용할 수 있게 하기 위함), 및 다른 이러한 메카니즘과 같은 다양한 방식으로 행해질 수 있다.

다양한 데이터 저장소는 또한 시스템(200)에 의해 저장, 액세스, 및 관리될 수 있는 데이터의 형태들을 예시하기 위해서, 본 도면에 도시되어 있다. 예를 들어, 상술된 것처럼, 버그 저장소는 사용자들(210)로부터 발생한 버그 레포트들에 대한 정보를 저장할 수 있다. 버그 정보는 개발자 또는 다른 기술자들이 버그가 발생했을 때 무엇이 잘못되었는지를 추론(적어도 부분적으로, 적어도 일부 시간, 또는 다른 버그 레포트들과의 조합으로)할 수 있게 하는 진단 정보를 포함할 수 있다. 버그 저장소는 또한, 소정 상황에서, 개발자들(212)이 아니고 시스템(200)에 내부적으로 액세스가능 해야만 하는 정보를 포함할 수 있다. 이러한 정보는 예를 들어, 버그 레코트 생성기(220) 및/또는 개발자 프론트 앤드(216)에 의해 적절한 방식으로 필터링될 수 있다.

신용장(credentials) 데이터베이스(224)는 개발자들(212) 및 사용자들(210)에 대한 신용장 발행 정보(credentialing information)를 저장할 수 있다. 신용장은 다양한 사람들이 자신의 계정들에 연관되는 관련 정보를 액세스하고, 시스템(200)을 통해 애플리케이션들의 구매 및 판매에 대한 금액을 지불하거나 수령할 수 있게 한다. 또한, 신용장은 소정 데이터에 대해 특정 사용자에 의한 액세스의 적절한 레벨을 결정하는데 사용될 수 있다. 예를 들어, 사용자들이 자신의 애플리케이션들과 관련된 버그들에 대한 레포트들을 요청하였을 때, 애플리케이션들의 사용자들에 대한 익명성을 유지관리하기 위하여 개인 정보가 걸러지도록, 3자 개발자들은 제한된 액세스 레벨에 연관된 신용장을 가질 수 있다. 반면, 내부 사용자들은 사용자 디바이스상의 결함에 대한 데이터에 대해서는 더 큰(greater) 액세스를 가질 수 있다.

마지막으로, 앱 데이터 스토어(226)는 개발자들(212)에 의해 업로드된 앱들과 시스템(200)의 운영자에 의해 초기에 마켓플레이스에 마련될 수 있는 앱들을 포함하는, 사용자들(210)이 이용할 수 있게 만들어진 애플리케이션들을 저장한다.

서버 시스템(202)의 외부에는, 로컬 개발자(206)가 예시적으로 도시되어 있는데, 그 로컬 개발자는 앱 서버 시스템(202)과 동일한 도메인 내에 있을 수 있고, 사설 네트워크(208)를 통해 앱 서버 시스템(202)과 통신할 수 있다. 로컬 개발자는 앱 서버 시스템(202) 운영자에 의해 신뢰받는 프로그래머(예컨대, 앱 서버 시스템을 운영하는 기관의 직원)일 수 있다. 이러한 사용자는 다양한 방식들로 앱 서버 시스템(202)에 의해 식별될 수 있고, 따라서 개발자 프론트 앤드(216)는 개발자(206)에게 에러 데이터로의 더 큰 액세스와 그 데이터를 분석하기 위해 더 강력해진 도구로의 더 큰 액세스를 제공할 수 있다. 다시 말해서, 개발자(206)는 개발자이긴 하지만, 다른 개발자들(212)과는 다른 개발자로, 시스템(200)에 의해 처리될 수 있다.

일 예시로서, 사용자들(210) 중 소정인은 앱 서버 시스템(202)을 제공하는 기관에 소정 개인적 식별가능 데이터를 제공하는 것에 동의했을 수 있지만, 그러한 정보를 3자와 공유하는 것은 거절했을 수 있다. 이러한 경우, 개발자들(212) 보다도 로컬 개발자(206)가 더 많은 정보에 액세스할 수 있을 것이다. 로컬 개발자(206)가 시스템에 가장 유용하고 보편적으로 배치되는 애플리케이션(예컨대, 워드 프로세싱 및 전자 메일)들을 자주 생성하기 때문에, 이러한 상황이 사용자들(210)의 관점에서 특히 바람직할 수 있고, 사용자들이 그들이 프로그램들을 향상시키는데 필요한 모든 것을 이러한 개발자들에게 주고 싶어할 수 있다.

도 3은 소프트웨어 문제 레포트들을 관리하기 위한 프로세스의 순서도이다. 일반적으로, 프로세스는 애플리케이션의 개발자들로부터 다양한 컴퓨터 애플리케이션들에 대한 컴퓨터 코드를 수신하는 단계와, 다운로드될 수 있고, 애플리케이션 마켓플레이스에서 일반 사용자들((members of the public)이 구매할 수 있는 애플리케이션들을 만드는 단계를 포함할 수 있다. 다양한 애플리케이션이 시스템의 등록된 사용자들을 위하여 다양한 컴퓨터상에 설치된 후에, 그 애플리케이션들이 경보(alert)들을 생성하기 시작할 수 있고(예컨대, 크래쉬나 다른 문제가 있을 때), 이러한 경보들에 대한 정보가 애플리케이션 마켓플레이스의 운영자에게 다시 전달될 수 있으며, 이 정보는 이벤트들을 갖는 특정 애플리케이션들을 제출한 상응하는 개발자들이 이용할 수 있도록 하여, 상기 개발자가 자신의 애플리케이션들에 대한 코드를 향상시키거나 편집할 수 있게 한다.

프로세스는 박스(302)에서 시작하는데, 302에서 프로세서는 개발자에 의한 애플리케이션들의 업로드를 수신한다. 개발자는 예를 들어, 재택 근무하는 개인 프로그래머일 수 있으며, 그 프로그래머는 목수용 계산기, 특정 직업용 탐색 도구, 또는 모바일 컴퓨팅 디바이스상에 실행될 수 있는 다른 유사한 애플리케이션들과 같이, 특정 분야에서의 특정 틈새 문제(niche problem)를 해결하기 위해, 간단한 애플리케이션을 제작하였다. 개발자는 대안적으로 예컨대, 애플리케이션 마켓플레이스에서 판매되는 애플리케이션들을 개발하는 사업을 하는 소규모 소프트웨어 회사와 같은, 개인들의 그룹을 포함할 수 있다. 일반적으로, 개발자는 애플리케이션을 판매함으로써 생긴 수익에 대한 정당한 청구권(rightful claim), 또는 다양한 사용자들에게 애플리케이션을 배포하여 얻어진 이익(benefit)을 갖는 단체(party)일 수 있다.

박스(304)에서, 애플리케이션은 마켓플레이스에서 입수(available)할 수 있게 만들어진다. 이러한 동작은 유사한 방법으로 행해질 수 있으며, 애플리케이션의 아이콘 및 텍스트 설명을 포스팅하는 것을 포함하는데, 이 두 가지 모두는 개발자에 의해 마켓플레이스에 제공될 것이다. 애플리케이션은 이 기술 분야에서 알려진 것처럼, 구매를 결재하여 입수할 수 있도록 만들어지거나, 무료 다운으로 입수할 수 있다록 만들어질 수도 있다.

박스(306)에서, 애플리케이션의 인스턴스들이 애플리케이션의 카피본을 수신하는 것에 대한 관심(interest)을 전달하는 구매자들에게 전달된다. 그 결과로서, 애플리케이션의 카피본이 애플리케이션 스토어 또는 마켓플레이스를 액세스하고 있는 사용자의 사용자 계정에 연관된 모바일 디바이스에 다운로드될 수 있다. 이어, 사용자는 애플리케이션을 설치하고, 그들이 애플리케이션을 구매했을 때, 또는 나중에 한번 또는 여러 번, 자신의 디바이스상에서 애플리케이션을 실행시키기 위한 적절한 액션들을 행할 수 있다. 따라서 특정 애플리케이션을 다운로드받은 디바이스의 사용자 및 그 애플리케이션을 다운로드받은 다른 사용자들이, 그 애플리케이션들에 액세스하여 그들이 설치되는 것을 보면서, 애플리케이션들과 상호 동작할 수 있다.

애플리케이션과의 이러한 상호 동작은 애플리케이션의 동작과 관련된 문제적 이슈들(problematic issue)을 야기할 수 있다. 이러한 이슈 중 하나는 애플리케이션(또는 애플리케이션이 실행중인 프로세스)의 상호 동작 또는 종료(hang-up)로 이어질 수 있는 애플리케이션의 오작동을 포함한다. 다른 이슈는 사용자에 의한 애플리케이션에 대한 불만족일 수 있는데, 그 이유는 애플리케이션이 잘못 수행하고 있거나, 또는 사용자가 그 애플리케이션이 소정 개선사항들로 더 낫게 수행할 수 있다고 믿기 때문이다. 이러한 상황에서, 사용자를 위한 특정 클라이언트 디바이스는 이벤트의 파라미터들을 특성화(characterize)하기 위하여 디바이스로부터 자동적으로 또는 사용자로부터 수동적으로 데이터를 모을 수 있다. 특정 구현예들에서, 상술된 다양한 데이터는 운영 시스템의 구성요소 또는 애플리케이션에 의해 모아질 수 있고, 이벤트가 발생했을 때 디바이스의 현재 스크린샷과 같은 다른 데이터 외에, 디바이스의 사용자에 의한 디바이스로의 입력일 수 있는 정보(예컨대, 예컨대, 사용자가 애플리케이션에 추가하고자 하는 특징의 분류(sort of feature)를 나타내는 단어들)도 포함할 수 있다. 이러한 진단 정보가 모아지면, 그 모아진 정보는 클라이언트 디바이스로부터 서버 시스템으로 전송될 수 있고, 이어 서버 시스템은 경보들과 다른 클라이언트 디바이스들로부터 수신된 다른 경보들에 대한 정보를 포맷하여 저장할 수 있다(박스 310).

이러한 포맷팅 및 필터링을 수행하는 도중에, 중앙 서버 시스템은 또한 애플리케이션에 대해 발생하는 동일한 버그를 나타내는지를 이벤트들을 식별하기 위한 노력으로 다른 이벤트들에 대한 데이터들 간의 공통 파라미터들을 식별할 수 있다. 예를 들어, 두 개의 다른 이벤트에 대한 트레이스 정보가 서로에 대해 매우 근접하게 매치하면, 그 시스템은 두 개의 이벤트가 공통 버그의 결과였다고 추론할 수 있다. 2개의 이벤트가 동일 버그에 의한 것인지를 판단하기 위한 소정 파라미터들은 가중될 수 있고, 다른 파라미터들은 이벤트가 분류된 버그가 특정 파라미터에 관련되었는지 여부에 대한 결정 요인(determinative)일 수 있다. 이러한 식별된 버그들의 각각에는, 이어서 공통 버그를 갖는 것으로 판단되는 다른 경보 데이터 간에 상관 관계(correlation)를 생성하고, 경보들 및 버그들의 그룹 레코딩을 시스템에 있는 소프트웨어의 개발자들에게 제공하는데 사용될 수 있는 식별 번호(identificate number)가 할당될 수 있다.

박스(312)에서, 프로세스는 그들의 상응하는 애플리케이션 또는 애플리케이션들에 대한 버그 정보를 포맷하여, 특정 애플리케이션 또는 애플리케이션들의 개발자에게 전달한다. 상술된 바와 같이, 레포트는 다양한 형태를 취할 수 있으며, 그 형태는 웹페이지상에 있는 인쇄된 레포트, XML 포맷과 같은 데이터 블럭, 또는 애플리케이션을 구동중인 다양한 클라이언트 디바이스드에 의한 프로세스에, 이벤트가 레포트되거나 또는 이벤트들의 그룹이 레포트될 때마다의 데이터 전송에 관계되는 데이터의 스트림을 포함한다. 이러한 방식에서, 개발자는 사용자 및/또는 사용자의 디바이스가 제공할 수 있는 사용자의 디바이스상에서 발생한 버그-생성 이벤트들에 대한 정보를 획득할 수 있다.

도 4는 복수의 개발자들로부터 소프트웨어와 함께 문제들의 제출들을 관리하는 프로세스의 스윔 레인 다이어그램으로서, 상기 소프트웨어는 다수의 모바일 컴퓨팅 디바이스 전체에 설치되어 있다. 이 프로세스는 도 3의 프로세스와 유사하지만, 시스템에 있는 특정 구성요소들에 의해 수행될 수 있는 특정 예시적 동작들에 대해서 더 자세하게 나타내고 있다. 프로세스는 박스(402)에서 시작하며, 여기서 개발자는 소프트웨어 애플리케이션을 개발한다. 이러한 개발은 애플리케이션을 구성(architecture)하는 단계, 그 애플리케이션에 대한 코드를 작성(draft)하는 단계, 및 애플리케이션에 대한 코드의 부분들을 다르게 배열(arrange)하는 단계를 포함할 수 있다. 애플리케이션이 사용될 준비가 되는 즉시, 개발자는 익숙한 방식으로 애플리케이션 스토어 서버 시스템에 등록 및 로그인할 수 있고(404), 서버 시스템은 이 방식으로 개발자와의 양방향 세션(interactive session)을 시작할 수 있다(박스 406). 그 애플리케이션과 관련된 적절한 형태의 메타데이터(예컨대, 애플리케이션의 제목, 그 애플케이션에 부과될 수 있는 가격, 애플리케이션의 텍스트 설명, 사용자의 디바이스 및 애플리케이션 스토어 상에 제시될 애플리케이션을 위한 아이콘, 및 다른 적절한 데이터)를 제공한 후에, 사용자 또는 개발자는 필요한 메타데이터와 함께 자신의 애플리케이션 또는 애플리케이션들을 업로드할 수 있다(박스 408).

박스(410)에서, 애플리케이션 스토어 서버들은 그 애플리케이션을 등록하고, 애플리케이션의 파라미터들을 설명하는 데이터와 함께 애플리케이션을 저장하기 위한 공간(space)을 생성하고, 애플리케이션 스토어상에서 입수할 수 있는 방법으로 애플리케이션을 관리한다.

이 시간 약간 이후 시점에, 애플리케이션을 브라우징하던 사용자가 애플리케이션을 찾아서 그것을 구매하고 싶어한다. 박스(414)에서, 사용자가 애플리케이션 스토어에 등록 및 로그인하면, 사용자와의 세션을 시작한다(박스 416).

박스(418)에서, 사용자가 예컨대, 애플리케이션에 대한 아이콘을 클릭하고, 이어 사용자가 구매하여 그 애플리케이션을 획득하고 싶어한다는 것을 확인하는 특정 온-스크린 선택가능 컨트롤을 선택함으로써, 그 애플리케이션을 다운로드하라는 명령을 제공한다. 박스(420)에서, 애플리케이션 스토어는 사용자가 애플리케이션 스토어에 계정을 가지고 있는 것을 보장하는 사용자의 신용장들을 체크한 다음, 사용자가 이러한 계정을 가지고 있으면, 그 사용자에게 애플리케이션을 제공한다. 대안적으로, 서버들은 사용자가 계정을 가지고 있지 않다는 것을 판단할 수 있고, 종래 방식으로 사용자로부터 이러한 정보(미래에 다운로드받은 애플리케이션들에 대한 비용 결제를 위하여 사용자로부터 신용 카드 정보를 요청하는 것을 포함함)를 요청할 수 있다.

사용자가 애플리케이션을 다운로드했을 때, 그 애플리케이션을 사용하기 시작할 수 있고, 이러한 사용은, 소정 상황에서, 박스(422)에 도시된 것과 같은 에러 또는 문제 이벤트를 생성할 수 있다. 에러 이벤트들의 예시들이 상술되어 있으며, 디바이스의 프리징(freezing), 디바이스의 크래쉬, 또는 애플리케이션에 대한 제안된 개선 사항들 또는 문제들에 관련된 사용자로부터의 수동 레포트들을 포함할 수 있다. 이어, 사용자의 디바이스는 이벤트에 대한 진단 정보와 함께, 이러한 이벤트를 버그 서버에 보고하는데(박스 424), 버그 서버는 그 데이터를 수신하여 기록할 수 있다. 클라이언트 디바이스로부터의 이러한 전송은 이벤트를 겪고 있는 특정 애플리케이션에 의해, 또는 디바이스상에 상주하는 다른 애플리케이션에 의해, 운영 시스템 구성요소들을 통해 발생할 수 있다. 디바이스와 버그 서버들 간의 특별 상호 동작은 API 표준에 의해 확립될 수 있고, 데이터를 적절하게 전송하기 위해 이 표준을 따를 수 있다.

이어, 프로세스는 잠시 기다릴 수 있으며, 다른 사용자들이 자신의 디바이스상에서 애플리케이션들을 실행시킬 수 있는데, 상기 디바이스도 결국 해당 디바이스상에서의 문제들에 대한 데이터를 보고할 수 있다. 그러나 약간 지난 시점에, 개발자는 애플리케이션이 적합하게 동작하는지를 확인하고 싶어할 수 있으며, 끝에서 로그인할 수 있지만(박스 426), 이때 개발자는 버그 서버들로부터, 박스 428에서 세션을 시작할 수 있는 제공받아야 한다. 공통 상호 동작은 개발자에 의해 작동되는 컴퓨팅 디바이스에 의해 만들어진 하나 이상의 레포트에 대한 요청을 포함할 수 있고(박스 403), 박스 432에서 버그 서버들은 그 요청된 레포트를 개발자에게 제공할 수 있다. 이러한 제공은 버그 서버들에 의해 식별된 특정 포스트(post)들을 따라서 에러 이벤트 데이터를 체계화하는 단계, 현명한 결정을 하기 위해 개발자가 그들이 필요한 데이터만을 수신하게 하고, 그래서 그들이 액세스하면 안 되는 데이터를 수신하지 않게 하도록 데이터를 필터링하는 단계를 포함한다. 마지막으로, 박스 434에서, 개발자의 디바이스는 예컨대, 웹 페이지상에서 레코드들 또는 레포트들을 디스플레이하여, 개발자가 그것들을 검토하고, 하나 이상의 디바이스들에서 발생했을 수 있는 에러들을 해결하기 위해 자신의 소트프웨어를 업데이트할 지 여부, 및 업데이트하는 방법을 결정할 수 있다.

도 5a와 도 5b는 소프트웨어 애플리케이션의 동작적 문제들을 경험하고 있는 모바일 컴퓨팅 디바이스의 예시적 스크린샷들이다. 일반적으로, 이러한 스크린샷들은 에러가 발생할 때, 예컨대 운영 시스템 구성요소 또는 애플리케이션에 의해 클라이언트 디바이스상에서 생성될 수 있는 스크린에 대한 두 가지 예시를 나타낸다. 도 5a에도시된 스크린샷은 특정 프로세스가 예기치못하게 정지해 버림으로 인하여 생성되는 경고 화면을 나타낸다. 이 스크린샷은 사용자에게 무엇이 발생했는지를 나타내고, 사용자에게 응답을 위한 두 가지 옵션을 제공한다. 특히, 사용자는 그들이 강제 종료를 시키면 데이터를 잃어버릴 것이라는 것을 알면서, 애플리케이션을 확장 샷다운(extension shut down)하는 것에 의해, 그 프로세스를 샷다운하도록 "강제 종료(force close)"를 선택할 수 있다. 사용자는 또한 문제에 대한 정보를 보고하도록 선택할 수 있는데, 이 사용자는 열린 사고(open-minded)를 가지고 있으며, 유사한 예기치않은 멈춤이 향후 발생하지 않도록 하기 위해, 애플리케이션 또는 운영 시스템의 개발자가 그 소프트웨어를 개선시키는 것을 돕고자한다.

"레포트" 옵션의 사용자의 선택은 도 5b에 도시된 스크린샷이 디스플레이되게 한다. 여기서, 사용자는 문제를 중앙 서버 시스템에 어떻게 보고할지를 제어하는 파라미터들이 도시되어 있다. 특히, 이 전송에 적용되어질 적절한 프라이버시 정책이 사용자의 검토를 위해 디스플레이될 수 있고, 사용자는 그 프라이버시 정책을 수정하거나 업데이트하기 위한 적절한 컨트롤들을 제공받을 수 있다. 이에 더하여, 사용자에게 문제의 내용을 선택적으로 기술할 수 있는 빈 텍스트 박스를 제시할 수 있는데, 빈 텍스트 박스에는 예컨대, "전화 통화와 동시에, 비디오를 핸드브레이크(Handbrake)로 변환하고, SETI용 수치 처리(number crunching)를 하고, 풀 레스 퍼스트 펄슨 슛터(a full res person shooter)를 하면서, abc 애플리케이션에 xyz을 타이핑하고 있었는데, 별다른 이유없이, 그 애플리케이션이 중지하였습니다."가 기재될 수 있다. 이러한 텍스트는 문제에 대한 다른 진단 정보를 갖는 필드로서 전달될 수 있다. 특정 상황들에서, 사용자는 버그가 특히 골치아프거나(thorny) 개발자가 사용자가 이메일을 보내거나 전화를 걸어야할 필요가 있는 경우에, 개발자들에게 제공되는 자신의 연락처 정보를 제공할 수 있는 기회를 가질 수 있다. 대안적으로, 사용자는 임의의 연락처 정보를 제공하기를 처음에는 요구받지 않을 수 있지만, 코멘트를 검토할 때, 개발자가 연락처 정보에 대한 요청을 생각해낼 수 있고, 이어 시스템은 그 사용자가 응답할 수 있다는 메시지를 생성할 수 있다.

사용자는 그 문제에 대해 업로드되어질 모든 데이터를 볼 수 있게 하는 "미리 보기(preview)"를 선택하거나, 또는 정보의 이러한 업로드가 행해지게 하는 "전송(send)"을 선택할 수 있다.

도 6a-도 6c는 소트프웨어 트래킹 시스템에 의해 생성된 개발자 레포트들의 예시적 스크린샷이다. 도 6a는 application com.android.launcher2의 버그들에 대한 요약 통계를 나타낸다. 예를 들어, 클라이언트 디바이스들로부터의 레포트들 또는 제출들의 총 개수가, 프리즈 및 크래쉬 모두에 대해, 제출들의 현재 비율(current rate of submission)로서 보여진다.

다른 경우로서, 디바이스 배터리 전력 및 사용에 대한 정보가 실행중인 애플리케이션에 대한 정보로 보고된다. 예를 들어, 만약 배터리의 전력이 갑자기 낮아지면, 진단 정보가 디바이스로부터 업로드되어, 중앙 조사자(central researcher)가 전기적 요구의 근원(source)을 판단할 수 있게 한다. 예를 들어, 특정 애플리케이션이 주기적으로 이러한 이벤트들이 발생할 때마다 활성화되는 것으로 보여지면, 중앙 시스템은 이 애플리케이션이 배터리 소모의 근원이라는 것을 추론할 수 있다.

도 6b는 유사한 요약 레포트지만, 다수의 다른 애플리케이션 또는 코드 파일들에 대한 것이다. 예를 들어, 실패했을 때 그것의 내용, 이러한 실패에 대한 레포드의 개수, 및 이러한 이벤트들의 현재 비율과 함께 코드의 이름이 보여진다.

도 6c는 특정 애플리케이션의 특정 실패에 대한 보다 상세한 보고와, 실패 내용에 대한 보다 많은 정보를 나타내고 있다. 예를 들어, 소정의 다른 유용한 정보로서, 디바이스에 대한 스택 트레이스들이 레포트에 도시되어 있다. 정보의 일부가 하이퍼링크되어, 사용자가 여기에 디스플레이되어 있는 것에 대한 추가 소스 데이터를 볼 수 있게 한다.

도 7은 본 명세서에서 설명된 기술들에 사용될 수 있는 일반적인 컴퓨터 디바이스(700)와 일반적인 모바일 컴퓨터 디바이스(750)의 예시를 나타낸다. 컴퓨팅 시스템(700)은 랩탑, 데스크탑, 워크스테이션, PDA(Personal Digital Assistant), 서버, 블레이드(blade) 서버, 메인프레임, 및 그 밖의 적절한 컴퓨터들과 같은 다양한 형태의 디지털 컴퓨터를 나타내기 위해 사용된다. 컴퓨팅 디바이스(750)는 PDA, 셀룰라 전화, 스마트폰, 및 그 밖의 유사한 컴퓨팅 디바이스와 같은 다양한 형태의 모바일 디바이스를 나타내기 위해 사용된다. 본 명세서에서 나타낸 구성요소, 그들의 접속 및 관계, 및 그들의 기능들은 단지 예시적인 것을 의미하고, 본 명세서에서 설명하거나 및/또는 청구된 발명들의 구현예를 제한하는 것을 의미하지 않는다.

컴퓨팅 디바이스(700)는 프로세서(702), 메모리(704), 저장 디바이스(706), 메모리(704)와 고속 확장 포트(710)에 접속하는 고속 인터페이스(708), 및 저속 버스(714)와 저장 디바이스(706)에 접속하는 저속 인터페이스(712)를 포함한다. 각 구성요소(702, 704, 706, 708, 710, 및 712)는 다양한 버스들을 사용하여 서로 접속되고, 공통 마더보드에 탑재되거나 또는 적절한 경우 다른 방식으로 탑재될 수 있다. 프로세서(702)는 컴퓨팅 디바이스(700) 내에서 실행하기 위한 인스트럭션을 처리할 수 있으며, 이러한 인스트럭션에는, 고속 인터페이스(708)에 연결된 디스플레이(716)와 같은 외장 입/출력 디바이스상에서 GUI용 그래픽 정보를 디스플레이하기 위해, 메모리(704) 또는 저장 디바이스(706)에 저장되는 인스트럭션이 포함된다. 다른 구현예에서, 다중 프로세서 및/또는 다중 버스는 적절한 경우, 다중 메모리 및 메모리 타입과 함께 사용될 수 있다. 또한, 다중 컴퓨팅 디바이스(700)는 각 디바이스가 필요 동작의 부분을 제공하는 형태(예를 들어, 서버 뱅크, 블레이드 서버의 그룹, 또는 다중 프로세서 시스템)로 접속될 수 있다.

메모리(704)는 컴퓨팅 디바이스(700) 내에 정보를 저장한다. 일 구현예에서, 메모리(704)는 휘발성 메모리 유닛 또는 유닛들이다. 또 다른 구현예서, 메모리(704)는 비휘발성 메모리 유닛 또는 유닛들이다. 또한, 메모리(704)는 마그네틱 또는 광 디스크와 같은 다른 형태의 컴퓨터 판독가능 매체일 수 있다.

저장 디바이스(706)는 컴퓨팅 디바이스(700)를 위한 대용량 저장소(mass storage)를 제공할 수 있다. 일 구현예에서, 저장 디바이스(706)는 플로피 디스크 디바이스, 하드 디스크 디바이스, 광 디스크 디바이스, 또는 테입 디바이스, 플래쉬 메모리 또는 다른 유사한 고체 상태 메모리 디바이스, 또는 저장 영역 네트워크 또는 다른 구성에 존재하는 디바이스를 포함하는 디바이스 어레이일 수 있다. 컴퓨터 프로그램 제품은 정보 캐리어(information carrier) 내에 유형적으로 구체화될 수 있다. 또한, 컴퓨터 프로그램 제품은 실행될 때, 상술한 것과 같은 하나 이상의 방법을 수행하는 인스트럭션을 포함할 수 있다. 정보 캐리어는 메모리(704), 저장 디바이스(706), 또는 프로세서(702) 상의 메모리와 같은 컴퓨터 또는 기계 판독가능 매체이다.

저속 제어부(712)가 저대역-집약적 동작(lower bandwidth-intensive operations)을 관리하는 반면, 고속 제어부(708)는 컴퓨팅 디바이스(900)에 대한 대역-집약적 동작을 관리한다. 이러한 기능들의 배치는 단지 예시적인 것이다. 일 구현예에서, 고속 제어부(708)는 메모리(704), 디스플레이(716)(예를 들어, 그래픽 프로세서 또는 가속기를 통함)에 연결되고, 다양한 확장 카드(도시되지 않음)을 수용할 수 있는 고속 확장 포트(710)에 연결된다. 일부 구현예에서는, 저속 제어부(712)는 저장 디바이스(706) 및 저속 확장 포트(714)에 연결된다. 다양한 통신 포트(예를 들어, USB, 블루투스, 이더넷, 무선 이더넷)를 포함할 수 있는 저속 확장 포트는 키보드, 포인팅 디바이스, 스캐너와 같은 하나 이상의 입/출력 디바이스들에 연결되거나, 또는 예컨대 네트워크 어댑터를 통하여, 스위치나 라우터와 같은 네트워킹 디바이스에 연결될 수 있다.

컴퓨팅 디바이스(700)는 도면에 도시된 바와 같이, 복수의 다른 형태로 구현될 수 있다. 예를 들어, 컴퓨팅 디바이스(700)는 표준 서버(720)로 구현되거나 이러한 서버들의 그룹에서 여러 번(multiple time) 구현될 수 있다. 또한, 컴퓨팅 디바이스(700)는 랙 서버 시스템(724)의 부분으로서 구현될 수 있다. 이에 더하여, 컴퓨팅 디바이스(700)는 랩탑 컴퓨터(722)와 같은 개인용 컴퓨터내에 구현될 수 있다. 선택적으로, 컴퓨팅 디바이스(700)로부터의 구성요소는 디바이스(750)와 같은 모바일 디바이스(도시되지 않음) 내 다른 구성요소와 조합될 수 있다. 이러한 디바이스 각각은 하나 이상의 컴퓨팅 디바이스(700, 750)를 포함하고, 전체 시스템은 서로 통신하는 다중 컴퓨팅 디바이스(700, 750)로 구성될 수 있다.

컴퓨팅 디바이스(750)는 여러 구성요소 중에서 프로세서(752), 메모리(764), 디스플레이(754)와 같은 입/출력 디바이스, 통신 인터페이스(766), 및 트랜스시버(768) 등을 포함한다. 또한, 디바이스(750)에는 추가적인 저장소를 제공하기 위하여, 마이크로 드라이브 또는 다른 디바이스와 같은 저장 디바이스가 제공될 수 있다. 구성요소(750, 752, 764, 754, 766, 및 768) 각각은 다양한 버스를 이용하여 서로 접속되고, 구성요소의 몇몇은 공통의 마더보스에 탑재되거나 적절한 다른 방법으로 탑재될 수 있다.

프로세서(752)는 컴퓨팅 디바이스(750) 내에서 인스트럭션을 실행하며, 이 인스트럭션에는 메모리(764)에 저장된 인스트럭션이 포함된다. 프로세서는 개별적이고 다중의 아날로그 및 디지털 프로세서를 포함하는 칩들의 칩 세트로서 구현될 수 있다. 프로세서는, 예를 들어, 사용자 인터페이스의 컨트롤, 디바이스(750)에 의해 실행되는 애플리케이션, 및 컴퓨팅 디바이스(750)에 의한 무선 통신과 같은 디바이스(750)의 다른 구성요소들 사이에 조정을 제공할 수 있다.

프로세서(752)는 제어 인터페이스(758) 및 디스플레이(754)에 연결된 디스플레이 인터페이스(756)를 통해 사용자와 통신할 수 있다. 디스플레이(754)는, 예를 들어, TFT LCD(Thin-Film-Tansistor Liquid Crystal Display) 또는 OLED(Organic Light Emitting Diode) 디스플레이, 또는 다른 적절한 디스플레이 기술일 수 있다. 디스플레이 인터페이스(756)는 그래픽 및 다른 정보를 사용자에게 나타내기 위해 디스플레이(754)를 구동하는 적절한 회로를 포함할 수 있다. 제어 인터페이스(758)는 사용자로부터 명령들을 수신하고, 프로세서(752)에 제출하기 위해 그 명령들을 변환한다. 더욱이, 확장 인터페이스(762)는 디바이스(750)와 다른 디바이스들 간에 근거리 통신이 가능하도록 하기 위해, 프로세서(752)와의 통신에 제공될 수 있다. 확장 인터페이스(762)는, 예를 들어, 일부 구현예에서는 유선 통신을 제공하고 다른 구현예에서 무선 통신을 제공하며, 또한 다중 인터페이스가 사용될 수 있다.

메모리(764)는 컴퓨팅 디바이스(750) 내에 정보를 저장한다. 메모리(764)는 컴퓨터 판독가능 매체 또는 미디어, 휘발성 메모리 유닛 또는 유닛들, 또는 비휘발성 메모리 유닛 또는 유닛들 중 하나 이상으로서 구현될 수 있다. 또한, 확장 메모리(774)가 제공되어, 예를 들어 SIMM(Single In Line Memory Module) 카드 인터페이스를 포함하는 확장 인터페이스(772)를 통해 디바이스(750)에 접속될 수 있다. 이러한 확장 메모리(774)는 디바이스(750)를 위한 여분의 저장 공간을 제공할 수 있고, 또한 애플리케이션 또는 디바이스(750)를 위한 다른 정보를 저장할 수 있다. 특히, 확장 메모리(774)는 상술된 프로세스를 실행하거나 보조하기 위한 인스트럭션을 포함하고, 또한 보안 정보를 포함할 수 있다. 따라서 예를 들어, 확장 메모리(774)는 디바이스(750)용 보안 모듈(security module)로서 제공될 수 있고, 디바이스(750)의 안전한 사용을 가능하게 하는 인스트럭션로 프로그램될 수 있다. 더욱이, 보안 애플리케이션은, 해킹할 수 없는 방식(non-hackable manner)으로 SIMM 카드 상에 식별 정보를 위치시킨 것과 같은 추가적 정보와 함께 SIMM 카드를 통해 제공될 수 있다.

메모리는 아래에서 논의되는 것과 같이 예를 들어, 플래시 메모리 및/또는 NVRAM 메모리를 포함할 수 있다. 일 구현예에서, 컴퓨터 프로그램 제품은 정보 캐리어에 유형적으로 구체화된다. 컴퓨터 프로그램 제품은 실행될 때, 상술된 것과 같은 하나 이상의 방법을 수행하는 인스트럭션을 포함한다. 정보 캐리어는 메모리(764), 확장 메모리(774), 또는 예를 들어 트랜스시버(768) 또는 확장 인터페이스(762)를 통해 수신될 수 있는 프로세서(752) 상의 메모리 또는 전파된 신호(propagated signal)와 같은 컴퓨터-또는 기계-판독가능 매체이다.

디바이스(750)는 디지털 신호 처리 회로를 필요에 따라 포함하는 통신 인터페이스(766)를 통해 무선으로 통신할 수 있다. 통신 인터페이스(766)는 GSM 음성 호, SMS, EMS, 또는 MMS 메시징, CDMA, TDMA, PDC, WCDMA, CDMA2000, 또는 GPRS 등과 같은 다양한 모드 또는 프로토콜 하에서의 통신을 제공할 수 있다. 이러한 통신은 예를 들어, 무선-주파수 트랜스시버(768)를 통해 수행될 수 있다. 또한, 단거리(short range) 통신은 예를 들어, 블루투스, WiFi, 또는 다른 이러한 트랜스시버(도시되지 않음)를 사용하여 수행될 수 있다. 이에 더하여, GPS(Global Position System) 수신기 모듈(770)은 추가적인 네비게이션- 및 위치- 관련 무선 데이터를 디바이스(750)에 제공할 수 있으며, 이 무선 데이터는 디바이스(750)에서 실행중인 애플리케이션에 의해 적절하게 사용될 수 있다.

또한, 디바이스(750)는 사용자로부터의 발화 정보(spoken information)를 수신하고, 그 발화 정보를 사용가능한 디지털 정보로 변환하는 오디오 코덱(760)을 이용하여, 청취가능하게(audibly) 통신할 수 있다. 또한, 오디오 코덱(760)은 예를 들어, 디바이스(750)의 핸드셋 내의 스피커를 통하는 것과 같이 해서, 사용자가 들을 수 있는 음성을 생성한다. 이러한 음성은 음성 전화 호로부터의 음성을 포함할 수 있고, 녹음된 음성(예를 들어, 음성 메시지, 음악 파일 등)은 포함할 수 있고, 또한 디바이스(750) 상에서 동작하는 애플리케이션에 의해 생성된 음성을 포함할 수 있다.

컴퓨팅 디바이스(750)는 도면에 도시된 바와 같이, 복수의 다양한 형태로 구현될 수 있다. 예를 들어, 컴퓨팅 디바이스(750)는 셀룰러 전화(780)로서 구현될 수 있다. 또한, 컴퓨팅 디바이스(750)는 스마트폰(782), PDA, 또는 다른 유사한 모바일 디바이스의 일부로서 구현될 수 있다.

본 명세서에 기재된 시스템의 다양한 구현예와 기술은 디지털 전자 회로, 집적 회로, 특별하게 설계된 ASICs(Application Specific Intergrated Circuit), 컴퓨터 하드웨어, 펌웨어, 소프트웨어, 및/또는 그것의 조합물로 실현될 수 있다. 이러한 다양한 구현예는 하나 이상의 컴퓨터 프로그램으로 된 구현예를 포함하며, 이 컴퓨터 프로그램은 적어도 하나의 프로그램 가능한 프로세서를 포함하는 프로그램 가능한 시스템에서 실행가능하고 및/또는 해석가능하다. 또한, 전용 또는 범용 프로세서일 수 있는 이 프로그램 가능한 프로세서는 데이터와 인스트럭션을 송수신하기 위해, 저장 시스템, 적어도 하나의 입력 디바이스 및 적어도 하나의 수신 디바이스에 연결된다.

컴퓨터 프로그램(또한 프로그램, 소프트웨어, 소프트웨어 애플리케이션, 또는 코드로 알려짐)은 프로그램 가능한 프로세서를 위한 기계 인스트럭션을 포함하고, 고레벨 절차 및/또는 오브젝트 지향 프로그램 언어(object-oriented programming language) 및/또는 어셈블리/기계 언어로 구현될 수 있다. 본 명세서에서 사용되는 바와 같이, 용어 "기계 판독가능 매체(machine-readable medium)"와 "컴퓨터 판독가능 매체(computer-readable medium)"는 기계 인스트럭션 및/또는 데이터를 프로그램 가능한 프로세서에 제공하기 위해 이용되는 장치, 및/또는 디바이스(예를 들어, 마그네틱 디스크, 광학 디스크, 메모리, PLDs(Programmable Logic Devices))를 가리키며, 기계 판독가능 신호와 같은 기계 인스트럭션을 수신하는 기계 판독가능 매체를 포함한다. 용어 "기계 판독가능 신호(machine-readable signal)"는 기계 인스트럭션 및/또는 데이터를 프로그램 가능한 프로세서에 제공하기 위해 사용되는 임의의 신호를 가리킨다.

사용자와의 상호 동작을 제공하기 위하여, 본 명세서에 기술된 시스템과 기술은, 정보를 사용자에게 디스플레이하기 위한 디스플레이 디바이스(예를 들어, CRT(cathode ray tube) 또는 LCD 모니터)와 사용자가 컴퓨터에 입력을 제공할 수 있는 키보드 및 포인팅 디바이스(예를 들어, 마우스 또는 트랙볼)를 구비한 컴퓨터상에서 구현될 수 있다. 사용자와의 상호 동작을 제공하기 위하여 다른 종류의 디바이스가 또한 사용될 수 있다; 예를 들어, 사용자에게 제공되는 피드백(feedback)은 임의의 형태의 감각 피드백(예를 들어, 시각 피드백, 청각 피드백 또는 촉각 피드백)일 수 있고, 사용자로부터의 입력은 음향(acoustic), 음성(speech) 또는 촉각(tactile) 입력을 포함하는 임의의 형태로 수신될 수 있다.

본 명세서에서 설명한 시스템과 기술은, 백앤드(back end) 구성요소(예를 들어, 데이터 서버와 같은), 또는 미들웨어 구성요소(예를 들어, 애플리케이션 서버), 또는 프론트 앤드(front end) 구성요소(예를 들어, 본 명세서에서 설명된 시스템 및 기술의 구현예와 사용자가 상호 동작할 수 있는 그래픽 사용자 인터페이스 또는 웹브라우저를 구비한 클라이언트 컴퓨터), 또는 이러한 백앤드, 미들웨어, 또는 프론트 앤드 구성요소들의 임의의 조합을 포함하는 컴퓨팅 시스템으로 구현될 수 있다. 시스템의 구성요소는 디지털 데이터 통신의 임의의 형태 또는 매체(예를 들어, 통신 네트워크)에 의해 상호 접속될 수 있다. 통신 네트워크의 예로서, 근거리 네트워크(LAN), 광역 네트워크(WAN), 및 인터넷이 있다.

컴퓨팅 시스템은 클라이언트와 서버를 포함할 수 있다. 클라이언트와 서버는 보통 서로 떨어져 있으며, 일반적으로는 통신 네트워크를 통하여 상호 동작한다. 클라이언트와 서버의 관계는 각각의 컴퓨터상에서 실행되고 상호 클라이언트-서버 관계를 갖는 컴퓨터 프로그램에 의하여 발생한다.

많은 구현예들이 설명되었다. 그렇지만, 본 발명의 요지 및 범위를 벗어나지 않고 다양한 변형예들이 만들어질 수 있다는 것을 이해할 수 있을 것이다. 예를 들어, 본 명세서의 전화 다이얼링 애플리케이션에 관련하여 설명되었지만, 다른 형태의 애플리케이션들 및 키패드 레이아웃들(예컨대, 영숫자 문자들 외에, 그래픽 아이콘들 및 매크로들에 관련됨)도 처리될 수 있다.

이에 더하여, 도면에서 묘사된 로직 흐름은 희망하는 결과를 달성하기 위해, 도시된 특정 순서 또는 시계열적 순서일 필요는 없다. 이에 더하여, 다른 단계들이 제공되거나, 그로부터 단계들이 제거될 수 있으며, 다른 구성요소들이 설명된 시스템에 추가되거나 그로부터 제거될 수 있다. 따라서 다른 실시예예들은 후술하는 청구범위의 범위 내에 속한다.

108: 사용자 센터
110: 개발자 센터
112: 앱 스토어
114: 앱 관리자
116: 버그 수집기
118: 버그 레포터
102: 애플리케이션 센터

Claims

컴퓨터로 구현되는 방법으로서,
제1 애플리케이션 개발자의 컴퓨팅 시스템으로부터 온라인 애플리케이션 스토어의 컴퓨팅 시스템으로, 제1 애플리케이션 개발자의 제1 애플리케이션을 상기 온라인 애플리케이션 스토어에서 배포 가능하게 하는 제1 요청을 제공하는 단계;
상기 제1 요청은 (i) 상기 제1 애플리케이션 개발자를 식별하는데 이용가능한 정보 및 (ii) 제1 애플리케이션을 위한 컴퓨터 코드를 포함하며,
상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템은 상기 제1 애플리케이션 개발자를 포함하는 복수의 독립적인 애플리케이션 개발자들로부터의 애플리케이션들을 상기 복수의 독립적인 애플리케이션 개발자들과는 독립적인 최종 사용자들의 컴퓨팅 디바이스들에 배포 가능하게 하도록 구성되며,
상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템은 최종 사용자들이 상기 온라인 애플리케이션 스토어를 통해 배포된 애플리케이션들을 실행하는 것과 관련하여 경험했던 문제들에 관한 정보를 수집하고 그리고 최종 사용자들이 상기 온라인 애플리케이션 스토어를 통해 배포된 애플리케이션들을 실행하는 것과 관련하여 경험했던 문제들에 관한 정보를 상기 복수의 독립적인 애플리케이션 개발자들 중 대응하는 개발자에게 보고하도록 구성되며;
이후 시간에, 상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템으로부터 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템으로, 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템이 상기 제1 애플리케이션 개발자를 대신하여 배포 가능하게 했던 애플리케이션들에 관한 정보에 대한 제2 요청을 제공하는 단계;
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 상기 제2 요청에 대한 응답으로, 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템이 상기 제1 애플리케이션 개발자를 대신하여 배포 가능하게 했던, 상기 제1 애플리케이션을 포함하는 하나 이상의 애플리케이션들에 관한 정보를 수신하는 단계; 그리고
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 하나 이상의 애플리케이션들을 실행하는 것과 관련하여 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 적어도 일부를 표시하는 보고(report)를 디스플레이하는 단계를 포함하는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 그리고 상기 제2 요청에 대한 응답의 일부로서, 하나 이상의 최종 사용자들의 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어가 상기 제1 애플리케이션 개발자를 대신하여 배포 가능했던 상기 제1 애플리케이션이 아닌 하나 이상의 추가적인 애플리케이션들을 실행하는 것과 관련하여 상기 온라인 애플리케이션 스토어에 보고한 문제들에 관한 추가적인 정보를 수신하는 단계를 더 포함하며; 그리고
상기 보고를 디스플레이하는 단계는 하나 이상의 최종 사용자들의 컴퓨팅 디바이스들이 상기 제1 애플리케이션과 상기 하나 이상의 추가적인 애플리케이션들 중에서 선택된 다수의 애플리케이션들을 실행하는 것과 관련하여 상기 온라인 애플리케이션 스토어에 보고한 문제들에 관한 정보를 디스플레이하는 것을 포함하는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 제1 애플리케이션은 모바일 컴퓨팅 디바이스에서 실행되도록 구성되는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 상기 적어도 일부를 표시하는 상기 보고는 복수의 문제 유형들 중에서 각각의 문제 유형 각각에 대해, 정의된 시간 간격 내에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 각각의 문제 유형과 관련된 문제들의 빈도를 식별하는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 4에 있어서,
상기 보고는 상기 복수의 문제 유형들 중에서 각각의 문제 유형 각각에 대해,
(i) 최근 시간 간격 내에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 각각의 문제 유형과 관련된 문제들의 빈도, 및
(ii) 상기 최근 시간 간격 이전에 발생한 선행하는 시간 간격 내에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 각각의 문제 유형과 관련된 문제들의 빈도를 식별하는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 상기 적어도 일부를 표시하는 상기 보고는 상기 문제들 중 상기 적어도 일부 중에서 각 문제를 (i) 애플리케이션들이 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들에서 크래쉬(crash)하게 했던 문제들에 대한 문제들의 제1 그룹 및 (ii) 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 프리즈(freeze)하게 했던 문제들에 대한 문제들의 제2 그룹 중 하나로 분류하는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 상기 적어도 일부를 표시하는 상기 보고는 하나 이상의 플랫폼들 중에서 각각의 플랫폼 각각에 대해, 상기 각각의 플랫폼에서 발생한 것으로 보고된 문제들의 빈도를 식별하는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 제2 요청에 대한 상기 응답에서 수신된 상기 정보는 개별 최종 사용자들에 대한 식별 정보를 포함하지 않는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 제1 요청을 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템에 제공하는 단계는 상기 제1 애플리케이션과 연관된 메타데이터를 전송하는 것을 포함하며, 상기 메타데이터는 제1 애플리케이션의 제목, 상기 온라인 애플리케이션 스토어가 상기 제1 애플리케이션에 대해 특정 가격을 부과하게 하는 지시, 상기 제1 애플리케이션의 텍스트적 설명 또는 최종 사용자들의 컴퓨팅 디바이스들 상에서 또는 상기 온라인 애플리케이션 스토어의 사이트 상에서 제시될 상기 제1 애플리케이션에 대한 아이콘 중 적어도 하나를 포함하는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
청구항 1에 있어서,
상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 상기 적어도 일부를 표시하는 상기 보고는 상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서 웹페이지에 제시되는 것을 특징으로 하는 컴퓨터로 구현되는 방법.
명령어들이 저장된 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 명령어들은 하나 이상의 프로세서들에 의해 실행될 때, 동작들을 수행하게 하며, 상기 동작들은:
제1 애플리케이션 개발자의 컴퓨팅 시스템으로부터 온라인 애플리케이션 스토어의 컴퓨팅 시스템으로, 제1 애플리케이션 개발자의 제1 애플리케이션을 상기 온라인 애플리케이션 스토어에서 배포 가능하게 하는 제1 요청을 제공하는 동작;
상기 제1 요청은 (i) 상기 제1 애플리케이션 개발자를 식별하는데 이용가능한 정보 및 (ii) 제1 애플리케이션을 위한 컴퓨터 코드를 포함하며,
상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템은 상기 제1 애플리케이션 개발자를 포함하는 복수의 독립적인 애플리케이션 개발자들로부터의 애플리케이션들을 상기 복수의 독립적인 애플리케이션 개발자들과는 독립적인 최종 사용자들의 컴퓨팅 디바이스들에 배포 가능하게 하도록 구성되며,
상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템은 최종 사용자들이 상기 온라인 애플리케이션 스토어를 통해 배포된 애플리케이션들을 실행하는 것과 관련하여 경험했던 문제들에 관한 정보를 수집하고 그리고 최종 사용자들이 상기 온라인 애플리케이션 스토어를 통해 배포된 애플리케이션들을 실행하는 것과 관련하여 경험했던 문제들에 관한 정보를 상기 복수의 독립적인 애플리케이션 개발자들 중 대응하는 개발자에게 보고하도록 구성되며;
이후 시간에, 상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템으로부터 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템으로, 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템이 상기 제1 애플리케이션 개발자를 대신하여 배포 가능하게 했던 애플리케이션들에 관한 정보에 대한 제2 요청을 제공하는 동작;
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 상기 제2 요청에 대한 응답으로, 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템이 상기 제1 애플리케이션 개발자를 대신하여 배포 가능하게 했던, 상기 제1 애플리케이션을 포함하는 하나 이상의 애플리케이션들에 관한 정보를 수신하는 동작; 그리고
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 하나 이상의 애플리케이션들을 실행하는 것과 관련하여 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 적어도 일부를 표시하는 보고를 디스플레이하는 동작을 포함하는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 11에 있어서,
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 그리고 상기 제2 요청에 대한 응답의 일부로서, 하나 이상의 최종 사용자들의 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어가 상기 제1 애플리케이션 개발자를 대신하여 배포 가능했던 상기 제1 애플리케이션이 아닌 하나 이상의 추가적인 애플리케이션들을 실행하는 것과 관련하여 상기 온라인 애플리케이션 스토어에 보고한 문제들에 관한 추가적인 정보를 수신하는 동작을 더 포함하며; 그리고
상기 보고를 디스플레이하는 동작은 하나 이상의 최종 사용자들의 컴퓨팅 디바이스들이 상기 제1 애플리케이션과 상기 하나 이상의 추가적인 애플리케이션들 중에서 선택된 다수의 애플리케이션들을 실행하는 것과 관련하여 상기 온라인 애플리케이션 스토어에 보고한 문제들에 관한 정보를 디스플레이하는 것을 포함하는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 11에 있어서,
상기 제1 애플리케이션은 모바일 컴퓨팅 디바이스에서 실행되도록 구성되는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 11에 있어서,
상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 상기 적어도 일부를 표시하는 상기 보고는 복수의 문제 유형들 중에서 각각의 문제 유형 각각에 대해, 정의된 시간 간격 내에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 각각의 문제 유형과 관련된 문제들의 빈도를 식별하는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 14에 있어서,
상기 보고는 상기 복수의 문제 유형들 중에서 각각의 문제 유형 각각에 대해,
(i) 최근 시간 간격 내에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 각각의 문제 유형과 관련된 문제들의 빈도, 및
(ii) 상기 최근 시간 간격 이전에 발생한 선행하는 시간 간격 내에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 각각의 문제 유형과 관련된 문제들의 빈도를 식별하는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 11에 있어서,
상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 상기 적어도 일부를 표시하는 상기 보고는 상기 문제들 중 상기 적어도 일부 중에서 각 문제를 (i) 애플리케이션들이 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들에서 크래쉬(crash)하게 했던 문제들에 대한 문제들의 제1 그룹 및 (ii) 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 프리즈(freeze)하게 했던 문제들에 대한 문제들의 제2 그룹 중 하나로 분류하는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 11에 있어서,
상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 상기 적어도 일부를 표시하는 상기 보고는 하나 이상의 플랫폼들 중에서 각각의 플랫폼 각각에 대해, 상기 각각의 플랫폼에서 발생한 것으로 보고된 문제들의 빈도를 식별하는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 11에 있어서,
상기 제2 요청에 대한 상기 응답에서 수신된 상기 정보는 개별 최종 사용자들에 대한 식별 정보를 포함하지 않는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
청구항 11에 있어서,
상기 제1 요청을 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템에 제공하는 동작은 상기 제1 애플리케이션과 연관된 메타데이터를 전송하는 것을 포함하며, 상기 메타데이터는 제1 애플리케이션의 제목, 상기 온라인 애플리케이션 스토어가 상기 제1 애플리케이션에 대해 특정 가격을 부과하게 하는 지시, 상기 제1 애플리케이션의 텍스트적 설명 또는 최종 사용자들의 컴퓨팅 디바이스들 상에서 또는 상기 온라인 애플리케이션 스토어의 사이트 상에서 제시될 상기 제1 애플리케이션에 대한 아이콘 중 적어도 하나를 포함하는 것을 특징으로 하는 하나 이상의 비일시적 컴퓨터 판독가능 매체.
컴퓨팅 시스템으로서,
하나 이상의 프로세서들; 및
명령어들이 저장된 하나 이상의 컴퓨터 판독가능 매체를 포함하며, 상기 명령어들은 상기 하나 이상의 프로세서들에 의해 실행될 때, 동작들을 수행하게 하며, 상기 동작들은:
제1 애플리케이션 개발자의 컴퓨팅 시스템으로부터 온라인 애플리케이션 스토어의 컴퓨팅 시스템으로, 제1 애플리케이션 개발자의 제1 애플리케이션을 상기 온라인 애플리케이션 스토어에서 배포 가능하게 하는 제1 요청을 제공하는 동작;
상기 제1 요청은 (i) 상기 제1 애플리케이션 개발자를 식별하는데 이용가능한 정보 및 (ii) 제1 애플리케이션을 위한 컴퓨터 코드를 포함하며,
상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템은 상기 제1 애플리케이션 개발자를 포함하는 복수의 독립적인 애플리케이션 개발자들로부터의 애플리케이션들을 상기 복수의 독립적인 애플리케이션 개발자들과는 독립적인 최종 사용자들의 컴퓨팅 디바이스들에 배포 가능하게 하도록 구성되며,
상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템은 최종 사용자들이 상기 온라인 애플리케이션 스토어를 통해 배포된 애플리케이션들을 실행하는 것과 관련하여 경험했던 문제들에 관한 정보를 수집하고 그리고 최종 사용자들이 상기 온라인 애플리케이션 스토어를 통해 배포된 애플리케이션들을 실행하는 것과 관련하여 경험했던 문제들에 관한 정보를 상기 복수의 독립적인 애플리케이션 개발자들 중 대응하는 개발자에게 보고하도록 구성되며;
이후 시간에, 상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템으로부터 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템으로, 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템이 상기 제1 애플리케이션 개발자를 대신하여 배포 가능하게 했던 애플리케이션들에 관한 정보에 대한 제2 요청을 제공하는 동작;
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 상기 제2 요청에 대한 응답으로, 상기 온라인 애플리케이션 스토어의 상기 컴퓨팅 시스템이 상기 제1 애플리케이션 개발자를 대신하여 배포 가능하게 했던, 상기 제1 애플리케이션을 포함하는 하나 이상의 애플리케이션들에 관한 정보를 수신하는 동작; 그리고
상기 제1 애플리케이션 개발자의 상기 컴퓨팅 시스템에서, 상기 하나 이상의 최종 사용자들의 상기 컴퓨팅 디바이스들이 상기 하나 이상의 애플리케이션들을 실행하는 것과 관련하여 상기 온라인 애플리케이션 스토어에 보고한 상기 문제들 중 적어도 일부를 표시하는 보고를 디스플레이하는 동작을 포함하는 것을 특징으로 하는 컴퓨팅 시스템.
청구항 1에 있어서,
상기 제1 애플리케이션 개발자, 상기 하나 이상의 최종 사용자들 및 상기 온라인 애플리케이션 스토어를 운영하는 엔터티는 서로 독립적인 것을 특징으로 하는 컴퓨터로 구현되는 방법.