KR20060042383A

KR20060042383A - 서비스 제공자가 서비스 소비자에 의한 미납 사용에의 노출을 제어하기 위한 방법 및 시스템

Info

Publication number: KR20060042383A
Application number: KR1020050015999A
Authority: KR
Inventors: 마이클 디. 스미스; 밀러 티. 아벨
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-02-27
Filing date: 2005-02-25
Publication date: 2006-05-12
Also published as: CN1661615A; EP1569152A2; US7996323B2; JP4796312B2; EP1569152A3; US20050192877A1; JP2005243036A

Abstract

서비스 소비자가 서비스들을 요청했다는 것을 서비스 제공자가 서비스 중개자에게 증명할 수 있도록 서비스를 제공할 것을 서비스 제공자에게 요청하기 위한 분쟁 해결 시스템이 제공된다. 서비스 제공자의 서비스를 요청하기 시작하고자 하는 서비스 소비자는 단방향 함수를 사용하여 생성된 코드들의 시퀀스 중 최종코드를 서비스 중개자에 등록한다. 서비스 중개자는 상기 최종코드를 서비스 제공자에게 제공한다. 그러면 서비스 소비자는 시퀀스의 코드들을 사용하여 서비스 제공자에게 서비스들을 제공하도록 요청할 수 있다. 서비스 제공자가 요청을 수신하면 요청의 코드가 최종코드를 유도하기 위해 사용될 수 있는지를 확인한다. 만약 확인이 성공적이면, 서비스 제공자는 서비스 소비자에 의해 요청된 서비스들의 부인할 수 없는 증거로서 검증된 코드를 서비스 중개자에게 제공할 수 있다.

서비스 소비자, 서비스 제공자, 서비스 중개자, 시작코드, 최종코드, 단방향 함수

Description

서비스 제공자가 서비스 소비자에 의한 미납 사용에의 노출을 제어하기 위한 방법 및 시스템{METHOD AND SYSTEM FOR A SERVICE PROVIDER TO CONTROL EXPOSURE TO NON-PAYMENT BY A SERVICE CONSUMER}

도 1은 일 실시예에서 분쟁 해결 시스템의 컴포넌트들을 도시하는 블럭도.

도 2는 일 실시예에서 서비스 소비자, 서비스 중개자 및 서비스 제공자 사이의 정보의 흐름 예를 나타낸 도면.

도 3은 일 실시예에서 코드들의 시퀀스를 등록하는 서비스 소비자의 컴포넌트의 처리과정을 도시하는 흐름도.

도 4는 일 실시예에서 시퀀스를 생성하는 컴포넌트의 처리과정을 도시하는 흐름도.

도 5는 일 실시예에서 서비스 제공자로부터의 서비스를 요청하는 컴포넌트의 처리과정을 도시하는 흐름도.

도 6은 일 실시예에서 서비스 소비자로부터 등록 요청 메세지를 수신할 때 실행되는 서비스 중개자의 컴포넌트의 처리과정을 도시하는 흐름도.

도 7은 일 실시예에서 서비스 중개자로부터 등록 통지 메세지를 수신할 때 실행되는 서비스 제공자의 컴포넌트의 처리과정을 나타내는 흐름도.

도 8은 일 실시예에서 서비스 소비자로부터 서비스 요청 메세지가 수신될 때 실행되는 서비스 제공자의 컴포넌트의 처리과정을 도시하는 흐름도.

도 9는 일 실시예에서 분쟁을 처리하는 서비스 중개자의 컴포넌트의 처리과정을 도시하는 흐름도.

도 10은 일 실시예에서 서비스 소비자의 컴포넌트들을 도시하는 블럭도.

도 11은 일 실시예에서 서비스 소비자의 사용자가 어떻게 어플리케이션들에 대한 허가 제한들을 설정할 수 있는지를 도시하는 화면 설명.

도 12는 일 실시예에서 런타임 컴포넌트의 설치 서브 컴포넌트의 처리과정을 도시하는 흐름도.

도 13은 일 실시예에서 서비스 제공자에게 서비스를 수행하도록 요청하는 런타임 컴포넌트의 서브 컴포넌트의 처리과정을 도시하는 흐름도.

<도면의 주요 부분에 대한 부호의 설명>

101: 서비스 소비자

102: 서비스 중개자

103: 서비스 제공자

104: 네트워크

본 발명은 일반적으로 서비스 제공자에 의해 제공된 부인할 수 없는 증거(non-repudiatable evidence)에 기초하여 서비스 제공자와 서비스 소비자 사이의 분쟁을 해결하기 위한 방법 및 시스템에 관한 것이다.

서비스 제공자들로부터의 다양한 서비스들이 인터넷을 통하여 이용가능하다. 예를 들어, 어떤 서비스 제공자들은 지도 정보, 날씨 정보, 주식 정보 등을 제공한다. 서비스 소비자들(예를 들면, 개인용 컴퓨터)이 서비스 제공자들의 웹 서버로 서비스에 대한 요청을 전송한다. 웹 서버는 요청된 서비스를 수행하고(예를 들면, 요청된 정보를 검색함.), 그 서비스의 결과를 웹 페이지를 통해 서비스를 요청한 소비자에게 제공한다. 이런 서비스 제공자들 중 다수가 무료로 서비스 소비자들에게 서비스를 제공한다. 그러나, 전형적으로 서비스 제공자는 서비스 소비자들이 요청한 정보를 제공하는 웹 페이지의 광고 공간을 판매함으로써 수익을 얻는다.

컴퓨팅 장치들이 점점 작아짐에 따라, 정보를 디스플레이하는 화면 또한 작아지고 있다. 예를 들어, 휴대전화는 웹 접속이 허용되는 컴퓨팅 장치이지만 매우 작은 화면을 가지고 있어 광고를 포함하는 전형적인 웹 페이지를 표시할 수 없다. 따라서 휴대전화로 서비스를 제공하는 서비스 제공자는 광고를 통해서 수익을 얻을 수 없다. 이러한 컴퓨팅 장치들로 서비스를 제공하는 서비스 제공자들이 수익을 얻을 수 있는 방식을 가지는 것이 바람직할 것이다.

이러한 컴퓨팅 장치들이 점점 작아지고 있지만, 그들의 처리 능력은 증가하고 있다. 결과적으로, 이러한 컴퓨팅 장치들(예를 들면, 휴대 전화 및 휴대형 정보 단말기(PDA))은 많은 다른 어플리케이션들을 실행할 수 있다. 예를 들어, 휴대전화는 전자 메일, 지도 정보, 위치 정보, 달력 정보 등을 제공하는 어플리케이션들을 실행할 수 있다. 이러한 어플리케이션들은 컴퓨팅 장치가 판매될 때 미리 설 치되어 있거나 또는, 구입 후 사용자에 의해 설치되어야 할 수도 있다. 예를 들어, 휴대전화 사용자가 현재 위치의 지도가 휴대전화 화면에 표시되기를 원할 수 있다. 만약 지도 어플리케이션이 미리 설치되어 있지 않다면, 휴대전화 사용자는 인터넷으로부터 지도 어플리케이션을 다운로드하여 설치해야 한다. 지도 어플리케이션이 위치 서비스 제공자와 지도 서비스 제공자의 서비스들을 사용할 것을 필요로 할 수 있다. 지도 어플리케이션은 휴대전화 근방의 여러 셀(cell)들로부터 읽어온 정보에 기초하여 휴대전화의 현재 위치를 알아내기 위하여 위치 서비스 제공자를 사용하고, 사용자에게 표시하기 위한 적절한 지도를 획득하기 위해 지도 서비스 제공자에게 현재 위치를 제공한다.

그러한 컴퓨팅 장치들에서 어플리케이션들을 사용하는 데에는 몇 가지 어려움이 발생할 수도 있다. 한가지 어려움은 서비스 제공자들에 의해 사용된 광고 수익 모델이 그런 컴퓨팅 장치들에서 사용될 때는 잘 동작하지 않을 수 있다는 것이다. 서비스 사용자가 각 요청된 서비스에 대해 요금을 부과하는 것이 한가지 해결책이 될 것이다. 예를 들어, 위치 서비스 제공자는 각 요청된 위치에 대해 0.02$를 부과할 수 있다. 그러나, 요금 부과의 처리 비용이 너무 높기 때문에, 위치 서비스 제공자가 각 요청된 서비스마다 신용카드 요금을 부과하게 되는 것은 비실용적일 것이다. 위치 서비스 제공자가 서비스 소비자에 대한 요금부과들을 총합하여 한달에 단 한번만 신용카드 요금을 부과한다고 할지라도, 서비스 소비자(또는 컴퓨팅 장치의 사용자)가 그런 요금부과에 이의를 제기할 수 있는 비용효율적인 방법이 존재하지 않는다. 예를 들어, 축적된 요금이 10$가 될 수 있고, 그것은 이러한 분쟁을 해결하기 위해 필요한 신용카드 회사에 의한 조사의 처리비용을 거의 포함하지 않을 것이다. 이러한 분쟁을 자동적으로 해결하기 위한 방법을 찾는 것이 바람직할 것이다.

