KR20040091675A

KR20040091675A - 일시 네트워크에 있어서 동적 어드레싱 방법

Info

Publication number: KR20040091675A
Application number: KR10-2004-7013433A
Authority: KR
Inventors: 웨슬리아자무; 버벡스테판
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2002-03-27
Filing date: 2003-02-14
Publication date: 2004-10-28
Also published as: CN100539602C; ATE524914T1; CN1643880A; KR100656222B1; JP2005522103A; TW200307440A; AU2003258902A1; EP1491026A1; WO2003084186A1; JP3899076B2; TWI243569B; EP1491026B1

Abstract

한 측면에 있어서, 커뮤니티들이 애드 혹 참가자들을 갖는 일시 피어 투 피어 네트워킹 환경에서 식별자들 및 관계들을 지속하는 방법, 시스템, 및 컴퓨터 프로그램 제품이 개시된다. 노드들을 위한 지속 식별자들이 정의되어, 노드들이 상이한 네트워크 어드레스를 갖는 네트워크에 재진입하는 경우라도, 노드들이 세션들 및 호출들을 거쳐 식별될 수 있도록 한다. 네트워크를 트래버스하는 경우 컨텐츠 자원에 의해 (예를 들면, 어떠한 노드들이 컨텐츠를 전달했는지) 취해진 경로들은 노드들에 관한 (예를 들면, 노드들이 피어들로부터의 질의들에 응답하는데 얼마나 성공적인가를 표시하는) 레퓨테이션 정보와 함께 지속된다. 지속되는 정보를 이용하여 신뢰 관계들이 유도될 수 있다. 교환되는 메시지들의 수를 감소시키기 위해 층을 이룬 브로드캐스트 계획이 정의된다.

Description

일시 네트워크에 있어서 동적 어드레싱 방법{DYNAMIC ADDRESSING IN TRANSIENT NETWORKS}

피어 투 피어(peer-to-peer) 또는 "P2P" 네트워크에 있어서, 각 통신 노드는 네트워킹 프로그램을 구비하며, 네트워킹 프로그램은 각 통신 노드가 그 프로그램을 구비한 다른 노드와의 통신을 시작할 수 있도록 한다. 노드들은 네트워크가 분산화되어 있기 때문에 "피어(peer)"로 간주되고, 각 노드는 동일한 (P2P 교환용) 능력을 갖는다. P2P 네트워크는 중앙 프로세싱 유닛("CPU") 싸이클, 메모리, 및 기억 장치와 같은 자원들이 낭비되지 않는 보다 효율적인 네트워크라는 점에서 유망하다. 이러한 네트워크들은, 노드들이 자의적으로 네트워크들에 접속하고(join), 떠날(leave) 수 있다는 점에서 애드 혹(ad hoc)이다. 그러므로 P2P 네트워크들은 "일시(transient)" 네트워크로 특징지어질 수 있다.

종래의 기술의 P2P 네트워크 프로그램들은 피어의 동적 질의(query) 및 검색(discovery)을 위한 기능을 제공한다. 그러나 종래의 기술은 몇가지 결점이 있다.지속 네트워크(persistent network) 어드레스의 결여가 한가지 그러한 결점이다. 네트워크 어드레스들이 노드들에 할당되는 동적 어드레싱 구조로 인하여, 특정 노드가 P2P 네트워크에 진입할 때마다, 일반적으로 상이한 인터넷 프로토콜("IP") 어드레스를 가질 것이다. (다이얼-업 계정을 지닌 사용자들은 각 로그인에 대해 상이한 IP 어드레스들을 갖는다. 일정한 디지털 가입자 라인, 또는 "DSL"과 같은 몇몇 "항상 접속되어 있는(always-connected)" 네트워크의 사용자들, 계정들 또한 상이한 로그인에 대해 상이한 IP 어드레스를 가질 수 있다.) 이러한 지속 네트워크 어드레싱의 결여로 인하여, 노드들은 특정 서비스 또는 컨텐츠 자원이 어디에서 이용 가능한지를 "기억하는 것(remember)"이 어렵게 된다. 대신, 노드가 컨텐츠 또는 몇몇 종류의 서비스를 필요로 하는 경우, 통상적으로 새로운 검색 요청을 발행(issue)한 후 잠재적으로 대량의 응답 가운데서 선택하는 방법을 결정해야 한다. 이러한 통신은 매우 버스티한(bursty) 트래픽을 유발한다.

종래의 P2P 네트워크들의 또 다른 결점은 그들이 신뢰 모델(trust model)을 갖지 않는다는 것이다: 노드들이 지속 네트워크 어드레스들을 갖지 않기 때문에, 어떤 노드들이 신뢰할만하고 어떤 노드들이 신뢰할만하지 않은지를 지속적으로 추적하는 종래의 수단이 없다. 그러므로 노드가 어떠한 피어 노드로부터 서비스 또는 컨텐츠를 획득할지를 선택하는 경우, 동적 질의에 응답했던 노드들의 집합 가운데서 선택하는 방법을 결정하는데 쓰이는 이용 가능한 "추적 기록" 또는 이력이 없다. 이러한 신뢰 모델의 부재는 또한 종래의 P2P 네트워크들이 일시 커뮤니티들의 멤버들간의 안전한 트랜잭션을 위한 지원을 제공하지 않음을 의미한다. (SunMicrosystems, Inc로부터의 JXTA 프로젝트는 "피어 그룹(peer group)" 또는 "공유 공간(shared space)"의 개념을 제공하는 P2P 구조이며, 여기에서 피어 그룹 내의 노드들은 서비스들을 발행할 수 있다. 이러한 서비스들 중에는 멤버쉽, 액세스, 및 리졸버(resolver) 서비스들을 포함하는 핵심 서비스들의 집합이 있다. 정의된 해결 방법은 피어 그룹에 인증(authentication), 허가(authorization), 및 명명(naming)의 클라이언트/서버 모델을 적용한다. 즉, 집중화의 개념은 단지 피어 그룹 레벨에서만 유지된다. 이러한 피어 그룹들은 일시 커뮤니티인 것으로 적당히 특징지워지지 않는다. 마찬가지로 Groove Networks, Inc.로부터의 Groove? 제품은 피어 커뮤니티 내에 "공유된 서비스들"의 집합을 제공하며, 이러한 집합은 보안, 멤버, 및 접근 제어 서비스들을 포함한다. 보안 메커니즘은 인증용 공개 키 인프라스트럭쳐("PKI"), 및 비밀용 공유 비밀 키를 갖는 키 교환(key exchange)이다. 그러므로 디지털 서명, 디지털 증명, 및 공유된 보안 서비스에 대해 수반된 요구 조건은 일시 커뮤니티의 개념을 부정한다.)

널리 쓰이는 P2P 네트워크 중 하나로 "GnutellaNet"가 알려져 있다. GnutellaNet는 사용자가, 우선 "다운로드" 웹사이트로 가지 않고 그들 컴퓨터의 기억 장치 자원들간에 직접적으로 파일들을 교환하도록 하는 프로토콜을 이용한다. "Napster"는 또 다른 잘 알려진 P2P 네트워크 구현이며, 여기에서 사용자들은 MP3 음악 파일을 식별하기 위해 집중화된 웹사이트에 접속하여, 서로간의 컴퓨터로부터 MP3 파일을 다운로드할 수 있다. GnutellaNet는 임의의 종류의 파일 컨텐츠를 다운로드할 수 있도록 한다. 많은 다른 P2P 네트워크 구현들이 존재한다.

P2P 네트워크는 클라이언트/서버 네트워크보다 잠재적으로 보다 효율적이다. 이러한 잠재적으로 증가된 효율은 P2P 네트워크가 집중화된 서버를 갖지 않는다는 사실에 기인한다. 클라이언트/서버 모델에 있어서, 프로세싱 능력의 대부분은 집중화된 서버 상에 상주하고, 따라서 프로세싱 부하는 이러한 서버에 집중되는 경향이 있다. P2P 네트워크에서는, 네트워크 내의 모든 노드들에 걸쳐서 태스크를 분배할 잠재력이 있으며, 이로 인하여 네트워크 자원들을 더 효율적으로 이용할 수 있다. P2P 시스템의 동적 특성, 및 효율적인 부하 분배에 대한 잠재력이 증진되어, P2P 시스템은 정보 기술("IT") 아키텍쳐에 있어서 다음 단계로 진전되었다. 그러나, 상술한 제한들로 인하여, 종래의 P2P 네트워크는 소비자 및 "무상용" 시장으로 격하되었고, (e비지니스 또는 B2B 트랜잭션과 같은) 고용량의 업무를 수행하는 데에는 적합하지 않다. (그리고 상술한 바와 같이, 종래의 P2P 구현들은 일시 커뮤니티들 내에서의 안전한 트랜잭션들에 적합하지 않으며, 이는 통상적으로 e비지니스에 대해서도 비슷하다.)

또한, 종래의 P2P 시스템들은 관리되지 않고 유사한 구조나 특성을 지녀서(homogenous), 많은 상이한 형태의 장치들이 관리 가능한 방법으로 공동 사용될 수 있어야 하는 대규모의 로버스트(robust) IT 아키텍쳐 내에서 P2P를 구현하는 것이 비실용적이 된다.

P2P 네트워크의 이점 및 잠재력을 이용하는 한편, 종래의 해결 방법들의 결점 및 제한들을 회피할 수 있도록 하는 기술을 제공하는 것이 바람직하다.

본 발명은 컴퓨터 네트워크에 관한 것으로, 보다 구체적으로, 일시 네트워킹(transient networking) 환경에서 쓰이는 방법, 시스템, 및 컴퓨터 프로그램 제품에 관해 다룬다.

도 1은 본 발명의 구현에 의해 레버리지(leverage)될 수 있는 종래 기술의 웹 서비스 스택을 도시한 도면.

도 2는 네트워킹 환경과의 상호 접속 및 컴포넌트들 배치의 추상도를 포함하는, 본 발명의 컴포넌트들을 도시하는 다이어그램.

도 3a는 바람직한 실시예가 특정 컨텐츠 자원의 탐색 경로를 어떻게 식별하는지를 도시하기 위한 SOAP(Simple Object Access Protocol) 헤더 샘플.

도 3b는 바람직한 실시예가 특정 노드의 레퓨테이션(reputation)을 어떻게 식별하는지를 도시하기 위한 SOAP 헤더 샘플.

도 4a 및 도 4b는 바람직한 다른 실시예가 노드의 레퓨테이션을 어떻게 노드 메타-데이터(meta-data)로 지정하는지를 도시하기 위한 XML(Extensible Markup Language) 문서 샘플.

도 5는 바람직한 실시예가 컨텐츠 메타-데이터를 이용한 컨텐츠 자원을 어떻게 설명하는지를 도시하는 XML 문서 샘플.

도 6은 지속 노드 식별자들 및 현재 네트워크 종단점들간의 맵핑 뿐만 아니라 지속 컨텐츠 식별자들 및 그 컨텐츠를 위한 현재 기억장치 위치간의 맵핑을 기록하기 위하여 바람직한 실시예에 따라 생성되는 자원 셋을 바람직한 실시예가 어떻게 지정하는지를 도시하는 XML 문서 샘플.

도 7은 P2P 네트워크에 진입한 이 후 특정 컨텐츠 자원에 의해 취해진 경로를 식별하여 바람직한 실시예가 컨텐츠 탐색 경로 정의를 지정하는 방법을 도시하는 XML 문서 샘플.

도 8은 바람직한 실시예에 따라 초기 상태의 P2P 네트워크 내의 노드들에 의해 실행되는 초기 적재(bootstrap) 흐름도.

도 9는 바람직한 실시예가 도 8의 초기 적재 흐름 동안 발행되는 "alive" 통지 메시지의 레퓨테이션 정보를 어떻게 전달하는지를 도시하는 XML 문서 샘플.

도 10은 P2P 네트워크 내에서 "alive" 메시지를 전달하기 위하여 바람직한 실시예에 의해 이용될 수 있는 "spy" 메시지를 도시하는 XML 문서 샘플.

도 11은 바람직한 실시예에 따라, 노드가 컨텐츠 제공자 또는 서비스 제공자를 위치시키고, 컨텐츠/서비스를 요청하고, 컨텐츠/서비스를 수신하는 요청자 흐름을 도시한 도면.

도 12는 바람직한 실시예가 도 11의 요청자 흐름 동안 질의를 브로드캐스트하는 방법을 도시하는 SOAP 엔벌로프 샘플.

도 13은 노드가 질의에 응답할 수 있는 방법을 보여주는 SOAP 엔벌로프 샘플.

도 14는 바람직한 실시예가 도 11의 요청자 흐름 동안 선택된 노드로부터 컨텐츠/서비스의 전달을 요청하는 방법을 도시하기 위해, SOAP 엔벌로프를 구현하는 HTTP(HyperText Transfer Protocol) 요청 메시지 샘플.

도 15는 요청된 컨텐츠 또는 요청된 서비스의 결과가 요청자에게 전달될 수 있는 방법을 도시하는 HTTP 응답 메시지 샘플.

도 16은 바람직한 실시예에 따라, 노드가 요청자로부터의 질의에 응답하고, 요청자에 의해 선택되는 경우 요청된 서비스의 결과 또는 요청된 컨텐츠로 응답하는 제공자 흐름도.

도 17a 내지 도 17c는 본 명세서에 개시된 임의적인 시스템 관리 능력(system management capability)으로 이용될 수 있는 헤더들의 샘플을 도시한 도면.

도 18은 임의적인 시스템 관리 능력을 제공하는 시스템 노드들에 의해 구현될 수 있는 관리 흐름도.

본 발명은 피어 투 피어 컴퓨팅 네트워크를 개선하는 방법, 시스템, 및 컴퓨터 프로그램 제품들을 제공한다. 바람직한 실시예의 한 측면에 있어서, 개선점에는 네트워크를 구성하는 노드들의 집합이 시간에 따라 변할 수 있는 일시 네트워크 커뮤니티들을 구비하는 네트워크 내의 노드들을 지속적으로 식별하는 것이 포함된다. 바람직하게, 이러한 기술은 다음을 포함한다: 네트워크로 처음 진입할 때, 각 노드에 초기 네트워크 어드레스를 할당하고; 네트워크로 노드가 처음 진입할 때, 노드들 각각에 대해 지속 노드 식별자(persistent node identifier)를 생성하고; 초기 네트워크 어드레스 및 지속 노드 식별자간의 맵핑을 저장하고; 추후 진입시 노드에 상이한 네트워크 어드레스가 할당될 수도 있지만, 네트워크로 추후 진입시 각 노드의 아이덴티티를 분석(resolve)하기 위해서 지속 노드 식별자를 이용한다.

특정 노드에 대해 저장된 맵핑은 특정 노드가 상이한 네트워크 어드레스로 재진입할 때마다 변경되어, 특정 노드에 대한 맵핑으로부터의 네트워크 어드레스가 상이한 네트워크 어드레스로 대체되도록 한다.

특정 노드에 대한 지속 노드 식별자는 바람직하게는, 특정 노드의 초기 네트워크 어드레스, 네트워크로의 최초 진입이 발생한 날짜, 네트워크로의 최초 진입이발생한 시간, 및 최초 진입이 발생한 도메인의 식별자에 기초하여 발생된다.

특정 노드 식별자들을 이용하여, 네트워크 내의 각 노드의 행동(예를 들면, 특정 노드가 나머지 다른 노드들로부터의 요청에 얼마나 잘 응답하는지)을 추적할 뿐만 아니라, 네트워크 내의 컨텐츠 자원들에 의해 취해진 네트워크 탐색 경로를 추적할 수 있다.

본 발명의 다른 측면들은 첨부된 청구항에서 정의될 것이다.

본 발명의 실시예를 첨부 도면을 참조하여 예시의 방법으로 설명할 것이며, 도면 전체를 통해 같은 참조 번호는 동일한 요소를 표시한다.

후술할 실시예들은 P2P 네트워크 동작을 개선하기 위한 기술들을 보여준다. 지속 식별자는 각 네트워크 참가자, 즉 노드에 할당되어, 노드가 네트워크를 떠나고 재진입한 후 식별될 수 있도록 한다. 네트워크를 탐색하는 컨텐츠에 의해 취해진 경로는 추적되고 또한 지속된다. 본 명세서에 개시된 바와 같이 컨텐츠 경로 및 전후 노드의 정보를 지속함으로써 호출들에 걸쳐서 피어 관계를 유지할 수 있다. 그러므로 개시된 기술들은 종래 기술의 단점을 다루어, 참가자들이 통신하는 커뮤니티가 당연히 일시 커뮤니티인 경우에도, 피어 장치들간의 관계가 단일 세션 너머에서 지속할 수 있도록 한다.

개시된 기술들은 P2P 네트워크의 고유한 동적 네트워크 어드레싱 특징들을지원하는 한편, 이종 네트워크 노드들도 지원한다. 지속된 정보는 레버리지되어, 네트워크 관리, 트랜잭션, 및 보안 정책의 애플리케이션을 포함하는 비지니스 엔터프라이즈 동작들을 지원할 수 있다.

