KR101227769B1 - 폴링 간격을 이용한 모바일 네트워크 배경 트래픽 데이터 관리 - Google Patents

Abstract

무선 네트워크를 통한 전송을 위해 확립된 연결을 최적화하기 위해 데이터 전송을 정렬하기 위한 시스템 및 방법이 개시된다. 하나의 양태에서, 본 발명의 실시예는, 셀룰러 네트워크에서 모바일 장치에 의해 만들어진 연결을 최적화하기 위해, 모바일 장치로의 데이터 전송을 정렬하기 위해 시스템에서 구현될 수 있는 방법을 포함한다. 상기 방법은, 복수의 트랜잭션이 발생할 때마다 모바일 장치와의 무선 연결이 확립될 필요가 없도록, 모바일 장치로 전송되기 위해 모바일 장치로의 복수의 트랜잭션으로 수신된 데이터를 일괄처리하는 단계를 포함한다. 예를 들어, 모바일 장치를 위해 복수의 트랜잭션에서 수신된 데이터는, 모바일 장치에서의 무선 네트워크 연결의 단일 구현을 통해 하나의 트랜잭션에서 모바일 장치로 전송된다.

Description

폴링 간격을 이용한 모바일 네트워크 배경 트래픽 데이터 관리{MOBILE NETWORK BACKGROUND TRAFFIC DATA MANAGEMENT WITH OPTIMIZED POLLING INTERVALS}

관련 출원에 대한 상호 참조

이 출원은 2011년1월18일자 미국 특허 출원 제13/300,267호 "Aligning Data Transfer To Optimize Connections Established For Transmission Over A Wireless Network"의 계속 출원이며, 상기 미국 특허 출원은 2010년11월22일자로 출원된 미국 가특허출원 제61/416,020호 "ALIGNING BURSTS FROM SERVER TO CLIENT", 2010년11월22일자로 출원된 미국 가특허출원 제61/416,033호 "POLLING INTERVAL FUNCTIONS", 2011년01월07일자로 출원된 미국 가특허출원 제61/430,828호 "DOMAIN NAME SYSTEM WITH NETWORK TRAFFIC HARMONIZATION", 2011년09월09일자로 출원된 미국 가특허출원 제61/533,007호 "DISTRIBUTED CACHING IN A WIRELESS NETWORK OF CONTENT DELIVERED FOR A MOBILE APPLICATION OVER A LONG-HELD REQUEST"를 기초로 우선권 주장하며, 상기 출원들은 본원에서 참조로서 포함된다.

배경 기술

상시 연결 및 연결해제가 시그널링 네트워크 트래픽의 양을 증가시키며, 이는 네트워크 성능을 전체적으로 감소시키고, 네트워크 운영자(network operator)에게 책임을 넘기며, 그들로 하여금 대역폭과 네트워크 액세스의 증가하게 한다. 지금까지, 핫스팟(hotspot)에서의 네트워크 수용량을 증가시키기 위해 통신업체(carrier)가 4G와 LET 네트워크에 투자할 수 있었다. 그러나 이들 솔루션은 한계점에 도달하는 중이다. 또한 LTE와 4G는 추가 대역폭의 인지된 수용량으로 인해 사용자와 애플리케이션이 사용량과 데이터 소모량을 증가시킴을 보여준다. 장기적으로 이는 도움보다는 혼잡 문제를 추가시킬 수 있다.

덧붙이자면, 대부분은, 모바일 장치가 서비스 네트워크 내 복수의 소스(가령, 서버, 웹사이트, 네트워크의 노드, 등)로부터 데이터를 수신할 수 있다. 서비스와 클라이언트 사이의 라우터/통신 네트워크가 모든 서비스는 단일 물리 연결(physical connection)을 통해 클라이언트에게 변경사항을 전달할 수 있음을 보장한다. 그러나 서로 다른 (서로의 동작에 대해 알지 못하는) 서비스들이 클라이언트로 하여금 서로 다른 시점에서 연결을 만들도록 트리거하며, 서비스에서 클라이언트로의 데이터 전송의 효율적이거나 최적화된 정렬이 결여될 수 있다는 문제가 발생할 수 있다. 따라서 공유 연결(shared connection)의 효율적인 이용이 부재하며(또는 적어도 최소한이거나 덜 최적화되며), 때때로 단일 연결은, 단일 서비스 또는 데이터 소스에 대해서만 적합하거나 현실적인 수준의 서비스만 제공할 수 있다.

모바일 또는 광대역 네트워크가 대량 데이터의 높은 처리율을 위해 설계될 수 있지만, 반드시 소량 데이터의 낮은 처리율의 빈번한 요청을 필요로 하는 모바일 애플리케이션에 서비스하도록 맞춤 구성된 것은 아닐 수 있다. 기존 네트워크는 또한, 가령, 사용자 경험 관점에서, 여러 다른 유형의 모바일 트래픽 및 여러 다른 유형의 트래픽의 우선순위를 고려하지 않는다.

이러한 트랜잭션(transaction)이 모바일 장치 라디오를 상당한 시간(통상, 15-30초) 동안 고전력 모드(high-power mode)로 둔다. 상기 고전력 모드는 유휴 모드(idle mode)에서보다 100배의 전력을 더 소모할 수 있기 때문에, 이들 네트워크 개시(network-initiated) 애플리케이션은 전력을 많이 필요로 하며, 배터리를 빨리 소모할 수 있다. 네트워크 개시 기능부를 갖는 네트워크 애플리케이션(가령, 푸시 이메일, 뉴스 피드, 상태 업데이트, 멀티미디어 콘텐츠 공유, 및 그 밖의 다른 모바일 애플리케이션 등)의 수의 빠른 증가에 의해 문제가 확대된다. 덧붙이자면, 상시 폴링(constant polling)의 문제는 모바일 폰이 호(call)와 SMS 메시지를 전송하고 수신하기 위한 시그널링에 의존하고, 가끔 이들 기본 모바일 기능이 다루기 힘든 애플리케이션 및 그 밖의 다른 모바일 클라이언트에게 밀려나게 된다는 것이다.

도 1A는 무선 네트워크(또는 광대역 네트워크)에서 호스트 서버가 자원 보존을 위해, 모바일 장치(가령, 무선 장치)와 애플리케이션 서버 또는 콘텐츠 제공자 간 트래픽의 관리, 콘텐츠 캐싱, 및/또는 자원 보존을 촉진하는 시스템의 예시적 다이어그램을 도시한다. 호스트 서버는 추가로, 애플리케이션 거동(application behavior), 콘텐츠 우선순위(content priority), 사용자 활동(user activity), 및/또는 사용자 기대(user expectation)를 기초로 하여, 모바일 트래픽을 카테고리화, 및/또는 전달 정책(delivery policy)을 구현하여, 데이터 전송을 정렬하는 데 추가로 사용할 수 있음으로써, 무선 전송을 위해 확립된 연결을 최적화할 수 있다.
도 1B는 호스트 서버와 장치 간에 분산된 프록시 및 캐시 시스템의 예시적 다이어그램을 도시하며, 상기 시스템은 자원 보존 및 콘텐츠 캐싱을 위해 장치와 애플리케이션 서버/콘텐츠 제공자 간의 네트워크 트래픽 관리를 촉진한다. 호스트 서버와 장치 간에 분산된 프록시 시스템은 추가로, 애플리케이션 거동, 콘텐츠 우선순위, 사용자 활동, 및/또는 사용자 기대를 기초로 하여, 모바일 트래픽을 카테고리화, 및/또는 전달 정책을 구현하여, 예를 들어, 데이터 전송을 정렬하는 데 추가로 사용함으로써, 무선 전송을 위해 확립되는 연결을 최적화할 수 있다.
도 2A는 자원 보존, 콘텐츠 캐싱, 및/또는 트래픽 관리를 위해 무선 네트워크(또는 광대역 네트워크)의 트래픽을 관리하는, 모바일 장치(가령, 무선 장치)상에 있는 분산 프록시 및 캐시 시스템 내 클라이언트 측 구성요소의 하나의 예를 도시하는 블록도이다. 클라이언트 측 프록시(또는 로컬 프록시)는 추가로, 애플리케이션 거동, 콘텐츠 우선순위, 사용자 활동, 및/또는 사용자 기대를 기초로 하여, 모바일 트래픽을 카테고리화, 및/또는 전달 정책을 구현할 수 있어서, 데이터 전송을 추가로 정렬함으로써, 모바일 장치에서 확립되는 연결을 최적화할 수 있다.
도 2B는 모바일 애플리케이션 거동 및/또는 네트워크 상태에 대해 캐싱할 수 있고 캐싱 전략을 적응시킬 수 있는, 도 2A의 예에 나타난 캐시 시스템의 구성요소의 추가 예를 도시하는 블록도이다. 롱 폴(long poll) 요청을 검출하고 롱 폴의 캐싱을 관리할 수 있는 구성요소가 또한 도시된다.
도 2C는 캐시 디피트(cache defeat)를 검출할 수 있고, 캐시를 디피트하도록 의도된 식별자에 의해 주소지정된(addressed) 콘텐츠의 캐싱을 수행할 수 있는, 도 2A의 예에서 도시된 캐시 시스템의 애플리케이션 거동 검출기 및 캐싱 정책 관리기의 추가 구성요소를 도시하는 블록도이다.
도 2D는 애플리케이션 거동 및/또는 사용자 활동을 기초로 하여, 모바일 트래픽 카테고리화를 수행할 수 있고, 정책 구현을 수행할 수 있는 도 2A의 예시에서 나타난 로컬 캐시 내 추가 구성요소의 예를 도시하는 블록도이다.
도 2E는 무선 네트워크 또는 광대역 네트워크를 통해 데이터를 수신하기 위해 확립될 필요가 있는 연결의 개수를 최적화하도록, 모바일 또는 광대역 장치, 또는 그 사용자에게로의 인커밍 데이터 전송의 정렬을 촉진할 수 있는, 도 2A의 예에서 나타난 트래픽 성형 엔진과 애플리케이션 거동 검출기의 추가 구성요소의 예를 도시하는 블록도이다.
도 3A는 자원 보존, 콘텐츠 캐싱, 및/또는 트래픽 관리를 위해, 무선 네트워크(또는 광대역 네트워크)의 트래픽을 관리하는 분산 프록시 및 캐시 시스템 내 서버 측 구성요소의 일례를 도시하는 블록도이다. 서버 측 프록시(또는 프록시 서버)는 추가로, 애플리케이션 거동, 콘텐츠 우선순위, 사용자 활동, 및/또는 사용자 기대를 기초로 하여 모바일 트래픽을 카테고리화, 및/또는 전달 정책을 구현하여, 예를 들어, 데이터 전송을 정렬하는 데 추가로 사용함으로써, 모바일 장치로의 무선 전송을 위해 확립되는 연결을 최적화할 수 있다.
도 3B는 모바일 애플리케이션 거동 및/또는 네트워크 상태에 대해 캐싱할 수 있고 캐싱 전략을 적응화시킬 수 있는 도 3A의 예에서 도시된 캐시 시스템의 캐싱 정책 관리기의 구성요소의 추가 예를 도시하는 블록도이다. 롱 폴 요청을 검출하고 롱 폴의 캐싱을 관리할 수 있는 구성요소도 도시된다.
도 3C는 캐시 디피트 메커니즘(cache defeating mechanism)을 관리 및 검출할 수 있고, 콘텐츠 소스를 모니터링할 수 있는 도 3A의 예에서 도시되는 프록시 시스템의 구성요소의 또 다른 예를 도시하는 블록도이다.
도 3D는 애플리케이션 거동 및/또는 트래픽 우선순위를 기초로 하여, 모바일 트래픽 카테고리화와 정책 구현을 수행할 수 있는 도 3A의 예에서 나타난 프록시 서버의 추가 구성요소의 예를 도시하는 블록도이다.
도 3E는 무선 네트워크 또는 광대역 네트워크에서의 전송을 위해 확립된 연결을 최적화하기 위해, 모바일 또는 광대역 장치 또는 또 다른 수신자로의 데이터 전송을 정렬할 수 있는 도 3A의 예시에 도시된 트래픽 성형 엔진의 추가 구성요소의 예시를 도시하는 블록도이다.
도 4는 무선 네트워크(또는 광대역 네트워크)에서, 분산 프록시 시스템에 의해 수행되는 콘텐츠 캐싱 및 모니터링을 이용함으로써, 네트워크와 배터리 자원이 보존되는 방식으로, 모바일 장치(가령, 임의의 무선 장치)로부터 애플리케이션 서버/콘텐츠 제공자로의 데이터 요청이, 분산 프록시 시스템에 의해 조화될 수 있는 방법을 도시하는 타이밍도이다.
도 5는 분산 프록시 및 캐시 시스템(가령, 도 1B의 예에서 도시되는 분산 시스템)을 이용해 모바일 장치(가령, 임의의 무선 장치)상에서의 하이브리드 IP 및 SMS 전력 절약 모드를 구현하기 위한 하나의 예시적 프로세스를 도시하는 도면이다.
도 6은 모바일 장치(가령, 임의의 무선 장치)와 원격 프록시 간의 분산 콘텐츠 캐싱 및 콘텐츠 캐싱의 분산된 관리를 위한 예시적 프로세스를 도시하는 흐름도이다.
도 7은 장기 유지 요청을 통해 모바일 애플리케이션으로 향할 콘텐츠의 신선도(freshness)를 유지하면서, 분산 프록시 시스템에 의한 이뤄지는 상기 콘텐츠의 캐시 관리를 도시하는 상호대화도이다.
도 8은 롱 폴 요청에서의 헌팅 모드의 거동을 도시하는 타이밍도와 롱 폴이 정착됐을 때의 타이밍 특성을 도시하는 타이밍도이다.
도 9는 무선 네트워크(또는 광대역 네트워크)를 통해 모바일 장치(가령, 임의의 무선 장치)로부터 애플리케이션 서버/콘텐츠 제공자로의 데이터 요청을 갖는 폴이, 분산 캐싱 시스템에 의해, 로컬 프록시 상에 캐싱 및 관리될 수 있는 방법을 도시하는 상호대화도이다.
도 10은 무선 네트워크(또는 광대역 네트워크)를 통해 식별자(가령, 캐싱을 디피트하도록 의도된 식별자) 내 캐시 디피트 메커니즘을 이용하는 애플리케이션 서버/콘텐츠 제공자로부터의 콘텐츠에 대한 폴이 검출되고 로컬 캐싱될 수 있는 방법을 도시하는 상호대화도이다.
도 11은 요청 및 이와 연계된 응답에 대한 정보를 수집하여 캐싱가능함 여부를 식별하고, 응답을 캐싱하는 것에 대한 예시적 프로세스를 도시하는 흐름도이다.
도 12는 요청에 대한 응답이 캐싱될 수 있는지 여부를 결정하기 위한 판정 흐름을 보여주는 예시적 프로세스를 도시하는 흐름도이다.
도 13은 요청 주기성 및/또는 응답 반복성을 기초로 하여, 캐싱가능할 가능성을 결정하기 위한 예시적 프로세스를 도시하는 흐름도이다.
도 14는 특정 요청 또는 클라이언트에 대한 캐싱 파라미터를 동적으로 조절하기 위한 예시적 프로세스를 도시하는 흐름도이다.
도 15는 프록시 서버가 모바일 장치(가령, 임의의 무선 장치)를 대신하여 애플리케이션 서버/콘텐츠 호스트를 모니터링하기 위한 폴링 간격 또는 속도를 결정하고 설정하기 위해, 요청 간격(request interval)을 이용하는 예시적 프로세스를 도시하는 흐름도이다.
도 16은 다양한 유형의 요청-응답 시퀀스를 위한 타이밍 특성을 나타내는 예시적 타이밍도이다.
도 17A는 요청-응답 시퀀스에 대한 타이밍 특성을 나타내는 타이밍도의 하나의 예이다.
도 17B는 롱 폴의 요청-응답 시퀀스 특성에 대한 타이밍 특성을 도시하는 타이밍도의 일례이다.
도 18은 캐싱을 위해 적합할 수 있는 주기적 요청의 검출의 하나의 예를 도시하는 데이터 타이밍도이다.
도 19는 요청 간격에서 변화의 검출의 하나의 예를 도시하고, 이에 대흔 응답에서의 서버 폴링 속도를 업데이트하는 데이터 타이밍도이다.
도 20은 캐싱된 엔트리로 전경 요청에 대해 서비스하는 하나의 예를 도시하는 데이터 타이밍도이다.
도 21은 요청하는 애플리케이션에 대해, 오래된 콘텐츠가 서비스가 다시 한 번 서비스된 후 발생하는 캐시 무효화의 가능한 효과의 하나의 예를 나타내는 데이터 타이밍도이다.
도 22는 캐시 엔트리에 대해 설정된 수명시간(TTL)을 고려해 캐시 관리 및 응답을 도시하는 데이터 타이밍도이다.
도 23은 캐시 스토어에 대한 구성요소 API 레이어의 하나의 예를 도시하는 도면이다.
도 24는 캐시 스토어를 위한 데이터 모델의 하나의 예를 도시하는 도면이다.
도 25는 캐시 스토어에서 캐시 엔트리의 데이터 모델의 하나의 예의 개념도이다.
도 26A-B는 변하는 파라미터를 갖는 식별자에 의해 주소지정되는 캐싱가능한 응답을 도시하는 예시적 요청-응답 쌍이다.
도 27A는 모바일 장치에 있는 애플리케이션 또는 클라이언트를 위한 디폴트 또는 초기 폴링 간격의 예시적 리스트를 도시한다.
도 27B는 모바일 장치에 있는 애플리케이션 또는 클라이언트를 위한 조절된 폴링 간격의 예시적 리스트를 도시한다.
도 28은 트랜잭션이 발생할 때마다 모바일 장치가 라디오를 확립하거나 켤 필요없도록, 특정 모바일 장치로의 전송을 위한 복수의 트랜잭션을 통해 수신된 데이터를 일괄처리하기 위해, 복수의 모바일 장치 또는 모바일 장치 사용자를 위해 수행되는 예시적 프로세스를 도시하는 흐름도이다.
도 29는 폴링 간격을 조작함으로써, 무선 네트워크에서 모바일 장치로의 데이터 전송을 관리하는 예시적 프로세스를 도시하는 흐름도이다.
도 30은 제 1 서비스에 대한 조절된 폴링 간격을, 동일한 장치상의 타 서비스의 간격을 기초로 하여, 생성하기 위한 예시적 프로세스를 도시하는 흐름도이다.
도 31은 무선 네트워크를 통한 송신을 위해 확립된 연결을 최적화하기 위해, 데이터 전송을 정렬하는 예시적 프로세스를 도시하는 흐름도이다.
도 32는 기계가 본원의 방법들 중 임의의 하나 이상을 수행하도록 하기 위해 하나의 세트의 명령이 실행될 수 있는 컴퓨터 시스템의 형태로 된 예시적 기계의 개략적 표현이다.

다음의 기재와 도면은 설명을 위한 것이며, 한정하기 위한 것이 아니다. 많은 구체적 세부사항이 본원의 완전한 이해를 제공하기 위해 기재된다. 그러나 특정 경우, 본원의 기재를 불명확하게 하는 것을 막기 위해, 공지 또는 종래의 세부사항은 제공되지 않는다. 본원에서 "하나의 실시예" 또는 "실시예"가 반드시, 동일한 실시예를 지칭하는 것이 아닐 수 있고, 이러한 지칭은 실시예들 중 적어도 하나를 의미한다.

본 명세서에서, "하나의 실시예" 또는 "실시예"라는 언급은 상기 실시예와 관련하여 기재되는 특정한 특징, 구조, 또는 특성이 본원발명의 적어도 하나의 실시예에 포함됨을 의미한다. 본 명세서의 다양한 부분에서의 "하나의 실시예에서"라는 구문의 언급이 반드시 동일한 실시예를 지칭하는 것은 아니며, 또한 개별적인, 또는 대안적인 실시예들이 타 실시예들과 상호 배타적인 것임을 나타내는 것도 아니다. 덧붙이자면, 어떤 실시예들에서는 나타나고, 나머지 실시예들에서는 나타나지 않는 다양한 특징이 기재된다. 마찬가지로, 어떤 실시예들의 요건일 수 있지만, 또 다른 실시예들의 요건은 아닐 수 있는 다양한 요건이 기재된다.

본 명세서에서 사용되는 용어는, 본원발명의 맥락과, 각각의 용어가 사용되는 특정 맥락에 비추어, 해당 기술 분야의 통상의 의미이다. 본원발명의 설명과 관련해 해당업계 종사자에게 추가 안내를 제공하기 위해, 본원발명을 기재하기 위해 사용되는 특정 용어가 이하에서, 또는 본 명세서의 그 밖의 다른 곳에서, 설명된다.편의상, 특정 용어가, 예를 들어, 이탤릭체 및/또는 인용 부호를 이용해, 강조될 수 있다. 강조어의 사용은, 용어의 범위와 의미에 어떠한 영향도 미치지 않고, 용어가 강조되었는지에 관계없이, 용어의 범위와 의미는 동일한 맥락 하에서 동일하다. 동일한 사항이 두 가지 이상의 방식으로 설명될 수 있음을 알 것이다.

결과적으로, 대치어와 동의어가 본원에서 설명되는 용어들 중 임의의 하나 이상에 대해 사용될 수 있으며, 본원에서 상술 또는 설명되는지에 관계없이 어떠한 특별한 의의도 두지 않는다. 특정 용어에 대한 동의어가 제공된다. 하나 이상의 동의어의 언급이 다른 동의어의 사용을 배제하는 것은 아니다. 본 명세서의 임의의 부분에서의 예시의 사용, 예를 들면, 본원에서 설명되는 임의의 용어의 예시는 단지 설명을 위한 것에 불과하며, 본원발명의 범위와 의미 또는 임의의 예로 든 용어의 범위와 의미를 추가로 제한하려는 의도는 없다. 마찬가지로, 본원발명은 본 명세서에서 제공되는 다양한 실시예로 한정되지 않는다.

본원발명의 범위를 한정하려는 의도 없이, 본원발명의 실시예에 따르는 기기, 장치, 방법, 및 이들과 관련된 결과의 예시가 이하에서 제공된다. 제목 또는 소제목은 편의상 예시로 사용된 것일 수 있으며, 본원발명의 범위를 제한하지 않는다. 다르게 정의되지 않는 한, 본원에서 사용되는 모든 기술적이며 과학적인 용어는 본원발명이 속하는 기술분야의 종사자에 의해 일반적으로 이해되는 의미를 가진다. 상호충돌의 경우, 정의를 포함해, 본원이 우선시될 것이다.

본원발명의 실시예는, 무선 네트워크, 셀룰러 네트워크, 또는 광대역 네트워크를 통한 전송을 위해 확립된 연결을 최적화하기 위해 데이터 전송(data transfer)을 정렬하기 위한 시스템과 방법을 포함한다. 데이터 버스트(data burst)(즉, 복수의 소스로부터의 데이터 전송)의 정렬을 촉진하기 위해, 본원발명의 실시예가 데이터 전송 프로세스를 (시간 또는 그 밖의 다른 관련 관점에서) 데이터의 소스에 더 가깝도록 정렬한다. 즉, 하나의 실시예에서, 랜덤 시점에서 데이터를 인출(fetch)하고 버퍼링하기보다는, 최소한의 인-메모리 버퍼링이 필요하고, 모바일 장치에서 확립될 필요가 있는 연결의 수가 감소할 수 있도록, 정렬된 간격에서 데이터를 폴링하거나, 및/또는 정렬된 간격에서 새로운 콘텐츠를 수신하기 위해, 시스템이 일부 또는 모든 서비스를 정렬하려 시도할 수 있다.

데이터의 급증에 기여하는 복수의 인자가 존재하며, 예를 들어, 최종 사용자, 모바일 장치, 무선 장치, 모바일 애플리케이션, 및 네트워크가 있다. 모바일 장치가 진화할수록, 모바일 장치와 연계된 다양한 요소들, 즉, 가용성, 애플리케이션, 사용자 행동, 위치가 네트워크가 장치 및 애플리케이션과 상호대화하는 방식을 변화시킨다.

본원발명의 기술은, 모바일 콘텐츠가, 지정될 수 있거나 상대적인 "신선도(freshness)" 값을 가진다는 전제를 활용함으로써, 운영자와 장치 제조업체가 모바일 또는 무선 장치의 이동과 데이터의 급증을 모두 지원하기 위해 각각의 요소를 해결할 수 있는 포괄적이면서 엔드-투-엔드인 솔루션을 제공한다. 모바일 콘텐츠의 "신선도"는, 확정적으로, 또는 허용오차(이 오차 내에서, 사용자 경험은 개선되거나, 부정적인 영향을 받지 않으며, 부정적인 영향을 받더라도 사용자가 인지할 수 없거나 허용될 수 있는 임계 수준 내에 있음)를 갖는 일부 휴리스틱에 의해 결정될 수 있다.

본원발명의 혁신기술은 애플리케이션(가령, 모바일 애플리케이션)과 피어(대응하는 서버 또는 그 밖의 다른 클라이언트) 사이의 트랜잭션(transaction)(요청/응답)을 모니터링하고 분석하며, 규칙을 적용함으로써, 이러한 "신선도(freshness)"를 투명하게 결정한다. 덧붙이자면, 상기 기술은, 콘텐츠의 출처/호스트 서버에 의해 "캐싱 불가능함(non-cacheable)"로 표시될 수 있는 콘텐츠를 효율적으로 캐싱(cache)하고, 일부 "신선도" 값을 식별할 수 있으며, 그 후 상기 "신선도" 값은 애플리케이션-특정적 캐싱(application-specific caching)을 구현하는 데 사용될 수 있다. 일반적으로, "신선도" 값은, 일반적으로, 애플리케이션과 이에 대응하는 서버/호스트 간의 업데이트 간격(update interval)(가령, 요청이 전송되는 간격)을 이용하여 결정되는 근사 최솟값을 가진다.

본원발명의 기법의 한 가지 실시예는, 장치와 애플리케이션 활동(가령, 로딩(loading), 장치상의 현재 애플리케이션 수요, 액세스의 유형(푸시(push) vs. 풀(pull), 또는 하이브리드)의 제어, 위치, 단일 영역 내 사용자의 밀집도, 하루 중 시(time of day), 사용자가 애플리케이션, 콘텐츠, 또는 장치와 상호대화하는 빈도, 및 협업하는 클라이언트/서버로의 트래픽, 또는 협업하는 클라이언트 없이 모바일 장치들로의 동시 트래픽을 성형(shape)하기 위해 이 정보를 사용하는 것)을 포괄적으로 살펴볼 때 유선 및 무선 네트워크와 장치의 연결의 복수의 양태를 최적화하는 시스템을 포함한다. 본원발명의 서버는 어떠한 특정 네트워크 제공자와도 관련이 없기 때문에, 모든 서비스 제공자들 간의 네트워크 성능에 대한 가시성을 가진다. 이로 인해서, 운영자 또는 서비스 제공자에 무관하게, 최적화가 장치에 적용될 수 있으며, 따라서, 사용자 경험이 개선되고 로밍(roaming) 동안의 네트워크 활용이 관리된다. 오늘날 대역폭이 무선 네트워크에서의 주요 쟁점으로 간주된다. 액세스 문제를 해결하기 위한 추가 대역폭의 필요와 관련하여, 점점 더 많은 연구가 이뤄지고 있다. 성능 향상 솔루션 및 차세대 표준(가령, 흔히 3.5G, LTE, 4G, 및 WiMAX라고 일컬어지는 것들) 중 다수가 증가된 대역폭을 제공하는 것에 초점을 맞춘다. 상기 표준에 의해 부분적으로 해결될지라도, 남아 있는 핵심적인 문제는, 데이터 채널에서보다 시그널링 채널에서 대역폭이 더 부족하다는 것이며, 상기 표준은 배터리 수명 문제를 그리 잘 해결하지 않는다.

본원 발명의 기술의 실시예는, 예를 들어, 복수의 애플리케이션으로부터의 요청을 정렬하여 복수의 폴링 요청의 필요성을 최소화하는 것; 특정 콘텐츠 유형을 활용하여 연결/콘텐츠를 프록시화/관리하는 법을 결정하는 것; 장치, 사용자 행동 패턴(사용자가 장치/애플리케이션과 상호대화하는 빈도) 및/또는 네트워크 파라미터와 연계된 특정 휴리스틱을 적용하는 것을 포함한다.

본 발명의 기술의 실시예는, 다양한 위젯(widget), RSS 리더(RSS reader), 등에 의해 수행되는 반복되는 HTTP 폴을 원격 네트워크 노드(가령, 네트워크 운영 센터(Network Operation Center, NOC))로 이동시키는 것, 따라서, 장치 배터리/전력 소모량, 라디오 채널 시그널링 및 대역폭 사용량을 상당히 낮추는 것을 포함한다. 덧붙이자면, 기존 애플리케이션이 변할 필요가 없도록 분담(offloading)이 투명하게(transparently) 수행될 수 있다.

일부 실시예에서, 이는 동일한 콘텐츠(RSS 피드, 위젯 데이터 세트)에 대한, 특정 규칙(가령, 15분마다 발생)에 부합하는 반복되는 요청을 자동으로 검출하는 모바일 장치(가령, 임의의 무선 장치)상의 로컬 프록시를 이용해 구현될 수 있다. 로컬 프록시는 서버(가령, 통신 네트워크의 하나의 요소로서 동작하는 프록시 서버)로의 폴링을 위임하면서 모바일 장치에 콘텐츠를 자동으로 캐싱할 수 있다. 그 후, 상기 서버는 콘텐츠가 변한 경우 모바일/클라이언트 프록시에게 통지할 수 있으며, 콘텐츠가 변하지 않은 경우(또는 콘텐츠가 충분히, 즉, 식별될 만큼 변경되지 않은 경우) 모바일 프록시는 (라디오를 전혀 이용할 필요 없이) 자신의 캐시 내 최신 버전을 사용자에게 제공한다. 이러한 방식으로, 요청이 모니터링되어 요청이 새로운 것/변경됨(new/changed)이라고 플래깅된 적 없는 콘텐츠에 대한 것인 경우, 모바일 또는 무선 장치(가령, 모바일 폰, 스마트 폰, M2M 모듈/MODEM, 또는 그 밖의 다른 임의의 무선 장치 등)는 데이터 연결을 개설하거나 사용할 필요가 없다.

모니터링될 (가령, URL/콘텐츠를 포함하는) 콘텐츠 소스/애플리케이션 서버를 자동으로 추가하기 위한 로직이 다양한 인자들, 가령, 콘텐츠가 동일할 빈도, 동일한 요청이 만들어지는 빈도(고정된 간격/패턴이 있는가?), 어느 애플리케이션이 데이터를 요청 중인가, 등을 체크할 수 있다. 로컬 프록시 및/또는 서버에 의해, 캐시를 사용하는 것과, 원본 소스로부터 데이터를 요청하는 것 중에서 결정하기 위해 유사한 규칙이 구현되고 실행될 수 있다.

예를 들면, 요청이 계획에 없던/예기치 않은 때(사용자에 의해 개시되는 체크), 또는 캐시 등으로부터 응답이 n번 연속으로 제공된 후, 또는 애플리케이션이 배경(background)에서 실행 중인지, 전경(foreground)의 더 상호대화적 모드에서 실행 중인지 여부가 있다. 점점 더 많은 모바일 애플리케이션 또는 무선 지원 애플리케이션이 네트워크에서 이용 가능한 자원을 기반으로 할수록, 이는 점점 더 중요해진다. 덧붙이자면, 본원발명의 기술에 의해, 네트워크로부터 불필요한 채터(chatter)가 제거되며, 이는, 무선 스펙트럼 사용량을 최적화하려 시도하는 운영자에게 유익하다.

서버로부터 수신자로의 데이터 버스트를 정렬하기

일부 경우, 모바일 장치 또는 모바일 클라이언트(가령, 도 1B 및 도 2A-2E에서의 로컬 프록시(175 또는 275))가 무선 또는 광대역 네트워크 내 복수의 소스(가령, 서로 다른 서비스, 서로 다른 서버, 웹사이트, 네트워크의 다양한 노드, 등)로부터 데이터를 수신할 수 있다. 서비스와 모바일 클라이언트(또는 모바일 장치) 사이의 라우터/통신 네트워크에 의해, 복수의 서비스, 가령, 서로 다른 서버 또는 콘텐츠 호스트에 의해 호스팅되는 서로 다른 서비스가, 하나의 단일 물리 연결을 통해, 또는, 다른 경우라면 요구됐을 연결보다 더 적은 연결을 통해, 변경사항을 클라이언트에게 전달할 수 있다. 그러나 서로 다른 서버에 의해 호스팅되는 (서로의 동작에 대해 알고 있지 않은) 서로 다른 서비스가 서로 다른 시점에서 상기 연결을 생성하도록 모바일 장치 상의 그들 각자의 클라이언트/모바일 애플리케이션을 트리거할 수 있기 때문에, 일반적으로, 대응하는 모바일 클라이언트 또는 애플리케이션과 통신하기 위해, 서비스에서 모바일 장치로의 데이터 전송의 효율적이고 최적화된 정렬이 결여될 수 있다. 따라서 공유 연결의 효율적인 이용이 부재하며(또는 적어도 최소한이거나, 준-최적화되며), 때때로 단일 연결은, 단일 서비스 또는 데이터 소스에 대해 적절하거나 현실적인 수준의 서비스만 제공할 수 있다.

본 발명의 실시예에 의해, 데이터 버스트의 정렬이 가능해지고, 따라서 복수의 소스 또는 서버에서 모바일 장치로의 데이터의 전송이 추가로 더 효율적이 될 수 있다. 예를 들어, 본원발명의 실시예가 데이터 전송 프로세스(들)을 (시간 또는 그 밖의 다른 관련 관점에서) 데이터의 소스(들)에 더 가깝도록 정렬한다. 즉, 랜덤 시점에서 데이터를 인출하고 버퍼링하는 것 대신, 시스템은 최소한의 인-메모리 버퍼링(in-memory buffering)이 필요하도록 정렬된 간격(aligned interval)에서 데이터를 인출하기 위해, 및/또는 모바일 클라이언트/장치로 전송되는 데이터의 일괄처리(batching)를 가능하게 하기 위해, 일부 또는 전체 서비스를 정렬한다.

예를 들어, 모바일 장치의 사용자가 다음의 서비스를 구독, 또는 그 밖의 다른 방식으로 다음의 서비스에 등록/가입된 예를 고려하자.

1) 야후!(Yahoo!)로부터의 전자메일: 서비스가 배경(background)에서 30분마다, 그리고 새로운 통지가 수신될 때, 폴링한다.

2) 범용 IMAP으로부터의 전자메일: 서비스가 13분마다 폴링하며, 어떠한 통지도 유효하지 않다.

3) 트위터(Twitter)에 대한 스마트 프록싱: 서비스는 13분 4분마다 폴링한다.

4) RSS 클라이언트를 위한 스마트 프록싱: 서비스는 10분마다 폴링한다.

5) ESPN 스포츠 피드를 위한 스마트 프록싱: 서비스는 3분마다 폴링한다.

이러한 상기의 서비스/모바일 클라이언트들 중 일부가 모바일 또는 무선 광대역 장치에서 그들 고유의 폴링 간격(polling interval)을 갖는 랜덤 시점에서 초기화되는 경우, 서로에 대한 정렬 또는 대응이 최소한이거나 거의 없이, 폴(poll)들은 꽤 고르게 확산될 것이다. 이들 서비스는 서버 측에서는 서로에 대해 반드시 알 필요는 없기 때문에(그리고 이러한 종속성은 이들 서비스 사이에 구축되지 않아야하고 않을 것이기 때문에), 이러한 활동을 정렬하고, 따라서 데이터 전송(들)을 더 잘 최적화함에 있어, 모바일 장치(가령, 모바일 장치의 로컬 프록시(175 또는 275))가 모바일 애플리케이션으로부터 정보를 획득할 수 있고,

일부 실시예에서, 모바일 장치(가령, 로컬 프록시(175 또는 275))가 계산과 분석을 수행하여, 모바일 장치에서, 모바일 애플리케이션의 이들 폴링 간격에 걸쳐 정렬을 구동시킬 수 있다. 발원 애플리케이션 서버/콘텐츠 제공자(가령, 앱 서버(app server)/콘텐츠 제공자(110))로 폴링하기 위해 본원발명의 분산 시스템에서 로컬 프록시가 호스트 서버(100)의 원격 프록시 서버(125)와 함께 작업하기 때문에, 로컬 프록시(125)는 하나 이상의 모바일 애플리케이션 또는 클라이언트에 대한 폴링 간격을 폴링을 위한 원격 프록시(125)에게로 특정해 알릴 수 있다. 모든 서비스(가령, 모바일 클라이언트 또는 모바일 애플리케이션)가 그들의 폴링 간격을 (서로에게는 전달하지 않고) 클라이언트에게 전달할 때, 로컬 프록시(175 또는 275)가 전체 그림을 볼 것이다.

로컬 프록시(175 또는 275)가 개별 애플리케이션, 사용자, 모바일 장치, OS 또는 플랫폼, 네트워크 상태, 애플리케이션 우선순위/트래픽의 중요도(criticality), 또는 콘텐츠에 대해 갖는 개별 폴링 간격 및 추가 정보를 이용해, 애플리케이션이 오작동을 하지 않도록 사용자 기대와 애플리케이션 수요를 충족하기 위해 필요한 데이터 전송의 횟수를 최소화하는 지능적 방식으로, 상기 로컬 프록시(175)는 각각의 모바일 클라이언트 또는 애플리케이션에 대해 폴링 간격을 조절할 수 있다.

한 가지 개시되는 전략은, 모바일 애플리케이션들 중 적어도 일부에 대해, 간격의 조절 후, 폴들이 적어도 부분적으로 일시적으로 동시발생(coincide)할 수 있도록, 폴링 간격을 조절하는 것이다. 예를 들어, 한 가지 방식은, 모바일 애플리케이션의 세트의 본래의 폴링 간격들(또는 디폴트 폴링 간격들)의 공통 인수 또는 공통 분모의 배수이도록 간격을 조절하고 설정하는 것이다. 상기의 예의 경우, 이러한 사용되는 분모는 3분(min.)이고, 폴링 간격은 3분의 배수이도록 조절될 수 있으며, 필요에 따라, 일례로서, 이하와 같은 조절된 간격을 산출할 수 있다:

모바일 장치 또는 로컬 프록시가 각각의 서비스의 긴급함을 결정할 수 있으며, 트위터(Twitter)에 대해 약 4분 내지 최대 6분을 결정하거나, 애플리케이션 유형 또는 시간 중요도(time criticality), 또는 그 밖의 다른 설정치(가령, 사용자 선호도)를 기반으로 하여, 전달 시간(delivery time)을 보장하기 위해 3까지로 압축할 수 있다. 또한 로컬 프록시는 공통 간격(common interval)이 반드시 가장 작은 간격(여기서, 3분)을 기초로 할 필요는 없으며, (가령, 사용자 선호도, 또는 애플리케이션 유형/행동, 또는 그 밖의 다른 우선순위/임계도 파라미터를 다시 기초로 하는 연장될 수 없는 가장 작은 간격을 의미하는) 가장 작은 하드 간격(hard interval)을 기초로 함을 보장할 수 있다. 이러한 예에서, 트위터, 또는 시간 임계 콘텐츠를 갖는 또 다른 애플리케이션 또는 높은 우선순위 애플리케이션에 대한 전달 시간 요건은, 로컬 프록시가 모든 간격이 4분을 기초로 하도록 설정하게 할 수 있음으로써, 트위터 요건이 충족되고, 다른 간격은 내림되기보다는 올림되어, 자원이 보존됨을 보장할 수 있다.

덧붙이자면, 로컬 프록시는 (t₀)에 대한 값, 즉, 다양한 서비스들 간의 각각의 폴에 대한 상호 시작점을 결정할 수 있다. 로컬 프록시가 이 데이터를 다시 서비스로 되돌려 전달할 때, 데이터 도달에 딜레이가 있을 수 있고 딜레이는 서비스별로 달라질 수 있다. 동기화를 유지하기 위해, 로컬 프록시는 현재 시점(present time)으로서 (t₀)를 사용할 수 없고, 대신, 시작시점을 서비스들 간에 시간상 동일한 절대 점으로 고정시킬 수 있다.

일반적으로 서버들은 UTC 내에 있고, NTP를 사용하여 동시간대를 유지할 수 있으며, 이로써 이 문제를 해결하는 한 가지 방법이 제공된다. 예를 들어, 로컬 프록시가 분 마크(minute mark)를 선택하고, 이를 원격 프록시(프록시 서버)로 전달할 수 있다. 이러한 분 마크는 랜덤일 수 있으며, 선택된 마크는 이러한 마크의 다음번 발생에서, 모든 서비스가 사용할 수 있는 기초가 될 수 있다(즉: 13). 분 마크는 장래에 최대 59분만큼 멀어질 수 있고, 59분 동안 폴링하지 않는 것의 딜레이 또는 비효율성을 피하기 위해, 서비스는 t₀에서부터 다시, 임의의 필요한 폴링 간격도 계산할 수 있다.

로컬 프록시가 원격 프록시 상의 서비스에게 데이터 버스트 스케줄(가령, 조절된 간격 및/또는 시작점)을 전달했으면, 특정 간격에서 모바일 클라이언트를 대신하여 폴을 시작하는 것뿐 아니라, 특정 간격에서 수신된 데이터가 모바일 장치로 다시 전송됨을 확인하는 것은 원격 프록시에게 달려 있다. 적어도 일부 시간에서 정렬된 버스트로 데이터를 전송할 준비가 됐음을 확인하기 위해, 서비스는 과거에서부터의 평균 폴링 시간을 이용할 수 있다. 본원에 기재된 로직은 하나의 폴 내에서 클라이언트에게 전송될 새로운 데이터를 발견한 경우, 복수의 서비스가 모바일 장치(로컬 프록시)로의 그들의 통신(communication)을 정렬할 확률을 상당히 개선할 수 있다.

추가 예:

통지 기반 서비스(notification based service): 야후!, 또는 실시간 통지를 포함하는 그 밖의 다른 모바일 클라이언트가 임의의 시점에서 통지를 수신할 수 있다. 통지를 다루는 추가적인 방식이 존재한다:

실시간 통지 요건을 충족시키기 위해, 애플리케이션은 폴링하고 데이터를 즉시 전송하며, 조절된 폴링 간격을 이용하고, 다른 데이터를 갖는 수신된 응답을 추가로 정렬하는 플랜에 따라 다음번 배경 폴을 정렬할 수 있다.

애플리케이션 폴러(application poller)가 새로운 전자메일에 대해 폴링하고, 가장 이른 공유 간격(이는, 예를 들어, 디폴트/본래 폴링 간격으로부터 한 번에 3분씩 뒤로 감으로써, 계산될 수 있다)에서 클라이언트에게 이를 전송하는 것을 스케줄링할 수 있도록, 로컬 프록시가 모든 서비스에게 간격의 공통된 기저(상기의 예의 경우, 3분)를 전달한다.

트래픽 카테고리화 및 정책

일부 실시예에서, 본원발명의 프록시 시스템은, 캐싱 및/또는 성형(shape)하기 위한 트래픽(데이터, 콘텐츠, 메시지, 업데이트 등)을 선택하기 위한 정책을 확립할 수 있다. 덧붙이자면, 네트워크 요청을 하는 애플리케이션의 관찰, 또는 애플리케이션으로부터의 명시적 정보(explicit information)의 수집, 또는 애플리케이션이 도달하는 네트워크 도착지에 대한 인지로부터 도출된 정보를 조합함으로써, 본원발명의 기술은 전송되는 트래픽이 속하는 카테고리를 결정하거나, 추론할 수 있다.

예를 들어, 하나의 실시예에서, 모바일 또는 무선 트래픽은, (a1) 상호대화 트래픽, 또는 (a2) 배경 트래픽으로 카테고리화될 수 있다. 차이점은, (a1)에서, 사용자는 응답을 적극적으로 기다리지만, (a2)에서 사용자는 응답을 기대하지 않는다. 이러한 카테고리화는 두 번째 유형의 카테고리화와 함께, 또는 대신하여, 사용될 수 있고, 두 번째 유형의 카테고리는 다음과 같다: (b1) 즉시(immediate), (b2) 낮은 우선순위, (b3) 요청하는 애플리케이션이 전경(foreground)에 있고 액티브 상태인 경우, 즉시.

예를 들어, 새로운 업데이트, 메시지, 또는 전자메일은, 즉시 전달될 (b1) 카테고리에 속할 수 있지만, 여전히 (a2) 배경 트래픽이다(사용자는 이를 적극적으로 기다리지 않는다). 활성 챗 세션(active chat session) 밖으로 나올 때, 유사한 카테고리화가 인스턴트 메시지(instant message)에 적용된다. 활성 챗 세션 동안 사용자는 응답이 더 빠를 것을 기대한다. 이러한 사용자 기대는 결정되거나 추론되며, 트래픽 카테고리화 및 정책 이행을 수행함에 있어서 네트워크 사용과 장치 자원을 최적화할 때, 요인으로 고려된다.

기재된 카테고리화 스킴의 적용의 일부 예로는, (a1) 상호대화 트래픽이 (b1) 즉시(immediate)로 카테고리화되지만, (a2) 배경 트래픽은 (b2) 또는 (b3)일 수도 있다. 낮은 우선순위 전송(transfer)의 예로는 전자메일 또는 메시지 유지관리 트랜잭션, 가령, 전자메일 또는 그 밖의 다른 메시지 삭제하기, 또는 메일 또는 애플리케이션 서버에서 읽힐 때 전자메일에 표시하기 트랜잭션이 있다. 일반적으로 이러한 전송은 (a) 타이머가 타임아웃 값(가령, 2분)을 초과하는 때, 및 (b) 데이터가 그 밖의 다른 목적으로 전송될 때 중에서 더 이른 때 발생할 수 있다.

(b3)의 예로는 IM 프레즌스(presence) 업데이트, 주식 시세 표시기 업데이트, 날씨 업데이트, 상태 업데이트, 뉴스 피드(news feed)가 있다. 애플리케이션의 UI가 전경(foreground)에 있거나, 및/또는 액티브 상태일 때(가령, 장치/폰의 백라이트에 의해 지시되거나, 그 밖의 다른 센서의 상태로부터 결정 또는 추론되는 바와 같이), 업데이트는, 서버가 장치로 푸시(push)될 임의의 것을 가질 때마다 즉시 될 것이라고 여겨질 수 있다. 애플리케이션이 전경에 있지 않거나 액티브 상태가 아닐 때, 이러한 업데이트는, 애플리케이션이 전경으로 오고 액티브 상태가 될 때까지 억제될 수 있다.

일부 실시예에서, 네트워크는 (a1) 상호대화 트래픽과 (a2) 배경 트래픽에 대해 동시에 선택되거나 최적화될 수 있다.

일부 실시예에서, 무선 장치 또는 모바일 장치 프록시는 (서버 프록시와 별도로, 또는 함께) 트래픽을, (예를 들어) (a1) 상호대화 트래픽, 또는 (a2) 배경 트래픽으로 카테고리화할 수 있기 때문에, 서로 다른 유형의 트래픽에 서로 다른 정책을 적용할 수 있다. 이는, 내부적으로 (a1)과 (a2) 트래픽에 대해 서로 다르게 동작할 수 있음을 의미한다(이는, 예를 들어, 상호대화 트래픽이 네트워크를 전체적으로 또는 부분적으로 통과하게 하고, 배경 트래픽에는 더 엄격한 트래픽 제어를 적용함으로써, 또는 장치 측이 서버로부터 호스트의 콘텐츠가 업데이트됐다는 정보를 수신했을 때만 라디오를 활성화시키는 요청을 허용하는 등에 의해 이뤄진다).

요청이 무선 네트워크를 통한 액세스를 요구할 때, 본원발명의 기술은 라디오 레이어(radio layer)에게, 서로 다른 트래픽에 서로 다른 네트워크 설정을 적용할 것을 요청할 수 있다. 트래픽과 네트워크의 유형에 따라서, 이는 다음의 여러 다른 수단에 의해 달성될 수 있다:

(1) (a1)에 대해 3G/4G, (a2)에 대해 2G/2.5G를 이용하기;

(2) 서로 다른 데이터 세트에 대해 네트워크 설정을 명시적으로 특정하기(가령, FACH(forward access channel) vs. DCH(dedicated channel)의 사용 관점에서, 또는 배경 트래픽에 대한 더 낮은/더 높은 네트워크 효율의 데이터 전송 속도(data rate)를 그 밖의 다른 방식으로 요청하기), 또는

(3) 서로 다른 데이터 세트에 대해 서로 다른 네트워크 액세스 포인트를 이용하기(상기 (1) 및 (2)와 유사하게 네트워크 자원을 서로 다르게 이용하도록 설정될 액세스 포인트).

덧붙이자면, 3GPP 빠른 휴면(Fast Dormancy)은, 애플리케이션, 운영 체제, 또는 모바일 장치가 장래에 더 효율적이 될 트래픽 유형을 알고 있도록 하는 개선을 요구한다. 트래픽 카테고리에 대한 지식을 갖고, 빠른 휴면을 이용할 수 있는 본원발명의 시스템의 실시예는 빠른 휴면에서 확인된 문제점을 해결할 수 있다. 이러한 방식으로, 모바일 또는 광대역 네트워크는, 배터리 소모량과 네트워크 시그널링 자원 모두에 부정적인 영향을 미치는 타협된 구성으로 구성될 필요가 없다.

폴링 스케줄

폴링 스케줄을 검출(또는 결정)함으로써, 프록시 서버(분산 캐시 시스템의 서버측)는 자신의 폴을 애플리케이션 폴과 가능한 가까이 둘 수 있다. 많은 애플리케이션이 (가령, 4시간마다, 또는 30초마다, 또는 또 다른 시간 간격으로) 스케줄링된 간격 폴링을 이용한다. 클라이언트 측 프록시는 시간 기준을 기초로 하여 자동 폴을 검출하고, 애플리케이션에 대한 자동 폴링 프로파일을 만들 수 있다. 예를 들어, 로컬 프록시가 요청(request)과 2, 3, 4, 또는 그 이상의 폴 사이의 시간 간격을 검출하려 시도하며, 시간 간격들이 모두, 각각 1초(또는 상대적 가까움에 대한 또 다른 기준) 내에 있는 경우, 자동 속도(automatic rate)를 결정한다. 그렇지 않은 경우, 클라이언트는 더 많은 개수의 폴링 이벤트(가령, 10-12개의 폴)로부터 데이터를 수집하고, 통계적 분석을 적용하여, 사용되는 평균 간격에 대한 값을 결정, 계산, 또는 추정할 수 있다. 폴링 프로파일은, 상기 폴링 프로파일이 사용되는 서버로 전달된다. 빈번한 수동 요청이 있는 경우, 로컬 프록시는 이를 비-중요 애플리케이션(non-critical application)에 대한 프로파일로부터 얻어진 이 애플리케이션에 대한 디폴트 간격으로 대체할 수 있다.

일부 실시예에서, 로컬 프록시(가령, 장치 측 프록시)가 애플리케이션/클라이언트 폴을 계속 모니터링하고, 폴링 간격을 업데이트할 수 있다. 현재 값에서 30%(또는 또 다른 지정 값/동적 값/조건적 값)보다 많이 변할 경우, 프록시 서버(가령, 서버 측 프록시)로 전달된다. 이 방식은, "로스트 인터레스트(lost interest)" 시나리오라고 일컬어질 수 있다. 일부 예에서, 로컬 프록시는 이러한 스케줄에서 벗어나 이뤄지는 요청을 인지하고, 이러한 요청을 "수동(manual)"이라고 간주할 수 있으며, 이들을 적절하게 처리할 수 있다.

애플리케이션 클래스/캐싱의 모드

일부 실시예에서, 애플리케이션은 3가지 캐싱 그룹 또는 모드로 구성될 수 있다. 각각의 모바일 클라이언트/애플리케이션은, 하나 이상의 조건에 따라서, 이들 모드 중 하나로서 다뤄지거나, 복수의 모드를 이용해 다뤄지도록 카테고리화될 수 있다.

A) 완전 캐싱됨(fully cached) - 프록시 서버가 로컬 프록시에게 업데이트하라고 할 때만 로컬 프록시가 업데이트한다(가령, 애플리케이션 요청을 애플리케이션 서버/콘텐츠 호스트에 의해 서비스될 네트워크를 통해 직접 전송한다). 이 모드에서, 로컬 프록시가 수동 요청을 무시할 수 있고, 프록시 서버는 애플리케이션 서버/콘텐츠 제공자에게 폴링하도록, 검출된 자동 프로파일을 사용한다(가령, 스포츠 점수 애플릿, 페이스북(Facebook), 10, 15, 30, 또는 그 이상의 폴).

B) 부분 캐싱됨(partially cached) - 로컬 프록시는 자동 요청(가령, 애플리케이션 자동 재생)을 위해 로컬 또는 내부 캐시를 이용하지만, 그 밖의 다른 스케줄링된 요청은 일부 수동 요청(가령, 전자메일, 다운로드, 이베이(Ebay) 또는 일부 페이스북(Facebook) 요청)을 거친다.

C) 캐싱되지 않음(가령, 실시간 주식 시세 표시기, 스포츠 점수/상태; 그러나 일부 경우, 15분 지연된 인용은 30초 스케줄에 안전하게 놓일 수 있다 - B 또는 심지어 A)

콘텐츠 변화율 및 데이터의 핵심 문자(critical character)를 기초로, 실제 애플리케이션 또는 캐싱 모드 분류가 결정될 수 있다. 디폴트로 분류되지 않은 애플리케이션은 클래스 C로 설정될 수 있다.

백라이트 및 액티브 애플리케이션

일부 실시예에서, 로컬 프록시는 장치 백라이트 상태를 검출함으로써 시작한다. 동일한 특징(signature)을 갖는 요청이, 요청이 향하는 본래 호스트 서버/콘텐츠 서버에게 폴링하는 중인 프록시 서버에 등록되는 경우, 스크린 라이트의 '꺼진 상태(off)'에 의해 만들어지는 요청이 로컬 캐시를 사용하기 위해 허용될 수 있다. 스크린 라이트가 켜진 상태인 경우, 배경 애플리케이션인지 여부를 판단하거나, 로컬 캐시의 엔트리가 상기 요청을 만족시키기 위해 사용될 수 있는지 또는 사용될 수 없는지에 대한 그 밖의 다른 지시자(indicator)에 대한 추가 검출이 이뤄질 수 있다. 식별될 때, 어느 로컬 엔트리가 사용될 수 있는지에 대한 요청이 스크린 라이트 꺼짐 상황과 동일하게 처리될 수 있다. 캐싱된 데이터가 요청을 프로세싱하도록 사용되기에 안전할 때 전경 요청(foreground request)이 앞서 언급된 애플리케이션 분류를 사용할 수 있다.

도 1A는 자원 보존을 위해 무선 네트워크(또는 광대역 네트워크)(106 또는 108) 내에서, 호스트 서버(100)가 클라이언트(가령, 모바일 장치, 임의의 무선 장치, 또는 클라이언트 장치(150)상의 클라이언트/애플리케이션)들과 애플리케이션 서버 또는 콘텐츠 제공자(110) 간 트래픽 관리, 콘텐츠 캐싱, 및/또는 자원 보존을 촉진하는 시스템의 예시적 다이어그램을 도시한다. 호스트 서버(100)는 추가로, 애플리케이션 거동(application behavior), 콘텐츠 우선순위, 사용자 활동(user activity), 및/또는 사용자 기대(user expectation)를 기초로 하여, 모바일 트래픽을 카테고리화, 및/또는 전달 정책(delivery policy)을 이행할 수 있다.

클라이언트 장치(150)는 다른 장치, 서버, 및/또는 그 밖의 다른 시스템(가령, 호스트 서버(100) 및/또는 애플리케이션 서버/콘텐츠 제공자(110))와 연결(가령, 유선, 무선, 셀룰러 연결)을 확립할 수 있는 임의의 시스템, 장치, 및/또는 임의의 장치/시스템 조합일 수 있다. 클라이언트 장치(150)는 일반적으로, 장치(150) 및/또는 호스트 서버(100) 및/또는 애플리케이션 서버/콘텐츠 제공자(110) 간에 교환되는 정보와 데이터를 제공하기 위해, 디스플레이 및/또는 그 밖의 다른 출력 기능을 포함할 것이다.

예를 들어, 클라이언트 장치(150)가 모바일, 핸드헬드, 또는 휴대용 장치, 무선 장치, 또는 비-휴대용 장치를 포함할 수 있고, 서버 데스크톱, 데스크톱 컴퓨터, 컴퓨터 클러스터, 또는 휴대용 장치(노트북, 랩톱 컴퓨터, 핸드헬드 컴퓨터, 팜톱 컴퓨터, 모바일 폰, 셀 폰, 스마트 폰, PDA, 블랙베리(Blackberry) 장치, 팜 장치, 핸드헬드 타블릿(가령, iPad 또는 그 밖의 다른 임의의 타블릿), 핸드헬드 콘솔, 핸드헬드 게임 장치 또는 콘솔, 임의의 수퍼폰(가령, iPhone), 및/또는 그 밖의 다른 임의의 휴대용, 모바일, 핸드헬드 장치, 또는 고정회선 무선 인터페이스(가령, M2M 장치) 등 중 임의의 것일 수 있다(그러나 이에 국한되지 않음). 하나의 실시예에서, 클라이언트 장치(150), 호스트 서버(100), 및 애플리케이션 서버(110)가 네트워크(106) 및/또는 네트워크(108)를 통해 연결된다. 일부 실시예에서, 장치(150) 및 호스트 서버(100)가 서로 직접 연결될 수 있다.

클라이언트 장치(150) 상의 입력 수단(input mechanism)은 터치 스크린 키패드(가령, 싱글 터치, 멀티 터치, 2D 또는 3D 제스처 감지, 등), 물리적 키패드, 마우스, 포인터, 트랙 패드, 모션 검출기(가령, 1축, 2축, 3축 가속도계 등), 광 센서, 커패시턴스 센서, 저항 센서(resistance sensor), 온도 센서, 근접도 센서(proximity sensor), 압전기 장치, 장치 배향 검출기(가령, 전자 나침반(electronic compass), 기울기 센서, 회전 센서, 자이로스코프(gyroscope), 가속도계), 또는 이들의 조합을 포함할 수 있다.

앞서 언급된 입력 수단 또는 그 밖의 다른 수단 중 하나 이상을 통해, 클라이언트 장치(150)에서의 사용자 활동을 지시하는, 수신되거나 검출된 신호가, 본원 발명의 기술에서 클라이언트 장치(150)에서의 상황 인지(context awareness)를 획득할 때 사용될 수 있다. 일반적으로, 클라이언트 장치(150)에서의 상황 인지는, 예를 들어, 클라이언트 장치(150) 동작 또는 상태 인정, 관리, 사용자 활도/행동/상호대화 인지, 검출, 감지, 추적, 추세, 및/또는 애플리케이션(가령, 모바일 애플리케이션) 유형, 행동, 활동, 동작 상태 등을 포함한다(그러나 이에 국한되지 않음).

본 발명에서의 상황 인지는 네트워크 측 상황 데이터(context data)의 지식 및 검출을 포함하고, 네트워크 정보, 가령, 네트워크 수용량, 대역폭, 트래픽, 네트워크/연결 유형, 및/또는 그 밖의 다른 임의의 동작 상태 데이터를 포함할 수 있다. 네트워크 측 상황 데이터는 (가령, 호스트 서버 및/또는 장치(150)에 의해) 네트워크 서비스 제공자(가령, 셀 제공자(cell provider)(112), 및/또는 인터넷 서비스 제공자)로부터 수신, 및/또는 질의 받을 수 있다. 클라이언트(150) 측에서 결정된 바의 애플리케이션 상황 인지에 추가로, 또한 애플리케이션 상황 인지는 (호스트(100) 및/또는 클라이언트 장치(150)에 의해) 각자의 애플리케이션/서버 제공자(110)로부터 수신되거나, 획득/질의 받을 수 있다.

클라이언트 장치(150)의 데이터 수요를 만족시키기 위해(가령, 애플리케이션, 또는 그 밖의 다른 임의의 요청(가령 HTTP 요청)을 만족시키기 위해) 시스템의 트래픽을 관리하기 위해, 호스트 서버(100)는, 예를 들어, 클라이언트 장치(150), 네트워크(106/108), 애플리케이션(가령, 모바일 애플리케이션), 애플리케이션 서버/제공자(110), 또는 이들의 임의의 조합에 대해 획득된 상황 정보를 사용할 수 있다. 하나의 실시예에서, 명시적 또는 비-명시적 사용자(103) 요청 및/또는 장치/애플리케이션 유지관리 작업에 응답하여 만들어진 데이터 요청을 만족시키기 위해, 호스트 서버(100)에 의해 트래픽이 관리된다. 효율적이고 효과적인 대역폭 활용을 위해 네트워크 소비량, 예를 들어, 셀룰러 네트워크의 사용량이 보존되도록 트래픽이 관리될 수 있다. 덧붙이자면, 성능과 사용자 경험을 여전히 최적화하면서 자원 보존의 일반적인 철학에 따라 장치(150) 측 자원의 사용(가령, 배터리 전력 소모, 라디오 사용, 프로세서/메모리 사용)이 최적화되도록, 호스트 서버(100)가 시스템에서 이러한 트래픽을 관리하고 조화시킬 수 있다.

예를 들어, 배터리 보존의 맥락에서, 장치(150)는 (예를 들어, 사용자 키스트로크, 백라이트 상태를 관찰하거나 하나 이상의 입력 수단을 통해 또 다른 신호를 관찰하는 등에 의해) 사용자 활동을 관찰하거나 장치(150) 행동을 바꿀 수 있다. 또한 장치(150)는 사용자 활동 또는 행동을 기초로 하여 네트워크 자원 소모에 대한 행동을 바꾸도록 호스트 서버(100)에 요청할 수 있다.

하나의 실시예에서, 호스트 서버(100)와 클라이언트 장치(150) 간의 분산 시스템을 이용해 자원 보존을 위한 트래픽 관리가 수행된다. 상기 분산 시스템은 서버 측(100)과 장치/클라이언트 측 상에서 프록시 서버와 캐시 구성요소를 포함할 수 있으며, 예를 들면, 서버(100) 측 상의 서버 캐시(135)와 클라이언트(150) 측 상의 로컬 캐시(185)가 있다.

네트워크(가령, 네트워크(106 및/또는 108))와 장치(150)에서의 자원 보존을 위한 상황 인지 트래픽 관리를 위해 개시된 기능 및 기법이 분산 프록시 및 캐시 시스템내에 있다. 프록시 및 캐시 시스템은 특정 클라이언트 장치(150) 및/또는 호스트 서버(100) 상에 분산 위치될 수 있다. 분산 프록시 및 캐시 시스템은 도 1B에 도시된 예시적 다이어그램을 추가로 참조하여 도시된다. 클라이언트 장치(150) 내 프록시 및 캐시 구성요소, 호스트 서버(100), 및 이들 내 관련 구성요소에 의해 수행되는 기능 및 기법이 도 2-3의 예를 추가로 참조하여 상세히 설명된다.

하나의 실시예에서, 클라이언트 장치(150)는 네트워크(106)를 통해 호스트 서버(100) 및/또는 애플리케이션 서버(110)와 통신하며, 상기 네트워크(106)는 셀룰러 네트워크 및/또는 광대역 네트워크일 수 있다. 네트워크(대역폭 이용률) 및 장치 자원(가령, 배터리 소모)을 구현하도록, 장치(150)와 다양한 애플리케이션 서버/콘텐츠 제공자(110) 간의 전체 트래픽 관리를 촉진하기 위해, 호스트 서버(100)가 네트워크(108)를 통해 애플리케이션 서버/제공자(110)와 통신할 수 있으며, 상기 네트워크(108)는 인터넷(가령, 광대역 네트워크)를 포함할 수 있다.

일반적으로, 클라이언트 장치(150), 호스트 서버(100), 및/또는 애플리케이션 서버(100)가 통신하는 네트워크(106 및/또는 108)는 셀룰러 네트워크, 광대역 네트워크, 전화 네트워크, 공개 네트워크(open network)(가령, 인터넷), 또는 비공개 네트워크(가령, 인트라넷(intranet) 및/또는 익스트라넷(extranet)), 또는 이들의 임의의 조합일 수 있다. 예를 들어, 인터넷은, 임의의 알려진 또는 편리한 프로토콜(가령, TCP/IP 프로토콜, UDP, HTTP, DNS, FTP, UPnP, NSF, ISDN, PDH, RS-232, SDH, SONET 등)를 통해 파일 전송, 원격 로그인, 전자메일, 뉴스, RSS, 클라우드 기반 서비스, 인스턴트 메시징, 비주얼 보이스메일(visual voicemail), 푸시 메일, VoIP, 및 그 밖의 다른 서비스를 제공할 수 있다.

네트워크(106 및/또는 108)는, 클라이언트 장치(150)와 호스트 서버(100)에게 연결성(connectivity)을 제공하기 위해 전체적으로 또는 부분적으로 함께 동작하는 개별 네트워크들의 임의의 집합일 수 있으며, 서비스되는 시스템 및 장치에게 하나 이상의 네트워크로 보일 수 있다. 하나의 실시예에서, 클라이언트 장치(150)와의 통신이, 공개 네트워크, 가령 인터넷, 또는 비공개 네트워크, 광대역 네트워크, 가령, 인트라넷 및/또는 익스트라넷에 의해 이뤄질 수 있다. 하나의 실시예에서, 통신은, 보안 통신 프로토콜, 가령, 보안 소켓 계층(SSL: secure sockets layer), 또는 전송 계층 보안(TLS: transport layer security)에 의해 이뤄질 수 있다.

덧붙이자면, 통신은, 하나 이상의 네트워크, 가령, WiMax, LAN(Local Area Network), WLAN(Wireless Local Area Network), PAN(Personal area network), CAN(Campus area network), MAN(Metropolitan area network), WAN(Wide area network), WWAN(Wireless wide area network), 또는 임의의 광대역 네트워크(그러나 이에 국한되지 않음)를 통해, 이뤄지고, 예를 들어, GSM(Global System for Mobile Communication), PCS(Personal Communications Service), Bluetooth, WiFi, 고정회선 무선 데이터(Fixed Wireless Data), 2G, 2.5G, 3G, 4G, IMT-Advanced, pre-4G, LTE Advanced, 모바일 WiMax, WiMax 2, WirelessMAN-Advanced 네트워크, EDGE(enhanced data rates for GSM evolution), GPRS(general packet radio service), enhanced GPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA, UMTS-TDD, 1xRTT, EV-DO, 메시징 프로토콜(가령, TCP/IP, SMS, MMS, XMPP(extensible messaging and presence protocol), RTMP(real time messaging protocol), IMPP(instant messaging and presence protocol), 인스턴트 메시징, USSD, IRC), 또는 그 밖의 다른 임의의 무선 데이터 네트워크, 광대역 네트워크, 또는 메시징 프로토콜 등의 기법에 의해 더 활성화된다.

도 1B는 자원 보존 및 콘텐츠 캐싱을 위해, 장치(150)와 애플리케이션 서버/콘텐츠 제공자(100)(가령, 소스 서버) 간의 네트워크 트래픽 관리를 촉진시키며, 호스트 서버(100)와 장치(150) 사이에 분산되는 프록시 및 캐시 시스템의 예시적 다이어그램을 도시한다. 호스트 서버(100)와 장치(150) 사이에 분산된 프록시 시스템은 추가로, 애플리케이션 거동, 콘텐츠 우선순위, 사용자 활동, 및/또는 사용자 기대를 기초로 하여, 모바일 트래픽을 카테고리화하고, 및/또는 전달 정책을 구현할 수 있다.

분산 프록시 및 캐시 시스템은, 예를 들어, 프록시 서버(125)(가령, 원격 프록시) 및 서버 캐시(135) 구성요소를 서버 측에서 포함할 수 있다. 서버 측 프록시(125) 및 캐시(135)는, 호스트 서버(100) 내부에 상주할 수 있다. 덧붙이자면, 서버 측상의 프록시 서버(125)와 캐시(135)는 호스트 서버(100) 외부에 부분적으로 또는 전체적으로 위치할 수 있고, 네트워크(106 및 108) 중 하나 이상을 통해 통신할 수 있다. 예를 들어, 프록시 서버(125)는 호스트 서버 외부에 있고, 서버 캐시(135)는 호스트 서버(100)에 유지될 수 있다. 또는, 서버 캐시가 호스트 서버(100) 외부에 위치하는 동안 프록시 서버(125)가 호스트 서버(100) 내에 있을 수 있다. 덧붙이자면, 프록시 서버(125)와 캐시(135) 각각은 부분적으로 호스트 서버(100) 내부에 위치하고 부분적으로 호스트 서버(100) 외부에 위치할 수 있다.

분산 시스템은, 하나의 실시예에서, 클라이언트 측 구성요소도 포함할 수 있으며, 제한받지 않는 예를 들면, 로컬 프록시(175)(가령, 모바일 장치 상의 모바일 클라이언트), 및/또는 장치(150)(가령, 모바일 장치) 내부에 상주하는 로컬 캐시(185)가 있다.

덧붙이자면, 클라이언트 측 프록시(175)와 로컬 캐시(185)가 부분적으로 또는 전적으로 장치(150) 외부에 있을 수 있으며, 네트워크(106 및 108) 중 하나 이상을 통해 통신한다. 예를 들어, 로컬 프록시(175)는 장치(150) 외부에 있을 수 있고, 로컬 캐시(185)는 장치(150)에서 유지될 수 있다. 또는, 로컬 프록시(175)가 장치(150) 내에 있고, 로컬 캐시(185)가 장치(150) 외부에 있을 수 있다. 덧붙이자면, 프록시(175)와 캐시(185) 각각은, 부분적으로 호스트 서버(100) 내부에 있고, 부분적으로 호스트 서버(100) 외부에 있을 수 있다.

하나의 실시예에서, 분산 시스템은 선택사항적 캐싱 프록시 서버(199)를 포함할 수 있다. 상기 캐싱 프록시 서버(199)는 애플리케이션 서버/콘텐츠 제공자(110), 또는 네트워크 서비스 제공자(112), 또는 이들의 임의의 조합에 의해, 네트워크 및 장치 자원을 보존하도록 네트워크 트래픽 관리를 촉진하기 위해 동작되는 구성요소일 수 있다. 예를 들어, 애플리케이션 서버/제공자(110), 호스트 서버(100) 및/또는 네트워크 서비스 제공자(112) 중 하나 이상으로부터 캐싱 콘텐츠가 장치(150)로 제공되도록 프록시 서버(199)가 사용될 수 있다. 장치(150)에서의 애플리케이션 요청 또는 그 밖의 다른 데이터 요청을 만족시키도록, 콘텐츠 캐싱이 원격 프록시(125)에 의해 전적으로 또는 부분적으로 수행될 수 있다.

네트워크(가령, 셀룰러 네트워크 또는 그 밖의 다른 무선 네트워크)에서의 자원 보존을 위한 상황 인지 트래픽 관리 및 최적화에서, 모바일 장치(가령, 임의의 무선 장치)(150)에서의 사용자 활동/행동의 특성 및/또는 애플리케이션 거동이, 로컬 프록시(175)에 의해 추적되고, 네트워크(106)를 통해 호스트 서버(100) 내 프록시 서버(125) 구성요소로, 예를 들면, 연결 메타데이터로서 전달될 수 있다. 그 후, 프록시 서버(125)는 애플리케이션 서버/제공자(110)로 연결되고, 콘텐츠 및 데이터를 제공하여, 장치(150)로부터의 요청을 만족시킬 수 있다.

덧붙이자면, 로컬 프록시(175)는 모바일 장치 속성(가령, 배터리 잔량, 장치가 등록된 네트워크, 라디오 상태, 또는 모바일 장치가 사용되는 중인지 여부(가령, 사용자와 상호대화 중인지 여부) 중 하나 이상)을 식별하고 불러올(retrieve) 수 있다. 일부 경우, 로컬 프록시(175)는, 프록시 서버(125)로 전송하기 전에 적절하게 데이터를 지연, 우선시(선-인출(prefetch)), 및/또는 수정할 수 있으며, 도 2-3의 예시와 관련하여 이하에서 더 상세히 설명될 것이다.

로컬 데이터베이스(185)는 로컬 프록시(175)에 포함되거나 로컬 프록시(175)로 연결될 수 있고, 데이터 요청이 프록시 서버(125)로 포워딩되기 전에, 데이터 요청에 대한 로컬-저장된 응답이 질의될 수 있다. 로컬-캐싱된 응답은 로컬 프록시(175)에 의해 사용되어, 캐싱된 콘텐츠가 여전히 유효(valid)할 때 캐시 저장소(185)에 저장된 캐싱된 콘텐츠를 불러옴으로써, 모바일 장치(150)의 특정 애플리케이션 요청을 만족시킬 수 있다.

마찬가지로, 호스트 서버(100)의 프록시 서버(125)는 로컬 프록시로부터의 데이터를 콘텐츠 소스(가령, 애플리케이션 서버/콘텐츠 제공자(110))로 전송하기 전에 지연, 우선시, 또는 수정할 수 있다. 덧붙이자면, 프록시 서버(125)는 장치 속성 및 연결 메타데이터를 사용하여, 모바일 장치(150) 상의 애플리케이션의 요청을 만족시키기 위한 규칙을 생성할 수 있다. 프록시 서버(125)는, 모바일 장치(150) 또는 또 다른 모바일 장치와의 유사한 연결을 최적할 때 추후 사용하기 위해 애플리케이션의 요청에 대한 실시간 트래픽 정보를 수집할 수 있다.

일반적으로, 로컬 프록시(175)와 프록시 서버(125)는 모바일 장치 상에서 실행되는 복수의 애플리케이션에 투명(transparent)하다. 로컬 프록시(175)는 모바일 장치의 운영 체제 또는 플랫폼에 투명한 것이 일반적이며, 장치 제조업체-특정적이거나 장치 제조업체-특정적이 아닐 수 있다. 일부 경우, 선택사항으로서, 로컬 프록시(175)는 부분적으로 또는 전적으로 장치 특정적이도록 맞춤 구성(customizable)될 수 있다. 일부 실시예에서 로컬 프록시(175)는 무선 모델, 방화벽 및/또는 라우터에 내장될 수 있다.

하나의 실시예에서, 일부 경우, 호스트 서버(100)는, 가령, 네트워크 서비스 제공자에 의해 제공되는 것과 같은, 네트워크 트래픽 관리를 획득할 때 장치(150)와 통신하는 단문 메시지 서비스 센터(SMSC)(112)의 저장 및 포워드(store and forward) 기능을 이용한다. 112는 그 밖의 다른 임의의 유형의 대안적 채널, 가령, USSD, 또는 그 밖의 다른 네트워크 제어 수단을 이용할 수 있다. 도 3의 예를 참조하여 추가로 설명되겠지만, 장치(150)가 이용 가능하다면 장치(150)로 자동으로 포워딩되고, 장치(150)가 현재 이용가능하지 않다면 나중에 포워딩되도록, 호스트 서버(100)는 콘텐츠 또는 HTTP 응답을 SMSC(112)로 포워딩할 수 있다.

일반적으로, 본원 발명의 분산 프록시 및 캐시 시스템은, 예를 들어, 로컬 캐시(185)로부터의 요청을 서비스함으로써 네트워크 이용의 최적화를 가능하게 하고, 로컬 프록시(175)는 네트워크(106)를 통해 만족될 필요가 있는 요청의 개수를 감소시킨다. 덧붙이자면, 로컬 프록시(175) 및 프록시 서버(125)는 통신된 데이터로부터 무관한 데이터를 필터링할 수 있다. 덧붙이자면, 또한 로컬 프록시(175) 및 프록시 서버(125)는 낮은 우선순위 데이터를 축적하고, 이를 일괄적으로(in batch) 전송하여, 개별 데이터 프래그먼트를 전송하는 프로토콜 오버헤드를 피한다. 로컬 프록시(175) 및 프록시 서버(125)는 또한 트래픽을 압축 또는 트랜스코딩(transcode)하여, 네트워크(106 및/또는 108)를 통해 전송되는 데이터의 크기를 감소한다. 네트워크가 덜 사용되고 개별 애플리케이션들 간에 네트워크 트래픽이 동기화될 수 있음으로써, 네트워크(106 및/또는 108)에서의 시그널링 트래픽이 감소될 수 있다.

모바일 장치(150)의 배터리 수명과 관련하여, 로컬 캐시(185)로부터의 애플리케이션 또는 콘텐츠 요청을 서비스함으로써, 로컬 프록시(175)는 라디오 모듈이 켜지는(power up) 횟수를 감소시킬 수 있다. 로컬 프록시(175)와 프록시 서버(125)는, 낮은 우선순위 데이터를 축적하고, 라디오가 켜지는 횟수 및/또는 시간을 감소시키도록 상기 데이터를 일괄적으로 전송하기 위해 결합하여 동작할 수 있다. 로컬 프록시(175)는 모든 연결에 대해 동시에 일괄 방식 데이터 전송을 수행함으로써 네트워크 사용을 동기화할 수 있다.

도 2A는 자원 보존, 콘텐츠 캐싱, 및/또는 트래픽 관리를 위해 무선 네트워크의 트래픽을 관리하는 장치(250)에 위치하는 분산 프록시 및 캐시 시스템 내 클라이언트-특 구성요소의 일례를 도시하는 블록도를 도시한다. 클라이언트 측(client-side) 프록시(또는 로컬 프록시(275))는 추가로 모바일 트래픽을 카테고리화하고, 및/또는 애플리케이션 거동, 콘텐츠 우선순위, 사용자 활동, 및/또는 사용자 기대를 기초로 하는 전달 정책(delivery policy)을 구현할 수 있다.

휴대용 전화기와 같은 휴대용 또는 모바일 장치(가령, 임의의 무선 장치)일 수 있는 장치(250)는, 예를 들어, 네트워크 인터페이스(208), 운영 체제(204), 상황 API(206), 및 모바일 애플리케이션을 포함하며, 프록시-비인지형(proxy-unaware)(210)이거나 프록시-인지형(proxy-aware)(220)일 수 있는 것이 일반적이다. 장치(250)는 도 2의 예에서 특정하게 모바일 장치로서 도시되지만, 이렇게 한정되는 것은 아니며, 장치(250)는 유선 네트워크 또는 무선 네트워크를 포함해 네트워크(가령, WiFi, 셀룰러, 블루투스, LAN, WAN 등)를 통한 데이터 요청을 만족시키기 위해 신호를 수신하고 송신할 수 있는 임의의 무선, 광대역, 휴대용/모바일 또는 비-휴대용 장치일 수 있다.

네트워크 인터페이스(208)는 장치(250)가 네트워크에서 호스트 및 외부 개체에 의해 지원되는 임의의 알려진 및/또는 종래의 통신 프로토콜을 통해, 호스트 서버(250) 외부에 있는 개체와 데이터를 중재(mediate)할 수 있도록 해주는 네트워킹 모듈일 수 있다. 상기 네트워크 인터페이스(208)는, 네트워크 어댑터 카드(network adaptor card), 무선 네트워크 인터페이스 카드(가령, SMS 인터페이스, WiFi 인터페이스, 2G, 3G, 3.5G, 4G, LTE, 등(그러나 이에 국한되지 않음)의 다양한 세대의 모바일 통신 표준을 위한 인터페이스), 블루투스, 또는 연결이 라우터를 거치는지의 여부에 무관하게, 액세스 포인트, 무선 라우터, 스위치, 멀티레이어 스위치, 프로토콜 컨버터, 게이트웨이, 브리지, 브리지 라우터, 허브, 디지털 미디어 수신기, 및/또는 리피터(repeater)를 포함할 수 있다.

장치(250)는, 로컬 프록시(275)(가령, 모바일 장치의 모바일 클라이언트) 및 캐시(285)를 포함할 수 있는 분산 프록시 및 캐시 시스템의 클라이언트 측(client-side) 구성요소를 더 포함할 수 있다. 하나의 실시예에서, 로컬 프록시(275)는 사용자 활동 모듈(215), 프록시 API(225), 요청/트랜잭션 관리기(235), 애플리케이션 프로토콜 모듈(248)을 갖는 캐싱 정책 관리기(245), 트래픽 성형 엔진(traffic shaping engine)(255), 및/또는 연결 관리기(265)를 포함한다. 트래픽 성형 엔진(255)은 정렬 모듈(alignment module)(256) 및/또는 일괄처리 모듈(batching module)(257)을 더 포함할 수 있고, 연결 관리기(265)는 라디오 제어기(266)를 더 포함할 수 있다. 요청/트랜잭션 관리기(235)는 애플리케이션 거동 검출기(application behavior detector)(236) 및/또는 우선순위화 엔진(prioritization engine)(241)을 더 포함할 수 있고, 애플리케이션 거동 검출기(236)는 패턴 검출기(237) 및/또는 애플리케이션 프로파일 생성기(239)를 더 포함할 수 있다. 이보다 더 많거나 더 적은 구성요소/모듈/엔진이 로컬 프록시(275) 및 각각의 예시적 구성요소에 포함될 수 있다.

본원에서 사용될 때, "모듈", "관리기", "핸들러", "검출기", "인터페이스", "제어기", "정규화기(normalizer)", "생성기", "무효화기(invalidator)", 또는 "엔진"은 범용, 전용, 또는 공유 프로세서를 포함하고, 일반적으로 프로세서에 의해 실행되는 펌웨어 또는 소프트웨어 모듈을 포함한다. 구현예 특정적, 또는 그 밖의 다른 고려사항에 따라, 모듈, 관리기, 핸들러, 검출기, 인터페이스, 제어기, 정규화기, 생성기, 무효화기, 또는 엔진이 중앙 집중(centralize)되거나, 각자의 기능들이 분산될 수 있다. 모듈, 관리기, 핸들러, 검출기, 인터페이스, 제어기, 정규화기, 생성기, 무효화기, 또는 엔진은, 프로세서에 의해 실행되기 위해 컴퓨터-판독형(저장) 매체로 구현되는 범용 또는 특수 하드웨어, 펌웨어, 또는 소프트웨어를 포함할 수 있다.

본원에서 사용될 때, 컴퓨터 판독형 매체, 또는 컴퓨터 판독형 저장 매체는 법령(가령, 미국에서는, 35 U.S.C. 101)으로 명시된 모든 매체를 포함하며, 컴퓨터 판독형(저장) 매체를 포함하는 청구항이 유효하기 위한 범위까지 모든 비법정 매체는 특정하게 배제하는 것으로 의도된다. 알려진 법정 컴퓨터 판독형 매체는 하드웨어(가령, 레지스터, 랜덤 액세스 메모리(RAM), 비휘발성(NV) 저장장치 등)를 포함하지만, 이러한 하드웨어로 반드시 한정되는 것은 아니다.

하나의 실시예에서, 분산 프록시 및 캐시 시스템의 네트워크 트래픽 관리용 부분은 로컬 프록시(275)(모바일 클라이언트) 및/또는 캐시(285)를 포함하는 장치(250) 내에 있거나, 상기 장치(250)와 통신할 수 있다. 로컬 프록시(275)는 사용자가 장치 애플리케이션 및 서비스(가령, 전자메일, IM, 음성 메일, 시각 음성메일(visual voicemail), 피드, 인터넷, 게임, 생산성 툴(productivity tool), 또는 그 밖의 다른 애플리케이션 등)를 액세스할 수 있도록 하는 장치(250) 상의 인터페이스를 제공할 수 있다.

프록시(275)는 일반적으로 애플리케이션 독립적이며, 원격 서버(가령, 도 1A-1B의 예에서 서버(100), 및/또는 도 1B 및 도 3A의 예에서 서버 프록시(125/325))로의 TCP 연결을 개방하기 위해 애플리케이션(가령, 프록시-인지형 및 프록시-비인지형 애플리케이션(210 및 220) 둘 모두, 또는 모바일 애플리케이션)에 의해 사용될 수 있다. 일부 경우, 로컬 프록시(275)는, 선택사항으로서 프록시-인지형 애플리케이션(220)(또는 모바일 장치(가령, 임의의 무선 장치) 상의 애플리케이션(가령 모바일 애플리케이션))과 인터페이싱하도록 사용될 수 있는 프록시 API(225)를 포함한다.

일반적으로, 애플리케이션(210 및 220)은 임의의 사용자 애플리케이션, 위젯(widget), 소프트웨어, HTTP-기반 애플리케이션, 웹 브라우저, 비디오 또는 그 밖의 다른 멀티미디어 스트리밍 또는 다우로딩 애플리케이션, 비디오 게임, 소셜 네트워크 애플리케이션, 전자메일 클라이언트, RSS 관리 애플리케이션, 애플리케이션 상점(application store), 문서 관리 애플리케이션, 생산성 강화 애플리케이션 등을 포함할 수 있다. 애플리케이션은 장치 제조업체에 의해, 또는 네트워크 서비스 제공자에 의해, 장치 OS와 함께 제공되거나, 사용자에 의해 다운로드되거나, 그 밖의 다른 방식으로 제공될 수 있다.

한 실시예의 로컬 프록시(275)는 도시된 바와 같이 상황 API(206)를 포함하거나, 상기 상황 API(206)로 연결된다. 상황 API(206)는 운영 체제(204) 또는 장치 플랫폼의 일부이거나, 도시된 것처럼 운영 체제(204)에 독립적일 수 있다. 운영 체제(204)는 임의의 운영 체제를 포함할 수 있으며, 제한되지 않는 예를 들면, Windows Mobile, iOS, Android, Symbian, Palm OS, Brew MP, Java 2 Micro Edition (J2ME), Blackberry, 등의 임의의 과거, 현재, 및/또는 미래 버전/판일 수 있다.

상황 API(206)는 장치(205)의 운영 체제(204) 또는 특정 클라이언트/애플리케이션의 플러그-인(plug-in)일 수 있다. 상황 API(206)는 사용자 또는 장치 활동(가령, 모션, 제스처, 장치 위치, 장치 위치의 변화, 장치 백라이트, 키스트로크(keystroke), 클릭, 활성된 터치 스크린, 마우스 클릭의 감지 또는 그 밖의 다른 포인터 장치의 검출)을 나타내는 신호를 검출할 수 있다. 상황 API(206)는 장치(250) 상의 입력 장치 또는 센서로 연결되어, 이들 신호를 식별할 수 있다. 일반적으로 이러한 신호는, 장치(250)의 입력 장치/수단에서의 명시적 사용자 입력(explicit user input)에 응답하여 수신된 입력, 및/또는 장치(250)에서 또는 그 주변에서 검출된 주변 신호/상황 큐(contextual cue)(가령, 빛, 모션(motion), 압전기 등)로부터 수집된 입력을 포함할 수 있다.

하나의 실시예에서, 장치(250)에서의 사용자 활동의 특성을 식별, 결정, 추론, 검출, 계산, 예측, 및/또는 예상하기 위해, 사용자 활동 모듈(215)은 상황 API(206)와 상호대화한다. 사용자 활동의 특성에 대한 프로파일을 생성하기 위해, 상황 API(206)에 의해 수집된 다양한 입력이 사용자 활동 모듈(215)에 의해 집합화(aggregate)될 수 있다. 이러한 프로파일은 다양한 시간적 특성(temporal characteristic)을 갖고 사용자 활동 모듈(215)에 의해 생성될 수 있다. 예를 들어, 특정 경우 특정 시간(가령, 시간 윈도(time window)로 지정된 시간, 마지막 1분, 마지막 30초 등)에서 사용자가 하고 있는 것 또는 하지 않는 것의 뷰를 제공하기 위해, 사용자 활동 프로파일이 실시간으로 생성될 수 있으며, 또한 사용자 활동 프로파일은, 장치(250)에서 관련되는 특정 작업에 대한, 또는 특정 시간 주기(가령, 마지막 2시간, 마지막 5시간)에 대한 사용자 행동의 특성을 기술하는 애플리케이션 또는 웹 페이지에 의해 정의된 '세션(session)'에 대해 생성될 수 있다.

덧붙이자면, 사용자 활동 및 행동에 대한 추세 히스토리(historical trend)(가령, 1주, 1개월, 2개월 등)를 묘사하기 위해 사용자 활동 모듈(215)에 의해 특성 프로파일(characteristic profile)이 생성될 수 있다. 이러한 프로파일 히스토리가 사용되어, 사용자 행동의 추세(예를 들어, 하루 중 여러 다른 시간대에서의 액세스 빈도, 일주일의 특정 요일(주말 또는 평일)에 대한 추세, 위치 데이터(가령, IP 주소, GPS, 또는 셀 기지국 좌표 데이터)를 기초로 하는 사용자 활동 추세, 또는 위치 데이터의 변화를 기초로 하는 사용자 활동 추세(가령, 사용자 위치를 기초로 하는 사용자 활동, 또는 사용자가 나가려던 중인지 외출 중인지 등을 기초로 하는 사용자 활동))를 추론할 수 있어서, 사용자 활동 특성을 획득할 수 있다.

하나의 실시예에서, 사용자 활동 모듈(215)은 장치(250) 상의 애플리케이션, 문서, 파일, 창, 아이콘, 및 폴더와 관련해, 사용자 활동을 검출하고 추적할 수 있다. 예를 들어, 사용자 활동 모듈(215)은 애플리케이션 또는 창(가령, 웹 브라우저 또는 그 밖의 다른 임의의 유형의 애플리케이션)이 활성화될 때, 닫힐 때, 최소화될 때, 최대화될 때, 열릴 때, 전경(foreground)으로 이동될 때, 배경(background)으로 이동될 때, 멀티미디어 콘텐츠가 재생될 때 등을 검출할 수 있다.

하나의 실시예에서, 자원 소모, 가령, 배터리/전력 소모를 최적화하기 위해, 그리고 더 일반적으로는, 그 밖의 다른 장치 자원(가령, 메모리, 저자장치, 및 프로세싱 파워)의 소모를 최적화하기 위해, 장치(250) 상의 사용자 활동의 특성은 장치(가령, 모바일 장치 또는 임의의 무선 장치)의 행동을 로컬하게 조절하도록 사용될 수 있다. 하나의 실시예에서, (가령, 연결 관리기(265)의 라디오 제어기(266)에 의해) 사용자 활동 모듈(215)로 연결되는 사용자 행동의 특성을 기초로 하여 장치에서의 라디오의 사용이 조절될 수 있다. 예를 들어, 라디오 제어기(266)는 장치(250)에서의 사용자 활동의 특성을 기초로 하여, 라디오를 끄거나 켤 수 있다. 덧붙이자면, 사용자 활동의 특성에 따라, 라디오 제어기(266)는 라디오의 파워 모드(가령, 더 높은 파워 모드 또는 더 낮은 파워 모드이도록)를 조절할 수 있다.

하나의 실시예에서, 장치(250)에서의 사용자 활동의 특성이 사용되어, (가령, 셀룰러 또는 또 다른 네트워크를 통해) 장치(250)와 통신할 수 있는 또 다른 장치(가령, 또 다른 컴퓨터, 모바일 장치, 무선 장치, 또는 비-휴대용 장치(non-portable device)) 또는 서버(가령, 도 1A-B 및 도 3A의 예에서 호스트 서버(100 및 300))가 자신의 장치(250)와의 통신 빈도(communication frequency)를 수정하도록 할 수 있다. 원격 장치에게 자신의 통신 빈도를 변조하는 방식(가령, 통신 빈도의 감소, 가령, 사용자가 유휴 상태인 경우 데이터 푸시 빈도의 감소, 새로운 데이터, 변경된 데이터, 또는 특정 중요도의 데이터가 이용 가능해지는 경우 등, 원격 장치가 장치(250)에게 통지하도록 요청하는 등)에 대해 지시하기 위해, 로컬 프록시(275)는 사용자 활동 모듈(215)에 의해 결정된 사용자 행동의 특성 정보를 사용할 수 있다.

하나의 실시예에서, 사용자 활동 모듈(215)은, 사용자 활동 특성이 사용자가 비활성 주기 후 활성 상태임을 지시한다고 판단한 것에 응답하여, 원격 장치(가령, 도 1A-B 및 도 3A의 예에서 서버 호스트 서버(100 및 300))가 이전에 감소된 통신 빈도의 결과로서 버퍼링된 데이터를 전송하도록 요청할 수 있다.

이에 추가로, 또는 이를 대체하여, 로컬 프록시(275)가 장치(250)에서의 사용자 활동의 특성을 원격 장치(가령, 도 1A-B 및 도 3A의 예에서, 호스트 서버(100 및 300))로 통신할 수 있고, 원격 장치는 네트워크 자원 보존과 장치(250) 자원의 보존을 위해 장치(250)와 관련된 자신 고유의 통신 주파수를 변경하는 방식을 결정한다.

로컬 프록시(275)의 하나의 실시예는, 예를 들어, 애플리케이션(210 및/또는 220)에 의해, 및/또는 직접/간접적으로 사용자 요청에 의해, 장치(250)에서 개시되는 데이터 요청을 검출, 식별, 인터셉트, 프로세싱, 관리할 수 있는 요청/트랜잭션 관리기(235)를 더 포함한다. 요청/트랜잭션 관리기(235)는 트랜잭션 특성을 기초로하여 특정 요청 또는 트랜잭션(또는 요청/트랜잭션의 세트)을 처리하는 방식과 시점을 결정할 수 있다.

요청/트랜잭션 관리기(235)는 장치(250)에서 애플리케이션 및/또는 사용자에 의해 이뤄진 요청 또는 트랜잭션을, 가령 우선수위화 엔진(241)에 의해 우선순위화할 수 있다. 요청/트랜잭션의 중요도 또는 우선순위는 요청/트랜잭션 관리기(235)에 의해, 예를 들어, 트랜잭션의 시간 민감도(time sensitivity), 트랜잭션에서의 콘텐츠의 시간 민감도, 또는 트랜잭션의 시간 중요도(time criticality), 트랜잭션에 의해 전송되는 데이터의 시간 중요도, 및/또는 요청을 하는 애플리케이션의 시간 중요도 또는 중요도에 따르는 규칙 세트를 적용함으로써 결정될 수 있다.

덧붙이자면, 트랜잭션 특성은, 트랜잭션이 사용자-상호대화 또는 그 밖의 다른 사용자에 의해 장치에서 개시되는 동작(가령, 애플리케이션(가령, 모바일 애플리케이션)과의 사용자 상호대화)의 결과인지 여부에 따를 수 있다. 일반적으로, 시 중요성(time critical) 트랜잭션은 사용자에 의해 개시되는 데이터 전송으로부터 야기된 트랜잭션을 포함할 수 있고, 이에 따라 우선순위화될 수 있다. 트랜잭션 특성은, 요청된 트랜잭션의 결과로서 전송되는, 또는 전송될 것으로 예상되는 데이터의 크기에 따라 달라질 수 있다. 예를 들어, 연결 관리기(265)는 전송될 필요가 있을 데이터의 크기를 기초로 하여 라디오 모드(가령, 라디오 제어기(266)를 통해 높은 전력 또는 낮은 전력 모드)를 조절할 수 있다.

덧붙이자면, 라디오 제어기(266)/연결 관리기(265)는, 트랜잭션의 시간 중요도/민감도를 기초로 하여, 라디오 전력 모드(고전력 또는 저전력 모드)를 조절할 수 있다. 라디오 제어기(266)는 시 중요성 트랜잭션(가령, 사용자에 의해 개시되는 데이터 전송, 전경에서 실행 중인 애플리케이션, 특정 기준을 충족하는 임의의 그 밖의 다른 이벤트로부터 야기된 트랜잭션)이 개시되거나 검출될 때 고전력 라디오 모드를 트리거할 수 있다.

일반적으로, 우선순위는, 예를 들어, 장치 플랫폼, 장치 제조업체, 운영 체제 등을 기초로 하여, 디폴트(default)로 설정될 수 있다. 이에 추가로, 또는 이를 대체하여, 우선순위는 특정 애플리케이션에 의해 설정될 수 있으며, 가령, 페이스북(Facebook) 애플리케이션(가령, 모바일 애플리케이션)이 다양한 트랜잭션에 대헤 자신 고유의 우선순위를 설정할 수 있고(가령, 상태 업데이트가 친구 추가 요청이나 콕 찔러보기(poke) 요청보다 더 높은 우선순위를 가질 수 있고, 메시지 전송 요청은 메시지 삭제 요청보다 저 높은 우선순위를 가질 수 있다), 전자메일 클라이언트 또는 IM 챗 클라이언트가 우선순위에 대해 자신 고유 설정을 가질 수 있다. 우선순위화 엔진(241)은 우선순위를 할당하기 위한 규칙의 세트를 포함할 수 있다.

또한 우선순위화 엔진(241)은 요청/트랜잭션에 대한 전체 우선순위 상태를 결정할 때, 네트워크 제공자 제한(limitation) 또는 상세사항(specification)을 추적할 수 있다. 덧붙여, 우선순위는 명시적으로 또는 묵시적으로 사용자 선호도에 의해 부분적으로 또는 전적으로 결정될 수 있다. 사용자는, 일반적으로, 서로 다른 티어(tier)에서의 우선순위, 가령, 세션, 유형, 또는 애플리케이션에 대해 특정 우선순위를 설정할 수 있다(가령, 브라우징 세션 대(vs.) 게임 세션 대 IM 채팅 세션, 사용자가 게임 세션을 IM 챗 세션보다 항상 높은 우선순위를 갖도록 설정할 수 있고, IM 챗 세션은 웹 브라우징 세션보다 높은 우선순위를 가질 수 있다). 사용자는 애플리케이션 특정 우선순위(가령, 사용자는 페이스북-관련 트랜잭션을 링크드인(LinkedIn)-관련 트랜잭션보다 높은 우선순위를 갖도록 설정할 수 있음)를 특정 트랜잭션 유형에 대해 설정(가령, 모든 애플리케이션들 간 모든 메시지 전송 요청은 메시지 삭제 요청보다 더 높은 우선순위를 갖고, 모든 일정(calendar)-관련 이벤트는 높은 우선순위를 갖도록 하는 등)하거나, 및/또는 특정 폴더에 대해 애플리케이션 특정 우선순위를 설정할 수 있다.

우선순위화 엔진(241)은 서로 다른 개체에 의해 설정된 우선순위들 간 충돌을 추적하고 해결할 수 있다. 예를 들어, 사용자에 의해 특정되는 수동 설정이 장치 OS 설정보다 우선시될 수 있고, 네트워크 제공자 파라미터/제한(가령, 네트워크 서비스 영역, 지리적 현장에 대해 디폴트로 설정된 것, 하루 중 특정 시간에 대해 설정된 것, 또는 서비스/요금 유형을 기초로 설정된 것)이 임의의 사용자 특정된 설정 및/또는 애플리케이션 설정 우선순위를 제한할 수 있다. 일부 경우, 사용자로부터 수신된 수동 동기화 요청은, 요청된 동작에 대해 개별 할당된 우선순위 또는 전체 우선순위 등급에 무관하게, 요청된 동기화가 요청될 때 수행되는, 일부, 대부분, 또는 모든 우선순위 설정을 무효화(override)할 수 있다.

우선순위는, 임의의 알려진 및/또는 종래의 방식(제한받지 않는 예를 들면, 이진 표현, 다가 표현(multi-valued representation), 등급별 표현(graded representation))으로 내부적으로 특정되고 추적될 수 있으며, 모두 본 발명의 기술의 범위 내에 있는 것으로 고려된다.

표 1

표 1은, 설명을 목적으로, 이진 표현 스킴으로 할당된 우선순위들의 예시를 갖는 트랜잭션의 일부 예를 나타낸다. 추가적인 유형의 이벤트, 요청, 트랜잭션에 대해, 그리고 앞서 설명한 바와 같이, 추가적인 할당이 가능하며, 우선순위 할당은 더 높거나 낮은 입도 레벨(granular level)에서, 가령, 세션 레벨 또는 애플리케이션 레벨 등에서 이뤄질 수 있다.

상기의 표의 예에서 나타나는 것처럼, 일반적으로 더 낮은 우선순위의 요청/트랜잭션은, 메시지 상태를 읽음, 읽지 않음으로 업데이트하기, 메시지 삭제하기, 연락처 삭제하기가 있고, 더 높은 우선순위의 요청/트랜잭션은, 일부 경우에서, 상태 업데이트, 새 IM 챗 메시지, 새 전자메일, 일정 이벤트 업데이트/취소/제거, 모바일 게임 세션 내 이벤트, 또는 그 밖의 다른 엔터테인먼트 관련 이벤트, 웹 구매 또는 온라인을 통한 구매 확인, 추가 로딩 또는 콘텐츠 다운로드 요청하기, 연락처 관련 이벤트, 장치 설정을 변경하기 위한 트랜잭션, 위치-인지형 또는 위치 기반 이벤트/트랜잭션, 또는 사용자에 의해 개시되거나 사용자가 응답을 기다리고 있다고 알려지거나 예상되거나 추측되는 그 밖의 다른 임의의 이벤트/요청/트랜잭션을 포함할 수 있다.

수신함 가지치기(inbox pruning) 이벤트(가령, 전자메일, 또는 그 밖의 다른 임의의 유형의 메시지)는 일반적으로 낮은 우선순위라고 여겨지며, 그 밖의 다른 임박한 이벤트가 없다면, 장치(250) 상의 라디오의 사용을 트리거하지 않을 것이다. 구체적으로, 스케줄링된 가지치기 이벤트가 발생할 때, 오래된 전자메일 또는 그 밖의 다른 콘텐츠를 삭제하는 가지치기 이벤트에, 다른 경우라면 라디오가 켜지지 않을 그 밖의 다른 통신이 '업힐 수 있다(piggy backed)'. 예를 들어, 사용자가 '메시지를 7일 동안 보관'으로 설정된 선호도를 가진다면, 메시지가 7일째를 초과한 때 장치(250)에서 메시지 삭제를 개시하기 위해 장치 라디오를 켜는 대신, 다음 번 라디오가 켜질 때 메시지가 삭제된다. 라디오가 이미 켜져 있는 경우, 가지치기는 정규 스케줄대로 발생할 수 있다.

장치(250)로부터 나가는 트래픽을 자원 최적화를 위해 관리하기 위해(가령, 장치 라디오를 배터리 보존을 위해 더 효율적으로 사용하기 위해) 요청/트랜잭션 관리기(235)는 요청(가령, 우선순위화 엔진(241)에 의한 요청)에 대한 우선순위를 사용할 수 있다. 예를 들어, 연결 관리기(265)에 의해 제어될 때, 장치(250) 상에서의 라디오가 이미 스위치-온되어 있지 않은 경우, 특정 우선순위 등급 이하의 트랜잭션/요청이 라디오의 사용을 트리거할 수 있다. 이와 달리, 트랜잭션에 대한 요청이 특정 우선순위 레벨 이상이라고 검출될 때 상기 요청이 전송될 수 있도록, 라디오 제어기(266)가 라디오를 켤 수 있다.

하나의 실시예에서, 우선순위 할당(가령, 로컬 프록시(275) 또는 또 다른 장치/개체에 의해 결정되는 우선순위 할당)이 사용되어, 원격 장치가 모바일 장치 또는 무선 장치와의 통신의 빈도를 수정할 수 있다. 예를 들어, 더 높은 중요도의 데이터가 모바일 장치나 무선 장치로 전송될 수 있을 때 원격 장치는 장치(250)에게 통지를 전송하도록 구성될 수 있다.

하나의 실시예에서, 예를 들어, 트래픽 성형 엔진(255)에 의해, 트래픽을 성형하거나 관리할 때 트랜잭션 우선순위가 사용자 활동의 특성과 함께 사용될 수 있다. 예를 들어, 트래픽 성형 엔진(255)은, 사용자가 휴지기 즉 비활성 상태임을 검출한 것에 응답하여, 상기 장치(250)로부터 낮은 우선순위의 트랜잭션을 전송하기를 일정 시간 동안 기다릴 수 있다. 덧붙이자면, 트래픽 성형 엔진(255)에 의해, 복수의 낮은 우선순위 트랜잭션이 축적되어, (가령, 일괄처리 모듈(257)을 통해) 장치(250)로부터 일괄 전송(batch transferring)될 수 있다. 하나의 실시예에서, 사용자에 의해 우선순위가 설정, 구성, 또는 재조절될 수 있다. 예를 들어, 표 1에 기재된 콘텐츠는 장치(250)의 사용자 인터페이스에서 동일하거나 유사한 형태로 액세스될 수 있으며, 예를 들어, 우선순위를 조절하거나 보기 위해 사용자에 의해 사용될 수 있다.

일괄처리 모듈(257)은 특정 기준에 따라 일괄 전송을 개시할 수 있다. 예를 들어, 일괄 전송(가령, 발생된 복수의 이벤트의 일괄 전송이 있으며, 여기서 일부 이벤트는 서로 다른 때에 발생함)은, 특정 횟수의 낮은 우선순위 이벤트가 검출된 후, 또는 첫 번째 낮은 우선순위 이벤트가 개시되고 일정 시간이 흐른 후, 발생할 수 있다. 덧붙이면, 장치(250)에서 더 높은 우선순위 이벤트가 개시되거나 검출될 때, 일괄처리 모듈(257)이 누적된 낮은 우선순위 이벤트들의 일괄 전송을 개시할 수 있다. 또 다른 이유로(가령, 원격 장치, 가령, 호스트 서버(100 또는 300)로부터 데이터를 수신하기 위해) 라디오 사용이 트리거될 때 일괄 전송은 다른 방식으로 개시될 수 있다. 하나의 실시예에서, 일괄 전송이 발생할 때, 임박한 가지치기 이벤트(수신함(inbox)의 가지치기), 또는 그 밖의 다른 임의의 낮은 우선순위 이벤트가 실행될 수 있다.

일반적으로, 다음에서 나열되는 것들 중 하나 이상을 기초로 하여, 이벤트/트랜잭션 레벨, 애플리케이션 레벨, 또는 세션 레벨에서 일괄처리 능력(batching capability)이 비활성화 또는 활성화될 수 있다: 사용자 설정, 장치 제한/설정, 제조업체 명세, 네트워크 제공자 파라미터/제한, 플랫폼 특정 제한/설정, 장치 OS 설정 등. 하나의 실시예에서, 애플리케이션/창/파일이 닫히거나, 종료되거나, 배경으로 이동될 때 일괄 전송이 개시될 수 있고, 선택사항으로서, 일괄 전송을 개시하기 전에 사용자에게 프롬프팅될 수 있으며, 사용자는 일괄 전송을 수동으로 트리거할 수 있다.

하나의 실시예에서, 로컬 프록시(275)가 캐시(285)로 데이터를 캐싱함으로써, 장치(250)상에서의 라디오 사용을 로컬하게 조절한다. 캐시(285)에 저장된 콘텐츠에 의해 장치(250)로부터의 요청 또는 트랜잭션이 만족될 수 있을 때, 라디오 제어기(266)는 요청을 원격 개체(가령, 도 1A 및 도 3A에 도시된 호스트 서버(100, 300) 또는 콘텐츠 제공자/애플리케이션 서버, 가령, 도 1A 및 도 1B의 예에서 도시되는 서버/제공자(110))로 전송하기 위해 라디오를 활성화시킬 필요가 없다. 따라서 로컬 프록시(275)는 데이터 요청을 만족하도록, 데이터를 로컬하게 저장하기 위해 로컬 캐시(285) 및 캐시 정책 관리기(245)를 사용하여, 네트워크 자원 및 장치 배터리 소모를 보존하기 위해 장치 라디오의 사용을 생략 또는 감소시킬 수 있다.

로컬 캐시를 활용할 때, 요청/트랜잭션 관리기(225)가 장치(250) 상에서의 애플리케이션에 의한 데이터 요청을 인터셉트하면, 로컬 레포지토리(local repository)(285)에게, 임의의 로컬 저장된 응답이 존재하는지 여부에 대해, 그리고 상기 응답이 유효한지 여부에 대해 질의될 수 있다. 로컬 캐시(285)에서 유효한 응답이 이용가능할 때, 장치(250)가 셀룰러 네트워크 또는 무선 광대역 네트워크를 액세스할 필요 없이, 응답이 장치(250)상의 애플리케이션에 제공될 수 있다.

유효한 응답이 이용 가능하지 않은 경우, 로컬 프록시(275)는 원격 프록시(가령, 도 3A의 서버 프록시(325))에게, 원격 저장된 응답이 유효한지 여부에 대해 질의할 수 있다. 상기 원격 저장된 응답이 유효한 경우, 상기 응답(가령, 도 1B의 예의 경우, 서버 캐시(135) 또는 선택적 캐싱 서버(199)에 저장될 수 있는 응답)은 모바일 장치로 제공될 수 있으며, 이는, 모바일 장치(250)가 셀룰러 네트워크에 액세스할 필요 없이 이뤄질 수 있어서, 네트워크 자원의 소모가 완화될 수 있다.

유효한 캐시 응답이 이용 가능하지 않은 경우, 또는 캐시 응답이 인터셉트된 데이터 요청에 대해 이용 가능하지 않은 경우, 로컬 프록시(275), 가령, 캐싱 정책 관리기(245)가 데이터 요청을 원격 프록시(가령, 도 3A의 서버 프록시(325))로 전송할 수 있으며, 상기 원격 프록시는 데이터 요청을 콘텐츠 소스(가령, 도 1A의 애플리케이션 서버/콘텐츠 제공자(110))로 포워딩하며, 콘텐츠 소스로부터의 응답이 원격 프록시를 통해 제공될 수 있으며, 이는 도 3A의 예시적 호스트 서버(300)와 관련된 설명에서 추가로 설명될 것이다. 캐시 정책 관리기(245)는 다양한 프로토콜(가령, HTTP, HTTPS, IMAP, POP, SMTP, XMPP, 및/또는 ActiveSync)을 사용하는 요청을 관리하거나 프로세싱할 수 있다. 캐싱 정책 관리기(245)는 데이터 요청에 대한 응답을, 동일하거나 유사한 데이터 요청을 만족시킬 때 추후 사용되도록, 로컬 데이터베이스(285)에 캐시 엔트리로서 로컬하게 저장할 수 있다.

캐싱 정책 관리기(245)는 원격 프록시가 데이터 요청에 대한 응답을 모니터링할 것을 요청할 수 있으며, 원격 프록시는, 데이터 요청에 대한 예상되지 않은 응답이 검출될 때, 장치(250)에게 통지할 수 있다. 이러한 이벤트의 경우, 캐시 정책 관리기(245)는 데이터 요청에 대해 예상되지 않은 응답(가령, 새 데이터, 변경된 데이터, 추가 데이터 등)을 통지받을 때, 장치(250) 상에서 로컬 저장된 응답을 지우거나 대체할 수 있다. 하나의 실시예에서, 캐싱 정책 관리기(245)는 특정 요청에 대해 사용되는 프로토콜(가령, HTTP, HTTPS, IMAP, POP, SMTP, XMPP, 및/또는 ActiveSync, 그러나 이에 국한되지 않음)을 검출하거나 식별할 수 있다. 하나의 실시예에서, (가령, 캐싱 정책 관리기(245)의 애플리케이션 프로토콜 모듈(246)을 통한) 로컬 프록시(275) 상의 애플리케이션-특정적 핸들러(application specific handler)가, 분산 프록시 내 핸들러로 포트 매핑(port map)(가령, 도 3A의 예시의 경우, 프록시 서버(325)로 포트 매핑)될 수 있는 임의의 프로토콜의 최적화를 가능하게 한다.

하나의 실시예에서, 예를 들어, 콘텐츠 소스로의 데이터 요청이 모바일 장치로 반환될 동일한 결과를 산출할 때, 원격 프록시가 장치(250)로 결과를 반환하기 전에 콘텐츠 소스로부터의 변경된 결과에 대한 데이터 요청에 대해 수신된 응답을 모니터링할 수 있도록, 로컬 프록시(275)가 원격 프록시에게 통지한다. 일반적으로, 로컬 프록시(275)는 로컬 캐싱된 콘텐츠를 이용하여 장치(250) 상의 애플리케이션에 대한 애플리케이션 서버 응답을 시뮬레이트(simulate)할 수 있다. 이는, 새로운/변경된 데이터가 이용 가능하지 않는 트랜잭션에 대해 셀룰러 네트워크가 이용되는 것을 막고, 따라서, 네트워크 자원을 이용가능하게 하며 네트워크 혼잡을 방지할 수 있다.

하나의 실시예에서, 로컬 프록시(275)는 장치(250) 상에서 액세스되거나 설치되는 애플리케이션(가령, 프록시-인지형 및/또는 프록시-비인지형 애플리케이션(210 및 220))을 추적, 검출, 관찰, 모니터링하기 위한 애플리케이션 거동 검출기(236)를 포함한다. 장치(250) 상에서 액세스되는 하나 이상의 애플리케이션의 애플리케이션 거동, 또는 (가령 패턴 검출기(237)를 통해) 검출되는 거동의 패턴이 로컬 프록시(275)에 의해 사용되어, 이들 애플리케이션의 데이터 수요를 만족시키기 위해 요구되는 무선 네트워크에서의 트래픽을 최적화할 수 있다.

예를 들어, 복수의 애플리케이션의 검출된 거동을 기초로 하여, 트래픽 성형 엔진(traffic shaping engine)(255)이 (가령, 정렬 모듈(256)을 통해) 애플리케이션들 중 적어도 일부에 의해 네트워크(무선 네트워크)를 통해 만들어진 콘텐츠 요청을 정렬할 수 있다. 정렬 모듈(256)은 정렬을 하기 위해 먼저 수신된 일부 요청들을 지연시키거나 우선시할 수 있다. 요청이 정렬될 때, 트래픽 성형 엔진(255)은 연결 관리기를 이용하여, 네트워크를 통해 폴링함으로써, 애플리케이션 데이터 요청을 만족시킬 수 있다. 복수의 애플리케이션에 대한 콘텐츠 요청들이, 거동 패턴 또는 규칙/설정(예를 들어, 복수의 애플리케이션에 의해 요청되는 콘텐츠 유형(오디오, 비디오, 텍스트 등), 장치(가령, 모바일 또는 무선 장치) 파라미터, 및/또는 네트워크 파라미터/트래픽 상태, 네트워크 서비스 제공자 제약/상세사항 등)을 기초로 정렬될 수 있다.

하나의 실시예에서, 패턴 검출기(237)는, 예를 들어, 애플리케이션 거동의 패턴을 추적함으로써, 복수의 애플리케이션에 의해 만들어지는 애플리케이션 요청에서의 반복(recurrence)을 검출할 수 있다. 추적되는 패턴은, 특정 애플리케이션이 배경 프로세스로서, 애플리케이션 서버에 규칙적으로, 하루 중 특정 시점에서, 일주일 중 특정 요일에, 예측 가능한 방식으로 주기적으로, 특정 빈도로, 특정 유형의 이벤트에 응답하여 특정 빈도로, 특정 유형의 사용자 질의에 응답하여 요청되는 콘텐츠가 동일한 빈도, 동일한 요청이 이뤄지는 빈도, 요청들 간 간격, 요청을 하는 애플리케이션, 또는 이들 중 임의의 조합을 갖고 폴링하는 것의 검출을 포함할 수 있다.

이러한 반복이 트래픽 성형 엔진(255)에 의해 사용되어, 모바일 장치 또는 무선 장치(250)에서 수행될 애플리케이션 요청으로부터 야기될 콘텐츠 소스(가령, 도 1A의 애플리케이션 서버/콘텐츠 제공자(110))로부터의 콘텐츠의 폴링이, 상기 장치(250)에 원격으로 위치하는 프록시 서버(가령, 도 1B의 프록시 서버(125) 또는 도 3A의 프록시 서버(325))에 의해 분담될 수 있다. 반복이 규칙에 일치할 때 트래픽 성형 엔진(255)이 폴링을 분담하기로 결정할 수 있다. 예를 들어, 정확히 동일한 자원 또는 반환되는 값을 갖거나 요청과 응답 사이에 반복되는 시간 주기의 검출(가령, 하루 중 특정 시점에서 요청되는 자원의 검출)을 기초로 하는 동일한 자원에 대한 복수의 발생 또는 요청이 있을 수 있다. 폴링의 분담이, 반복되는 콘텐츠 폴링에 대해 콘텐츠 소스와의 무선(셀룰러 또는 그 밖의 다른 무선 광대역) 연결을 확립하기 위해 모바일 장치(250)가 필요로 하는 대역폭 소모량을 감소시킬 수 있다.

콘텐츠 소스의 폴링에서 콘텐츠 변화가 검출되지 않을 때, 폴링의 분담의 결과로서, 장치(250)에서의 데이터 요청을 만족시키기 위해 로컬 캐시(285)에 저장되는 로컬 캐싱된 콘텐츠가 제공될 수 있다. 따라서 데이터가 변경되지 않을 때, 라디오 사용을 활성화할 필요 없이, 또는 셀룰러 대역폭을 차지하지 않고, 애플리케이션 데이터 수요가 만족될 수 있다. 데이터가 변경되거나, 및/또는 새로운 데이터가 수신될 때, 폴링을 분담하는 원격 개체가 장치(250)에게 통지할 수 있다. 원격 개체는 도 3A의 예에서 나타나는 것처럼 호스트 서버(300)일 수 있다.

하나의 실시예에서, 로컬 프록시(275)는, 상당한 양의 전력을 소모하고 따라서 모바일 장치 배터리 수명에 부정적 영향을 미치는 TCP/IP 연결을 유지하기 위한 주기적 킵얼라이브 메시지(keep-alive message)의 수요/사용을 경감시킬 수 있다. 로컬 프록시 내 연결 관리기(265)(가령, 하트비트 관리기(heartbeat manager)(267))가 애플리케이션으로부터 전송되고 있는 임의의 또는 모든 하트비트(킵얼라이브) 메시지를 검출, 식별, 및 인터셉트할 수 있다.

하트비트 관리기(267)는 임의의 또는 모든 이들 하트비트 메시지가 셀룰러, 또는 또 다른 네트워크를 통해 전송되는 것을 막을 수 있으며, 대신, 백엔드(가령, 도 lA의 예의 경우, 애플리케이션 서버/제공자(110))와의 연결을 유지하기 위해, 분산 프록시 시스템의 서버 구성요소(가령, 도 1B에 도시된 것)가 하트비트 메시지를 생성하고 전송하는 것에 의지할 수 있다.

일반적으로, 로컬 프록시(275)는 개별 관리기, 모듈, 및/또는 엔진에 대해 설명된 기능들 중 임의의 하나 또는 일부를 나타낸다. 본 발명의 범위 내에서, 로컬 프록시(275) 및 장치(250)는 더 많거나 더 적은 구성요소를 포함할 수 있고, 더 많거나 더 적은 기능이 포함될 수 있다.

도 2B는 애플리케이션 거동 및/또는 네트워크 상태에 대해 캐싱하고 캐싱 전략을 적응화할 수 있는 도 2A의 예에서 나타난 캐시 시스템 내 구성요소의 추가 예를 도시하는 블록도를 도시한다.

하나의 실시예에서, 캐싱 정책 관리기(245)는 메타데이터 발생기(203), 캐시 룩-업 엔진(205), 캐시 적절성 판단 엔진(cache appropriateness decision engine)(246), 폴 스케줄 생성기(247), 애플리케이션 프로토콜 모듈(248), 캐시 또는 연결 선택 엔진(249) 및/또는 로컬 캐시 무효화기(244)를 포함한다. 캐시 적절성 판단 엔진(246)은 타이밍 예측기(timing predictor)(246a), 콘텐츠 예측기(content predictor)(246b), 요청 분석기(246c), 및/또는 응답 분석기(246d)를 포함하며, 캐시 또는 연결 선택 엔진(249)은 응답 스케줄러(249a)를 포함한다. 메타데이터 생성기(203) 및/또는 캐시 룩-업 엔진(205)은, 캐시 엔트리의 수정 또는 추가, 또는 이들의 질의를 위해, 캐시(285)(또는 로컬 캐시)로 연결된다.

캐시 룩-업 엔진(205)은 ID 또는 URI 필터(205a)를 더 포함하고, 로컬 캐시 무효화기(244)는 TTL 관리기(244a)를 더 포함하며, 폴 스케줄 생성기(247)는 스케줄 업데이트 엔진(247a) 및/또는 시간 조절 엔진(247b)을 더 포함할 수 있다. 캐싱 정책 관리기(245)의 한 가지 실시예는 애플리케이션 캐시 정책 레포지토리(243)를 포함한다. 하나의 실시예에서, 애플리케이션 거동 검출기(236)는 패턴 검출기(237), 폴 간격 검출기(238), 애플리케이션 프로파일 생성기(239), 및/또는 우선순위 엔진(241)을 포함한다. 폴 간격 검출기(238)는 응답/요청 추적 엔진(238b)을 갖는 롱 폴 검출기(long poll detector)(238a)를 더 포함할 수 있다. 폴 간격 검출기(238)는 롱 폴 헌팅 검출기(long poll hunting detector)(238c)를 더 포함할 수 있다. 애플리케이션 프로파일 생성기(239)는 응답 지연 간격 추적기(239a)를 더 포함할 수 있다.

패턴 검출기(237), 애플리케이션 프로파일 생성기(239), 및 우선순위 엔진(241)이 도 2A의 예시에서 나타난 패턴 검출기에 대한 기재와 관련하여 기재되었다. 하나의 실시예는 애플리케이션 프로파일(가령, HTTP 요청의 거동, 패턴, 유형 등)과 관련된 정보 또는 메타데이터를 저장하기 위해 로컬 프록시(275)에 의해 사용될 수 있는 애플리케이션 프로파일 레포지토리(242)를 더 포함한다.

캐시 적절성 판단 엔진(246)은, 모바일 장치(250)가 상호대화하며 콘텐츠를 갖는 콘텐츠 소스(가령, 도 1B의 예시의 경우, 애플리케이션 서버/콘텐츠 제공자(110))로부터의 콘텐츠가 캐싱되기 적합할 수 있는지 여부를 검출, 평가, 또는 결정할 수 있다. 예를 들어, 상기 판단 엔진(246)은 모바일 장치(250)에서 개시되는 요청 및/또는 상기 요청에 대해 수신된 응답에 대한 정보를 이용하여, 캐싱 가능함(cacheability), 캐싱 가능할 가능성이 있음(potential cacheability), 또는 캐싱 불가능함(non-cacheability)을 결정할 수 있다. 일부 경우, 판단 엔진(246)은 먼저, 요청이 블랙리스트에 올라간 도착지와 관련됐는지 여부, 또는 요청 자체가 블랙리스트에 올라간 클라이언트 또는 애플리케이션으로부터 발원된 것인지 여부를 검증할 수 있다. 그런 경우, 판단 엔진(246)에 의해, 추가 프로세싱 및 분석이 수행되지 않을 수 있고, 요청을 만족시키기 위해 요청이 무선으로(over the air) 서버로 전송되도록 허용될 수 있다. 블랙리스트에 올라간 도착지 또는 애플리케이션/클라이언트(가령, 모바일 애플리케이션)가 로컬 프록시에서 로컬하게 (가령, 애플리케이션 프로파일 레포지토리(242)에) 유지되거나, 원격으로 (가령, 프록시 서버(325) 또는 또 다른 개체에) 유지될 수 있다.

하나의 실시예에서, 예를 들어, 요청 분석기(246c)를 통해, 판단 엔진(246)은, 모바일 장치(250)에서 생성된 애플리케이션 또는 클라이언트 요청에 대한 정보를 수집한다. 요청 정보는 요청 특성 정보, 가령, 요청 방법을 포함할 수 있다. 예를 들어, 요청 방법은 모바일 애플리케이션 또는 클라이언트에 의해 생성된 HTTP 요청의 유형을 지시할 수 있다. 하나의 실시예에서, 요청 방법이 GET 요청이거나 POST 요청인 경우, 상기 요청에 대한 응답이 캐싱 가능하거나, 캐싱 가능할 가능성이 있는 것으로 식별될 수 있다. 또 다른 유형의 요청(가령, OPTIONS, HEAD, PUT, DELETE, TRACE, 또는 CONNECT)이 캐싱될 수 있거나 캐싱되지 않을 수 있다. 일반적으로 캐싱될 수 없는 요청 방법에 의한 HTTP 요청은 캐싱되지 않을 것이다.

요청 특성 정보는 예를 들면, 요청 크기와 관련된 정보를 더 포함할 수 있다. 특정 크기를 초과하는 본체 크기(body size)를 갖는 요청(가령, HTTP 요청)에 대한 응답이 캐싱되지 않을 것이다. 예를 들어, 요청에 대한 정보가 요청의 요청 본체 크기가 특정 크기를 초과하지 않는다고 가리키는 경우, 캐싱 가능함(cacheability)이라고 결정될 수 있다. 일부 경우, 최대 캐싱 가능한 요청 본체 크기는 8092 바이트로 설정될 수 있다. 또 다른 경우, 예를 들어, 네트워크 수용력 또는 네트워크 운영자 특정 설정에 따라서, 여러 다른 값들이 사용될 수 있다.

일부 경우, 특정 애플리케이션 서버/콘텐츠 제공자(가령, 도 1B의 서버/콘텐츠 제공자(110))로부터의 콘텐츠는, 기준의 세트, 예를 들면, 콘텐츠 소스로부터 요청되는 콘텐츠의 시간 중요도를 특정하는 기준들을 기초로 하여, 캐싱되기 적합하다고 결정된다. 하나의 실시예에서, 로컬 프록시(가령, 도 1B 및 도 2A의 로컬 프록시(175 또는 275))가, 애플리케이션에 의해 요청되는 호스트 서버로부터의 콘텐츠를, 애플리케이션에 의해 만들어지는 후속 요청을 만족시키기 위해, 모바일 장치 상의 로컬 캐시에 캐싱되는 요소로서 저장하기 위한 선택 기준을 적용한다.

캐시 적절성 판단 엔진(246)은, (가령, 모바일 애플리케이션 또는 장치(250) 상의 그 밖의 다른 클라이언트에 의해) 모바일 장치(250)로부터 전송되는 요청들의 검출된 패턴 및/또는 수신된 응답들의 패턴을 더 기초로 하여, 요청 및/또는 응답에서 예측가능성(predictability)을 검출할 수 있다. 예를 들어, 판단 엔진(246)(가령, 요청 분석기(246c))에 의해 수집되는 요청 특성 정보는, 하나의 요청과, 모바일 장치상의 동일 클라이언트에 의해 생성되는 나머지 다른 요청들(또는 동일한 호스트로 향해지는 나머지 다른 요청들)(가령, 유사하거나 동일한 식별자 파라미터를 가짐) 간의 주기성 정보(periodicity information)를 더 포함할 수 있다.

상기 하나의 요청 및 동일한 클라이언트에 의해 생성되는 나머지 다른 요청들이, 일부 식별 가능한, 또는 부분적으로 또는 전체적으로 재생성될 수 있는 변하는 패턴을 갖고 고정 속도(rate)로, 또는 거의 고정 속도로, 또는 동적 속도(dynamic rate)로 발생할 때, 판단 엔진(246) 또는 요청 분석기(246c)에 의해 주기성이 검출될 수 있다. 일부 식별 가능한 패턴(가령, 규칙적 간격, 검출 가능한 패턴을 갖는 간격, 또는 추세(가령, 증가하는 추세, 감소하는 추세 등))을 갖고 요청이 이뤄지는 경우, 타이밍 예측기(246a)가 장치상의 특정 애플리케이션에 의해 이뤄지는 요청이 예측 가능하다고 결정하고, 적어도 타이밍 관점에서, 캐싱되기 적절할 가능성이 있는 것으로 식별할 수 있다.

일반적으로, 식별 가능한 패턴 또는 추세는, 예를 들어 임의의 애플리케이션 또는 클라이언트 거동을 포함할 수 있으며, 이들은 모바일 장치(250) 상의 로컬 프록시(275) 상에서 로컬하게 시뮬레이트(simulate)될 수 있거나, 예를 들어 호스트(300) 상의 프록시 서버(325)에 의해 원격으로 시뮬레이트될 수 있거나, 로컬 시뮬레이션과 원격 시뮬레이션이 조합되어 애플리케이션 거동을 모방할 수 있다.

하나의 실시예에서, 판단 엔진(246)은, 예를 들어, 응답 분석기(246d)를 통해, 모바일 장치(250)에서 생성되는 애플리케이션 또는 클라이언트 요청에 대한 응답에 관한 정보를 수집할 수 있다. 일반적으로 응답은, 모바일 장치(250)에서 요청을 전송했던 애플리케이션(가령, 모바일 애플리케이션)의 서버 또는 호스트로부터 수신된다. 일부 경우, 모바일 클라이언트 또는 애플리케이션은 애플리케이션의 모바일 버전(가령, 소셜 네트워킹, 검색, 여행 관리, 음성메일, 연락처 관리기, 전자메일) 또는 웹 브라우저나 데스크톱 클라이언트를 통해 액세스되는 웹 사이트일 수 있다.

예를 들어, 응답 특성 정보는, 응답을 전송할 때 전송 인코딩(transfer encoding)이 사용되는지 또는 청크 전송 인코딩(chunked transfer encoding)이 사용되는지에 대한 지시자(indication)를 포함할 수 있다. 일부 경우, 전송 인코딩 또는 청크 전송 인코딩을 이용한 HTTP 요청에 대한 응답은 캐싱되지 않으며, 따라서 추후 분석을 위해 이동된다. 왜냐하면, 보통, 청크 응답은 크고 캐싱되기 적합하지 않는데, 이는 이들 트랜잭션의 프로세싱이 전체적인 수행을 느리게 할 가능성이 높기 때문이다. 따라서 일부 실시예에서, 응답 전송 시 전송 인코딩이 사용되지 않을 때, 캐싱 가능함 또는 캐싱 가능할 가능성이 있음으로 결정될 수 있다.

덧붙이자면, 응답 특성 정보가, 응답 분석기(246d)에 의해 식별될 수 있는 응답의 관련된 상태 코드를 포함할 수 있다. 일부 경우, 캐싱될 수 없는 상태 코드를 갖는 HTTP 응답은 일반적으로 캐싱되지 않는다. 응답 분석기(246d)가 응답으로부터 상태 코드를 추출할 수 있으며, 상기 상태 코드가 캐싱 가능함 또는 캐싱 불가능함 상태 코드와 일치하는지 여부를 결정할 수 있다. 임의의 캐싱 가능함 상태 코드의 예로는, 200-OK, 301-Redirect, 302-Found, 303-See other, 304-Not Modified, 307Temporary Redirect, 또는 500-Internal server error를 포함한다. 임의의 캐싱 불가능함 상태 코드로는, 예를 들어, 403-Forbidden 또는 404-Not found를 포함할 수 있다.

하나의 실시예에서, 응답에 대한 정보가 캐싱 불가능함 상태 코드를 나타내지 않거나, 캐싱 가능함 상태 코드를 나타내는 경우 캐싱 가능함 또는 캐싱 가능할 가능성이 있음이라고 결정될 수 있다. 응답 분석기(246d)가 특정 응답과 연계된 캐싱 가능하지 않음 상태 코드를 검출한 경우, 추가 프로세싱으로부터 특정 트랜잭션(요청/응답 쌍)이 제거되고, 일시적으로, 또는 반영구적으로, 또는 영구적으로 캐싱 불가능함이라고 결정될 수 있다. 상태 코드가 캐싱 가능함이라고 나타내는 경우, 도 9-13의 예시적 흐름도에서 나타나는 것처럼, 트랜잭션(가령, 요청 및/또는 응답 쌍)이 추가 프로세싱의 대상이 될 수 있고, 캐싱 가능함을 확인하기 위해 분석될 수 있다.

또한 응답 특성 정보는 응답 크기 정보를 포함할 수 있다. 일반적으로, 응답이 특정 크기를 초과하지 않는 경우, 응답은 모바일 장치(250)에서 로컬하게 캐싱될 수 있다. 일부 경우, 디폴트 최대 캐싱되는 응답 크기는 128KB로 설정된다. 또 다른 경우, 최대 캐싱 가능한 응답 크기는 서로 다를 수 있으며, 및/또는 동작 상태, 네트워크 상태, 네트워크 수용량, 사용자 선호도, 네트워크 운영자 요구사항, 또는 그 밖의 다른 애플리케이션 특정, 사용자 특정 및/또는 장치 특정 요인을 기초로, 동적으로 조절될 수 있다. 하나의 실시예에서, 응답 분석기(246d)는 응답의 크기를 식별할 수 있고, 응답 크기가 특정 임계치 또는 최댓값을 초과하지 않는 경우, 캐싱 가능함 또는 캐싱 가능할 가능성이 있음으로 결정될 수 있다.

덧붙이자면, 응답 특성 정보는, 한 요청에 대한 한 응답 및 모바일 장치 상의 동일한 클라이언트에 의해 생성되거나 동일한 콘텐츠 호스트 또는 애플리케이션 서버로 전달되는 그 밖의 다른 요청에 대한 그 밖의 다른 응답에 대한 응답 본체 정보(response body information)를 포함할 수 있다. 예를 들어, 응답 분석기(246d)에 의해, 응답에 대한 응답 본체 정보와 그 밖의 다른 응답에 대한 응답 본체 정보가 비교되어, 동적 콘텐츠 (또는 빈번하게 변경되며 캐시 엔트리로 효율적으로 서비스될 수 없는 콘텐츠, 가령, 금융 데이터, 주식 시세, 뉴스 피드, 실시간 스포츠 이벤트 활동 등을 포함한 응답)의 캐싱이 방지될 수 있다.

캐시 적절성 판단 엔진(246)(가령, 콘텐츠 예측기(246b))이 반복성(repeatability)을 확정적으로 식별하거나, 반복성의 지시자를 식별하거나, 반복성의 가능성을 식별하거나, 콘텐츠 소스(가령, 도 1A-B의 예시의 경우, 콘텐츠 호스트/애플리케이션 서버(110))로부터 수신된 응답의 예측성을 식별할 수 있다. 반복성은, 예를 들어, 콘텐츠 소스로부터 수신된 적어도 2개의 응답을 추적하고, 2개의 응답이 서로 동일한지 여부를 결정함으로써 검출될 수 있다. 예를 들어, 한 응답에 대한 응답 본체 정보와, 동일한 모바일 클라이언트에 의해 전송되거나 동일한 호스트/서버로 전달되는 그 밖의 다른 응답에 대한 응답 본체 정보가 동일하거나 실질적으로 동일한 경우 응답 분석기(246d)에 의해, 캐싱 가능함으로 결정될 수 있다. 2개의 응답은 연속한 요청들에 응답하여 전송된 응답일 수도 있고, 아닐 수도 있다. 하나의 실시예에서, 특정 애플리케이션으로부터의 요청에 대해 수신된 응답의 해시 값(hash value)이 (휴리스틱을 이용하거나 이용하지 않고) 애플리케이션에 대해 전체적으로, 및/또는 특정 요청에 대한 콘텐츠의 반복성을 결정하기 위해 사용된다. 추가적인 동일한 응답이 일부 애플리케이션에 대해, 또는 특정 환경 하에서 요구될 수 있다.

수신된 콘텐츠의 반복성은 100% 확정될 필요는 없다. 예를 들어, 특정 개수 또는 특정 퍼센트의 응답들이 서로 동일하거나 유사한 경우, 응답이 반복성이 있다고 결정될 수 있다. 특정 개수 또는 특정 퍼센트의 동일/유사한 응답은, 디폴트(default)로 설정되거나, 요청을 발생하는 애플리케이션을 기초로 설정된(가령, 애플리케이션이 꾸준한 업데이트로 매우 동적인지, 드문 업데이트로 덜 동적인지 여부) 선택 시간 주기 동안 추적될 수 있다. 모바일 장치(250) 상의 요청하는 애플리케이션 또는 클라이언트로 제공될 콘텐츠를 캐싱할 때, 분산 시스템에 의해 임의의 지시된 예측성 또는 반복성, 또는 반복될 가능성이 활용될 수 있다.

하나의 실시예에서, 롱 폴 유형 요청의 경우, 첫 2개의 응답들에 대한 응답 지연 시간이 서로 동일하거나, 실질적으로 동일하거나, 간격이 증가하는 것으로 검출된 경우, 로컬 프록시(175)는 세 번째 요청에 대한 응답을 캐싱하기 시작할 수 있다. 일반적으로 첫 2개의 응답들에 대해 수신된 응답은 서로 동일해야 하며, 세 번째 요청에 대해 수신된 세 번째 응답이 동일하다고 검증되면(가령, R0 = R1 = R2인 경우), 세 번째 응답이 모바일 장치에 로컬하게 캐싱될 수 있다. 애플리케이션의 유형, 데이터의 유형, 콘텐츠의 유형, 사용자 선호도, 또는 통신업체(carrier)/네트워크 운영자 명세에 따라, 더 적거나 더 많은 개수의 동일한 응답들이 캐싱되기 시작할 필요가 있을 수 있다.

애플리케이션 거동 검출기(236)의 롱 폴 헌팅 검출기(238c)에 의해 검출될 때, 롱 폴에 대한 동일한 응답의 증가하는 응답 지연은 헌팅 주기(hunting period)(가령, 모바일 장치상의 애플리케이션/클라이언트가, 특정 네트워크가 허용할 요청과 응답 사이의 가장 긴 시간을 찾는 중인 주기, 타이밍 특성을 보여주는 타이밍도가 도 8에 도시된다)를 가리킬 수 있다.

일례가 T0, T1, T2를 이용하여 이하에서 설명될 수 있으며, 여기서, T는 연속하는 요청들에 대해, 요청이 전송되는 시점과 응답(가령, 응답 헤더)이 검출/수신되는 시점 사이의 지연 시간을 나타낸다:

T0 = 응답0(t) - 요청0(t) = 180 s. (+/- 허용오차)

T1 = 응답1(t) - 요청1(t) = 240 s. (+/- 허용오차)

T2 = 응답2(t) - 요청2(t) = 500 s. (+/- 허용오차)

앞서 나타난 예시적 타이밍 시퀀스 T0 < T1 < T2에서, 이는, 네트워크 타임아웃이 아직 초과되지 않았을 때 롱 폴에 대한 헌팅 패턴을 나타낼 수 있다. 덧붙이자면, 3개의 요청에 대하여 수신된 응답 R0, R1, 및 R2이 서로 동일한 경우, R2는 캐싱될 수 있다. 이 예에서, 롱 폴이 정착(settle)되기를 기다리지 않고 롱 폴 헌팅 주기 동안 R2가 캐싱되며, 따라서 응답 캐싱이 신속화된다(가령, 이는 모든 또는 선택된 애플리케이션에 대해 구현될 수 있는 선택사항적인 가속화된 캐싱 거동이다).

따라서 로컬 프록시(275)는 앞서 나타난 타이밍 시퀀스로부터 추출될 수 있는 정보(가령, 폴링 스케줄, 폴링 간격, 폴링 유형)를 프록시 서버로 특정하고, 캐싱을 시작하며, 프록시 서버가 소스로 폴링하고 소스를 모니터링하는 것을 시작하도록 요청할 수 있다(가령, T0, T1, T2 중 임의의 것(일반적으로는 T2, 즉, 타임 아웃 없는 가장 긴 검출 간격)을 폴링 간격으로서 이용하며, 소스로부터의 응답이 수신되는 폴링 간격이 콘텐츠 소스(가령, 애플리케이션 서버/서비스 제공자(310))에게 폴링할 때 사용되도록 도 3A의 프록시 서버(325)로 전송될 것이다).

그러나 시간 간격이 점점 더 짧아지는 것으로 검출되는 경우, 애플리케이션(가령, 모바일 애플리케이션)/클라이언트가, 콘텐츠 소스(가령, 애플리케이션/서버 서버/제공자(110 또는 310))로부터 응답이 신뢰할만하게(reliably) 수신될 수 있는 시간 간격 동안 여전히 헌팅할 수 있고, 따라서 일반적으로, 요청/응답 간격이 예를 들어 롱 폴 유형 요청에 대해 동일한 시간 간격 또는 증가하는 시간 간격을 가리킬 때까지 캐싱은 시작되지 않아야 한다.

검출된 감소하는 지연을 핸들링하는 일례가 이하에서, T0, T1, T2, T3, 및 T4를 이용해 설명될 수 있으며, 여기서 T는 연속한 요청에 대해 요청이 전송된 시점과 응답(가령, 응답 헤더)이 검출/수신된 시점 사이의 지연 시간을 가리킨다:

T0 = 응답0(t) - 요청0(t) = 160 s. (+/- 허용오차)

T1 = 응답1(t) - 요청1(t) = 240 s. (+/- 허용오차)

T2 = 응답2(t) - 요청2(t) = 500 s. (+/- 허용오차)

T3 = 700 s.에서 타임 아웃 (+/- 허용오차)

T4 = 응답4(t) - 요청4(t) = 600 (+/- 허용오차)

상기의 타이밍 시퀀스에서 나타나는 것처럼, 응답 지연에 대한 패턴 T1 < T2 < T3 > T4이 검출되는 경우(가령, 애플리케이션 거동 검출기(236)의 롱 폴 헌팅 검출기(238c)에 의해 검출), 롱 폴 헌팅 주기 동안 T3가 네트워크 타임 아웃을 초과할 가능성이 높다고 판단될 수 있다. 요청3에서, 연결이 네트워크, 애플리케이션, 서버에 의해, 또는 그 밖의 다른 이유로, 응답이 전송되거나 이용 가능해지기 전에 종료됐기 때문에, 응답이 수신되지 않았을 가능성이 높다. 요청4(T4 후)에서, 응답(가령, 응답4)이 검출되거나 수신된 경우, 그 후, (콘텐츠 반복성 조건이 충족되는 경우) 로컬 프록시(275)가 캐싱을 위해 상기 응답을 이용할 수 있다. 로컬 프록시는 또한, 프록시 서버가 콘텐츠 소스를 모니터링/폴링하기 위해 설정된 폴링 스케줄에서 T4를 폴 간격으로서 이용할 수 있다.

상기의 기재가, 증가하는 응답 지연을 검출하는 경우, 응답이 수신되고, 특정 요청에 대해 타임 아웃되지 않는 한, 롱 폴이 헌팅 모드에 있는 동안 캐싱이 시작될 수 있음을 나타낸다. 이는 롱 폴 헌팅 동안 선택적 가속화된 캐싱(optional accelerated caching)이라고 일컬어질 수 있다. 또한 헌팅 모드가 완료된 후(가령, 폴 요청이 일정한 또는 거의 일정한 지연 값으로 정착된 후) 캐싱이 시작될 수 있다. 롱 폴 동안 헌팅이 발생하거나 발생하지 않을 수 있으며, 헌팅이 발생할 때, 프록시(275)는 헌팅을 검출하고 헌팅 주기(동일한 응답을 갖는 증가하는 간격) 동안 캐싱을 시작할지 여부를 결정하거나 헌팅이 안정적인 값으로 정착될 때까지 기다릴 수 있다.

하나의 실시예에서, 캐시 적절성 판단 엔진(246)의 타이밍 예측기(246a)가, 애플리케이션(가령, 모바일 애플리케이션) 또는 클라이언트로부터의 아웃고잉 요청으로부터 수신된 응답의 타이밍을 추적함으로써, 로컬 캐싱된 응답이 콘텐츠 소스(가령, 애플리케이션 서버/콘텐츠 제공자(110 또는 310))의 거동을 시뮬레이트(simulate)하는 방식으로(예를 들어, (가령, 타이밍 관점에서) 응답이나 콘텐츠가 장치(250) 상의 요청하는 애플리케이션/클라이언트에게 전달될 방식으로) 모바일 장치(250) 상의 요청하는 클라이언트에게 제공될 수 있도록 부분적으로 또는 전체적으로 재생 가능한 임의의 식별 가능한 패턴을 검출할 수 있다. 이는, 애플리케이션 또는 모바일 클라이언트 요청에 대한 응답이, 콘텐츠 소스(가령, 애플리케이션, 콘텐츠 제공자(110 또는 310))로부터 직접 불러와 지거나 수신되는 대신, 로컬 및/또는 원격 캐시로부터 서비스될 때 사용자 경험(user experience)의 보존을 보장한다.

하나의 실시예에서, 판단 엔진(246) 또는 타이밍 예측기(246a)가, 예를 들어, 요청/응답 추적 엔진(238b) 및/또는 애플리케이션 프로파일 생성기(239)(가령, 응답 지연 간격 추적기(239a))로부터 특정 애플리케이션(가령, 모바일 애플리케이션) 또는 클라이언트의 타이밍 특성을 결정한다. 타이밍 특성을 이용해, 타이밍 예측기(246a)가 요청에 응답하여 수신된 콘텐츠가 적합한지, 또는 캐싱되기 적합할 가능성이 있는지 여부를 결정한다. 예를 들어, 특정 애플리케이션으로부터의 2개의 연속하는 요청들 간의 폴 요청 간격이 사용되어, 요청 간격이 반복될 수 있는지(가령, 일정, 거의 일정, 패턴을 갖고 증가, 패턴을 갖고 감소, 등) 여부를 결정할 수 있고, 예측될 수 있으며, 따라서 정확히, 또는 허용오차 수준 내에서 대략적으로 시간들 중 적어도 일부에서 재생될 수 있다.

일부 경우, 특정 애플리케이션에 대한, 하나의 애플리케이션의 복수의 요청에 대한, 또는 복수의 애플리케이션에 대한 특정 요청 유형의 타이밍 특성이 애플리케이션 프로파일 레포지토리(242)에 저장될 수 있다. 일반적으로, 애플리케이션 프로파일 레포지토리(242)는 타이밍 패턴, 타이밍 반복성, 콘텐츠 반복성 등을 포함하는 애플리케이션 요청/응답 특성과 관련된 임의의 유형의 정보 또는 메타데이터를 저장할 수 있다.

또한 애플리케이션 프로파일 레포지토리(242)는, 특정 애플리케이션에 의해 사용되는 요청의 유형(가령, 롱 폴, 장기 유지(long-held) HTTP 요청, HTTP 스트리밍, 푸시, COMET 푸시 등)을 나타내는 메타데이터를 저장할 수 있다. 애플리케이션에 의한 요청 유형을 나타내는 애플리케이션 프로파일은, 후속하는 동일한/유사한 요청이 검출될 때, 또는 이미 카테고리화된 애플리케이션으로부터 요청이 검출될 때, 사용될 수 있다. 이러한 방식으로, 추적 및/또는 분석된 적 있는 특정 요청 유형에 대한, 또는 구체적 애플리케이션의 요청에 대한 타이밍 특성은 재분석될 필요가 없다.

애플리케이션 프로파일은 수명시간(time-to-live)(가령, 디폴트 만료 시간)과 연계될 수 있다. 애플리케이션 프로파일, 또는 다양한 형태의 애플리케이션 또는 요청의 프로파일을 위해 만료 시간을 사용하는 것은 케이스 별로 사용될 수 있다. 애플리케이션 프로파일 엔트리의 수명시간(time-to-live) 또는 실제 만료 시간이 디폴트 값으로 설정되거나, 개별적으로 결정되거나, 조합되어 설정될 수 있다. 또한 애플리케이션 프로파일은 무선 네트워크, 물리 네트워크, 네트워크 운영자, 또는 특정 통신업체 특정적일 수 있다.

하나의 실시예는 애플리케이션 블랙리스트 관리기(201)를 포함한다. 애플리케이션 블랙리스트 관리기(201)는 애플리케이션 캐시 정책 레포지토리(243)에 연결되고, 로컬 프록시 또는 캐싱 정책 관리기(245) 내부에 부분적으로 또는 전부 위치할 수 있다. 마찬가지로, 블랙리스트 관리기(201)는 로컬 프록시 또는 애플리케이션 거동 검출기(236) 내부에 부분적으로 또는 전부 위치할 수 있다. 블랙리스트 관리기(201)는 영구적 또는 일시적으로 '블랙리스트'에 올라갔으며, 캐싱되지 않음이라고 식별되는 서버/호스트의 도착지의 리스트를 집합화, 추적, 업데이트, 관리, 조절, 또는 동적으로 모니터할 수 있다. 도착지 블랙리스트는, 요청에서 식별될 때, 요청이 (셀룰러) 네트워크를 통해 서비스되기 위해 전송되게 하도록 사용될 수 있다. 요청이 블랙리스트 도착지로 전달된다고 검출되기 때문에 요청의 추가 프로세싱이 수행될 수 없다.

특정 URL 또는 식별자 패턴(가령, URI 패턴) 등의 주소 식별자에 의해 블랙리스트 도착지가 애플리케이션 캐시 정책 레포지토리(243)에서 식별될 수 있다. 일반적으로, 임의의 이유로, 사용자(모바일 장치(250)의 소유자/사용자), 장치(250)의 운영 체제/모바일 플랫폼, 도착지 자체, (셀룰러 네트워크의) 네트워크 운영자, 인터넷 서비스 제공자, 기타 제3자를 포함한 임의의 측에 의해, 또는 캐싱될 수 없음/캐싱되기 부적합함이라고 알려진 애플리케이션용 도착지들의 리스트에 따라서, 블랙리스트 도착지가 설정되거나 수정될 수 있다. 블랙리스트 도착지 내 일부 항목은, 로컬 프록시(가령, 캐시 적절성 판단 엔진(246))에 의해 수행되는 분석 또는 프로세싱을 기초로 집합화된 도착지를 포함할 수 있다.

예를 들어, 응답이 캐싱되기 부적합한 것으로 식별되는 모바일 장치상의 애플리케이션 또는 모바일 클라이언트가 블랙리스트에 추가될 수 있다. 그들의 대응하는 호스트/서버가 모바일 장치(250)상의 요청하는 애플리케이션/클라이언트의 식별자에 추가로, 또는 상기 식별자를 대신하여 추가될 수 있다. 프록시 시스템에 의해 식별되는 이러한 클라이언트의 일부 또는 전부가 블랙리스트에 추가될 수 있다. 예를 들어, 일시적으로, 캐싱되기 부적합한 것으로 식별되는 모든 애플리케이션 클라이언트 또는 애플리케이션에 대해, (타이밍, 주기성, 응답 콘텐츠 변화 빈도, 콘텐츠 예측성, 크기, 등을 기초로) 특정 검출 특성을 갖는 것만 블랙리스트에 올라갈 수 있다.

블랙리스트의 항목은 (도착지보다는) 모바일 장치상의 요청하는 애플리케이션 또는 요청하는 클라이언트의 리스트를 포함할 수 있어서, 특정 애플리케이션 또는 특정 클라이언트로부터 요청이 검출될 때, 응답을 위해, 네트워크를 통해 전송될 수 있는데, 이는 블랙리스트의 클라이언트/애플리케이션이 대부분의 상황에서 캐싱되지 않기 때문이다.

애플리케이션이 액세스되는 모바일 장치와 연계된 모바일 계정에 따라, 특정 애플리케이션 프로파일이 상이하게(가령, 로컬 프록시(275) 및 원격 프록시(325)의 상이한 거동) 취급되거나 처리될 수 있다. 예를 들어, 더 많이 지불하는 계정, 즉 프리미어 계정은 무선 네트워크의 더 빈번한 액세스, 또는 더 높은 대역폭 허용을 가능하게 할 수 있고, 따라서 자원의 보존에 비교되는 더 우수한 성능을 강조하면서, 로컬 프록시(275)와 프록시 서버(325) 사이에 구현되는 캐싱 정책에 영향을 미칠 수 있다. 특정 애플리케이션 프로파일은 서로 다른 무선 네트워크 상태 하에서(가령, 혼잡이나 네트워크 작동불능 상태(network outage) 등을 기초로) 상이하게 취급되거나 처리될 수 있다.

모바일 장치(250) 상의 복수의 클라이언트 또는 애플리케이션에 대해 캐시 적절성이 결정, 추적, 및 관리될 수 있다. 모바일 장치(250) 상의 특정 클라이언트 또는 애플리케이션에 의해 개시되는 여러 다른 요청, 또는 요청 유형에 대해, 캐시 적절성이 또한 결정될 수 있다. 캐싱 정책 관리기(245)는, 예측가능함, 또는 예측가능할 가능성이 있음을 경험적으로(heuristically) 결정하거나 추정하는 타이밍 예측기(246a) 및/또는 콘텐츠 예측기(246b)와 함께, 다양한 애플리케이션, 또는 특정 애플리케이션에 대한 다양한 요청에 대한 캐싱 가능함 정보를 추적, 관리, 및 저장할 수 있다. 캐싱 가능함 정보는 또한 조건(가령, 애플리케이션이 하루 중 특정 시간대에서, 또는 일주일 중 특정 요일에 캐싱될 수 있거나, 특정 애플리케이션의 특정 요청이 캐싱될 수 있거나, 특정 도착지 주소를 갖는 모든 요청이 캐싱될 수 있다)을 포함할 수 있으며, 상기 조건 하에서, 캐싱이 적절하고, 상기 조건은, 캐시 적절성 판단 엔진(246)에 의해 결정 및/또는 추적될 수 있고, 캐시 적절성 판단 엔진(246)에 연결되는 애플리케이션 캐시 정책 레포지토리(243)에 적절하게 저장 및/또는 업데이트될 수 있다.

요청, 애플리케이션, 및/또는 연계된 조건의 캐싱 가능함과 관련된, 애플리케이션 캐시 정책 레포지토리(243)의 정보는, 추후 동일한 요청이 검출될 때 사용될 수 있다. 이러한 방식으로, 판단 엔진(246) 및/또는 타이밍 및 콘텐츠 예측기(246a/b)는, 캐싱 가능함에 대해 평가하기 위해, 요청/응답 타이밍 및 콘텐츠 특성을 추적하고 재분석할 필요가 없다. 덧붙이자면, 일부 경우, 캐싱 가능함 정보는, 직접 통신을 통해, 또는 호스트 서버(가령, 호스트 서버(300)의 프록시 서버(325))를 통해, 또 다른 모바일 장치의 로컬 프록시와 공유될 수 있다.

예를 들어, 다양한 모바일 장치 상의 로컬 프록시(275)에 의해 검출된 캐싱 가능함 정보가 호스트 서버 상의 원격 호스트 서버 또는 프록시 서버(325)(가령, 도 3A의 예시의 경우, 호스트 서버(300) 또는 프록시 서버(325), 또는 도 1A-B의 예시의 경우 프록시 서버(125))로 전송될 수 있다. 그 후, 원격 호스트 또는 프록시 서버가 애플리케이션 특정적, 요청 특정적 캐싱 가능함 정보, 및/또는 임의의 연계된 조건에 대한 정보를, 사용되기 위해, 하나의 무선 네트워크 내에 있거나, 복수의 무선 네트워크들에 걸쳐 있는(동일한 서비스 제공자이거나 복수의 무선 서비스 제공자) 다양한 모바일 장치 또는 그들의 로컬 프록시에게 분산시킬 수 있다. 일반적으로, 캐싱을 위한 선택 기준은, 예를 들어, 모바일 장치가 활성 상태인지 비활성상태인지 여부를 나타내는 모바일 장치의 상태, 네트워크 조건, 및/또는 라디오 커버리지 통계치(radio coverage statistic)를 더 포함할 수 있다. 캐시 적절성 판단 엔진(246)은, 기준들 중 임의의 하나 이상으로, 임의의 순서로, 캐싱이 적합할 수 있는 소스를 식별할 수 있다.

애플리케이션 서버/콘텐츠 제공자가 모바일 장치(250) 상에 로컬 캐싱되기 적합할 가능성이 있다고 식별된 또는 검출된 콘텐츠를 가진다면, 캐시 정책 관리기(245)는, 콘텐츠 소스로부터 수신된 콘텐츠를 모바일 장치(250) 상의 로컬 캐시(가령, 도 1B와 도 2A의 예시의 경우, 로컬 캐시(185 또는 285))의 캐시 요소로서 저장함으로써 식별된 소스로부터 수신된 연계된 콘텐츠를 계속 캐싱할 수 있다.

응답이 캐시 엔트리로서 캐시(285)(가령, 또한 로컬 캐시라고도 지칭됨)에 저장될 수 있다. 요청에 대한 응답에 덧붙여, 캐싱된 엔트리가 응답의 캐싱과 관련된 추가 정보를 갖는 응답 메타데이터를 포함할 수 있다. 메타데이터는 메타데이터 생성기(203)에 의해 생성될 수 있고, 예를 들어, 타이밍 데이터(가령, 캐시 엔트리의 액세스 시간, 또는 캐시 엔트리의 생성 시간(creation time))를 포함할 수 있다. 메타데이터는 추가 정보, 가령, 캐싱된 엔트리로서 저장되는 응답이 다음 번 응답을 만족시키기 위해 사용되는지 여부를 결정하는 데 사용되기 적합한 임의의 정보를 포함할 수 있다. 예를 들어, 메타데이터 정보는, 요청 타이밍 히스토리(가령, 요청 시간, 요청 시작 시점, 요청 종료 시점을 포함하는 요청 타이밍 히스토리), 요청 및/또는 응답의 해시(hash), 시간격, 또는 시간격의 변화 등을 더 포함할 수 있다.

캐시 엔트리는, 예를 들어, 캐시 무효화기(244)의 TTL 관리기(244a)에 의해 할당되거나 결정될 수 있는 수명시간(TTL: time-to-live)과 연계되어 캐시(285)에 저장되는 것이 일반적이다. 응답이 여전히 유효한지 또는 모바일 장치(250) 상의 특정 요청 또는 클라이언트/애플리케이션에 대해 관련이 있는지 여부에 무관하게, 캐시 엔트리의 수명시간은 엔트리가 캐시(285) 내에서 영속하는 시간이다. 예를 들어, 특정 캐시 엔트리의 수명시간이 12시간으로 설정되는 경우, 캐시 엔트리 내에 포함된 응답 본체가 여전히 유효하고, 관련 요청에 대해 적용 가능할지라도, 캐시 엔트리는 삭제 또는 제거되거나, 그 밖의 다른 방식으로 초과된 수명시간을 갖고 있음이 지시된다.

(가령, TTL 관리기(244a)에 의해) 다르게 특정되지 않는 한, 모든 엔트리에 대해 자동으로 디폴트 수명시간이 사용되거나, 개별 TTL(가령, 다양한 동적 또는 정적 기준을 기초로 하여 TTL 관리기(244a)에 의해 결정된 TTL)을 이용해 각각의 캐시 엔트리가 생성될 수 있다. 각각의 엔트리는 응답 데이터 및 임의의 연계된 메타데이터 모두와 연계된 단일 수명시간을 가질 수 있다. 일부 경우, 연계된 메타데이터는 응답 데이터와 상이한 수명시간(가령, 더 긴 수명시간)을 가질 수 있다. 캐시 엔트리의 데이터 모델의 표현의 예가 도 24 및 도 25에 도시된다.

이에 추가로, 또는 이를 대신하여, 모바일 장치(250)의 원격에 위치하며 상기 모바일 장치(250)와 무선 통신하는 프록시 서버(가령, 도 1B 및 도 3A의 예시의 경우 프록시 서버(125 또는 325))에게 캐싱될 콘텐츠를 갖는 콘텐츠 소스를 알려서, 새로운 또는 변경된 데이터에 대해 프록시 서버가 콘텐츠 소스(가령, 애플리케이션 서버/콘텐츠 제공자(110))를 모니터할 수 있다. 마찬가지로, 로컬 프록시(가령, 도 1B 및 도 2A의 로컬 프록시(175 또는 275))가 프록시 서버에게, 특정 애플리케이션 서버/콘텐츠 제공자로부터 수신된 콘텐츠가 로컬 캐시(285) 내 캐싱되는 요소로서 저장되어 있다고 알릴 수 있다.

콘텐츠가 로컬하게 캐싱되어 있는 경우, 폴링 요청을 서비스하기 위해 모바일 장치의 라디오가 활성화되지 않도록, 캐시 정책 관리기(245)가 애플리케이션 서버/콘텐츠 호스트(가령, 110 또는 310)를 접촉하기 위한 미래의 폴링 요청을 수신하면, 로컬 캐시로부터 캐싱된 요소를 불러와서, 모바일 장치(250)에서 만들어진 폴링 요청에 응답할 수 있다. 예를 들어, 서비스될 응답이 응답인지 확인하기 위해 캐시 룩-업 엔진(205)이 캐시(285)에게 질의할 수 있다. 일치하는 캐시 엔트리를 식별하는 것과 또한 캐시 엔트리에 응답과 함께 저장된 임의의 메타데이터를 이용하는 것에 응답하여 응답이 캐시로부터 서비스될 수 있다. 요청의 URI 또는 또 다른 유형의 식별자를 이용해(가령, ID 또는 URI 필터(205a)를 통해) 캐시 룩-업 엔진에 의해 캐시 엔트리가 질의될 수 있다. 캐시 룩-업 엔진(205)은, 현재 요청에 대해 서비스될 때 응답이 사용되기에 여전히 적합한지 여부를 결정하기 위해, 일치되는 캐시 엔트리와 함께 저장된 메타데이터를 더 사용할 수 있다(가령, 임의의 타이밍 정보 또는 그 밖의 다른 관련 정보를 추출할 수 있다).

다양한 복수의 전략들 중 하나 이상을 이용해 엔진(205)에 의한 캐시 룩-업이 수행될 수 있다. 하나의 실시예에서, 적어도 하나의 룩-업 전략에 일치되는 캐시 엔트리를 식별할 때까지, 캐시(285)에 저장된 각각의 엔트리에 대해 복수의 룩-업 전략이 순차적으로 수행될 수 있다. 캐시 룩-업을 수행하기 위해 사용되는 전략은, 엄격한 일치 기준, 또는 비-일치 파라미터를 허용하는 일치 기준을 포함할 수 있다.

예를 들어, 룩-업 엔진(205)은, 프록시가 캐시 엔트리를 식별하려 시도하는 중인 현재 요청에서 참조되는 식별자(가령, 호스트 또는 자원에 대한 URI)와 캐시 엔트리와 함께 저장된 식별자 간의 정확한 일치를 찾는 엄격한 일치 전략을 수행할 수 있다. 식별자가 URI 또는 URL을 포함하는 경우, 엄격한 일치를 위한 일치 알고리즘이 URL 내 모든 파라미터에 일치하는 캐시 엔트리를 찾을 것이다. 예를 들면:

예시 1.

1. 캐시가 http://test.com/products/에 대한 엔트리를 포함한다.

2. 요청이 URI http://test.com/products/로 이뤄지는 중이다.

두 URI가 모두 동일하기 때문에, 엄격한 전략이 일치하는 것을 찾을 것이다.

예시 2.

1. 캐시가 http://test.com/products/?query=all에 대한 엔트리를 포함한다.

2. 요청이 URI http://test.com/products/?query=sub로 이뤄지는 중이다.

앞서 요약된 엄격한 전략 하에서, 질의 파라미터에서 URI가 상이하기 때문에, 일치하는 것이 발견되지 않을 것이다.

또 다른 예시적 전략에서, 룩-업 엔진(205)은, 프록시가 일치하는 캐시 엔트리를 식별하려 시도하는 현재 요청 내 식별자 참조와 부분적으로 일치되는 식별자를 이용해 캐시 엔트리를 찾는다. 예를 들어, 룩-업 엔진(205)은 요청 식별자와 질의 파라미터 값이 상이한 식별자를 이용해 캐시 엔트리를 찾을 수 있다. 이러한 전략을 이용할 때, 룩-업 엔진(205)은 복수의 이전 요청에 대해 수집된 정보(가령, 식별자 내 임의의 파라미터들의 리스트)를 수집하여, 현재 요청의 검출된 임의의 파라미터를 이용해, 추후 체크되도록 할 수 있다. 예를 들어, URI 또는 URL 식별자와 함께 캐시 엔트리가 저장되는 경우, 룩-업 엔진이, 질의 파라미터가 상이한 URI를 이용해 캐시 엔트리를 검색한다. 발견된 경우, 엔진(205)은 이전 요청 동안 수집되거나, 현재 URI/URL에서 검출되거나 상기 현재 URI/URL로부터 추출된 임의의 파라미터가 임의의 파라미터 리스트에 속하는지 여부가 체크된 정보(가령, 임의의 파라미터의 리스트)를 찾기 위해 캐시 엔트리를 검사할 수 있다.

예시 1.

1. 캐시가 http://test.com/products/?query=all에 대한 엔트리를 포함하며, 여기서 질의는 임의(arbitrary)라고 표시된다.

2. URI http://text.com/products/?query=sub로 요청이 이뤄지는 중이다.

질의 파라미터가 임의라고 표시되어 있기 때문에 일치함이 발견될 것이다.

예시 2.

1. 캐시가 http://test.com/products/?query=all에 대한 엔트리를 포함하며, 질의가 임의라고 표시된다.

2. URI http://test.com/products/?query=sub&sort=asc로 요청이 이뤄지는 중이다.

현재 요청이 캐시 엔트리에서 임의라고 표시되지 않은 파라미터를 포함하기 때문에, 일치함이 발견되지 않을 것이다.

캐시 히트(cache hit)를 검출하기 위한 추가 전략이 채용될 수 있다. 이들 전략은 단독으로, 또는 임의의 조합으로, 구현될 수 있다. 이들 전략 중 임의의 하나가, 일치함을 결정할 때 캐시 히트가 결정될 수 있다. 어떠한 이유로든 요청된 데이터가 캐시(285)로부터 서비스될 수 없다고 룩-업 엔진(205)이 결정할 때 캐시 미스(cache miss)가 지시될 수 있다. 예를 들어, 임의의 또는 모든 이용되는 룩-업 전략에 대해 어떠한 캐시 엔트리도 식별되지 않을 때 캐시 미스가 결정될 수 있다.

일치하는 캐시 엔트리가 존재하지만 현재 요청에 대해 무효하다고 또는 관련 없다고 결정될 때도 역시 캐시 미스가 결정될 수 있다. 예를 들어, 룩-업 엔진(205)은 일치하는 캐시 엔트리와 연계된 메타데이터(가령, 캐시 엔트리의 타이밍 데이터를 포함할 수 있는 메타데이터)를 더 분석하여, 현재의 요청에 응답할 때 사용되기에 여전히 적합한지 여부를 결정할 수 있다.

룩-업 엔진(205)이 캐시 히트(가령, 요청된 데이터가 캐시로부터 서비스될 수 있다고 가리키는 이벤트)를 식별할 때, 일치하는 캐시 엔트리에 저장된 응답이 캐시로부터 서비스되어, 애플리케이션/클라이언트의 요청을 만족시킬 수 있다.

캐시(285)에 저장된 캐시 엔트리를 이용해 요청을 서비스함으로써, 네트워크 대역폭 및 그 밖의 다른 자원이, 모바일 장치(250)에서 이미 수신된 적이 있는 응답에서 변경되지 않았을 수 있는 폴 응답을 요청/수신하도록 사용될 필요가 없다. 이러한 서비스 및 이행 애플리케이션(가령, 모바일 애플리케이션)의 요청을 로컬 캐시(285) 내 캐시 엔트리를 통해 서비스하고 이행함으로써, 요청이, 대역폭을 추가로 소모하는 무선 네트워크를 통해 전송될 필요가 없기 때문에, 더 효율적인 자원 및 모바일 네트워크 트래픽 활용 및 관리가 가능해진다. 일반적으로, 캐시(285)는 모바일 장치(250)의 전원 켜기와 끄기 사이에서 지속될 수 있고, 애플리케이션/클라이언트 리프레시와 재시작 사이에서도 지속될 수 있다.

예를 들어, 로컬 프록시(275)는, 모바일 장치(250) 상의 자신의 모바일 장치(250) 또는 애플리케이션 또는 그 밖의 다른 유형의 클라이언트로부터의 아웃고잉 요청을 수신하면, 요청을 인터셉트하고, 모바일 장치(250)의 로컬 캐시(285)에 캐싱된 응답이 이용가능한지 여부를 결정한다. 로컬 캐시(285)에 캐싱된 응답이 이용가능한 경우, 아웃고잉 요청에, 모바일 장치의 캐시 상의 캐싱된 응답을 이용해 로컬 프록시(275)가 응답한다. 따라서 무선 네트워크를 통해 아웃고잉 요청을 전송할 필요 없이, 아웃고잉 요청이 충족될 수 있으며, 따라서, 네트워크 자원 및 배터리 소모량이 보존된다.

하나의 실시예에서, 콘텐츠 서버가 지속형 연결(persistent connection)을 통해(가령, 로컬 프록시에 의한 인터셉트 없이 확립됐을 지속형 연결, 또는 장기 유지(long-held) HTTP 연결, 또는 롱 폴 유형 연결을 통해) 아웃고잉 요청에 응답했을 방식에 대응하도록, 장치(250) 상의 요청하는 애플리케이션/클라이언트에 응답하는 것의 타이밍이 정해진다. 의도된 콘텐츠 소스(가령, 도 1A-B의 콘텐츠 호스트/애플리케이션 서버(110))로부터 수신된 프레시 콘텐츠가 아닌 로컬 캐시(285)로부터 저장된 콘텐츠를 서비스함으로써 최종 사용자 경험이 반영되지 않거나, 최소한만 반영되도록 애플리케이션 거동을 보존하기 위해, 로컬 프록시(275)에 의해 응답의 타이밍이 에뮬레이트되거나 시뮬레이트될 수 있다. 타이밍은, 정확하게 복제되거나, 사용자가 알아차리지 않을 수 있거나 동작 문제를 일으키지 않도록 애플리케이션에 의해 유사하게 처리될 수 허용오차 파라미터 내로 추정될 수 있다.

예를 들어, 아웃고잉 요청은, 콘텐츠 서버(가령, 도 1A-1B의 예의 경우, 애플리케이션 서버/콘텐츠 제공자)에 대해 의도된 지속형 연결에 대한 요청일 수 있다. 콘텐츠 소스(서버)와의 지속형 연결(가령, 롱 폴, COMET-스타일 푸시, 또는 비동기식 HTTP 요청에서의 그 밖의 다른 임의의 푸시 시뮬레이션, 장기 유지 HTTP 요청, HTTP 스트리밍, 등)에서, 요청이 전송된 후 연결이 임의의 시간 동안 유지된다. 모바일 장치와 서버 간의 연결은, 콘텐츠가 모바일 장치로 전송되기 위해 서버에서 이용가능할 때까지, 지속될 수 있는 것이 일반적이다. 따라서 일반적으로, 롱 폴 요청이 전송되는 시점과 콘텐츠 소스로부터 요청이 수신되는 시점 사이에 약간의 시간 지연이 있을 수 있다. 콘텐츠 소스에 의해 특정 시간 동안 응답이 제공되지 않는 경우, 응답이 전송되지 않은 경우 네트워크 이유로(가령, 소켓 폐쇄(socket closure)로) 연결이 종료될 수 있다.

따라서 콘텐츠 서버로부터 지속형 연결(가령, 롱 폴 스타일 연결)을 통해 전송되는 응답을 에뮬레이트하기 위해, 아웃고잉 요청에 캐싱된 응답으로 응답하기 전에 시간격이 경과되게 함으로써, 콘텐츠 서버의 응답의 방식이 시뮬레이트될 수 있다. 예를 들어, 요청별로, 또는 애플리케이션별로(클라이언트별로) 시간격의 길이가 결정될 수 있다.

하나의 실시예에서, 아웃고잉 요청이 발원되는 모바일 장치 상의 애플리케이션의 요청 특성(가령, 타이밍 특성)을 기초로, 시간격이 결정된다. 예를 들어, 로컬 캐시 엔트리로 요청에 응답하기 전에 기다리기 위한 시간격을 결정하기 위해 폴 요청 간격이 사용되고, 응답 스케줄러(249a)에 의해 관리될 수 있다.

캐시 정책 관리기(245)의 한 가지 실시예는 폴 스케줄 생성기(247)를 포함하고, 폴 스케줄 생성기(247)는 모바일 장치(250) 상의 하나 이상의 애플리케이션에 대해 폴링 스케줄을 생성할 수 있다. 폴링 스케줄은, 모바일 장치를 대신하여 (요청이 전달되는 호스트 서버(호스트 서버(110 또는 310))로 폴링함으로써, 캐싱된 응답이 주기적으로 검증될 수 있도록) 하나 이상의 애플리케이션에 대해 콘텐츠 소스를 모니터링할 때 모바일 장치(250)와 물리적으로 구별 및/또는 구분되는 개체에 의해 사용될 수 있는 폴링 간격을 특정할 수 있다. 모바일 장치(250)를 위해 소스에서 콘텐츠를 모니터링할 수 있는 이러한 외부 개체의 한 가지 예로는 프록시 서버(가령, 도 1B 및 도 3A-C의 예에서 도시되는 프록시 서버(125 또는 325))가 있다.

예를 들어, 모바일 장치로부터 콘텐츠 소스로 전달되는 폴링 요청들 간 간격을 기초로 하여, 폴링 스케줄(가령, 폴링 속도/빈도(rate/frequency))이 결정될 수 있다. 모바일 장치(250)에서 (로컬 프록시에 의해) 폴링 스케줄 또는 폴링 속도가 결정될 수 있다. 하나의 실시예에서, 애플리케이션 거동 검출기(236)의 폴 간격 검출기(238)가 모바일 장치(250)로부터 콘텐츠 소스로 전달되는 폴링 요청을 모니터링하여, 임의의 또는 모든 애플리케이션(가령, 모바일 애플리케이션)으로부터 이뤄진 폴링 요청들 간 간격을 결정할 수 있다.

예를 들어, 폴 간격 검출기(238)는 장치(250) 상의 애플리케이션 또는 클라이언트에 대해 요청과 응답을 추적할 수 있다. 하나의 실시예에서, 동일한 모바일 클라이언트 또는 애플리케이션(가령, 모바일 애플리케이션)에 의해 모바일 장치(250) 상의 애플리케이션(가령, 모바일 애플리케이션)으로부터 개시된 아웃고잉 요청의 검출 전에, 연속하는 요청들이 추적된다. 응답이 캐싱되는 요청에 대해 수집된 요청 정보를 이용해, 폴링 속도(polling rate)가 결정될 수 있다. 하나의 실시예에서, 요청을 생성한 동일한 클라이언트에 의해 생성되는 이전 요청들 사이의 시간격들의 평균으로부터 폴링 속도가 결정된다. 예를 들어, 현재 요청과 이전 요청 사이에서 제 1 간격이 계산될 수 있고, 2개의 이전 요청들 사이에서 제 2 간격이 계산될 수 있다. 제 1 간격과 제 2 간격의 평균으로부터 폴링 속도(polling rate)가 설정될 수 있고, 캐싱 전략을 설정할 때 프록시 서버로 전송될 수 있다.

평균을 생성할 때, 대안적 간격이 계산될 수 있는데, 가령, 2개의 이전 요청들에 추가되는 복수의 이전 요청들이 사용될 수 있고, 평균을 계산할 때, 셋 이상의 간격이 사용될 수 있다. 일반적으로, 간격을 계산할 때, 특정 요청이, 호스트 서버/콘텐츠 소스로부터 간격 계산을 위해 사용되기 위한 응답을 수신할 필요가 없다. 즉, 요청이 검출되는 한, 요청 전송에 실패한 경우, 또는 응답 불러오기에 실패한 경우라도, 간격 계산에서 특정 요청의 타이밍 특성이 사용될 수 있다.

폴 스케줄 생성기(247)의 한 가지 실시예는 스케줄 업데이트 엔진(247a 및/또는 시간 조정 엔진(247b))을 포함한다. 스케줄 업데이트 엔진(247a)은, 모바일 장치(250) 상의 클라이언트 또는 애플리케이션(가령, 모바일 애플리케이션)으로부터 생성된 실제 요청에서 검출된 간격 변화를 기초로, 이전 설정된 값으로부터 특정 애플리케이션 서버/콘텐츠 호스트가 이용하는 속도(rate) 또는 폴링 간격을 업데이트할 필요가 있는지 여부를 결정할 수 있다.

예를 들어, 모니터링 속도(monitoring rate)를 결정하라는 요청이 서로 다른 요청 간격에서 애플리케이션(가령, 모바일 애플리케이션) 또는 클라이언트로부터 전송될 수 있다. 스케줄링된 업데이트 엔진(247a)이 실제 요청의 업데이트된 폴링 간격을 결정하고, 이전에 설정된 속도(rate)와 상이한, 모바일 장치(250)를 대리하여 호스트로 폴링하기 위한 새로운 속도를 생성할 수 있다. 업데이트된 폴링 속도가, 셀룰러 네트워크를 통해 원격 프록시(프록시 서버(325))로 전달되어, 원격 프록시가 특정 호스트를 모니터링할 수 있다. 일부 경우, 호스트를 모니터링하는 원격 프록시 또는 원격 개체에서 업데이트된 폴링 속도가 결정될 수 있다.

하나의 실시예에서, 시간 조정 엔진(247b)이, 애플리케이션 서버/콘텐츠 소스(110 또는 310)를 모니터링하기 위해 생성된 폴 스케줄을 더 최적화할 수 있다. 예를 들어, 선택사항으로서, 시간 조정 엔진(247b)이 프록시 서버로 폴링하기 시작할 시간을 특정할 수 있다. 예를 들어, 프록시 서버가 애플리케이션을 모니터링하는 폴링 간격을 설정하는 것에 추가로, 서버/콘텐츠 호스트가 모바일 클라이언트/애플리케이션에서 실제 요청이 생성되는 시간을 특정할 수 있다.

그러나 일부 경우, 내재적인 전송 지연 또는 추가되는 네트워크 지연 또는 그 밖의 다른 유형의 대기시간(latency) 때문에, 원격 프록시 서버가 약간의 지연(가령, 수 분, 또는 수 초)을 두고 로컬 프록시로부터 폴 설정을 수신한다. 이는, 모바일 클라이언트/애플리케이션에 의해 요청이 발생한 후, 소스에서의 응답 변화를 검출하는 효과를 가지며, 이는, 응답이 더 이상 현재이거나 유효하지 않은 후 다시 한 번 애플리케이션으로 서비스된 후 캐싱된 응답의 무효화가 발생하도록 한다. 이러한 불일치는 도 21의 데이터 타이밍도로 추가로 도시된다.

날짜가 지난 콘텐츠(out-dated content)를 무효화하기 전에 다시 한 번 서비스하는 이러한 최적화되지 않은 결과를 해결하기 위해, 시간 조정 엔진(247b)은 속도(rate)에 추가로 폴링이 시작해야 하는 시점(t0)을 특정할 수 있으며, 여기서, 특정된 초기 시점(t0)은, 프록시 서버(325)에게, 모바일 애플리케이션/클라이언트에 의해 요청이 발생될 때 실제 시간보다 짧은 시간으로 특정되어 알려진다. 이러한 방식으로, 실제 애플리케이션 요청 전에 임의의 콘텐츠 변화가 검출될 수 있도록, 모바일 클라이언트에 의해 실제 요청이 발생하기 약간 전에, 서버가 자원에게 폴링한다. 이는 무효 또는 무관한 날짜가 지난 콘텐츠/응답이, 프레시 콘텐츠(fresh content)가 서비스되기 전에 다시 한 번 서비스되는 것을 방지한다.

하나의 실시예에서, 모바일 장치(250)로부터의 아웃고잉 요청이, 모바일 장치(250) 상의 동일한 애플리케이션 또는 클라이언트로부터의 이전 요청의 타이밍 특성을 기초로 하는, 지속형 연결(가령, 롱 폴, COMET 스타일 푸시, 및 장기 유지 (HTTP) 요청)을 위한 것이라고 검출된다. 예를 들어, 폴 간격 검출기(238)의 롱 폴 검출기(238a)의 요청/응답 추적 엔진(238b)에 의해 요청 및/또는 이에 대응하는 응답이 추적될 수 있다.

연속하는 요청의 타이밍 특성은 애플리케이션 또는 클라이언트에 대한 폴링 스케줄을 설정하도록 결정될 수 있다. 폴링 스케줄은 콘텐츠 변경을 찾기 위해 콘텐츠 소스(콘텐츠 소스/애플리케이션 서버)를 모니터하도록 사용되어, 모바일 장치(250) 내 로컬 캐시 상에 저장된 캐싱된 콘텐츠가 적절하게 관리(가령, 업데이트되거나 폐기)될 수 있다. 하나의 실시예에서, 타이밍 특성은, 예를 들어, 응답 지연 시간('D') 및/또는 유휴 시간(idle time)('IT')을 포함할 수 있다.

롱 폴의 통상의 응답 지연 시간 및 유휴 시간이 타이밍도로 도시되며, 이는 이하에서 나타나고 도 17A-B를 참조하여 상세히 더 설명될 것이다. 하나의 실시예에서, 출원인 또는 클라이언트 요청에 대한 타이밍도를 결정, 계산, 및/또는 추정하기 위해, 응답/요청 추적 엔진(238b)이 요청과 응답을 추적할 수 있다.

예를 들어, 제 1 요청에 따라 모바일 장치에서 응답이 수신된 후, 응답/요청 추적 엔진(238b)이, 모바일 장치 상의 클라이언트에 의해 개시되는 제 1 요청(요청0)과, 모바일 장치 상의 클라이언트에 의해 개시되는 제 1 요청(요청1)을 검출한다. 제 2 요청은 제 1 요청에 뒤따르는 요청이다. 요청들 간 관계가 도 17A-B의 타이밍도에서 나타날 수 있다.

하나의 실시예에서, 응답/요청 추적 엔진(238b)이 요청 및 응답을 추적하여, 애플리케이션 또는 클라이언트 요청에 대한 타이밍도를 결정, 계산, 및/또는 추정할 수 있다. 제 1 요청에 따라 모바일 장치에서 응답이 수신된 후, 응답/요청 추적 엔진(238b)은, 모바일 장치 상의 클라이언트에 의해 개시되는 제 1 요청과, 모바일 장치 상의 클라이언트에 의해 개시되는 제 2 요청을 검출할 수 있다. 제 1 요청은 제 1 요청에 뒤따르는 요청이다.

응답/요청 추적 엔진(238b)은 제 1 요청, 제 2 요청, 및 상기 제 1 요청에 따라 수신된 응답 간의 상대적 타이밍을 더 결정한다. 일반적으로 애플리케이션에 의해 생성되는 요청이 롱 폴 요청인지 여부를 결정하기 위해, 상대적 타이밍이 롱 폴 검출기(238a)에 의해 사용될 수 있다.

일반적으로, 상대적 타이밍을 계산할 때 응답/요청 추적 엔진(238b)에 의해 사용되는 제 1 요청 및 제 2 요청이, 롱 폴 헌팅 주기가 정착된 후, 또는 롱 폴 헌팅이 발생하지 않는 경우에, 사용되기 위해 선택된다. 롱 폴 헌팅 주기의 일반적인 타이밍 특성이 도 8의 예시에서 도시되며, 예를 들어, 롱 폴 헌팅 검출기(238c)에 의해 검출될 수 있다. 즉, 응답/요청 추적 엔진(238b)에 의해 추적되며, 특정 요청이 롱 폴인지 여부를 결정하기 위해 사용되는 요청은, 롱 폴이 정착된 후(가령, 헌팅 모드(805)가 완료된 후 도 8의 810으로 도시됨), 발생한다.

하나의 실시예에서, 롱 폴 헌팅 검출기(238c)는, 증가하는 요청 간격(가령, 증가하는 지연 시간) 및 이에 뒤따르는 어떠한 응답도 없는 요청(가령, 연결이 타임 아웃됨)을 검출함으로써, 또는 증가하는 요청 간격 및 이에 뒤따르는 간격의 감소를 검출함으로써, 헌팅 모드를 식별하거나 검출할 수 있다. 덧붙이자면, 롱 폴 헌팅 검출기(238c)가 필터 값 또는 임계값을, 그 이상에서 검출된 지연이 롱 폴 요청-응답 지연이라고 간주될 수 있는 요청-응답 시간 지연 값(가령, 절댓값)에 적용할 수 있다. 필터 값은 롱 폴의 임의의 적합한 값 특성 및/또는 네트워크 조건(가령, 2초, 5초, 10초, 15초, 20초, 등)일 수 있으며, 필터 또는 임계값으로서 사용될 수 있다.

응답 지연 시간('D')은, 요청이 전송된 후 응답을 수신하기 위한 시작 시점을 지칭하고, 유휴(idle)는 응답이 수신된 후 뒤따르는 요청을 전송하기 위한 시간을 지칭한다. 하나의 실시예에서, 응답 지연 시간('D') 또는 ('D')의 평균(가령, 임의의 시간 주기 동안의 임의의 평균)의 유휴 시간('IT')에 대한 비교(가령, 추적 엔진(238b)에 의해 수행되는 비교)를 토대로, 예를 들어, 롱 폴 검출기(238a)에 의해, 아웃고잉 요청이 지속형 연결에 대한 것이라고 검출된다. 사용되는 평균의 개수는 고정되거나, 동적으로 조절되거나, 더 긴 시간 동안 변경될 수 있다. 예를 들어, 응답 지연 시간 간격이 유휴 시간 간격보다 큰 경우(D>IT 또는 D>>IT), 클라이언트에 의해 개시되는 요청이 롱 폴 요청이라고 결정된다. 하나의 실시예에서, 롱 폴 검출기의 추적 엔진(238b)이 응답 지연 시간 간격을, 제 1 요청의 시점과 응답의 초기 검출 또는 완전 수령 시점 사이에 경과된 시간의 크기로서, 계산, 결정, 또는 추정한다.

하나의 실시예에서, 예를 들어, 롱 폴 요청 또는 롱 폴 HTTP 요청에 대한 응답에서 확립된 지속형 연결이, 이전 요청에 대한 응답의 수신 후 다음번 요청의 즉각적인 또는 거의 즉각적인 발생을 검출하는 것을 특징으로 갖기 때문에, 유휴 시간('IT')이 짧을 때(가령, IT~0), 요청은 지속형 연결에 대한 것이라고 검출된다. 따라서, 유휴 시간('IT')이 이러한 즉각적이거나 거의 즉각적인 재-요청을 검출하도록 사용되어, 롱 폴 요청을 식별할 수 있다. 제 1 요청에 대한 응답이 수신된 후, 추적 엔진(238b)에 의해 결정된 절대 또는 상대적 타이밍이 사용되어, 제 2 요청이 즉각적이거나 거의 즉각적으로 재-요청됐는지 여부를 결정할 수 있다. 예를 들어, IT가 작아서 D+RT+IT~D+RT인 경우, 요청이 롱 폴 요청이라고 카테고리화될 수 있다. IT는 임계값보다 작은 경우 작은 것으로 판단될 수 있다. 임계값은 고정되거나, 짧은 시간 주기(1세션, 1일, 1달 등) 동안 계산될 수 있거나, 더 긴 시간 주기(가령, 몇 달, 또는 분석의 수명) 동안 계산될 수 있다. 예를 들어, 매 요청에 대하여, 평균 IT가 계산될 수 있고, 이 평균 IT를 이용하여 임계치가 결정될 수 있다(가령, 특정 퍼센티지 미만의 평균 IT가 임계치로서 사용될 수 있다). 이로 인하여, 시간의 흐름에 따라 임계치는 네트워크 상태 및 서버 수용력의 변경, 자원 이용가능도 또는 서버 응답의 변경에 자동으로 적응될 수 있다. 고정된 임계치는 임의의 값(예를 들어, 1s, 2s, 3s,... 등, 그러나 이에 제한되지 않음)을 취할 수 있다.

하나의 실시예에서, 롱 폴 검출기(238a)는, (가령, 추적 엔진(238b)에 의해 결정된) 상대적 타이밍을, 타 애플리케이션에 대한 요청-응답 타이밍 특성에 비교하여, 애플리케이션의 요청이 롱 폴 요청인지 여부를 결정할 수 있다. 예를 들어, 응답 지연 간격 시간(가령, x번의 요청에 대한 평균, 또는 x 시간에 걸쳐 평균내진 임의의 개수의 지연 간격 시간)이 임계값보다 큰 경우, 클라이언트 또는 애플리케이션에 의해 개시되는 요청이 롱 폴 요청이라고 결정될 수 있다.

타 클라이언트에 의해, 예를 들어, 요청/응답 추적 엔진(238b)에 의해 및/또는 애플리케이션 프로파일 생성기(239)(가령, 응답 지연 간격 추적기(239a))에 의해, 발생된 요청에 대해 응답 지연 간격 시간을 이용해 임계값이 결정될 수 있다. 상기 타 클라이언트는 동일한 모바일 장치에 상주할 수 있고, 모바일 장치상의 구성요소에 의해 임계값이 로컬하게 결정된다. 예를 들어, 모든 네트워크에 걸쳐 있는 모든 자원 서버에 대한 모든 요청에 대해 임계값이 결정될 수 있다. 모든 요청 또는 적용 가능한 임계값을 갖지 않는 임의의 요청에 대해 사용되도록 임계값이 특정 상수 값(가령, 30초)으로 설정될 수 있다(가령, D>30초인 경우 롱 폴이 검출된다).

일부 경우, 상기 타 클라이언트가 서로 다른 모바일 장치상에 상주하며, 임계치가, 모바일 장치 외부에 위치하며, 무선 네트워크를 통해 복수의 서로 다른 모바일 장치와 통신할 수 있는 프록시 서버(가령, 도 3A-B의 예시의 경우, 호스트(300)의 프록시 서버(325))에 의해 결정될 수 있으며, 이는 도 3B를 참조하여 더 설명될 것이다.

하나의 실시예에서, 캐시 정책 관리기(245)가 폴링 스케줄을 프록시 서버(가령, 도 1B 및 도 3A의 예시에서 나타난 프록시 서버(125 또는 325))로 전송하고, 프록시 서버에 의해, 예를 들어, 변경된 콘텐츠나 새로운 콘텐츠(요청 또는 애플리케이션과 연계된 캐싱된 응답과 상이한 업데이트된 응답)를 찾기 위해 콘텐츠 소스를 모니터링하는 데 사용될 수 있다. 프록시로 전송된 폴링 스케줄은 복수의 타이밍 파라미터, 가령, 간격(요청 1에서 요청 2까지의 시간) 또는 타임 아웃 간격(예를 들어 롱 폴에서 사용되는, 응답을 대기하는 시간)(그러나 이에 국한되지 않음)를 포함할 수 있다. 도 17A-B의 예시에서 도시된 요청/응답 타이밍 시퀀스의 타이밍도를 참조하면, 타이밍 간격('R1', 'D', 'RT' 및/또는 'IT') 또는 상기 값들의 임의의 통계적 조작(가령, 평균, 표준 편차 등)이 프록시 서버로 전체적으로 또는 부분적으로 전송될 수 있다.

예를 들어, 로컬 프록시(275)가 롱 폴을 검출하는 경우, 요청/응답 타이밍 시퀀스의 다양한 타이밍 간격(가령, 'D', 'RT' 및/또는 'IT')이 프록시 서버(325)로 전송되어, 콘텐츠 소스(가령, 애플리케이션 서버/콘텐츠 호스트(110))로 폴링할 때 사용될 수 있다. 또한 로컬 프록시(275)는 프록시 서버(325)에게, 모니터링될 특정 애플리케이션 또는 요청 롱 폴 요청이라고 알려줄 수 있다(가령, 프록시 서버에게 "롱 폴 플래그(long poll flag)"를 설정하도록 명령함). 덧붙이자면, 프록시 서버가 다양한 타이밍 간격을 사용하여, 모바일 장치를 대리하여 킵-얼라이브 지시자(keep-alive indication)를 전송할 때를 결정할 수 있다.

특정 요청에 대해 애플리케이션 서버/콘텐츠 소스로부터 새롭거나 변경된 데이터(가령, 업데이트된 응답)가 검출될 때 캐싱 정책 관리기(245)의 로컬 캐시 무효화기(244)가 로컬 캐시(가령, 캐시(185 또는 285)) 내 캐시 요소를 무효화할 수 있다. 프록시 서버(가령, 프록시(325) 또는 호스트 서버(300))로부터 수신된 통지를 기초로 하여, 캐싱된 응답이 아웃고잉 요청에 대해 무효인 것으로 결정될 수 있다. 모바일 클라이언트의 요청에 대해 응답을 제공하는 소스가 모니터링되어, 요청에 대한, 모바일 장치(250)의 캐시에 저장된 캐싱된 응답의 관련성(relevancy)을 결정할 수 있다. 예를 들어, 특정 요청 또는 특정 애플리케이션에 대해 캐싱된 응답이 더 이상 유효하지 않을 때, 캐싱된 무효화기(244)가 모바일 장치의 캐시에서 캐싱된 응답을 더 제거/삭제할 수 있다.

하나의 실시예에서, 캐싱된 응답은 아웃고잉 요청을 발생시킨 애플리케이션으로 다시 한 번 제공된 후, 캐싱된 응답이 더 이상 유효하지 않다고 판단되면 캐시로부터 제거된다. 캐싱된 응답은 시간 간격 동안 기다리지 않고 제공될 수 있거나, 시간 간격(가령, 롱 폴 내 응답 지연을 에뮬레이트하기 위해 특정된 것으로 판단된 시간 간격) 동안 기다린 후 다시 제공될 수 있다. 하나의 실시예에서, 시간 간격이 응답 지연 'D', 또는 둘 이상의 응답 지연 'D'의 값의 평균 값이다.

예를 들어, 새로운 데이터 또는 변경된 데이터가 프록시 서버(가령, 도 1B 및 도 3A의 예시에서 나타난 프록시 서버(125 또는 325))에 의해 검출될 수 있다. 특정 요청/폴에 대한 캐시 엔트리가 무효화된 때, 모바일 장치(250)상의 라디오의 사용이 (가령, 로컬 프록시(275) 또는 캐시 정책 관리기(245)에 의해) 활성화되어, 후속하는 폴링 요청을 만족시킬 수 있고, 이는 도 4B의 상호대화도를 참조하여 더 설명될 것이다.

캐시 정책 관리기(245)의 한 가지 실시예는, 애플리케이션 또는 위젯에 의해 모바일 장치(250)에서 생성되는 폴/콘텐츠 요청을 만족시키기 위해 로컬하게 캐싱된 엔트리를 사용할지 여부를 결정할 수 있는 캐시 또는 연결 선택 엔진(249)을 포함한다. 예를 들어, 로컬 프록시(275) 또는 캐시 정책 관리기(245)는, 애플리케이션 서버/콘텐츠 제공자를 접촉하기 위해 모바일 장치상의 애플리케이션(가령, 모바일 애플리케이션)에 의해 만들어지는 폴링 요청을 인터셉트할 수 있다. 선택 엔진(249)은 인터셉트된 요청에 대해 수신된 콘텐츠가 캐시 요소로서 로컬하게 저장됐는지 여부를 결정할 수 있음으로써, 애플리케이션(가령, 모바일 애플리케이션)에 의해 만들어진 요청을 만족시키기 위해 모바일 장치의 라디오가 활성화될 필요가 있는지 여부를 결정할 수 있고, 또한 캐싱된 응답을 이용해 아웃고잉 요청에 대해 응답하기 전에, 상기 캐싱된 응답이 상기 아웃고잉 요청에 대해 여전히 유효한지 여부를 판단할 수 있다.

하나의 실시예에서, 로컬 프록시(275)는, 관련 캐싱된 콘텐츠가 존재하며 여전히 유효하다고 판단한 것에 응답하여, 로컬 캐시로부터 캐싱된 요소를 불러와 응답을 폴링 요청을 한 애플리케이션(가령 모바일 애플리케이션)에 제공할 수 있음으로써, 모바일 장치의 라디오가 애플리케이션(가령, 모바일 애플리케이션)에 응답을 제공하기 위해 활성화되지 않게 된다. 일반적으로 로컬 프록시(275)는, 캐싱된 응답과 상이한 업데이트된 응답이 검출될 때까지 아웃고잉 요청이 수신될 때마다 캐싱된 응답을 계속 제공할 수 있다.

캐싱된 응답이 더 이상 유효하지 않다고 판단될 때, 특정 요청에 대한 새로운 요청이 업데이트된 응답을 위해 무선 네트워크를 통해 전송된다. 새로운 그리고 업데이트된 응답에 대한 요청이, 애플리케이션 서버/콘텐츠 제공자(가령, 서버/호스트(110)) 또는 호스트 서버상의 프록시 서버(가령, 호스트(300)상의 프록시(325))로 전송될 수 있다. 하나의 실시예에서, 시간 간격 내에 새로운 응답이 수신되지 않을 경우, 캐싱된 응답은, 모바일 장치 상의 캐시에서 제거되기 전에, 아웃고잉 요청에 대한 응답으로서 제공될 수 있다.

도 2C는 도 2A의 예에서 도시된 분산 프록시 시스템의 클라이언트 측 상에서의 애플리케이션 거동 검출기(236) 및 로컬 프록시(275) 내 캐싱 정책 관리기(245)의 구성요소의 또 하나의 예를 도시하는 블록도를 도시한다. 도시된 애플리케이션 거동 검출기(236) 및 캐싱 정책 관리기(245)는, 예를 들어, 로컬 프록시(275)가 캐시 디피트(cache defeat)를 검출하고, 캐시를 디피트하도록 의도된 식별자에 의해 주소지정된 콘텐츠의 캐싱을 수행하도록 할 수 있다.

하나의 실시예에서, 캐싱 정책 관리기(245)는 캐시 디피트 해결 엔진(221), 식별자 포멀라이저(identifier formalizer)(211), 캐시 적절성 판단 엔진(246), 폴 스케줄 생성기(247), 애플리케이션 프로토콜 모듈(248), 캐시 질의 모듈(229)을 갖는 캐시 또는 연결 선택 엔진(249), 및/또는 로컬 캐시 무효화기(244)를 포함한다. 캐시 디피트 해결 엔진(221)은 패턴 추출 모듈(222) 및/또는 캐시 디피트 파라미터 검출기(223)를 더 포함할 수 있다. 캐시 디피트 파라미터 검출기(223)는 랜덤 파라미터 검출기 및/또는 시간/날짜 파라미터 검출기(226)를 더 포함할 수 있다. 하나의 실시예는 판단 엔진(246)으로 연결된 애플리케이션 캐시 정책 레포지토리(243)를 더 포함한다.

하나의 실시예에서, 애플리케이션 거동 검출기(236)는 패턴 검출기(237), 폴 간격 검출기(238), 애플리케이션 프로파일 생성기(239), 및/또는 우선순위 엔진(241)을 포함한다. 패턴 검출기(237)는, 예를 들어, 랜덤 파라미터 검출기(233) 및/또는 시간/날짜 파라미터 검출기(234)를 갖는 캐시 디피트 파라미터 검출기(223)를 더 포함할 수 있다. 한 가지 실시예는, 애플리케이션 프로파일 생성기(239)로 연결되어 있는 애플리케이션 프로파일 레포지토리(242)를 더 포함한다. 애플리케이션 프로파일 생성기(239) 및 우선순위 엔진(241)은 도 2A의 예시의 애플리케이션 거동 검출기(236)의 설명과 관련하여 기재되었다.

캐시 디피트 해결 엔진(221)은 콘텐츠 또는 콘텐츠 소스(가령, 서버 또는 호스트)를 검출, 식별, 추적, 관리, 및/또는 모니터링하며, 상기 콘텐츠 또는 콘텐츠 소스는, 캐시를 디피트하거나 캐시를 디피트하도록 의도된 하나 이상의 메커니즘을 갖는 식별자를 이용하거나, 및/또는 식별자(가령, URL 및/또는 URI 등의 자원 식별자)에 의해 주소지정된다. 캐시 디피트 해결 엔진(221)은, 예를 들어, 식별자가 캐시를 디피트하거나 디피트할 가능성이 있는 애플리케이션 또는 클라이언트에 의해 발생되는 특정 데이터 요청으로부터, 다른 경우라면, 데이터 요청이 캐싱 가능한 호스트 또는 서버(가령, 애플리케이션 서버/콘텐츠 호스트(110 또는 310))로부터 콘텐츠 또는 응답을 주소지정할 곳을 검출할 수 있다.

하나의 실시예에서, 캐시 디피트 해결 엔진(221)은 모바일 장치(250)에서 검출되는 데이터 요청의 식별자를 이용해 콘텐츠 소스(가령, 애플리케이션 서버/콘텐츠 호스트(110 또는 310))에 의해 사용되는 캐시 디피트 메커니즘을 검출하거나 식별한다. 캐시 디피트 해결 엔진(221)은 캐시 디피트 메커니즘이 사용됨을 가리킬 수 있는 식별자에서 파라미터를 검출하거나 식별할 수 있다. 예를 들어, 포맷, 구문(syntax), 또는 파라미터의 패턴이 사용되어, 캐시 디피트(가령, 패턴 추출 모듈(222)에 의해 결정되거나 추출되는 상태의 패턴, 포맷, 또는 구문)를 식별할 수 있다.

패턴 추출 모듈(222)은 식별자를 복수의 파라미터 또는 성분으로 파스(parse)하고, 각각의 파라미터에 대해 매칭 알고리즘(matching algorithm)을 수행하여, 그 중 어느 것이 하나 이상의 지정된 포맷(가령, 도 7의 파라미터(702)에서 나타나는 것처럼, 날짜 및/또는 시간 포맷)과 매칭하는지를 식별할 수 있다. 예를 들어, (캐시 디피트 파라미터 검출기(223)에 의해) 매칭의 결과, 또는 식별자로부터 파스된 파라미터들이 사용되어, 하나 이상의 변하는 파라미터를 포함할 수 있는 캐시 디피트 파라미터를 식별할 수 있다.

하나의 실시예에서, 캐시 디피트 파라미터 검출기(223)는 (가령, 랜덤 파라미터 검출기(224)에 의해) 랜덤 파라미터를 검출하거나 및/또는 일반적으로 캐시 디피트를 위해 사용되는 날짜 및/또는 시간 파라미터를 검출할 수 있다. 캐시 디피트 파라미터 검출기(223)는 랜덤 파라미터(가령, 도 7에 도시된 파라미터(752)로 나타난 것)를 검출하거나, 및/또는 이들 파라미터에 대해 일반적으로 사용되는 포맷을 이용하고 패턴 매칭 알고리즘 및 테스트를 이용해, 시간/날짜를 검출할 수 있다.

패턴, 포맷, 및/또는 구문을 검출하는 것에 추가로, 캐시 디피트 파라미터 검출기(223)는 특정 파라미터가 캐시를 디피트하는 중인지 여부와 분산 캐싱 시스템에 의해 주소지정된 콘텐츠가 캐싱될 수 있는지 여부를 더 결정하거나 확인한다. 캐시 디피트 파라미터 검출기(223)는, 특정 데이터 요청에 의해 사용되는 식별자에 대해 수신된 응답을 분석함으로써, 이를 검출할 수 있다. 일반적으로, 복수의 데이터 요청이 복수의 데이터 요청 각각에 대해 상이하게 변하는 파라미터를 갖는 식별자를 사용할 때조차, 복수의 데이터 요청에 대응하는 응답들이 동일할 때 식별자 내 변하는 파라미터가 캐시 디피트를 가리키도록 식별될 수 있다. 예를 들어, 도 7의 예시에서 나타난 요청/응답 쌍은, 자원 식별자가 각각의 요청에 따라 변하는 파라미터(도 7의 702 및 752)를 포함할지라도, 수신된 응답(도 7의 704 및 754)이 동일함을 나타낸다.

예를 들어, 변하는 파라미터가 캐시 디피트를 나타낸다고 식별하기 위해, 적어도 2개의 동일한 응답이 요구될 수 있다. 일부 경우, 적어도 3개의 동일한 응답이 필요할 수 있다. 요청들 간에 변하는 값을 갖는 특정 파라미터가 캐시 디피트임을 결정하기 위해 필요한 동일한 응답의 개수에 대한 요건이 애플리케이션 특정적, 상황 종속적, 및/또는 사용자 종속적/사용자 특정적, 또는 이들의 조합일 수 있다. 또한 이러한 요건은 정적이거나, 특정 성능 임계치 및/또는 사용자 경험에 대한 명시적/묵시적 피드백(가령, 사용자 또는 애플리케이션이 요청에 응답하여 관련/프레시 콘텐츠를 수신하는 중인지 여부)을 충족하기 위해, 분산 캐시 시스템에 의해, 동적으로 조절될 수 있다. 애플리케이션이 응답 캐싱 때문에 오작동하기 시작하는 경우, 및/또는 사용자가 불만족을 표시하거나(명시적 사용자 피드백) 시스템이 사용자 불만족을 검출하는 경우, 캐시 디피트를 확정하기 위해, 또는 시스템이 특정 파라미터를 캐시 디피트에 대해 의도된 것으로 취급하기 위해, 더 많은 동일한 응답이 필요할 수 있다.

캐시 적절성 판단 엔진(246)은, 모바일 장치(250)가 상호대화하는 콘텐츠 소스(가령, 도 1B의 예시에서 애플리케이션 서버/콘텐츠 제공자(110))로부터의 콘텐츠가 캐싱에 적합할 수 있는 콘텐츠를 가지는지 여부를 검출, 판정, 또는 결정할 수 있다. 일부 경우, 특정 애플리케이션 서버/콘텐츠 제공자(가령, 도 1B의 서버/제공자(110))가 기준들의 세트(예를 들어, 콘텐츠 소스로부터 요청되는 콘텐츠의 시간 중요도를 특정하는 기준)를 기초로 캐싱에 적합한 것으로 결정된다. 하나의 실시예에서, 로컬 프록시(가령, 도 1B 및 도 2A의 로컬 프록시(175 또는 275))가, 애플리케이션에 의해 이뤄지는 후속하는 요청들을 만족하기 위해, 애플리케이션에 의해 요청받은 호스트 서버로부터의 콘텐츠를, 모바일 장치 상의 로컬 캐시 내 캐싱된 요소로서 저장하기 위한 선택 기준을 적용한다.

또한, 선택 기준은, 예를 들어, 모바일 장치가 활성인지 비활성인지 여부를 가리키는 모바일 장치의 상태, 네트워크 조건, 및/또는 라디오 커버리지 통계치(radio coverage statistics)를 포함할 수 있다. 캐시 적절성 판단 엔진(246)은 캐싱이 적합할 수 있는 소스를 식별할 때, 기준들 중 임의의 하나 또는 기준들의 임의의 조합을, 임의의 순서로 이용할 수 있다.

애플리케이션 서버/콘텐츠 제공자가 모바일 장치(250) 상의 로컬 캐싱에 적합할 가능성이 있는 식별되거나 검출된 콘텐츠를 가지면, 캐시 정책 관리기(245)는, 콘텐츠 소스로부터 수신된 콘텐츠를 모바일 장치(250) 상의 로컬 캐시(가령, 도 1B와 도 2A의 예시의 경우, 로컬 캐시(185 또는 285)) 내 캐시 요소로서 저장함으로써, 식별된 소스로부터 수신된 관련 콘텐츠의 캐싱을 진행할 수 있다. 또한 콘텐츠 소스는, 모바일 장치(250)에 원격으로 위치하며 상기 모바일 장치(250)와 무선 통신하는 프록시 서버(가령, 도 1B 및 도 3A의 프록시 서버(125 또는 325))에게 알려질 수 있어서, 상기 프록시 서버가 새로운 데이터 또는 변경된 데이터를 찾기 위해 콘텐츠 소스(가령, 애플리케이션 서버/콘텐츠 제공자(110))를 모니터할 수 있다. 이와 유사하게, 로컬 프록시(가령, 도 1B 및 도 2A의 로컬 프록시(175 또는 275)가 프록시 서버에게, 특정 애플리케이션 서버/콘텐츠 제공자로부터 수신된 콘텐츠가 로컬 캐시 내 캐싱된 요소로서 저장되어 있다고 알려줄 수 있다.

하나의 실시예에서, 캐시 요소가 로컬 캐시(285)에, 캐시를 디피트하는 것으로 의도된 하나 이상의 파라미터를 이용하는 식별자의 정규화된 버전(normalized version)과 연계되어, 저장된다. 식별자 정규화기 모듈(211)에 의해 식별자가 정규화될 수 있고, 예를 들어, 정규화 프로세스는, URI 스킴 및 호스트를 소문자로 변환하는 것, 퍼센트-인코딩식 이스케이프 시퀀스의 문자들을 대문자화하는 것, 디폴트 포트를 제거하는 것, 및 중복 슬래시(duplicate slash)를 제거하는 것 중 하나 이상을 포함할 수 있다.

또 하나의 실시예에서, 정규화기(211) 또는 캐시 디피트 파라미터 핸들러(212)에 의해, 캐시 디피트에 대한 파라미터를 제거함으로써, 및/또는 상기 파라미터를, 식별자를 이용하는 요청에 응답하여 수신된 캐싱된 응답을 주소지정하기 위해 사용될 수 있거나, 상기 캐싱된 응답과 연계될 수 있는 정적 값(static value)으로 대체함으로써, 식별자가 정규화된다. 예를 들어, 식별자의 정규화된 버전 또는 상기 정규화된 식별자의 해시 값(hash value)을 이용하여 (도 2A에 도시된) 로컬 캐시(285)에 저장된 캐싱된 요소가 식별될 수 있다. 식별자의 해시 값 또는 정규화된 식별자의 해시 값은 해시 엔진(213)에 의해 생성될 수 있다.

콘텐츠가 로컬하게 캐싱된 경우, 캐시 정책 관리기(245)는, 콘텐츠 서버로 접촉하기 위한 추후 폴링 요청을 수신할 때, 모바일 장치의 라디오가 폴링 요청을 서비스하기 위해 활성화되지 않도록, 로컬 캐시에서 캐싱된 요소를 불러와서, 모바일 장치(250)에서 이뤄진 폴링 요청에 응답할 수 있다. 로컬 캐시 엔트리를 통해 애플리케이션(가령, 모바일 애플리케이션)의 요청을 이렇게 서비스하고 이행함으로써, 모바일 장치(250)에 이미 수신된 응답에서 변경되지 않을 수 있는 폴 응답을 요청/수신하기 위해 네트워크 대역폭 및 그 밖의 다른 자원이 사용될 필요가 없기 때문에, 더 효율적인 자원 및 모바일 네트워크 트래픽 활용과 관리가 가능해진다.

캐시 정책 관리기(245)의 한 가지 실시예는, 모바일 장치(250) 상의 하나 이상의 애플리케이션에 대해 폴링 스케줄을 생성할 수 있는 폴 스케줄 생성기(247)를 포함한다. 폴링 스케줄은, 하나 이상의 애플리케이션을 위해 콘텐츠 소스를 모니터링할 때 프록시 서버(가령, 도 1B 및 도 3A의 예시에서 도시된 프록시 서버(125 또는 325))에 의해 사용될 수 있는 폴링 간격을 특정할 수 있다. 폴링 스케줄은, 예를 들어, 모바일 장치로부터 콘텐츠 소스로의 폴링 요청들 사이의 간격을 기초로 결정될 수 있다. 하나의 실시예에서, 애플리케이션 거동 검출기의 폴 간격 검출기(238)는 모바일 장치(250)로부터 콘텐츠 소스로의 폴링 요청들을 모니터할 수 있어서, 임의의 또는 모든 애플리케이션(가령, 모바일 애플리케이션)에서 이뤄진 폴링 요청들 사이의 간격을 결정할 수 있다.

하나의 실시예에서, 캐시 정책 관리기(245)는 폴링 스케줄을 프록시 서버(가령, 도 1B 및 도 3A의 예시에서 나타난 프록시 서버(125 또는 325))로 전송하며, 상기 폴링 스케줄은, 프록시 서버에 의해, 가령, 변경되거나 새로운 콘텐츠를 찾기 위해 콘텐츠 소스를 모니터링할 때 사용될 수 있다. 특정 요청에 대해, 새로운 데이터 또는 변경된 데이터가 애플리케이션 서버/콘텐츠 소스로부터 검출될 때, 캐싱 정책 관리기(245)의 로컬 캐시 무효화기(244)는 로컬 캐시(가령, 캐시(185 또는 285)) 내 캐시 요소를 무효화할 수 있다. 예를 들어, 새로운 데이터 또는 변경된 데이터는, 프록시 서버에 의해 검출될 수 있다. 특정 요청/폴에 대한 캐시 엔트리가 무효화 및/또는 무효화 후 제거(가령, 캐시에서 삭제)됐을 때, 뒤이은 폴링 요청을 만족시키기 위해, 모바일 장치(250) 상의 라디오의 사용이 (가령, 로컬 프록시 또는 캐시 정책 관리기(245)에 의해) 활성화될 수 있으며, 이는, 도 4B의 상호대화도를 참조하여 추가로 기재된다.

또 하나의 실시예에서, 프록시 서버(가령, 도 1B 및 도 3A의 예시의 경우, 프록시 서버(125 또는 325))가, 데이터 요청에서 사용되는 수정된 버전의 자원 식별자를 이용하여, 새로운 데이터 또는 변경된 데이터를 찾기 위해 특정 콘텐츠 소스(도 1A 및 도 1B의 애플리케이션 서버/콘텐츠 호스트(110))를 모니터할 수 있다. 예를 들어, 캐시 디피트 메커니즘을 이용하기 위한 콘텐츠 소스 또는 식별자가 검출되는 경우, 수정된(가령, 정규화된) 식별자가 콘텐츠 소스를 폴링하도록 사용될 수 있다. 캐싱 정책 관리기(245)에 의해, 또는 더 구체적으로, 식별자 정규화기(211)의 캐시 디피트 파라미터 핸들러(212)에 의해, 수정 또는 정규화된 버전의 식별자가 프록시 서버로 전달될 수 있다.

모바일 장치/애플리케이션(가령, 모바일 애플리케이션)을 대리하여 콘텐츠 소스로 폴링하기 위해 프록시 서버에 의해 사용된 수정된 식별자는 정규화된 식별자와 동일한 것이거나, 동일한 것이 아닐 수 있다. 예를 들어, 정규화된 식별자는 제거된 변경 캐시 디피트 파라미터를 갖는 원본 식별자일 수 있으며, 반면에 수정된 식별자는 캐시를 디피트하기 위해 사용되는 파라미터를 대신하여 대체 파라미터를 이용한다(가령, 변하는 파라미터가 로컬 프록시 및/또는 프록시 서버에게 알려진 정적인 값 또는 그 밖의 다른 지정 값으로 대체됨). 수정된 파라미터는 로컬 프록시(275)에 의해 결정되고, 프록시 서버로 전달될 수 있다. 또한, 프로시 서버에 의해(가령, 도 3C의 예시에 나타난 식별자 수정기 모듈(353)에 의해) 수정된 파라미터가 생성될 수 있다.

캐시 정책 관리기(245)의 하나의 실시예는, 애플리케이션 또는 위젯에 의해 모바일 장치(250)에서 생성되는 폴/콘텐츠 요청을 만족시키기 위해, 로컬 캐싱된 엔트리를 사용할지 여부를 결정할 수 있는 캐시 또는 연결 선택 엔진(249)을 포함한다. 예를 들어, 로컬 프록시(275) 또는 캐시 정책 관리기(245)가, 애플리케이션 서버/콘텐츠 제공자와 접속하기 위해, 모바일 장치 상의 애플리케이션(가령, 모바일 애플리케이션)에 의해 이뤄진 폴링 요청을 인터셉트할 수 있다. 애플리케이션(가령, 모바일 애플리케이션)에 의해 이뤄진 요청을 만족시키도록 모바일 장치의 라디오가 활성화될 필요가 있는지 여부를 결정하기 위해, 선택 엔진(249)이 인터셉트된 요청에 대해 수신된 콘텐츠가 캐시 요소로서 로컬하게 저장됐는지 여부를 결정할 수 있다. 하나의 실시예에서, 로컬 프록시(275)는, 관련 캐싱된 콘텐츠가 존재하고 여전히 유효하다는 결정에 응답하여, 로컬 캐시로부터 캐싱된 요소를 불러와, 폴링 요청을 만든 애플리케이션(가령 모바일 애플리케이션)에 응답을 제공하여, 애플리케이션(가령, 모바일 애플리케이션)에 응답을 제공하기 위해 모바일 장치의 라디오가 활성화되지 않도록 할 수 있다.

하나의 실시예에서, 예를 들어, 캐시 질의 모듈(229)을 이용하여, 식별자의 정규화된 버전, 또는 식별자의 정규화된 버전의 해시 값을 이용해 (도 2A에 도시된) 로컬 캐시(285)에 저장된 캐싱된 요소가 식별될 수 있다. 동일한 유형의 캐시 디피트를 이용하는 그 밖의 다른 요청을 만족시키기 위해 장래에 관련 캐싱된 요소가 식별되고 불러와 질 수 있도록, 캐시 디피트 파라미터가 제거, 또는 그 밖의 다른 방식으로 대체된 정규화된 식별자와 함께, 캐싱된 요소가 저장될 수 있다. 예를 들어, 추후 요청에서 사용되는 식별자가 동일한 캐시 디피트 파라미터를 이용하는 중이라고 판단될 때, 데이터 요청을 만족시키기 위해, 식별자의 정규화된 버전이 생성되고, 모바일 장치 캐시에 저장된 캐싱된 응답을 식별하기 위해 사용될 수 있다. 식별자 정규화기(211)의 해시 엔진(213)에 의해, 식별자의 해시 값, 또는 정규화된 식별자의 해시 값이 생성될 수 있다.

도 2D는 애플리케이션 거동 및/또는 사용자 활동을 기초로 하여, 모바일 트래픽 카테고리화 및 정책 구현을 더 수행할 수 있는, 도 2A의 예에서 나타난 로컬 프록시(275)의 추가 구성요소의 예를 도시하는 블록도를 도시한다.

로컬 프록시(275)의 이 실시예에서, 사용자 활동 모듈(215)은, 사용자 활동 추적기(215a), 사용자 활동 예측 엔진(215b), 및/또는 사용자 기대 관리기(user expectation manager)(215c)를 더 포함한다. 애플리케이션 거동 검출기(236)는 우선순위화 엔진(241a), 시간 중요도 검출 엔진(241b), 애플리케이션 상태 카테고리화기(application state categorizer)(241c), 및/또는 애플리케이션 트래픽 카테고리화기(241d)를 더 포함할 수 있다. 로컬 프록시(275)는 백라이트 검출기(219) 및/또는 네트워크 설정 선택 엔진(251)을 더 포함할 수 있다. 네트워크 설정 선택 엔진(251)은, 무선 세대 표준 선택기(wireless generation standard selector)(251a), 데이터 전송 속도 특정기(data rate specifier)(251b), 액세스 채널 선택 엔진(251c), 및/또는 액세스 포인트 선택기를 더 포함할 수 있다.

하나의 실시예에서, 애플리케이션 거동 검출기(236)는, 예를 들어, 애플리케이션 상태 카테고리화기(241c) 및/또는 트래픽 카테고리화기(241d)를 통해, 트래픽이 발원된, 또는 상기 트래픽이 전달되는 모바일 장치(250) 상의 애플리케이션의 활동 상태(activity state)를 검출, 결정, 식별, 또는 추론할 수 있다. 전경 애플리케이션 vs. 배경 애플리케이션의 트래픽이 서로 다르게 핸들링될 수 있기 때문에, (애플리케이션 상태 카테고리화기(241c)를 통해) 애플리케이션이 모바일 장치 상에서 전경(foreground) 상태에 있는지 배경(background) 상태에 있는지에 따라, 활동 상태가 결정될 수 있다.

하나의 실시예에서, 휴리스틱(heuristic)의 확신도(certainty)의 레벨을 이용해, 또는 모바일 장치(250)의 백라이트 상태를 기초로 하여, 또는 모바일 장치 상의 그 밖의 다른 소프트웨어 에이전트 또는 하드웨어 센서(제한되지 않는 예를 들면, 저항성 센서, 용량성 센서, 주변광 센서, 모션 센서, 터치 센서 등)에 의해, 활동 상태가 판단, 검출, 식별, 또는 추론될 수 있다. 일반적으로, 백라이트가 켜져 있는 경우, 트래픽은 액티브 상태이거나 전경 상태인 애플리케이션으로부터 생성되는 것이라고 취급되거나 판단될 수 있거나, 트래픽은 상호대화형이다. 덧붙이자면, 백라이트가 켜져 있는 경우, 트래픽은 사용자 상호대화 또는 사용자 활동으로부터의 트래픽, 또는 일정 시간 프레임 내에서 사용자가 기대 중인 데이터를 포함하는 트래픽인 것으로 취급되거나, 판단될 수 있다.

하나의 실시예에서, 트래픽이 상호대화형 트래픽(interactive traffic)인지 유지관리형 트래픽(maintenance traffic)인지를 기초로 하여, 활동 상태가 결정된다. 상호대화 트래픽은 사용자 활동/애플리케이션과의 상호대화로부터 직접 생성된 응답 및 요청으로부터의 트랜잭션을 포함할 수 있으며, 사용자가 수신하기 위해 대기 중이거나 기대 중인 콘텐츠 또는 데이터를 포함할 수 있다. 유지관리형 트래픽은 사용자에 의해 직접 검출되지 않는 애플리케이션의 기능을 지지하기 위해 사용될 수 있다. 또한 유지관리형 트래픽은, 사용자 동작(action)에 응답하여 이뤄질 수 있지만 사용자가 적극적으로 응답을 기다리거나 기대하지 않는 액션 또는 트랜잭션을 포함할 수 있다.

예를 들어, 모바일 장치(250)에서의 메일 또는 메시지 삭제 동작이, 이에 대응하는 메일 또는 메시지를 서버에서 삭제하라는 요청을 생성하지만, 일반적으로 사용자는 응답을 기다리지 않는다. 따라서 요청이 유지관리형 트래픽, 또는 (가령, 우선순위화 엔진(241a)에 의해) 더 낮은 우선순위를 갖는 트래픽으로 카테고리화될 수 있거나, 및/또는 (시간 중요도 검출 엔진(214b)에 의해) 시간-중요성(time-critical)이 아니라고 카테고리화될 수 있다.

이와 대조적으로, 모바일 장치(250)에서 사용자에 의해 개시되는 메일 '읽기' 또는 메시지 '읽기' 요청은 '상호대화형 트래픽'이라고 카테고리화될 수 있는데, 왜냐하면, 일반적으로 사용자가 메시지나 메일을 읽기를 요청할 때 콘텐츠 또는 데이터를 액세스하기를 기다리기 때문이다. 마찬가지로, 이러한 요청은 (가령, 우선순위화 엔진(241a)에 의해) 더 높은 우선순위를 갖는 것 및/또는 (가령, 시간 중요도 검출 엔진(241b)에 의해) 시간 중요성/시간 민감성을 갖는 것으로 카테고리화될 수 있다.

시간 중요도 검출 엔진(241b)은 모바일 장치(250)로부터 전송된, 또는 호스트 서버(가령, 호스트(300)) 또는 애플리케이션 서버(가령, 앱 서버(app server)/콘텐츠 소스(110))로부터 모바일 장치로 전송된 트래픽에 포함된 데이터의 시간 민감도를 판단, 식별, 추론할 수 있다. 예를 들어, 시간 민감형 데이터는, 상태 업데이트, 주식 정보 업데이트, IM 프레슨스 정보(IM presence information), 전자메일 메시지 또는 그 밖의 다른 메시지, 모바일 게임 애플리케이션으로부터 발생된 동작, 웹페이지 요청, 위치 업데이트 등을 포함할 수 있다. 콘텐츠 또는 요청의 속성에 따라, 시간 민감형 또는 시간 중요형이 아닌 데이터는, 메시지 삭제 요청, 읽음 표시, 또는 편집된 동작, 애플리케이션-특정 동작(가령, 친구 추가, 친구 삭제 요청), 특정 유형의 메시지 또는 속성을 빈번하게 변경하지 않는 그 밖의 다른 정보 등을 포함할 수 있다. 일부 경우, 데이터가 시간 중요형이 아닐 때, 트래픽이 통과하도록 하는 타이밍이, 추가 데이터가 모바일 장치(250)로부터 전송될 필요가 있을 때를 기초로 설정된다. 예를 들어, 트래픽 성형 엔진(255)은, (가령, 정렬 모듈(256) 및/또는 일괄처리 모듈(257)을 이용해) 모바일 장치 라디오의 한 번의 전원 켜기 이벤트로 다 함께 전송될 하나 이상의 후속하는 트랜잭션과 함께 트래픽을 정렬할 수 있다. 또한 정렬 모듈(256)은 동일한 호스트 서버로 전달되는 폴링 요청 발생을 시간 상 가깝도록 정렬할 수 있는데, 이들 요청이 동일한 데이터로 응답될 가능성이 높기 때문이다.

이를 대체하여, 또는 이와 조합되어, (가령, 사용자 활동 모듈(215)을 통해) 모바일 장치(250)에서의 사용자 활동을 평가, 판단, 산정, 추론, 식별하는 것으로부터 활동 상태가 결정될 수 있다. 예를 들어, 사용자 활동 추적기(215a)를 이용해 사용자 활동이 직접 검출되고 추적될 수 있다. 그 후, 이로부터 야기된 트래픽이, 추후 프로세싱을 위해 적절하게 카테고리화되어, 핸들링 정책을 결정할 수 있다. 덧붙이자면, 사용자 활동 예측 엔진(215b)에 의해, 사용자 활동이 예측 또는 예상될 수 있다. 사용자 활동을 예측하거나 사용자 활동을 예상함으로써, 예측 후 발생하는 트래픽이 사용자 활동으로부터 야기된 것으로 취급되고, 전송 정책을 결정하기 위해 적절하게 카테고리화될 수 있다.

덧붙이자면, 사용자 활동 모듈(215)은 또한 (가령, 사용자 기대 관리기(215c)를 통해 및/또는 활동 추적기(215) 및/또는 예측 엔진(215b)과 결합하여) 사용자 기대를 관리함으로써, 일반적으로 사용자 기대가 충족되도록 트래픽이 적절하게 카테고리화됨을 보장할 수 있다. 예를 들어, 사용자에 의해 개시되는 동작이 (가령, 기대 관리기(215)에 의해) 분석되어, 사용자가 응답을 기다릴 것인지 여부를 판단 또는 추론할 수 있다. 사용자가 응답을 기다린다고 판단된 경우, 이러한 응답이나 동작을 수신할 때 사용자가 원치 않는 지연을 경험하지 않도록, 이러한 트래픽은 정책에 따라 핸들링되어야 한다.

하나의 실시예에서, 무선 네트워크에서 모바일 장치와 호스트 서버 사이에 트래픽을 전송하는 데 사용되기 위해 진보된 세대 무선 표준 네트워크가, 트래픽이 발원되거나 전달되는 모바일 장치의 애플리케이션의 활동 상태를 기초로 선택된다. 사용자 상호대화, 사용자 활동의 결과로서 발생되는 트래픽, 또는 사용자가 기대하거나 대기 중인 데이터를 포함하는 트래픽을 핸들링하기 위해 진보된 기술 표준, 가령, 3G, 3.5G, 3G+, 4G, 또는 LTE 네트워크가 선택될 수 있다. 또한, 전경 활동에 응답하는 모바일 장치로 전달되는 트래픽에 포함된 데이터를 송신하기 위해, 진보된 세대 무선 표준 네트워크가 선택될 수 있다.

트래픽을 카테고리화하고, 모바일 트래픽에 대한 전송 정책을 정의할 때, 모바일 장치와 프록시 서버(325) 및/또는 애플리케이션 서버(가령, 앱 서버(app server)/호스트(110)) 사이에 트래픽을 전송하는 데 네트워크 설정이 모바일 장치(250) 상에서 (가령, 네트워크 설정 선택 엔진(251)에 의해) 사용되기 위해 선택될 수 있다. 선택된 네트워크 설정은, 애플리케이션 활동 상태(가령, 배경 또는 전경 트래픽), 애플리케이션 트래픽 카테고리(가령, 상호대화형 또는 유지관리형 트래픽), 데이터/콘텐츠의 임의의 우선순위, 시간 민감도/중요도와 관련된 애플리케이션 거동 모듈(236)에 의해 수집된 정보를 기초로 결정될 수 있다.

네트워크 설정 선택 엔진(2510)은 세대 표준(가령, 무선 세대 표준 선택기(251a)를 통해), 데이터 전송 속도(가령, 데이터 전송 속도 특정기(251b)를 통해), 액세스 채널(가령, 액세스 채널 선택 엔진(251c), 및/또는 액세스 포인트(가령, 액세스 포인트 선택기(251d)를 통해) 중 하나 이상을 임의의 조합으로 선택하고 특정할 수 있다.

예를 들어, 활동 상태가 사용자와 상호대화 중이거나, 모바일 장치 상에서 전경 상태일 때, 트래픽에 대해 더 진보된 세대(가령, 3G, LTE, 또는 4G, 또는 그 이상)가 선택되거나 특정될 수 있다. 이와 달리, 다음 중 하나 이상이 검출될 때, 트래픽에 대해 더 낡은 세대 표준(가령, 2G, 2.5G, 또는 3G, 또는 그 이하)이 특정될 수 있다: 애플리케이션이 사용자와 상호대화 중이 아닌 상황, 애플리케이션이 모바일 장치 상에서 배경에서 실행 중인 상황, 또는 트래픽에 포함된 데이터가 시간 중요형이 아니거나, 그 밖의 다른 방식으로 더 낮은 우선순위를 갖는다고 판단된 상황.

마찬가지로, 다음 중 하나 이상이 검출될 때, 트래픽에 대하여 더 느린 데이터 전송 속도를 갖는 네트워크 설정이 특정될 수 있다: 애플리케이션이 사용자와 상호대화하는 중이 아닌 상황, 애플리케이션이 모바일 장치 상의 배경에서 실행 중인 상황, 또는 트래픽에 포함된 데이터가 시간 중요형이 아닌 상황. 액세스 채널(가령, 순방향 액세스 채널 또는 전용 채널)이 특정될 수 있다.

도 2E는, 무선 네트워크 또는 광대역 네트워크를 통해 데이터를 수신하도록 구축될 필요가 있는 연결의 개수를 최적화하기 위해, 모바일 또는 광대역 장치 또는 그 사용자에게로의 인커밍 데이터 전송의 정렬을 촉진시킬 수 있는 도 2A의 예시에서 도시된 트래픽 성형 엔진(traffic shaping engine)(255)과 애플리케이션 거동 검출기(236)의 추가 구성요소의 예를 도시하는 블록도를 도시한다.

로컬 프록시(275)의 하나의 실시예에서, 트래픽 성형 엔진(255)은, 정렬 모듈(256), 일괄처리 모듈(257)에 추가로, 폴 간격 조절기(poll interval adjuster)(258)를 더 포함한다. 폴 간격 조절기(258)는 인수 또는 분모 검출 엔진(258a), 중요 애플리케이션 검출기(critical application detector)(258b), 중요 간격 식별기(critical interval identifier)(258c), 및/또는 폴링 간격 설정 엔진(258d)을 포함할 수 있다. 추가로, 하나의 실시예에서, 로컬 프록시(275)의 애플리케이션 거동 검출기(236)는 폴 간격 검출기(238)를 더 포함한다.

모바일 장치(250)로의 다양한 서비스 또는 호스트들 간에 데이터 버스트(data burst)의 정렬을 촉진할 때, 우선 로컬 프록시(275)는 모바일 장치(250) 상의 애플리케이션 또는 모바일 클라이언트에 대한 본래의, 즉 디폴트인 폴링 간격을 (가령, 폴 간격 검출기(238)에 의해) 판단, 검출, 식별, 계산, 추론, 추출할 수 있다. 본래의 또는 디폴트 폴링 간격은 모바일 애플리케이션 자체, 및/또는 모바일 애플리케이션의 호스트(가령, 도 1A-1B에서 도시된, 대응하는 애플리케이션 서버/콘텐츠 호스트(110))의 특성인 것이 일반적이다. 폴 간격 검출기(238)는, 애플리케이션 서버 또는 호스트로 규칙적으로 폴링하는 모바일 애플리케이션들 중 일부 또는 모두에 대해 본래의 또는 디폴트인 폴 간격을 검출하여, 장치(250)에 설치된 애플리케이션 및 그들 각자의 폴 타이밍 특성을 기초로 하여, 장치(250)용으로 사용되기 적합한 폴링 간격을 생성하거나 조절할 때 프록시(275)에 의해 사용되도록 할 수 있다.

예를 들어, 장치(250) 상의 모바일 클라이언트 또는 애플리케이션의 폴 간격(본래의 또는 디폴트인 폴 간격)은, 폴 간격 조절기(258)에 의해 사용될 수 있다. 일반적으로, 제 1 서비스와 구별되는 호스트에 의해 서비스되는 제 2 서비스의 폴링 간격을 기초로 하여, 제 1 서비스에 대해 조절된 폴링 간격이 생성된다(가령, 트위터(Twitter)=서비스 1, ESPN.com=서비스 2). 제 1 및 제 2 서비스의 모바일 장치 상의 액세스 때문에, 제 1 서비스 및/또는 제 2 서비스에 대해 계산된 조절된 폴링 간격이 구별되는 호스트로부터 수신된 적어도 일부 트래픽을 정렬할 때 사용될 수 있다.

예를 들어, 하나의 실시예에서, 제 1 서비스의 조절된 폴링 간격은, 제 1 서비스의 본래 폴링 간격이 제 2 서비스의 본래 폴링 간격과 공통으로 갖는 인수 또는 분모(가령, 인수 또는 분모 검출 엔진(258a)에 의해 결정됨)일 수 있고, 제 1 서비스의 본래 폴링 간격을 기초로 더 결정될 수 있다. 제 1 서비스의 본래 폴링 간격과 제 2 서비스의 폴링 간격이 서로의 인수 또는 분모일 때, 제 1 서비스의 조절된 폴링 간격은 제 1 서비스의 본래 폴링 간격과 상이할 필요가 없다.

하나의 실시예에서, 검출 엔진(258a)은 제 2 서비스의 폴링 간격의 인수 또는 분모의 배수를 더 결정할 수 있고, 제 1 서비스의 조절된 폴링 간격은 제 2 서비스의 폴링 간격의 인수의 배수 또는 분모의 배수이다. 덧붙여, 엔진(258a)은 장치(250) 상의 복수의 애플리케이션에 대한 대다수의 디폴트 폴링 간격의 공통 인수 또는 공통 분모의 배수를 결정할 수 있다.

덧붙여, 제 2 서비스 또는 모바일 장치(250) 상의 추가 서비스로부터의 트래픽의 시간 중요도에 대한, 제 1 서비스로부터의 트래픽의 시간 중요도를 기초로 하여, 제 1 서비스의 조절된 폴링 간격이 (가령, 폴링 간격 설정 엔진(258d)에 의해) 더 결정, 조절, 또는 재설정될 수 있다. 예를 들어, 중요 애플리케이션 검출기(258b)는 장치(250) 상의 하나 이상의 애플리케이션을, 다른 것보다 더 중요하다고(가령, 더 높은 우선순위, 시간 민감형 콘텐츠/트래픽, 사용자 선호형 애플리케이션, OS 후원형 애플리케이션, 운영자-후원형 콘텐츠 등이라고), 식별하거나 검출, 또는 식별하거나 특정하는 입력을 수신할 수 있으며, 필요에 따라 제 1 및/또는 제 2 서비스의 폴링 간격을 추가로 조절할 수 있다.

예를 들어, 중요 애플리케이션 검출기(258b)는 중요 애플리케이션을, 모바일 장치상의 모든 애플리케이션 또는 데이터 버스트 정렬이 적용되거나 시도되는 애플리케이션의 세트 중에서 가장 시간 중요형이라고 식별할 수 있다. 중요 애플리케이션의 경우, 중요 애플리케이션의 폴링 간격이 (가령, 중요 간격 식별기(258c)에 의해) 중요 애플리케이션에 대해 업데이트된 폴링 간격을 할당할 때 초과되지 않는 최소 중요 간격(minimun critical interval)이라고 식별되어, 데이터가 애플리케이션 서버 또는 콘텐츠 호스트로부터 신속하고 적시에 전달되도록 데이터 수요의 우선순위(가령, 사용자-수요인지 장치-수요인지 애플리케이션-수요인지)가 정해질 수 있다.

높은 우선순위 정보/데이터 또는 애플리케이션은, 예를 들어, 금융 데이터, 스포츠 데이터 또는 속성이 끊임없이 변하는 그 밖의 다른 데이터, 이전 값과 거의 관련성을 갖지 않는 임의의 데이터, 사용자가 애플리케이션 서버/콘텐츠 호스트에 의해 실시간(real time) 또는 준실시간(near real time) 형태(가령, 실시간 상태 업데이트, 또는 실시간 통지, 높은 우선순위 전자메일 또는 그 밖의 다른 메시지, IM 메시지 등)로서 즉시 통지받기를 원하는 임의의 데이터(가령, 구독물(subscription) 또는 피드(feed)), 또는 임의의 유형의 높은 우선순위/시간 민감성 콘텐츠를 서비스하는 애플리케이션을 포함할 수 있다.

모바일 장치(250) 상의 하나 이상의 애플리케이션의 폴링 간격이 설정되면, 로컬 프록시(275)는, 조절된 폴링 간격을 포함하는 폴링 스케줄을 프록시 서버(가령, 도 3A-3E의 원격 프록시(325))로 전달하여, 제 1 및 제 2 서비스, 및 임의의 추가 서비스의 모바일 장치의 액세스로 인한 구별되는 호스트들로부터 수신된 적어도 일부 트래픽을 적시에 정렬하는 데 사용되도록 할 수 있다.

하나의 실시예에서, 폴 간격 설정 엔진(258d)은 복수의 애플리케이션을 서비스하는 콘텐츠 호스트들의 초기 폴에 대해 시간상 공통 시작점을 선택한다. 폴 간격 설정 엔진(258d)은 장치(250) 상의 복수의 애플리케이션의 시작 시점을 하나의 동일한 절대 시점으로 고정되도록 설정할 수 있다. 일반적으로, 애플리케이션 서버/콘텐츠 호스트는 UTC인 것이 일반적으로, NTP를 이용하여 동일한 시각을 유지할 수 있다. 예를 들어, 간격 설정 엔진(258d)은 임의의 분 마크(minute mark), 초 마크(second mark), 시 마크(hour mark), 또는 그 밖의 다른 시각 지시자를 수집할 수 있고, 이를, 조절된 폴링 파라미터의 일부로서, 원격 프록시 서버(가령, 프록시(325))로 전달할 수 있다. 마크는 공통의 '초기 시점 t0'로서 모든 애플리케이션에 의해 사용되도록 랜덤하게 선택될 수 있다.

상기의 기재에서, 2개의 애플리케이션의 예시를 이용했지만, 동일한 개수의 프로세스가 임의의 개수의 애플리케이션, 또는 모바일 장치(250) 상의 모든 애플리케이션/클라이언트에 대해 수행될 수 있다. 일부 경우, 폴 간격 조절기(258)의 하나 이상의 구성요소에 의해 수행되는 일부 또는 모든 기능이, 가령, 모바일 장치(250)에서 (가령, 폴 간격 검출기(238)에 의해) 로컬하게 검출된, 폴 간격을 이용하여 원격 프록시 서버(가령, 프록시(325))에서 원격으로 수행될 수 있다. 원격 프록시(가령, 프록시(325))는 복수의 장치에서의 애플리케이션을 위한 폴 간격을 수신하고, 복수의 장치 상의 애플리케이션에 대해 조절된 간격을 추적할 수 있으며, 이는 도 3E의 예시를 이용해 추가로 설명될 것이다.

도 3A는 자원 보존을 위해, 무선 네트워크에서 트래픽을 관리하는 호스트 서버(300)에 상주하는 분산 프록시 및 캐시 시스템에서의 서버 측 구성요소의 일례를 도시하는 블록도를 도시한다. 서버 측 프록시(또는 프록시 서버(325))는 추가로, 애플리케이션 거동, 콘텐츠 우선순위, 사용자 활동, 및/또는 사용자 기대를 기초로 하여, 모바일 트래픽을 카테고리화, 및/또는 전달 정책(delivery policy)을 이행할 수 있다.

호스트 서버(300)는, 예를 들어, 네트워크 인터페이스(308) 및/또는 하나 이상의 레포지토리(312, 314 및 316)를 일반적으로 포함한다. 서버(300)는 임의의 휴대용/모바일 또는 비-휴대용 장치, 서버, 컴퓨터의 클러스터, 및/또는 임의의 유선 또는 무선 네트워크(가령, WiFi, 셀룰러, 블루투스 등)를 포함하는 네트워크를 통해 데이터 요청을 만족시키기 위한 신호를 수신하거나 송신할 수 있는 그 밖의 다른 유형의 프로세싱 유닛(가령, 도 11의 예시의 경우, 임의의 개수의 기계)일 수 있다.

네트워크 인터페이스(308)는 네트워킹 모듈 또는 장치를 포함할 수 있으며, 상기 네트워킹 모듈 또는 장치에 의해, 서버(300)가 호스트 서버(300) 외부의 개체를 갖는 네트워크 내 데이터를, 상기 호스 및 외부 개체에 의해 지원되는 임의의 공지된, 및/또는 종래의 통신 프로토콜을 통해 조정(mediate)할 수 있다. 구체적으로, 네트워크 인터페이스(308)에 의해, 서버(300)는 모바일 전화 장치(350) 및/또는 하나 이상의 애플리케이션 서버/콘텐츠 제공자(310)를 포함하는 복수의 장치와 통신할 수 있다.

호스트 서버(300)는 장치와의 연결에 대한 정보(가령, 네트워크 특성, 조건, 연결 유형 등)를 연결 메타데이터 레포지토리(312)에 저장할 수 있다. 덧붙이자면, 제3자 애플리케이션 또는 콘텐츠 제공자에 대한 임의의 정보가 또한 레포지토리(312)에 저장될 수 있다. 호스트 서버(300)는 장치에 대한 정보(가령, 하드웨어 능력, 속성, 장치 설정, 장치 언어, 네트워크 능력, 제조업체, 장치 모델, OS, OS 버전 등)를 장치 정보 레포지토리(314)에 저장할 수 있다. 덧붙이자면, 호스트 서버(300)는 네트워크 제공자 및 다양한 네트워크 서비스 영역에 대한 정보를 네트워크 서비스 제공자 레포지토리(316)에 저장할 수 있다.

네트워크 인터페이스(308)에 의해 활성화되는 통신은 장치(350)와의 동시 연결(simultaneous connection)(가령, 셀룰러 연결) 및/또는 콘텐츠 서버/제공자(310)와의 연결(가령, 유/무선, HTTP, 인터넷 연결, LAN, WiFi 등)을 가능하게 하여, 네트워크 자원 이용을 최적화하기 위해 장치(350)와 콘텐츠 제공자(310) 간의 트래픽을 관리하거나, 및/또는 서비스받는 장치(350) 상의 전력(배터리) 소모량을 보존할 수 있다. 상기 호스트 서버(300)는 상이한 네트워크 서비스 제공자에 의해 서비스되는, 및/또는 동일/상이한 네트워크 서비스 영역에서 서비스되는 모바일 장치(350)와 통신할 수 있다. 호스트 서버(300)는 다양한 유형 또는 레벨의 모바일 능력(mobile capability)(가령, 1G, 2G, 2G 과도세대(2.5G, 2.75G), 3G(IMT-2000), 3G 과도세대(3.5G, 3.75G, 3.9G), 4G(IMT-advanced) 등)을 갖는 장치(350)를 운영하고, 상기 장치(350)와 호환된다.

일반적으로, 네트워크 인터페이스(308)는, 라우터, 액세스 포인트, 무선 라우터, 스위치, 멀티레이어 스위치, 프로토콜 변환기, 게이트웨이, 브리지, 브리지 라우터, 허브, 디지털 미디어 수신기, 및/또는 리피터를 통해 연결되거나 연결되지 않는지의 여부에 무관하게, 네트워크 어댑터 카드, 무선 네트워크 인터페이스 카드(가령, SMS 인터페이스, WiFi 인터페이스, 다양한 세대의 모바일 통신 표준(1G, 2G, 3G, 3.5G, 4G형 네트워크 가령, LTE, WiMAX, 등)용 인터페이스, Bluetooth, WiFi, 또는 그 밖의 다른 임의의 네트워크 중 하나 이상을 포함할 수 있다.

호스트 서버(300)는 프록시 서버(325) 및 서버 캐시(335)를 포함할 수 있는 분산 프록시 및 캐시 시스템의 서버 측 구성요소를 더 포함할 수 있다. 하나의 실시예에서, 프록시 서버(325)는 HTTP 액세스 엔진(345), 캐시 정책 관리기(355), 프록시 제어기(365), 트래픽 성형 엔진(375), 새로운 데이터 검출기(347) 및/또는 연결 관리기(395)를 포함할 수 있다.

HTTP 액세스 엔진(345)은 하트비트 관리기(heartbeat manager)(398)를 더 포함할 수 있고, 프록시 제어기(365)는 데이터 무효화기 모듈(368)을 더 포함할 수 있으며, 트래픽 성형 엔진(375)은 제어 프로토콜(376) 및 일괄처리 모듈(377)을 더 포함할 수 있다. 이보다 많거나 더 적은 구성요소/모듈/엔진이 프록시 서버(325) 및 각각의 설명된 구성요소에 포함될 수 있다.

본원에서 사용될 때, "모듈", "관리기", "핸들러", "검출기", "인터페이스", "제어기", "정규화기", "생성기", "무효화기", 또는 "엔진"은 범용, 전용, 또는 공용 프로세서를 포함하고, 일반적으로, 프로세서에 의해 실행되는 펌웨어 또는 소프트웨어 모듈을 포함한다. 구현예 특정적 고려사항, 또는 그 밖의 다른 고려사항에 따라서, 모듈, 관리기, 핸들러, 검출기, 인터페이스, 제어기, 정규화기, 생성기, 무효화기, 또는 엔진은 중앙 집중형이거나, 그들의 기능이 분산될 수 있다. 모듈, 관리기, 핸들러, 검출기, 인터페이스, 제어기, 정규화기, 생성기, 무효화기, 또는 엔진은 범용 또는 특수용 하드웨어, 펌웨어, 또는 프로세서에 의해 실행되기 위한 컴퓨터 판독형 (저장) 매체에 내장된 소트프웨어를 포함할 수 있다. 본원에서 사용될 때, 컴퓨터 판독형 매체, 또는 컴퓨터 판독형 저장 매체는 법령(가령, 미국에서는, 35 U.S.C. 101)으로 명시된 모든 매체를 포함하며, 컴퓨터 판독형(저장) 매체를 포함하는 청구항이 유효하기 위한 범위까지 모든 비법정 매체는 특정하게 배제하는 것으로 의도된다. 알려진 법정 컴퓨터 판독형 매체는 하드웨어(가령, 레지스터, 랜덤 액세스 메모리(RAM), 비휘발성(NV) 저장장치 등)를 포함하지만, 이러한 하드웨어로 반드시 한정되는 것은 아니다.

애플리케이션 서버 또는 콘텐츠 제공자(310)에게 애플리케이션 또는 콘텐츠 요청을 하는 장치(가령, 모바일 장치(350)의 예에서, 상기 요청이 인터셉트되고, 장치(350) 및 애플리케이션 서버/콘텐츠 제공자(310)로 연결되어 있는 프록시 서버(325)로 라우팅될 수 있다. 구체적으로, 프록시 서버는 모바일 장치(350)의 로컬 프록시(가령, 도 1 및 2의 예시의 경우, 프록시(175 및 275))와 통신할 수 있고, 일부 경우 추가 프로세싱을 위해, 그리고 필요한 경우, 데이터 요청에 대해 응답하기 위해 애플리케이션 서버/콘텐츠 서버(310)로의 송신을 위해, 로컬 프록시는 데이터 요청을 프록시 서버(325)로 포워딩한다.

이러한 구성에서, 호스트(300), 또는 호스트 서버(300) 내 프록시 서버(325)는, 네트워크 및 장치 자원의 이용을 최적화하는 방식으로 장치와의 통신을 조절할 때 로컬 프록시에 의해 제공되는 지능적 정보(intelligent information)를 이용할 수 있다. 예를 들어, 프록시 서버(325)는 장치(350)에서의 사용자 활동의 특성을 식별하여, 통신 빈도(communication frequency)를 수정할 수 있다. 사용자 활동의 특성은, 예를 들어, 장치(350) 상의 로컬 프록시에 의해 수집된 정보를 통해, 프록시 제어기(365) 내 활동/거동 인지 모듈(activity/behavior awareness module)(366)에 의해 결정될 수 있다.

하나의 실시예에서, 통신 빈도는, 예를 들어, 프록시 서버(325)의 연결 관리기(395)에 의해 제어되어, 장치(350)로의 콘텐츠의 푸시 빈도 또는 업데이트를 조절할 수 있다. 예를 들어, 사용자 활동의 특성이 사용자가 비활성(inactive) 상태라고 가리키는 경우, 연결 관리기(395)에 의해 푸시 빈도가 감소할 수 있다. 하나의 실시예에서, 사용자 활동의 특성이, 비활성 상태의 주기 후, 사용자가 활성 상태라고 가리킬 때, 연결 관리기(395)는, 장치(350)로의 감소된 통신 빈도의 결과로서 버퍼링된 데이터를 전송하기 위해 장치(350)와의 통신 빈도를 조절할 수 있다.

덧붙이자면, 프록시 서버(325)는 다양한 요청, 트랜잭션, 세션, 애플리케이션, 및/또는 특정 이벤트의 우선순위 인지(priority awareness)를 포함한다. 이러한 인지는 장치(350) 상의 로컬 프록시에 의해 결정되고 프록시 서버(325)로 제공될 수 있다. 일반적으로, 프록시 서버(325)의 우선순위 인지 모듈(367)이 다양한 이벤트 또는 애플리케이션의 우선순위(가령, 시간-중요도, 시간-민감도, 등)를 평가할 수 있고, 추가로, 우선순위 인지 모듈(367)이 장치(350)의 로컬 프록시들에 의해 결정된 우선순위를 추적할 수 있다.

하나의 실시예에서, 우선순위 인지를 통해, 연결 관리기(395)는 장치(350)와의 서버(300)의 통신 빈도를 더 수정할 수 있다(가령, 라디오 제어기(396)에 의해 제어될 때 라디오를 사용하는 것). 예를 들어, 서버(300)가 장치(350)에서 기준을 충족하는 중요도/우선순위 레벨의 데이터 또는 업데이트가 전송 가능해질 때를 통지할 수 있고, 따라서 이미 사용 중이 아닌 경우 라디오의 사용을 요청할 수 있다.

하나의 실시예에서, 프록시 서버(325)는 이벤트(가령, 트랜잭션, 콘텐츠, 서버/제공자(310)로부터 수신된 데이터)의 복수의 발생을 검출할 수 있으며, 이벤트들이 축적되어, 장치(350)로 일괄 전송되도록 할 수 있다. 일괄 전송은 누적될 수 있고, 모듈(367 및/또는 366)에 의해 추적되는 우선순위 인지 및/또는 사용자 활동/애플리케이션 거동 인지를 기초로 하여 이벤트의 전송이 지연될 수 있다. 예를 들어, (임계치 또는 기준을 충족하는) 더 높은 우선순위의 이벤트가 서버(300)에서 검출될 때, (더 낮은 우선순위를 갖는) 복수의 이벤트를 장치(350)로 일괄 전송하는 것은 일괄처리 모듈(377)에 의해 개시될 수 있다. 덧붙이자면, 서버가 장치(350)로부터 데이터를 수신할 때 서버(300)로부터의 일괄 전송이 트리거될 수 있으며, 이는, 장치 라디오가 이미 사용중이며, 따라서 장치 라디오가 켜진 상태임을 가리킨다. 하나의 실시예에서, 프록시 서버(325)는, 이벤트/트랜잭션 우선순위를 기초로 하여, 각각의 메시지/패킷을 일괄 전송되도록 정렬하여, 연결이 소실되거나 배터리가 닳은 경우 등에서, 더 높은 우선순위 콘텐츠가 먼저 전송될 수 있도록 할 수 있다.

하나의 실시예에서, 서버(300)는 (가령, 캐싱 정책 관리기(355)에 의해 관리되는) 데이터를 캐싱함으로써, 네트워크(가령 셀룰러 네트워크)를 통한 장치(350)와의 통신 빈도가 수정(가령, 감소)될 수 있다. 예를 들어, 데이터가 서버 캐시(335)에 캐싱되어, 추후 불러와 지거나(retrieval) 장치(350)로 일괄 전송될 수 있음으로써, 장치(350) 라디오를 켤 필요성이 낮아질 가능성이 있다. 서버 캐시(335)는, 도 3A의 예에서, 호스트 서버(300) 외부에 위치하는 것처럼 도시되지만, 호스트 서버(300) 내부에 부분적으로 또는 전적으로 위치할 수 있다. 일부 경우, 서버 캐시(335)는, 가령, 애플리케이션 서버/콘텐츠 제공자(310), 네트워크 서비스 제공자, 또는 또 다른 제3자에 의해 관리되는 바와 같이, 또 다른 개체(가령, 도 1B의 예시의 경우, 선택적 캐싱 프록시 서버(199))에 의해 관리되는 또 다른 캐시와 부분적으로 또는 전적으로 동일하거나 일체로 구성될 수 있다.

하나의 실시예에서, 콘텐츠 캐싱은, 호스트 서버(300)의 도움으로, 장치(350)에서 로컬하게 수행된다. 예를 들어, 호스트 서버(300) 내 프록시 서버(325)가 요청과 함께 애플리케이션 서버/제공자(310)에게 질의할 수 있으며, 응답의 변경을 모니터링할 수 있다. (가령, 새로운 데이터 검출기(347)에 의해) 변경되거나 새로운 응답이 검출될 때, 프록시 서버(325)는 모바일 장치(350)에게 통지하여, 장치(350) 상의 로컬 프록시가, 자신의 로컬 캐시 내에 임의의 응답으로서 저장되어 있는 관련 캐시 엔트리를 무효화하기(가령, 날짜가 지났다(out-dated)고 표시하기)로 결정할 수 있다. 또는, 데이터 무효화기 모듈(368)이, 애플리케이션 서버/제공자(310)로부터 수신된 응답을 기초로 하여 특정 캐싱된 데이터를 무효화하라고 장치(350)의 로컬 프록시에게 자동으로 명령할 수 있다. 캐싱된 데이터는 무효(invalid)라고 표시되며, 콘텐츠 서버(310)로부터 새로운 콘텐츠가 수신될 때 대체되거나 삭제될 수 있다.

검출기(347)에 의해 하나 이상의 방식으로 데이터 변경이 검출된다. 예를 들어, 변경이 있은 후, 서버/제공자(310)가 호스트 서버(300)에게 통지할 수 있다. 또한 변경은, 소스 서버/제공자(310)의 직접적인 폴에 응답하여, 호스트 서버(300)에서 검출될 수 있다. 일부 경우, 이에 추가로, 프록시 서버(325)가, 새로운/업데이트된 데이터로 장치(350) 상의 로컬 캐시를 사전-로딩(pre-load)할 수 있다. 이는, 호스트 서버(300)가 모바일 장치 상의 라디오가 이미 사용 중이라고 검출할 때, 또는 서버(300)가 장치(350)로 전송될 추가 콘텐츠/데이터를 가질 때, 수행될 수 있다.

상기의 메커니즘들 중 하나 이상이 동시에 구현되거나, 애플리케이션(가령, 서로 다른 서버/제공자(310)를 위한 서로 다른 정책)에 따라 조절/설정될 수 있다. 일부 경우, 특정 유형의 이벤트(가령, 우선순위 임계 레벨을 충족하는 이벤트)의 경우, 소스 제공자/서버(310)가 호스트(300)에게 통지할 수 있다. 덧붙여, 이벤트 우선순위에 무관하게, 제공자/서버(310)가 특정 시간 간격으로 호스트(300)에게 통지하도록 설정될 수 있다.

하나의 실시예에서, 호스트(300)의 프록시 서버(325)는, 모바일 장치로 결과를 반환하기 전에, 변경된 결과를 찾기 위해 콘텐츠 소스로부터의 데이터 요청에 대해 수신된 응답을 모니터/추적할 수 있으며, 이러한 모니터링은 콘텐츠 소스로의 데이터 요청이 모바일 장치로 반환될 동일한 결과를 산출할 때, 적합할 수 있으며, 이에 따라서, 특정 요청에 대해 어떠한 새로운 변경도 없는 경우, 네트워크/파워 소모량이 사용되는 것이 방지된다. 장치(350)의 로컬 프록시가 프록시 서버(325)에게 이러한 모니터링을 수행하도록 명령하거나, 특정 요청에 대해 특정 개수의 동일한 응답(가령, 일정 시간 주기 내에 복수의 동일한 응답)을 수신하면 프록시 서버(325)가 이러한 프로세스를 자동으로 개시할 수 있다.

하나의 실시예에서, 서버(300)는, 활동/거동 인지 모듈(366)을 통해, 모바일 장치(350)와 별개의 장치에서의 사용자 활동을 식별하거나 검출할 수 있다. 예를 들어, 모듈(366)은 사용자의 메시지 수신함(message inbox)(가령, 전자메일 또는 다른 유형의 수신함)이 액세스되고 있음을 검출할 수 있다. 이는 사용자가 모바일 장치(350)가 아닌 장치를 이용해 자신의 애플리케이션과 상호대화 중이며, 빈번한 업데이트가 필요하지 않음을 나타낼 수 있다.

이러한 경우, 따라서 서버(300)는 새로운 또는 업데이트된 콘텐츠가 모바일 장치(350)로 전송되는 빈도를 감소시킬 수 있고, 사용자가 또 다른 장치를 이용해 액세스한다고 검출되는 한, 모든 통신을 삭제할 수 있다. 이러한 빈도 감소는 애플리케이션 특정적(가령, 사용자가 또 다른 장치와 상호대화하는 중인 애플리케이션에 특정됨)일 수 있거나, 모바일 장치(350)에 대한 전반적인 빈도 감소일 수 있다(가령, 사용자가 다른 장치를 통해, 하나의 서버 또는 하나의 애플리케이션과 상호대화한다고 검출되기 때문에, 사용자는 또 다른 서비스를 액세스할 때 이를 사용할 수 있다).

하나의 실시예에서, 장치(350)에서의 전력 또는 배터리 소모량을 보존하기 위해, 호스트 서버(300)는 장치(350)를 대신하여 콘텐츠 소스(310)로 폴링할 수 있다. 예를 들어, 모바일 장치(35) 상의 특정 애플리케이션은 예측가능한 반복 방식으로 자신의 각자의 서버(310)로 폴링할 수 있다. 프록시 제어기(365) 내 활동/거동 모듈(366)에 의해 이러한 반복 또는 또 다른 유형의 애플리케이션 거동이 추적될 수 있다. 따라서 호스트 서버(300)는 모바일 장치(350) 상의 애플리케이션에 대해 콘텐츠 소스(310)로 폴링할 수 있으며, 이러한 폴링은, 다른 경우라면, 다른 경우라면 장치(350)에 의해 무선(가령, 셀룰러 연결)을 통해 수행됐을 것이다. 호스트 서버는, HTTP 액세스 엔진(345)을 이용해 HTTP 연결을 구축함으로써, 또는 라디오 제어기(396)를 이용해 셀룰러 네트워크를 통해 소스(310)로 연결함으로써, 새로운 또는 변경된 데이터를 찾기 위해 소스(310)로 폴링할 수 있다. 새로운 또는 변경된 데이터가 검출될 때, 새로운 데이터 검출기(347)는 장치(350)에게, 이러한 데이터가 이용 가능하다고 통지, 및/또는 새로운/변경된 데이터를 장치(350)로 제공할 수 있다.

하나의 실시예에서, 연결 관리기(395)는 모바일 장치(350)가 이용 가능하지 않다고(가령, 라디오가 꺼져 있다고) 결정하고, SMS를 이용해(가령, 도 1B의 예시에 도시된 SMSC를 통해) 장치(350)에게 콘텐츠를 전송할 수 있다. SMS는 무효화 메시지, 또는 무효화 메시지의 일괄분(batch), 또는 심지어 콘텐츠(콘텐츠가 단 몇 개의 SMS 메시지(보통 1개 또는 2개의 SMS 메시지)에 맞기에 충분히 작은 경우)를 전송하도록 사용된다. 이로 인해, 오버헤드 정보(overhead information)를 전송하기 위해 라디오 채널을 액세스할 필요가 없어진다. 호스트 서버(300)는 임계치에 가까운 우선순위 레벨을 갖거나 그 밖의 다른 방식으로 기준을 충족하는 특정 트랜잭션 또는 응답을 위해 SMS를 이용할 수 있다. 서버(300)는, 상시 접속된(always-on) IP 연결을 유지하는 것의 대안예로서, 대역외 트리거(out-of-band trigger)로서 SMS를 이용하여, IP 연결을 유지하거나 각성시킬 수 있다.

하나의 실시예에서, 프록시 서버(325) 내 연결 관리기(395)(가령, 하트비트 관리기(398))가, 연결된 장치(350)를 대신하여, 하트비트 메시지를 생성 및/또는 전송함으로써, 장치(350)에서 실행 중인 애플리케이션을 위한 제공자(310)와의 백엔드 연결(backend connection)을 유지할 수 있다.

예를 들어, 분산 프록시 시스템에서, 장치(350) 상의 로컬 캐시가, 애플리케이션을 위해 요구되는 TCP/IP 연결을 유지하기 위해 필요한 임의의 또는 모든 하트비트 메시지가 셀룰러 또는 그 밖의 다른 네트워크를 통해 전송되는 것을 방지하고, 대신, 호스트 서버(300) 상의 프록시 서버(325)에 의존하여, 백엔드(가령, 도 1A의 예시의 경우, 애플리케이션 서버/제공자(110))와의 연결을 유지하기 위한 하트비트 메시지를 생성 및/또는 전송할 수 있다. 프록시 서버는, 모바일 장치 상의 로컬 프록시의 동작에 독립적으로, 킵-얼라이브(keep-alive)(하트비트) 메시지를 생성할 수 있다.

레포지토리(312, 314 및/또는 316)가 소프트웨어, 서술적 데이터(descriptive data), 이미지, 시스템 정보 드라이버, 및/또는 호스트 서버(300) 및/또는 그 밖의 다른 서버의 그 밖의 다른 구성요소에 의해 사용되는 그 밖의 다른 임의의 데이터 아이템을 추가로 저장할 수 있다. 레포지토리는 데이터베이스 관리 시스템(DBMS)에 의해 관리될 수 있으며, 가령, 상기 데이터베이스 관리 시스템은 Oracle, DB2, Microsoft Access, Microsoft SQL Server, PostgreSQL, MySQL, FileMaker 등일 수 있다(그러나 이에 국한되지 않음).

레포지토리는 객체 지향 기법 및/또는 텍스트 파일을 통해 구현될 수 있으며, 분산 데이터베이스 관리 시스템, 객체 지향 데이터베이스 관리 시스템(OODBMS)(가령, ConceptBase, FastDB 메인 메모리 데이터베이스 관리 시스템, JDOInstruments, ObjectDB, 등), 객체 관련 데이터베이스 관리 시스템(ORDBMS)(가령, Informix, OpenLink Virtuoso, VMDS, 등), 파일 시스템, 및/또는 그 밖의 다른 임의의 종래의, 즉 공지된 데이터베이스 관리 패키지에 의해 관리될 수 있다.

도 3B는 애플리케이션(가령, 모바일 애플리케이션) 거동 및/또는 네트워크 조건에 대해 캐싱하고 캐싱 전략을 조정할 수 있는 도 3A에서 도시되는 캐시 시스템에서의 캐싱 정책 관리기(355) 내 구성요소의 추가 예를 도시하는 블록도를 도시한다.

하나의 실시예에서, 캐싱 정책 관리기(355)는 메타데이터 생성기(303), 캐시 룩-업 엔진(305), 애플리케이션 프로토콜 모듈(356), 폴 스케줄 관리기(358)를 갖는 콘텐츠 소스 모니터링 엔진(357), 응답 분석기(361), 및/또는 업데이트된 또는 새로운 콘텐츠 검출기(359)를 더 포함할 수 있다. 하나의 실시예에서, 폴 스케줄 관리기(358)는 호스트 타이밍 시뮬레이터(358a), 롱 폴 요청 검출기/관리기(358b), 스케줄 업데이트 엔진(358c), 및/또는 시간 조정 엔진(358d)를 더 포함한다. 메타데이터 생성기(303) 및/또는 캐시 룩-업 엔진(305)은 캐시(335)(또는 서버 캐시)로 연결되어, 캐시 엔트리 또는 캐시 엔트리의 질의를 수정하거나 추가할 수 있다.

하나의 실시예에서, 프록시 서버(가령, 도 1B 및 도 3A의 예시의 프록시 서버(125 또는 325))가 모니터링 엔진(357)을 통해 새로운 또는 변경된 데이터를 찾기 위해 콘텐츠 소스를 모니터링할 수 있다. 도시된 것처럼, 프록시 서버는 도 2A-B의 모바일 장치(250) 외부의 개체이다. 콘텐츠 소스(가령, 도 1B의 애플리케이션 서버/콘텐츠 제공자(110))는, (가령, 로컬 프록시에 의해) 프록시 서버에게, 모바일 장치(가령, 모바일 장치(150 또는 250)) 상에 로컬하게 캐싱되어 있는 콘텐츠를 갖는다고 알려진 것일 수 있다. 예를 들어, 모바일 장치에서의 콘텐츠 소스의 폴링 빈도를 기초로 하는 빈도로 모니터링 엔진(357)에 의해 콘텐츠 소스가 모니터링될 수 있다. 폴 스케줄은, 예를 들어, 로컬 프록시에 의해 생성되고, 프록시 서버로 전송될 수 있다. 폴 스케줄 관리기(358)에 의해, 폴 빈도가 추적, 및/또는 관리될 수 있다.

예를 들어, 프록시 서버는. 모바일 장치를 대신하여, 호스트(가령, 콘텐츠 제공자/애플리케이션 서버)로 폴링할 수 있고, 호스트 타이밍 시뮬레이터(358a)를 통해 클라이언트의 폴링 거동(polling behavior)을 호스트로 시뮬레이트할 수 있다. (가령, 롱 폴 요청 검출기/관리기(358b)에 의해) 폴링 거동은 호스트와의 지속형 연결에서 겪는 롱 폴 요청-응답 시퀀스의 특성을 포함하도록 시뮬레이트될 수 있다. 폴링 간격/거동이 설정되면, 장치 측의 로컬 프록시(275) 및/또는 서버 측의 프록시 서버(325)가, 애플리케이션 및 애플리케이션 서버/콘텐츠 호스트 거동이 매칭되는지, 또는 이러한 예측 패턴에 의해 표현될 수 있는지 여부를 검증할 수 있다. 일반적으로, 로컬 프록시 및/또는 프록시 서버가 편이(deviation)를 검출할 수 있고, 적절할 때, 또 다른 폴링 간격을 재-평가 및 계산, 결정, 또는 추정할 수 있다.

하나의 실시예에서, 분산 프록시의 서버 측 상의 캐싱 정책 관리기(355)는, 모바일 장치 상의 프록시 서버(275)와 함께, 또는 상기 프록시 서버(275)와 독립적으로, 롱 폴 요청을 식별하거나 검출할 수 있다. 예를 들어, 캐싱 정책 관리기(355)는, 롱 폴 요청, 가능한 롱 폴 요청(가령, 클라이언트가 통신할 때 이용하는 호스트와의 지속형 연결에 대한 요청(가령, 장기 유지 HTTP 요청, 지속형 연결 가능 COMET 스타일 푸시, HTTP 스트리밍에 대한 요청 등))을 식별 또는 검출하라는 애플리케이션 요청에 대한 요청-응답 시퀀스에서, 응답 지연 간격 시간(도 17A-B의 예시적 타이밍도에서 도시된 간격 시간 'D')과 비교되어 사용될 임계값을 결정할 수 있다.

예를 들어, 복수의 서로 다른 셀룰러 또는 무선 네트워크에 의해 서비스받을 수 있는 모바일 장치들의 클라이언트/애플리케이션에 의해 생성된 요청에 대한 응답 지연 간격 시간을 이용해 프록시(325)에 의해 임계값이 결정될 수 있다. 호스트(300)에 상주하는 프록시(325)가 복수의 네트워크를 통해 복수의 모바일 장치와 통신할 수 있기 때문에, 캐싱 정책 관리기(355)는, 롱 폴을 카테고리화하고 검출하기 위한 임계값을 설정할 때 사용될 수 있는 글로벌 레벨(global level)에서 애플리케이션/클라이언트 정보를 액세스할 수 있다.

여러 다른 또는 하나의 동일한 네트워크에 걸쳐 있는 장치들의 애플리케이션들의 응답 지연 수간 시간을 추적함으로써, 캐싱 정책 관리기(355)는 하나 이상의 임계값을, 롱 폴 검출을 위해 응답 지연 간격 시간과 비교하여 사용되도록 설정할 수 있다. 프록시 서버(325)에 의해 설정된 임계값은 정적이거나 동적일 수 있으며, 조건 및/또는 수명시간(상대적 또는 절대적인 만료 시각/날짜)과 관련될 수 있다.

덧붙이자면, 프록시(325)의 캐싱 정책 관리기(355)는, 전적으로 또는 부분적으로, 특정 무선 네트워크의 네트워크 지연, 특정 통신업체(서비스 제공자)에 의해 서비스되는 네트워크, 또는 복수의 무선 네트워크를 기초로 하여, 임계값을 더 결정할 수 있다. 또한 프록시(325)는 애플리케이션(가령, 모바일 애플리케이션) 또는 모바일 클라이언트 요청이 전달되는 하나 이상의 애플리케이션 서버/콘텐츠 제공자(가령, 110)의 지연을 기초로 하여, 롱 폴 요청의 식별을 위한 임계값을 결정할 수 있다.

프록시 서버는 모니터링된 콘텐츠 소스에서 새로운 또는 변경된 데이터를 검출하고, 모바일 장치에게 이러한 변경을 통지하는 메시지를 전송함으로써, 모바일 방치(또는 모바일 장치의 로컬 프록시)가 적절한 조치(가령, 로컬 캐시 내 캐시 요소를 무효화하기)를 취할 수 있다. 일부 경우, 프록시 서버(가령, 캐싱 정책 관리기(355))는 새롭거나 변경된 데이터를 검출하면, 상기 새롭거나 변경된 데이터를 자신의 캐시(가령, 도 1B 및 도 3A의 서버 캐시(135 또는 335))에 저장할 수 있다. 일부 경우, 모바일 장치에서의 콘텐츠 요청을 만족시키기 위해, 서버 캐시(335)에 저장된 새롭거나 업데이트된 데이터가 사용될 수 있으며, 예를 들어, 프록시 서버가 모바일 장치에게 새롭거나 변경된 콘텐츠를 통지하고, 로컬 캐싱된 콘텐츠가 무효화된 후 사용될 수 있다.

메타데이터 생성기(303)는, 도 2B의 예시에 도시된 메타데이터 생성기(203)와 유사하게, 모바일 장치(250)에서의 요청에 대해 캐싱된 응답에 대해 메타데이터를 생성할 수 있다. 메타데이터 생성기(303)가 서버 캐시(335)에 저장된 캐시 엔트리를 위한 메타데이터를 생성할 수 있다. 마찬가지로, 캐시 룩-업 엔진(305)은 도 2B의 예시의 캐시 룩-업 엔진(205)에 대해 기재된 것과 동일하거나 유사한 기능을 포함할 수 있다.

응답 분석기(361)는 모바일 장치(250)에서 생성된 요청에 대해 수신된 응답을 분석하는 것과 관련된 일부 또는 모든 기능을 도 2B에서 도시된 로컬 프록시의 응답 분석기(246d)와 동일하거나 유사한 방식으로 수행할 수 있다. 프록시 서버(325)가, 모바일 장치(250)로 전달되는 애플리케이션 서버/콘텐츠 소스(310)로부터의 응답을 수신할 수 있기 때문에, 프록시 서버(325)(가령, 응답 분석기(361))는, 캐싱 가능함을 판단하기 위해, 로컬 프록시의 응답 분석기에 대해 설명된 것과 유사한 응답 분석 단계를 수행할 수 있다. 응답 분석 절차의 예시가 도 11-13에서 도시된 흐름도와 함께 설명된다. 모바일 장치(250) 상의 로컬 프록시(275)에서 수행될 수 있는 분석에 추가로, 또는 상기 분석을 대신하여 응답이 분석될 수 있다.

덧붙이자면, 스케줄 업데이트 엔진(358c)은, 로컬 프록시(275) 내 스케줄 업데이트 엔진에 대해 기재된 것처럼, 모바일 장치(250)에서의 애플리케이션의 애플리케이션 요청 간격 변경을 기초로 하여 특정 애플리케이션 서버/콘텐츠 호스트의 폴링 간격을 업데이트할 수 있다. 시간 조정 엔진(358d)은 초기 시점을 설정하며, 상기 초기 시점에서 애플리케이션 서버/콘텐츠 호스트의 폴은, 로컬 프록시(275) 내 스케줄 업데이트 엔진에 대해 기재된 바 있는 프레시 콘텐츠(fresh content)를 서비스하기 전에, 오래된(out of date) 콘텐츠를 다시 한 번 서비스하는 것을 막는 것이다. 스케줄 업데이팅 및 시간 조절 알고리즘 모두, 모바일 장치(250) 상의 로컬 프록시(275)에서 유사한 프로세스와 함께, 또는 상기 프로세스를 대체하여 수행될 수 있다.

도 3C는, 캐시 디피트 메커니즘을 관리 및 검출하고 콘텐츠 소스를 모니터링할 수 있는 도 3A의 예시에서 도시된 분산 프록시 시스템의 서버 측 상의 프록시 서버(375) 내 캐싱 정책 관리기(355)의 구성요소의 또 다른 예를 도시하는 블록도를 도시한다.

하나의 실시예에서, 캐싱 정책 관리기(355)는 캐시 디피트 소스 관리기(352), 폴 스케줄 관리기(358)를 갖는 콘텐츠 소스 모니터링 엔진(357), 및/또는 업데이트되거나 새로운 콘텐츠 검출기(359)를 더 포함할 수 있다. 캐시 디피트 소스 관리기(352)는 식별자 수정기 모듈(353) 및/또는 식별자 패턴 추적 모듈(354)을 더 포함할 수 있다.

하나의 실시예에서, 프록시 서버(가령, 도 1B 및 도 3A의 예시의 프록시 서버(125 또는 325)는 모니터링 엔진(357)을 통해 새롭거나 변경된 데이터를 찾기 위해 콘텐츠 소스를 모니터링할 수 있다. 콘텐츠 소스(가령, 도 1B 또는 도 3A의 애플리케이션 서버/콘텐츠 제공자(110 또는 310))는, (가령, 로컬 프록시에 의해) 프록시 서버에게, 모바일 장치(가령, 모바일 장치(150 또는 250)) 상에 로컬 캐싱된 콘텐츠를 갖는다고 알려진 것일 수 있다. 콘텐츠 소스(310)는, 예를 들어, 모바일 장치에서 콘텐츠 소스의 폴링 빈도를 기초로 하는 빈도로 모니터링 엔진(357)에 의해 모니터링될 수 있다. 예를 들어, 폴링 스케줄은 로컬 프록시에 의해 생성되고 프록시 서버(325)로 전송될 수 있다. 폴 스케줄 관리기(358)에 의해 폴 주파수가 추적 및/또는 관리될 수 있다.

하나의 실시예에서, 프록시 서버(325)는 새롭거나 변경된 데이터(응답)를 검출하기 위해 콘텐츠 소스(310)로 폴링할 때, 정규화된 식별자 또는 수정된 식별자를 이용한다. 또한, 서버 캐시(335)에 응답을 저장할 때 정규화된 식별자 또는 수정된 식별자가 프록시 서버(325)에 의해 사용될 수 있다. 일반적으로, 캐싱 가능한 콘텐츠에 대해 캐시 디피트(cache defeat) 메커니즘이 사용될 때 정규화된 또는 수정된 식별자가 사용될 수 있다. 캐시 디피트 메커니즘은, 식별자 내 변하는 파라미터(changing parameter)의 형태(가령, URI 또는 URL), 변하는 시/날짜 파라미터, 랜덤하게 변하는 파라미터, 또는 그 밖의 다른 유형의 파라미터를 가질 수 있다.

뒤 이은 요청 및 연계된 응답의 식별과의 연계를 위해, 정규화된 식별자 또는 수정된 식별자가 변하는 파라미터를 제거하거나, 그 밖의 다른 방식으로 대체하고, 콘텐츠 소스를 폴링하도록 사용될 수 있다. 하나의 실시예에서, 프록시 서버(325) 상의 캐싱 정책 관리기(355)의 캐시 디피트 소스 관리기(352)(분산 프록시 시스템의 서버 측 구성요소)(가령, 식별자 수정기 모듈(353))에 의해 수정된 식별자가 생성된다. 수정된 식별자는 캐시를 디피트하도록 사용되는 변하는 파라미터를 대신하여, 대체 파라미터(substitute parameter)(이는 일정 시간 주기 동안 정적(static)임)를 이용할 수 있다.

선택사항으로서, 캐시 디피트 소스 관리기(352)는, 식별자의 다양한 수정본 또는 하나 이상의 콘텐츠 소스(가령, 애플리케이션 서버/콘텐츠 호스트(110 또는 310))에 대해 콘텐츠를 주소 지정하는 식별자들을 추적, 저장, 및 모니터링하여, 콘텐츠 소스로 폴링하기 위해 프록시 서버(325)에 의해 사용된 수정된 식별자 및/또는 정규화된 식별자가 예상 또는 의도한 대로 동작하는지(가령, 동일한 응답, 또는 다른 방식으로 본래의 수정되지 않은 식별자와 여전히 관련성이 있는 응답)를 지속적으로 검증하기 위해, 식별자 패턴 추적 모듈(354)을 포함한다.

패턴 추적 모듈(354)이, 콘텐츠 소스에서 오류나 예측되지 않은 거동(가령, 기대되지 않은 응답이 전송됨)을 초래하는 식별자의 수정본 또는 정규화본을 검출하는 경우, 추적 모듈(354)은 수정본을 로그에 기록할 수 있고, 캐시 디피트 소스 관리기(352)에게 또 다른 수정본/정규화본을 생성할 것을 명령하거나, 로컬 프록시(가령, 로컬 프록시(275))에게 콘텐츠 소스로 폴링할 때 사용되기 위해 또 다른 수정본/정규화본을 생성하기 위해 통지할 수 있다. 이와 함께, 또는 이를 대신하여, 직접 응답이 모바일 장치로 제공되도록 하거나, 및/또는 제대로 동작하는 식별자의 수정본이 생성될 때까지, 모바일 장치(가령, 모바일 장치(250))상의 특정 모바일 애플리케이션/클라이언트로부터의 요청이 임시로 네트워크를 통해 콘텐츠 소스로 전송된다.

하나의 실시예에서, 모바일 장치(가령, 모바일 장치(250))의 로컬 캐시(가령, 캐시(285))에 이미 저장되어 있는 응답에 대해 새롭거나 변경된 데이터가 검출될 때 응답이 서버 캐시 내 서버 캐시 요소로서 저장된다. 따라서 모바일 장치 또는 로컬 프록시(275)가 프록시 서버(325)로 연결되어, 로컬 캐시(285)에 로컬하게 이미 캐싱됐던 요청에 대한 응답(현재 무효인(invalid), 오래된(out-dated), 또는 그 밖의 다른 방식으로 관련성이 없다고 판단된 것)에 대해 새롭거나 변경된 데이터를 불러올 수 있다.

프록시 서버(325)는 모니터링된 애플리케이션 서버/콘텐츠 호스트(310)에서 새롭거나 변경된 데이터를 검출할 수 있고, 모바일 장치로, 이러한 변경에 대해 통지하는 메시지를 전송함으로써, 모바일 장치(또는 모바일 장치의 로컬 프록시)가 적절한 조치(가령, 로컬 캐시 내 캐시 요소를 무효화시키는 것)를 취할 수 있다. 일부 경우, 프록시 서버(가령, 캐싱 정책 관리기(355)는, 새롭거나 변경된 데이터를 검출하면, 상기 새롭거나 변경된 데이터를 자신의 캐시(가령, 도 1B 및 도 3A의 서버 캐시(135 또는 335))에 저장할 수 있다. 일부 경우, 서버 캐시에 저장된 업데이트된/새로운 데이터가 사용되어, 모바일 장치에서의 콘텐츠 요청을 만족시킬 수 있는데, 예를 들어, 프록시 서버가 모바일 장치에게 새롭거나 변경된 콘텐츠를 통지하고, 로컬 캐싱된 콘텐츠가 무효화된 후, 사용될 수 있다.

도 3D는 애플리케이션 거동 및/또는 트래픽 우선순위를 기초로 하여 모바일 트래픽 카테고리화 및 정책 구현을 더 수행할 수 있는 도 3A의 예에서 나타난 프록시 서버(325) 내 추가 구성요소의 예를 도시하는 블록도를 도시한다.

프록시 서버(325)의 하나의 실시예에서, 트래픽 성형 엔진(375)이 트래픽 분석기(336)로 더 연결되어, 하나 이상의 모바일 장치(가령, 도 2A-2D의 모바일 장치(250)) 또는 애플리케이션 서버/콘텐츠 호스트(도 1A-1B의 110)로 전달되는 모바일 트래픽 및 트랜잭션에 대한 정책의 정의 및 이행에 대해, 모바일 트래픽을 카테고리화할 수 있다. 일반적으로, 도 1A-1B의 예에서 도시된 것처럼, 프록시 서버(325)는 모바일 장치의 원격에 위치하고, 호스트 서버의 원격에 위치한다. 프록시 서버(325) 또는 호스트 서버(300)는 복수의 모바일 장치에 대해 트래픽을 모니터링하고, 여러 다른 모바일 장치에 대해, 트래픽을 카테고리화하고 트래픽 정책을 고안할 수 있다.

덧붙이자면, 프록시 서버(325) 또는 호스트 서버(300)가 복수의 통신업체(carrier) 또는 네트워크 운영자에 의해 동작되고, 다양한 카케고리에 대해, 트래픽의 카테고리화 및 트래픽 정책의 구현과 관련된 통신업체 특정 정책을 구현할 수 있다. 예를 들어, 프록시 서버(325) 또는 호스트 서버(300)의 트래픽 분석기(336)가 우선순위화 엔진(341a), 시간 중요도 검출 엔진(341b), 애플리케이션 상태 카테고리화기(341c), 및/또는 애플리케이션 트래픽 카테고리화기(341d)를 포함할 수 있다.

이들 엔진 또는 모듈 각각은, 서로 다른 무선 통신업체에 따라, 고려할 것으로 우선순위, 시간 중요도, 배경/전경, 또는 상호대화형/유지관리형의 서로 다른 기준을 추적할 수 있다. 서로 다른 기준이 서로 다른 모바일 장치 유형(가령, 장치 모델, 제조업체, 운영 체제 등)에 대해 존재할 수 있다. 일부 경우, 모바일 장치의 사용자가 트래픽 카테고리와 관련된 설정 또는 기준을 조절하고, 프록시 서버(325)가 이들 사용자에 의해 조절/설정되는 설정을 추적하고 구현할 수 있다.

하나의 실시예에서, 트래픽 분석기(336)는, 예를 들어 애플리케이션 상태 카테고리화기(341c) 및/또는 트래픽 카테고리화기(341d)를 통해 트래픽이 발원되거나 전달되는 하나 이상의 모바일 장치(가령, 모바일 장치(150 또는 250)) 상의 애플리케이션의 활동 상태를 검출, 결정, 식별, 또는 추론할 수 있다. 네트워크 사용을 최적화하기 위해, 전경 애플리케이션 트래픽 vs. 배경 애플리케이션 트래픽이 상이하게 핸들링될 수 있기 때문에, (가령, 애플리케이션 상태 카테고리화기(341c)를 통해) 모바일 장치들 중 하나 이상 상의 애플리케이션이 전경 상태인지 배경 상태인지를 기초로 하여, 활동 상태가 결정될 수 있다.

이를 대신하여, 또는 이와 함께, 무선 연결된 모바일 장치에 의해(가령, 로컬 프록시 내 애플리케이션 거동 검출기를 통해) 애플리케이션의 활동 상태가 결정되고, 프록시 서버(325)로 전달될 수 있다. 예를 들어, (가령, 백라이트 검출기에 의한) 모바일 장치에서의 백라이트 상태를 기초로 하여, 또는 모바일 장치 상의 또 다른 소프트웨어 에이전트 또는 하드웨어 센서(가령, 저항성 센서, 용량성 센서, 주변광 센서, 모션 센서, 터치 센서 등)를 기초로 하여, 휴리스틱(heuristic)의 확신도를 갖는, 활동 상태가 결정, 검출, 식별, 또는 추론될 수 있다. 일반적으로, 백라이트가 켜진 경우, 트래픽은 활성 상태이거나 전경에 있는 애플리케이션으로부터 생성된 것으로 취급되거나 결정되거나, 트래픽은 상호대화형일 수 있다. 덧붙여, 백라이트가 켜진 경우, 트래픽은 사용자 상호대화 또는 사용자 활동으로부터 온 트래픽이라고 취급되거나 결정될 수 있거나, 일정 시간 내에 사용자가 기대 중인 데이터를 포함하는 트래픽일 수 있다.

(가령, 사용자 활동 모듈(215)을 통해) 모바일 장치(250)에서 사용자 활동을 산정, 결정, 평가, 추론, 식별하는 것으로부터, 활동 상태가 결정될 수 있고, 프록시 서버(325)로 전달될 수 있다. 하나의 실시예에서, 트래픽이 상호대화형 트래픽인지 유지관리형 트래픽인지 여부를 기초로 하여, 활동 상태가 결정된다. 상호대화형 트래픽은, 사용자 활동/애플리케이션과의 상호대화로부터 직접 생성된 응답 및 요청으로부터의 트랜잭션을 포함할 수 있고, 사용자가 수신하기를 기다리거나 기대 중인 콘텐츠 또는 데이터를 포함할 수 있다. 유지관리형 트래픽은 사용자에 의해 직접 검출되지 않는 애플리케이션의 기능을 지원하기 위해 사용될 수 있다. 또한 유지관리형 트래픽은, 사용자 동작에 응답하여 발생할 수 있지만 사용자가 응답을 적극적으로 기다리거나 대기하지 않는 동작 또는 트랜잭션을 포함할 수 있다.

일반적으로, 시간 중요도 검출 엔진(341b)이 모바일 장치(250)로부터 전송되는 트래픽, 또는 호스트 서버(300) 또는 프록시 서버(325) 또는 애플리케이션 서버(가령, 앱 서버(app server)/콘텐츠 소스(110))로부터 모바일 장치로 전송되는 트래픽에 포함된 데이터의 시간 민감도를 결정, 식별, 추론할 수 있다. 예를 들어, 시간 민감형 데이터는, 상태 업데이트, 주식 정보 업데이트, IM 프레즌스 정보, 전자메일 메시지 또는 그 밖의 다른 메시지, 모바일 게임 애플리케이션으로부터 생성된 동작, 웹페이지 요청, 위치 업데이트 등을 포함할 수 있다.

콘텐츠 또는 요청의 속성상, 시간 민감형이나 시간 중요형이 아닌 데이터는, 메시지 삭제 요청, 읽음 표시, 또는 편집된 동작, 애플리케이션-특정 동작(가령, 친구 추가 또는 친구 삭제 요청), 특정 유형의 메시지, 또는 속성이 빈번하게 변하지 않는 그 밖의 다른 정보 등을 포함할 수 있다. 일부 경우에서, 데이터가 시간 중요형이 아닐 때, 트래픽이 모바일 장치로 전송되게 할 타이밍은, 동일한 모바일 장치로 전송될 필요가 있는 추가 데이터가 존재하는 때를 기초로 한다. 예를 들어, 트래픽 성형 엔진(375)은 하나 이상의 후속하는 트랜잭션과 함께 트래픽을 정렬하여, (가령, 정렬 모듈(378) 및/또는 일괄처리 모듈(377)을 이용해) 모바일 장치 라디오의 한 번의 전원 켜기(power-on) 이벤트로 다 함께 전송되도록 할 수 있다. 또한 정렬 모듈(378)은 동일한 호스트 서버로 전달되는 폴링 요청들을 시간상 가깝게 정렬할 수 있는데, 왜냐하면 이들 요청은 동일한 데이터로 응답될 가능성이 높기 때문이다.

일반적으로, 새롭거나 변경된 데이터가 호스트 서버로부터 모바일 장치로 전송되는지 여부가, 새롭거나 변경된 데이터가 관련된 모바일 장치 상의 애플리케이션이 전경에서 실행 중인지 여부(가령, 애플리케이션 상태 카테고리화기(341c)에 의함), 또는 새롭거나 변경된 데이터의 우선순위 또는 시간 중요도를 기초로 결정될 수 있다. 애플리케이션이 모바일 장치에서 전경에 위치하는 경우, 또는 애플리케이션이 모바일 장치에서 전경에 있고 사용자와 상호대화하는 활성 상태인 경우, 및/또는 사용자가 새롭거나 변경된 데이터에 제공될 응답을 기다리는 중인지 여부에 따라, 프록시 서버(325)는 새롭거나 변경된 데이터를 모바일 장치로 전송할 수 있다. 프록시 서버(325)(또는 트래픽 성형 엔진(375))가, 높은 우선순위를 갖거나 시간 중요성을 갖는 새롭거나 변경된 데이터를 전송할 수 있다.

마찬가지로, 애플리케이션이 모바일 장치에서 배경에 있는 경우, 프록시 서버(325)(또는 트래픽 성형 엔진(375))는 새롭거나 변경된 데이터의 전송을 억제할 수 있다. 프록시 서버(325)는 또한, 사용자가 새롭거나 변경된 데이터에 제공되는 응답을 기다리고 있지 않은 경우, 새롭거나 변경된 데이터의 전송을 억제할 수 있으며, 이러한 억제는 호스트 서버로 연결되며 모바일 장치로 무선으로 연결될 수 있는 프록시 서버에 의해 수행된다.

일반적으로, 새롭거나 변경된 데이터를 포함하여, 데이터가 낮은 우선순위를 갖거나, 시간 중요성을 갖는 경우, 시간 주기가 지날 때까지, 또는 (가령, 정렬 모듈(378) 및/또는 일괄처리 모듈(377)을 통해) 전송될 추가 데이터가 있을 때까지, 프록시 서버는 데이터를 전송하는 것을 기다릴 수 있다.

도 3E는, 무선 네트워크 또는 광대역 네트워크에서의 송신을 위해 구축된 연결을 최적화하기 위해, 추가로, 모바일 또는 광대역 장치, 또는 또 다른 수신자로의 데이터 전송을 정렬할 수 있는 도 3A의 예의 트래픽 성형 엔진(375)에서 추가 구성요소의 예를 도시하는 블록도를 도시한다.

프록시 서버(325)의 하나의 실시예에서, 트래픽 성형 엔진(375)은 통지 엔진(379)을 더 포함하고, 정렬 모듈(378)은 조절된 폴 추적기(378a)를 포함하고, 일괄처리 모듈(377)은 연결 트리거(connection trigger)(377a)를 더 포함한다.

하나의 실시예에서, 프록시 서버(325)는 스케줄에 따라 특정 모바일 장치 상의 다양한 애플리케이션을 서비스하는(가령, 제 1 서비스 및 제 2 서비스) 개별 호스트로 폴링할 수 있다. 로컬 프록시(가령, 도 2A-2E의 프록시(275))에 의해 폴링 스케줄이 설정되고, 모바일 장치(가령, 장치(250)) 상의 애플리케이션에 대해 할당된 폴링 간격을 포함할 수 있으며, 상기 폴링 간격은 조절됐을 수 있다. 가령, 프록시 서버(325) 내 트래픽 성형 엔진(375)의 정렬 모듈(378) 내 조절된 폴 추적기(378a)에 의해 폴링 스케줄은 추적될 수 있다. 하나의 서비스/하나의 애플리케이션의 조절된 폴링 간격이, 모바일 장치 상의 또 다른 서비스의 폴링 간격을 기초로 하여 결정되어, 예를 들어, 일괄처리 모듈(377)에 의해, 원격 프록시(325)에서 수신된 데이터가 모바일 장치로 일괄적으로 제공될 수 있다.

폴링 스케줄은 또한, 특정 모바일 장치 상의 복수의 애플리케이션을 대신하여 폴링을 시작하기 위한 초기 시작 시점(t0)을 포함할 수 있다. 제 1 및 제 2 서비스를 서비스하는 개별 호스트들의 제 1 폴의 초기 시작 시점(가령, 공동 시작 시점(mutual starting point))이, 예를 들어, 로컬 프록시(275)(가령, 도 2A-2E의 프록시(275))에 의해, 그리고 일부 경우, 프록시 서버(325)에 의해, 선택될 수 있다. 로컬 프록시에 의해 결정되면, 로컬 프록시가 폴링을 위한 공동 시작 시점을 프록시 서버(325)로 전달한다. 하나의 실시예에서, 공동 시작 시점은, 미래의 통신 지연을 보상하도록 설정된다.

하나의 실시예에서, 특정 모바일 클라이언트/모바일 애플리케이션이 활성 상태가 아닌 경우, 또는 특정 모바일 장치(250)가 무선 네트워크로 연결되지 않은 경우, 연결 트리거(377a)가 트리거(가령, 대역외 트리거)를 모바일 장치 또는 모바일 장치 상의 로컬 프록시로 전송하여, 라디오에 전력이 공급될 것을 요청, 및/또는 하나 이상의 관련 애플리케이션을 활성화하도록 요청할 수 있다. 예를 들어, 일괄처리 모듈(377)은 특정 모바일 장치 상의 복수의 애플리케이션으로 전송될 다양한 콘텐츠 도는 데이터를 일괄처리했을 수 있고, 모바일 클라이언트/애플리케이션이 활성 상태가 아닌 경우, 연결 트리거(377a)가 애플리케이션이 활성화될 것을 요청하는 트리거를 전송할 수 있다. 또는, 통지 엔진(379)이 모바일 장치(250)에게, 전송될 준비가 된 데이터가 있다는 지시자(indication)를 전송할 수 있으며, 이는 모바일 장치(250)에게 라디오가 현재 꺼짐 모드(off-mode)인 경우, 라디오를 켜도록 요청하는 것이다.

프록시 서버(325)는 복수의 모바일 장치를 모니터링하고, 복수의 장치, 사용자 및 네트워크에 걸쳐 애플리케이션 특성 및 사용자 거동/특성을 추적한다. 따라서 조절된 폴 간격 추적기와 관련된 상기의 특징은, 특정 장치 상의 복수의 애플리케이션과 관련된 예시를 제공했지만, 예를 들어, 상기 장치 상의 로컬 프록시(가령, 프록시 서버(325)에 의해 서비스되는 복수의 모바일 장치들 중 하나 이상에 설치될 수 있는 로컬 프록시(275)의 도 2E에 도시된 구성요소)에 의해 조절된 폴 간격 또는 폴링 스케줄이, 각각의 모바일 장치 상의 애플리케이션을 기초로 계산되는 다른 애플리케이션 세트를 갖는 복수의 장치에 대해서도 동일한 것이 추적된다.

프록시 서버(325)는, 하나의 네트워크에서, 네트워크들에 걸쳐, 하나의 지리적 영역에서, 복수의 지리적 영역에 걸쳐, 복수의 모바일 장치로의/로부터의 트래픽을 관리하기 때문에, 프록시 서버(325)는, 트래픽 조건 또는 네트워크 조건의 데이터의 개요 또는 집합체를 기초로 하여, 트래픽을 정렬하고, 데이터의 전송을 일괄처리할 수 있다. 프록시 서버(325)는, 가령, 네트워크 혼잡이 검출될 때 모바일 장치로의 데이터 전송을 우선순위화할 수 있다. 예를 들어, 프록시 서버(325)는 데이터를 모바일 장치로 전송할 수 있고, 여기서, 장치 사용자의 구독의 유형 또는 레벨, 즉, 모바일 장치로 전송될 콘텐츠의 가장 높은 우선순위를 기초로 티어형(tiered)인지 스태거형(staggered)인지 결정된다(가령, 모바일 장치 A에 대한 가장 높은 우선순위 데이터가 모바일 장치 B의 것보다 높은 우선순위인 경우, 데이터들의 일괄분(batch)이, 모바일 장치 B와 비교할 때 모바일 장치 A로 우선 전송될 수 있다).

가령, 지리적 영역에 대해, 또는 특정 네트워크 운영자에 대해, 또는 특정 유형의 웹 서비스에 대해, 또는 이들의 조합에 대해, 하나의 프록시 서버(325)가 존재할 수 있다. 여러 다른 서비스하는 개체를 기초로 하여, 프록시 서버(325)가 네트워크 트래픽, 운영자 설정, 애플리케이션 선호도/요건, 사용자 선호도, 구독-관련 파라미터, 또는 이들의 다양한 조합과 관련된 여러 다른 유형의 정보를 집합화할 수 있고, 수신하는 모바일 장치에 의해 확립될 필요가 있는 연결을 최적화할 때 프록시(325)에 의해 사용될 수 있다. 여려 다른 운영자에 대해 하나의 지리적 영역 내 여러 다른 네트워크를 서비스하는 복수의 프록시 서버(325)가 트래픽, 구독물, 사용자, 또는 애플리케이션 레벨 정보를 공유하여, 네트워크 자원 활용, 트래픽 관리를 더 촉진시킬 수 있으며, 일부 경우, 모바일 장치로의 데이터 전송의 정렬을 촉진시킬 수 있다.

도 4는 무선 네트워크에서 분산 프록시 시스템(460)에 의해, 모바일 장치(450)로부터 애플리케이션 서버/콘텐츠 제공자(495)로의 데이터 요청이, 부산 프록시 시스템(460)에 의해 수행되는 콘텐츠 캐싱 및 모니터링을 통해 네트워크 및 배터리 자원이 보존되는 방식으로 조율될 수 있는 법을 도시하는 다이어그램을 도시한다.

분산 프록시 시스템(460) 없이 모바일 장치(450) 상의 애플리케이션 또는 클라이언트 요청을 만족시킬 때, 모바일 장치(450) 또는 상기 장치(450) 상에서 실행되는 소프트웨어 위젯이 애플리케이션 서버(495)로의 데이터 요청(402)(가령, HTTP GET, POST, 또는 그 밖의 다른 요청)을 수행하고, 서버/제공자(495)로부터 직접 응답(404)을 수신한다. 데이터가 업데이트된 경우, 모바일 장치(450) 상의 위젯(455)은 리프레시되어, 업데이트를 반영하고, 짧은 시간 주기 동안 기다리며, 서버/제공자(495)로의 또 다른 데이터 요청을 개시할 수 있다.

하나의 실시예에서, 장치(450) 상의 요청하는 클라이언트 또는 소프트웨어 위젯(455)은 서버/제공자(495)로 이뤄지는 데이터 요청을 핸들링할 때, 분산 프록시 시스템(460)을 이용할 수 있다. 일반적으로 분산 프록시 시스템(460)은 로컬 프록시(465)(일반적으로 시스템(460)의 클라이언트 측 구성요소라고 간주되고 모바일 장치(450) 상에 위치할 수 있음), 캐싱 프록시(475)(시스템(460)의 서버 측 구성요소(470)라고 간주되고 호스트 서버(485) 상에 위치하거나 호스트 서버(485) 외부에 전체적으로 또는 부분적으로 위치함), 및 호스트 서버(485)를 포함할 수 있다. 로컬 프록시(465)는, 임의의 네트워크 또는 네트워크 조합을 통해, 캐싱 프록시(475) 및 호스트 서버(485)로 연결될 수 있다.

분산 프록시 시스템(460)이 데이터/애플리케이션 요청을 위해 사용될 때, 위젯(455)은 로컬 프록시(465)를 통해 데이터 요청(406)을 수행할 수 있다. 로컬 프록시(465)는, 장치 애플리케이션에 의해 이뤄지는 요청을 인터셉트하고, 요청의 연결 유형(가령, HTTP get 요청 또는 그 밖의 다른 유형의 요청)을 식별할 수 있다. 그 후, 로컬 프록시(465)가 (가령, 로컬 저장된 응답이 이용 가능한지, 및/또는 여전히 유효한지 여부를 결정하기 위해) 요청에 대한 임의의 이전 정보를 찾기 위해 로컬 캐시에게 질의할 수 있다. 로컬 저장된 응답이 이용 가능하지 않은 경우, 또는 유효하지 않은 응답이 저장되어 있는 경우, 로컬 프록시(465)가 요청에 대한 정보, 요청이 이뤄진 시점, 및 임의의 추가 데이터를 업데이트하거나 로컬 캐시에 저장할 수 있다. 뒤 이은 요청을 만족시키기 위해 사용되기 위해, 정보가 업데이트될 수 있다.

그 후, 로컬 프록시(465)는 호스트 서버(485)로 요청을 전송할 수 있고, 호스트 서버(485)는 요청을 수행하며, 결과를 응답(408)으로 반환한다. 로컬 프록시(465)는 결과와, 이에 추가로, 결과에 대한 정보를 저장할 수 있고, 결과를 요청하는 위젯(455)에게 반환할 수 있다.

하나의 실시예에서, 동일한 요청이 (특정 시간 주기 내에) 복수 번 발생하고, 종종 동일한 결과를 산출한 경우, 결과를 로컬 프록시(465) 또는 요청하는 ㅇ위젯(455)에게 반환하기 전에, 로컬 프록시(465)가 서버(485)에게, 결과 변경을 찾기 위해 요청이 모니터링되어야 한다고 통지할 수 있다(가령, 단계(412 및 414)). 하나의 실시예에서, 모니터링을 위해 요청이 표시된 경우, 로컬 프록시(465) 는 결과를 로컬 캐시로 저장할 수 있다. 이제, 로컬하게 위치한 응답이 이용 가능한 데이터 요청(416)이 위젯(455)에 의해 이뤄지고, 로컬 프록시(465)에서 인터셉트된 경우, 로컬 프록시(465)는, 무선 네트워크를 통한 연결 통신을 확립할 필요 없이, 응답(418)을 로컬 캐시로부터 반환할 수 있다.

덧붙이자면, 서버 프록시가 모니터링(420)이라고 표시된 요청을 수행하여, 특정 요청에 대한 응답(422)이 변경됐는지 여부를 판단할 수 있다. 일반적으로, 호스트 서버(485)는 이러한 모니터링을, 위젯(455) 또는 로컬 프록시(465)의 동작에 독립적으로, 수행할 수 있다. 요청에 대해 기대되지 않은 응답(422)이 수신될 때마다, 서버(485)가 로컬 프록시(465)에게 응답이 변경됐다고 통지(가령, 단계(424)의 무효화 통지)하고, 클라이언트 측에 로컬 저장된 응답이 삭제되거나 새로운 응답으로 대체되어야 한다고 통지할 수 있다.

이러한 경우, 장치(450)에서의 위젯(455)에 의한 뒤 이은 데이터 요청(426)이 데이터가 (가령, 캐싱 프록시(475)를 통해) 호스트 서버(485)로부터 반환되는 결과를 도출하며, 단계(428)에서 캐싱 프록시(475)로부터의 요청이 만족된다. 따라서 분산 프록시 시스템(460)을 이용함으로써, 위젯 또는 모바일 장치(450) 상의 소프트웨어 애플리케이션(455)에 대한 콘텐츠/데이터가 실제로 변경됐을 때 무선(셀룰러) 네트워크가 지능적으로 사용된다. 따라서, 애플리케이션 데이터의 변경을 찾기 위해 체크될 필요가 있는 트래픽은 무선(셀룰러) 네트워크를 통해 수행되지 않는다. 이는 생성되는 네트워크 트래픽의 양을 감소시키고, 모바일 장치(450) 상에서 라디오 모듈이 켜지는 총 시간 및 총 횟수를 감소시킴으로써, 배터리 소모량을 낮추고, 이에 추가로, 네트워크 대역폭을 비울 수 있다.

도 5는 분산 프록시 및 캐시 시스템(가령, 도 1B의 예시의 경우 분산 시스템)을 이용해 모바일 장치(550) 상에서 IP와 SMS의 하이브리드형 전력 절약 모드를 구현하기 위한 한가지 예시적 프로세스를 나타내는 다이어그램을 도시한다.

단계(502)에서, 로컬 프록시(가령, 도 1B의 예시의 프록시(175))가 사용자 활동에 대해 장치를 모니터링한다. 사용자가 활성 상태라고 판단될 때, 서버 푸시(server push)가 활성 상태이다. 이러한 방식으로, 상시 푸시(always-on-push) IP 연결이 유지될 수 있고, 이용 가능한 경우, SMS 트리거는 이용 가능해질 때 즉시 모바일 장치(550)로 전송될 수 있다.

프로세스(504)에서, 사용자가 일정 시간 주기 동안 비활성 상태 또는 유휴 상태라고 검출된 후(가령, 20분의 비활성 상태의 시간 주기에 대한 예시가 도시되어 있다), 로컬 프록시는 장치가 전력 절약 모드로 돌입하도록 조절할 수 있다. 전력 절약 모드에서, 로컬 프록시가 분산 프록시 및 캐시 시스템의 서버 측 상의 원격 프록시(가령, 도 1B의 예시의 경우, 서버 프록시(135))로부터 메시지 또는 통신물을 수신할 때, 로컬 프록시는 장치(550)가 현재 전력 절약 모드임을 지시하는 콜(가령, 전력 절약 원격 프로시저 호출)로 응답할 수 있다. 일부 경우, 로컬 프록시는 현재 전력 절약 상태에 대해 복수의 계정 또는 제공자(가령, 510A 및 510B)에게 통지하는 기회를 가질 수 있다(가령, 동일한 라디오 전원 켜기 이벤트를 이용하도록 타이밍이 정해짐).

하나의 실시예에서, 로컬 프록시로부터의 응답은, 원격 프록시(가령, 서버 프록시(135)) 및/또는 애플리케이션 서버/제공자(510A/B)에게, 다음번에 언제 장치(550)가 변경 또는 추가된 데이터를 수신할 수 있는지를 나타내는 시간(가령, 전력 절약 주기)을 포함할 수 있다. 로컬 프록시에 의해 디폴트 전력 절약 주기가 설정될 수 있다.

하나의 실시예에서, 임의의 하나의 전력 절약 주기가 끝나기 전에, 새로운, 또는 변경되거나, 상이한 데이터 또는 이벤트가 수신되는 경우, 서버(510A/B)로 전달되는 대기 주기는, 증분된 시간 주기가 아니라, 현재 존재하는 주기일 수 있다. 응답에서, 원격 프록시 서버가 전력 절약 통지를 장치(550)로부터 수신하면, 요청된 시간 주기 동안 변경사항(데이터 또는 SMS)을 전송하는 것을 중단할 수 있다. 대기 주기의 끝 부분에서, 수신된 임의의 통지가, 예를 들어, 장치(550)로, 하나의 일괄 처리되는 이벤트 또는 개별 이벤트들로서 전송되는 변경사항에 따라 처리될 수 있다. 어떠한 통지도 유입되지 않는 경우, 장치(550)로 전송되는 데이터 또는 SMS를 포함하는 푸시가 재개될 수 있다. 프록시 서버는 폴 또는 데이터 수집 이벤트의 타이밍을 정할 수 있다. 모바일 장치(550)로의 콘텐츠의 일괄 전송을 최적화하여, 다음번 라디오 전력 켜기 이벤트에서 클라이언트가 데이터를 수신할 기회를 증가시킬 수 있다.

동작 상태에 적응하기 위해 동작 중에 실시간으로 대기 주기(wait period)가 업데이트될 수 있다. 예를 들어, 시스템에서 발생하는 여러 다른 지연에 적응하기 위해, 로컬 프록시는 상기 대기 주기를 그때 그때 조절할 수 있다.

장치(550)에서 사용자 활동이 검출되면(단계(508)), 전력 절약 모드가 종료될 수 있다. 장치(550)가 전력 절약 모드에서 빠져 나올 때, 장치는 임의의 계류중인 통지와 연계된 임의의 변경사항을 수신하기 시작할 수 있다. 전력 절약 주기가 만료되면, 프록시 서버가 이미 전통적인 푸시 동작 모드일 때 어떠한 전력 절약 취소 호출도 필요하지 않을 수 있다.

하나의 실시예에서, 장치(550)가 충전기(charger)로 플러깅될 때 전력 절약 모드가 적용되지 않는다. 이러한 설정은 사용자나 또 다른 측(party)에 의해 재구성되거나 조절될 수 있다. 일반적으로 장치(550) 상의 사용자 인터페이스를 통해 사용자에 의해 전력 절약 모드가 켜지거나 꺼질 수 있다. 일반적으로 데이터를 수신하기 위한 전력 이벤트의 타이밍이 임의의 전력 절약 호출과 동기화되어, 라디오 사용을 최적화할 수 있다.

도 6은 모바일 장치와 프록시 서버 간의 분산 콘텐츠 캐싱과 콘텐츠 캐싱의 분산된 관리를 위한 예시적 프로세스를 도시하는 또 다른 흐름도를 도시한다.

도 4의 예시의 분산 시스템 상호대화도에서 도시되는 것처럼, 본 발명의 기법은 클라이언트 측/모바일 장치 측(가령, 도 4의 예시의 경우, 모바일 장치(450))(가령, 도 4의 예시의 경우, 모바일 장치(450))과 서버 측(가령, 호스트 서버(485) 및/또는 선택적 캐싱 프록시(475)를 포함하는 서버 측(470)) 간에 분할된 작업들을 캐싱하는 다양한 양태를 갖는 분산 캐싱 모델이다.

일반적으로, 장치 측 책무는 특정 요청에 대한 응답이 캐싱될 수 있는지(및/또는 캐싱되어야 하는지) 여부를 결정하는 것을 포함할 수 있다. 프록시의 장치 측은 요청과 응답 둘 모두로부터/요청과 응답 동안에 수집되는 정보(가령, 타이밍 특성, 검출된 패턴, 휴리스틱을 이용해 검출된 패턴, 예측가능성 또는 반복성의 지시자)를 기초로, 이러한 결정을 할 수 있으며, 이를 캐싱할 수 있다(가령, 모바일 장치 상의 로컬 캐시에 저장함). 또한 장치 측은 분산 캐시 시스템의 서버 측에게 이러한 로컬 캐시 이벤트를 통지할 수 있으며, 콘텐츠 소스의 모니터링(가령, 도 1A-1B의 애플리케이션 서버/콘텐츠 제공자(110))을 통지할 수 있다.

장치 측은 (가령, 폴링에 의해, 또는 콘텐츠 소스로 폴링 요청을 전송함으로써) 분산 프록시의 서버 측에게 캐시 응답을 주기적으로 검증(validate)하도록 명령할 수 있다. 장치 측은, 특정 캐시 요청에 대한 응답이 로컬 캐시로부터 반환되어야 하는지 여부(가령, 캐시 히트(cache hit)가 검출되는지 여부)를 추가로 결정할 수 있다. 요청 및/또는 콘텐츠 소스로부터 수신된 응답으로부터(또는 요청 및/또는 응답 중에) 수집된 정보를 이용해, 장치 측(가령, 장치 상의 로컬 프록시)에 의해 결정이 이뤄질 수 있다.

일반적으로, 서버 측 책무는 관련성에 대하여 캐싱된 응답을 검증하는 것(가령, 캐싱된 응답이 여전히 유효한지 또는 이와 연계된 요청과 관련성이 있는지 여부를 판단하는 것)을 포함할 수 있다. 서버 측은 모바일 장치에게, 장치 측에게 캐싱된 응답이 더 이상 유효하지 않거나, 더 이상 관련성이 없을 때 통지하기 위해 무효화 요청을 전송할 수 있다(가령, 서버가 특정 콘텐츠 소스를 무효화한다). 그 후 장치 측이 로컬 캐시로부터 응답을 제거할 수 있다.

도 6의 다이어그램은, 모바일 장치(가령, 분산 프록시의 클라이언트 측)에서 검출된 각각의 검출되거나 인터셉트된 요청(가령, HTTP 요청)에 대해 수행되는 캐싱 로직 프로세스를 도시한다. 단계(602)에서, 프록시(가령, 도 2A-B에서 도시된 로컬 프록시(275), 또는 도 4의 모바일 장치(450))의 클라이언트 측이 (애플리케이션(가령, 모바일 애플리케이션) 또는 모바일 클라이언트로부터) 요청을 수신한다. 단계(604)에서, URL이 정규화되고, 단계(606)에서 클라이언트 측은 요청이 캐싱 가능한지 여부를 결정하도록 체크한다. 단계(612)에서 요청이 캐싱 가능한 것이 아니라고 결정된 경우, 클라이언트 측 프록시에 의해 인터셉트되는 것 없이 요청-응답 시퀀스와 유사하게, 단계(608)에서 요청이 소스(애플리케이션 서버/콘텐츠 제공자)로 전송되고, 단계(610)에서 응답이 수신되며, 단계(622)에서 요청하는 애플리케이션으로 전달된다.

요청이 캐싱 가능하다고 결정된 경우, 단계(612)에서 클라이언트 측은 캐시를 조사(look up)하여, 현재 요청에 대해 캐시 엔트리가 존재하는지 여부를 판단할 수 있다. 현재 요청에 대해 캐시 엔트리가 존재한다고 판단한 경우, 단계(624)에서 클라이언트 측은 엔트리가 유효한지 여부를 판단할 수 있고, 엔트리가 유효하다고 판단한 경우, 단계(628)에서 클라이언트 측은 요청을 체크하여, 검사자(가령, 수정된 헤더 또는 개체 태그)를 포함하는지 여부를 판단할 수 있다. 예를 들어, 가능한 유형의 헤더(가령, eTAG, Modified_Since, must_revlaidate, pragma no_cache)를 기술하는 RFC 2616의 섹션 13.3에서 검증의 개념이 빠져 있으며, 그럴 경우, 단계(622)에서 요청하는 애플리케이션으로 전달될 검증하는 응답을 형성한다(632). 단계(628)에서 판단될 때 요청이 검사자를 포함하지 않는 경우, 단계(630)에서 응답이 로컬 캐시로부터 형성되고, 단계(622)에서 요청하는 애플리케이션으로 전달된다. 이러한 검증 단계는 일반적으로 다른 경우라면 캐싱될 수 없음(un-cacheable)이라고 간주될 콘텐츠에 대해 사용될 수 있다.

대신, 단계(624)에서, 캐시 엔트리가 발견되지만, 더 이상이 유효하지 않다고 또는 무효하다고 판단되는 경우, 프록시의 클라이언트 측이 요청을 콘텐츠 소스(애플리케이션 서버/콘텐츠 호스트)로 전송하고(616), 소스로부터 직접 응답을 수신한다(618). 마찬가지로, 단계(612)에서 조사(look up) 동안 캐시 엔트리가 발견되지 않은 경우, 단계(616)에서 요청이 또한 전송된다. 응답이 수신되면, 단계(626)에서, 클라이언트 측이 응답을 체크하여, 캐싱 가능한지 여부를 판단할 수 있다. 캐싱 가능한 경우, 단계(620)에서 응답이 캐싱된다. 그 후, 단계(614)에서 클라이언트가 또 다른 폴을 전송하며, 단계(622)에서 응답을 요청하는 애플리케이션으로 전달한다.

도 7은, 전달되는 콘텐츠의 신선도를 보장하면서, 장기 유지 요청을 통해, 애플리케이션(가령, 모바일 애플리케이션)(755)으로 전달되는 콘텐츠의 분산 프록시 시스템(760)에 의한 캐시 관리를 나타내는 상호대화도를 도시한다.

다이어그램은 장기 유지 요청(가령, 장기 유지 HTTP 요청, 롱 폴, 또는 HTTP 스트리밍)의 경우 수신된 캐싱된 응답이 요청하는 애플리케이션(755)으로 전달되는 방식과, 만료된/무효인/관련성 없는 캐시 엔트리를 관리하는 방식에 대한 예시적 프로세스를 도시한다. 장기 유지 요청은, 장치로 전송(또는 푸시)될 응답이 서버에서 이용가능할 때까지 장치와 서버 사이에 유지되는 지속형 연결에 대한 임의의 요청일 수 있다. 장기 유지 요청 또는 장기 유지 HTTP 요청에 의해, 장치/서버 상호대화가, 지속형 연결(예를 들어, HTTP를 통한 지속형 연결)을 통한 콘텐츠 푸시(가령, COMET 스타일 푸시)를 시뮬레이트할 수 있다.

단계(702)에서 애플리케이션(755)은 요청을 전송하고, 상기 요청은, 프록시 시스템(760)의 클라이언트/장치 측 상의 모바일 장치(750) 상의 로컬 프록시(765)에 의해 검출 및 인터셉트된다. 때때로 롱 폴 요청을 전송하는 애플리케이션(가령, 모바일 애플리케이션)에 의해 수행될 수 있는 롱 폴 헌팅 주기 후에, 요청-응답 시퀀스(702, 704, 706, 및 708)가 발생한다. 롱 폴 헌팅 주기는 수행되거나 수행되지 않을 수 있지만, 수행될 때, 롱 폴 헌팅 주기의 수행에 의해, (가령, 네트워크 이유, 가령 소켓 폐쇄로 인해) 연결이 만료되기 전에, 요청하는 애플리케이션(755)이 말단 서버/제공자(795)에 의해 요청을 유지할 수 있는 가장 긴 시간을 찾을 수 있다.

특성 요청-응답 타이밍 시퀀스를 나타내는 타이밍도가 도 8의 예에서 추가로 도시된다. 일반적으로 장치 프록시(750) 또는 로컬 프록시(765)는, 롱 폴 헌팅 동안, 애플리케이션(755)으로부터 개시되는 요청-응답 패턴 시퀀스를 검출할 수 있고, 롱 폴 요청으로부터의 응답을 캐싱하는 것은 헌팅 주기가 정착되기 전까지 기다릴 수 있다. 도시된 요청-응답 단계(702 내지 710)는, 임의의 롱 폴 헌팅 요청/응답 쌍(요청하는 애플리케이션(755)에 의해 수행된 경우) 후에 발생한다.

단계(704)에서 요청이 서버/제공자(795)로 전송되고, 단계(708)에서 서버(795)가 응답을 다시 장치 측(750) 상의 애플리케이션(755)으로 전송할 때, 단계(706)에서 요청이 만료되거나 폐쇄된다. 단계(702)에서 전송된 장기 유지 요청의 속성으로 인해, 단계(708)에서 서버(795)가 응답을 전송할 때 연결이 만료된다. 응답은 전송될 때, 분산 프록시(760)의 모바일 측(750) 상의 로컬 프록시(765)에 의해, 로컬 캐싱되기 위해, 인터셉트된다.

캐싱되면, 로컬 프록시(765)는 시스템(760)의 프록시의 서버 측(770)에게 통지하고, 서버 측(770) 프록시(가령, 호스트 서버(785))가 서버/제공자(795)를 모니터링하기 시작하도록 요청한다(단계(712)). 단계(714)에서, 이제, 서버/제공자(796)로부터 수신된 응답(716)을 모니터링하기 위해, 서버 측 프록시(770)가 서버/제공자에게 요청을 전송하기 시작한다.

그 후, 애플리케이션(755)이 요청(718)을 전송하며, 로컬 프록시(765)가 로컬 캐시 엔트리가 현재 존재한다고 판단하며, 단계(722)에서 캐싱된 응답을 애플리케이션(755)으로 다시 제공하기 전에, 일정 시간(가령, 롱 폴 간격) 동안 기다린다(720). 로컬 프록시(765)는, 애플리케이션(755)에 의한 서버/제공자(795)의 실제 거동을 시뮬레이트하기 위해, 시간 주기가 경과되게 할 수 있다. 네트워크를 통해 전달되는 실제 롱 폴 요청에서, 특정 롱 폴의 특성인 임의의 지연시간 후에야 응답이 수신된다.

단계(724)에서 시작하여, 단계(726)에서 서버/제공자(795)로부터의 응답이 검증될 때 또 다른 요청이 애플리케이션(가령, 모바일 애플리케이션)(755)으로부터 전송된다. 단계(744)에서 캐시 엔트리로 응답하기 전에, 단계(728)에서 로컬 프록시(765)는 일정 간격 동안 기다린다. 그러나 그 사이에, 단계(730)에서 응답을 모니터링하는 서버 측 프록시(770)가 서버/제공자(795)에게 요청을 전송하고, 단계(734)에서 서버/제공자(795)로부터 수신된 응답(732)에서 콘텐츠 변경사항을 검출한다. 따라서 서버 측(770) 프록시는 단계(736)에서 서버 측 프록시에 변경/업데이트된 응답 데이터를 캐싱하고, 연계된 캐시 엔트리(738)를 무효화하는 것을 로컬 프록시(765)에게 통지한다.

로컬 프록시(765)는, 무효화 통지를 수신하는 것에 응답하여, 단계(740)에서, 연계된 엔트리를 '과도 상태(transient)'로서 무효화되도록 설정하거나, 그 밖의 다른 방식으로 삭제나 제거로 표시되도록 주석이 달리거나 나타내어질 수 있다. 이때, 단계(744)에서 로컬 프록시(765)가 과도 캐시(transient cache)를 이용해 애플리케이션(755)에 다시 응답한다. 또한 로컬 프록시(765)는 서버 측 프록시(770)로 연결되어, 단계(742)에서 서버 측(770)에서 새로운 캐싱된 데이터를 획득하고, 단계(746)에서 응답(새로운/업데이트된 응답)을 수신할 수 있다.

그 후, 단계(748)에서 애플리케이션(가령, 모바일 애플리케이션)으로부터 동일한 요청이 전송되며, 단계(750)에서 로컬 프록시(765)는 서버 캐시로부터 수신된 응답으로 대답할 수 있다. 따라서 캐시 엔트리가 무효화됐을 경우에서도, 현재/관련성 있는 응답을 수신하기 위해, 애플리케이션(가령, 모바일 애플리케이션) 요청이 네트워크(가령, 무선 또는 셀룰러 네트워크)를 통해 전송될 필요가 없다. 단계(754)에서 다음번 요청(752)이 프로세싱되기 위해 로컬 프록시(765)로 전송(가령, 애플리케이션 서버/콘텐츠 제공자(795)로 포워딩)된다.

도 8은 롱 폴 요청에서 헌팅 모드 거동(805)을 보여주는 타이밍도와, 롱 폴이 정착됐을 때(810) 타이밍 특성을 보여주는 타이밍도를 도시한다.

헌팅 모드(805)에서, (802, 804, 806, 및 808로 도시되는 것처럼) 서버로부터 응답을 수신하지 않고 요청이 만료될 때까지, 증가하는 시간(180, 360, ..., 1024초) 동안 요청 시간이 유지된다. 이러한 시간이 검출된 후, 요청 시간은, 만료 시 걸리는 시간(가령, 여기서는, 500초)보다 짧은 임의의 시간으로 유지되며, 미래의 롱 폴 요청을 전송하도록 사용된다. 다이어그램(810)은, 롱 폴 헌팅 주기가 정착된 후, 요청/응답 쌍의 타이밍 특성을 도시한다. 로컬 프록시 및/또는 원격 프록시에 의해 동작될 때, 이들 특성이 검출되고 식별되어서, 캐싱 동안 핸들링될 수 있다. 상기에서 기재된 바와 같이, 분산 캐싱 시스템은, 애플리케이션이 여전히 롱 폴 헌팅 모드인 동안 (선택사항으로서) 캐싱을 시작하거나, 헌팅 주기(805)가 완료되고, (810)에서처럼 애플리케이션이 정착된 모드(settled mode)로 있을 경우, 캐싱을 시작할 수 있다. 일반적으로 시간 간격의 감소가 검출되는 경우, 일반적으로 시간 간격의 감소가 검출될 때, 로컬 또는 원격 프록시가 다음번 수신되는 응답이 캐싱 가능함 조건을 충족함을 검증할 수 있고 나서야, 응답이 캐싱된다.

일반적으로, 롱 폴 헌팅은 모바일 앱(app) 또는 클라이언트에 의해 수행되거나 수행되지 않을 수 있지만, 분산 시스템은 애플리케이션 롱 폴을 위한 롱 폴 헌팅 활동을 검출하기 위한 메커니즘을 포함하고, 롱 폴 헌팅 요청을 단순히 무시할 수 있으며, 헌팅 주기가 경과되고, 롱 폴이 임의의 일정한(또는 거의 일정한) 간격 값으로 정착된 후 캐싱을 시작하거나, 헌팅 주기 동안 캐싱을 시작하기 위한 로직을 적용함으로써, 성능을 향상시키고 사용자 경험을 개선하는 가속화된 캐싱을 가능하게 할 수 있다.

프로세스(802)에서, 호스트 서버로부터 수신된 콘텐츠를 캐싱하기 시작하도록 결정이 내려진다. 결정은 도 9의 예시에서 나타난 예시적 프로세스를 통해 이뤄질 수 있으며, 도 9는 단계(802)에서 호스트 서버로 이뤄지는 폴링 요청의 빈도를 판단함으로써, 및/또는 단계(804)에서 호스트 서버에서의 콘텐츠 변경의 빈도를 판단함으로써, 특정 호스트 서버(콘텐츠 소스)로부터의 콘텐츠를 캐싱하는지 여부를 판단하기 위한 예시적 프로세스를 도시하는 흐름도를 도시한다. 단계(806)에서, 호스트 서버로부터의 콘텐츠가 캐싱될지 여부를 결정할 때, 두 단계들은 함께 사용되거나, 서로 독립적으로 사용될 수 있다.

프로세스(804)에서, 콘텐츠 서버로부터의 콘텐츠가 모바일 장치 상의 로컬 캐시에 캐싱된 요소로서 저장된다. 프로세스(806)에서, 콘텐츠 서버에 접속하기 위한 폴링 요청이 분산 캐싱 시스템에 의해 수신된다. 프로세스(808)에서, 모바일 장치의 라디오가 활성화되지 않는다고 판단되는 경우, 프로세스(810)에서, 로컬 캐시로부터 캐싱된 요소가 불러와 져서, 캐시 디피트 메커니즘(cache defeating mechanism)이 사용될 때에도 라디오를 활성화시키지 않고 폴링 요청에 응답할 수 있다.

주소지정하는 캐시를 디피트하기 위한 의도로 사용되는 캐시 디피트 메커니즘, 또는 식별자가 콘텐츠 서버(식별자를 이용해 폴링 요청이 전달되는 서버)에 의해 사용될 수 있다. 일반적으로, 캐시 디피트를 위해 의도된 캐시 디피트 메커니즘 또는 식별자가, 콘텐츠 서버를 식별하는 폴링 요청에 포함되는 자원 식별자의 구문 또는 패턴으로부터 검출될 수 있다.

예를 들어, 자원 식별자는 URI 또는 URL을 포함할 수 있고, 다음의 단계들 중 하나 이상을 수행함으로써, URI/URL은 정규화된다: URI 스킴 및 호스트를 소문자로 변환, 퍼센트-인코딩식 이스케이프 시퀀스 내 문자들을 대문자화, 디폴트 포트를 제거, 또는 중복 슬래시를 제거. 덧붙이자면, 캐시 디피트(cache defeat)를 이용하는 식별자를 위한 식별자 정규화 프로세스가, 캐시를 디피트하기 위해 의도된 식별자의 임의의 부분(가령, 일반적으로, 파라미터의 포맷, 패턴, 또는 구문에 의해 검출 가능한 요청들 간에 변하는 파라미터)을 제거한다.

캐시를 디피트하는 것으로 의도된 캐시 디피트 메커니즘 또는 식별자의 검출이 100% 확실함을 갖고 결정될 필요는 없다. 캐시 디피트를 이용하는 중이라고 판단될 수 있는 특정 문자를 갖는 식별자(가령, 특정 포맷과 매칭하는 파라미터를 갖는 식별자)가 단순히, 캐시 디피트를 하는 것으로 취급되거나, 무선 네트워크를 통한 콘텐츠를 캐싱할 목적으로 캐시를 디피트하도록 의도될 수 있는데, 예를 들어, 이들은 분산 방식으로 관리될 수 있다.

도 9는 무선 네트워크를 통해 모바일 장치로부터 애플리케이션 서버/콘텐츠 제공자(995)로의 데이터 요청을 갖는 애플리케이션(가령, 모바일 애플리케이션)(955) 폴이 로컬 프록시(965) 상에 캐싱될 수 있고, 분산 캐싱 시스템(로컬 프록시(965) 및 (서버 캐시(935) 또는 캐싱 프록시 서버(975)를 갖는) 호스트 서버(985)에 의해 관리될 수 있는 방법을 보여주는 상호대화도를 도시한다.

하나의 예에서, 모바일 애플리케이션/위젯(955)이 애플리케이션 서버/제공자(932)에게 폴링할 때, 폴이 로컬 프록시(965)에 의해 모바일 장치 상에서 로컬하게 인터셉트될 수 있다(934). 로컬 프록시(965)는, 요청에서 폴링된 콘텐츠에 대해 캐싱된 콘텐츠가 이용 가능하다고 검출할 수 있으며, 따라서 무선 네트워크 대역폭 또는 또 다른 무선 네트워크 자원을 사용할 필요 없이, 인터셉트된 폴(936)을 만족시키기 위해, 로컬 캐시로부터 응답을 불러올 수 있다. 그 후, 모바일 애플리케이션/위젯(955)은 캐시 엔트리(938)로부터의 폴에 대한 응답을 수신할 수 있다.

또 다른 예에서, 모바일 애플리케이션 위젯(955)이 애플리케이션 서버/제공자(940)로 폴링한다. 폴이 로컬 프록시(965)에 의해 인터셉트되고(942), 캐시 콘텐츠가 로컬 캐시에서 이용 가능하지 않음을 검출하며, 폴링받는 소스를 캐싱하도록 설정하기로 결정한다(944). 요청을 만족시키기 위해, 폴이 콘텐츠 소스로 포워딩된다(946). 애플리케이션 서버/제공자(995)가 애플리케이션으로부터 폴 요청을 수신하고, 현재 요청을 만족시키기 위한 응답을 제공한다(948). 단계(950)에서, 애플리케이션(가령, 모바일 애플리케이션)/위젯(955)은 애플리케이션 서버/제공자로부터 응답을 수신하여 요청을 만족시킬 수 있다.

이와 함께, 콘텐츠 캐싱을 설정하기 위해, 로컬 프록시(965)는 애플리케이션의 폴링 빈도를 추적하고, 호스트 서버로 전송될 폴링 스케줄을 설정할 수 있다(952). 로컬 프록시는 캐싱 설정을 호스트 서버로 전송한다(954). 호스트 서버(985)는, 예를 들어, 폴링될 애플리케이션 서버/제공자의 식별자와, 선택사항으로서, 폴링 스케줄을 포함하는 캐시 설정을 사용할 수 있다(956). 호스트 서버(985)는 애플리케이션 서버/제공자(995)로 폴링하여, 모바일 장치를 대신하여, 요청(958)에 대한 응답을 모니터링할 수 있다. 애플리케이션 서버는 호스트 서버로부터 폴을 수신하고, 응답한다(960). 호스트 서버(985)는 동일한 응답이 수신됐다고 판단하며, 특정 폴링 스케줄(962)에 따라, 애플리케이션 서버(995)로 폴링한다. 애플리케이션 서버/콘텐츠 제공자(995)는 폴을 수신하고 이에 따라 응답한다(964). 호스트 서버(985)는 변경되거나 새로운 응답을 검출하고, 로컬 프록시(965)로 통지한다. 호스트 서버(985)는 변경되거나 새로운 응답을 서버 캐시 또는 캐싱 프록시(968)에 추가로 저장할 수 있다. 로컬 프록시(965)는 호스트 서버(985)로부터, 새롭거나 변경된 데이터가 현재 이용 가능하다는 통지를 수신하고, 영향받은 캐시 엔트리를 무효화할 수 있다(970). 그 후, 애플리케이션(가령, 모바일 애플리케이션)/위젯(955)이 동일한 서버/콘텐츠 제공자에 대해 동일한 요청을 발생시키고(972), 로컬 프록시는 어떠한 유효한 캐시 엔트리도 이용 가능하지 않는다고 판단하며, 대신, 예를 들어 HTTP 연결을 통해 서버 캐시(974)로부터 응답을 불러온다. 호스트 서버(985)는 새로운 응답에 대한 요청을 수신하고, 로컬 프록시(965)로 응답을 다시 전송한다(976). 따라서 모바일 장치가 자신의 라디오를 이용하거나 모바일 네트워크 대역폭을 소비할 필요 없이, 서버 캐시 또는 캐싱 프록시(978)로부터의 요청이 만족됨으로써, 네트워크 자원을 보존할 수 있다.

또는, 단계(980)에서 애플리케이션(가령, 모바일 애플리케이션)이 동일한 요청을 생성할 때, 로컬 프록시(965)는, 어떠한 유효한 캐시 엔트리도 이용가능하지 않다고 판단하는 것에 응답하여, 단계(982)에서, 폴을 애플리케이션 서버/제공자에게 모바일 네트워크를 통해 포워딩한다. 단계(984)에서 애플리케이션 서버/제공자(995)는 모바일 네트워크를 통해 폴을 수신하고, 응답을 모바일 장치로 전송한다. 따라서 단계(986)에서 모바일 네트워크를 이용해 서버/제공자로부터 요청이 만족된다.

도 10은 애플리케이션(1055)이, 무선 네트워크를 통해 콘텐츠 식별자 내 캐시 디피트 메커니즘(가령, 캐싱을 디피트하도록 의도된 식별자)을 이용하고 무선 네트워크를 통해 검출되고 로컬하게 캐싱되는 애플리케이션 서버/콘텐츠 제공자(1095)로부터의 콘텐츠에 대해 폴링하는 방법을 도시한다.

하나의 예에서, 단계(1032)에서 애플리케이션(가령, 모바일 애플리케이션)/위젯(1055)이 애플리케이션 서버/제공자로 폴링할 때, 단계(1034)에서 로컬 프록시(1065)에 의해 모바일 장치 상에서 폴이 로컬하게 인터셉트될 수 있다. 단계(1034)에서, (임의의 확신도 및 휴리스틱을 이용해) 모바일 장치 상의 로컬 프록시(1065)는 또한, 서버 제공자에 의해, 캐시 디피트 수단이 이용되거나, 이용될 수 있다고 판단할 수 있다.

로컬 프록시(1065)는 요청에서 폴링된 콘텐츠에 대해 캐싱된 콘텐츠가 이용가능한다고 검출할 수 있고, 따라서 무선 네트워크 대역폭 또는 또 다른 무선 네트워크 자원을 사용할 필요 없이, 로컬 캐시로부터 응답을 불러와, 인터셉트된 폴(1036)을 만족시킬 수 있다. 단계(1038)에서 애플리케이션(가령, 모바일 애플리케이션)/위젯(1055)은 캐시 엔트리(가령, 모바일 장치 상에 로컬하게 저장된 캐시 엔트리)로부터의 폴에 대한 응답을 수신할 수 있다.

또 다른 예에서, 단계(1040)에서 애플리케이션(가령, 모바일 애플리케이션) 위젯(1055)은 애플리케이션 서버/제공자(1095)로 폴링한다. 단계(1042)에서, 로컬 프록시(1065)에 의해 폴이 인터셉트되며, 상기 로컬 프록시(1065)는 서버/제공자(1095)에 의해 캐시 디피트 메커니즘이 이용된다고 판단한다. 또한 로컬 프록시(1065)는 이러한 요청에 대해 캐싱된 콘텐츠가 로컬 캐시에서 이용 가능하지 않음을 검출하고, 단계(1044)에서 폴링 받는 콘텐츠 소스를 캐싱을 위해 설정하기로 결정한다. 그 후, 단계(1046)에서, 로컬 프록시(1065)는 요청의 식별자의 패턴(가령, 포맷 또는 구문)을 추출하고, 애플리케이션의 폴링 빈도를 추적하여, 호스트 서버(1085)의 폴링 스케줄을 설정할 수 있다.

단계(1048)에서, 요청을 만족시키기 위해, 폴 요청이 콘텐츠 제공자(1095)로 포워딩된다. 단계(1050)에서 애플리케이션 서버/제공자(1095)는 애플리케이션으로부터 폴 요청을 수신하고, 응답을 제공하여, 현재 요청을 만족시킬 수 있다. 단계(1052)에서, 애플리케이션(가령, 모바일 애플리케이션)/위젯(1055)은 애플리케이션 서버/제공자(1095)로부터의 응답을 수신함으로써, 요청을 만족시킬 수 있다.

이와 함께, 단계(1054)에서, 콘텐츠 캐싱을 설정하기 위해, 로컬 프록시(1065)가, 차후의 식별과 불러오기(retrieval)를 위해 수신된 응답과 연계하여 응답을 캐싱하고 정규화된 버전의 식별자(또는 정규화된 식별자의 해시 값(hash value))를 저장한다. 단계(1056)에서 로컬 프록시가 호스트 서버(1085)로 캐시 설정을 전송한다. 예를 들어, 캐시 설정은, 식별자 및/또는 정규화된 버전의 식별자를 포함한다. 일부 경우, 정규화된 식별자와 다른 수정된 식별자가 호스트 서버(1085)로 전송된다.

단계(1058)에서, 호스트 서버(1085)는, 예를 들어, 폴링 받을 애플리케이션 서버/제공자의 식별자와, 선택사항으로서, 폴링 스케줄을 포함하는 캐시 설정을 사용할 수 있다. 단계(1060)에서 호스트 서버(1085)는 모바일 장치를 대신하여 요청에 대한 응답을 모니터링하기 위해 애플리케이션 서버/제공자(1095)로 폴링할 수 있다. 단계(1062)에서 애플리케이션 서버(1095)는 호스트 서버(1085)로부터의 폴을 수신하고 응답한다. 단계(1064)에서 호스트 서버(1085)는 동일한 응답이 수신됐다고 판단하고, 예를 들어, 특정 폴링 스케줄에 따라, 그리고 정규화된 또는 수정된 식별자를 이용해 애플리케이션 서버(1095)로 폴링한다. 단계(1066)에서 애플리케이션 서버/콘텐츠 제공자(1095)는 폴을 수신하고, 이에 따라서 응답한다.

이때, 단계(1068)에서, 호스트 서버(1085)는 변경되거나 새로운 응답을 검출하고, 로컬 프록시(1065)를 통지한다. 단계(1070)에서 호스트 서버(1085)는 변경되거나 새로운 응답을 서버 캐시(1035) 또는 캐싱 프록시(1075)에 추가로 저장할 수 있다. 단계(1072)에서, 로컬 프록시(1065)는 호스트 서버(1085)로부터, 새롭거나 변경된 데이터가 현재 이용가능하다는 통지를 수신하고, 영향받은 캐시 엔트리를 무효화할 수 있다. 그 후, 단계(1074)에서, 애플리케이션(가령, 모바일 애플리케이션)/위젯이 동일한 서버/콘텐츠 제공자(1095)에 대해 동일한 요청을 생성하고, 로컬 프록시(1065)가 어떠한 유효한 캐시 엔트리도 이용가능하지 않다고 판단하며, 대신, 단계(1076)에서, 가령, HTTP 연결을 통해, 서버 캐시로부터 응답을 불러온다. 단계(1078)에서, 호스트 서버(1085)는 새로운 응답에 대해 요청을 수신하고, 응답을 로컬 프록시(1065)로 다시 전송한다. 따라서 단계(1080)에서 모바일 장치가 자신의 라디오를 사용하거나 모바일 네트워크 대역폭을 소모할 필요없이, 서버 캐시 또는 캐싱 프록시로부터 요청이 만족되고, 따라서 네트워크 자원이 보존된다.

또는, 애플리케이션(가령, 모바일 애플리케이션)(1055)이 동일한 요청을 생성할 때, 로컬 프록시(1065)는, 단계(1082)에서, 어떠한 유효한 캐시 엔트리도 이용 가능하지 않는다고 판단한 것에 응답하여, 단계(1082)에서 모바일 네트워크를 통해 폴을 애플리케이션 서버 제공자(1095)에게 포워딩한다. 단계(1086)에서 애플리케이션 서버/제공자(1095)는 폴을 수신하며, 모바일 네트워크를 통해 응답을 모바일 장치로 전송한다. 따라서 단계(1088)에서, 모바일 네트워크(1086)를 이용해 서버/제공자로부터 요청이 만족된다.

도 11은 캐싱 가능함을 식별하고 응답을 캐싱하기 위해, 요청 및 이와 연계된 응답에 대한 정보를 수집하기 위한 예시적 프로세스를 도시하는 흐름도를 도시한다.

프로세스(1102)에서, 요청에 대한 정보 및 상기 요청에 대해 수신된 응답에 대한 정보가 수집된다. 프로세스(1104 및 1106)에서, 모바일 장치에 대해 개시된 요청에 대한 정보와, 요청에 대해 수신된 응답에 대한 정보는 집합적으로 사용되거나, 서로 독립적으로 사용되어, 단계(1108)에서 캐싱 가능함을 판단할 수 있다. 캐싱 가능함을 평가하기 위해, 요청 및 응답 정보를 사용하는 단계들의 세부사항이 흐름 A에서 도시되고, 이는 도 12의 예에서 추가로 설명된다.

단계(1108)에서, 흐름 A를 기초로 하여, 응답이 캐싱 가능하지 않다고 판단되는 경우, 단계(1110)에 응답이 캐싱되지 않고, 단계(1102)에서 선택사항으로서, 흐름이 재시작되어, 요청 또는 응답에 대한 정보를 수집하여, 캐싱 가능함을 다시 산정할 수 있다.

단계(1108)에서, 흐름 A로부터, 응답이 캐싱 가능하다고 판단되는 경우, 단계(1112)에서 응답이, 응답의 캐싱과 관련된 추가 정보를 갖는 메타데이터를 포함하는 캐시 엔트리로서, 캐시에 저장될 수 있다. 캐싱된 엔트리는, 응답에 추가로, 응답의 캐싱과 관련된 추가 정보를 갖는 메타데이터를 포함한다. 상기 메타데이터는 타이밍 데이터, 가령, 캐시 엔트리의 액세스 시간 또는 캐시 엔트리의 생성 시점을 포함할 수 있다.

응답이 캐시에 저장된 후, 프로세스(1120)에서 캐시에 저장된 응답이 업데이트될 필요가 있는지 여부를 판단하기 위해 병렬 프로세스가 발생할 수 있다. 업데이트될 필요가 있다고 판단된 경우, 프로세스(1122)에서, 모바일 장치의 캐시에 저장된 응답이 무효화되거나 모바일 장치의 캐시에서 제거된다. 예를 들어, 모바일 장치를 대신하여 요청이 전달되는 호스트 서버로 폴링함으로써, 응답의 관련성 또는 유효성이 주기적으로 검증될 수 있다. 응답이 캐싱되는 요청에 대해 수집된 요청 정보를 이용해 모바일 장치에서 결정된 속도(rate)로 호스트 서버에 폴링될 수 있다. 상기 속도는 요청을 발생시켰던 동일한 클라이언트에 의해 발생되는 이전 요청들 사이의 시간 간격들의 평균으로부터 결정된다.

검증은, 모바일 장치와 물리적으로 이격된 개체에 의해 수행될 수 있다. 하나의 실시예에서, 개체는 모바일 장치로 연결되어 있고 모바일 장치와 무선으로 통신할 수 있는 프록시 서버이며, 상기 프록시 서버는, 요청을 발생시켰던 동일한 클라이언트에 의해 발생되는 이전 요청들 사이의 타이밍 간격을 기초로 하여 모바일 장치에서 결정된 속도(rate)로 요청이 전달되는 호스트 서버로 폴링한다.

프로세스(1114)에서, 동일한 클라이언트 또는 애플리케이션에 대한 다음번 요청이 검출된다. 프로세스(1116)에서 다음번 요청에 응답하여 사용될 캐시 엔트리를 식별하기 위해 로컬 캐시 내 캐시 룩-업이 수행된다. 하나의 실시예에서, 캐시 엔트리로서 저장된 응답이 다음번 응답을 만족시키도록 사용되는지 여부를 결정하기 위해 메타데이터가 사용된다. 프로세스(1118)에서, 다음번 요청을 만족시키기 위해 캐시로부터 응답이 서비스될 수 있다. 상기 응답은, 메타데이터를 이용해 적어도 부분적으로 결정된 다음번 요청에 대해 매칭하는 캐시 엔트리를 식별하는 것에 응답하여 서비스될 수 있다.

도 12는 요청에 대한 응답이 캐싱될 수 있는지 여부를 결정하기 위한 예시적 프로세스를 나타내는 흐름도를 도시한다.

프로세스(1202)는 요청이 블랙리스트 도착지(blacklisted destination)로 향하는지 여부를 판단한다. 요청이 블랙리스트 도착지로 향하는 경우, 단계(1285)에서 응답은 캐싱되지 않는다. 블랙리스트 도착지가 검출된 경우, 또는 요청 자체가 블랙리스트 애플리케이션과 연계된 경우, 도면에 나타난 분석의 나머지 부분이 수행되지 않을 수 있다. 요청 및 그 도착지가 블랙리스트에 올라가지 않은 경우, 프로세스는 단계(1204 및 1206)로 진행될 수 있다.

프로세스(1204)에서, 요청과 연계된 요청 특성 정보가 분석된다. 요청을 분석함에 있어서, 프로세스(1208)에서 요청 방법이 식별되고, 단계(1214)에서, 요청 방법을 기초로 하여, 응답이 캐싱될 수 있는지 여부가 결정된다. 캐싱될 수 없는 요청이 검출되는 경우, 요청이 캐싱되지 않고, 프로세스가 프로세스(1285)에서 종료될 수 있다. 요청 방법이 캐싱 가능하다고 결정되거나, 캐싱 불가능하다고 결정되지 않는다면, 단계(1295)에서 응답은 캐싱 가능함, 또는 캐싱 가능할 가능성이 있음(가령, 캐싱 가능하지만 도면에 나타난 또 다른 테스트 및 분석의 대상이 됨)이라고 식별될 수 있다.

프로세스(1210)에서, 요청의 크기가 결정된다. 프로세스(1216)에서, 요청 크기가 캐싱 가능한 크기를 초과하는지 여부가 결정된다. 요청 크기가 캐싱 가능한 크기를 초과하는 경우, 프로세스(1285)에서 응답이 캐싱되고 분석이 종료될 수 있다. 단계(1216)에서 요청 크기가 캐싱 가능한 크기를 초과하지 않은 경우, 단계(1295)에서 응답이 캐싱 가능함 또는 캐싱 가능할 가능성이 있음(가령, 캐싱 가능하긴 하지만, 도면에서 나타난 또 다른 테스트 및 분석의 대상이 됨)이라고 식별될 수 있다.

단계(1212)에서, 상기 요청과, 동일한 클라이언트에 의해 생성되는 또 다른 요청 간의 주기성 정보가 판단된다. 단계(1218)에서, 주기성이 식별됐는지 여부가 결정된다. 주기성이 식별되지 않은 경우, 응답이 캐싱되지 않고, 프로세스(1285)에서 분석이 종료될 수 있다. 주기성이 식별되는 경우, 단계(1295)에서 응답은 캐싱 가능함 또는 캐싱 가능할 가능성이 있음(가령, 캐싱 가능하긴 하지만, 도면에서 나타난 또 다른 테스트 및 분석의 대상이 됨)이라고 식별될 수 있다.

프로세스(1206)에서, 요청에 대해 수신되는 응답과 연계된 요청 특성 정보가 분석된다.

프로세스(1220)에서, 상태 코드(status code)가 식별되고, 프로세스(1228)에서 상태 코드가 캐싱 가능한 응답 상태 코드를 가리키는지 여부가 결정된다. 캐싱 불가능한 상태 코드가 검출되는 경우, 요청이 캐싱되지 않고, 프로세스(1285)에서 프로세스가 종료될 수 있다. 응답 상태 코드가 캐싱 가능함을 가리키거나, 캐싱 불가능함을 가리키지 않는다면, 단계(1295)에서 응답이 캐싱 가능함 또는 캐싱 가능할 가능성이 있음(가령, 캐싱 가능하지만, 도면에 나타난 또 다른 테스트 및 분석의 대상이 됨)이라고 식별될 수 있다.

프로세스(1222)에서, 응답의 크기가 판단된다. 프로세스(1230)에서 응답 크기가 캐싱 가능한 크기를 초과하는지 여부가 판단된다. 응답 크기가 캐싱 가능한 크기를 초과하는 경우, 응답은 캐싱되지 않고, 여기, 단계(1230)에서 분석이 종료될 수 있다. 단계(1230)에서 응답 크기가 캐싱 가능한 크기를 초과하지 않는 경우, 단계(1295)에서, 응답이 캐싱 가능함 또는 캐싱 가능할 가능성이 있음(가령, 캐싱 가능하지만 도면에 도시된 또 다른 테스트 및 분석의 대상이 됨)이라고 식별될 수 있다.

프로세스(1224)에서, 응답 본체가 분석된다. 프로세스(1232)에서, 응답이 동적 콘텐츠(dynamic content) 또는 고도 동적 콘텐츠(highly dynamic content)를 포함하는지 여부가 판단된다. 동적 콘텐츠는, 자주 변경되거나, 및/또는 데이터의 내재적 속성으로 인해 수명이 짧거나 관련성 있는 시간이 짧은 데이터(가령, 주식 시세, 빠른 속도의 스포츠 이벤트의 스포츠 점수, 등)를 포함한다. 응답이 동적 콘텐츠 또는 고도 동적 콘텐츠를 포함하는 경우, 응답은 캐싱되지 않고, 여기서, 프로세스(1285)에서 분석이 종료될 수 있다. 응답이 동적 콘텐츠 또는 고도 동적 콘텐츠를 포함하지 않는 경우, 응답은 단계(1295)에서 캐싱 가능함 또는 캐싱 가능할 가능성이 있음(가령, 캐싱 가능하지만 도면에서 나타난 또 다른 테스트 및 분석의 대상이 됨)이라고 식별될 수 있다.

프로세스(1226)에서, 전송 인코딩(transfer encoding) 또는 청크 전송 인코딩(chunked transfer encoding)이 사용되는지 여부가 판단된다. 전송 인코딩 또는 청크 전송 인코딩이 사용되는 경우, 응답이 캐싱되지 않으며, 프로세스(1285)에서 분석이 종료될 수 있다. 전송 인코딩 또는 청크 전송 인코딩이 사용되지 않는 경우, 단계(1295)에서 응답은 캐싱 가능함 또는 캐싱 가능할 가능성이 있음(가령, 캐싱 가능하지만, 도면에 도시된 또 다른 테스트 및 분석의 대상이 됨)이라고 식별될 수 있다.

응답이 캐싱되는지 여부를 판단하기 위해, 앞서 기재된 테스트 모두가 수행될 필요는 없다. 도시되지 않은 추가 테스트가 역시 수행될 수 있다. 테스트(1208, 1210, 1212, 1220, 1222, 1224, 및 1226) 중 임의의 테스트가 단독으로 또는 임의의 조합으로 수행되어, 캐싱 가능함을 결정할 수 있다. 일부 경우, 상기의 테스트 모두 수행된다. 일부 경우, 수행되는 모든 테스트(실제로 수행되는 임의의 개수의 상기 테스트)는 캐싱 가능하다고 판단될 응답에 대해 캐싱 가능함을 확인할 필요가 있다. 즉, 일부 경우, 상기의 테스트들 중 임의의 하나가 캐싱 불가능함을 가리키는 경우, 다른 테스트의 결과에 상관없이, 응답은 캐싱되지 않는다. 다른 경우, 요청 특성 및 응답 특성의 조합을 기초로 하여, 시스템이 특정 응답을 캐싱하려 결정하기 위해, 어느 테스트를, 또는 얼마나 많은 테스트를 통과할 필요가 있는지를 판단하기 위해, 상이한 기준이 사용될 수 있다.

도 13은 요청 주기성 및/또는 응답 반복성을 기초로 하여, 캐싱 가능할 가능성이 있다고 판단하기 위해 예시적 프로세스를 나타내는 흐름도를 도시한다.

프로세스(1302)에서, 클라이언트에 의해 생성되는 요청이 추적되어, 요청의 주기성을 검출할 수 있다. 프로세스(1306)에서, 요청의 타이밍에서, 예측가능한 패턴이 존재하는지 여부가 판단된다. 예측가능한 패턴이 존재하는 경우, 프로세스(1395)에서 응답 콘텐츠가 캐싱될 수 있다. 예측가능한 패턴이 존재하지 않는 경우, 프로세스(1308)에서 요청 간격(request interval)이 허용오차 수준(tolerance level) 내에 있는지 여부가 판단된다. 요청 간격이 허용오차 수준 내에 있다고 판단되는 경우, 프로세스(1395)에서 응답 콘텐츠가 캐싱될 수 있다. 그렇지 않은 경우, 프로세스(1308)에서 요청 간격이 허용오차 수준 내에 있는지 여부가 판단된다. 요청 간격이 허용오차 수준 내에 있다고 판단되는 경우, 프로세스(1395)에서 응답 콘텐츠가 캐싱될 수 있다. 그렇지 않은 경우, 프로세스(1385)에서 응답은 캐싱되지 않는다.

프로세스(1304)에서, 클라이언트에 의해 생성된 요청에 대해 수신된 응답이 추적되어, 응답의 콘텐츠의 반복성을 검출할 수 있다. 프로세스(1310)에서, 클라이언트에 대해 수신된 응답의 응답 본체의 해시 값이 검사된다. 프로세스(1314)에서 해시 값 및/또는 상태 코드를 이용해 응답들의 적어도 2개의 응답의 콘텐츠의 유사함이 존재하는지 여부가 판단된다. 유사함이 존재한다고 판단된 경우, 프로세스(1395)에서 응답이 캐싱될 수 있다. 그렇지 않은 경우, 응답이 캐싱되지 않는다(1385).

도 14는 특정 요청 또는 클라이언트에 대해 캐싱 파라미터를 동적으로 조절하기 위한 예시적 프로세스를 도시하는 흐름도를 도시한다.

프로세스(1402)에서, 클라이언트에 의해 생성되거나 호스트로 전달되는 요청이 모바일 장치에서 추적되어, 요청들의 주기성이 검출될 수 있다. 프로세스(1404)는 둘 이상의 요청들 간의 요청 간격이 동일하거나 거의 동일한지 여부를 판단한다. 프로세스(1406)에서 둘 이상의 요청들 간의 요청 간격이 허용오차 수준내에 있다고 판단된다.

단계(1404 및 1406)의 결과를 기초로 하여, 프로세스(1408)에서 주기성이 검출되는 요청에 대한 응답이 수신된다.

프로세스(1412)에서, 응답이 모바일 장치의 캐시 내 캐시 엔트리로서 캐싱된다. 프로세스(1414)에서, 캐시 엔트리의 관련성(relevance) 또는 유효성(validity)을 검증하기 위한 속도(rate)로 호스트가 모니터링되고, 동시에, 프로세스(1416)에서, 다음번 요청을 만족시키기 위해 캐시로부터 응답이 서비스될 수 있다.

프로세스(1410)에서, 호스트를 모니터링하기 위한 속도(rate)는, 예를 들어, 프로세스(1404 및/또는 1406)의 결과를 이용해, 요청 간격으로부터 판단된다. 프로세스(1420)에서, 특정 호스트가 모니터링되는 속도가 요청에 대한 캐시 엔트리의 관련성 또는 유효성을 검증하도록 설정된다. 프로세스(1422)에서, 클라이언트에 의해 발생된 요청에 대한 요청 간격의 변경이 검출된다. 프로세스(1424)에서, 요청 간격의 변경을 기초로 하여 상이한 속도가 계산된다. 요청에 대한 캐시 엔트리의 관련성 또는 유효성을 검증하기 위해 특정 호스트가 모니터링되는 속도는 단계(1420)에서 업데이트된다.

도 15는 프록시 서버가 모바일 장치를 대신하여 애플리케이션 서버/콘텐츠 호스트를 모니터링하는 폴링 간격 또는 속도를 판단하고 설정하기 위해 요청 간격을 이용하기 위한 예시적 프로세스를 보여주는 흐름도(1500)를 도시한다.

흐름도(1500)가, 도 17A-B에서 도시된 요청/응답 시퀀스의 다양한 타이밍 파라미터를 참조한다. 타이밍 파라미터 'IT', 'RI', 'D', 'RT'는 다음과 같이 정의되고 도 17A-B에 도시된다.

1. RI - 요청 간격(request interval) - "요청 전송 0" 및 "요청 전송 1" 사이의 시간

2. D - 지연시간(delay) - '요청 전송'과 "응답의 첫 번째 바이트(HEADER) 도착" 사이의 시간

3. IT - 유휴 시간(idle time) - '전체 응답 콘텐츠 수신 0'과 '요청 전송 1' 사이의 시간

4. RT - 응답 시간(response time) - "응답의 첫 번째 바이트(HEADER) 도착"과 "전체 응답 콘텐츠 수신" 사이의 시간

로컬 프록시가 프록시 서버와 함께 폴을 설정할 때, 타이밍 파라미터 RI, IT, D, 또는 이들의 임의의 조합을 통해, 폴링 간격 또는 폴링 속도가 특정될 수 있다. 로컬 프록시가 프록시와 함께 폴을 설정할 수 있는 방법의 일부 예로는 다음과 같은 것이 있다: a) IT만 특정하기 - IT 간격이 안정한 경우에서 사용될 수 있음, b) IT와 D를 특정하기 - IT가 안정하고 D가 긴 경우에서 사용될 수 있음, c) RI만 특정하기 - RI가 안정한 경우(가령, 선형 패턴이 검출된 경우) 사용될 수 있음, d) RI와 D를 특정하기 - RI가 안정하고 D가 긴 경우에서 사용될 수 있음.

특정 클라이언트/애플리케이션(가령, 모바일 애플리케이션)의 요청에 대한 IT가 안정한지 여부가 판단되는 단계(1502)로부터 시작하는 흐름도에서 나타난 기준을 기초로 하여 각각의 설정이 선택될 수 있다. IT가 안정하지 않은 경우, 프로세스(1512)에서 RI가 주기적인지 여부가 판단되며, RI가 주기적이 아니라고 판단된 경우, 단계(1520)에서 아직 어떠한 패턴도 검출되지 않는다. RI이 주기적이라면, 프로세스가 단계(1522)로 진행되며, 이는 이하에서 상세히 설명된다.

단계(1502)에서 IT가 안정한 경우, 단계(1504)에서 'IT'가 0인지 여부가 판단된다. 단계(1504)에서 'IT'가 0이 아닌 경우, 단계(1514)에서 'RI'가 'IT'보다 더 안정한지 여부가 판단된다. 'RI'가 'IT'보다 더 안정하지 않다고 판단된 경우, 프로세스가 단계(1506)로 진행한다. 'RI'가 'IT'보다 더 안정하다고 판단된 경우, 단계(1522)에서, 프로세스가 'D'가 안정한지 여부, 또는 롱 폴 헌팅 패턴이 검출되는 여부가 판단된다. 그렇지 않은 경우, 단계(1526)에서 'RI'을 이용해 폴링에 대해 폴이 설정된다. 단계(1522)에서 D가 안정하고 헌팅 패턴이 검출된 경우, 프로세스는 단계(1524)로 진행되어, 'D'가 긴지 여부가 판단되며, 'D'가 길다고 판단된 경우, 'RI'와 'D' 모두를 이용해 폴이 설정된다. 'D'가 길지 않다고 판단된 경우, 단계(1526)에서 'R1'으로만 폴이 설정된다.

단계(1504)에서 'IT'가 0이라고 검출된 경우, 단계(1506)에서 'D'가 안정한지 여부, 또는 (롱 폴에 대한) 헌팅 패턴이 검출되는지 여부가 판단된다. 그럴 경우, 단계(1508)에서 'D'가 긴지 여부가 판단되고, 'D'가 길다고 판단된 경우, 단계(1510)에서 'D'와 'IT'의 간격이 폴링을 위해 사용될 수 있다. 따라서 판단된 'D' 및/또는 'IT'가 프록시 서버에게 또는 모바일 장치 또는 로컬 프록시를 대신하여 콘텐츠 소스를 모니터링하는 그 밖의 다른 개체에게 알려질 수 있다. 단계(1508)에서 'D'가 길지 않다고 판단된 경우, 단계(1518)에서 단지 'IT'만으로 폴이 설정될 수 있다. 그러나 단계(1506)에서 'D'가 안정하다고 검출되지 않고 헌팅 패턴이 검출되지 않은 경우, 단계(1516)에서 아직까지 어떠한 패턴도 검출된 적이 없다.

일반적으로, 둘 이상의 요청들 간 임의의 허용오차 임계치 내에서, 간격의 일부 수준의 반복성 또는 예측가능성을 참조하기 위해 '안정한' 간격이 사용될 수 있다. 예를 들어, '안정한'은 2개의 간격이 서로의 5%, 10%, 15%, 또는 20% 내에 있음을 의미할 수 있다. 일부 경우, 더 큰 차이도 허용될 수 있다. '안정한' 간격을 평가하기 위해 사용되는 임계치는 정적 값이거나, 실시간 동작 상태에 따라 변하는 동적 값, 및/또는 장치, 사용자, OS, 애플리케이션, 네트워크 운영자, ISP, 및/또는 그 밖의 다른 제3자 세부사항을 기초로 하여 변하는 값일 수 있다. 모바일 장치를 대신하여 프록시 서버의 폴링을 위해 사용되는 특정된 간격이 사용자가 인지하는 성능 또는 사용자 경험에 실질적으로 부정적인 영향을 미치지 않는 한, '안정한'에 대한 어떠한 엄격한 정의도 적용될 필요가 없다.

도 16은 다양한 유형의 요청-응답 시퀀스에 대한 타이밍 특성을 나타내는 예시적 타이밍도(1600)를 도시한다.

도 16에서, 8개의 타임 라인 조합이 도시되고, 각각의 타임 라인이 요청-응답 시퀀스의 2개의 블록을 포함한다. 각각의 시퀀스에서, 점선은 요청-응답 간격 내 응답을 가리킨다. 시퀀스(1602)는 짧은 'D', 짧은 'RT', 및 긴 'IT'를 특징으로 한다. 따라서 시퀀스(1602)는 일반적인 폴일 수 있다. 시퀀스(1604)는 짧은 'D', 짧은 'RT', 짧은 'IT'를 특징으로 하며, 높은 폴링 속도를 나타낸다. 또한 시퀀스(1604)는 사용자가 애플리케이션과 적극적으로 상호대화하는 중, 및/또는 애플리케이션을 적극적으로 리프레시하는 중임을 가리킬 수 있다.

시퀀스(1606)는 짧은 'D', 긴 'RT', 및 짧은 'IT'를 특징으로 하며, 가능한 스트리밍을 가리킬 수 있다. 시퀀스(1608)는 짧은 'D', 긴 'RT', 및 긴 'IT'를 특징으로 하며, 큰 콘텐츠의 폴링을 가리킬 수 있다. 시퀀스(1610)는 긴 'D', 짧은 'RT', 및 긴 'IT'를 특징으로 하며, 이는 애플리케이션 레벨에서 허용되는 높은 대기시간(latency)을 갖는 롱 폴(long poll)을 가리킬 수 있다.

긴 'D', 짧은 'RT', 및 짧은 'IT'를 갖는 시퀀스(1612)는 롱 폴을 가리킬 수 있다. 긴 'D', 긴 'RT', 및 짧은 'IT'를 갖는 시퀀스(1614)가 큰 콘텐츠의 스트리밍 또는 롱 폴을 가리킬 수 있다. 시퀀스(1616)는 긴 'D', 긴 'RT', 및 긴 'IT'를 가지며, 시퀀스(1614)와 시퀀스(1610)의 조합일 수 있다.

도 17A는 요청 및 응답 시퀀스에 대한 타이밍 특성을 나타내는 타이밍도(1700)의 일례를 도시한다.

본 발명의 기법은 장치 측 프록시와 서버 측의 협업을 포함하는 분산 캐싱 모델을 포함한다. 분산 캐싱 모델이 캐싱 응답 후 동작하도록 하기 위해, 클라이언트 측 구성요소는 서버 측 프록시에게 통지하고, (캐싱된 콘텐츠의 유효성을 검증하기 위해) 특정 자원(애플리케이션 서버/콘텐츠 제공자)이 폴링되어야 할 속도를 제공할 필요가 있다. 이러한 통지를 수신한 후, 서버 측 프록시는 변경사항을 찾기 위해 자원을 모니터링(자원 검증)할 수 있고, 변경사항이 검출되면, 서버 측 구성요소는 무효화 요청을 전송함으로써 장치 측 구성요소에게 통지할 수 있다.

클라이언트 측 구성요소는 최적의 성능을 위해 올바르고 안정한 폴링 간격(가령, 서버 측 프록시가 자원을 모니터링하기 위해 자원으로 폴링하는 간격)을 서버 측 프록시에게 제공할 필요가 있는데, 이는 폴링 간격이 너무 낮은 경우, 서버 측 프록시에서 로드(load)가 불필요하게 증가하기 때문이다. 폴링 간격을 증가시킴으로써, 로컬 프록시가 사용자 장치에서 사용자에게 만료된/관련성이 없는 정보를 제공할 위험이 있다.

앞서 기재된 바와 같이, 요청 클라이언트/애플리케이션과 콘텐츠 제공자/애플리케이션 서버 간의 요청-응답 시퀀스의 타이밍 특성이 사용되어, 애플리케이션 거동을 결정, 및/또는 요청 유형을 카테고리화하도록 사용될 수 있다. 애플리케이션의 폴링 간격을 결정, 식별, 추정, 또는 예측하기 위해, 이러한 정보가 사용될 수 있음으로써, 서버 측 프록시가 자원을 모니터링할 필요가 있는 최적 폴링 간격이 판단되고 서버 측 프록시로 제공될 수 있다.

타이밍 특성은, 예를 들어, 요청이 전송된 후 응답을 수신하기까지의 응답/지연 시간과, 응답이 수신된 후 다음번 요청을 전송하기까지의 유휴 시간을 포함할 수 있다. 응답-요청 시퀀스에서의 다양한 시간 간격들의 관계가 타이밍도(1700)에서 나타날 수 있다.

다음의 이벤트들 중 모두 또는 일부를 이용하여, 각각의 요청-응답 시간 시퀀스가 설명될 수 있다: 1) 요청 전송 시작(1705), 2) 요청 전송됨, 3) 응답 시작하기(1710), 4) 응답 종료됨(1720), 및 5) 다음번 요청 전송됨(1715). '응답 시작하기' (1710)는 응답의 첫 번째 바이트(HEADER)가 도착할 때를 나타내고, '응답 종료'(1720)는 모든 응답 콘텐츠가 수신됐을 때를 나타낸다.

이들 이벤트들을 이용하여, 장치 측은 1700에 나타난 다음의 간격들을 계산할 수 있다:

1. RI(1708) - 요청 간격(request interval) - "요청 전송 0"과 "요청 전송 1" 사이의 시간

2. D(1704) - 지연시간(delay) - '요청 전송'과 '응답의 첫 번째 바이트(HEADER) 도착' 사이의 시간

3. IT(1706) - 유휴 시간(idle time) - '전체 응답 콘텐츠가 수신됨 0'과 '요청 전송 1' 사이의 시간

4. RT(1712) - 응답 시간(response time) - '응답의 첫 번째 바이트(HEADER)가 도착'과 '전체 응답 콘텐츠가 수신됨' 사이의 시간.

요청-응답 시퀀스에서의 타이밍 특성의 관계(RI=D+RT+IT)가 고려되어, 콘텐츠를 분산 방식으로 캐싱하는 데 사용되기 위한 애플리케이션 거동 정보를 추출할 수 있다. 또한, 애플리케이션 및 상기 애플리케이션의 요청을 특징화하기 위해 서로 다른 간격들 간의 상대적 비교가 사용될 수 있다.

일반적으로, 분산 프록시의 장치 측 구성요소가 요청-응답 시퀀스의 개별 타이밍 간격을 계속 알고 있고, 값들을 상대적 방식으로 비교하거나(가령, 다른 간격보다 큰지 또는 작은지), 절대적 방식으로 비교한다(구체적 지속시간, 즉, 동적 또는 정적 임계값에 비교할 때 긴지, 짧은지, 등). 장치 측 구성요소는 시간의 흐름에 따라 이들 간격 값을 추적하고, 안정한 구성요소에 대해 체크하며, 추세나 패턴을 결정 또는 식별할 수 있다. 예를 들어, 장치 측 구성요소는 롱 폴 요청에 대한 롱 폴 헌팅 모드의 경우, 증가하거나 감소하는 'D'(1704)를 검출할 수 있다. 도 17B는 롱 폴의 요청/응답 시퀀스 특성에 대한 타이밍 특성을 나타내는 타이밍도(1750)의 일례를 도시한다. 타이밍도(1750)는 높은 대기시간의 롱 폴에 적용될 수 없다.

하나의 실시예에서, 요청은, 요청 0(1755)과 응답 시작 시점(1760) 사이의 유휴 시간(IT(1756))에 대한 응답/지연 시간(D(1754))의 비교를 기초로 하여, 롱 폴 요청이라고 검출 또는 결정될 수 있다. 예를 들어, 응답 지연 시간에 비교해서 유휴 시간이 짧을 때(IT(1756) < D(1754)), 요청이 롱 폴 요청이라고 검출될 수 있다. 또한 IT(1756)가 0이거나 실질적으로 0(~0)일 때, 요청은 롱 폴이라고 판단될 수 있다.

덧붙이자면, 유휴 시간(IT(1756))이 다음번 요청이 응답이 수신된 즉시, 또는 거의 즉시 발생했음을 가리키는 경우(가령, 짧은 IT(1756)), 요청이 롱 폴 요청이라고 판단되거나 카테고리화될 수 있다. 덧붙이자면, RI(1758) = D(1754) + RT(1762) + IT(1756) ~ D(1754) + RT(1762)인 경우, 요청은 롱 폴이라고 판단될 수 있다. 하나의 실시예에서, 응답 시간 'RT'(1762)가 사용되어, 비트 전송 속도(bit rate)(가령, 바이트*8/시간으로 된 크기)를 결정할 수 있다.

일반적으로, 시간 간격의 여러 다른 조합이 특정 애플리케이션 또는 요청의 폴링 패턴에 대한 지시자를 제공하며, 장치 측 구성요소에 의해 사용됨으로써, 콘텐츠 소스를 모니터링하는 데 사용되기 위한 서버 측 구성요소에 대한 폴링 간격을 생성할 수 있다.

도 18은 캐싱되기 적합할 수 있는 주기적 요청의 검출의 일례를 나타내는 데이터 타이밍도(1800)를 도시한다.

도시된 예에서, 모바일 장치 상의 클라이언트/애플리케이션으로부터의 제 1 요청이 시점 1:00(t1)에서 검출된다. 이때, 단계(1802)에서 캐시 엔트리가 생성될 수 있다. 시점 2:00(t2)에서, 동일한 클라이언트/애플리케이션으로부터 제 2 요청이 검출되고, 이때, 단계(1804)에서, 생성된 캐시 엔트리가, 검출된 간격(시점 t2와 시점 t1 사이의 1시간)으로 업데이트될 수 있다. 동일한 클라이언트로부터의 제 3 요청이 시점 3:00(t3)에서 검출되고, 단계(1806)에서 주기적 요청이 검출됐다고 판단될 수 있다. 로컬 프록시가 응답을 캐싱하고, 간격(가령, 이 경우, 1시간)을 프록시 서버에게 알려주는 폴 시작 요청을 전송할 수 있다.

타이밍도는 2:54와 3:06 사이의 타이밍 윈도(timing window)를 더 도시하며, 이 타임 프레임(1810) 내에서 제 3 요청이 수신된 경우 주기성이 있다고 판단될 윈도의 경계부를 가리킨다. 2:54와 3:06 사이의 타이밍 윈도(1808)는 이전 간격의 20%에 대응하며, 예시적 허용오차이다. 그 밖의 다른 허용오차가 사용될 수 있고, 동적으로, 또는 케이스별로(애플리케이션별로), 결정될 수 있다.

도 19는 요청 간격의 변경을 검출하고, 이에 대한 응답에서 서버 폴링 속도를 업데이트하는 예를 나타내는 데이터 타이밍도(1900)를 도시한다.

단계(1902)에서, 프록시는 주기적 요청이 검출됐다고 판단하며, 로컬 프록시는 응답을 캐싱하고 프록시 서버로의 폴링 요청을 설정하며, 예를 들어, 간격은 제 3 요청에서 1시간으로 설정된다. 시점 3:55(t4)에서, 요청은 1시간이 아니라 55분 후에 검출된다. 55분이라는 간격은 여전히, 20%의 허용오차의 경우, 윈도(1904) 내에 있다. 그러나 단계(1906)에서 제 5 요청이 시점 4:50(t5)에 수신되고, 이는 더 이상, 제 1 요청과 제 2 요청 사이의 간격과 제 2 요청과 제 3 요청 사이의 간격(1시간)으로부터 결정된 허용오차 윈도 내에 있지 않는다. 이제 로컬 프록시가 프록시 서버로부터 자원 또는 응답을 불러오고 로컬 캐시(가령, 제 5 요청을 서비스하기 위해 사용되지 않은 캐시 엔트리)를 리프레시한다. 또한 로컬 프록시는 업데이트된 간격(가령, 이 예시의 경우, 55분)을 이용해 폴 시작 요청을 프록시 서버로 재전송하며, 예를 들어 20%라고 설정된 허용오차에 의해 정의된 윈도는 이제, 12분이 아니라 11분이 된다.

일반적으로, 로컬 프록시가 업데이트된 폴링 간격을 갖고 프록시 서버에게, 간격 변경이 검출될 때, 및/또는 새로운 속도(rate)가 결정될 때를 통지한다. 그러나 이는 배경 애플리케이션 요청 또는 자동/프로그램된 리프레시(가령, 어떠한 사용자 상호대화도 관련되지 않는 요청)에 대해서만 수행되는 것이 일반적이다. 일반적으로, 사용자가 전경에서 애플리케이션과 상호대화하고, 주기외(out of period) 요청이 검출되도록 하는 경우, 도 20에 도시되는 것처럼, 프록시 서버에 특정된 폴링의 속도(rate) 또는 폴링 간격이 업데이트되지 않는 것이 일반적이다. 도 20은 캐싱된 엔트리를 이용하여 전경 요청(foreground request)을 서비스하는 일례를 나타내는 데이터 타이밍도(2000)를 도시한다.

예를 들어, t=3:00과 3:30 사이에서, 로컬 프록시가 t = 3:10와 t = 3:20에서 제 1 전경 요청과 제 2 전경 요청을 검출한다. 이들 전경 요청은 배경 애플리케이션 또는 자동 애플리케이션 요청에 대해 검출된 주기를 벗어난다. 전경 요청에 대해 불러와 진 응답 데이터가 캐싱되고 업데이트될 수 있지만, 프로세스(2008)에서 전경 요청에 대한 요청 간격은 서버로 전송되지 않는다.

도시된 바와 같이, t=4:00에서 애플리케이션으로부터 검출되는 다음 주기 요청(가령, 배경 요청, 프로그램된/자동적 리프레시)에 대해, t=5:00에서의 요청인 것처럼, 응답이 캐시로부터 서비스된다.

도 21은 요청하는 애플리케이션에게 오래된 콘텐츠(outdated content)가 다시 한번 서비스된 후 발생하는 캐시 무효화(cache invalidation)의 비-최적 효과의 일례를 나타내는 데이터 타이밍도(2100)를 도시한다.

프록시 서버의 간격은, 애플리케이션(가령, 모바일 애플리케이션)이 요청을 전송하는 간격과 거의 동일한 간격으로 설정되기 때문에, 캐싱된 엔트리(현재, 오래된 엔트리)가 요청에 대해 이미 서비스된 후(가령, t=5:00에서의 제 5 요청까지) 프록시 서버가 (가령, t=5:02에서) 변경된 콘텐츠를 검출하는 경우일 가능성이 높다. 도시된 예에서, t=4:20에서 자원이 업데이트 또는 변경되며, t=4:02에서 발생한 이전 서버 폴은 다음 폴(5:02) 전까지 이러한 변경을 포착할 수 없었으며, 캐시 무효화를 로컬 프록시로 전송한다(2110). 따라서 시점 t=5:00에서의 제 5 요청에 대해 낡은 콘텐츠로 이미 서비스된 후 임의의 시점에서 로컬 캐시가 캐시를 무효화하지 않는다. 제 6 요청(t=6:00)이 지나서야, 즉, 1주기가 후에야, 프레시 콘텐츠(fresh content)가 요청하는 애플리케이션으로 제공된다(2106).

캐싱 성능을 최적화하고, 이러한 문제를 해결하기 위해, 로컬 프록시가, 폴링 간격에 추가로, 요청의 초기 시점을, 프록시 서버에게 특정해 줌으로써, 시간 설정을 조절할 수 있다. 요청의 초기 시점은, 요청이 실제로 발생하기 얼마 전(가령, 수분 전)으로 설정됨으로써, 미래의 애플리케이션 요청 약간 전에 프록시 서버 폴이 발생할 수 있다. 이러한 방식으로, 프록시는 다음번 애플리케이션 요청에 대새 서비스될 응답의 임의의 시간 변경사항을 수집할 수 있다.

도 22는 캐시 엔트리에 대해 설정된 수명시간(TTL)을 고려하는 캐시 관리 및 응답을 나타내는 데이터 타이밍도(2200)를 도시한다.

하나의 실시예에서, 로컬 캐시 내에 캐싱된 응답 데이터가, 캐시 엔트리가 삭제 또는 제거될 때까지 로컬 캐시에 저장될 수 있는 시간을 특정한다.

특정 캐시 엔트리 내 응답 데이터가 제거될 예정인 시점이, 공식: <응답 데이터_캐시 시간> + <TTL>을 이용해 결정될 수 있으며, t=3:00에서 나타나는 것처럼, 단계(2212)에서 캐싱으로 인해 TTL이 경과된 후(가령, 이 예시의 경우, 단계(2212)에서의 캐싱 후 24시간), 응답 데이터가 자동으로 제거된다. 일반적으로 수명시간(TTL)이 (가령, 응답 데이터와, 주기성 관련 정보와 주기성을 계산하기 위해 사용되는 정보를 포함하는 임의의 메타데이터를 모두 포함하는) 전체 캐시 엔트리에 적용된다. 하나의 실시예에서, 캐싱된 응답 데이터(TTL)는 디폴트로 24시간, 또는 그 밖의 다른 값(가령, 6시간, 12시간, 48시간 등)으로 설정된다. 또한 TTL은, 관리자/사용자(admin/user)에 의해 동적으로 조절 또는 재설정되고, 및/또는 경우에 따라, 또는 장치, 애플리케이션, 네트워크 제공자, 네트워크 조건, 운영자, 및/또는 사용자별로 상이할 수 있다.

도 23은 캐시 스토어(cache store)를 위한 구성요소 API 레이어의 일례적 다이어그램을 도시한다.

캐시 스토어 구성요소 API의 한 가지 예는 다음의 개체를 포함할 수 있다: 1) 캐시 관리기(2312). 캐시 관리 시스템의 클라이언트 측 엔트리 포인트. 상기 캐시 관리기에 의해, 복수의 애플리케이션/클라이언트에 대해 서로 다른 캐시의 등록이 가능할 수 있으며, 필요할 때 이를 관련 애플리케이션/클라이언트로 제공한다. 2) ICache(2314). 이 개체는 캐시 스토어, 즉, 캐시 엔트리의 풀을 유지관리하기 위한 메커니즘을 나타낸다. iCache 내 캐시 엔트리는 질의, 편집, 제거, 및/또는 새로운 엔트리로 업데이트될 수 있다. 3) ICacheListener(2304). 이는 애플리케잉션/클라이언트의 특징(feature)의 구현을 가능하게 함으로써, 캐시 관련 통지의 수신을 가능하도록 한다. 4) CacheEvent(2302). 이는 캐시 관련 이벤트를 나타낸다. 5) 반복자(Iterator)(2320). 이는 캐시 엔트리의 집합에 대해 반복하기 위한 메커니즘을 제공한다. 6) ICacheFilter(2306). 이는 캐시 엔트리를 필터링하기 위한 메커니즘을 제공한다. 7) UrIFilter(2308). 이는 엔트리 URI를 기초로 캐시 룩업 수행을 가능하게 하는 캐시 필터이다. 8) IdentityFilter(2310). 이는 엔트리 ID를 기초로 하는 캐시 룩업의 수행을 가능하게 하는 캐시 필터이다. 9) ICacheEntry(2316). 이 개체는 단일 캐시 엔트리를 나타낸다. 캐시 엔트리는 ID 또는 URI에 의해 식별되며, 둘 모두 하나의 단일 캐시의 범위에서 고유(unique)해야 한다. 10) ICacheEntryData(2318). 이는 일부 캐시 엔트리와 연계된 명명된 데이터(named data)이다.

도 24는 캐시 스토어를 위한 데이터 모델의 하나의 예시를 나타내는 다이어그램을 도시한다. 캐시 스토어는 모바일 플랫폼 특정적일 수 있다. 하나의 실시예에서, 캐시 스토어는 하이브리드 저장장치를 이용할 수 있고, 상기 하이브리드 저장장치는, 1) 캐시 엔트리를 영속시키기 위한 SQL 파일 데이터베이스, 또는 2) 메타-데이터 및 2진 응답 데이터(binary response data)를 영속시키기 위한 파일 시스템이라는 구성요소를 포함할 수 있다. 이 구성은 모바일 플랫폼, 예컨대 안드로이드(Android)를 위해 사용될 수 있다.

도 25는 캐시 스토어(2502) 내 캐시 엔트리(2504)의 데이터 모델의 하나의 예시의 개념적 다이어그램을 도시한다. 식별자(가령, URI)에 의해 특정 캐시 엔트리(2504)는 식별될 수 있다. 일반적으로, 캐시 엔트리가 응답 데이터 구성요소(가령, ResponseData 필드(2508))와 임의의 연계 메타데이터(가령, MetaInfo 필드(2506))를 포함한다.

도 26A-B는 변하는 파라미터(changing parameter)(2602 및 2652)를 갖는 식별자에 의해 주소지정되는 캐싱 가능한 응답(2604 및 2654)을 나타내는 예시적 요청-응답 쌍을 도시한다.

타이밍 파라미터(2602)가 매번 변할지라도 각각의 요청에 대해 수신된 응답(2604)이 동일하기 때문에, 도 26A의 예에서 도시된 요청/응답 쌍은, 캐시 디피트(cache defeat)를 위해 사용되는 타이밍 파라미터(2602)를 나타낸다. 두 번째, 또는 세 번째, 또는 그 이상의 후속하는 때에 '응답'이 동일한 것으로 검출되면, 자원 식별자 및 파라미터(2602)는 캐시 디피트한다고 식별될 수 있다.

마찬가지로, 식별자 내 랜덤 파라미터(2652)가 매 번 달라지더라도 각각의 요청에 대해 수신되는 응답(2654)이 동일하기 때문에, 도 26B의 예시에서 도시된 요청 응답 쌍이, 캐시 디피트를 위해 사용되는 랜덤 파라미터(2652)를 도시한다. 두 번째, 또는 세 번째, 또는 그 이상의 후속하는 때에, '응답'이 동일한 것으로 식별되면 식별자 및 파라미터(2602)가 캐시 디피트한다고 식별될 수 있다. '응답=x'의 캐싱이 두 번째 검출된 동일한 응답, 세 번째 검출된 동일한 응답, 또는 그 이상의 후속하는 때에 검출된 동일한 응답에서 유사하게 시작될 수 있다.

2가지 유형의 변하는 파라미터(타이밍/날짜(2602) 및 랜덤 파라미터(2652))가 도시되지만, 그 밖의 다른 유형의 변하는 파라미터가 캐시 디피트를 위해 사용될 수 있고, 시스템에 의해 유사하게 검출될 수 있다.

도 27A는 모바일 장치에서 애플리케이션 또는 클라이언트를 위한 디폴트 또는 초기 폴링 간격의 예시적 리스트(2700)를 도시한다.

애플리케이션의 리스트는 모바일 장치에서 폴링하는, 또는 폴링하는 것으로 검출된 모든 또는 일부 모바일 애플리케이션/클라이언트를 가질 수 있다. 모바일 장치에서 (가령, 로컬 프록시(275)에 의해) 폴링 간격 및 그 밖의 다른 임의의 폴링 거동 또는 네트워크 액세스가 검출될 수 있다. 모바일 장치의 로컬 프록시(275)에 의해, 각각의 애플리케이션의 상대적 우선순위(가령, 야후(Yahoo) 메일 vs. 범용 IMAP 전자메일, 트위터(Twitter), RSS, 또는 ESPN)도 역시 결정 또는 추론될 수 있다.

도 27B는 모바일 장치에서의 애플리케이션 또는 클라이언트(2702)를 위해, 원본 폴링 간격(2704)으로부터 조절된 폴링 간격(2706)의 예시적 리스트를 도시한다.

조절된 폴링 간격이 설정될 수 있는 다양한 방식이 존재하며, 컬럼(2706) 하에서 도시된 리스트는, 이러한 특정 세트의 애플리케이션을 위한 많은 가능한 경우 중 하나의 예이다. 이 예에서, 원본 폴링 간격 중에서 선택된 공통 분모 또는 인수는 '3s.'이며, 그 밖의 다른 애플리케이션에 대한 간격이 선택 또는 설정되고, 반올림되거나 반내림될 수 있다. 예를 들어, IMAP, 트위터(Twitter), RSS에 대한 폴링 간격이 반올림되며, 이는 전송량을 최소화하고 네트워크 트래픽을 경감시키는 이점을 가진다. 일부 경우, 시스템은 애플리케이션들 중에서 더 높은 우선순위(가령, 트위터)를 검출하고, 조절된 폴링 간격을 6s.가 아닌 3s.로 설정하여, 데이터 정렬 전략을 적용하지 않은 경우 전달됐을 시점이나 그 전에, 업데이트된 콘텐츠가 수신됨을 보장할 수 있다. 또한 폴링 간격은, 예를 들어, 우선순위, 사용자 선호도, 네트워크 조건, 운영자 설정, 등을 기초로 하여, 더 빈번하거나 덜 빈번한 폴로 설정될 수 있다. 폴링 간격은, 애플리케이션 수요, 애플리케이션 거동, 운영자 특정 설정, 사용자 설정 또는 선호도, 이들의 조합을 기초로, 일부 애플리케이션의 경우 더 빈번한 폴로, 이와 균형을 유지하기 위해(trade off) 나머지 애플리케이션의 경우 덜 빈번한 폴이도록 설정된다.

도 28은 모바일 장치가 트랜잭션이 발생할 때마다 라디오를 구축하거나 켤 필요없도록, 특정 모바일 장치로의 송신을 위한 복수의 트랜잭션을 통해 수신되는 데이터를 일괄 처리하기 위해 복수의 모바일 장치 또는 모바일 장치 사용자에 대해 수행되는 예시적 프로세스를 나타내는 흐름도를 도시한다.

프로세스(2802)에서, 모바일 장치로 전달되는 데이터가 복수의 트랜잭션에서 수신된다. 전부는 아니지만 임의의 복수의 트랜잭션이 동시에 발생할 필요가 있음을 알아야 한다. 예를 들어, 일부 트랜잭션은 동시에 발생할 수 있으며, 이들 모두 서로 다른 때에 발생할 수 있다.

프로세스(2804)에서, 데이터가 전송되기 전에 일괄처리(batch)된다. 데이터를 일괄처리함으로써, 모바일 장치로의 데이터 전송이 셀룰러 네트워크 내 모바일 장치에 의해 만들어지는 연결을 최적화하도록 정렬될 수 있다. 일반적으로 복수의 트랜잭션에서 수신되는 데이터가, 수행될 수 있거나, 및/또는 예를 들어, 애플리케이션 특성, 거동, 애플리케이션 또는 상기 애플리케이션이 운반하는 트래픽의 중요도, 사용자 선호도, 실시간 네트워크 상태, 네트워크 혼잡도, 네트워크의 유형, 네트워크 운영자/통신업체 설정 도는 선호도, 사용자 구독 유형, 사용자 계정 유형, 모바일 장치 제조업체 설정(가령, 장치 하드웨어 설정 및 능력), 플랫폼 또는 OS 특정 설정 등을 기초로 하여, 추가로 동적으로 조절될 수 있는 시간 윈도(time window) 내에서 발생한다.

복수의 트랜잭션에서 수신된 데이터는 모바일 장치 상의 복수의 서로 다른 클라이언트(가령, 서로 다른 모바일 클라이언트 또는 애플리케이션)에게 전달되거나, 모바일 장치의 사용자가 구독하는 서로 다른 웹 서비스로부터 전달될 수 있다. 예를 들어, 하나의 트랜잭션에서, 전자메일이 수신되고, 제 2 트랜잭션에서, 네트워킹 애플리케이션(가령, 페이스북(Facebook), 링크드인(Linkedin) 등)을 위한 상태 업데이트 또는 뉴스 피드가 수신된다. 일괄처리될 수 있는 그 밖의 다른 트랜잭션은, 동시에 또는 서로 다른 때에서의 서로 동일하거나 상이한 애플리케이션에 대한 데이터 또는 콘텐츠(가령, IM 통지/메시지, 웹 브라우저에 대한 콘텐츠, SMS, 통지 등)를 포함할 수 있다.

프로세스(2806)에서, 복수의 트랜잭션이 발생할 때마다 매 번 모바일 장치와의 무선 연결이 확립될 필요가 없도록, 일괄처리된 데이터가 셀룰러 네트워크를 통해 모바일 장치로 전송된다. 예를 들어, 일부 트랜잭션으로부터의 데이터의 서브셋이 모바일 장치로의 하나의 트랜잭션에서 일괄처리될 수 있고, 제 2 서브셋은 모바일 장치로의 또 다른 트랜잭션에서 일괄처리될 수 있다. 하나의 실시예에서, 프로세스(2808)에서, 모바일 장치에서의 무선 네트워크 연결의 단일 설치를 통해, 일괄처리된 데이터가 단일 트랜잭션으로 모바일 장치로 전송되는데, 예를 들어, 복수의 트랜잭션에서 수신된 모든 데이터가 모바일 장치로의 하나의 트랜잭션으로 일괄처리된다.

도 29는 폴링 간격을 조작함으로써, 무선 네트워크 내 모바일 장치로의 데이터 전송을 관리하기 위한 예시적 프로세스를 나타내는 흐름도를 도시한다.

프로세스(2902)에서, 콘텐츠 호스트의 복수의 애플리케이션의 디폴트 폴링 간격은, 각자의 콘텐츠 호스트로부터 결정된다. 디폴트 폴링 간격으로부터, 제 1 서비스에 대해 조절된 폴링 간격이, 예를 들어, 개별 콘텐츠 호스트에 의해 서비스되는 제 2 서비스의 폴링 간격을 기초로 하여, 결정되거나 생성될 수 있다.

프로세스(2904)에서, 업데이트된 폴링 간격이 복수의 애플리케이션 중 일부에게 할당되어, 복수의 애플리케이션에 대한 폴링 시간(polling times) 중 적어도 일부가 시간상 겹칠 수 있다. 업데이트된 간격은, 제 1 및 제 2 서비스의 모바일 장치 상에서의 액세스로 인해 개별 호스트로부터 수신된 적어도 일부 트래픽을 정렬하는 데 사용될 수 있다.

업데이트된 폴링 간격은, 예를 들어, 복수의 애플리케이션에 대한 간격의 공통 인수 또는 분모로부터 결정될 수 있다. 애플리케이션 중요도 및/또는 애플리케이션에 포함된 트래픽의 우선순위/시간 민감도를 고려하여 인수를 정하면서 또한 간격도 결정된다. 폴링 간격을 결정하거나 설정하기 위한 예시적 프로세스가 도 30에서 도시된다. 일반적으로, 제 1 서비스의 원본 폴링 간격과 제 2 서비스의 폴링 간격이 서로의 인수이거나 분모일 때, 특정 서비스에 대해 조절된 폴링 간격이 제 1 서비스의 원본 폴링 간격을 기초로 하고, 조절된 폴링 간격은 제 1 서비스의 원본 폴링 간격과 상이할 필요는 없다. 하나의 실시예에서, 조절된 폴링 간격은 또 다른 서비스의 폴링 간격의 인수의 배수이거나 분모의 배수이다. 조절된 폴링 간격은, 제 2 서비스로부터의 트래픽의 시간 중요도에 비교되는 제 1 서비스로부터의 트래픽의 시간 중요도를 기초로 더 결정될 수 있다.

프로세스(2906)에서, 복수의 애플리케이션을 서비스하는 콘텐츠 호스트의 초기 폴에 대해 공통의 시작시점이 선택된다. 프로세스(2908)에서, 공통의 시작시점과 업데이트된 폴링 간격을 기초로 하여, 콘텐츠 호스트로부터 콘텐츠가 폴링된다.

도 30은 제 1 서비스에 대한 조절된 폴링 간격을, 동일한 장치의 또 다른 서비스의 간격을 기초로 하여, 생성하기 위한 예시적 프로세스를 나타내는 흐름도를 도시한다.

프로세스(3002)에서, 복수의 디폴트 폴링 간격의 공통 인수의 배수가 결정된다. 프로세스(3004)에서, 복수의 디폴트 폴링 간격의 공통 분모의 배수가 결정된다. 프로세스(3050)에서, 공통 인수 및/또는 공통 분모를 이용해, 업데이트된 폴링 간격이 결정된다.

프로세스(3012)에서, 모바일 장치 상의 타 애플리케이션에 비교되는 애플리케이션의 트래픽의 시간 중요도가 결정된다. 프로세스(3014)에서, 중요 애플리케이션(critical application)이 모바일 장치 상의 복수의 애플리케이션들 중에서 가장 시간 중요성을 가진다고 식별된다.

프로세스(3016)에서, 중요 애플리케이션의 디폴트 폴링 간격이 최소 중요 간격이라고 식별된다. 일반적으로, 중요 애플리케이션에 대한 업데이트된 폴링 간격을 할당할 때 최소 중요 간격이 초과되지 않는다. 프로세스(3050)에서, 예를 들어, 임의의 중요 애플리케이션 및/또는 시간 민감형 트래픽에서, 디폴트 폴링 간격을 이용하고 인수를 구함으로써, 업데이트된 폴링 간격이 결정될 수 있다.

도 31은 무선 네트워크를 통한 전송을 위해 구축된 연결을 최적화하기 위해 데이터 전송을 정렬하기 위한 예시적 프로세스를 나타내는 흐름도를 도시한다.

프로세스(3102)에서, 수신자에게 전달되는 제 1 데이터세트가 제 1 인스턴스에서 수신된다. 프로세스(3104)에서, 수신자에게 전달되는 제 2 데이터세트가 제 2 인스턴스에서 수신된다. 제 1 인스턴스와 제 2 인스턴스는 서로 다른 시점일 수 있고, 제 1 데이터세트와 제 2 데이터세트가 서로 다른 웹 서비스(가령, 사용자/수신자가 구독하는 서비스)로부터 수신될 수 있다. 제 1 데이터세트와 제 2 데이터세트는, 서로 다른 때에 수신될 수 있더라도, 일괄처리될 수 있고, 정렬된 채 모바일 장치로 송신될 수 있도록, 동일한 모바일 장치 상의 서로 다른 모바일 애플리케이션으로 전달된다.

프로세스(3106)에서, 무선 네트워크에서의 단일 무선 연결이 확립된다. 하나의 실시예에서, 모바일 장치 상의 캐싱된 콘텐츠를 업데이트하기 위해, 제 1 및 제 2 데이터세트가 변경된 데이터를 포함한다고 판단한 것에 응답하여, 수신자로의 송신이 개시된다. 덧붙이자면, 제 2 데이터 세트가 전달되는 모바일 장치 상의 제 2 데이터세트 또는 애플리케이션의 우선순위 또는 시간 중요도의 레벨을 검출하는 것에 응답하여, 단일 무선 연결의 구축이 트리거된다. 프로세스(3108)에서, 제 1 및 제 2 인스턴스에서 수신된 제 1 및 제 2 데이터세트가, 무선 네트워크를 통해, 수신자로 전송된다.

도 32는 컴퓨터 시스템의 예시적 형태로 된 기계를 나타내는 개략도이며, 상기 기계에서, 본원에서 개시되는 방법들 중 임의의 하나 이상을 기계가 수행하도록 하는 하나의 세트의 명령(instruction)이 실행될 수 있다.

대안적 실시예에서, 기계는 자립형(standalone) 장치로서 동작하거나, 다른 기계로 연결(가령, 네트워크-연결)될 수 있다. 네트워크-연결된 형태에서, 기계는 클라이언트-서버 네트워크 환경에서 서버 또는 클라이언트 기계로서 동작하거나, 피어-투-피어(또는 분산) 네트워크 환경에서 피어 기계(peer machine)로서 동작할 수 있다.

기계는, 서버 컴퓨터, 클라이언트 컴퓨터, 개인 컴퓨터(PC), 사용자 장치, 태블릿 PC, 랩톱 컴퓨터, 셋 톱 박스(STB), PDA(personal digital assistant), 셀룰러 전화기, iPhone, iPad, Blackberry, 프로세서, 전화기, 웹 어플라이언스, 네트워크 라우터, 스위치 또는 브리지, 콘솔, 핸드-헬드 콘솔, (핸드-헬드) 게임 장치, 음악 재생기, 임의의 휴대용, 모바일, 핸드-헬드 장치, 또는 수행할 동작을 특정하는 한 세트의 명령어를 (순차적으로 또는 그 밖의 다른 방식으로) 실행할 수 있는 임의의 기계일 수 있다.

하나의 예시적 실시예에서, 기계 판독형 매체 또는 기계 판독형 저장 매체가 하나의 단일 매체인 것으로 나타나지만, 용어 "기계-판독형 매체" 및 "기계-판독형 저장 매체"는 하나 이상의 세트의 명령을 저장하는 단일 매체 또는 복수의 매체(가령, 중앙집중형 또는 분산형 데이터베이스 및/또는 이와 연계된 캐시 및 서버)를 포함하도록 이해되어야 한다. 용어 "기계-판독형 매체"와 "기계-판독형 저장 매체"는 또한, 기계가 현재 개시된 기법 및 혁신 기술의 방법들 중 임의의 하나 이상을 수행하도록 하며 기계에 의해 실행되기 위한 한 세트의 명령을 저장, 인코딩, 또는 지닐 수 있는 임의의 매체를 포함하도록 이해되어야 할 것이다.

일반적으로, 본원에 개시된 실시예를 구현하도록 실행되는 루틴이, 운영 체제, 또는 특정 애플리케이션, 구성요소, 프로그램, 객체, 모듈, 또는 "컴퓨터 프로그램"이라 지칭되는 명령들의 시퀀스의 일부분으로서 구현될 수 있다. 컴퓨터 프로그램은, 컴퓨터의 다양한 메모리 및 저장 장치에서 다양한 시점에서, 컴퓨터의 하나 이상의 프로세싱 유닛에 의해 판독되고 실행될 때 컴퓨터가 본원의 다양한 양태들과 관련된 요소를 실행하기 위한 동작을 수행하도록 하는 하나 이상의 명령 세트를 포함하는 것이 일반적이다.

덧붙여, 실시예들이, 완전히 동작하는 컴퓨터 및 컴퓨터 시스템의 맥락에서 기재되었지만, 해당업계 종사자라면 다양한 실시예는 다양한 형태의 프로그램 프로덕트로서 분산될 수 있고, 본원은 실제로 분산을 위해 사용되는 특정 유형의 기계 또는 컴퓨터-판독형 매체에 무관하게 동일하게 적용됨을 알 것이다.

기계-판독형 저장 매체, 기계-판독형 매체, 또는 컴퓨터-판독형 (저장) 매체의 추가 예로는, 기록 가능한 유형의 매체, 가령, 휘발성 및 비-휘발성 메모리 장치, 플로피 및 그 밖의 다른 탈착식 디스크, 하드 디스크 드라이브, 광학 디스크(가령, CD ROMS(Compact Disk Read-Only Memory), DVD(Digital Versatile Disk) 등) 등, 전송 유형 매체(가령, 디지털 및 아날로그 통신 링크) 등이 있다(그러나 이에 국한되지 않음).

문맥상 명백하게 그렇지 않다고 언급하지 않는 한, 상세한 설명과 청구범위에서, "~를 포함하다", "~를 포함하는" 및 이와 유사한 용어는, 폐쇄형이 아닌 개방형으로 사용되는데, 즉, "~를 포함하지만, ~에 국한되는 것은 아니다"의 의미로 사용된다. 본원에서 사용될 때 "연결된", "결합된", 또는 이들의 임의의 변형형태는 둘 이상의 요소 간의 직접 또는 간접적 임의의 연결 또는 결합을 의미하며, 요소들 간의 연결의 결합은 물리적, 논리적, 또는 이 둘의 조합일 수 있다. 덧붙이자면, "여기서", "상기의", "하기의" 등의 단어가 본 명세서에서 사용될 때, 이 출원을 전체적으로 지칭하는 것이며 이 출원의 임의의 특정 부분을 지칭하는 것이 아니다. 문맥이 허용하는 한, 단수형 또는 복수형을 이용한 상기의 상세한 설명의 기재는 각각, 복수형 또는 단수형도 포함할 수 있다. 둘 이상의 아이템의 리스트를 참조할 때 단어 "또는"은, 리스트의 아이템들 중 임의의 것, 또는 리스트의 모든 아이템들, 또는 리스트의 아이템들 중 임의의 조합을 커버한다.

본원의 실시예에 대한 상기의 상세한 설명은 상기의 개시된 형태로의 한정을 의미하는 것이 아니다. 본원의 특정 실시예, 및 그 예시가 앞서, 설명을 목적으로 기재되었지만, 해당 분야의 통상의 기술자가 인식할 다양한 동등한 수정예가 본원의 범위 내에서 가능하다. 예를 들어, 프로세스 또는 블록이 지정된 순서로 제공되지만, 대안적 실시예가 단계들을 갖는 루틴을 수행하거나, 블록을 갖는 시스템을 상이한 순서로 이용할 수 있고, 일부 프로세스 또는 블록은 삭제, 이동, 추가, 분할, 결합, 및/또는 수정되어, 대안예 또는 서브-조합을 제공할 수 있다. 이들 프로세스 또는 블록 각각은 다양한 서로 다른 방식으로 구현될 수 있다. 또한, 프로세스 또는 블록이 순차적으로 수행되는 것처럼 보이지만, 이들 프로세스 또는 블록은 병렬로 수행되거나, 서로 다른 시점에서 수행될 수 있다. 덧붙이자면, 본원에서 언급된 임의의 특정 숫자는 예에 불과하며, 대안적 구현예가 다른 값 또는 범위를 이용할 수 있다.

본원에서 제공되는 설명은, 앞서 기재된 시스템외에 다른 시스템에도 적용될 수 있다. 상기에서 기재된 다양한 실시예의 요소 및 동작은 조합되어, 추가 실시예를 제공할 수 있다.

첨부된 출원서에 나열될 수 있는 앞서 언급된 임의의 특허 및 출원과 그 밖의 다른 인용문헌은 본원에서 참조로서 포함된다. 필요에 따라, 앞서 기재된 다양한 참조문헌의 시스템, 기능, 및 개념을 이용하기 위해, 본원의 양태는 수정되어, 본 발명의 또 다른 실시예를 제공할 수 있다.

상기의 상세한 설명을 고려하여 이러한 변경과 그 밖의 다른 변경이 본 발명에 적용될 수 있다. 상기에서 본 발명의 특정 실시예를 기재하고, 고려될 수 있는 가장 최적 모드를 기재하지만, 앞서 상세히 나타나더라도, 본 발명의 사상은 다양한 방식으로 실시될 수 있다. 시스템의 구현 세부사항은 본 발명의 범위 내에서 상당히 달라질 수 있다. 앞서 언급된 바와 같이, 본 발명의 특징 또는 양태를 기재할 때 사용되는 특정 용어는, 용어가 상기 용어와 관련되는 본 발명의 임의의 특정 특성, 특징, 또는 양태로 제한되는 것으로 재정의되는 것을 의미하지 않아야 한다. 일반적으로, 앞서 언급된 상세한 설명 섹션이 이러한 용어를 명시적으로 정의하지 않는 한, 다음의 청구범위에서 사용되는 용어는 본 발명을 상세한 설명에서 개시된 특정 실시예로 한정하도록 구성되지 않는다. 따라서 본 발명의 실제 범위는 본원에 기재된 실시예만 아니라, 특허청구범위에 따라 실시 또는 구현되는 모든 동치예까지 포함한다.

본 발명의 특정 양태가 특정 청구항의 형태로 이하에서 제공되지만, 발명자는 본 발명의 다양한 양태를 임의의 개수의 청구항 형태로 고려한다. 예를 들어, 본 발명의 단 하나의 양태는 35 U.S.C. §112, ¶6에 따르는 기능식 청구항(means-plus function claim)으로서 구현되고, 그 밖의 다른 양태는 이와 유사하게 기능식 청구항 또는 그 밖의 다른 형태, 가령, 컴퓨터-판독형 매체로서 구현될 수 있다. (35 U.S.C. §112, ¶6에 따라 취급되는 임의의 청구항은, "~하기 위한 수단"이라는 단어로 시작할 것이다.) 따라서 출원인은 출원 후에 본 발명의 또 다른 양태를 위한 이러한 추가 청구항 형태를 추구하기 위해 추가 청구항을 추가할 권리를 가진다.

Claims (39)

1. 무선 네트워크(wireless network)에서 모바일 장치에 의해 만들어지는 연결을 최적화하기 위해, 모바일 장치로부터의 데이터 전송(data transfer)을 정렬하기 위한 방법에 있어서, 상기 방법은
   각각의 트랜잭션이 발생할 때마다 모바일 장치와의 연결이 확립될 필요가 없도록, 무선 네트워크를 통한 전송을 위한 모바일 장치상의 모바일 클라이언트로부터의 복수의 트랜잭션으로 수신된 데이터를 일괄처리(batching)하는 단계
   를 포함하며,
   일괄처리되는 데이터는 모바일 클라이언트의 배경 데이터(background data)를 포함하고,
   모바일 장치의 백라이트(backlight)가 꺼져 있을 때 복수의 트랜잭션에 대한 데이터가 일괄처리되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 제 1 항에 있어서, 복수의 트랜잭션은 동시에 발생할 필요가 없는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
8. 제 1 항에 있어서, 데이터가 일괄처리되는 복수의 트랜잭션은, 지정되며 동적으로 조정될 수 있는 시간 윈도(time window) 내에서 발생하는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
9. 삭제
10. 삭제
11. 무선 네트워크에서 모바일 장치로부터의 데이터 전송(data transfer)을 관리하기 위한 방법에 있어서, 상기 방법은
    제 2 서비스의 폴링 간격(polling interval)을 기초로 하여, 제 1 서비스에 대한 조절된 폴링 간격(adjusted polling interval)을 생성하는 단계
    를 포함하며, 제 1 서비스와 제 2 서비스는 모바일 장치상에서 액세스되며, 개별 호스트에 의해 서비스되고,
    제 1 서비스에 대한 조절된 폴링 간격은, 모바일 장치의 백라이트(backlight)가 꺼져 있을 때, 제 1 서비스와 제 1 서비스의 모바일 장치에서의 동작으로 인해 개별 호스트로 전달되는 트래픽을 정렬하는 데 사용되는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
12. 삭제
13. 삭제
14. 제 11 항에 있어서, 조절된 폴링 간격은 제 2 장치의 폴링 간격의 인수(factor) 또는 분모(denominator)인 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
15. 제 11 항에 있어서, 제 1 서비스에 대한 조절된 폴링 간격은 제 1 서비스의 본래 폴링 간격(original polling interval)을 더 기초로 하며,
    제 1 서비스의 본래 폴링 간격과 제 2 서비스의 폴링 간격이 서로의 인수 또는 분모인 경우 상기 조절된 폴링 간격은 제 1 서비스의 본래 폴링 간격과 상이할 필요는 없는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
16. 제 11 항에 있어서, 조절된 폴링 간격은 제 2 서비스의 폴링 간격의 인수의 배수, 또는 분모의 배수인 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
17. 제 11 항에 있어서, 조절된 폴링 간격은 제 2 서비스로부터의 트래픽의 시간 중요도(time criticality)에 대한 제 1 서비스로부터의 트래픽의 시간 중요도를 기초로 더 결정되는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
18. 제 11 항에 있어서,
    조절된 폴링 간격은, 프록시 서버를 통해 제 1 서비스 및 제 2 서비스와 통신하는 모바일 장치상의 로컬 프록시에 의해 결정되며,
    프록시 서버는 제 1 서비스와 제 2 서비스의 개별 호스트들과 연결되고, 모바일 장치의 로컬 프록시와 추가로 무선 통신할 수 있고,
    로컬 프록시는 제 1 서비스의 조절된 폴링 간격을 프록시 서버로 전달하여, 개별 호스트들로부터 모바일 장치로의 트래픽을 정렬하는 데 사용되도록 하는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
19. 제 18 항에 있어서,
    제 1 서비스의 조절된 폴링 간격에 따라 모바일 장치가 폴링하는 데이터가 상기 모바일 장치로 제공되도록, 프록시 서버는, 제 1 서비스의 조절된 폴링 간격과 제 2 서비스의 폴링 간격을 기초로 하는 스케줄에 따라, 모바일 장치상의 제 1 서비스와 제 2 서비스를 서비스하는 개별 호스트로 폴링하는 단계
    를 더 포함하는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
20. 제 11 항에 있어서,
    제 1 서비스와 제 2 서비스를 서비스하는 개별 호스트들의 제 1 폴에 대해 공동 시작 시점(mutual starting point)을 선택하는 단계
    를 더 포함하는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
21. 제 11 항에 있어서, 제 1 폴에 대한 공동 시작 시점을 프록시 서버로 전달하는 단계를 더 포함하며, 공동 시작 시점은 미래의 통신 지연시간(communication delay)을 보상하기 위한 것임을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
22. 제 18 항에 있어서, 프록시 서버는 추가 모바일 장치와 무선으로 통신하고, 추가 모바일 장치상으로 추가 서비스를 서비스하는 추가 호스트로 폴링할 수 있는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
23. 무선 네트워크에서 모바일 장치로부터의 데이터 전송을 관리하기 위한 시스템에 있어서, 상기 시스템은
    모바일 장치상의 로컬 프록시
    를 포함하고,
    상기 로컬 프록시는 프록시 서버와 무선 통신할 수 있고, 상기 프록시 서버는 모바일 장치상의 제 1 서비스와 제 2 서비스의 개별 호스트들과 연결되며,
    로컬 프록시는 제 2 서비스의 폴링 간격을 기초로 하여 제 1 서비스에 대한 조절된 폴링 간격을 생성하며, 상기 조절된 폴링 간격은 제 2 서비스의 트래픽의 시간 중요도(time criticality)에 대한 제 1 서비스의 트래픽의 시간 중요도를 부분적으로 기초로 하여 결정되고,
    로컬 프록시는 조절된 폴링 간격을 프록시 서버로 전달하여, 제 1 서비스와 제 2 서비스의 모바일 장치상에서의 액세스로 인한 개별 호스트들로 전달되는 요청들을 시간 정렬하는 데, 사용되도록 하는 것을 특징으로 하는 데이터 전송을 관리하기 위한 시스템.
24. 무선 네트워크를 통해 모바일 장치로부터 데이터를 전송하도록 확립된 연결을 최적화하기 위해 데이터 전송을 정렬하기 위한 방법에 있어서, 상기 방법은
    제 1 인스턴스에서, 모바일 장치로부터 온 제 1 데이터세트를 수신하는 단계,
    제 2 인스턴스에서, 모바일 장치로부터 온 제 2 데이터세트를 수신하는 단계,
    제 1 인스턴스와 제 2 인스턴스에서 수신되는 제 1 데이터세트와 제 2 데이터세트를 무선 네트워크를 통해 전송하기 위해, 무선 네트워크에서 단일 무선 연결을 확립하는 단계
    를 포함하며,
    단일 무선 연결의 확립은, 제 2 데이터세트 또는 상기 제 2 데이터세트가 발원된 모바일 애플리케이션의 시간 중요도(time criticality)의 검출에 응답하여, 트리거(trigger)되며,
    제 1 인스턴스에서 모바일 장치의 백라이트(backlight)가 꺼져 있는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
25. 제 24 항에 있어서, 제 1 인스턴스와 제 2 인스턴스는 상이한 시점에서 발생하는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
26. 제 24 항에 있어서, 제 1 데이터세트와 제 2 데이터세트는 상이한 웹 서비스에 관한 것임을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
27. 제 24 항에 있어서, 모바일 장치가 수신자이며, 제 1 데이터세트와 제 2 데이터세트가 모바일 장치상의 상이한 모바일 애플리케이션을 통해 전송되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
28. 삭제
29. 삭제
30. 삭제
31. 무선 네트워크에서 모바일 장치에 의해 만들어진 연결을 최적화하기 위해 모바일 장치로부터의 데이터 전송(data transfer)을 정렬하기 위한 방법에 있어서, 상기 방법은
    각각의 트랜잭션이 발생할 때마다 모바일 장치와의 연결이 확립될 필요가 없도록, 무선 네트워크를 통한 전송을 위한 모바일 장치상의 모바일 클라이언트로부터의 복수의 트랜잭션으로 수신된 데이터를 일괄처리(batching)하는 단계
    를 포함하며,
    일괄처리되는 데이터는 모바일 장치의 배경(background)에서 동작 중이며,
    모바일 장치의 전경(foreground)에서 동작 중인 다른 모바일 클라이언트에 대한 전경 데이터(foreground data)는 일괄처리되지 않는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
32. 무선 네트워크에서 모바일 장치에 의해 만들어진 연결을 최적화하기 위해 모바일 장치로부터의 데이터 전송(data transfer)을 정렬하기 위한 방법에 있어서, 상기 방법은
    각각의 트랜잭션이 발생할 때마다 모바일 장치와의 연결이 확립될 필요가 없도록, 무선 네트워크를 통한 전송을 위한 모바일 장치상의 모바일 클라이언트로부터의 복수의 트랜잭션으로 수신된 데이터를 일괄처리(batching)하는 단계
    를 포함하며,
    모바일 장치가 배경 모드(background mode)일 때, 복수의 트랜잭션에 대한 데이터가 일괄처리되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
33. 무선 네트워크에서 모바일 장치에 의해 만들어진 연결을 최적화하기 위해 모바일 장치로부터의 데이터 전송(data transfer)을 정렬하기 위한 방법에 있어서, 상기 방법은
    각각의 트랜잭션이 발생할 때마다 모바일 장치와의 연결이 확립될 필요가 없도록, 무선 네트워크를 통한 전송을 위한 모바일 장치상의 모바일 클라이언트로부터의 복수의 트랜잭션으로 수신된 데이터를 일괄처리(batching)하는 단계
    를 포함하며,
    모바일 장치의 백라이트(backlight)가 꺼져 있을 때 복수의 트랜잭션에 대한 데이터가 일괄처리되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
34. 무선 네트워크에서 모바일 장치에 의해 만들어진 연결을 최적화하기 위해 모바일 장치로부터의 데이터 전송(data transfer)을 정렬하기 위한 방법에 있어서, 상기 방법은
    각각의 트랜잭션이 발생할 때마다 모바일 장치와의 연결이 확립될 필요가 없도록, 무선 네트워크를 통한 전송을 위한 모바일 장치상의 모바일 클라이언트로부터의 복수의 트랜잭션으로 수신된 데이터를 일괄처리(batching)하는 단계
    를 포함하며,
    모바일 장치로부터의 복수의 트랜잭션에서 수신된 데이터는, 모바일 장치에서의 무선 네트워크 연결의 단일 확립을 통한 단일 트랜잭션으로 전송되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
35. 무선 네트워크에서 모바일 장치에 의해 만들어진 연결을 최적화하기 위해 모바일 장치로부터의 데이터 전송(data transfer)을 정렬하기 위한 방법에 있어서, 상기 방법은
    각각의 트랜잭션이 발생할 때마다 모바일 장치와의 연결이 확립될 필요가 없도록, 무선 네트워크를 통한 전송을 위한 모바일 장치상의 모바일 클라이언트로부터의 복수의 트랜잭션으로 수신된 데이터를 일괄처리(batching)하는 단계
    를 포함하며,
    복수의 트랜잭션으로 수신된 데이터는 모바일 장치상의 상이한 클라이언트에 의해 생성되고,
    모바일 장치의 백라이트(backlight)가 꺼져 있을 때 복수의 트랜잭션에 대한 데이터가 일괄처리되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
36. 무선 네트워크에서 모바일 장치에 의해 만들어진 연결을 최적화하기 위해 모바일 장치로부터의 데이터 전송(data transfer)을 정렬하기 위한 방법에 있어서, 상기 방법은
    각각의 트랜잭션이 발생할 때마다 모바일 장치와의 연결이 확립될 필요가 없도록, 무선 네트워크를 통한 전송을 위한 모바일 장치상의 모바일 클라이언트로부터의 복수의 트랜잭션으로 수신된 데이터를 일괄처리(batching)하는 단계
    를 포함하며,
    일괄처리되는, 복수의 트랜잭션으로 수신된 데이터는 모바일 장치의 사용자가 구독하는 상이한 웹 서비스에 관한 것임을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
37. 무선 네트워크에서 모바일 장치로부터의 데이터 전송(data transfer)을 관리하기 위한 방법에 있어서, 상기 방법은
    제 2 서비스의 폴링 간격(polling interval)을 기초로 하여, 제 1 서비스에 대한 조절된 폴링 간격(adjusted polling interval)을 생성하는 단계
    를 포함하며, 제 1 서비스와 제 2 서비스는 모바일 장치상에서 액세스되며, 개별 호스트에 의해 서비스되고,
    제 1 서비스에 대한 조절된 폴링 간격은, 제 1 서비스와 제 1 서비스의 모바일 장치에서의 동작으로 인해 개별 호스트로 전달되는 트래픽을 정렬하는 데 사용되고,
    제 1 서비스와 제 2 서비스의 동작은, 제 1 서비스와 제 2 서비스가 배경(background)에서 동작 중인 때 전송되는 배경 데이터(background data)를 포함하는 것을 특징으로 하는 데이터 전송을 관리하기 위한 방법.
38. 무선 네트워크를 통해 모바일 장치로부터 데이터를 전송하도록 확립된 연결을 최적화하기 위해 데이터 전송을 정렬하기 위한 방법에 있어서, 상기 방법은
    제 1 인스턴스에서, 모바일 장치로부터 온 제 1 데이터세트를 수신하는 단계,
    제 2 인스턴스에서, 모바일 장치로부터 온 제 2 데이터세트를 수신하는 단계,
    제 1 인스턴스와 제 2 인스턴스에서 수신되는 제 1 데이터세트와 제 2 데이터세트를 무선 네트워크를 통해 전송하기 위해, 무선 네트워크에서 단일 무선 연결을 확립하는 단계
    를 포함하며,
    단일 무선 연결의 확립은, 제 2 데이터세트의 우선순위의 레벨의 검출에 응답하여, 트리거(trigger)되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.
39. 무선 네트워크를 통해 모바일 장치로부터 데이터를 전송하도록 확립된 연결을 최적화하기 위해 데이터 전송을 정렬하기 위한 방법에 있어서, 상기 방법은
    제 1 인스턴스에서, 모바일 장치로부터 온 제 1 데이터세트를 수신하는 단계,
    제 2 인스턴스에서, 모바일 장치로부터 온 제 2 데이터세트를 수신하는 단계,
    제 1 인스턴스와 제 2 인스턴스에서 수신되는 제 1 데이터세트와 제 2 데이터세트를 무선 네트워크를 통해 전송하기 위해, 무선 네트워크에서 단일 무선 연결을 확립하는 단계
    를 포함하며,
    단일 무선 연결의 확립은, 제 2 데이터세트를 발원한 모바일 애플리케이션의 우선순위의 레벨의 검출에 응답하여, 트리거(trigger)되는 것을 특징으로 하는 데이터 전송을 정렬하기 위한 방법.

Images