분쟁 해결책이 연관된 처리 비용을 가지지 않을지라도, 비용을 총합하는 것은 여전히 서비스 제공자에게 단점이 존재한다. 특히, 한가지 단점은 서비스 소비자에 의한 미납으로의 노출 위험을 가진다는 점이다. 서비스 제공자가 서비스 소비자의 신용카드 번호를 가질지라도, 예를 들어, 카드를 발행받은 사람이 최근에 신용카드를 취소했을 경우 요금이 감소될 수 있다. 그러한 미납에의 노출을 제어하기 위해, 서비스 제공자는 신용카드 요금을 더 빈번히 부과하길 원할지도 모르지만, 그러한 빈번한 요금부과의 단점은 각 요금부과가 부과될 양보다 더 많을 수도 있는 최소 처리 비용을 가질 수 있다는 점이다. 미납으로의 노출과 서비스에 대한 요금부과의 처리비용 사이의 용인할 수 있는 균형을 서비스 제공자가 명시하도록 허용하는 것이 바람직할 것이다.

그러한 컴퓨팅 장치들의 사용에 있어서 또다른 어려움은 컴퓨팅장치에 다운로드되어 설치된 어플리케이션이 올바르게 동작하지 않을 수도 있다는 점이다. 예를 들면, 설치된 어플리케이션이 위치 서비스 제공자로부터 매 10초마다 위치 정보를 요청하는 바이러스를 포함하고 있을 수 있다. 그러한 요청들은 서비스 제공자가 그 달에 대해 5000$이 넘는 서비스 요금을 서비스 사용자에게 부과했다는 신용카드 계산서가 수신될 때까지 서비스 소비자에게 알려지지 않을 수도 있다. 그런 어플리케이션이 올바르게 동작하는지를 자동으로 감지하는 방법을 갖는 것이 바람직할 것이다. 또한, 서비스 소비자가 그런 어플리케이션을 설치하는 것에 대해 더욱 인지된 결정을 내릴 수 있도록 동작 히스토리에 기초하여 어떤 어플리케이션이 신뢰할 수 있는지를 서비스 제공자가 알려주는 것이 바람직할 것이다.

일반적으로, 서비스 제공자가 서비스를 제공하고 참여자들(예를 들면, 서비스 제공자들, 서비스 소비자들, 그리고 어플리케이션들과 그 프로그램을 만든 사람들)이 신뢰할 수 없는 환경에서 다양한 어플리케이션들을 사용하는 서비스 소비자들을 위한 비용효율적인 방법을 가지는 것이 바람직할 것이다.

서비스 제공자가 서비스 소비자에 의한 미납으로의 노출을 제어하고 지불 요청과 관련된 비용을 제어하기 위한 시스템이 제공된다. 일 실시예에서, 서비스 제공자는 빌링 유닛(billing unit)에 포함될 서비스들의 수를 명시한다. 빌링 유닛은 서비스 제공자가 서비스 소비자에 의한 미납 위험을 감수할 서비스들의 수를 나타낸다. 그 수의 코드들의 시퀀스가 이전 응용 프로그램에 의해 생성된 코드에 단방향 함수를 성공적으로 적용함으로써 생성되는데, 시작코드로 시작하고, 최종코드로 끝난다. 서비스 제공자와 서비스 소비자 양측에 의해 신뢰되는 서비스 중개자가 최종코드를 서비스 제공자에게 제공한다. 서비스 소비자는 끝에서 두번째 코드로 시작하는 발생의 역순으로 된 시퀀스의 코드를 포함하는 요청을 서비스 제공자에게 전송한다. 서비스 제공자가 서비스 소비자로부터 시작코드를 수신하면, 서비스 제공자는 지불을 요청하기 위해, 그리고 요청된 서비스를 제공했다는 것을 서비 스 중개자에게 증명하기 위하여 상기 시작코드를 사용할 수 있다. 지불을 요청하는 것이 지불요청된 서비스들의 수에만 의존하지 않고 그와 관련된 비용들을 가질 수 있기 때문에, 서비스 제공자는 하나의 빌링 유닛에 많은 수의 서비스들을 가지고자 할 수 있다. 그러나 하나의 빌링 유닛에 많은 수의 서비스들을 포함하면 서비스 제공자는 미납으로의 노출 위험이 더욱 커진다. 따라서, 서비스 제공자는 빌링 유닛에 미납으로의 위험과 지불 요청과 관련된 비용 사이에 조화를 이루도록 서비스들의 수를 세팅할 수 있다.

서비스 제공자가 서비스 소비자에 의해 요청된 서비스들을 제공했다는 것을 서비스 중개자에게 증명할 수 있도록 서비스를 제공할 것을 서비스 제공자에게 요청하기 위한 분쟁 해결 방법 및 시스템이 제공된다. 일 실시예에서, 서비스 제공자에게 서비스를 요청하기 시작하고자 하는 서비스 소비자는 최종코드(end code)를 서비스 중개자에 등록한다. 최종코드는 단방향 함수(one-way function)를 시작코드(start code)에 적용함으로써 생성된 코드들의 시퀀스의 마지막 코드를 나타낸다. (단방향 함수는 비교적 계산하기 쉽지만, 그것의 역은 비교적 계산하기 어려운 함수이다.) 단방향 함수의 적용은 시작코드로 시작하고, 사이에 있는 중간 코드들 중의 어떤 숫자를 가지는 최종코드로 끝나는 시퀀스를 생성한다. 서비스 소비자의 등록을 수신하면, 서비스 중개자는 최종코드를 서비스 제공자에게 제공한다. 그리고 나서, 서비스 소비자는 서비스를 제공할 것을 서비스 제공자에게 요청하기 시작할 수 있다. 서비스 소비자가 서비스 제공자에게 전송한 각 요청은 시퀀스의 코드를 발생의 역순으로 포함한다. 함수가 단방향이기 때문에, 서비스 제공 자가 서비스 소비자로부터 수신된 것보다 시작 코드에 더 가까운 코드를 생성하기 위해 역함수를 적용하는 것은 비실용적일 것이다. 따라서, 만약 서비스 제공자가 시퀀스의 코드를 가진다면, 그 서비스 소비자로부터 수신되었다는 부인할 수 없는 증거로 간주될 수 있다. 게다가, 단방향 함수는 비교적 계산하기 쉬우므로, 서비스 제공자는 최종코드가 올바르게 유도될 수 있는지를 결정하기 위해 단방향 함수를 적용함으로써, 서비스 소비자로부터 수신된 코드가 시퀀스의 유효한 코드인지를 쉽게 확인할 수 있다. 따라서 서비스 제공자가 요청을 수신하면, 서비스를 제공하기 전에 그 요청의 코드가 최종코드를 유도하기 위해 사용될 수 있는지를 확인한다. 만약 확인이 성공적이면 서비스 제공자는 서비스 소비자에게 요청된 서비스를 제공한다. 서비스 제공자는 확인된 코드가 수신되기 전에 서비스 소비자가 요청했던 모든 서비스를 제공했다는 부인할 수 없는 증거로서 확인된 코드를 사용할 수 있다. 만약 검증이 성공적이지 않으면, 서비스 제공자는 서비스 소비자가 서비스를 요청했다는 부인할 수 없는 증거를 갖지 않으면 서비스 제공을 거부할 수 있다. 만약 서비스 소비자가 요청된 서비스를 제공받지 못했거나 제공된 서비스가 만족스럽지 않으면 서비스 소비자는 더이상 그 서비스 제공자의 서비스를 요청할 필요가 없다. 그런 경우에, 서비스 제공자는 서비스 소비자가 제공된 서비스에 불만족스러웠던 첫번째 요청을 통한 코드들(즉,부인할 수 없는 증거)만을 가질 것이다. 이러한 방식으로, 서비스 제공자는 부인할 수 없는 증거를 가진다는 것을 확신할 수 있고, 서비스 소비자는 제공된 서비스에 불만족할 때 언제든지 서비스 요청을 중지할 수 있다.