또한, 개시된 기술들은 자가 복구(self-healing) 네트워크를 용이하게 제공할 수 있게 한다. 자가 복구 네트워크는 별개의 컴퓨팅 시스템에 의한 관리 또는 인적 상호작용과는 독립적으로 네트워크가 실행시에 태스크 관리/모니터링을 적용하는 것이다. 본 명세서에서 개시된 기술들은 노드들이 그들의 피어들과의 관계를 양성하고(cultivate) 이러한 정보를 지속하는 것을 가능하게 하여, 성능 및 기능 무결성과 관련하여 악의 또는 장애 있게 수행하는 노드들이 식별될 수 있도록 한다(그 후 이러한 노드들은 일단 검출되면 네트워크에 불리한 영향을 주지 못하도록 차단될 수 있다). (자율 컴퓨팅(autonomic computing)이라는 용어를 이용하여 자가 복구 네트워크의 개념을 논하는 http://www.research.ibm.com/autonomic/을 참조한다. 여기에서 설명된 기술들은 집중화된 기관이 없는 일시 네트워크 커뮤니티에서의 자가 복구는 교시하지 않는다)

본 명세서에서 개시된 기술들은 또한 P2P 네트워크 동작에서의 효율성을 용이하게 개선한다. 종래 기술의 P2P 네트워크에서 처럼, 질의가 전체 서브넷에 브로드캐스트되도록 요구하기 보다, 본 발명은 네트워크 내의 노드들의 지속된 인식을 이용하는 단을 이룬(tiered) 브로드캐스트 기술을 개시하여, 발생된 네트워크 트래픽의 양을 감소시킨다.

전형적인 P2P 네트워크 내에 다양한 피어 노드들이 공존할 것이다. 피어 네트워크 자체는 소비자/공급자 관계로 서로 상호 작용하는(예를 들면, 서브-서비스들간의 방향 그래프로서 정의될 수 있는 서비스를 포함하는 일련의 관련된 비지니스 활동들을 수행하는) 수직 피어들의 집합을 대표할 수도 있다. 또는, 네트워크는 공통 기능을 제공하는 수평 피어들의 집합을 대표할 수도 있다. 본 발명의 기술들을 이용하여 이러한 노드들에 자동 및 관리 능력을 제공하는 P2P 아키텍쳐를 증가시킬 수 있다.

예로서, 피어 노드들의 그룹은 기억 장치 영역 네트워크(Storage Area Network; SAN) 내에 기억 장치 자원을 제공할 수 있다. 기억 장치 서비스 제공자(Storage Service Provider; SSP)는 고객을 위해 가입 또는 페이 퍼 유스(pay-per-use)를 토대로 SAN을 유지하고, 통상적으로 이러한 고객들에게 SSP의 서비스 약정을 특정하는 적절한 서비스 레벨 합의서(Service Level Agreement; SLA)를 갖는다. 고객 결제는 SLA 약정이 충족되지 않는 경우 불리한 영향을 받을 수도 있다. P2P 네트워크에 있어서, 기억 장치를 필요로 하는 노드들은 이러한 능력을 제공하는 다른 노드들을 찾기 위해 동적 네트워크 질의를 발행할 수 있다. 피어의 이러한 유형의 동적 질의 및 발견은 종래 기술의 P2P 네트워크에서 이용 가능하다. 그러나, 이전에 언급한 바와 같이, 종래의 P2P 네트워크는 신뢰 모델 및 어떻게 "좋은" 기억 장치 제공 노드를 선택할 것인지를 아는 방법을 갖고 있지 않는다. 본 발명의 기술들을 이용하여, SSP는 실시간으로 결정되는 레퓨테이션들을 갖는 P2P 기억 장치 유틸리티들과 같은 자율 기억 장치 파티션들을 관리할 수 있으며, 기억 장치 요청들이 현재 얼마나 잘 처리되고 있는지를 반영할 수 있다. 이러한 동적으로 계산된 정보를 이용하여, 기억 장치 요청들에 가장 잘 응답할 수 있는 기억 장치들이 결정되어, 요청자들에게 기억 장치를 용이하게 동적 할당할 수 있다. 또한, 특정 컨텐츠 요청들에 응답할 수 있는 특정 기억 장치 자원들은 본 발명의 기술들을 이용하여 더 쉽게 식별될 수 있다. 그러므로 SLA 내의 응답 및 성능 약정들은 더 일관되게 실현될 수 있다. (기억 장치 노드가 얼마나 잘 기억장치 요청을 처리하는가는 요청에 응답하는 성공 비율, 노드가 얼마나 효율적으로 요청에 응답하고 있는가, 노드의 이용 가능한 기억 장치 용량, 그 노드로부터 어떤 컨텐츠가 이용 가능한가 등을 포함할 수 있다)

이하에서 더 상세히 설명되겠지만, 하나 이상의 노드들이 P2P 네트워크를 떠나고 그 후에 재진입할 수 있다 하더라도(P2P 네트워크에서, 이러한 재진입하는 노드들은 전형적으로 변하는 네트워크 어드레스들을 갖는다), 컨텐츠 경로 및 전후 노드의 정보를 지속함으로써 피어 노드들은 서로의 관계, 및 세션을 통한 서로의 인식을 유지할 수 있다. 또한, 본 명세서에서 개시된 기술들에 따라, 특정 노드에 관한 전후 정보가 획득되는 경우, 노드는 본 명세서에서 "레퓨테이션(reputation)"으로 언급되는 것을 계발(develope)한다. 그 후 이러한 레퓨테이션은 신뢰 모델을 위한 기초로 이용될 수 있다.레퓨테이션들은 이하에서 더 상세히 설명될 것이다. (바람직하게 노드의 레퓨테이션을 위해 지속되는 정보의 설명을 위해서는 도 4a 및 도 4b의 논의(discussion)를 참조한다)

본 발명의 바람직한 실시예는, 개시된 기술들이 다른 환경에서 쓰이기 위해 적응될 수도 있지만, 도 1을 참조하여 설명되는 것처럼 P2P 네트워킹에 대한 웹 서비스 해결 방법 및 웹 서비스 모델을 이용하여 전개된다. 본 발명의 유리한 기술들은 본 명세서에서 주로 파일 공유(즉, 어떤 컨텐츠가 어떤 노드로부터 이용 가능하게 되는지를 식별하고; 특정 컨텐츠가 네트워크를 가로질러 갈 때 취해지는 경로를 기억하고; 피어로부터 컨텐츠를 요청하고, 그 컨텐츠를 수신하는 등)에 적용됨으로써 논의된다. 그러나, 이는 예시용이지 제한 사항이 아니다. 개시된 기술들은 단순한 파일 공유 상호 작용 외에, 더 복합적인 상호 작용들로 이용될 수 있다. 예를 들면, 기술 분야에서 알려진 바와 같이 웹 서비스 모델은 복합적인 상호 작용의 수행을 용이하게 한다. 일반적으로 "웹 서비스"는 네트워크 접근 가능한 동작들의 집합을 설명하는 인터페이스이다. 웹 서비스는 특정 태스크 또는 태스크들의 집합을 수행하고, 공동으로 이용 가능한 방법으로 하나 이상의 다른 웹 서비스들과 작업하여 웹 서비스로 정의되는 비지니스 트랜잭션 또는 복합 작업 흐름의 부분을 수행한다. 일예로서, 복합적인 구매 주문 트랜잭션을 완성하는 것은 주문하는 비지니스에서의 주문 배치 서비스(즉, 주문 배치 소프트웨어) 및 하나 이상의 비지니스 협력자들에서의 주문 이행 서비스간의 자동화된 상호 작용을 요구할 수도 있다. 이러한 프로세스가 웹 서비스로서 설명되는 경우, 본 발명의 기술들을 이용하는 노드는 이러한 서비스를 수행할 수 있는 피어 노드들을 위치시키고, 특정 노드를 (예를 들면, 노드의 레퓨테이션에 기초하여) 선택한다. 요청하는 경우 위치된 피어 노드는 (전형적으로 많은 서브 서비스들을 포함하는) 서비스를 수행하고 그 후 요청 노드에 그 서비스의 결과를 반환한다.

웹 서비스 기술은 월드 와이드 웹과 같이 클라이언트/서버 네트워크에서의분배된 애플리케이션 통합을 위하여 기술 분야에서 알려진 메커니즘이고, 이러한 네트워크에서의 프로그램간 동작을 위한 소프트웨어에 대한 분배된 네트워크 액세스를 가능하게 한다. 웹 서비스는 HTTP, SOAP 및/또는 XML 프로토콜, WSDL(Web Services Description Language), 및 UDDI(Universal Description, Discovery, and Intgration)와 같은 많은 개방된 웹 기반 표준들을 레버리지한다. HTTP는 보통 인터넷과 같은 TCP/IP(Transmission Control Protocol/Internet Protocol) 네트워크 상에서 메시지를 교환하기 위해 이용된다. SOAP는 분배되는 환경에서 방법들을 호출하기 위해서 이용되는 XML 기반 프로토콜이다. XML 프로토콜은 애플리케이션간 메시징을 가능하게 하도록 설계된 애플리케이션층 전송 프로토콜을 위한 월드 와이드 웹 컨소시움("W3C")의 진화하는 스펙이다. XML 프로토콜은 SOAP로 수렴할 수도 있다. WSDL은 분배된 네트워크 서비스들을 분배하는 XML 포맷이다. UDDI는 XML 기반 레지스트리 기술이며, 이 기술로 비지니스들은 그들의 서비스들을 열거할 수 있고 서비스 요청자들은 특정 서비스들을 제공하는 비지니스들을 찾을 수 있다.

클라이언트/서버 네트워크의 분배되는 애플리케이션 통합은, 분배되는 서비스들을 UDDI 레지스트리를 통해 위치시키기 위해 UDDI 요청들을 발행하고, SOAP/XML 프로토콜 및 HTTP 메시지들을 이용하는 플랫폼 중립 WSDL 포맷으로 전달되는 서비스 정보를 이용하여 요청자를 위치된 서비스에 동적으로 바인딩함으로써 달성된다. (여기에서 SOAP에 대한 참조는 XML 프로토콜의 의미론적으로 유사한 측면을 동등하게 언급하는 것으로 구성되어야 한다) 이러한 컴포넌트들이 상이한 운영 시스템 상에서 구동하고 요청자의 언어와 상이한 프로그램 언어로 쓰여질 수도있지만, 이러한 컴포넌트들을 이용하여, 웹 서비스는 하나 이상의 원격 위치 내에 상주할 수 있는 프로그램 컴포넌트에 대한 투과(transparent) 접근을 요청자들에게 제공한다. (SOAP에 대한 더 많은 정보를 위해서는, http://www.w3.org/TR/2000/NOTE-SOAP-20000508, 제목 "Simple Object Access Protocol(SOAP) 1.1, W3C Note 08 May 2000"을 참조한다. XML 프로토콜에 대한 더 많은 정보를 위해서는, http://www.w3.org/2000/xp를 참조한다. WSDL에 대한 더 많은 정보는 http://www.w3.org/TR/2001/NOTE-wsdl-20010315, 제목 "Web Services Description Language(WSDL) 1.1, W3C Note 15 March 2001"에서 찾을 수 있다. UDDI에 대한 더 많은 정보는 http://www.uddi.org/specification.html을 참조한다. HTTP는 "Hypertext Transfer Protocol -- HTTP/1.1"(1999년 6월) 제목의 인터넷 엔지니어링 태스크 포스로부터의 RFC(Request For Comments) 2616에 설명된다)

이제 도 1을 참조하면, 본 명세서에 개시된 기술들의 바람직한 실시예는 IBM 웹 서비스 상호 운용성 스택(interoperability stack; 100)을 레버리지하여, P2P 네트워크 내의 노드들간 통신을 위한 하위(underlying) 지원을 제공한다. 그러나 이는 예시를 위한 것이지 이에 한정하는 것은 아니다. 본 명세서에 개시된 발명의 개념을 일탈하지 않는다면 다른 지원 메커니즘들이 레버리지될 수도 있다. 웹 서비스 상호 운용성 스택(100)의 컴포넌트들이 이제 설명될 것이다.

바람직하게, 종래 기술을 이용하여 다수의 서브 서비스들로 구성된 웹 서비스를 수행하는 것에 관련되는 오퍼레이션들을 모델링하기 위하여 방향성 그래프(directed graph)가 이용된다. 예를 들어, 공동 양도된 미국 특허 ______________(일련번호 09/956,276, 2001년 9월 19일 제출) "Dynamic, Real-Time Integration of Software Resources through Servies of a Content Framework"을 참조한다. 여기에 개시된 기술들에서 그래프의 노드들은 서비스를 수행하는 경우 실행되는 오퍼레이션들을 표현하고(여기에서, 이러한 오퍼레이션들은 또한 서브 서비스로 언급될 수도 있다), 그래프 노드들을 연결하는 그래프 가장자리들은 하나의 서비스 오퍼레이션으로부터 다른 서비스 오퍼레이션으로의 잠재적인 천이(transition)를 표현한다. 이러한 그래프 가장자리들, 또는 "서비스 링크들"은 하나 이상의 천이 조건들이 부여될 수 있고, 또한 적용 가능하다면 데이터 맵핑 정보가 부여될 수도 있다. 조건들은 어떤 조건 하에서 다음 연결된 서비스가 호출되어야 하는지를 특정한다. 종종, 이러한 조건들은 이전의 서비스 호출의 결과를 이용하여 결정될 것이다. 데이터 맵핑은 방향성 그래프의 오퍼레이션들을 연결하고 하나의 오퍼레이션에서 다른 오퍼레이션으로 데이터를 전달하는 능력을 참조한다. 예를 들면, 데이터 맵핑 정보는 하나의 서브 서비스의 출력 파라미터들이 다른 서브 서비스의 입력 파라미터들로 맵핑되는 것을 표시할 수도 있다.

바람직하게는, 이러한 방향성 그래프를 지원하기 위해, WSFL(Web services Flow Language)를 이용한다. 이는 도 1에서 서비스 흐름 지원(110)으로 표시된다. 방향성 그래프가 WSFL 엔진으로 처리되어 복합 웹 서비스를 수행하는 방식은 본 발명을 이해하는데 관계되는 것이 아니고, 여기에서는 상세히 설명하지 않을 것이다. WSFL의 상세한 논의는 WSFL 스펙("Web Services Flow Language(WSFL 1.0)", Prof. Dr. F. Leymann, 2001년 5월)에서 알 수 있다. 이 문서는 IBM에서 얻을 수 있으며,또한 http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf에서 인터넷 상으로 이용 가능하다.

바람직하게는 웹 서비스들(예를 들면, P2P 네트워크 내의 노드들의 다양한 것들로부터 이용 가능한 웹 서비스들)의 자동화된 발견(discovery; 120) 및 발행(publication; 130)이 UDDI 메시지들을 이용하여 제공되어, UDDI 레지스트리에 액세스할 수 있다. WSDL층(140)은 서비스 설명 문서를 지원한다. SOAP를 이용하여 XML 기반 메시징(150)을 제공할 수 있다. HTTP, FTP(File Transfer Protocol), 이메일, MQ(message queuing) 등과 같은 프로토콜들이 네트워크 지원(160)을 위해 이용될 수 있다. 실행시에, 서비스들은 UDDI 서비스 발견(discovery) 프로세스를 이용하는 레지스트리 내에서 발견되고, 서비스들의 WSDL 정의들로부터의 정보를 이용하는 것에 속박된다. 이 후 WSFL 런타임은 이러한 정의들을 이용하여 서비스들을 모은다.

본 발명의 바람직한 실시예들에 따라, UDDI 레지스트리로부터 검색된 정보를 이용하여 파일 공유 오퍼레이션들이 용이하게 되고, 또한 더 복합적인 웹 서비스들이 이와 동일한 방식으로 지원될 수 있다(레지스트리의 이용에 대한 더 많은 정보를 위해서는 이하 도 2의 논의를 참조한다).

본 실시예들은 P2P 네트워크의 노드들이 엄격하게 피어라기 보다는 클래스로 모델링될 수 있는 기술들을 개시한다. 예를 들면, 본 실시예들은 "시스템" 노드들을 설명한다. 본 명세서에서 이용되는 바와 같이 "시스템 노드"라는 용어는 종래의 클라이언트/서버 네트워크에서 시스템 관리자에 의해 관리되는 형태의 기능들을 제공하는 P2P 네트워크 내의 노드들을 언급한다. 이러한 기능들은 네트워크 관리, 부하 밸런싱, 모니터링, 보안 등과 같은 네트워크 오퍼레이션들을 포함한다. 본 발명을 구현하는 노드들을 갖는 P2P 네트워크는 근거리 통신망 및 기업들에 이를 수 있고, 월드 와이드 웹의 한도까지만 속박된다(예를 들면, 노드가, 상이한 서브넷 상에 위치할 수도 있는 노드들에 관해 알 수 있도록 하는 "spy" 메시지의 논의를 참조한다. 다른 한편으로 종래 기술의 P2P 네트워크에 있어서, 브로드캐스트 트래픽은 IP 어드레스들을 모니터링하는 필터들의 구성으로 인하여 전형적으로 서브넷 내의 노드들에 한정된다). 그러므로, 다양한 노드들의 클래스들이 네트워크에 참가할 수 있고, 새로운 형태의 노드들이 네트워크에 참가할 수 있다; 본 명세서에서 개시된 기술들을 이용하여, 이러한 것은 혼란스럽지 않은 방식으로 발생한다. 노드들의 클래스들, 및 특히 시스템 노드들의 이러한 개념은 본 발명의 임의적 측면이고, 하이브리드 형태의 P2P 네트워크들을 생성하기 위하여 이용될 수 있으며, P2P 네트워크에서 몇몇 노드들은 다른 노드들을 지시하고 이러한 노드들에 의해 저장된 정보에 영향을 줄 수 있다. 시스템 노드들에 이용 가능한 특별한 기능들은 본 명세서에서 더 상세히 설명될 것이다.

바람직한 실시예에 따라, 본 발명의 하나 이상의 측면을 구현하는 노드들은 AXIS(Apache eXtensible Interaction System) 체이닝(chaining) 프레임을 레버리지하는 핸들러를 지닌 AXIS 엔진의 환경 내에서 구동하는 웹 서비스 모델을 이용한다. (Apache AXIS에 대한 더 많은 정보를 위해서는 http://xml.apache.org/axis/index.html을 참조하며, Apache AXIS는 Apache 소프트웨어 기반에 의한 SOAP 프로토콜의 구현이다)

"AXIS"는 SOAP 서비스들을 위한 런타임 환경이며, 여기에서 웹 서비스들은 컨테이너 모델(container model)을 이용하여 구동한다. "라우터"로 불리는 서블릿(servlet)은 착신 SOAP 요청 메시지를 수신하고, 그 요청을 수행하기 위해서 어떤 코드가 요청되는지를 결정하고, 그 코드들 위해 요구되는 객체들을 역직렬화(deserialize)하고, 그 코드를 호출한다. 호출된 코드가 실행을 완료한 경우, 라우터는 그 결과를 발신 SOAP 응답 메시지로 직렬화(serialize)한다.

"AXIS 체이닝"은 착신 및 발신 메시지들에 대한 실행의 주문을 지시하는 구성 가능한 "체인" 또는 시퀀스를 언급한다. "핸들러"는 특정 기능을 구현하는 실행 가능한 코드이고, (체이닝 메커니즘을 통해) 다른 핸들러들의 기능과 링크될 수 있다. 핸들러들은 SOAP 요청들의 사전 또는 사후 처리를 수행한다. 배치 기술자(deployment descriptior)를 이용하여 특정 서비스가 어떻게 배치될 것인지를 지정하며, 여기에는 그 서비스에 의해 이용되는 객체들을 어떻게 직렬화/역직렬화하고 어떤 AXIS 핸들러 체인을 이용할 것인지를 포함한다. 예를 들면, SOAP 메시지 교환들은 암호화된 데이터를 이용할 수 있다. 암호화된 데이터를 포함하는 메시지를 수신하는 경우, 해독(decryption) 핸들러는 (사전 처리 단계로서) 그 데이터를 해독하고 이를 적절한 메시지 처리 코드에 전달할 것이다. 결과가 반환되는 경우, 암호화 핸들러는 그 결과를 또 다른 SOAP 메시지로 전송하기 이전에 (사후 처리 단계로서) 그 결과를 암호화한다.

AXIS 엔진은 세가지 형태의 핸들러 체인을 지원한다. 하나는 전송 체인이며,이는 (HTTP와 같은) 메시지 전송 메커니즘을 특정한다. 다른 하나는 서비스 특정 체인이다. 예를 들면, 특정 서비스 "XYZ"에 대하여, 서비스 특정 체인은 메시지가 서비스 XYZ를 위해 수신되거나 서비스 XYZ에 의해 발생되는 경우 어떤 핸들러들을 호출할 것인지를 규정한다. 제3의 핸들러 체인은 글로벌 체인이며, 이는 모든 메시지들에 대해 호출될 핸들러들을 특정한다.

도 2는 컴포넌트들이 네트워킹 환경 내에 어떻게 위치하고 상호 연결되어 있는지를 추상적으로 나타내는, 바람직한 실시예들에서 이용되는 컴포넌트들을 도시한다. 이제 이러한 컴포넌트들을 설명할 것이다.

바람직한 실시예들에 있어서, 런타임 엔진(220)은 AXIS 실행 엔진(225)과; 글로벌 핸들러 체인 내의 세개의 AXIS 핸들러(230, 235, 240)와; 링크 기반 저장소(245)와; 메타 데이터 저장소(250)와; 디지털 인증 저장소(255)를 포함한다. 이러한 런타임 엔진(220)은 바람직하게는 (웹 서비스(200)에 의해 도시되는) 웹 서비스 내에 구현된다. 웹 서비스는 임의적으로 t모델 인스턴스(205)를 실행할 것을 선택한다. 기술 분야에서 알려진 바와 같이, t모델은 웹 서비스에 의해 실행되는 행동들 또는 스펙들을 표시한다. t모델들은 UDDI 레지스트리에 저장되어 특정 서비스의 실행을 위한 레지스트리를 용이하게 스캐닝하도록 한다. t모델은 본 발명의 바람직한 실시예들의 환경 내에서 이용되어 웹 서비스가 지원하는 질의의 형태를 특정할 수 있다. 컨텐츠 저장소(210)에 의해 예시되는 하나 이상의 컨텐츠 저장소들은 런타임 엔진(220)에 의해 표현되는 노드에 의해 액세스될 수 있는 원거리에 위치한 컨텐츠에 노드의 근거리 컨텐츠 및/또는 참조들을 저장한다.

3개의 AXIS 핸들러들은 더 상세하게 설명될 바람직한 실시예들에서 이용되고, 본 명세서에서는 "경로 인티메이터(Path Intimater)"(230), "가십 몽거(Gossip Monger)"(235), 및 디지털 서명("DSIG") 핸들러(240)로 언급된다. 이제 이러한 핸들러들을 설명할 것이다.

전술한 바와 같이, 본 발명의 하나 이상의 측면들은 전후 노드 정보를 지속하는 기술들 및 P2P 네트워크의 노드들 사이에서 공유되는 컨텐츠에 의해 트래버스(traverse)된 경로들을 정의한다. 경로 인티메이터(230)는 방향성 그래프를 이용하여 본 명세서에서 정의되는 지속된 컨텐츠 경로들을 관리한다. 이러한 방향성 그래프들에 있어서, 그래프 노드들은 컨텐츠가 순회했던 피어 노드들에 대응하고, 그래프 아크(arc)들은 그 컨텐츠가 각 아크에 의해 연결되는 피어 노드들 사이를 지나가는 것을 표현한다. (이러한 방향성 그래프들은 복합적인 웹 서비스 인터랙션들을 정의하기 위해 이용되고 WSFL을 이용하여 지원되는 전술한 방향성 그래프와 혼동되어서는 않된다.)

바람직한 실시예들에 따르면, XML Linking("XLink") 언어는 지속된 컨텐츠 경로들을 정의하는 방향성 그래프들을 표현하는 수단으로 이용된다. XLinking 언어는 "XML Linking Language (XLink) Version 1.0, W3C Recommendation 27 June 2001" 내에서 정의되며, 이는 인터넷 상의 http://www.w3.org/TR/xlink/에서 발견될 수 있다. 기술 분야에서 알려진 바와 같이, XLink 구문을 이용하여 (원거리에 위치하는 자원들을 가리키는 발신 링크들 및 지역 노드에 링크된 자원들을 식별하는 착신 링크들을 포함하는) 단순한 마크업 스타일 링크들, 또는 더 복합적인 "확장된" 링크들을 정의한다. (그러나, 본 명세서에서 개시된 바와 같은 XLink 링크들을 이용하는 것은 기술 분야에서 알려져 있지 않다.) 확장된 링크들을 이용하여 노드들의 그래프들 및 노드들간의 아크들을 표현하다. 확장된 링크 중 하나의 형태는 "제3자" 링크이다. 제3자 XLink들은 원거리 자원들을 관련시키며, 이는 링크 스펙은 그 링크 스펙이 함께 링크하는 컨텐츠로부터 개별적으로 저장됨을 의미한다. 이하 설명될 도 7은 본 발명의 바람직한 실시예들이 컨텐츠 탐색 경로 정의(또는 더 일반적으로, 메시지 탐색 경로 정의들)들을 지속하는 XLink들을 어떻게 레버리지할 수 있는지를 도시한다.

본 명세서에서는 지속된 경로 정의들을 이용하여 컨텐츠 자원들에 의해 취해진 경로들을 기억하는 것으로 바람직한 실시예들을 설명하고 있지만, 이는 단지 예일 뿐, 이에 한정되지 않는다. 또한, 경로 정의들은 서비스를 실행하는 결과와 같은 다른 정보를 위해 지속될 수 있다. 그러므로, 본 명세서에서 이용되는 "컨텐츠"라는 용어는 노드들간에 전송되는 임의의 형태의 정보를 표현하는 것으로 해석될 수 있으며, "컨텐츠"는 서비스를 요청하기 위해 노드를 요청함으로써 생성될 수 있는 컨텐츠 또는 이미 생성된 컨텐츠를 언급하는 약칭으로 이용된다. 또한, 지속된 경로들은 메시지에 의해 전송되는 정보의 형태에 관계없이 메시지의 경로를 표현하는 것으로 해석될 수 있다.

제3자 XLink들의 집합이 XML 문서로 함께 저장되는 경우, 그 집합은 "링크 기반(linkbase)" 또는 "링크 기반 문서"로 언급된다. 그러므로 본 명세서에서 이용되는 용어인 링크 기반은 제3자 XLink들로 표현되는 탐색 경로 정의들의 집합을 언급한다. 본 명세서에서 개시되는 포맷을 이용하여 링크 기반 식별자들을 정의하여, P2P 네트워크 내의 노드들을 유일하게 식별한다. (링크 기반 식별자들에 관한 더 많은 정보에 대해서는 이하의 도 4의 논의를 참조한다.)

그러므로 경로 인티메이터(230)는 지속된 메시지 경로들을 링크 기반들로서 관리한다. 이러한 링크 기반들은 링크셋들을 포함하며, 링크셋은 특정 컨텐츠 자원에 의해 트래버스된 경로를 정의한다. 이러한 링크 기반들은 본 명세서에서 더 상세히 논의된다.

경로 인티메이트(230)는 도 3a에 도시된 형태의 SOAP 헤더를 발신 메시지 SOAP 메시지들에 첨부하여 컨텐츠 캄색 정보를 전송하는 역할을 담당한다. 이러한 헤더(300)는 <traversalPathRef> 태그(305)(이는 도 3a의 예에 있어서, "path"에 대한 명칭 영역 식별자(name space identifier) "p"로 앞에 삽입되어 있음)를 포함하고 이러한 <traversalPathRef> 태그는 피어 네트워크 내에 지정된 컨텐츠의 탐색 경로를 저장하는 링크셋에 참조(310)를 제공한다. 도 3a의 예에 있어서, "href" 속성(310)의 값은 탐색 경로 정보가 URL(Uniform Resource Locator) "http://9.56.34.12/linkbase/lb.xml"을 이용하는 액세스 가능한 링크 기반 문서 내에 저장되는 것을 표시한다.

수신기의 경로 인티메이터(230)는 <traversalPathRef> 요소를 갖는 착신 SOAP 헤더를 수신하는 경우 수신기의 링크 기반을 그에 따라 적절히 갱신하는 역할을 담당한다. 이러한 프로세싱은 참조(310)에 의해 식별되는 탐색 경로의 종단에서 아크 내의 수신 노드의 LBuuid를 부가하는 것을 포함한다. (그러므로, 이어서 수신노드가 탐색 경로와 관련된 컨텐츠를 전달한다면, 도 3a를 참조하여 설명된 SOAP 헤더 내의 식별된 수정된 탐색 경로는 전달 노드를 적절하게 식별할 것이다.) 탐색 경로들이 노드들간의 경로를 어떻게 식별하는지에 관한 더 많은 정보를 위해 이하의 도 7을 참조한다.

가십 몽거(235)는 노드들에 관계하는 메타 데이터로서 레퓨테이션들을 관리한다. 또한, 가십 몽거는 노드 레퓨테이션들을 수정하는 경우 컨텐츠 메타 데이터를 처리하고 그 컨텐츠 메타 데이터를 평가할 것이다. 본 발명의 바람직한 실시예들은 RDF(Resource Description Framework; 자원 기술 개념) 표시를 레버리지하여, 컨텐츠 및 노드들을 설명하는 메타 데이터를 특정한다. (RDF는 웹 기반 메타 데이터를 특정하기 위해 설계된 표시이다. RDF에 대한 더 많은 정보를 위해서는 http://www.w3.org/TR/REC-rdf-syntax/에서 W3C에 의해 인터넷 상에서 제공되는 "Resource Description Framework, (RDF) Model and Syntax Specification, W3C Recommendation 22 February 1999"을 참조한다.) P2P 네트워크들이 매우 잘 분배되어 있고, 설명된 바와 같이 노드들의 IP 어드레스들이 시간이 지남에 따라 변할 수 있기 때문에, 본 명세서에서 개시된 가십 몽거는 신뢰가 시간이 지남에 따라 진화하는 진화적인 신뢰 모델을 제공한다. 처음에, 노드는 그 자체를 신뢰하고, 시간이 지남에 따라 그 노드는 노드의 피어들과의 인터랙션을 통해 수신하는 컨텐츠에 관한 메타 데이터 및 그 컨텐츠에 의해 취해진 경로를 수집한다. 이러한 수집된 메타 데이터는 이력 또는 감사 추적(audit trail)의 형태를 제공하는 것으로 간주될 수 있다. 긍정적인 결과들을 지닌 특정 피어로부터 더 많은 컨텐츠가 수신될수록, 그피어와의 신뢰 관계는 더욱더 강하게 된다. 임의적으로 노드는 또한 노드의 피어들로부터 얻는 관계 정보로부터 신뢰를 이끌어낼 수 있으며, 이러한 관계 정보는 그 피어들이 다른 피어 노드들과 맺고 있는 인터랙션을 설명한다(노드 자체는 다른 피어 노드들과 인터랙트되지 않을 수도 있다).

이제 도 4a 및 4b를 참조하면, 레퓨테이션 데이터를 특정하는 바람직한 다른 기술들이 도시된다. 바람직한 실시예들에 있어서, 노드의 레퓨테이션은 노드로부터 이용 가능한, 노드 및/또는 컨텐츠에 의해 제공되는 서비스들의 표시, 및 그 노드에 의해 제공되는 서비스의 품질을 포함한다. 노드의 레퓨케이션은 바람직하게 노드로부터 전송되는 메시지들 내의 메타 데이터로서 구현된다(그리고 수신기들에 의해 저장된다). 바람직한 실시예들에 있어서, 서비스의 품질은 ("stature" 값으로 언급되는) 수치값으로 특정되며, 이 수치값은 이러한 특정 노드가 네트워크 내의 다른 노드들로부터 수신하는 질의들에 답하는데 얼마나 성공적인가를 표현하다. 노드의 레퓨테이션의 서비스 컴포넌트의 품질은, 일정한 경우, 악의적인 노드를 표시한다(예를 들면, 로그(rogue) 에이전트들 또는 자원들의 소스인 경향을 나타낸 노드). 동적으로 어드레스된 노드를 레퓨테이션과 관련시키는 능력은 분산된 P2P 계에서 신뢰를 용이하게 하고, 일단 레퓨테이션 정보가 이용 가능하다면, 보안 정책들을 사용하는 신뢰 모델이 P2P 인터랙션들에 적용될 수도 있다. 그러므로, P2P 네트워크 내의 e비지니스에 대한 주요 억제자는 제거된다. (동적으로 습득되는 레퓨테이션들을 참조하여 바람직한 실시예들이 본 명세서에서 설명되고 있지만, 특정 구형에서는, 예를 들면 시스템 관리자가 시스템 관리를 용이하게 할 수 있도록 하기 위해, 하나 이상의 노드들의 레퓨테이션을 초기화 또는 사전 구성하는 것이 바람직할 수 있고, 이러한 구현은 본 발명의 범위 내에 있는 것으로 간주된다. 이러한 해결 방법을 이용하여 선택된 노드들에게 상대적으로 높은 stature를 주고, 이러한 노드들을 시스템 노드들로 효과적으로 지정할 수 있다.)

바람직한 실시예들에 따르면, P2P 네트워크 내의 일시 노드들은 링크 기반 식별자("ID"), 또는 "LBuuid"을 이용하여 식별되며, 이러한 LBuuid는 [IP_Address-Date-Time-Domain] 형태를 갖고, UUID(Universal Unique Identifier)의 개념 상에서 모델링된다. UUID는 퍼블릭 인터넷 상에서 객체 또는 엔티티를 유일하게 식별하는 기술로서 기술 분야에서 알려져 있다. (그러나, LBuuid 포맷은 알려져 있지 않다. 종래의 기술인 UUID는 전형적으로 UUID를 생성했던 호스트의 IP 어드레스에 대한 참조, 타임 스탬프, 및 유일성을 확실하게 하는 임의적으로 생성된 컴포넌트를 포함한다.

본 명세서에 개시된 LBuuid의 예로서, 도 4a의 문서(400) 내의 샘플 레퓨테이션에 의해 표현되는 노드는 LBuuid 9.37.43.2-05/04/01-12:02:05:37-Netzero.net을 가지며, 이는 <Description> 태그(405)의 "about" 속성(410)의 값으로 도시된다. 이러한 예에 있어서, IP 어드레스 컴포넌트는 "9.37.43.2"이고, 날짜 컴포넌트는 "05/04/01"이고, 시간 컴포넌트는 "12:02:05:37"이고, 도메인 컴포넌트는 "Netzero.net"이다. 본 명세서에서 정의된 바와 같이, 이러한 정보는 P2P 네트워크로 제1 진입할 때, 노드의 초기 IP 어드레스는 "9.37.43.2"이었고, 그 네트워크로의 이러한 최초 진입은 네트워크 도메인 "Netzero.net"에서 날짜 "05/04/01", 시간"12:02:05:37"에 발생했음을 표시한다. 본 명세서에서 개시된 바와 같이 이러한 LBuuid는 차후 이러한 특정 노드를 식별하고, 노드의 레퓨테이션이 지속될 수 있도록 하며, 또한 컨텐츠 경로 탐색 정의들 내의 이러한 노드에 대한 참조들이 분석(resolve)될 수 있도록 하기 위해 이용될 것이다.

주어진 시점에서 도 4a의 LBuuid에 의해 표현되는 노드의 현재 IP 어드레스는 LBuuid에 표시된 IP 어드레스라고 보장되지 않고, P2P 네트워크로 추후 진입시 동적 어드레스 할당 메커니즘으로부터 얻은 알맞은 일정한 다른 값 이상이다. 지속적으로 노드를 표현하는 LBuuid는 자원 셋에 저장된 맵핑을 통해 노드의 현재 IP 어드레스와 관련된다. (자원 셋들은 도 6을 참조하여 이하에서 설명된다.)

<Description> 태그(405)는 이러한 노드를 위해 레퓨테이션 정보를 괄호로 묶는다. 예에 있어서, <QuerySet>(415)로 명명된 차일드(child) 태그는 특정되고, "stature" 속성을 갖는다. 바람직한 실시예에 있어서, stature 속성은 이러한 노드가 질의들을 수행하는데 얼마나 성공적인가(또는 성공적이지 않은지)를 표시하는 수치값을 갖는다. stature 속성값은 -1 및 +1 사이의 비정수값으로 특정되는 것이 바람직하며, 여기에서 음의 stature 값은 악의적인 노드를 표시한다. 바람직하게는, 대응하는 "totalQueries" 속성이 또한 특정되고, 그 값은 그 노드에 의해 처리된 질의들의 총 수를 표시하는 정수이다. 그러므로 도 4a의 예에 있어서, 노드는 2,145개의 질의들을 수신하였고 이러한 질의들 중 34 퍼센트를 성공적으로 수행하였다. (임의의 "ID" 속성이 예에서 도시되며, 이는 종래의 UUID 포맷을 이용하여, 이러한 질의 셋(415)을 유일하게 식별하기 위해 이용될 수 있는 값을 제공한다.)

다른 실시예에 있어서, stature(즉, 성곡 비율) 정보는 전체 질의 셋 보다는 개별적인 질의들과 관련될 수 있다. 이러한 다른 예가 도 4b에 도시되며, 여기에서 "stature" 및 "totalQueries" 속성들은 <QuerySet> 태그 상이라기 보다는 <Query> 태그들 상에서 특정되었다. 본 발명의 개념들을 일탈함 없이, stature 정보를 위한 다른 표현들이 이용될 수 있음은 명백하다. 예를 들면, "2145의 34퍼센트" 또는 "34, 2145" 형태의 값을 갖는 단일 속성이 이용될 수 있다. -1 및 +1 사이 범위의 stature값을 이용하는 것 이외의 다른 대안으로서, 별개의 속성들을 이용하여 성공하지 못한(악의적인) 결과들 및 성공적인 결과들을 표시할 수 있다. 즉, 비율 보다는 계수가 이용될 수도 있다.

도 4a의 논의로 돌아가서, 바람직한 실시예들에 이용되는 문구로, <QuerySet> 태그(415)는 하나 이상의 <Query> 차일드 요소들을 가지며, 이러한 <Query> 요소들의 집합은 이러한 노드에 의해 충족될 수 있는 질의들(바람직하게는 통상적인 표현들로 표현된다)의 셋을 계산한다. 이러한 예에 있어서, 노드는 3개의 상이한 질의들(420, 425, 430)을 충족시킬 수 있다.

제1 <Query> 태그(420)의 통상적인 표현 문구는 노드가 "purchase_order 999-9999-999"(즉, 문자열 "purchase_order" 다음에 3개의 수치값, 하이픈, 4개의 수치값, 다른 하이픈, 및 3개의 수치값) 형태의 질의들을 처리할 수 있음을 표시한다. (본 명세서에서 이용되는 예에 있어서, 이러한 수치 영역들은 고객 번호를 특정하도록 의도된다.)

질의 셋의 예에 있어서 제2 <Query> 태그(425)는 노드가 문자열 "partnerprofile list"로 표현되는 질의들을 처리할 수 있음을 표시한다. 제3의 <Query> 태그(430)는 "-NDA.tiff"로 종료하는 문자열인 질의들을 표현한다.

임의적으로, 상이한 또는 부가적인 정보가 이용되어 노드의 레퓨테이션을 결정할 수 있으며, 도 4a 및 4b에 의해 표현되는 정보는 예시용이고 이에 한정하지 않는다. 예를 들면, 노드의 효율을 추적하는 것이 유용할 수도 있고, 이러한 목적으로 레퓨테이션 데이터를 이용할 수도 있다. 예를 들면, 효율이 질의들을 처리하는 응답 시간으로 측정된다면, 응답 시간 속성이 노드의 레퓨테이션에 (도 4b의 해결 방법 또는 더 일반적으로는 도 4a의 해결 방법 중 어느 하나를 이용하는 질의 특정값으로서) 부가될 수 있다. 전술한 바와 같이, 노드의 레퓨테이션은 가십 몽거 핸들러에 의해 처리된다. 그러므로, 본 명세서에 설명된 레퓨테이션 핸들링은 부가적인 또는 상이한 형태의 레퓨테이션 데이터를 지원하는데 필요한 핸들러에 의해 확장될 수 있다.

노드의 효율을 추적하는 것은 종래 기술의 P2P 네트워크에서 이용 가능한 것보다 컨텐츠/서비스 제공자들 사이에서 더 신중한 선택을 용이하게 한다. 앞에서 논의된 SSP 환경에서 이용되는 경우, 이러한 노드 효율 정보를 이용하는 SSP는 어떻게 저장소 자원 및 준비 저장소 자원들을 선택할 것인지에 관해 런타임 결정을 할 수 있고, 따라서, SSP의 고객들에게 서비스를 향상시키고 SLA의 약정을 충족시킬 가능성이 증가한다.

레퓨테이션은 노드의 능력에 관해 원격 노드들에 힌트들을 제공하고, 본 명세서에서 설명된 바와 같이, 노드의 능력에 관하여 그 정보를 제공하여 질의들에응답한다. 파일 공유 목적으로 이용되는 경우, 노드에 질의를 발행하는 것은 노드에게 "이 설명의 파일을 가지고 있습니까?"라고 묻는 것을 나타낸다. 응답하는 노드는 그 레퓨테이션을 제공하여 요청자에게 그 노드가 그 질의에 답할 수 있음(즉, 노드가 요청된 파일을 제공할 수 있음)을 알리고, 또한 과거에 노드가 파일들을 (도 4a의 해결 방법을 이용하여) 제공하거나 이러한 특정 파일을 (도 4b의 해결 방법을 이용하여) 제공하는데 성공적이었는지를 표시한다.

이제 도 5를 참조하면, 컨텐츠 메타 데이터(즉, 특정 컨텐츠에 관한 정보)를 특정하는 바람직한 기술을 나타내는 예가 도시된다. 이러한 형태의 메타 데이터 정보를 이용하여, 노드는 계획에 따라서 어떤 컨텐츠 질의들에 응답할 수 있는지를 결정한다. 바람직한 실시예들에 있어서, RDF가 레퓨테이션 메타 데이터를 위해 이용되었던 방법과 유사한 방식으로 컨텐츠 메타 데이터를 특정하기 위해 RDF를 이용한다(도 4a 및 도 4b를 참조한다). 도 5의 예에서 도시된 바와 같이, <Description> 태그(505)의 "about" 속성(510)은 문서(500)에 의해 설명되는 컨텐츠의 식별자를 특정한다. 바람직한 실시예들에 따라, "about" 속성의 값은 파일 명칭 또는 특정 질의에 대응하는 컨텐츠가 저장된 다른 저장소 위치를 특정하는 식별자이다. 그러므로, 예에 있어서, 이러한 컨텐츠는 "purchase_order 123-4567-890.xml" 위치에 저장된다. 이러한 식별자는 컨텐츠 메타 데이터를 실제 컨텐츠와 관련시키기 위해 이용될 수 있는 지속적인 컨텐츠 키로서의 역할을 한다.

문구의 예에 있어서, <Description> 태그(505)는 차일드 태그 <Creator>(515) 및 <synopsis>(520)을 갖는다. <Creator> 태그는 바람직하게는date 속성 및 time 속성을 가지며, 이 속성들의 값은 설명된 컨텐츠의 생성 날짜 및 시간을 특정한다. (다른 대안으로 날짜 및 시간은 단일 "Date_Time" 속성으로 결합될 수도 있다.) <Creator> 태그(515)의 값은 그 컨텐츠를 생성했던 (이러한 예에 있어서의) 개인을 식별한다. 다른 대안으로 프로세스 식별자는 컨텐츠가 비롯된 P2P 노드의 LBuuid와 같이 <Creator> 태그의 값으로서 이용될 수도 있다. <synopsis> 태그(520)는 바람직하게는 자유 문자값을 가지고, 대응하는 컨텐츠를 사람이 판독 가능하게 설명하기 위해 이용될 수도 있다. 그러므로, 예에 있어서, <synopsis>(520)는, "purchase_order 123-4567-890.xml"에 저장된 컨텐츠는 AMEX 고객 #123-4567-890을 위한 구매 주문임을 표시한다.

<Description> 요소에서의 정보, 또는 그 선택된 부분들은 사람인 사용자에게 건네져서, 예를 들면 다수의 후보들 사이에서 컨텐츠/서비스 제공자를 선택하는 데 있어 그 사람에게 도움을 줄 수 있다. 더 자동화된 환경에 있어서, <Description> 요소로부터의 정보는 계획에 따른 선택 프로세스에 의해 분석될 수 있다. 예에서 도시되는 컨텐츠 메타 데이터는 단지 저장될 수 있는 정보의 유형, 및 정보가 표현될 수 있는 형태를 예시하고 있을 뿐임은 명백하다.

가십 몽거는 도 3b에 도시되는 형태의 SOAP 헤더를 발신 SOAP 메시지들에 부가하여 수신 노드에게 레퓨테이션 정보를 알려주는 역할을 담당한다. 이러한 부가된 레퓨테이션 헤더(350)는 전송 노드의 레퓨테이션 정보가 저장되는 레퓨테이션 저장소에 ("href" 속성(360)을 이용하는) 참조를 제공하는 <reputationRef> 태그(355)를 포함한다. (이러한 저장된 레퓨테이션 정보는 전송 노드 자체에 속하고,또한 바람직하게는 전송 노드가 알고 있는 피어 노드들에 관한 레퓨테이션 정보를 포함한다.

수신기의 가십 몽거(235)는 레퓨테이션 메타 데이터를 착신 SOAP 메시지 내의 헤더 영역으로 식별하고, 그 레퓨테이션 메타 데이터를 본 명세서에서 더 설명되는 바와 같이 처리한다.

디지털 서명 핸들러(240)는 메시지 엔티티들을 디지털적으로 서명하여 메시지 무결성(integrity) 및 전송자 인증을 보장한다. 이러한 핸들러는 바람직하게는 W3C로부터의 SOAP 디지털 서명 스펙을 따르고 PKI를 레버리지하여 인증을 관리하고 서명을 적용/확인한다. SOAP 디지털 서명 및 PKI 기술들은 기술 분야에서 알려져 있고, 본 명세서에서는 상세히 설명하지 않을 것이다.

적절한 AXIS 핸들러 또는 가십 몽거 특권이 주어진 시스템 노드는 실제로 원격 피어 링크 기반 및 메타 데이터 저장소에 직접적으로 판독/기록하여, 예를 들면 강제적으로 피어 그룹에 그들 자신을 부가하고, 컨텐츠 탐색 경로 정의들을 삽입하고, 또는 피어의 레퓨테이션을 관리한다(예를 들면, 노드 X의 저장된 레퓨테이션을 수정하여 노드 X의 피어 그룹의 멤버 Z가 악의적인 것으로 식별한다). 바람직하게는 이러한 유형의 시스템 관리 능력은 새로운 AXIS 핸들러를 이용하여 구현되며, 여기에서 시스템 관리 기능은 다른 가십 몽거들의 기능에 우선할 수 있다는 점에서 슈퍼 가십 몽거로 간주될 수 있다. 즉, 노드들의 다수의 클래스들이 지원되는 경우, 종래의 AXIS 핸들러들이 그 클래스들의 식별자들을 인식하고 어떤 오퍼레이션들이 그 대응하는 노드들에 의해 액세스될 수 있는지를 결정하도록 적응될 수 있다. 예를 들면, "클래스 0" 노드들(즉, 초기 피어 노드들)이 질의를 만들고 그들의 레퓨테이션, 탐색 경로 등을 주장하는 동안, (본 명세서에서 설명되는 시스템 노드들과 같은) 다른 "클래스 N"의 노드들은 링크 기반들 및 저장소들을 판독 및 기록하도록 허용될 수 있으며, 노드들에 의해 유지되는 네트워크 뷰(view)들을 효과적으로 관리할 수 있다. (부가적인 AXIS 핸들러를 이용하는 시스템 관리 능력들을 구현하는 것에 관한 더 많은 정보를 위해서는 이하의 도 17a-17c 및 도 18을 참조한다.)

이제 링크 기반에 저장되는 컨텐츠 경로들의 논의로 돌아가면, 본 발명의 바람직한 실시예들에 따른 링크 기반은 휘발성(volatile) 컴포넌트 및 지속적인(persistent) 컴포넌트로 구성된다. 휘발성 컴포넌트는 본 명세서에서 "자원 셋"으로 언급되고, 지속적인 컴포넌트는 탐색 경로 정의들의 집합이다. 자원 셋은 도 6의 XML 문서(600)에 의해 예시된다. 자원 셋은 XLink 로케이터 링트들의 집합으로 정의된다. 이러한 링크들의 한 그룹을 이용하여 동적으로 할당된 네트워크 어드레스들 및 현재의 노드가 알고 있는 모든 노드에 대한 지속된 LBuuid 값들 사이의 맵핑을 정의할 수 있다. 이러한 링크들은 <node>요소들로 특정된다. 다른 그룹을 이용하여, 다운로드된 컨텐츠의 설명들을 그 컨텐츠가 현재 로컬 컨텐츠 저장소에 상주하고 있는 위치들로 맵핑하는 링크들을 정의할 수 있다. 이러한 링크들은 <content> 요소들로서 특정된다.

링크 기반 자원 셋은 바람직하게는 인메모리(in-memory) 테이블로서 저장되어 맵핑의 빠른 조사를 가능하게 한다. 그러므로 노드가 피어 노드와 인터랙트하기를 원한다면, 이러한 테이블을 참고하여 노드의 현재 어드레스를 찾는다. 자원 셋을 저장하는 문서의 루트 요소는 <ResourceSet>이며, 이는 확장된 XLink로서 정의된다((605)에서의 "type" 속성을 참조한다.)

도 6에 도시되는 바와 같이, 첫번째 3개의 요소들(610, 630, 645)은 새로 분석된 네트워크 종단점(즉, URL) 및 지속하는 링크 기반 ID 사이의 맵핑을 정의하는 <node> 요소들이다. <node> 요소들의 "href" 속성들은 새로운 종단점들을 식별하고, "role" 속성들은 지속된 LBuuid들을 식별한다. 네번째 요소(660)는 컨텐츠 자원을 특정하는 <content> 요소이고, 피어 네트워크로부터 다운로드된 로컬 컨텐츠를 식별한다. <content> 요소들의 "href" 속성들은 컨텐츠의 현재 저장 위치를 식별하고 "role" 속성들은 지속된 저장 위치 식별자들을 식별한다.

각 <node> 요소는 "role" 속성의 값과 동일한 ID로 링크 기반을 유지하고 있는 노드의 네트워크 종단점을 표시하는 "href" 속성을 갖는 로케이터 XLink이다(예를 들면, (615)에서의 "type" 속성을 참조한다). 예를 들면, "href" 속성(620)은 "http://9.56.34.12/soap/rpcrouter" 값을 갖는다. 요소(615)의 맵핑에 따라, 이러한 URL은 지속하는 LBuuid "9.37.43.2- 05/04/01-12:02:05:37-NetZero.net"을 갖는 링크 기반을 관리하고 있는 노드를 표현한다. 제1 <node> 요소(610)는 (그 값이 "true"로 설정되는 "local" 속성을 갖는) 로컬 노드에 속하는 반면, 나머지 다른 <node> 요소들(630, 645)은 (그 값이 "false"로 설정되는 "local" 속성을 갖는) 원격 노드들에 속한다.

<content> 요소(660)는 또한 로케이터 XLink이다. 이러한 맵핑의 "href" 속성(665)은 저장 위치 "file://usr/awesley/etc/downloads/purchase_order 123-4567-890.xml"가 현재 "purchase_order 123-4567-890.xml"로 식별되는 로컬 컨텐츠를 저장하기 위해 이용되고 있음을 표시한다("role" 속성(670)을 참조한다).

링크 기반의 지속하는 컴포넌트(즉, 탐색 경로 정의들)는 하나의 노드에서 다른 노드로 특정 컨텐츠 자원의 탐색 경로를 표시하는 아크들의 집합에 의해 자원 셋 내에서 표현되는 반면, 노드들은 노드들의 개별적인 링크 기반 ID(즉, LBuuid) 값에 의해 식별된다.

이제 도 7을 참조하면, 탐색 경로 정의(700)의 샘플이 제공된다. 이러한 샘플은, P2P 네트워크에 진입한 이 후 컨텐츠 자원에 의해 취해진 경로를 추적하는데, 방향성 그래프가 어떻게 이용되는지를 예시한다. 탐색 경로는 <traversalPath> 요소(705)를 이용하여 특정된다. 요소들(710 및 735)에 의해 예에서 표현되는 하나 이상의 <arc> 요소들은 "arc"의 "type" 속성을 갖는 XLink 요소들이다. 이러한 <arc> 속성값들은 하나의 노드에서 다른 노드로 컨텐츠의 이동을 특정한다. 아크 XLink 요소들은 자원 및 로케이터 노드들의 역할들을 레버리지한다. 로케이터 노드들은 도 6에 예시되는 바와 같이 자원 셋에 정의되고, 자원 노드들은 도 7의 <arc> 노드들의 "resource" 속성을 이용하여 식별된다. 이는 <arc> 링크(710)에서 시작하는 경로를 참조하여 이제 설명될 것이며, <arc> 링크(710)는 "purchase_order 123-4567-890.xml"(이는 도 6의 요소(670)에 따라, 현재 "file://usr/awesley/etc/downloads/purchase_order 123-4567-890.xml" 위치에 저장되고, 고객 123-4567-890을 위한 구매 주문을 나타낸다)로서 (725)에서 식별되는컨텐츠가 "12.37.43.5-03/03/01-08:35:13:04-MindSpring.com" 링크 기반을 관리하는 노드에 의해 발생되었음(또는 적어도 그 노드에서 네트워크에 진입하였음)을 특정한다("from" 속성(720)의 값을 참조한다). "to" 속성(725)의 값은 이러한 컨텐츠가 이 후 "12.37.43.5-03/02/01-03:45:23:02-MindSpring.com" 링크 기반을 관리하는 노드에 의해 다운로드되었음을 표시한다.

<arc> 노드(735)로 계속하는 경우, "resource" 속성(750)은 "resource" 속성(730)의 값과 동일하고, "from" 속성(740)은 전의 <arc> 요소(710)의 "to" 속성(725)과 동일한 값을 가지며, 이는 동일한 컨텐츠에 대한 또 다른 탐색임을 표시한다. 그러므로, 마지막 "to" 속성(750)은 그 컨텐츠가 현재의 노드에 의해 다운로드되었음을 표시한다. (750)에서 식별된 링크 기반을 판독하는 애플리케이션이 (750)에서 특정된 컨텐츠에 액세스하기를 원한다면, 자원 셋에서 정의된 <content> XLink를 레버리지함으로써 그렇게 할 것이다. 참조 번호(660)를 보면, 대응하는 <content> 요소가 정의된다. "resource" 속성(750)의 값을 "role" 속성(670)의 값에 매칭시킴으로써 이러한 <content> 요소(660)는 이러한 자원 셋으로부터 선택되고, 이 후 그 컨텐츠의 실제 위치는 그 "href"속성(665)의 값을 이용하여 발견된다. 그러므로 일반적인 경우, 탐색 경로 정의내의 <arc> 요소들에 의해 표현되는 지속된 아크들은 링크 기반들을 자원 셋 내의 <content> 요소의 "role" 속성값 및 그들의 "resource" 속성값을 통해 연결하며, 여기에서 <content> 요소는 지속된 컨텐츠 자원의 위치를 제공한다.

본 발명의 바람직한 실시예들은 본 명세서에서 7 단계를 갖는 것으로 설명되는 부트스트랩(bootstrap) 흐름을 이용하여 로드 시간에 네트워크 상의 모든 노드들(구현될 때, 시스템 노드들을 포함함)을 초기화한다. 이제 이러한 흐름은 도 8을 참조하여 설명될 것이다. 제1 단계(블록 800)에서, 문제의 노드는 자신의 IP 어드레스를 분석한다. 노드가 정적 IP 어드레스를 갖지 않는다고 가정하면, 이러한 목적을 위해 (동적 호스트 구성 프로토콜, 즉 "DHCP", 또는 자동 IP 프로토콜 등) 종래 기술 분야의 동적 어드레스 할당 기술을 이용하는 것이 바람직하다. (노드가 정적 IP 어드레스를 갖는다면, 이 단계는 건너뛴다.)

제2 단계의 전조로서, 노드가 이미 본 명세서에서 개시된 형태의 LBuuid를 갖는지를 알기 위한 테스트가 행하여진다(블록 810). 이러한 테스트의 결과가 부정적이라면, 단계 2에서 노드의 링크 기반을 위한 LBuuid가 생성된다(블록 820). 이러한 부정적인 결과는 링크 기반이 또한 초기화되어야 하는 경우, 피어 노드의 제1 호출 상에서 발생한다. 이 단계에서 생성된 LBuuid는 노드의 링크 기반을 위한 UUID로서의 역할을 하고, 여기에서 LBuuid는 LBuuid = f(current_IP_Address, current_Date, current_Time, a)의 형태이다.

바람직하게는 "a" 파라미터는 전술한 바와 같이 IP 어드레스의 제공자의 표시자(예를 들면, 그 도메인 네임)로서 역할을 한다. 다른 대안으로 "a"는 임의의 번호를 이용하는 종래 기술의 UUID에서 이용되는 파라미터일 수 있다. 그러나 임의의 UUID 생성 알고리즘을 이용하여 가측성(accountability)을 참작할 수 있으며, 상술한 바와 같이 추적하여, 그 생성된 값이 링크 기반을 그 소유자까지 거슬러 올라가서 컨텐츠 자원을 그 기원(및 컨텐츠 자원을 다운로드했던 피어 노드들)까지추적하는 능력을 제공하는 형태가 되도록 하는 것이 바람직하다.

링크 기반을 초기화하는 경우, 아크들의 셋을 생성하여 노드의 로컬 컨텐츠가 어떻게 네트워크를 탐색했는지를 표현한다. (예들이 논의되는 도 7을 참조한다.)

일단 LBuuid가 노드의 링크 기반을 위해 이용 가능하게 되면, 단계 3은 그 노드로부터 "alive" 메시지를 브로드캐스트하기 시작한다(블록 830). alive 메시지는 그 노드가 네트워크 상에 존재함을 알린다. 본 발명의 바람직한 실시예들에 있어서, alive 메시지는 HTTMU를 통해 SOAP를 레버리지한다. HTTMU는 HTTP의 UDP 멀티캐스트 기반 버전이고, alive 메시지가 서브 넷 상의 모든 노드들에 전송되도록 한다. 샘플 alive 메시지는 도 9에서 도시되며, 여기에서 <notification> 요소(905)는 "type" 속성(910)이 "alive"로 설정되도록 한다. 바람직한 실시예들에 따르면, alive 메시지는 또한 노드의 링크 기반을 위한 LBuuid 값((925)에서 <linkBaseID> 요소를 참조) 및 노드 자신의 레퓨테이션 버전에 대한 참조((930)에서 <reputationRef> 요소를 참조)를 특정한다. 레퓨테이션 정보는 도 9에 도시되며, "href" 속성(935)을 통해 식별되는 문서로의 단순한 링크에 의해 제공된다. 이러한 속성의 값은 노드의 레퓨테이션 정보가 지속되는 URL을 제공한다. 그러므로, alive 메시지는 피어 노드들에게 전송 노드의 지속된 식별자 및 그 레퓨테이션의 위치를 어떻게 찾는지를 알려 준다. alive 메시지는 또한 응답 메시지를 위해 콜백(callback) 어드레스("callback" 속성(920)을 참조)를 표시하는 콜백 정보를 포함하는 것이 바람직하며, 여기에서 노드의 현재 IP 어드레스가 제공되고, 다른 속성(915)은 다음 중 하나를 특정한다:

1) 이러한 노드로부터 이용 가능한 파일 공유 서비스를 위한 바인딩 키와 함께, UDDI 레지스트리를 가리키는 질의 URI(Uniform Resource Indicator). 그러므로 UDDI 레지스트리를 갖는 웹 서비스 모델을 이용하는 경우, 이 옵션의 alive 메시지는 이러한 서비스를 위한 발행 및 질의 API(Application Programming Interface)를 유지하는 레지스트리 뿐만 아니라, 이러한 파일 공유 서비스를 위한 바인딩 키를 식별한다.

2) WSIL(Web Services Inspection Language) 참조와 같이, 노드의 파일 공유 서비스를 발견하기 위한 몇몇 비 UDDI 방법. WSIL는 이용 가능한 서비스들을 위한 사이트의 검사을 돕고, 검사와 관련된 정보가 소비(consumption)를 위해 어떻게 이용 가능하게 되어야 하는지를 표시하는 규칙들의 집합을 특정하기 위해 설계된 표기이다. WSIL은 IBM 및 Microsoft에 의해 정의되고, IBM으로부터의 "ADS" 및 Microsoft로부터의 "DISCO"로 언급되는 초기 시도들에서 발견되는 개념들을 강화한다. (WSIL에 대한 더 많은 정보를 위해서는 인터넷 상의 "http://www-106.ibm.com/developerworks/library/ws-wsilspec.html에서 IBM에 의해 발행된 "Web Services Inspection Language(WS-Inspection) 1.0"(Keith Ballinger 등, 2001년 11월)을 참조한다.)

도 9의 예에 있어서, 제2 옵션이 선택되었고, 따라서 속성(915)은 WSIL 정보가 저장되는 URL을 특정하는 "wsil" 속성이다.

단계 4(블록(840)에 의해 표현됨)로 계속하면, 노드는 블록(830)에서 전송되는 alive 메시지를 수신하는 피어들에 의해 전송되는 HTTP 응답을 통한 SOAP에 귀를 기울인다. 바람직한 실시예들에 따라, 이러한 원격 노드들 각각으로부터의 응답 메시지는 또한 alive 메시지이고, 원격 노드의 자기 관리된 레퓨테이션 정보를 어디에서 발견할지를 식별하는 URL과 함께, 원격 피어를 위해 LBuuid를 특정한다. 앞서 설명한 바와 같이 노드의 레퓨테이션은 그 노드가 질의들을 처리하는데 얼마나 성공적인가를 표현하는 stature 값을 포함한다. (도 4a 및 도 4b를 참조하여 논의된 바와 같이, stature 값은 모든 노드의 질의들을 표현할 수 있거나, 질의 특정값들이 제공될 수 있다.)

로컬 (수신) 노드가 원격 노드의 레퓨테이션의 자신의 버전을 가진다면, 로컬 노드가 알고 있는 원격 노드들을 표현하기 위해 로컬 노드가 생성하는 (인메모리 테이블과 같은) 로컬 저장소에 저장하기 위하여 2개의 레퓨테이션들이 병합되는 것이 바람직하다. 바람직한 실시예들에 따라, 로컬 노드가 원격 노드를 보는 관점이 원격 노드가 자신의 레퓨테이션을 보는 관점에서 벗어나는 경우, 병합 오퍼레이션은 로컬 노드의 정보를 통해 원격 노드의 입력을 카피하는 것을 포함한다. (이는 로컬 노드가 소정의 기간 동안 네트워크에 대해 부재인 경우에 적절할 수 있으며, 이 시간 동안 원격 노드의 레퓨테이션은 수정되었다; 즉, 로컬 노드는 다른 이유들로 인하여 원격 노드의 활동들의 몇몇 전달을 놓칠 수도 있으며, 이는 로컬 노드가 원격 노드에 관하여 아는 것이 늦어지는 것을 초래한다.) 그러나, 로컬 노드가 원격 노드를 악의적인 것으로 식별한다면, (일반적인 경우) 로컬 노드는 바람직하게는 원격 노드가 그 레퓨테이션을 착신하는 관점을 무시한다. (예를 들면, 로컬 노드가 다른 노드의 인터랙션에 관하여 알고 있는 것과 알지 못하는 것을 통합하기 위한) 보외법(extrapolation) 또는 원격 노드의 관점과 로컬 노드의 관점을 평균하는 것과 같이 원격 노드를 위해 로컬 레퓨테이션 값을 유도하는 다른 기술들은 본 발명의 범위를 일탈함 없이 이용될 수 있다.

시스템 레벨 가십 몽거가 정의되고, 피어 노드들에 의해 유지되는 저장소들로 레퓨테이션 정보를 주입해도 좋은 경우, 로컬 가십 몽거는 원격 노드의 레퓨테이션에 대한 로컬 가십 몽거의 관점이 이러한 시스템 레벨 가십 몽거에 의해 우선되도록 할 수 있다.

단계 5(블록(850)에 의해 표현됨)에서, 로컬 노드는 본 명세서에서 "spy" 메시지로 언급되는 것을 발행한다. 바람직하게는 이러한 spy 메시지는 로컬 노의 초기 "alive" 요청에 응답한 모든 피어들에 직접적으로 전송되고, 각 피어가 그 피어가 알고 있는 네트워크 상의 각 노드에게 alive 요청을 전달할 것을 본질적으로 요청한다. 이 후 멀티 홈(Multi-homed) 피어들(즉, 하나 이상의 네트워크 접속을 지원하는 피어들)은 현재의 서브 넷 외의 피어들에게 alive 요청을 전달할 수 있다. 이 후 이러한 피어 노드들은 그들 자신의 alive 응답 메시지들로 응답하여, 로컬 노드가 동적으로 P2P 네트워크 형태를 습득할 수 있도록 할 것이다. 반환된 alive 메시지들로부터 수집된 정보를 이용하여, (로컬 노드의 자원 셋 내에서) LBuuid 대 URL 맵핑을 형성하며, 이로써 노드가 그 피어 노드들의 아이덴티티들을 분석할 수 있도록 한다.

spy 메시지들은 임의적인 것으로 간주되고, spy 메시지들을 위한 전달의 깊이는 요청 애플리케이션에 의해 결정되는 것이 바람직함에 주목한다. spy 메시지는 순차 전달의 최대수를 결정하는 임의의 깊이 속성을 가질 수 있다. spy 메시지는 메시지를 위한 UUID를 제공하여 무한 루프를 트리거하는 spy 메시지들의 되풀이되는 프로세싱을 피하도록 하는 것이 바람직하다.

도 10은 spy 메시지(1005)의 샘플이 SOAP 메시지(1000) 내에서 어떻게 구체화될 수 있지를 나타낸다. 이 예에서, "UUID" 속성(1010)은 되풀이되는 전달을 방지하기 위해 특정된다. (예에서 "[LBuuid]" 문구는 로컬 노드의 실제적인 LBuuid로 대체된다.)

도 8의 논의로 돌아가서, 단계 6(블록(860)에 의해 표현됨)에서, 로컬 노드는 자신의 alive 메시지에 응답하여(그리고, 구현되는 경우 로컬 노드의 spy 메시지에 응답하여) 수신하는 alive 메시지들을 이용함으로써, 네트워크 종단점들을 원격 노드들의 링크 기반 ID들을 맵핑하는 로컬 노드의 인메모리 테이블 엔트리들을 갱신한다. 이러한 엔트리들의 집합은 도 6의 예에서 예시하고 있는 바와 같이 로컬 링크 기반의 자원 셋 내에 <node> 요소들을 포함한다. 갱신 프로세스는 필요한 경우 URL을 갱신하는 것을 포함하여, 인메모리 테이블이 각 LBuuid와 관련된 노드의 현재 위치를 식별하도록 한다. (자원 셋은 바람직하게는 문서 객체 모델, 즉 "DOM" 트리를 이용하여 저장되는 XML 문서이므로, 새로운 엔트리들을 부가하는 것은 새로운 DOM 트리 노드들을 생성하는 것에 응답하는 것임에 주목한다. XML 문구 요소들로부터 DOM 트리 노드들을 형성하는 기술들은 기술 분야에서 잘 알려져 있다.)

노드는 또한, spy 메시지에 응답하여 alive 메시지들을 반환하는 원격 노드들에 속하는 국부적으로 저장된 레퓨테이션 정보를 갱신할 수 있다. 블록(840)의 논의를 참조하며, 여기에서 이러한 레퓨테이션 갱신은 노드 자신의 alive 메시지에 응답하는 노드들을 참조하여 설명된다.

마지막으로, 단계 7(블록(870))에서, 로컬 노드는 바람직하게는 여분의 HTTPPMU 채널을 통해 다른 피어 노드들로부터의 alive 메시지들에 귀 기울이고, 응답으로 alive 메시지를 전송한다(이는 블록(840)을 참조하여 설명되는 alive 응답 메시지들과 유사하다). 이러한 귀 기울이는 프로세스는 진행중인 것이 바람직하며, 노드가 P2P 네트워크 상에서 그 피어들의 인식을 유지하고, (LBuuid 및 URL간의 상호 관계를 저장하는) 그 자원 셋 및 그에 따라서 국부적으로 저장된 피어 레퓨테이션 정보를 수정할 수 있도록 한다.

도 11은 노드가 그 피어들로부터 컨텐츠를 요청할 때, 노드에 의해 이용될 수 있는 흐름을 나타내는 흐름도를 제공한다. 이러한 프로세스는 블록(1100)에서 시작하고, 여기에서 사용자는 관심있는 질의를 정의한다. 질의는 바람직하게는 질의 열(query string)로 표현되며, 이는 사용자에 의해 시작, 메뉴로부터 사용자에 의해 선택, 사용자에 의해 식별된 파일로부터 판독 등이 될 수 있다.

계획에 따른 프로세스가 다른 대안으로 질의를 결정하고 질의 열을 공급할 수 도 있지만, 전형적으로 사용자는 사람인 사용자이다. 예를 들면, 고객 번호 123-4567-890에 대한 구매 주문을 요청하기 위해, 선행 예에서 나타난 바와 같이, 질의 열은 "purchase_order 123_4567_890"으로 포맷될 것이다.

블록(1110)에서 최적화 프로세스는 바람직하게 수행되며, 이로써 노드는 그피어 노드들의 레퓨테이션들을 평가하여 본 명세서에서 "broadcast tiers"로 언급되는 것을 분석한다. 이러한 브로드캐스트 층들은 레졸루션을 질의하기 위해 계층적인 해결 방법을 특정하고, 각 층은 그 질의를 충족시키는 그들의 인식된 능력에 기초하여 선택된다. 이러한 계층적인 해결 방법은 네트워크를 탐색하는 응답 메시지 및 질의 요청 메시지들의 수를 감소시키려고 시도한다. 바람직하게는, 패턴 매칭 해결 방법을 이용하여 각 노드의 레퓨테이션 내의 <QuerySet>을 이용하여 어떤 노드들이 특정 질의에 응답할 수 있는지를 결정한다. 도 4a 및 도 4b를 참조한다. 예를 들면, 특정 노드가 (420)에서의 문구를 이용하여 표현되는 "purchase_order 999-9999-999" 질의 패턴에 응답할 수 없다면, 이러한 특정 노드에 그 형태의 질의를 전송하는 것은 비효율적이다. 대신 노드들이 이러한 질의를 지원한다고 그 레퓨테이션들이 표시하고, 상대적으로 더 높은 stature 값들을 갖는 노드들은 제1 브로드캐스트 층으로 선택될 것이다.

이러한 패턴 매칭 오퍼레이션의 임의적 향상으로서, 사이트 서머리(site summary)가 레버리지될 수 있다. "사이트 서머리"는 RDF를 이용하여 제공되고 "RSS"로서 기술 분야에서 알려진 컨텐츠 신디케이션 기술을 언급한다. 사이트 서머리는 컨텐츠 설명들의 집합을 포함하여, 특정 사이트로부터 이용 가능한 컨텐츠/서비스들을 설명할 수 있다(즉, 노드의 질의 셋). 예를 들면 사이트를 위한 새로운 컨텐츠를 부가하기 위해 설명들의 집합이 변화되는 경우, RSS를 이용하는 컨텐츠의 신디케이터들에 사전 행동으로 설명이 푸쉬될 수 있다. 노드들은 처음에 상술한 바와 같이 alive 메시지를 통해 서로의 레퓨테이션들을 안다. 노드들이 다른 노드들과의 인터랙션들에 참여하는 경우, (노드들의 stature, 및 아마도 노드들의 질의 셋을 포함하는) 노드들의 레퓨테이션들은 전형적으로 변화한다. 몇몇 노드들은 다른 노드들과 종종 인터랙트하지 않게 될 수도 있으며, 이는 서로의 레퓨테이션에 대한 이러한 노드들의 관점이 구식으로 되도록 한다. 그러므로 사이트 서머리들은 네트워크 내의 노드들 사이에서 레퓨테이션 정보를 주기적으로 전달하기 위해 유익하게 이용될 수 있다.

블록(1120)에서, 식별된 "우선권 제공자(priority provider)"에게 요청이 전송된다. 바람직하게는 질의들은 (HTTP를 통한) 방향성 "broadcast" 해결 방법을 이용하여 전송되며, 그 결과 셋을 이용하여 타겟 노드들 각각의 현재 IP 어드레스를 결정한다. (브로드캐스트 층들이 이용되지 않는다면, 질의 메시지의 타겟들은 다른 방식으로 결정될 수도 있으며, 여기에는 자원 셋에 표현되는 모든 피어들에 메시지를 전송하는 것을 포함한다.) SOAP 메시지로 구현되는 질의의 샘플(1200)이 도 12에 예시된다. 이 예에서 나타난 바와 같이, <query> 태그(1205)는 그 값(1210)으로서 질의의 문자열 표현을 가지며, 여기에서 관심있는 계정 번호("123-4567-890")가 입력 파라미터 값으로 제공되었다. (이러한 질의는 프로브의 형태로 피어들을 수신함으로써 해석될 것이고, 이로써 노드들은 그들이 실제로 이러한 질의를 지원하는지, 그리고 그들이 질의에 응답하는데 대해 그들의 현재 stature인 것으로 주장하는 것을 결정하도록 질의를 받음에 주목한다. (1120)에서 전송된 메시지는 실제 컨텐츠 요청이 아니다.)

만족스러운 응답이 제1 층의 임의의 노드들로부터 수신되지 않는다(즉, 질의된 피어들 중 어느 것도 용인 가능한 stature로 그 질의에 응답할 수 없다)면, 제어는 다음으로 가장 좋은 피어들의 집합으로 구성된 제2 층이 식별되는 블록(1110)으로 복귀한다. (바람직하게는 구성 가능할 수 있는 시간 간격을 이용하여, 질의된 피어들이 응답하는데 기다리며 소비된 시간을 제한한다.) 이러한 제2 층은 또한 이러한 질의를 지원하지만 제1 층보다 더 낮은 stature 값들을 갖는 이러한 피어들을 포함하는 것이 바람직하다.

다양한 층들의 피어들에게 질의 요청들을 전송하는 이러한 프로세스는 모든 비악의적인 피어 노드들이 질의될 때까지, 또는 질의 요청에 대한 만족스러운 응답이 수신될 때까지, 계속될 것이다. 이 후 제어는 블록(1130)에 도달한다.

몇몇 경우에 있어서, 질의에 대한 지원을 표시하지 않는 노드들에게 결국 질의 요청을 전송하는 것이 생산적일 수도 있음에 주목한다: 네트워크의 특별한 특성으로 인하여, 로컬 노드는 전형적으로 (피어들의 질의 셋을 포함하여) 노드의 모든 피어들의 레퓨테이션들에 관한 가장 현재의 정보를 항상 알지는 못할 것이다. 그러므로 로컬 노드의 정보가 그 피어를 좋은 후보로 나타내지 않을지라도, 그 요청된 질의에 잘 응답할 수 있는 피어 노드가 발견될 수 있다.

다시 도 11로 돌아가서, 하나 이상의 질의된 피어들이, 실제로 이러한 질의를 지원한다고 응답하는 것을 가정하면, 블록(1130)에서 로컬 가십 몽거 핸들러는 응답하는 노드들로부터 메타 데이터를 처리한다. 즉, 원격 피어들로부터의 응답 메시지는 원격 노드의 컨텐츠 저장소 내의 요청을 가장 잘 충족시키는 컨텐츠를 설명하는 메타 데이터를 포함할 것이고, 이러한 응답 메시지로부터의 정보는 블록(1140)에 의한 처리를 위해 국부적으로 저장되는 것이 바람직하다. 도 13의 SOAP 응답 메시지(1300)의 샘플을 참조하며, 여기에서 SOAP 헤더의 <content-meta-data> 태그(1305)는 컨텐츠 메타 데이터의 위치를 가리키는 단순한 XLink 요소를 제공한다. 예에서, "href" 속성의 값(1310)은 "purchase_order_123-4567-890.rdf"로 식별되는 정보가 본 명세서에서는 <queryResponse> 요소의 제1 차일드로서 구현됨을 표시한다((1315)에서 xpointer 문구를 참조한다). <queryResponse> 요소는 (1320)에 나타나 있고, 응답하는 노드로부터의 컨텐츠 메타 데이터의 RDF 스펙((1325) 참조)을 포함한다. 이 예에서 보여지는 바와 같이, 응답자는 반환할 문서의 명칭((1330)에서의 "about" 속성값을 참조); 창작의 날짜 및 시간 뿐만 아니라 창작자의 명칭을 포함하는 컨텐츠 창작자 정보(<Creator> 요소(1335) 참조); 명칭된 문서에 속하는 시납시스(<synopsis> 요소(1340) 참조)를 표시한다.

응답하는 노드들의 집합으로부터의 컨텐츠 메타 데이터는 이 후 사용자에 의해 평가된다. 전술한 바와 같이, 이러한 사용자 평가는 사람 또는 계획에 따른 프로세스에 의해 수행될 수 있다. 사용자가 사람인 경우, <synopsis> 요소의 값(1340)은 그래픽 사용자 인터페이스 패널 상에 디스플레이되는 것이 바람직하고, 원하는 경우, <Description> 요소(1325)로부터의 다른 값들 또한 디스플레이될 수도 있다. 컨텐츠 메타 데이터를 분석한 후, 사용자는 피어 또는 피어들이 질의를 가장 잘 충족시키는 그의 선호를 식별하고, 그 컨텐츠에 대한 요청은 이 후 SOAP POST 요청으로 발행된다(블록(1140)).

도 14는 바람직한 실시예들에 따라 컨텐츠 요청과 함께 전송되는 단순한SOAP POST 요청(1400)을 제공한다. 이러한 예에서, SOAP 엔벌로프는 <getContent> 요소(1405)를 구현하며, 이는 그 "ID" 속성의 값(1410)으로 사용자의 컨텐츠 요청의 문자(이는 도 12의 질의 요청 메시지로 전송되었다)를 갖는다. 다른 대안으로 응답 메시지의 "about" 속성(1330)으로 수신되는 값을 "ID" 속성의 값(1410)으로 이용할 수도 있다.

피어 노드는 바람직하게는 여러 부분의 MIME(Multi-purpose Internet Mail Extension) 구조를 갖는 SOAP 응답 메시지로 인코딩된 요청된 컨텐츠를 반환한다. 요청된 컨텐츠를 수신한 경우, 수신 노드는 그 컨텐츠를 처리한다(블록(1160)). "SOAP Messages with Attachments, W3C Note 11 December 2000"라는 제목으로 W3C에 의해 공표되는 스펙(http://www.w3.org/TR/2000/NOTE-SOAP-attachments- 20001211 참조)은 어태치먼트를 전송하는 여러 부분의 MIME 구조를 이용하여 SOAP 메시지를 원래 포맷의 하나 이상의 어태치먼트와 관련시키는 표준 방법을 설명한다. SOAP 응답 메시지의 예는 도 15의 (1500)에 도시되며, 여기에서 컨텐츠 요청에 대한 응답은 참조 번호(1520)에 의해 표현되는 MIME 어태치먼트에 특정되어 있다. 바람직한 실시예들에 따라, SOAP 응답은 또한 피어 네트워크에 진입한 이후 이러한 컨텐츠의 탐색 경로를 표시하는 헤더들을 가지고((1505) 참조), 그 요청을 충족시키는 원격 피어는 바람직하게 원격 피어의 레퓨테이션에 대한 자신의 표현을 식별하는 URL을 제공한다.((1510) 참조).

블록(1150)에서 수행되는 프로세싱은 (우선 메시지롤 해독한 후, 원한다면 해독 핸들러를 이용하여) 탐색 경로 및 원격 레퓨테이션 정보를 추출하는 것을 포함한다.

이 후 디지털 서명 핸들러는 이러한 메시지 상의 모든 디지털 서명들을 확인한다(블록(1160)). 전송자의 인증이 실패하거나, 메시지 무결성 체크가 실패하는 경우, 이러한 것은 역으로 피어의 레퓨테이션에 강한 영향을 주고, 바람직하게는 그 피어 노드에 의해 표명된 레퓨테이션이 무시될 것이다. (다른 대안으로 이러한 환경 하에서 이러한 피어 노드의 레퓨테이션의 로컬 버전을 감소시키는 것이, 특정 구현에 있어서는 바람직할 수도 있다.)

컨텐츠 요청(1400)에 의해 발행된 모든 피어 노드의 국부적으로 유지되는 레퓨테이션들은 갱신되어(블록(1170)), 충족시키는 질의(satisfying query)들에서 그들의 성공 비율을 반영한다. 바람직하게는 이러한 것은 "totalQueries" 속성의 값을 증가시키고, 이러한 특정 응답자에 대해 적절하게 성공 카운트를 증가시키거나 또는 증가시키지 않는 것을 포함하며, 이 후 stature를 재계산한다. 바람직한 실시예들에 있어서, stature는 성공 카운트를 totalQueries 값으로 나눔으로써 계산된다. 이 후 이러한 갱신된 값들은 국부적으로 저장된다. 다른 대안의 실시예들에 있어서, stature는 다른 방법들로 계산될 수도 있다.

블록(1180)에서, 피어가 성공적으로 인증되었음을 가정하면, 그 피어의 응답 메시지로부터 얻어진 탐색 경로 정보(도 15에서 문서(1500)의 참조번호(1505)를 참조)는 국부적으로 저장되고 새로 수신된 켄텐츠와 관련될 것이다. (일례로, 도 6의 자원 셋(600)의 <content> 요소(660)를 참조한다.) 또한 탐색 경로는 확장되어, 방향성 그래프에서 가장 최근의 타겟 노드로서 현재 노드를 포함할 것이다(즉, 도 7의 (735)에서 도시되는 형태의 새로운 <arc> 요소를 생성함로써).

마지막으로, 수신된 컨텐츠는 애플리케이션에 제공되며(블록(1190)), 애플리케이션은 애플리케이션 특정 방식으로 그 컨텐츠를 처리한다. 이 후 도 11의 요청자 흐름은 이러한 컨텐츠 요청에 대해 종료한다.

도 11에 도시되는 프로세싱의 임의적인 확장으로서, 사용자는 컨텐츠가 궁극적으로 그 요청을 충족시켰는지 여부에 대한 피드백을 제공하며, 이는 제공자 노드의 stature에 강한 영향을 미칠 수 있다.

이제 도 16으로 돌아가서, (원격) 피어 노드가 컨텐츠 요청들을 평가하고 이에 응답하는 제공자 흐름의 바람직한 실시예가 설명될 것이다. 이러한 프로세스는 블록(1600)에서 시작하며, 여기에서 피어 노드는 질의를 수신하고 수신된 질의로부터 질의 열을 추출한다.

블록(1610)에서, 피어 노드는 추출된 질의 열을 그 자신의 컨텐츠 메타 데이터에 대하여 매칭하기 위해 패턴 매칭 오퍼레이션을 수행하여, 이러한 질의에 대답할 수 있는지 여부를 결정한다. (도 4a 및 4b를 참조하며, 여기에서 <QuerySet> 요소의 샘플은 특정 노드가 지원할 수 있는 질의들을 식별한다.) 질의 메시지들에 대해 타겟 노드들을 식별하는 것을 참조하여 전술한 바와 같이, 본 발명의 특정 구현은 사이트 서머리를 레버리지하여 이러한 패턴 매칭 프로세스를 촉진시킬 수 있다.

이러한 피어 노드가 요청된 질의를 수행할 수 있는 경우, 피어 노드는 (가능한 컨텐츠 제공자들로부터 응답들을 수신하는 요청 노드를 논했던) 블록(1130)을참조하여 상술한 형태의 SOAP 응답 메시지를 생성하고, 요청자에게 그 메시지를 반환한다(블록(1620)). 상기에서 논한 바와 같이, 이러한 응답 메시지는 질의 요청을 충족시키는 이러한 피어 노드에 의해 제공되는 컨텐츠를 설명하는 메타 데이터를 갖는 RDF 메시지를 포함하는 SOAP 엔벌로프를 포함한다.

또한, 몇몇 경우에 있어서, 블록(1620)에 의해 전송되는 응답 메시지는 다수의 RDF 메시지들을 포함할 수 있다. 이러한 것은 특정 노드가 하나 이상의 방법으로 질의를 지원할 수 있는 경우에 발생할 수 있다. 또한, (블록(1120)을 참조하여 설명되는 바와 같이 전송되는) SOAP 헤더(1200)를 이용하여 특정된 질의 요청은 (예를 들면, 하나 이상의 <query> 태그(1205)로 포맷된) 하나 이상의 질의 패턴을 포함하게 될 수도 있다. 또한, 응답은 이러한 경우에 다수의 RDF 메시지들을 포함할 수도 있다.

응답 메시지를 발행한 후, 제공자 노드는 요청자 노드로부터의 착신 컨텐츠 요청에 귀 기울인다(블록(1630)). 블록(1610)에서 수신되는 "이러한 질의를 지원할 수 있습니까"라는 메시지 이외에, 대기되어 있는 컨텐츠 요청은 "이러한 질의를 수행하여 주십시요"라는 요청이다. 바람직한 실시예들에 따라, 노드는 구성되는 시간 간격에 대한 착신 컨텐츠에 귀를 기울일 것이다. 대기되어 있는 요청을 수신하지 않은 채로 시간 간격이 경과하는 경우, 이러한 컨텐츠 요청의 프로세싱은 완성된 것으로 간주되고, 따라서 제어는 다음의 "이러한 질의를 지원할 수 있습니까"라는 메시지를 대기하기 위해 블록(1600)으로 복귀하는 것으로 나타나 있다. (명확하게는 별개의 쓰레드(thread)가 바람직하게 이용되어, 노드가 진행중인 기반 상의 착신 요청들을 대기하도록 한다.) 그렇지 않다면, 준비되어 있는 "이러한 질의를 수행하여 주십시요"라는 요청 메시지가 수신되는 경우, 프로세싱은 블록(1630)에서 블록(1640)으로 이전한다.

블록(1640)은 요청된 질의의 프로세싱을 호출하고, (도 15를 참조하여 상술한 바와 같이) 여러 부분의 MIME 어태치먼트들을 이용하여 그 결과를 SOAP 응답 메시지로 포맷한다.

블록(1650)에서, 제공자 노드의 경로 인티메이터는 외향 메시지를 위한 SOAP 헤더로서 컨텐츠의 탐색 경로에 참조를 덧붙인다. SOAP 헤더(1505)가 도 3a에 의해 예시된 바와 같이 탐색 경로 정의 정보를 제공하는 도 15를 참조한다. (이전에 설명한 바와 같이, 헤더 문서(300)의 <traversalPathRef> 태그(305)는 피어 네트워크 내의 특정 컨텐츠의 탐색 경로를 저장하는 링크 셋에 참조(310)를 제공한다.) 또한 본 발명은 (예를 들면, 적절하게, 특정 날짜 및 시간 값을 갖는 이러한 노드에 의해 생성되거나, 특정 날짜 및 시간 값을 갖는 이러한 노드에 의해 전달되는) 국부적으로 저장된 컨텐츠 탐색 경로 정의를 갱신한다.

이 후 제공자 노드의 가십 몽거는 노드의 로컬 레퓨테이션을 갱신하고(블록(1660)), 갱신된 정보를 저장하고, 외향 메시지의 SOAP 헤더에 레퓨테이션 정보를 포함한다. (SOAP 헤더(1510)가 도 3b에서 예시된 바와 같이 응답하는 노드의 레퓨테이션의 버전을 포함하는 도 15를 다시 참조한다.) 레퓨테이션을 갱신하는 경우 제공자 노드는 바람직하게는 인터랙션을 실패로 계산하여, 시간 간격이 "이러한 질의를 수행하여 주십시요"라는 요청을 수신함 없이 경과한 경우 컨텐츠 요청을 충족시킨다. 그렇지 않은 경우, 제공자 노드는 바람직하게는 이러한 인터랙션을 성공으로 계산한다. 성공 또는 실패 결과를 고려할 경우, "stature" 속성은 도 11의 블록(1170)을 참조하여 상술한 바와 같이 재계산된다. (실패 프로세싱은 블록(1630)에서 음의 결과로 인하여 수행될 것임을 주목한다.)

이 후 생성된 응답 메시지는 디지털 서명 핸들러에 의해 (SOAP 헤더들 및 어태치먼트들을 포함하여) 디지털적으로 서명되고(블록(1670)), 응답 메시지는 요청자에게 반환된다.

도 17a-17c는 본 명세서에서 설명된 임의적인 시스템 관리 능력과 함께 이용될 수 있는 헤더들의 샘플을 예시한다. 바람직하게는 관리될 노드들에 부가적인 AXIS 핸들러가 제공되고, 관리 "권한"을 갖는 하나 이상의 노드들은 수신 노드들에서 AXIS 핸들러에 의해 처리되는 관리 정보를 전달한다. 시스템 관리 능력을 제공하는 부가적인 AXIS 핸들러는 본 명세서에서 "관리 핸들러"로 언급된다. 본 발명의 바람직한 실시예들에 있어서 중앙 집중화된 관리 노드가 없기 때문에, (예를 들면, 다른 피어 노드들을 일정한 방식으로 감독하는) 관리 노드들로 기능할 수 있는 노드들은 바람직하게는 상대적으로 높은 stature 레벨을 지닌 레퓨테이션을 갖는 이러한 노드들이다.

본 명세서에 개시된 진화적인 신뢰 모델로 인하여, 임의의 노드는 잠재적으로 관리 stature를 달성하고, 이로써 시스템 노드로 동작할 수 있다. 그러므로 시스템 관리 기능은 원하는 경우 네트워크 상의 모든 노드에, 또는 다수의 노드들에 배치될 수도 있다. 시스템 노드의 관리 코드는 바람직하게는 인증 허가에 의해 인증되며, 이는 다른 노드들이 그 코드에 의해 발행된 메시지들을 신뢰할 수 있도록 한다: 이러한 메시지들에 대한 디지털 서명들은 수신 노드들의 관리 핸들러가 메시지들의 출처를 확인할 수 있도록 한다.

바람직한 실시예들에 있어서, 관리 핸들러는 두개의 새로운 헤더 유형을 지원하며, 이는 본 명세서에서 "peek" 및 "access"로 언급된다. peek 헤더를 이용하여, 노드에게 그 트래픽이 시스템 노드에 의해 모니터링될 것임을 알릴 수 있다. access 헤더를 이용하여, 노드의 링크 기반, 레퓨테이션 저장소, 또는 컨텐츠 저장소로부터 판독하거나 이들에 기록할 수 있다.

도 17a는 peek 헤더의 예를 제공한다. peek 메시지는 시스템 노드에 의해 전송되어 수신 노드의 관리 핸들러가 특정된 시스템 노드로 SOAP 메시지들을 복제할 것을 통지한다. 그러므로, 요소(1700)로 나타난 헤더는 메시지의 전송자를 식별하는 어드레스(1710)를 특정하는 단순한 XLink이다(즉, 시스템 노드). 이 후 수신 노드는 그 SOAP 트래픽의 복제를 위해 이러한 어드레스를 이용한다. 임의적으로, 속성들은 <peek> 요소 상에서 특정되어 수신기에 복제될 SOAP 메시지들의 카테고리들을 통지할 수 있다. 디폴트로 모든 SOAP 메시지들은 바람직하게 복제된다.

도 17b 및 17c는 access 명령을 예시한다. access 명령을 이용하여 상술한 바와 같이 수신 노드의 시스템 자원들에 액세스할 수 있다. 명령 포맷은 "command" 속성에 대한 대응하는 값을 통해 기록 동작 또는 판독 동작 중 하나로 특정될 수 있다. 기록 동작을 예시하는 도 17b의 <access> 헤더(1730)의 예에 있어서, 시스템 노드는 수신 노드의 관리 핸들러에게 새로운 레퓨테이션 정보가 요약된 레퓨테이션참조(1750)에 제공되고 있음을 지시하고 있다. 이 후 관리 핸들러는 이러한 정보를 같은 장소에 배치된 가십 몽거 핸들러에 전달한다. 예에서, 레퓨테이션 참조(1750)는 주장된 레퓨테이션 정보가 발견될 수 있는 레퓨테이션 저장소의 위치를 식별한다. 수신 노드는 국부적으로 저장하기 위해 레퓨테이션의 카피를 검색할 것을 선택할 수 있다; 또는, 수신 노드는 링크를 저장할 것을 선택하고, 정보가 필요할 때 저장소로부터 레퓨테이션에 액세스할 수 있다. 다른 대안으로 문구 형태(도시되지 않음)를 이용할 수 있으며, 이로써 레퓨테이션 자체가 헤더 내에 (피어 노드의 LBuuid, 노드의 주장된 stature, 및 임의적으로 노드의 질의 셋을 식별하는 속성들과 함께) 요약된다. "href" 속성(1740)은 시스템 노드의 어드레스를 제공하며, 이는 수신 노드가 헤더의 전송자를 식별할 수 있도록 한다.

판독 동작을 예시하는 도 17c의 <access> 헤더(1760)의 예에서 명령은 "linkBaseURI" 속성(1780)을 제공하여 링크 기반을 식별하도록 하고, 시스템 노드는 이 링크 기반에 대한 액세스를 탐색한다. 예에서 이러한 속성의 값은 xpointer 표기를 이용하여, <content> 요소가 <ResourceSet> 문서 내에 위치되어야 함을 알리며, 문서의 예는 "http://9.56.34.12/linkbase/lb.xml"에 저장되어 있다. 속성들은 다른 대안으로 레퓨테이션 저장소 또는 컨텐츠 저장소에 액세스하는 access 명령 상에 제공될 수 있다. "href" 속성(1770)은 시스템 노드의 어드레스를 제공하며, 이는 수신 노드가 헤더의 전송자를 식별하고 판독 명령에 대해 요청된 정보를 반환할 수 있도록 한다.

바람직하게는 수신 노드는 전송자를 확인하는 프로세스에서 시스템 노드의stature를 확인하여 전송 시스템 노드가 관리 기능들을 수행할 정도로 충분한 신뢰를 얻었는지를 결정한다. 관리 핸들러에 의해 부가되는 디지털 서명들은 또한 확인되는 것이 바람직하며, 이는 헤더 메시지들이 대응하는 시스템 노드로부터 기원하였음을 보장한다. 임의적으로 수신 노드는 전송자에게 이의(challenge)를 발행하여 전송자의 아이덴티티를 확인할 수 있다; 이는 도 17a-17c의 예들에 표시된 바와 같이 전송 시스템 노드를 식별하는 "href" 속성들을 이용함으로써 용이하게 된다.

이제 도 18을 참조하면, 시스템 관리 능력들을 수행하는 시스템 노드들에 의해 구현될 수 있는 (예를 들면, 피어 커뮤니티를 모니터링하고 관리하는) 관리 흐름이 도시된다. 블록(1800)에서 시스템 노드는 peek 동작을 호출한다; 바람직하게는 peek 헤더는 노드들이 네트워크(이는 도 8을 참조하여 상술한 바와 같이 노드들이 "alive" 메시지들을 발행함으로써 검출될 수 있다)에 가입할 때 노드들에게 전송된다.

일단 피어 노드들이 시스템 노드에 그들의 SOAP 트래픽을 복제하기 시작하는 경우, 시스템 노드는 그 트래픽을 모니터링한다(블록(1810)). 특히 시스템 노드는 레퓨테이션들 및 컨텐츠의 모든 전송들을 모니터링한다. 그러므로 시스템 노드는 다양한 피어 노드들이 그들의 레퓨테이션들이라고 주장하고 있는 것을 관찰할 수 있으며, 여기에는 그들의 레퓨테이션 저장소들에 대한 참조들을 포함하고, 또한 특정 노드들로부터의 컨텐츠가 성공적인 인터랙션을 구성하는 것으로 용인되고 있는지를 관찰할 수 있다.

블록(1820)에서, 시스템 노드는 보안 이벤트들을 검출하기 위해 모니터링된트래픽을 평가하는 것으로 도시된다. 바람직하게는 시스템 노드는 잘못된 레퓨테이션 정보가 주장되는 경우, 또한 손상된 컨텐츠가 전달되고 있는 경우 보안 이벤트를 트리거한다. 예를 들면, 노드가 높은 양의 stature 값을 가지고 있다고 주장하나, 시스템 노드는 많은 피어들이 이러한 노드로부터의 컨텐츠를 거절하고 있음을 관찰한 경우, 시스템 노드는 주장하는 노드가 악의적인 노드라고 결론지을 수 있다. 마찬가지로 시스템 노드는 피어 노드들이 특정 컨텐츠를 거절하는 것을 검출할 수 있고, 그 컨텐츠가 손상되어 있다고 결론지을 수 있다; 보안 이벤트는 이러한 상황에서도 트리거되는 것이 바람직하다. 검출된 보안 이벤트가 잘못된 레퓨테이션을 수반하는 경우(블록(1830) 참조), 시스템 노드에서의 관리 흐름은 블록(1840)으로 이전되고, 여기에서 시스템 노드는 그 노드의 레퓨테이션에 액세스하기 위해 access 명령을 발행한다(바람직하게는 기록 동작을 이용하여 시스템 노드가 레퓨테이션을 보는 관점을 수신 노드들에게 부과한다). 시스템 노드가 노드에게 자신의 레퓨테이션, 또는 다른 피어 노드의 레퓨테이션을 알릴 수 있음에 주목한다. 레퓨테이션 저장소 내에 여분의 영역이 제공될 수 있고(여기서 여분의 영역은 악의적인 노드에 의해 오버라이트(overwrite)될 수 없다), 이 후 기록 동작은 정보가 이러한 여분의 영역에 기록되도록 할 수 있다. 악의적인 노드들은 이러한 저장소의 영역에 기록되어 부정하게 높은 stature 값을 설정하는 것으로부터 차단될 수 있다. 결과적으로 노드가 레퓨테이션 저장소에 액세스하는 경우, 노드는 여분의 영역에 저장되는 정보를 해석하여 동일한 레퓨테이션에 속하는 다른 데이터에 대해 우선권을 취하는 것이 바람직하다. 다른 대안으로 여분의 영역이 이용되지 않는 경우,access 헤더 상의 시스템 노드에 의해 전송되는 정보는 비여분(non-reserved) 저장소에 기록될 수도 있다. (설명된 바와 같이, 피어 노드들은 또한 레퓨테이션 참조 또는 레퓨테이션 정보를 포함하는 메시지의 형태로 서로에게 레퓨테이션 정보를 전송할 수 있음에 주목한다.)

블록(1850)의 테스트는 보안 이벤트가 손상된 컨텐츠에 관계되어 있는지를 결정한다. 관계되어 있다면, 프로세싱은 블록(1860)에 도달하며, 시스템 노드는 access 명령을 발행하여 피어 노드에 의해 저장되는 컨텐츠가 손상되어 있다고 주장한다(예를 들면, 링크 기반 데이터에 액세스하고 오버라이트하여 탐색 경로들을 수정한다). 링크 기반은 또한 여분의 영역을 이용할 수 있으며, 시스템 노드는 컨텐츠 경로 탐색 정보를 이러한 여분의 영역에 기록할 수 있다.

access 헤더에 대한 다른 속성들의 이용을 참조하여 앞에서 논했던 바와 같이, 특정 구현에서 원하는 경우, 시스템 노드는 또한 노드의 국부적으로 저장된 컨텐츠를 오버라이트하기 위한 명령들을 발행하도록 허용될 수 있다. 컨텐츠 저장소에 영향을 미치는 access 명령들의 프로세싱은 레퓨테이션 및 컨텐츠 탐색 경로들에 영향을 미치는 명령들을 위해 설명되었던 것과 유사한 방식으로 수행될 수 있다.

일단 보안 이벤트 프로세싱이 완료되는 경우, 제어는 블록(1810)으로 복귀하여 피어 노드들의 트래픽을 모니터링하는 것을 계속한다. (모니터링이 중단되지 않도록, 보안 프로세싱은 개별적인 쓰레드에 의해 수행되는 것이 바람직함은 명백하다.)

모니터링 기능이 보안을 참조하여 설명되는 동안, 본 발명의 구현들은 피어 노드 트래픽을 모니터링하는 것으로부터 수집된 정보를 다른 목적을 위해 이용할 수 있다. 다른 용도의 예들은 장애 극복(failover) 및 높은 이용 가능성 시나리오들을 포함한다. 예를 들면, 장애 극복 시나리오에서, access 명령을 이용하여, 실패 노드(failing node)에 대한 참조들을 백업 노드에 대한 참조들로 대체하거나, 아마도 실패했던 노드에 대한 참조들을 삭제할 수 있다. 이러한 변화들은 자원 셋에서 실패한 노드를 식별하고, 그 노드의 LBuuid를 언급하는 엔트리들을 대체 또는 삭제함으로써 이루어질 수 있다. 높은 이용 가능성 시나리오에서, 시스템 노드가, 특정 피어 노드가 오버로드(overload)되어 있거나, 아마도 다른 노드들의 자원들이 이용 하에 있음을 검출하는 경우, 컨텐츠(또는 서비스)에 대한 링크 기반 참조들을 수정하기 위해 access 명령을 이용함으로써, 다른 대안으로 컨텐츠(또는 서비스)가 얻어질 수 있는 상이한 노드로 그 트래픽을 다시 향하게 할 수 있다. 설명된 바와 같이, 본 명세서에 개시된 기술들은 관리되는 피어 투 피어 네트워크를 위한 프레임웍를 제공하고, 호출들에 걸쳐서 피어 관계들을 유지하고 특별한 커뮤니티들이 형성될 때 이러한 관계들 및 아이덴티티들을 재사용할 수 있게 한다. 상술한 바와 같이, 피어 노드들은 자의적으로 네트워크에 진입하고 네트워크를 떠날 수 있고, 본 명세서에 개시된 기술들은 이러한 일시 커뮤니티들의 면전에서 보안, 관리, 및 다른 시스템 레벨 기능들을 제공하는 것을 가능하게 한다. 개시된 기술들은 P2P 네트워크들의 일시 커뮤니티들이 관리될 수 있도록 하고, 메시지 무결성이 일시 커뮤니티들에서 보장될 수 있는 안전한 트랜잭션들의 교환을 허용한다. MicrosoftCorporation으로부터의 헤일스톰 프로젝트(Hailstorm project)(".Net My Services"로도 언급됨)는 P2P 기술로서 특징지어진다. 그러나 거기에서의 P2P 지원은 인스턴트 메시징에 한정되는 것으로 나타난다. 이전에 논의되었던 JXTA와 같은 다른 종래의 P2P 네트워킹 제품들은 일시 커뮤니티들에서 쓰이는 본 명세서에서 개시된 특징들을 제공하지 않는다.

당업자가 이해하는 바와 같이, 본 발명의 실시예들은 방법들, 시스템들, 또는 컴퓨터 프로그램 제품들로서 제공될 수 있다. 따라서, 본 발명은 전체적으로 하드웨어 실시예, 전체적으로 소프트웨어 실시예 또는 소프트웨어 및 하드웨어 측면들을 조합하는 실시예의 형태를 취할 수 있다. 또한 본 발명은 컴퓨터가 이용 가능한 프로그램 코드가 구현된 하나 이상의 컴퓨터가 이용 가능한 기억 장치 매체(디스크 기억 장치, CD-ROM, 광 기억 장치 등을 포함하지만 이에 한정하지 않음) 상에 구현되는 컴퓨터 프로그램 제품의 형태를 취할 수 있다. 본 발명의 실시예들에 따른 방법들, 장치들(시스템들) 및 컴퓨터 프로그램 제품들의 흐름도 및/또는 블록 다이어그램을 참조하여 바람직한 실시예들이 설명되었다. 각 흐름도 및/또는 블록 다이어그램의 흐름 및/또는 블록, 흐름도 및/또는 블록 다이어그램의 흐름 및/또는 블록의 조합은 컴퓨터 프로그램 명령어들에 의해 구현될 수 있음은 물론이다. 이러한 컴퓨터 프로그램 명령어들은 범용 컴퓨터, 특수용 컴퓨터, 내장된 프로세서 또는 다른 프로그램 가능한 데이터 프로세싱 장치에 제공되어 머신을 생산함으로써, 컴퓨터의 프로세서 또는 다른 프로그램 가능한 데이터 프로세싱 장치를 통해 실행하는 명령어들이 흐름도의 흐름 또는 흐름들 및/또는 블록 다이어그램의 블록 또는블록들에서 특정되는 기능들을 구현하는 수단을 생성하도록 한다.

이러한 컴퓨터 프로그램 명령어들은 또한 컴퓨터 또는 다른 프로그램 가능한 데이터 프로세싱 장치를 특정 방식으로 기능하도록 지시할 수 있는 컴퓨터로 판독 가능한 메모리 내에 저장되어, 컴퓨터로 판독 가능한 메모리 내에 저장되는 명령어들이 흐름도의 흐름 또는 흐름들 및/또는 블록 다이어그램의 블록 또는 블록들에 특정되는 기능을 구현하는 명령 수단을 포함하는 제품을 생산할 수 있도록 한다.

일련의 동작 단계들이 컴퓨터로 구현되는 프로세스를 생산하는 컴퓨터 또는 다른 프로그램 가능한 장치 상에서 수행되도록, 컴퓨터 프로그램 명령어들은 또한 컴퓨터 또는 다른 프로그램 가능한 데이터 프로세싱 장치 상에 로드되어, 컴퓨터 또는 다른 프로그램 가능한 장치 상에서 실행하는 명령어들이 흐름도의 흐름 또는 흐름들 및/또는 블록 다이어그램의 블록 또는 블록들에 특정되는 기능들을 구현하는 단계들을 제공할 수 있도록 한다.

본 발명의 바람직한 실시예들이 설명되었지만, 당업자가 기본적인 창작 개념을 안다면 이러한 실시예들에 있어서 부가적인 변화들 및 변경들은 당업자에게 자명할 수 있다. 또한 바람직한 실시예들이 웹 서비스 환경을 참조하여 설명되었지만, 개선된 기술들은 또한 다른 P2P 네트워크 환경들에서 이용될 수도 있다. 또한 바람직한 실시예들이 본 명세서에서, 메시지 헤더들을 위한 특정 문구 및 SOAP 메시지, 문서 등을 참조하여 설명되었지만, 이는 예시용이고 이에 한정하지 않는다; 본 발명의 범위를 일탈하지 않는다면, 다른 대안적인 메시지 포맷들 및 다른 대안 문구를 이용할 수도 있다. 부가적으로 본 명세서에서 일시 네트워크들에 대하여 참조가 이루어져 있지만, 네트워크 형태는 시간이 지남에 따라 안정화하고, 따라서 "일시 네트워크"라는 용어는 일시 형태를 지원하는 아키텍쳐를 갖는 네트워크를 참조하여 구성될 수도 있다. 그러므로 첨부된 청구항들은 바람직한 실시예 및 본 발명의 범위에 해당하는 모든 변화들 및 변경들을 포함하는 것으로 구성되는 것으로 의도된다.

Claims

네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 일시 네트워크 커뮤니티들을 갖는 네트워크들에서 노드들을 지속적으로 식별하는 방법에 있어서,

상기 네트워크로 노드가 처음 진입할 때, 각 노드에 초기 네트워크 어드레스를 할당하는 단계와;

상기 네트워크로 상기 노드가 처음 진입할 때, 상기 노드들 각각에 대한 지속 노드 식별자(persistent node identifier)를 생성하는 단계와;

상기 초기 네트워크 어드레스 및 상기 지속 노드 식별자간의 맵핑을 저장하는 단계와;

추후 진입시 상이한 네트워크 어드레스가 상기 노드에 할당될지라도, 상기 네트워크로 상기 노드가 추후 진입할 때, 상기 지속 노드 식별자를 이용하여 상기 각 노드의 아이덴티티를 분석(resolve)하는 단계를 포함하는 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

상기 노드들 중 특정한 하나에 대해, 상기 네트워크로 상기 특정 노드가 추후 진입할 때, 상기 특정 노드에 상기 상이한 네트워크 어드레스를 할당하는 단계와;

상기 특정 노드의 지속 노드 식별자를 이용하여 상기 상이한 네트워크 어드레스를 할당한 후 상기 특정 노드의 아이덴티티를 분석하는 단계를 더 포함하는 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

특정 노드가 상이한 네트워크 어드레스로 상기 네트워크에 재진입할 때마다, 상기 특정 노드에 대해 저장된 맵핑을 수정하여, 상기 특정 노드에 대한 맵핑으로부터의 네트워크 어드레스가 상기 상이한 네트워크 어드레스로 대체될 수 있도록 하는 단계를 더 포함하는 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

상기 각 노드의 지속 노드 식별자는 상기 노드에 의해 사용되는 링크 기반을 유일하게 식별하여 링크들을 저장하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

특정 노드를 위한 상기 지속 노드 식별자는 상기 특정 노드의 초기 네트워크 어드레스, 상기 네트워크로 최초 진입이 발생한 날짜, 상기 네트워크로 최초 진입이 발생한 시간, 및 상기 최초 진입이 발생한 도메인의 식별자를 포함하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제5항에 있어서,

상기 지속 노드 식별자들은 UUID(Universal Unique Identifier) 포맷에 기초하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

특정 노드에 대한 상기 맵핑은 상기 특정 노드에 의해 알려진 다른 노드들을 지속적으로 식별하는 맵핑들을 갖는 자원 셋에 저장되는 것인 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

상기 지속 노드 식별자들을 이용하여 상기 네트워크의 각 노드의 행동을 추적하는 단계를 더 포함하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제8항에 있어서,

특정 노드를 위한 상기 행동은 상기 특정 노드가 다른 노드들로부터의 요청들에 얼마나 잘 응답할 수 있는가를 포함하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

상기 지속 노드 식별자를 이용하여 상기 네트워크의 컨텐츠 자원들에 의해 취해진 네트워크 탐색 경로들을 추적하는 단계를 더 포함하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제10항에 있어서,

상기 추적 단계는,

특정 컨텐츠 자원에 대해, 상기 특정 컨텐츠 자원이 어디에서 상기 네트워크에 진입했고, 또는 다른 대안으로 상기 네트워크의 어디에서 생성되었는지를 식별하는 단계와;

상기 특정 컨텐츠 자원에 대해, 선택되는 네트워크 탐색 상에서 상기 특정 컨텐츠 자원이 지나간 각 노드를 식별하는 단계를 더 포함하는 것이고,

상기 식별 단계들은 대응하는 노드들을 위한 상기 지속 네트워크 식별자들을 이용하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제9항에 있어서,

상기 특정 노드의 행동은 상기 특정 노드로부터 전송되는 발신 메시지들 상에 표시되는 것인 네트워크에서의 노드의 지속적 식별 방법.
제11항에 있어서,

상기 특정 컨텐츠 자원의 네트워크 탐색 경로는 상기 특정 컨텐츠 자원들을전송하는 발신 메시지들 상에 표시되는 것인 네트워크에서의 노드의 지속적 식별 방법.
제2항에 있어서,

상기 네트워크로 재진입하는 경우 각 노드에 의해, 상기 노드의 지속적인 네트워크 식별자 및 상기 노드의 네트워크 어드레스의 현재 버전을 이용하여, 상기 노드를 식별하는 메시지를 전송하는 단계와;

상기 네트워크의 다른 노드들에 의해 상기 전송 메시지를 수신하는 단계와;

상기 수신 노드들의 저장되는 맵핑들을 상기 수신 노드들에 의해 수정하여, 상기 재진입 노드의 네트워크 어드레스의 현재 버전을 반영하는 단계를 더 포함하는 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

상기 맵핑은 Xlink 표기를 이용하여 특정되는 것인 네트워크에서의 노드의 지속적 식별 방법.
제14항에 있어서,

상기 저장되는 맵핑들을 참조하여, 선택되는 노드의 이전의 행동을 식별하는 단계를 더 포함하는 것인 네트워크에서의 노드의 지속적 식별 방법.
제14항에 있어서,

상기 저장되는 맵핑들을 참조하여, 선택되는 노드에 의해 생성되거나, 선택되는 노드에 의해 전달되는 컨텐츠를 추적하는 단계를 더 포함하는 네트워크에서의 노드의 지속적 식별 방법.
제1항에 있어서,

상기 네트워크는 피어 투 피어 네트워크인 것인 네트워크에서의 노드의 지속적 식별 방법.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 애드 혹(ad hoc) 네트워크들에서 상기 노드들을 지속적으로 식별하는 시스템에 있어서,

상기 네트워크로 노드가 처음 진입할 때, 각 노드에 초기 네트워크 어드레스를 할당하는 수단과;

상기 네트워크로 상기 노드가 처음 진입할 때, 상기 노드들 각각을 위한 지속 노드 식별자를 생성하는 수단과;

상기 초기 네트워크 어드레스 및 상기 지속 노드 식별자간의 맵핑을 저장하는 수단과;

특정 노드가 상이한 네트워크 어드레스로 상기 네트워크에 재진입한 후, 지속 노드 식별자를 이용하여 상기 특정 노드의 아이덴티티를 분석하는 수단을 포함하는 네트워크에서의 노드의 지속적 식별 시스템.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 애드 혹(ad hoc) 네트워크들에서 상기 노드들을 지속적으로 식별하기 위한 컴퓨터 프로그램 제품에 있어서,

상기 컴퓨터 프로그램 제품은 하나 이상의 컴퓨터로 판독 가능한 매체 상에 구현되고, 제1항 내지 제18항 중 어느 한 항의 단계를 수행하는 컴퓨터로 판독 가능한 프로그램 코드 수단을 포함하는 것인 네트워크에서 노드를 지속적으로 식별하기 위한 컴퓨터 프로그램 제품.
네트워크를 구성하는 노드들의 집합이 시간에 따라 변할 수 있는 일시 네트워크 커뮤니니들을 갖는 네트워크에서 상기 노드의 레퓨테이션(reputation)을 지속하는 방법에 있어서,

여러번 상기 네트워크에 진입하는 경우, 상이한 네트워크 어드레스가 상기 노드에 할당될지라도, 상기 네트워크의 각 노드를 위해 지속 노드 식별자를 이용하는 단계와;

상기 노드에 의해 이용되는 현재 네트워크 어드레스 및 상기 각 노드의 지속 노드 식별자간의 맵핑을 생성하는 단계와;

상기 네트워크의 다른 노드들과 인터랙트하는 상기 각 노드의 행동의 결과를 레코딩하는 단계를 포함하고,

상기 노드의 현재 네트워크 어드레스가 변할지라도, 상기 맵핑은 상기 행동을 상기 노드와 관련시키는 것을 허용하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 각 노드를 위한 상기 레코딩된 결과들은 상기 노드가 다른 노드들로부터의 질의들에 응답하는데 얼마나 성공적인가를 표시하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 각 노드를 위한 상기 레코딩된 결과들은 다른 노드들로부터의 질의들에 응답하는데 있어서 상기 노드의 효율을 표시하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제23항에 있어서,

상기 효율은 상기 질의들에 대한 상기 응답들의 경과된 시간으로 측정되는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제22항에 있어서,

상기 성공은 상기 노드가 대답할 수 있는 상기 질의 각각에 대해 결정되는것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제22항에 있어서,

상기 성공은 상기 노드가 대답할 수 있는 상기 질의들 모두에 대해 집합적으로 결정되는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제23항에 있어서,

상기 효율은 상기 노드가 대답할 수 있는 상기 질의들 각각에 대해 결정되는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 효율은 상기 노드가 대답할 수 있는 상기 질의들 모두에 대해 집합적으로 결정되는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 노드의 레퓨테이션은 상기 노드가 대답할 수 있는 질의들의 셋 뿐만 아니라, 상기 질의들에 응답하는 경우 상기 노드의 행동의 레코딩된 결과들도 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 노드의 레퓨테이션은 상기 노드로부터 이용 가능한 서비스들의 셋 뿐만 아니라, 상기 서비스들을 수행하는 경우, 상기 노드의 행동의 레코딩된 결과들도 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

특정 노드에 의해 전송되는 메시지들과 함께, 상기 특정 노드에 대한 상기 레코딩된 결과들에게 참조(reference)를 전달하는 단계를 더 포함하는 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

특정 노드에 의해, 상기 특정 노드로부터 이용 가능한 컨텐츠에 대한 요청을 수신하는 단계와;

상기 특정 노드에 의해, 상기 특정 노드의 레퓨테이션을 주장하는 정보와 함께 상기 요청되는 컨텐츠를 전달하는 단계를 더 포함하고,

상기 레퓨테이션은 상기 특정 노드에 대한 레코딩된 결과들을 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제32항에 있어서,

상기 요청을 수신하고 상기 요청되는 컨텐츠를 전달하는 것에 응답하여 상기 특정 노드의 레코딩된 결과들을 상기 특정 노드에 의해 수정하는 단계를 더 포함하는 네트워크에서의 노드의 레퓨테이션 지속 방법.
제32항에 있어서,

수신 노드에서 상기 전달되는 컨텐츠를 수신하는 단계와;

상기 수신 단계에 응답하는 상기 수신 노드에 의해 상기 특정 노드의 레퓨테이션의 로컬 버전을 저장하는 단계를 더 포함하고,

상기 로컬 버전은 상기 수신되는 컨텐츠가 상기 수신 노드에 충분한지 여부를 반영하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 네트워크에 진입하는 각 노드에 의해 메시지를 브로드캐스트하고 이로써 상기 노드의 레퓨테이션의 버전을 통지하는 단계를 더 포함하고,

상기 레퓨테이션은 상기 네트워크의 다른 노드들과의 인터랙션에 있어서 얼마나 성공적인지에 대한 상기 노드의 관점을 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제35항에 있어서,

상기 레퓨테이션은 상기 브로드캐스팅 노드로부터 이용 가능한 컨텐츠를 더 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제35항에 있어서,

상기 레퓨테이션은 상기 브로드캐스팅 노드로부터 이용 가능한 서비스들을 더 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제35항에 있어서,

상기 네트워크의 다른 노드에 의해, 상기 브로드캐스트 메시지를 수신하는 단계와;

상기 수신 노드에 의해, 상기 브로드캐스트 메시지로부터 상기 브로드캐스팅 노드의 레퓨테이션의 버전을 검색하는 단계와;

상기 검색되는 레퓨테이션의 로컬 카피를 저장하는 단계를 더 포함하는 네트워크에서의 노드의 레퓨테이션 지속 방법.
제35항에 있어서,

상기 통지되는 레퓨테이션은 상기 브로드캐스팅 노드의 레퓨테이션의 버전에 대한 참조인 것이고,

상기 네트워크의 다른 노드에 의해, 상기 브로드캐스트 메시지를 수신하는 단계와;

상기 수신 노드에 의해, 상기 브로드캐스트 메시지로부터 상기 참조를 검색하는 단계와;

상기 참조의 로컬 카피를 저장하는 단계를 더 포함하는 네트워크에서의 노드의 레퓨테이션 지속 방법.
제38항에 있어서,

상기 로컬 카피는 상기 브로드캐스팅 노드의 레퓨테이션에 대한 상기 수신 노드의 관점을 반영하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제40항에 있어서,

상기 수신 노드가, 상기 브로드캐스팅 노드는 신뢰할만한 것이 아니라고 간주하는 경우, 상기 로컬 카피는 상기 브로드캐스팅 노드의 레퓨테이션에 대한 관점을 무시하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

특정 노드에 의해, 상기 특정 노드가 다른 노드로부터의 서비스 또는 컨텐츠를 필요로 한다고 결정하는 단계와;

상기 네트워크의 어떠한 다른 노드들이 상기 필요한 컨텐츠 또는 서비스를 제공할 수 있는지를 결정하는 단계와;

상기 필요한 컨텐츠 또는 서비스를 제공할 수 있는 상기 노드들에 대한 레코딩된 결과들을 평가하여 상기 노드들 사이에서 선택하는 단계를 더 포함하는 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 레코딩된 결과들은 특정 노드가 언제 신뢰할만한 것으로 간주되는지를 표시하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 레코딩된 결과들은 시간이 지남에 따라 재계산되고, 이로써 상기 노드들이 상기 네트워크의 다른 노드들의 신뢰를 얻고 있는지를 반영하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제44항에 있어서,

상기 네트워크의 다른 노드와 인터랙트하기를 원하는 특정 노드는, 상기 다른 노드를 신뢰하는지 여부를 결정하기 위해 상기 다른 노드의 레코딩된 결과들을 참작하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

상기 레코딩된 결과들은 시간이 지남에 따라 재계산되고, 이로써 상기 노드들이 질의들에 응답하는데 있어서 효율적인 것으로 상기 네트워크의 다른 노드들에 의해 간주되는지 여부를 반영하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제46항에 있어서,

상기 네트워크의 다른 노드와 인터랙트하기를 원하는 특정 노드는 다른 노드들 중 어느 것이 상기 인터랙션을 가장 효율적으로 수행할 수 있는지를 결정하기 위해, 다수의 상기 다른 노드들의 레코딩된 결과들을 참작하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제21항에 있어서,

특정 노드의 현재 네트워크 어드레스가 상기 레코딩된 결과들의 생성 이후 변화하였을지라도, 상기 각 노드의 지속 노드 식별자를 이용하여 상기 특정 노드의 레코딩된레코딩된위치시키는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제35항에 있어서,

상기 브로드캐스팅 노드에 의해, 상기 브로드캐스트 메시지를 수신하는 다른 노드들로부터 응답들을 수신하는 단계와;

상기 브로드캐스팅 노드에 의해, 상기 응답들로부터의 수신되는 버전들을 이용하여 상기 다른 노드들의 레퓨테이션들의 로컬 관점을 결정하는 단계를 더 포함하고,

상기 응답들은 상기 다른 노드들의 레퓨테이션들의 버전들을 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
제49항에 있어서,

상기 브로드캐스팅 노드에 의해, 상기 다른 노드들 각각에 수반하는 메시지를 전송하는 단계를 더 포함하고,

상기 수반하는 메시지는 상기 다른 노드들이 노드들의 아이덴티티를 위한 요청을 전달하도록 요청하고, 이로써 상기 브로드캐스팅 노드가 다른 서브넷의 노드들을 알고 다른 서브넷의 상기 노드들과 레퓨테이션 정보를 교환하는 것을 가능하게 하는 것인 네트워크에서의 노드의 레퓨테이션 지속 방법.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 일시 네트워크를 갖는 네트워크에서 노드의 레퓨테이션을 지속하는 시스템에 있어서,

여러번 상기 네트워크에 진입하는 경우 상이한 네트워크 어드레스가 상기 노드에 할당될지라도, 상기 네트워크의 각 노드를 위해 지속 노드 식별자를 이용하는 수단과;

상기 각 노드의 지속 노드 식별자 및 상기 노드에 의해 이용되는 현재 네트워크 어드레스간의 맵핑을 생성하는 수단과;

상기 네트워크의 다른 노드들과 인터랙트하는 상기 각 노드의 행동의 결과를 레코딩하는 수단을 포함하고,

상기 노드의 현재 네트워크 어드레스가 변할지라도 상기 맵핑은 상기 행동을 상기 노드와 관련시키는 것을 허용하는 것인 네트워크에서의 노드의 레퓨테이션 지속 시스템.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 애드 혹(ad hoc) 네트워크에서 노드의 레퓨테이션을 지속하기 위한 컴퓨터 프로그램 제품에 있어서,

상기 컴퓨터 프로그램 제품은 하나 이상의 컴퓨터로 판독 가능한 매체 상에 내장되어 있고, 제21항 내지 제50항 중 어느 한 항의 단계를 수행하는 컴퓨터로 판독 가능한 프로그램 코드 수단을 포함하는 것인 네트워크에서의 노드의 레퓨테이션 지속을 위한 컴퓨터 프로그램 제품.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 일시 네트워크 커뮤니티들을 갖는 네트워크들에서 컨텐츠를 추적하는 방법에 있어서,

여러번 상기 네트워크에 진입하는 경우 상이한 네트워크 어드레스가 상기 노드에 할당될지라도, 상기 네트워크의 각 노드를 위한 지속 노드 식별자를 이용하는 단계와;

상기 각 노드의 지속 노드 식별자 및 상기 노드에 의해 이용되는 현재 네트워크 어드레스간의 맵핑을 생성하는 단계와;

상기 지속 노드 식별자를 상기 네트워크의 노드들의 컨텐츠 자원들과 관련시키는 단계를 포함하는 네트워크에서의 컨텐츠 추적 방법.
제53항에 있어서,

상기 컨텐츠 자원들의 네트워크 탐색 경로들을 표현하기 위해 방향성 그래프들을 이용하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제54항에 있어서,

상기 방향성 그래프들 각각의 노드들은 상기 컨텐츠 자원들 중 하나가 지나간 상기 네트워크의 노드들을 표현하고, 상기 방향성 그래프들의 아크(arc)들은 상기 네트워크의 하나의 노드로부터 다른 노드로 지나가는 상기 컨텐츠 자원을 표현하는 것인 네트워크에서의 컨텐츠 추적 방법.
제53항에 있어서,

각 컨텐츠 자원을 위한 메타 데이터를 저장하는 단계를 더 포함하고,

상기 메타 데이터는 상기 컨텐츠 자원의 지속 식별자를 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제56항에 있어서,

상기 메타 데이터는 상기 컨텐츠 자원의 생성에 관련한 정보를 더 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제57항에 있어서,

상기 정보는 상기 컨텐츠 자원의 생성자 및 상기 생성의 날짜 및 시간을 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제53항에 있어서,

메타 데이터는 상기 네트워크로 상기 컨텐츠 자원의 진입에 관련한 정보 및 상기 네트워크로 상기 진입의 날짜 및 시간을 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제56항에 있어서,

상기 메타 데이터는 상기 컨텐츠 자원의 설명을 더 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제60항에 있어서,

상기 설명은 상기 컨텐츠 자원이 요구되는지를 평가하는 사용자에게 제공되는 것인 네트워크에서의 컨텐츠 추적 방법.
제55항에 있어서,

탐색 저장소의 상기 컨텐츠 자원들을 위한 방향성 그래프들을 저장하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제55항에 있어서,

상기 컨텐츠 자원들 중 하나가 상기 네트워크의 하나의 노드로부터 다른 노드로 전달될 때마다, 상기 방향성 그래프에 노드 및 아크를 부가하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제55항에 있어서,

각 컨텐츠 자원을 위한 방향성 그래프를 특정하기 위해, 구조화된 마크업 언어 표기가 이용되는 것인 네트워크에서의 컨텐츠 추적 방법.
제62항에 있어서,

상기 방향성 그래프들은 아크들의 종단점들을 이용하여 특정되는 것인 네트워크에서의 컨텐츠 추적 방법.
제65항에 있어서,

Xlink 표기는 각 아크의 상기 종단점들을 특정하기 위해 이용되는 것인 네트워크에서의 컨텐츠 추적 방법.
제55항에 있어서,

특정 컨텐츠 자원의 현재 위치 및 상기 컨텐츠 자원의 지속 식별자간을 맵핑하는 컨텐츠 맵핑을 저장하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제67항에 있어서,

상기 컨텐츠 자원의 지속 식별자는 상기 컨텐츠 자원과 관련되는 메타 데이터로서 저장되는 것이고,

상기 관련되는 메타 데이터의 지속 식별자를 이용하여 상기 컨텐츠 자원의 현재 위치를 결정하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제65항에 있어서,

컨텐츠 자원들을 전달하는 각 메시지에서, 상기 전달되는 컨텐츠 자원들을 위한 방향성 그래프들에 대한 참조를 포함하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제69항에 있어서,

요청 노드에서, 선택되는 컨텐츠 자원 및 상기 요청 노드의 방향성 그래프에 대한 참조를 수신하는 단계와;

상기 포함되는 참조를 이용하여 상기 방향성 그래프를 위치시키는 단계와;

상기 위치되는 방향성 그래프를 확장하여 상기 선택되는 컨텐츠 자원을 전달하는 노드 및 상기 선택되는 컨텐츠 자원을 수신하는 노드를 표현하는 최종 아크를 포함하는 단계를 더 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제70항에 있어서,

상기 최종 아크는 상기 선택되는 컨텐츠 자원의 지속 식별자를 더 포함하는 것이고,

로컬 컨텐츠 저장소에 상기 수신되는 컨텐츠 자원을 저장하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제70항에 있어서,

상기 로컬 컨텐츠 저장소에 상기 수신되는 컨텐츠 자원을 저장하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제70항에 있어서,

상기 최종 아크는 상기 선택되는 컨텐츠 자원의 지속 식별자를 더 포함하는 것이고,

로컬 컨텐츠 저장소에 상기 수신되는 컨텐츠 자원을 저장하는 단계와;

상기 수신되는 컨텐츠 자원에 대한 컨텐츠 맵핑을 저장하는 단계를 포함하고,

상기 컨텐츠 맵핑은 상기 수신되는 컨텐츠 자원이 상기 로컬 컨텐츠 저장소에 저장되었던 위치 및 상기 컨텐츠 자원의 지속 식별자간을 맵핑하는 것인 네트워크에서의 컨텐츠 추적 방법.
제53항에 있어서,

상기 네트워크는 피어 투 피어 네트워크인 것인 네트워크에서의 컨텐츠 추적 방법.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 일시 네트워크 커뮤니티들을 갖는 네트워크들에서 컨텐츠를 추적하는 방법에 있어서,

각 컨텐츠 자원의 네트워크 탐색 경로를 표현하는 방향성 그래프를 저장하는 단계와;

상기 각 컨텐츠 자원을 위한 방향성 그래프를 확장하여, 상기 컨텐츠 자원을 유지하는 노드로부터의 상기 컨텐츠 자원의 수반하는 탐색을 상기 컨텐츠 자원을 수신하는 노드에 반영하는 단계를 포함하고,

상기 방향성 그래프의 각 아크는 상기 네트워크의 하나의 노드로부터 다른 노드로 트래버스(traverse)하는 상기 컨텐츠 자원을 표현하고,

지속 식별자는 상기 각 컨텐츠 자원과 관련되고, 특정 컨텐츠 자원을 위한 방향성 그래프의 각 아크는 상기 관련되는 지속 식별자를 특정하는 것인 네트워크에서의 컨텐츠 추적 방법.
제75항에 있어서,

각 노드에 의해, 상기 노드의 국부적으로 저장되는 컨텐츠 자원들의 지속 식별자 및 상기 노드의 국부적으로 저장되는 컨텐츠 자원들 각각의 현재 위치간의 맵핑을 저장하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제76항에 있어서,

선택되는 컨텐츠 자원을 지속 식별자에 의해 식별하는 단계와;

상기 선택되는 컨텐츠 자원을 위한 상기 저장되는 맵핑을 이용하여 특정 노드에서 현재 위치를 결정하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제76항에 있어서,

선택되는 컨텐츠 자원을 지속 식별자에 의해 식별하는 단계와;

상기 선택되는 컨텐츠 자원을 위한 상기 저장되는 맵핑을 이용하여 네트워크 탐색 경로를 결정하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제75항에 있어서,

상기 네트워크의 각 노드는 지속 노드 식별자를 가지고,

특정 컨텐츠 자원을 유지하는 상기 노드 및 상기 방향성 그래프의 각 아크를 위해 상기 특정 컨텐츠를 전달하는 상기 노드는 지속 노드 식별자들을 이용하여 식별되는 것인 네트워크에서의 컨텐츠 추적 방법.
제75항에 있어서,

상기 네트워크에 진입하는 각 노드에 의해, 메시지를 브로드캐스트하고, 이로써 상기 노드가 어떤 컨텐츠를 유지하는지를 통지하는 단계를 더 포함하는 네트워크에서의 컨텐츠 추적 방법.
제80항에 있어서,

상기 브로드캐스트 메시지를 수신하는 노드에 의해, 상기 브로드캐스팅 노드로부터 특정 컨텐츠 자원을 요청하는 단계와;

상기 컨텐츠 자원을 위한 상기 유지 노드의 방향성 그래프에 대한 참조와 함께, 상기 요청 노드에서 상기 요청되는 컨텐츠 자원을 수신하는 단계와;

로컬 컨텐츠 저장소에 상기 수신되는 컨텐츠 자원을 저장하는 단계와;

상기 수신되는 컨텐츠 자원을 위해 상기 방향성 그래프의 로컬 카피를 저장하는 단계를 더 포함하고,

상기 로컬 카피는 상기 유지 노드에서 상기 수신 노드로 트래버스(traverse)하기 위한 확장을 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제75항에 있어서,

상기 컨텐츠 자원들은 상기 네트워크의 노드들간의 공유를 위해 이용 가능한 파일들을 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
제75항에 있어서,

상기 컨텐츠 자원들은 상기 네트워크의 노드들로부터 이용 가능한 서비스들의 결과들을 포함하는 것인 네트워크에서의 컨텐츠 추적 방법.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 일시 네트워크 커뮤니티들을 갖는 네트워크들에서 컨텐츠를 추적하는 시스템에 있어서,

여러번 상기 네트워크에 진입하는 경우 상이한 네트워크 어드레스가 상기 노드에 할당될지라도, 상기 네트워크의 각 노드를 위한 지속 노드 식별자를 이용하는 수단과;

상기 각 노드의 지속 노드 식별자 및 상기 노드에 의해 이용되는 현재 네트워크 어드레스간의 맵핑을 생성하는 수단과;

상기 지속 노드 식별자를 상기 네트워크의 노드들의 컨텐츠 자원들과 관련시키는 수단을 포함하는 네트워크에서의 컨텐츠 추적 시스템.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 애드 혹(ad hoc) 네트워크들에서 컨텐츠를 추적하는 컴퓨터 프로그램 제품에 있어서,

상기 컴퓨터 프로그램 제품은 하나 이상의 컴퓨터로 판독 가능한 매체 상에 내장되어 있고, 제53항 내지 제83항 중 어느 한 항의 단계를 수행하는 컴퓨터로 판독 가능한 프로그램 코드 수단을 포함하는 것인 네트워크에서 컨텐츠를 추적하는 컴퓨터 프로그램 제품.
분산화된 네트워크에서 기억 장치 자원을 관리하는 방법에 있어서,

상기 네트워크에 진입하는 경우 노드에 할당되는 현재 네트워크 어드레스가 진입할 때마다 변할지라도, 지속 노드 식별자를 상기 네트워크의 각 노드와 관련시키는 단계와;

다수의 기억 장치 노드들의 행동을 동적으로 평가하는 단계와;

상기 네트워크의 각 노드의 현재 네트워크 어드레스를 관련되는 지속 노드 식별자와 상호 관련시키는 맵핑을 이용하여 상기 기억 장치 노드들 각각의 아이덴티티를 분석함으로써 상기 기억 장치 노드들의 동적으로 평가되는 행동에 대한 계속적인 인식을 유지하는 단계와;

상기 기억 장치 노드들의 기억 장치 자원들을 관리하기 위해 상기 유지되는 인식을 이용하는 단계를 포함하고,

상기 기억 장치 노드들은 주문형(on-demand) 기억 장치 자원들을 제공하는 노드들인 것인 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제86항에 있어서,

상기 기억 장치 노드들 각각의 상기 동적으로 평가되는 행동은 상기 기억 장치 노드가 기억 장치 요청들을 처리하는데 있어 얼마나 효율적인지를 포함하는 것인 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제86항에 있어서,

상기 기억 장치 노드들 각각의 상기 동적으로 평가되는 행동은 상기 기억 장치 노드가 기억 장치 요청들에 얼마나 잘 응답하는지를 포함하는 것인 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제88항에 있어서,

상기 기억 장치 노드가 상기 기억 장치 요청들에 얼마나 잘 응답하는지는 상기 기억 장치 자원들의 현재 이용 가능한 기억 장치 능력을 표현하는 것인 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제86항에 있어서,

상기 기억 장치 노드들 각각의 상기 동적으로 평가되는 행동은 상기 기억 장치 노드가 이전의 기억 장치 요청들에 만족스럽게 응답하였는지를 표시하는 성공 측정을 포함하는 것인 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제86항에 있어서,

상기 기억 장치 노드들 각각의 상기 동적으로 평가되는 행동은 상기 기억 장치 노드로부터 현재 이용 가능한 컨텐츠의 스펙을 포함하는 것인 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제86항에 있어서,

상기 네트워크의 노드들 중 하나에 의해, 상기 기억 장치 자원들을 필요로 함을 결정하는 단계와;

상기 기억 장치 노드들의 상기 행동에 대한 계속적인 인식을 이용하여, 상기 필요한 기억 장치 자원들을 현재 제공할 수 있는 상기 기억 장치들 중 하나를 선택하는 단계를 더 포함하는 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제89항에 있어서,

기억 장치를 필요로 하는 노드에 의해, 상기 기억 장치 자원들에 컨텐츠를 저장할 필요가 있음을 결정하는 단계와;

상기 기억 장치 노드들의 상기 행동에 대한 계속적인 인식을 이용하여, 상기 기억 장치 노드들 중 하나를 선택하고, 상기 선택되는 기억 장치 노드의 기억 장치 자원들은 상기 기억 장치를 필요로 하는 노드에 대해 상기 컨텐츠를 저장하는데 충분한 현재 이용 가능한 기억 장치 능력을 갖는 것인 단계를 더 포함하는 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제93항에 있어서,

상기 선택되는 기억 장치 노드에 상기 컨텐츠를 저장하기 위한 요청을 상기 기억 장치를 필요로 하는 노드에 의해 발행하는 단계를 더 포함하는 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제87항에 있어서,

상기 네트워크의 노드들 중 하나에 의해, 상기 기억 장치 자원들을 필요로 함을 결정하는 단계와;

상기 기억 장치 노드들의 상기 행동에 대한 계속적인 인식을 이용하여, 상기 필요한 기억 장치 자원들을 효율적으로 제공할 수 있는 상기 기억 장치 노드들 중 하나를 선택하는 단계를 더 포함하는 분산화된 네트워크에서 기억 장치 자원 관리 방법.
제90항에 있어서,

상기 네트워크의 노드들 중 하나에 의해, 상기 기억 장치 자원들을 필요로 함을 결정하는 단계와;

상기 기억 장치 노드들의 상기 행동에 대한 계속적인 인식을 이용하여, 이전의 기억 장치 요청들에 만족스럽게 응답하는 상대적으로 높은 성공 측정을 갖는 상기 기억 장치 노드들 중 하나를 선택하는 단계를 더 포함하는 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
제91항에 있어서,

컨텐츠를 필요로 하는 노드에 의해, 상기 기억 장치 자원들로부터 상기 컨텐츠를 검색할 필요가 있음을 결정하는 단계와;

상기 기억 장치 노드들의 상기 행동에 대한 계속적인 인식을 이용하여, 상기 기억 장치 노드들 중 하나를 선택하고, 상기 선택되는 기억 장치 노드의 현재 이용 가능한 컨텐츠의 스펙은, 상기 컨텐츠를 필요로 하는 노드가 검색할 필요가 있는 상기 컨텐츠를 포함하는 것인 단계를 더 포함하는 분산화된 네트워크에서의 기억 장치 자원 관리 방법.
애드 혹(ad hoc) 네트워크에서 기억 장치 자원들을 관리하는 시스템에 있어서,

상기 네트워크에 진입하는 경우 상기 노드에 할당되는 현재 네트워크 어드레스가 진입할 때마다 변할지라도, 지속 노드 식별자를 상기 네트워크의 각 노드와 관련시키는 수단과;

상기 네트워크의 각 노드의 현재 네트워크 어드레스를 관련되는 지속 노드 식별자와 상호 관련시키는 맵핑을 이용하여 상기 기억 장치 노드들 각각의 아이덴티티를 분석함으로써, 다수의 기억 장치 노드들의 동적으로 평가되는 행동에 대한 계속적인 인식을 유지하는 수단과;

상기 유지되는 인식을 이용하여 상기 기억 장치 노드들의 기억 장치 자원들을 관리하는 수단을 포함하고,

상기 기억 장치 노드들은 주문형 기억 장치 자원들을 제공하는 노드들인 것인 네트워크에서의 기억 장치 자원 관리 시스템.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 애드 혹(ad hoc) 네트워크에서 기억 장치 자원들을 관리하는 컴퓨터 프로그램 제품에 있어서,

상기 컴퓨터 프로그램 제품은 하나 이상의 컴퓨터로 판독 가능한 매체 상에 내장되어 있고, 제86항 내지 제97항 중 어느 한 항의 단계를 수행하는 컴퓨터로 판독 가능한 프로그램 코드 수단을 포함하는 네트워크에서 기억 장치 자원들을 관리하는 컴퓨터 프로그램 제품.
분산화된 네트워크에서 관리 기능들을 제공하는 방법에 있어서,

지속 노드 식별자를 상기 네트워크의 노드들 각각과 관련시켜, 상기 네트워크에 진입하는 경우 상기 노드에 할당되는 현재 네트워크 어드레스가 진입할 때마다 변할지라도, 상기 노드들의 아이덴티티가 분석될 수 있도록 하는 단계와;

관리 기능을 수행하도록 허용됨을 특정 노드에 의해 주장하는 단계와;

상기 특정 노드의 지속 노드 식별자를 이용하여 상기 특정 노드가 상기 관리 기능을 수행하도록 허용되는지 여부를 확인하는 단계를 포함하는 분산화된 네트워크에서의 관리 기능 제공 방법.
제100항에 있어서,

레퓨테이션을 상기 노드들 각각과 관련시키는 단계를 더 포함하고,

상기 각 노드의 레퓨테이션은 상기 노드의 지속 노드 식별자를 이용하여 위치되는 것이고, 상기 지속 노드 식별자를 이용하는 상기 단계는,

상기 지속 노드 식별자를 이용하여 상기 특정 노드의 레퓨테이션을 위치시키는 단계와;

상기 특정 노드가 적합한 레퓨테이션을 갖는 경우, 상기 특정 노드는 관리 기능들을 수행하도록 허용된다고 결정하는 단계를 포함하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제101항에 있어서,

상기 레퓨테이션의 적합성은 시간이 지남에 따른 상기 특정 노드의 행동에 기초하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
상기 레퓨테이션의 적합성은 상기 네트워크의 다른 노드들과 비교할 때 상대적으로 높게 그 안에 저장되는 값에 기초하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제103항에 있어서,

상기 값은, 외부적으로 결정되는 값으로 초기화되고, 이 후 상기 특정 노드의, 상기 네트워크의 다른 노드들과의 인터랙션에 기초하여 동적으로 수정되는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제100항에 있어서,

상기 관리 기능은 상기 주장을 수신하는 노드를 요청하여 상기 특정 노드에 트래픽을 복제하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제105항에 있어서,

상기 특정 노드가 상기 관리 기능을 수행하도록 허용된다고, 상기 수신 노드가 결정하는 경우, 상기 수신 노드에 의해, 트래픽을 복제하는 단계를 더 포함하는 분산화된 네트워크에서의 관리 기능 제공 방법.
제100항에 있어서,

상기 관리 기능은 상기 주장을 수신하는 노드를 요청하여 상기 특정 노드에 트래픽의 하나 이상의 카테고리들을 복제하는 분산화된 네트워크에서의 관리 기능 제공 방법.
제100항에 있어서,

상기 관리 기능은 상기 주장을 수신하는 노드가 노드들의 레퓨테이션들을 수반하거나 노드들간에 컨텐츠를 전달하는 모든 트래픽을 상기 특정 노드에 복제하도록 요청하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제100항에 있어서,

상기 관리 기능은, 상기 주장을 수신하는 노드가 상기 수신 노드에 속하는 정보를 지닌 상기 특정 노드에 응답하도록 요청하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제109항에 있어서,

상기 특정 노드는 상기 관리 기능을 수행하도록 허용된다고 상기 수신 노드가 결정하는 경우에만, 상기 수신 노드는 상기 요청되는 정보로 응답하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제109항에 있어서,

상기 요청되는 정보는 상기 수신 노드에 의해 저장되는 레퓨테이션인 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제109항에 있어서,

상기 요청되는 정보는 상기 수신 노드에 의해 저장되는 컨텐츠인 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제109항에 있어서,

상기 요청되는 정보는 상기 수신 노드에 의해 저장되는 컨텐츠의 탐색 경로인 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제109항에 있어서,

상기 특정 노드는 상기 관리 기능을 수행하도록 허용된다고 상기 수신 노드가 결정하는 경우에만, 상기 수신 노드는 상기 요청되는 정보로 응답하고, 상기 특정 노드는 상기 수신 노드에 의해 발행되는 이의(challenge)에 응답하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제109항에 있어서,

상기 특정 노드는 상기 관리 기능을 수행하도록 허용된다고 상기 수신 노드가 결정하는 경우에만, 상기 수신 노드는 상기 요청되는 정보로 응답하고, 상기 요청의 디지털 서명은 상기 특정 노드가 상기 요청을 전송했음을 확인하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제100항에 있어서,

상기 관리 기능은 상기 주장을 수신하는 노드가 상기 수신 노드에 의해 저장되는 정보를 변화시키도록 요청하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제116항에 있어서,

상기 특정 노드는 상기 관리 기능을 수행하도록 허용된다고 상기 수신 노드가 결정하는 경우에만, 상기 수신 노드는 상기 요청되는 변화를 수행하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제116항에 있어서,

상기 요청되는 변화는 상기 수신 노드에 저장되는 레퓨테이션 정보를 오버라이트(overwrite)하는 것인 분산화된 네트워크에서의 관리 기능 제공 방법.
제116항에 있어서,

상기 요청되는 변화는 상기 수신 노드에 저장되는 컨텐츠를 오버라이트하는 것인 분산화된 네트워크에서 관리 기능 제공 방법.
제116항에 있어서,

상기 요청되는 변화는 상기 수신 노드에 저장되는 컨텐츠 탐색 경로를 오버라이트하는 것인 분산화된 네트워크에서 관리 기능 제공 방법.
분산화된 네트워크에서 관리 기능들을 제공하는 시스템에 있어서,

지속 노드 식별자를 상기 네트워크의 노드들 각각과 관련시켜, 상기 네트워크에 진입하는 경우, 상기 노드에 할당되는 현재 네트워크 어드레스가 진입할 때마다 변할지라도, 상기 노드들의 아이덴티티가 분석될 수 있도록 하는 수단과;

레퓨테이션을 상기 노드들 각각과 관련시키는 수단과;

관리 기능을 수행하도록 허용된다고 특정 노드에 의해 주장하는 수단과;

지속 노드 식별자를 이용하여 상기 특정 노드의 레퓨테이션을 위치시키는 수단과;

상기 특정 노드가 적합한 레퓨테이션을 가지는 경우 상기 특정 노드가 관리 기능들을 수행하도록 허용된다고 결정하는 수단을 포함하고,

상기 각 노드의 레퓨테이션은 상기 노드의 지속 노드 식별자를 이용하여 위치하는 것인 분산화된 네트워크에서의 관리 기능 제공 시스템.
네트워크를 구성하는 노드들의 집합이 시간이 지남에 따라 변할 수 있는 애드 혹(ad hoc) 네트워크에서 관리 기능들을 제공하는 컴퓨터 프로그램 제품에 있어서,

상기 컴퓨터 프로그램 제품은 하나 이상의 컴퓨터로 판독 가능한 매체 상에 내장되어 있고, 제100항 내지 제120항 중 어느 한 항의 단계를 수행하는 컴퓨터로 판독 가능한 프로그램 코드 수단을 포함하는 것인 네트워크에서 관리 기능들을 제공하는 컴퓨터 프로그램 제품.