코드 수신 후, 서비스 제공자는 제공된 서비스에 대해 서비스 소비자에게 요금을 부과할 수 있다. 요금부과는 신용카드 서비스와 같은 제3자인 금융개체로 전송될 수 있다. 서비스 소비자가 요금부과에 이의를 제기한다면, 서비스 제공자나 서비스 소비자 둘 중 하나는 잘못된 것이다. (실제로, 어떤 상황에서는 양측 모두 잘못된 경우도 있다.) 그런 분쟁은 서비스 중개자에 의해 해결되는데, 서비스 중개자는 금융개체와 제휴될 수 있다. 서비스 중개자가 분쟁의 표시를 수신하면, 서비스 중개자는 서비스 제공자에게 요금부과된 서비스를 제공했다는 부인할 수 없는 증거로서 서비스 소비자로부터 수신했던 코드를 제공할 것을 요청할 수 있다. 서비스 중개자가 서비스 제공자로부터 코드를 수신하면, 등록시 서비스 소비자에 의해 제공된 최종코드가 올바르게 유도될 수 있는지를 결정하기 위해 수신된 코드로 시작하는 단방향 함수를 적용할 수 있다. 만약 최종코드가 올바르게 유도될 수 있고, 단방향 함수의 적용의 수가 요금부과된 서비스들과 일치한다면(예를 들어, 각 적용과 그에 의해 발생한 각 코드가 하나의 서비스에 대응할 수 있음) 서비스 중개자는 서비스 제공자를 분쟁의 승리자로 선언한다. 서비스 제공자에 의해 수신된 코드들의 수는 서비스 소비자에게 제공된 서비스들의 수를 나타낸다. 따라서, 만약 서비스 소비자가 10개의 서비스에 대해 요금을 부과받는다면, 서비스 제공자는 최종코드가 유도되기 전에 적어도 9개의 코드들이 유도될 필요가 있는 코드를 제공할 필요가 있다. 서비스 중개자는 시작코드로 시작하고 제공된 코드로 끝나는 코드들, 또는 제공된 코드로 시작하고 최종코드로 끝나는 코드들을 유도함으로써 제공된 코드를 확인할 수 있다. 어떤 경우든, 생성된 코드들의 수는 서비스 제공자 가 자신이 제공했다고 증명할 수 있는 서비스들의 수를 나타낸다. 만약 제공된 코드가 확인될 수 없으면, 서비스 중개자는 서비스 소비자를 승리자로 선언할 수 있다. 따라서, 서비스 중개자는 자동적으로 그리고 낮은 비용으로(즉, 어떠한 사람의 개입도 없이) 분쟁을 해결할 수 있다.

일 실시예에서, 서비스 중개자는 먼저, 단방향 함수를 적용하는 것 이외의 다른 방법을 사용하여 분쟁을 해결하고자 시도한다. 단방향 함수의 적용은 그것의 역에 비교하여 비교적 계산하기 쉽지만, 잦은 적용으로 실용적인 것보다 오히려 계산적으로 더 비용이 많이 든다. 예를 들어, 서비스 중개자는 하루에 수천 개의 분쟁을 해결할 수 있다. 서비스 중개자는 먼저, 요금부과된 서비스에 대응하는 코드들을 제공할 것을 서비스 제공자와 서비스 소비자 양측에게 요청함으로써 분쟁을 해결하고자 할 수 있다. 만약 코드들이 동일하다면, 서비스 소비자가 동의한 그 코드는 올바른 부인할 수 없는 증거이기 때문에 서비스 중개자는 서비스 제공자를 승리자로 선언한다. 그러나 만약 코드들이 동일하지 않다면, 서비스 제공자 혹은 서비스 소비자는 잘못된 것이다(혹은 양측 모두 잘못일 수도 있다). 그런 경우에, 서비스 중개자는 서비스 제공자 혹은 서비스 소비자에 의해 제공된 코드가 올바른지를 결정하기 위해 단방향 함수를 적용한다. 서비스 중개자는 올바른 코드를 제공한 측을 승리자로 선언한다. 만약 양측 모두 올바른 코드를 제공하지 않았다면 서비스 중개자는 양측 모두 올바르지 않은 정보를 제공하고 있으므로 분쟁이 해결될 수 없다고 선언한다. 대안으로, 서비스 중개자는 서비스 제공자가 자신의 요금부과를 지지할 수 있는 증거를 제공할 수 없었으므로, 서비스 소비자를 승리자로 선언할 수도 있다.

분쟁을 해결할 때 사용될 다른 증거로서, 서비스 제공자가 요청된 서비스들을 제공할 때 서비스 소비자에게 자신만의 코드를 제공할 수 있다. 서비스 제공자가 자신만의 코드들의 시퀀스를 생성하고 그것을 서비스 중개자에게 등록할 수 있을 것이다. 서비스 중개자는 최종코드를 서비스 소비자에게 제공할 수 있다. 그러면 서비스 제공자는 각 서비스 요청에 응답하여 자신의 코드들을 생성의 역순으로 서비스 소비자에게 제공할 수 있다. 분쟁을 해결할 때, 서비스 중개자는 서비스 제공자와 서비스 소비자에게 양측 모두에 의해 생성된 해당 코드들을 제공할 것을 요청할 수 있다. 서비스 중개자는 서비스 소비자의 코드들이 확인된 것과 같은 방식으로 코드들을 확인할 수 있다. 만약 서비스 제공자가 올바른 서비스 소비자 코드와 올바른 서비스 제공자 코드를 제공했다면, 서비스 중개자는 서비스 제공자를 승리자로 선언한다. 만약 서비스 제공자가 올바르지 않은 서비스 소비자 코드를 제공하고 서비스 소비자가 두 코드 모두 올바르게 제공했다면, 서비스 중개자는 서비스 소비자를 승리자로 선언한다. 그렇지 않으면, 양측 모두 올바르지 않다고 판명된 증거를 제공했으므로 분쟁이 해결될 수 없는 것으로 선언할 수 있다. 서비스 제공자에 의해 생성된 코드들의 사용은 분쟁의 해결책이 증거와 일치한다는 것을 확인하는 또다른 단계를 제공한다.

본 기술분야에서 숙련된 기술을 가진 자는 이 분쟁 해결 시스템이 많은 변형이 가능하다는 점을 알 수 있을 것이다. 예를 들면, 서비스 중개자가 서비스 소비자에 대한 코드들을 생성하여, 그것들을 서비스 소비자에게 제공하고, 서비스 제공 자에 대한 코드들을 생성하여 그것들을 서비스 제공자에게 제공할 수 있다. 대안으로, 자신들의 시퀀스를 생성하는데에 사용되는 등록 과정 동안 서비스 중개자가 시작코드들을 선택하고, 그것들을 서비스 소비자들과 서비스 제공자들에게 제공할 수 있다. 만약 서비스 소비자가 코드들의 시퀀스를 생성한다면, 서비스 소비자는 등록 동안 시작코드, 최종코드, 또는 둘 모두를 서비스 중개자에게 제공할 수 있다. 만약 서비스 중개자가 단지 시작코드만을 제공받는다면, 서비스 중개자는 최종코드를 유도하기 위해 명시된 횟수만큼 단방향 함수를 적용하고 유도된 최종코드를 서비스 제공자에게 제공할 수 있다. 만약 서비스 중개자가 최종코드를 제공받는다면, 즉시 서비스 제공자에게 제공할 수 있다. 서비스 제공자가 부인할 수 없는 증거를 제공할 때, 서비스 중개자는 최종코드가 유도될 수 있는지를 알기 위해 단방향 함수를 적용할 수 있다. 서비스 제공자가 자신의 코드들을 생성할 때, 유사한 과정이 발생할 수 있다.

본 기술 분야에서 숙련된 지식을 가진 자는 서비스 소비자로부터 서비스 제공자로의 코드 전송 시점이 변화될 수 있다는 점도 알 수 있을 것이다. 예를 들면, 서비스 소비자는 서비스 제공자가 요청된 서비스를 제공한 후에만 코드를 제공할 지도 모른다. 코드는 다음 서비스 요청 시, 또는 서비스가 제공된 직후에 제공될 수도 있다. 만약 서비스 제공자가 코드를 수신하지 않거나, 또는 코드의 정확성을 확인할 수 없다면, 서비스 제공자는 서비스 소비자로 더이상 서비스를 제공하기를 거부할 수 있다. 코드가 요청된 서비스가 제공되기 전에 제공되면, 서비스 소비자는 서비스 제공자가 서비스를 제공하지 않을 것이라는 위험을 가정한다. 반 대로, 요청된 서비스가 제공된 후에 코드가 제공되면, 서비스 제공자는 서비스 소비자가 코드를 전송하지 않을 위험을 가정한다. 본 기술 분야에서 통상적인 지식을 가진 자는 서비스 제공자가 확인할 수 있는 코드를 수신할 때 서비스 소비자가 서비스를 요청했음을 증명하기 위하여 그 코드를 사용할 수 있다는 점을 알 수 있을 것이다.

시퀀스의 길이 혹은 시퀀스에서의 코드들의 수는 하나의 등록에 기초하여 요청될 수 있는 서비스들의 수를 나타낸다. 예를 들면, 만약 시퀀스에 101개의 코드가 있다면, 100개의 서비스가 요청될 수 있다. 최종코드는 서비스 중개자로부터 서비스 제공자로 즉시 제공되기 때문에 서비스를 요청하기 위해 사용되지 않는다. 일 실시예에서, 시퀀스에서의 코드들의 수는 빌링 유닛(billing unit)을 나타낸다. 빌링 유닛은 서비스 제공자가 하나의 단일 요금부과 처리에서 부과할 수 있는 최소 서비스 수를 나타낸다. 서비스 제공자가 서비스 소비자로부터 시작코드를 수신하면 서비스 제공자는 그 빌링 유닛의 모든 서비스들에 대해 서비스 소비자에게 요금부과할 수 있다. 서비스 제공자는 미납 장애로의 노출과 요금부과 처리 비용을 균형잡기 위해 빌링 유닛에 코드들의 수를 명시할 수 있다. 서비스 제공자는 한번에 많은 수의 서비스에 대해서만 지불을 요청함으로써 요금부과 처리 비용을 줄이기를 원할 수 있다. 한번의 지불요청에 포함된 서비스들의 수가 많을수록, 행해지는 지불요청의 수는 적어지고, 제공된 서비스 당 요금부과 처리 비용은 작아진다. 그러나, 각 요금부과에 의해 포함되는 서비스들의 수가 많을수록, 서비스 소비자에 의한 미납으로의 노출은 더 커지게 된다. 예를 들어, 만약 빌링 유닛에 있는 서비스 들의 수가 1000 이라면, 서비스 제공자는 서비스 소비자가 지불할 수 없다면(예를 들어, 파산한 경우) 1000개의 서비스가 미납될 수 있는 위험을 가지게 된다. 그러나, 미납 위험은 빌링 유닛 당 많은 서비스 요청들을 갖는 것에 의해 요금부과 처리 비용을 잠재적으로 절약함으로써 커버될 수 있다.

일 실시예에서, 서비스 소비자는 실행 중인 어플리케이션이 올바르지 않게 동작하고 있는지를 감지할 수 있다. 예를 들면, 어플리케이션이 요청하도록 허가된 것보다 더 많은 서비스들을 요청하려고 할 수 있다. 서비스 소비자는 그런 올바르지 않은 동작을 감지하면, 자동적으로 그 어플리케이션을 삭제하고 서비스 제공자에게 알릴 수 있다. 서비스 제공자는 어플리케이션이 정말 올바르지 않게 동작하고 있는지를 결정하기 위해 다양한 서비스 소비자들에 의해 제공된 통지를 분석할 수 있다. 만약 그렇다면, 서비스 제공자는 어플리케이션이 서비스 제공자를 사용하도록 허가되지 않았음을 확신할 수 있다. 또다른 서비스 소비자가 그 어플리케이션을 설치하고자 할 때, 서비스 소비자는 그 어플리케이션이 허가받았는지를 알기 위해 서비스 제공자를 체크해 볼 수 있다. 만약 그렇지 않다면, 서비스 소비자는 어플리케이션의 설치를 중지할 수 있다. 반대로, 만약 서비스 제공자가 많은 어플리케이션들이 올바르지 않게 동작하고 있지만 어떤 서비스 소비자도 그런 통지를 제공하지 않고 있음을 감지한다면, 서비스 제공자는 어플리케이션이 아닌 서비스 소비자가 올바르지 않게 동작하고 있는 것으로 추론할 수 있다. 그런 경우에, 서비스 제공자는 서비스 소비자가 서비스 제공자를 사용하도록 부여받은 권한을 철회할 수 있다. 이런 방식으로, 서비스 제공자는 어떤 어플리케이션 혹은 서비스 소비자들이 올바르지 않게 동작하고 있는지를 결정하기 위해 어플리케이션들에 대한 정보를 수집할 수 있다.

도 1은 실시예에서 분쟁 해결 시스템의 컴포넌트를 도시하는 블럭도이다. 서비스 소비자(101), 서비스 중개자(102) 및 서비스 제공자(103)가 네트워크(104)로 연결된다. 서비스 중개자는 서비스 소비자와 서비스 제공자로부터 의도된 통신이 실제로 그들로부터 이루어지고 있고 사칭자(imposter)로부터 이루어지고 있는 것이 아님을 확신하기 위해 다양한 잘 알려진 인증 기술 중 어떤 방법이라도 사용할 수 있다. 서비스 소비자는 휴대형 정보 단말기(PDA), 휴대전화, 위성 항법 장치(GPS), 개인용 컴퓨터(PC) 등과 같은 다양한 종류의 컴퓨팅 장치를 포함할 수 있다. 서비스 제공자들은 다양한 서비스를 서비스 소비자들에게 제공할 수 있다. 예를 들면, 만약 서비스 소비자가 휴대전화라면, 서비스 제공자는 현재 위치를 제공하는 위치 서비스를 제공할 수 있다.

서비스 소비자, 서비스 제공자 및 서비스 중개자의 컴퓨터 시스템은 중앙처리장치(CPU), 메모리, 입력장치(예를 들면, 키보드와 포인팅 장치), 출력장치(예를 들면, 표시 장치) 및 저장 장치(예를 들면, 디스크 드라이브)를 포함할 수 있다. 메모리와 저장 장치는 생성 시스템을 구현하는 명령들을 포함할 수 있는 컴퓨터 판독가능 매체이다. 또한, 데이터 구조들과 메세지 구조들은 통신 링크로의 신호와 같은 데이터 전송 매체를 통해 저장 혹은 전송될 수 있다. 인터넷, 근거리통신망(LAN), 광역통신망(WAN), 또는 점대점 전화회선 연결과 같은 다양한 통신 링크들이 사용될 수 있다.

도 1은 분쟁 해결 시스템이 구현될 수 있는 적절한 운영 환경의 예를 도시한다. 운영 환경은 적절한 운영 환경의 한가지 예일 뿐이며 분쟁 해결 시스템의 사용 혹은 기능성의 범위에 어떠한 제한을 행하고자 하는 것은 아니다. 사용하기에 적절할 수 있는 다른 잘 알려진 컴퓨팅 시스템, 환경 및 구조들은 개인용 컴퓨터, 서버 컴퓨터, 포켓용 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 프로그래밍 가능한 가전기기, 네트워크 PC, 미니 컴퓨터, 메인프레임 컴퓨터, 시스템 혹은 장치들을 포함하는 분산 컴퓨팅 환경 등을 포함한다.

분쟁 해결 시스템은 하나 이상의 컴퓨터 또는 기타 장치들에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령의 일반적인 문맥으로 설명될 수 있다. 일반적으로 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 전형적으로, 프로그램 모듈의 기능성은 다양한 실시예에서 바람직하도록 결합되거나 분산될 수 있다.

도 2는 일 실시예에서 서비스 소비자, 서비스 중개자 및 서비스 제공자 사이의 정보의 흐름 예를 도시하고 있다. 이 예에서, 서비스 제공자(203)는 그 자신의 코드의 시퀀스를 제공하지 않는다. 서비스 소비자(201)가 서비스 제공자에게 서비스를 요청하고자 할 때, 시작코드를 선택하고 시작코드로부터 유도된 코드들의 시퀀스를 저장한다(1단계). 일 실시예에서, 시퀀스의 코드들의 수는 예를 들어, 서비스 중개자(202)에 등록되는 서비스 제공자와 서비스 소비자 사이의 계약에서 미리 정의될 수 있다. 서비스 소비자는 서비스 중개자에게 등록 요청을 전송한다(2 단계). 등록 요청은 시작코드, 최종코드, 서비스 제공자의 식별자(SP), 그리고 서비스들이 따라야 할 계약의 식별자(K) 등을 포함할 수 있다. 서비스 중개자는 요청의 정당성을 확인하고(예를 들어, 서비스 제공자와 계약이 유효한지를 확인) 서비스 소비자에 대한 등록 기록을 저장한다(3단계). 서비스 중개자는 분쟁이 있는 요금부과들이 해당 등록으로 추적될 수 있도록 각 등록에 유일한 등록 번호를 할당할 수 있다. 서비스 중개자는 서비스 제공자에게 등록 통지를 전송한다(4단계). 통지는 최종코드와 서비스 소비자의 식별자(SC)와 계약 식별자를 포함할 수 있다. 서비스 제공자는 통지의 정당성을 확인하고 서비스 요청을 검증하는 데에 사용하기 위해 통지의 정보를 저장한다(5단계). 서비스 제공자는 등록의 통지가 수락되었음을 확인하기 위해 서비스 중개자에게 응답한다(6단계). 다음으로, 서비스 중개자는 서비스 소비자에게 등록이 수락되었음을 알리는 응답을 보낸다(7단계). 서비스 소비자는 서비스 제공자에게 요청을 전송한다(8단계). 각 요청은 시퀀스의 코드를 포함한다. 요청을 수신하면 서비스 제공자는 서비스 소비자로부터 전에 수신된 마지막 코드 즉, 서비스 중개자에 의해 제공된 최종코드를 처음에 검색해온다(9단계). 서비스 제공자는 검색된 코드와 수신된 코드가 일치하는 지를 결정하기 위하여 수신된 코드에 단방향 함수를 적용한다. 만약 일치한다면, 수신된 코드가 올바른 것으로 판명되고 서비스 제공자는 수신된 코드를 저장하고(10단계) 서비스를 제공한다. 서비스 제공자는 서비스 소비자에게 서비스 수행의 결과를 전송한다(11단계). 대안적으로, 서비스 소비자는 다소 다른 방식으로 서비스 제공자가 서비스를 수행했음을 판명할 수 있다. 예를 들어, 만약 서비스 요청이 자동판매기로 상품을 지출하기 위한 권한부여를 전송하기 위한 것이었다면, 사용자는 서비스가 제공되었는지를 외관상으로 확인할 수 있다. 8-11단계가 서비스 소비자가 요청하는 각 서비스에 대해 미리 정해진 시퀀스의 길이까지 반복된다. 시퀀스의 모든 서비스들이 완료되면, 서비스 제공자는 서비스 소비자에게 요금을 부과할 수 있다. 요금부과는 등록의 고유 식별자를 포함할 수 있다. 만약 서비스 소비자가 요금부과에 이의를 제기한다면, 서비스 제공자는 서비스 소비자에 의해 제공된 시작코드를 서비스를 제공했다는 부인할 수 없는 증거로서 사용할 수 있다. 서비스 제공자는 시작코드를 증거로서 서비스 중개자에게 제공할 수 있다. 서비스 중개자는 그것을 등록 시 서비스 소비자에 의해 제공된 시작코드와 비교하여 서비스 제공자가 분쟁의 승리자인지를 결정할 수 있다.

도 3-9는 분쟁 해결 시스템의 서비스 소비자, 서비스 중개자, 서비스 제공자에 의해 수행되는 처리과정을 도시하는 흐름도이다. 도시된 처리과정에서, 서비스 제공자는 그 자신의 시퀀스 코드들을 생성하지 않는다. 도 3은 일 실시예에서 코드들의 시퀀스를 등록하는 서비스 소비자의 컴포넌트의 처리과정을 나타내는 흐름도이다. 컴포넌트는 서비스 제공자와 요청된 서비스들이 따라야할 계약의 표시를 전달할 때 호출되어 실행될 수 있다. 만약 서비스 소비자와 서비스 제공자 사이에 단 하나의 계약이 존재한다면, 그것은 식별될 필요가 없다. 또한, 계약이 서비스 중개자나 서비스 제공자에 의해 암시되어 있을 수도 있다. 블럭(301)에서, 컴포넌트는 계약에 기초하여 요청될 서비스들의 수를 선택한다. 블럭(302)에서 컴포넌트는 선택된 서비스 수에 대한 코드들의 시퀀스를 생성하기 위하여 함수를 실행한다. 블럭(303)에서 컴포넌트는 등록 요청 메세지를 서비스 중개자에게 전송한다. 등록 요청 메세지는 시작코드, 최종코드, 서비스 제공자 및 계약의 식별자를 포함할 수 있다. 블럭(304)에서, 컴포넌트는 서비스 중개자로부터의 응답을 기다린다. 결정 블럭(305)에서, 만약 응답이 등록이 수락되었음을 나타내면 컴포넌트는 블럭(306)으로 진행하고, 만약 그렇지 않으면 거절된 등록을 처리함으로써 상기 모드가 계속된다. 블럭(306)에서 컴포넌트는 제공된 서비스들의 수를 추적하기 위해 변수를 초기화한다. 그러면 컴포넌트는 완료된다.

도 4는 일 실시예에서 시퀀스를 생성하는 컴포넌트의 처리과정을 나타내는 흐름도이다. 컴포넌트는 시퀀스에 의해 표현될 서비스들의 수를 전달받는다. 블럭(401)에서 컴포넌트는 시퀀스의 첫번째 코드 즉 시작코드를 식별하기 위하여 인덱스 i를 세팅하고 시작코드를 세팅한다. 시작코드는 랜덤 발생기에 의해 선택될 수 있다. 시퀀스는 어레이 S에 저장된다. 블럭(402-404)에서는, 컴포넌트가 코드들의 시퀀스를 생성하기 위해 단방향 함수를 적용하면서 반복된다. 블럭(402)에서, 컴포넌트는 시퀀스에서 다음 코드를 가리키기 위해 인덱스를 증가시킨다. 결정 블럭(403)에서 인덱스가 시퀀스의 서비스들의 수보다 크다면, 컴포넌트는 시퀀스를 리턴하고, 그렇지 않으면 컴포넌트는 블럭(404)으로 진행한다. 블럭(404)에서 컴포넌트는 시퀀스에서 이전 코드에 단방향 함수를 적용하여 생성된 코드를 시퀀스 내에서 인덱스 i가 가리키는 위치에 저장한다. 컴포넌트는 시퀀스의 다음 코드를 생성하기 위해 블럭(402)으로 되돌아간다.

도 5는 일 실시예에서 서비스 제공자로부터의 서비스를 요청하는 컴포넌트의 처리과정을 도시하는 흐름도이다. 결정 블럭(501)에서 만약 시퀀스의 서비스들의 수가 이미 요청되었으면 컴포넌트는 서비스가 요청될 수 없다는 표시를 리턴한다. 그렇지 않으면 컴포넌트는 블럭(502)으로 진행한다. 블럭(502)에서 컴포넌트는 요청된 서비스들의 수를 추적하기 위해 사용되고 요청될 수 있는 서비스들의 수를 나타내는 변수를 감소시킨다. 블럭(503)에서, 컴포넌트는 시퀀스의 인덱스가 가리키는 코드를 포함하는 서비스 요청 메세지를 서비스 제공자에게 전송하고, 요청 메세지가 전송되었다는 표시를 리턴한다.

도 6은 일 실시예에서 서비스 중개자가 서비스 소비자로부터 등록 요청 메세지를 수신할 때 실행되는 서비스 중개자의 컴포넌트의 처리과정을 도시하는 흐름도이다. 컴포넌트는 서비스 소비자의 식별자, 시작코드, 최종코드, 서비스 제공자의 식별자, 계약의 식별자를 전달받는다. 결정 블럭(601)에서, 만약 계약이 서비스 소비자와 서비스 제공자 사이의 유효한 계약을 나타낸다면 컴포넌트는 블럭(602)로 진행한다. 그렇지 않으면 컴포넌트는 에러를 리턴하고, 등록이 거절되었음을 서비스 소비자에게 알린다. 일 실시예에서, 서비스 소비자와 서비스 제공자는 그들의 계약을 서비스 중개자에게 등록할 수 있다. 계약은 시퀀스에 포함될 서비스들의 수와, 서비스 제공자가 제공된 각 서비스에 부과할 총액과 같은 가격 정보를 식별할 수 있다. 서비스 중개자는 분쟁을 해결할 때 등록된 계약 정보를 사용한다. 블럭(602)에서, 컴포넌트는 분쟁이 해결될 필요가 있을 때 사용될 수 있도록 전달받은 정보를 저장한다. 블럭(603)에서, 컴포넌트는 등록 통지 메세지를 서비스 제공자에게 전송한다. 메세지는 서비스 소비자, 계약, 최종코드를 식별한다. 블럭 (604)에서, 컴포넌트는 서비스 제공자로부터 등록 확인 메세지를 기다린다. 확인 응답이 수신되면 컴포넌트는 블럭(605)에서 등록 응답 메세지를 서비스 소비자에게 전송하여 등록이 수락되었음을 알린다. 컴포넌트는 등록이 성공적임을 알리는 표시를 리턴한다.

도 7은 일 실시예에서 서비스 중개자로부터 등록 통지 메세지가 수신될 때 실행되는 서비스 제공자의 컴포넌트의 처리과정을 도시한 흐름도이다. 컴포넌트는 서비스 소비자 식별자, 계약 식별자, 최종코드를 전달받는다. 컴포넌트는 서비스 소비자와 계약의 유효성을 검사한다. 만약 유효하지 않으면 컴포넌트는 확인되지 않음 메세지 또는 응답 거절 메세지를 서비스 중개자에게 보낼 수 있다. 블럭(701)에서 컴포넌트는 계약으로부터 시퀀스 내의 서비스들의 수를 알아낸다. 블럭(702)에서 컴포넌트는 초기 수로부터 카운트 다운함으로써 요청된 서비스들의 수를 추적하기 위해 변수를 세팅한다. 블럭(703)에서 컴포넌트는 어레이 S에 최종코드를 저장하고 완료한다.

도 8은 일 실시예에서 서비스 소비자로부터 서비스 요청 메세지가 수신될 때 실행되는 서비스 제공자의 컴포넌트의 처리과정을 도시하는 흐름도이다. 컴포넌트는 서비스 소비자의 식별자, 계약 식별자 및 코드를 전달받는다. 컴포넌트는 코드가 올바른지를 확인하고, 만약 올바르다면 서비스를 수행한다. 블럭(801)에서 컴포넌트는 서비스 소비자와 계약에 대한 시퀀스(S)에서 남아있는 제공될 서비스들의 수(i)를 읽어온다. 결정 블럭(802)에서 만약 제공될 서비스가 남아있지 않다면 컴포넌트는 에러를 리턴하고, 그렇지 않으면 블럭(803)으로 진행한다. 결정 블럭 (803)에서 만약 수신된 코드로의 단방향 함수 적용이 수신된 마지막 코드와 일치하면 컴포넌트는 블럭(804)으로 진행하고, 그렇지 않으면 컴포넌트는 에러 표시를 리턴한다. 블럭(804)에서 컴포넌트는 제공될 남아있는 서비스들의 수를 추적하기 위해 변수를 감소시킨다. 블럭(805)에서 컴포넌트는 수신된 코드를 저장하고, 전달받은 코드가 확인되었음을 나타내는 표시를 리턴한다. 서비스 제공자는 부인할 수 없는 증거로서의 사용을 위해, 그리고 수신된 다음 코드의 정확성을 확인하기 위하여 단지 마지막 코드만을 저장하면 된다.

도 9는 일 실시예에서 분쟁을 다루는 서비스 중개자의 컴포넌트의 처리과정을 도시하는 흐름도이다. 이 컴포넌트는 서비스 소비자가 서비스 제공자로부터의 요금부과에 이의를 제기할 때 실행된다. 이 컴포넌트는 서비스 소비자에 의해 생성된 코드들의 시퀀스에만 기초하여 분쟁 해결을 처리한다. 컴포넌트는 서비스 소비자 식별자, 서비스 제공자 식별자, 그리고 분쟁이 있는 시퀀스의 등록(Registration)을 전달받는다. 블럭(901)에서 컴포넌트는 서비스 소비자로부터의 적절한 코드를 요청한다. 적절한 코드는 서비스 소비자가 요금부과받은 서비스들의 수를 나타낸다. 블럭(902)에서 컴포넌트는 서비스 제공자에게 적절한 코드(즉, 부인할 수 없는 증거)를 제공할 것을 요청한다. 결정 블럭(903)에서 만약 수신된 코드들이 일치하면 컴포넌트는 서비스 제공자를 승리자로 선언하고, 그렇지 않으면 컴포넌트는 블럭(904)으로 진행한다. 블럭(904)에서 컴포넌트는 시작코드와 등록에 대한 서비스들의 수를 읽어온다. 블럭(905)에서 컴포넌트는 시퀀스의 코드들을 생성한다. 결정 블럭(906)에서, 만약 서비스 제공자의 코드가 생성된 코드와 일치 하면, 컴포넌트는 서비스 제공자를 승리자로 선언하고, 그렇지 않으면 블럭(907)으로 진행한다. 결정 블럭(907)에서 만약 서비스 소비자의 코드가 생성된 코드와 일치하면 컴포넌트는 서비스 소비자를 승리자로 선언하고, 그렇지 않으면 컴포넌트는 서비스 소비자와 서비스 제공자 모두 요금부과된 서비스를 뒷받침하는 코드를 제공하지 않았기 때문에 분쟁이 해결될 수 없음을 보고한다.

일 실시예에서, 서비스 제공자와 서비스 소비자 모두 코드 시퀀스를 생성할 때, 서비스 중개자는 한 당사자가 양측 코드 모두 정확히 제공할 때에만 승리자로 선언한다. 분쟁을 해결하기 위해 서비스 중개자는 그들의 입장을 지지하기 위한 서비스 제공자 코드들과 서비스 소비자 코드들을 제공할 것을 양측에 요구한다. 만약 서비스 제공자에 의해 제공된 코드들이 올바르다면 서비스 중개자는 서비스 제공자를 승리자로 선언한다. 그렇지 않으면, 만약 서비스 소비자에 의해 제공된 코드들이 둘다 올바르다면, 서비스 중개자는 서비스 소비자를 승리자로 선언한다. 다른 모든 경우에, 양측 모두 적어도 하나의 올바르지 않은 코드를 제공한 것이고, 따라서 서비스 중개자는 승리자가 없음을 선언한다.

도 10은 일 실시예에서 서비스 소비자의 컴포넌트들을 도시하고 있는 블럭도이다. 서비스 소비자(1000)는 서비스 소비자 코드 컴포넌트(1001), 런타임 컴포넌트(1002), 어플리케이션들(1003), 코드 저장장치(1004), 계약 저장장치(1005), 응용 프로그램 저장장치(1006)를 포함한다. 서비스 소비자 코드 컴포넌트는 시퀀스를 생성하고 서비스 중개자에 시퀀스를 등록하는 일을 한다. 런타임 컴포넌트는 어플리케이션들이 서비스 제공자들에 접속할 수 있는 환경을 제공할 책임이 있다. 런타임 컴포넌트는 자신이 허가받은 것을 초과하여 서비스들을 요청하는 어플리케이션이 삭제되고, 해당하는 통지가 서비스 제공자에게 보내질 것을 보증한다. 코드 저장장치는 등록들에 관련된 정보를 포함한다. 각 엔트리는 서비스 제공자, 계약, 시퀀스, 각 등록된 시퀀스에 대한 시퀀스로의 현재 인덱스를 식별한다. 계약 저장장치는 서비스 소비자의 계약들에 대한 정보를 포함한다. 계약 저장장치의 각 엔트리는 서비스 제공자와 계약 사항을 식별한다. 응용 프로그램 저장장치는 각 어플리케이션들에 대한 서비스들의 한계에 대한 정보를 포함한다. 응용 프로그램 저장장치의 각 엔트리는 어플리케이션, 서비스 제공자, 허가된 한계, 서비스의 현재 사용성을 식별할 수 있다.

도 11은 일 실시예에서 서비스 소비자의 사용자가 어플리케이션들에 대한 허가된 한계를 어떻게 설정할 수 있는지를 보여주는 화면 설명이다. 화면설명(1100)은 어플리케이션 이름(1101)과 허가 테이블(1102)을 포함한다. 허가 테이블은 서비스 제공자, 누적 한계(cumulative limit), 허가 한계(authorized limit) 및 기간(period)에 대한 열을 포함한다. 서비스 제공자 열은 어플리케이션이 액세스하도록 허가된 서비스 제공자를 나타낸다. 누적 한계는 모든 어플리케이션들에 걸쳐서 허가된 서비스 제공자로의 서비스 요청들의 총 수를 나타낸다. 허가 한계는 어플리케이션이 서비스 제공자에게 요청하도록 허가된 서비스 요청의 수를 나타낸다. 예를 들어, 테이블의 첫 번째 행은 어플리케이션이 위치 서비스 제공자를 사용할 필요가 있다는 것을 나타내며, 하나의 그룹으로서의 어플리케이션들이 한달에 500개의 서비스를 요청하도록 허가되었다는 점을 나타내고, 이 어플리케이션이 한달에 50개의 서비스까지 요청하도록 허가되었다는 것을 알려준다. 이 표시화면으로부터의 정보가 응용 프로그램 저장장치에 저장된다.

도 12는 일 실시예에서 런타임 컴포넌트(runtime component)의 설치 서브컴포넌트(installation subcomponent)의 처리과정을 나타내는 흐름도이다. 블럭(1201)에서, 컴포넌트는 어플리케이션으로부터 인증 정보를 읽어온다. 인증 정보는 어플리케이션의 비밀키(private key)를 사용하여 암호화된 어플리케이션 이름일 수 있다. 컴포넌트는 이름을 복호하기 위하여 어플리케이션의 공개키(public key)를 사용할 수 있다. 결정 블럭(1202)에서, 만약 컴포넌트가 어플리케이션이 인증된 것이라고 결정한다면(즉, 이름이 올바르게 복호된다면), 컴포넌트는 블럭(1203)으로 진행하고 그렇지 않다면 컴포넌트는 블럭(1208)으로 진행하여 설치를 중지하고 종료한다. 블럭(1203-1207)에서, 컴포넌트는 서비스 소비자가 어플리케이션이 필요로 하는 서비스 제공자들에 가입했는지를 결정하기 위해 반복된다. 블럭(1203)에서 컴포넌트가 어플리케이션에게 필요로 하는 다음 서비스 제공자가 있는지를 질문한다. 결정 블럭(1204)에서, 만약 어플리케이션이 또다른 서비스 제공자를 필요로 한다는 것을 알려주면, 컴포넌트는 블럭(1205)으로 진행하고, 그렇지 않으면 컴포넌트는 블럭(1209)으로 진행한다. 결정 블럭(1205)에서 만약 서비스 소비자가 서비스 제공자에게 가입했다면, 컴포넌트는 블럭(1206)으로 진행하고, 그렇지 않으면 서비스 소비자는 그 어플리케이션을 지원할 수 없으므로 블럭(1208)에서 설치를 중지하고 종료한다. 블럭(1206)에서, 컴포넌트는 서비스 제공자에게 어플리케이션이 상기 서비스 제공자를 사용하도록 허가되었는지를 묻는다. 결정 블럭 (1207)에서, 만약 상기 어플리케이션이 허가되었다면 컴포넌트는 블럭(1203)으로 되돌아가 어플리케이션에게 필요한 다음 서비스 제공자가 있는지를 질문하고, 그렇지 않으면 컴포넌트는 블럭(1208)에서 설치를 중단하고 종료한다. 블럭 (1209)에서 서비스 소비자는 어플리케이션이 필요로 하는 모든 서비스 제공자들을 제공할 수 있고, 컴포넌트는 도 11의 화면 설명을 사용하여 각 서비스 제공자에 대한 서비스 허가 한계를 입력한다. 블럭(1210)에서, 컴포넌트는 어플리케이션을 설치하고 완료한다.

도 13은 일 실시예에서 서비스를 수행하도록 서비스 제공자에게 요청하는 런타임 컴포넌트의 부 컴포넌트의 처리과정을 나타내는 흐름도이다. 블럭(1301)에서 컴포넌트는 응용 프로그램 저장장치로부터 어플리케이션 데이터를 읽어온다. 결정 블럭(1302)에서 만약 서비스 요청이 서비스 제공자에 대한 어플리케이션의 허가 한계를 초과하면 컴포넌트는 블럭(1305)으로 진행하고, 그렇지 않으면 블럭(1303)으로 진행한다. 블럭(1303)에서, 컴포넌트는 서비스의 증가된 사용량을 나타내기 위해 응용 프로그램 저장장치에 어플리케이션 데이터를 갱신한다. 블럭(1304)에서, 컴포넌트는 서비스 제공자에게 시퀀스의 다음 코드를 포함하는 요청을 전송하고 완료한다. 블럭(1305)에서 컴포넌트는 서비스 제공자에게 어플리케이션이 올바르지 않게 동작하고 있다는 보고를 전송한다. 블럭(1306)에서 컴포넌트는 어플리케이션을 삭제하고 완료한다.

본 기술분야에서 통상적인 지식을 가진 자는 서술된 기술의 많은 변형이 가능하다는 것을 알 것이다. 예를 들어, 서비스 소비자가 서비스들의 시퀀스를 요청 하기를 원할 때 공유키와 비밀키 쌍을 생성할 수 있다. 서비스 소비자는 공유키를 서비스 중개자에게 등록할 수 있고, 서비스 중개자는 공유키를 서비스 제공자에게 제공할 수 있다. 서비스 소비자가 서비스 요청을 전송할 때 비밀키로 암호화된 시퀀스 번호를 포함한다. 서비스 제공자가 요청을 수신하면, 공유키를 사용하여 시퀀스 번호를 복호하고 올바른 것임을 확인할 수 있다. 만약 올바른 것이라면 서비스 제공자는 암호화된 시퀀스 번호를 부인할 수 없는 증거로서 사용할 수 있다.

본 기술분야에서 통상적인 지식을 가진 자는 또한, 서비스 소비자가 요청하여 몇 서비스를 제공받았다는 명백한 증거로서 서비스 제공자에 의해 생성되고 제공된 코드를 사용할 수 있다는 점을 알 수 있을 것이다. 그러한 증거는 예를 들어 서비스 소비자가 최소 수의 서비스를 요청한다면 할인을 받을 때 유용할 수 있다.

본 기술분야에서 통상적인 지식을 가진 자는 또한 런타임 환경이 어플리케이션이 오동작하고 있는지를 결정하기 위해 여러 다른 기술을 사용할 수 있다는 점도 알 수 있을 것이다. 예를 들어, 어플리케이션이 서비스를 매우 빈번히 요청하면서 어떤 태스크를 수행하는 데에 너무 많은 시간을 소비하고 있다는 것을 오동작의 표시로서 감지할 수 있다(예를 들어, 무한 루프). 런타임 환경은 또한 사용자가 어플리케이션의 동작에 만족하는지에 대하여 입력을 수신할 수 있다. 런타임 환경이 이러한 오동작들을 다양한 서비스 제공자들에게 보고하고, 서비스 제공자들이 다수의 서비스 소비자들로부터의 보고를 수집하여, 어플리케이션이 오동작하고 있는지에 대한 정확한 평가를 제공하도록 할 수 있다.

전술한 바로부터, 본 발명의 특정 실시예는 예시의 목적으로 기술된 것으로, 본 발명의 취지와 범위를 벗어나지 않는 한 다양한 변형이 행해질 수 있다는 점이 인지되어야 할 것이다. 당업자는 "서비스"라는 용어가 서비스 제공자에게 요청될 수 있는 다양한 형태의 행위라는 점을 인지할 것이다. 예를 들어, 행위들은 물리적 또는 전자 제품을 사용자에게 파는 것(예, 음악 CD), 자판기에 물품을 투여하는 것, 전화 번호를 찾아내는 것, 지불을 허가하는 것, 집안 전등을 원격 제어하는 것, 비디오를 스트리밍하는 것 등을 포함할 수 있다. 따라서, 본 발명은 첨부된 청구항에 의해서 이외에는 제한되지 않는다.

본 발명에 따르면, 서비스 제공자가 서비스 소비자에 의해 요청된 서비스를 제공했다는 것을 서비스 중개자에게 증명할 수 있도록 서비스 제공자에게 서비스를 요청하는 분쟁 해결 방법 및 시스템이 제공된다.

Claims

서비스 제공자가 서비스 소비자에게 서비스들을 제공할 때 서비스 소비자의 미납 책임에 대한 노출을 제어하고 지불요청과 관련된 비용을 제어하기 위한 방법으로서,

상기 서비스 제공자와 상기 서비스 소비자에 대한 빌링 유닛(billing unit) 내의 서비스 수를 지정하는 단계,

시작코드로부터 최종코드까지의 코드들의 시퀀스를 생성하는 단계 - 상기 시퀀스 내의 코드들의 수는 상기 빌링 유닛 내의 지정된 서비스 수에 대응함 - ,

상기 최종코드를 서비스 중개자를 통해 상기 서비스 제공자에게 제공하는 단계,

상기 서비스 소비자가 상기 서비스 제공자의 서비스를 요청할 때, 상기 최종코드가 유도되게 할 수 있는 상기 시퀀스의 코드들 중 하나를 상기 서비스 제공자에게 제공하는 단계, 및

상기 서비스 제공자가 상기 서비스 소비자에 의해 상기 시작코드를 제공받았을 때, 상기 빌링 유닛에 대한 지불을 요청하는 단계를 포함하는 방법.
제1항에 있어서,

상기 서비스 제공자는 상이한 서비스 소비자들의 빌링 유닛들에 대해, 해당 서비스 소비자에 의한 미납에 노출될 상기 서비스 제공자의 의지(willingness)에 기초하여, 상이한 서비스 수를 지정할 수 있는 방법.
제1항에 있어서,

상기 지정된 서비스 수는 상기 서비스 제공자가 상기 서비스 소비자에 의한 미납으로의 노출을 꺼리지 않는 서비스 수를 나타내는 방법.
제1항에 있어서,

상기 코드들의 시퀀스는 상기 서비스 소비자에 의해 생성되는 방법.
제4항에 있어서,

상기 서비스 소비자는 상기 시작코드를 선택하고 상기 서비스 중개자에게 터미널 코드(terminal code)를 제공하는 방법.
제1항에 있어서,

상기 시퀀스는 단방향 함수를 사용하여 생성되는 방법.
제1항에 있어서,

상기 빌링 유닛의 지정된 서비스 수는, 지불요청과 관련하여 발생하는 비용을 제어하기 위하여 선택되는 방법.
제1항에 있어서,

상기 서비스 제공자가 서비스들을 제공했다는 것에 대하여 서비스 소비자가 분쟁을 제기할 때, 상기 서비스 중개자가 상기 분쟁을 해결하는 방법.
제8항에 있어서,

상기 서비스 중개자는 상기 서비스 제공자에게 상기 시작코드를 제공할 것을 요청하고, 상기 제공받은 시작코드가 상기 코드들의 시퀀스를 생성하기 위해 사용될 수 있는 경우 상기 서비스 제공자가 상기 분쟁에서 승리한 것으로 결정함으로써 상기 분쟁을 해결하는 방법.
제8항에 있어서,

상기 서비스 중개자는 상기 서비스 제공자에게 상기 시작코드를 제공할 것을 요청하고, 상기 제공받은 시작코드가 상기 코드들의 시퀀스를 생성하기 위해 사용될 수 없는 경우 상기 서비스 소비자가 상기 분쟁에서 승리한 것으로 결정함으로써 상기 분쟁을 해결하는 방법.
제1항에 있어서,

상기 빌링 유닛의 지정된 서비스 수는 상기 서비스 소비자가 상기 서비스 중개자에게 등록하는 것과 관련된 비용에 기초하는 방법.
제1항에 있어서,

상기 서비스 중개자가 상기 시퀀스를 생성하는 방법.
제1항에 있어서,

상기 서비스 제공자는 상기 서비스 소비자에 의해 요청된 서비스들을 제공하는 방법.
서비스 소비자의 미납 책임에 대한 노출을 제어하고 지불요청과 관련된 비용을 제어하기 위해 서비스 제공자에 의해 수행되는 방법으로서,

서비스 중개자에게, 상기 서비스 제공자와 상기 서비스 소비자에 대한 빌링 유닛 내의 서비스 수를 제공하는 단계,

상기 서비스 중개자로부터 상기 빌링 유닛에 대한 최종코드를 수신하는 단계,

상기 서비스 수의 서비스들에 대해,

상기 서비스 소비자로부터 서비스를 제공하라는 요청을 수신하는 단계 - 상기 요청은 코드를 포함함 - ,

상기 요청에 포함된 상기 코드로부터 상기 최종코드가 유도될 수 있다는 것이 확인될 수 있는 경우, 상기 요청된 서비스를 제공하는 단계, 및

상기 서비스 수의 서비스들이 제공된 후, 상기 빌링 유닛에 대한 지불을 요청하는 단계

를 포함하며,

상기 서비스 제공자는 상기 서비스 소비자가 상기 서비스 수만큼의 서비스들을 요청했다는 것을 증명하기 위하여 마지막으로 수신된 요청에 포함된 시작코드를 사용할 수 있는 방법.
제14항에 있어서,

상기 서비스 제공자는 상이한 서비스 소비자들의 빌링 유닛들에 대해, 해당 서비스 소비자에 의한 미납에 노출될 상기 서비스 제공자의 의지(willingness)에 기초하여 상이한 수의 서비스들을 제공하는 방법.
제14항에 있어서,

상기 서비스 수는 미납에 노출될 상기 서비스 제공자의 의지를 나타내는 방법.
제14항에 있어서,

상기 최종코드는 단방향 함수를 사용하여 유도되는 방법.
제14항에 있어서,

상기 빌링 유닛의 상기 서비스 수는 지불 요청과 관련하여 발생하는 비용을 제어하기 위해 선택되는 방법.
제14항에 있어서,

서비스 소비자가 자신이 상기 서비스 제공자에게 서비스를 요청했다는 것에 대하여 분쟁을 제기할 때, 상기 서비스 중개자가 상기 분쟁을 해결하는 방법.
제14항에 있어서,

상기 서비스 중개자는 상기 서비스 제공자에게 상기 시작코드를 제공할 것을 요청하고, 상기 제공된 시작코드가 상기 최종코드를 유도하기 위해 사용될 수 있는 경우 상기 서비스 제공자가 상기 분쟁에 승리한 것으로 결정함으로써 상기 분쟁을 해결하는 방법.
제14항에 있어서,

상기 서비스 중개자는 상기 서비스 제공자에게 상기 시작코드를 제공할 것을 요청하고, 상기 제공된 시작코드가 상기 최종코드를 유도하기 위해 사용될 수 없는 경우 상기 서비스 소비자가 상기 분쟁에 승리한 것으로 결정함으로써 상기 분쟁을 해결하는 방법.
서비스 소비자의 미납 책임에 대한 노출을 제어하기 위한 시스템으로서,

상기 서비스 소비자에 의해 서비스 제공자에게 요청될 서비스 수를 알리는 표시를 수신하는 컴포넌트,

단방향 함수를 이용하여 상기 서비스 수만큼의 코드들의 시퀀스를 생성하는 컴포넌트, 및

상기 서비스 제공자에게 상기 시퀀스의 최종코드를 제공하는 컴포넌트

를 포함하며,

상기 서비스 소비자가 상기 서비스 제공자의 서비스를 요청할 때, 상기 서비스 소비자는 상기 시퀀스의 코드들 중 하나를 상기 서비스 제공자에게 제공하여 상기 제공된 코드가 상기 시퀀스의 코드라는 것을 상기 서비스 제공자가 확인할 수 있게 하고, 상기 서비스 제공자가 상기 서비스 소비자에 의해 상기 시퀀스의 시작코드를 제공받았을 때, 상기 서비스 제공자는 상기 서비스 소비자가 상기 지정된 수의 서비스들을 요청했음을 알려주는 시스템.
제22항에 있어서,

상기 서비스 제공자는 지불을 요청할 때 상기 서비스 소비자가 상기 지정된 수의 서비스들을 요청했음을 알려주는 시스템.
제22항에 있어서,

상기 서비스 제공자는 상이한 서비스 소비자들에 대해, 해당 서비스 소비자에 의한 미납 위험에 노출될 상기 서비스 제공자의 의지에 기초하여, 상이한 서비스 수를 지정하는 시스템.
제22항에 있어서,

상기 지정된 서비스 수는 상기 서비스 제공자가 상기 서비스 소비자에 의한 미납 위험에 노출될 것을 꺼리지 않는 서비스들의 수를 나타내는 시스템.
제22항에 있어서,

상기 코드들의 시퀀스는 상기 서비스 소비자에 의해 생성되는 시스템.
제26항에 있어서,

상기 서비스 소비자가 상기 시퀀스에 대한 시작코드를 선택하고 터미널 코드를 상기 서비스 중개자에게 제공하는 시스템.
제22항에 있어서,

상기 지정된 서비스 수는 상기 서비스 소비자가 상기 지정된 수의 서비스들을 요청했음을 나타내는 것과 관련하여 발생하는 비용을 제어하기 위하여 선택되는 시스템.
제22항에 있어서,

서비스 소비자가 자신이 상기 서비스 제공자의 서비스를 요청했다는 것에 대하여 분쟁을 제기할 때, 상기 서비스 중개자가 상기 분쟁을 해결하는 시스템.
제29항에 있어서,

상기 서비스 중개자는 상기 서비스 제공자에게 상기 시작코드를 제공할 것을 요청하고, 상기 제공된 시작코드가 상기 코드들의 시퀀스를 생성하기 위해 사용될 수 있는 경우 상기 서비스 제공자가 상기 분쟁에서 승리한 것으로 결정함으로써 상기 분쟁을 해결하는 시스템.
제29항에 있어서,

상기 서비스 중개자는 상기 서비스 제공자에게 상기 시작코드를 제공할 것을 요청하고, 상기 제공된 시작코드가 상기 코드들의 시퀀스를 생성하기 위해 사용될 수 없는 경우 상기 서비스 소비자가 상기 분쟁에서 승리한 것으로 결정함으로써 상기 분쟁을 해결하는 시스템.
제29항에 있어서,

상기 지정된 서비스 수는 상기 서비스 소비자가 상기 서비스 중개자에 등록하는 것과 관련된 비용에 기초하는 시스템.
제22항에 있어서,

상기 서비스 중개자가 상기 시퀀스를 생성하는 시스템.
제22항에 있어서,

상기 서비스 제공자는 상기 서비스 소비자에 의해 요청된 서비스를 제공하는 시스템.