KR101826384B1 - 장치 보조 서비스들을 위한 서비스 설계 센터 - Google Patents

Abstract

본 기술은 네트워크 서비스 플랜 컴포넌트들의 모듈식 저장 및 제공을 포함한다. 서비스 설계 시스템의 능력들의 서브세트가 샌드박스 시스템에 부여되어, 서비스 플랜 제안들 또는 다른 제어들의 맞춤화를 가능하게 할 수 있다.

Description

장치 보조 서비스들을 위한 서비스 설계 센터{SERVICE DESIGN CENTER FOR DEVICE ASSISTED SERVICES}

오늘날, 최종 사용자 장치들(예컨대, 이동 전화, 태블릿 컴퓨터, 또는 노트북 컴퓨터)은 상호 배타적인 하나 이상의 서비스 플랜(예컨대, 문자 메시지, 음성, 또는 데이터)에 가입한 후에 액세스 네트워크를 사용하도록 허용된다. 서비스 플랜들은 보통 선불 또는 후불이다. 사용자가 가입한 서비스 플랜들에 따라 액세스 네트워크의 사용 비용이 변화될 수 있다. 액세스 네트워크는 요청된 사용이 문자 메시지, 음성, 또는 데이터의 상호 배타적인 범주들을 위한 것인지 판단한다. 적절한 서비스 플랜이 결정되면, 액세스 네트워크는 서비스 플랜의 정책을 사용하여 사용 비용을 결정할 수 있다. 그러나, 사용자는 이러한 상호 배타적인 3개의 범주들 각각으로부터 하나의 서비스 플랜을 선택하는데 제한되며, 그에 따라 사용자는 액세스 네트워크를 어떻게 사용하기를 원하는지 선택하는데 제한된다. 예컨대, 사용자는 다양한 데이터 서비스들을 위한 다수의 데이터 플랜들을 선택하여, 최종 사용자 장치의 액세스 네트워크 사용을 맞춤화(customize)할 수 없다.

특정한 서비스 플랜을 실시하기 위한 액세스 네트워크의 구성 역시 매우 어렵다. 예컨대, 데이터 서비스들을 위한 서비스 플랜을 생성하기 위해, 액세스 네트워크를 동작시키는 캐리어의 직원들이 플랜의 기본 속성들(예컨대, MB에 의해 과금되는지 또는 무제한인지 여부)과 플랜의 비용을 논의할 것이다. 이후, 직원은 특정한 데이터 플랜에 가입한 최종 사용자 장치들을 위해 액세스 네트워크의 사용을 추적하기 위한 정책을 (예컨대, 네트워크 장치가 선택된 경우) 네트워크 장치에 입력할 것이다. 직원은 또한 데이터 플랜에 가입한 최종 사용자 장치들이 액세스 네트워크를 사용할 수 있게 하기 위한 정책을 다른 네트워크 장치에 입력한다. 이러한 번거로운 프로세스로 인해, 서비스 플랜의 설계가 경직되고, 시간 소모적이며, 에러에 취약하고, 그로 인해 완성되어 사용자들이 데이터 서비스들을 위한 데이터 플랜의 선택을 시작하는 데에 오랜 시간이 걸린다.

경향들과 사안들의 전술한 예들은 예시적이도록 그리고 배타적이지 않도록 의도된 것이다. 당해 기술분야의 다른 제한들이 본 명세서의 숙독 및 도면들의 검토 시에 관련 기술분야의 숙련자들에게 명백해질 것이다.

도 1은 액세스 네트워크와 네트워크 서비스 플랜 제공 시스템을 포함하는 시스템의 일례를 도시한다.
도 2는 서비스 플랜 설계 및 제공을 이해하는 데에 유용한 계층 구조의 일례의 개념도를 도시한다.
도 3은 서비스 설계 시스템의 특정한 실시예의 화면 캡쳐들을 도시한다.
도 4는 가입자 그룹들을 생성하기 위한 방법의 일례의 흐름도를 도시한다.
도 5는 서비스 플랜 컴포넌트들을 생성하기 위한 방법의 일례의 흐름도를 도시한다.
도 6은 서비스 플랜 컴포넌트들로부터 서비스 플랜들을 생성하기 위한 방법의 일례의 흐름도를 도시한다.
도 7은 가입자 그룹들과 서비스 플랜들로부터 서비스 플랜 카탈로그들을 생성하기 위한 방법의 일례의 흐름도를 도시한다.
도 8은 액세스 네트워크와 네트워크 서비스 플랜 제공 샌드박스 시스템을 포함하는 시스템의 일례를 도시한다.
도 9는 서비스 설계 시스템 샌드박스 실시예의 일례의 개념도를 도시한다.
도 10은 서비스 설계 시스템 샌드박스 실시예의 일례의 개념도를 도시한다.
도 11은 본 명세서에 설명된 기법들이 실시될 수 있는 컴퓨터 시스템의 일례를 도시한다.

도 1은 액세스 네트워크(102)와 네트워크 서비스 플랜 제공 시스템(104)을 포함하는 시스템(100)의 일례를 도시한다. 도 1의 예에서, 액세스 네트워크(102)는 네트워크 서비스 플랜 제공 시스템(104)으로부터 플랜 정책들을 시행하기 위한 네트워크 요소 제공 명령어들을 수신한다. 특정한 실시예에서, 네트워크 서비스 플랜 제공 시스템(104)은 액세스 네트워크로부터 서비스 플랜 선택 데이터를 수신하고, 선택에 기반하여 새로운 명령어들을 제공할 수 있다.

액세스 네트워크(102)는 장치에 새로운 서비스들을 제공할 수 있는 네트워크를 포함할 수 있다. 액세스 네트워크(102)는 무선 네트워크(예컨대, WiFi, 셀룰러, 또는 다른 무선 기술) 및/또는 유선 네트워크(예컨대, LAN 또는 DSL)를 포함할 수 있다. 무선 또는 유선 장치들이 관련된 연관, 인증, 및/또는 장치들로 하여금 적용 가능한 주지의 또는 편리한 기법들에 따라 액세스 네트워크(102) 상에 제안된 서비스들을 획득하게 할 수 있는 다른 절차들을 완료한 경우, 무선 또는 유선 장치들은 액세스 네트워크(102) "상에" 있는 것으로 참조될 수 있다. 유리하게는, 장치들은 본 명세서에 설명된 기법들에 따라 네트워크 서비스 플랜 제공 시스템(104)에 의해 제공된 인터-네트워크(inter-network) 정책들을 가질 수 있다. 본 명세서에 사용된 바와 같이, 인터-네트워크 정책들이라는 용어는 장치가 (예컨대, 로밍에 의해) 하나의 네트워크로부터 다른 네트워크로 이동한 후 유효하게 유지되는 트래픽 제어, 과금, 및 통지 정책들을 가리킨다. 다른 한편으로, 인트라-네트워크(intra-network) 정책들은 네트워크의 경계에 제한되는 제어 트래픽의 제어를 가리킨다(예컨대, 인-네트워크 트래픽 제어, 과금, 및/또는 통지 정책들, 그리고 다른 네트워크로의 로밍을 허용 또는 금지하는 임의적 트래픽 제어 정책).

액세스 네트워크(102)를 다른 네트워크에 연결하는 것이 바람직할 가능성이 높다. 네트워크들은 컴퓨터 네트워크 숙련자들에게 잘 알려진 기업 사설망들과 가상 사설망들(사설망으로 총칭함)을 포함할 수 있다. 명칭에서 알 수 있듯이, 사설망들은 대중에게 개방된 것이 아니라 개체(entity)의 제어 하에 있다. 사설망들은 본사와 임의적 지사들(사무실로 총칭함)을 포함한다. 많은 사무실들은 원격 사용자들이 인터넷, 공중 전화 교환망(PSTN) 등과 같은 다른 네트워크를 통해 사설망에 연결될 수 있게 한다. 본 명세서에 사용된 바와 같이, 사설망은 단일 개체 또는 개체들의 계층의 제어 하에 있는 네트워크를 의미하도록 의도된다. 이는 통상적으로 셀룰러 네트워크, 무선 인프라 네트워크, 회사 LAN과 WAN 등의 경우에 해당된다.

도 1의 예에서, 액세스 네트워크(102)와 네트워크 서비스 플랜 제공 시스템(104)은 동일한 사설망에 있을 수도 있고, 그렇지 않을 수도 있으며, 또는 제1 개체가 액세스 네트워크(102)의 일부를 소유 또는 제어할 수 있고, 제2 개체가 네트워크 서비스 플랜 제공 시스템(104)뿐만 아니라 액세스 네트워크(102)의 일부를 소유 또는 제어할 수 있다. 예컨대, 캐리어가 네트워크 서비스 플랜 제공 시스템(104)을 포함할 수 있지만, 액세스 네트워크(102)는 지역 사업 개체가 소유한 WiFi 네트워크를 포함할 수 있다. 유리하게는, 특정한 실시예에서, 가입자가 액세스 네트워크(102) 상에 있는 동안, 캐리어는 계속 정책 제어를 제공할 수 있다. 본 예에서 액세스 네트워크(102)가 캐리어의 셀룰러 네트워크를 포함하는 경우, 훨씬 더 큰 정책 제어가 가능할 수 있다.

가입자는 액세스 네트워크(102) 상의 모든 적용 가능한 장치를 포함하도록 광범위하게 정의될 수 있음을 주목해야 한다. 예컨대, 액세스 네트워크(102)는 스마트폰들과 사람들이 빈번히 사용하는 다른 장치들뿐만 아니라, 주차요금 징수 장치들, 식품 판매기들, 및 자동차 탑재 컴퓨터들을 포함할 수 있다.

도 1의 예에서, 네트워크 서비스 플랜 제공 시스템(104)은 서비스 설계 엔진(106), 서비스 플랜 데이터스토어(108), 임의적 정책 시행 우선순위 규칙 데이터스토어(110), 시행 요소 제공 명령어 해석 엔진(112), 네트워크 제공 명령어 세트(114), 네트워크 요소 제공 엔진(116), 및 분석 엔진(118), 이력 데이터스토어(120), 및 서비스 플랜 선택 엔진(122)을 포함한다.

서비스 설계 엔진(106)은 서비스 플랜 데이터스토어(108)에 서비스 플랜 데이터 구조들 및 이후 보다 상세히 설명되는 다른 관련 데이터를 입력한다. 본 명세서에 설명된 바와 같이, 엔진들은 프로세서에 연결된 컴퓨터-판독 가능한 매체를 가리킨다. 컴퓨터-판독 가능한 매체는 실행 가능한 파일들을 포함하는 데이터를 가지며, 이를 사용하여 프로세서가 데이터를 변형시키고, 새로운 데이터를 생성할 수 있다. 엔진은 전용 또는 공유 프로세서, 및 프로세서에 의해 실행되는 펌웨어 또는 소프트웨어 모듈들을 통상적으로 포함할 수 있다. 실시-특정 또는 다른 고려사항들에 따라, 엔진이 중앙화 또는 기능 분산될 수 있다. 엔진은 프로세서에 의해 실행되기 위해 컴퓨터-판독 가능한 매체 내에 구현된 특수목적 하드웨어, 펌웨어, 또는 소프트웨어를 포함할 수 있다. 본 명세서에 사용된 바와 같이, 컴퓨터-판독 가능한 매체는 제정법에 따르는 (예컨대, 미국 내에서 35 U.S.C. 101 하의) 모든 매체들을 포함하도록 의도되며, 유효한 컴퓨터-판독 가능한 매체를 포함하는 청구항을 위해 배제되어야 할 정도로 완전히 제정법에 따르지 않는 모든 매체들을 명확하게 배제하도록 의도된다. 제정법에 따르는 주지의 컴퓨터-판독 가능한 매체들은 하드웨어(몇 가지만 말하자면, 예컨대 레지스터, 랜덤 액세스 메모리(RAM), 비휘발성(NV) 저장 장치)를 포함하지만, 하드웨어에 제한될 수도 있고, 그렇지 않을 수도 있다.

본 명세서에 설명된 바와 같이, 데이터스토어들은 예컨대 범용 또는 특수목적 기계 상의 물리적 컴퓨터-판독 가능한 매체, 펌웨어, 하드웨어, 이들의 조합, 또는 적용 가능한 주지의 또는 편리한 장치 또는 시스템 내에 구현된 소프트웨어로서 실시될 수 있다. 본 명세서의 데이터스토어들은 표들, 콤마구분식(CSV) 파일들, 전통적인 데이터베이스들(예컨대, SQL), 또는 다른 적용 가능한 주지의 또는 편리한 조직화된 포맷들을 포함하는 모든 적용 가능한 데이터 조직을 포함하도록 의도된다. 데이터베이스 인터페이스들과 같은 데이터스토어-연관 컴포넌트들은 데이터스토어의 "일부", 다른 시스템 컴포넌트의 일부, 또는 이들의 조합으로 고려될 수 있지만, 데이터스토어-연관 컴포넌트들의 물리적 위치 및 다른 특성들은 본 명세서에 설명된 기법들을 이해하는 데에 중요하지 않다.

서비스 플랜 데이터스토어(108)는 서비스 플랜 데이터 구조들을 저장할 수 있다. 본 명세서에 설명된 바와 같이, 데이터 구조는 데이터가 소정의 문맥 내에서 효율적으로 사용될 수 있도록 데이터를 컴퓨터에 저장 및 조직화하는 특별한 방식과 연관된다. 데이터 구조들은 일반적으로 메모리 내의 임의의 장소에서 데이터를 인출 및 저장하는 컴퓨터의 능력에 기반하며, 어드레스, 즉 그 자체가 메모리에 저장될 수 있고 프로그램에 의해 조작될 수 있는 비트 스트링에 의해 명시된다. 그러므로, 몇몇 데이터 구조들은 산술 연산들로 데이터 항목들의 어드레스들을 산정하는 과정에 기반한다; 반면 다른 데이터 구조들은 구조 그 자체 내에 데이터 항목들의 어드레스들을 저장하는 과정에 기반한다. 다수의 데이터 구조들은 종종 비자명한(non-trivial) 방식으로 결합되는 두 원리를 사용한다. 데이터 구조의 실시는 보통 이 구조의 인스턴스들을 생성 및 조작하는 절차들의 세트를 기입하는 과정을 수반한다.

서비스 플랜 데이터스토어(108)가 데이터베이스로서 실시되는 시스템의 일례에서, 데이터베이스 관리 시스템(DBMS)이 서비스 플랜 데이터스토어(108)를 관리하기 위해 사용될 수 있다. 이러한 경우, DBMS는 서비스 플랜 데이터스토어(108)의 일부로, 또는 서비스 설계 엔진(106) 및/또는 시행 요소 제공 명령어 해석 엔진(112)의 일부로, 또는 별개의 기능 유닛(미도시)으로 여겨질 수 있다. DBMS는 통상적으로 데이터베이스 내의 데이터의 조직화, 저장, 관리, 및 검색을 제어하는 엔진으로서 실시된다. DBMS들은 종종 질의, 백업, 및 복사 능력을 제공하고, 규칙들을 시행하며, 보안을 제공하고, 산정을 수행하며, 변경 및 액세스 내역 관리(access logging)를 수행하고, 최적화를 자동화한다. 몇 가지만 말하자면, DBMS들의 예로는, 알파 파이브(Alpha Five), 데이터이즈(DataEase), 오라클 데이터베이스(Oracle database), IBM DB2, 적응형 서버 엔터프라이즈(Adaptive Server Enterprise), 파일메이커(FileMaker), 파일버드(Firebird), 잉그레스(Ingres), 인포믹스(Informix), 마크 로직(Mark Logic), 마이크로소프트 액세스(Microsoft Access), 인터시스템즈 캐시(InterSystems Cache), 마이크로소프트 SQL 서버(Microsoft SQL Server), 마이크로소프트 비주얼 폭스프로(Microsoft Visual FoxPro), MonetDB, MySQL, PostgreSQL, 프로그레스(Progress), SQLite, 테라데이터(Teradata), CSQL, 오픈링크 버추소(OpenLink Virtuoso), 대포딜 DB(Daffodil DB), 및 OpenOffice.org Base가 포함된다.

데이터베이스 서버들은 DBMS 및 관련 엔진들뿐만 아니라 데이터베이스들을 저장할 수 있다. 본 명세서에 설명된 데이터스토어들 중 임의의 데이터스토어가 아마도 데이터베이스 서버들로서 실시될 수 있을 것이다. 데이터베이스 내에 데이터의 2가지 논리 뷰, 논리(외부) 뷰와 물리(내부) 뷰가 있다는 것을 주목해야 한다. 본 명세서에서, 논리 뷰는 일반적으로 리포트 내에서 발견되는 데이터로 간주되는 반면, 물리 뷰는 특정하게 프로그래밍된 프로세서에 사용 가능하며 물리적 저장 매체 내에 저장되는 데이터이다. 대부분의 DBMS 실시예들에 의하면, 동일한 데이터에 대해 거의 무한수의 논리 뷰들과 하나의 물리 뷰가 있다.

DBMS는 통상적으로 모델링 언어, 데이터 구조, 데이터베이스 질의 언어, 및 거래 메커니즘을 포함한다. 모델링 언어를 사용하여, 계층 모델, 네트워크 모델, 관계 모델, 객체 모델, 또는 다른 적용 가능한 주지의 또는 편리한 조직을 포함할 수 있는 데이터베이스 모델에 따라 DBMS 내에 각각의 데이터베이스의 스키마(schema)를 정의한다. 최적의 구조는 응용 요건들(예컨대, 속도, 신뢰성, 유지 가능성, 확장성, 및 비용)에 따라 변화될 수 있다. 오늘날 사용 중인 더 일반적인 모델들 중 하나는 SQL 내에 삽입된 애드혹 모델이다. 데이터 구조들은 필드들, 기록들, 파일들, 객체들, 및 데이터를 저장하기 위한 다른 적용 가능한 주지의 또는 편리한 구조들을 포함할 수 있다. 데이터베이스 질의 언어는 사용자들이 데이터베이스들에 질의하는 것을 가능하게 할 수 있고, 비승인 액세스를 방지하기 위해 보안 메커니즘들과 리포트 작성자들을 포함할 수 있다. 데이터베이스 거래 메커니즘은 이상적으로는 고장 내성(fault tolerance)으로 동시다발적인 사용자 액세스 동안에도 데이터 무결성을 보장한다. DBMS들 역시 메타데이터 저장소를 포함할 수 있고; 메타데이터는 다른 데이터들을 묘사하는 데이터이다.

특정한 실시예에서, 서비스 설계 엔진(106)은 정책 시행 우선순위 규칙 데이터스토어(110) 내에서 정책 시행 우선순위 규칙 데이터 구조들을 입력한다. 본 명세서에 설명된 정책 제어의 양상은 서비스 플랜의 제1 트래픽 분류 필터를 서비스 플랜의 제2 트래픽 분류 필터 상에 중첩시키는 과정을 수반한다. 이러한 중첩을 달성하는 2가지 이상의 방식이 있는데, 예컨대 제1 트래픽 분류 필터가 제2 트래픽 분류 필터보다 먼저 트래픽 이벤트에 적용되도록 제1 및 제2 트래픽 분류 필터를 순서화하는 방식, 제2 트래픽 분류 필터가 매칭될 때까지 제1 트래픽 분류 필터의 매칭상대를 커널 내에 가두는 방식(이후, 액션 리스트의 제1 관련 액션을 적용한다), 또는 명시적 정책 시행 우선순위 규칙을 적용하는 방식을 포함한다. 내포적 정책 시행 우선순위들이 사용될 수 있기 때문에, 정책 시행 우선순위 규칙 데이터스토어(110)는 임의적이다. 명시적 정책 시행 우선순위들이 실시- 및/또는 구성-특정 매개변수들에 따라 좌우될 수 있거나, 또는 내포적 및 명시적 정책 시행 우선순위들의 조합이 사용될 수 있다는 것을 주목해야 한다. 특정한 실시예에서, 명시적 우선순위들은 내포적 우선순위들에 우선한다(예컨대, 순서화).

도 1의 예에서, 시행 요소 제공 명령어 해석 엔진(112)은 서비스 플랜 데이터스토어(108)의 서비스 플랜 데이터 구조들을, 네트워크 제공 명령어 세트 데이터스토어(114)에 저장되는 각각의 네트워크 제공 명령어 세트 데이터 구조들로 변환한다. 해석 엔진(112)은 또한, 적용 가능하다면, 정책 시행 우선순위 규칙 데이터스토어(110)로부터의 관련 정책 시행 우선순위 규칙 데이터 구조들을 네트워크 제공 명령어 세트 데이터 구조들 내에 포함되도록 변환한다.

도 1의 예에서, 네트워크 요소 제공 엔진(116)은 액세스 네트워크(102)에 플랜 정책들을 시행하기 위한 네트워크 요소 제공 명령어들을 제공한다. 네트워크 요소 제공 명령어들은 현재 액세스 네트워크(102) 상에 있을 수도 있고 그렇지 않을 수도 있는 하나 이상의 장치에 적용 가능하다. 특정한 실시예에서는, 적용 가능한 하나 이상의 장치가 액세스 네트워크(102) 상에 있을 때에만, 네트워크 요소 제공 명령어들이 액세스 네트워크(102)로 전송된다.

도 1의 예에서, 분석 엔진(118)은 액세스 네트워크(102)로부터 가입자 피드백 또는 명령어들을 포함할 수 있는 데이터를 수신한다. 이러한 예를 위해, 데이터는 서비스 플랜 선택 엔진(122)에 의해 사용되는 서비스 플랜 선택 데이터를 포함하는 것으로 가정된다. 분석 엔진(118)은 네트워크 서비스 플랜 제공 시스템(104)에 유용한 방식으로 데이터를 수정할 수 있고, 이는 액세스 네트워크(102)로부터의 피드백 또는 명령어들에 기반하여 액션들을 유발하는 과정을 포함할 수 있다. 데이터는 서비스 설계 엔진(106)에 의해 사용될 수 있는 이력 데이터스토어(120)에 저장될 수 있다. 예컨대, 서비스 설계 엔진(106)은 (예컨대, 네트워크 상태에 기반하여) 더 많거나 더 적은 데이터를 장치로부터 요청해야 하는지 여부를 명시하고, 계수 또는 다른 통지를 감소시킬지 여부를 판단하며, 분류들 내에 기록되어야 하는 매개변수들을 명시하는 등을 할 수 있다.

네트워크 상태는 네트워크 혼잡 상태(또는 반대로 네트워크 유효 상태)와 연관될 수 있다. 네트워크 유효 상태는 예컨대 네트워크의 세그먼트(예컨대, 무선 네트워크의 최종 에지 요소)의 유효성/용량의 상태 또는 측정값을 포함할 수 있다. 네트워크 혼잡 상태는 예컨대 네트워크의 세그먼트(예컨대, 무선 네트워크의 최종 에지 요소)의 네트워크 사용 레벨 또는 네트워크 정체의 상태 또는 측정값을 포함할 수 있다. 몇몇 구현예들에서, 네트워크 유효 상태와 네트워크 혼잡 상태는 반비례 측정값일 수 있다. 소정의 구현예들과 관련하여 본원에 사용된 바와 같이, 네트워크 유효 상태와 네트워크 혼잡 상태는 예컨대 설계 선택에 기반하여 교환 가능하게 사용될 수 있다(예컨대, 네트워크 혼잡 상태 또는 네트워크 유효 상태에 기반하여 배경 정책들을 배정하도록 설계하면 유사한 결과를 가져오지만, 이들은 네트워크 성능 및/또는 용량 및/또는 정체를 특징짓는 상이한 방식들이다). 몇몇 구현예들에서, 네트워크 유효 상태와 네트워크 혼잡 상태는 네트워크 사용 활동들에 기반하여(예컨대, 시각, 유효성/용량 레벨, 정체 레벨, 및/또는 성능 레벨에 기반하여) 변경되기 때문에, 이러한 상태들은 동적 측정값들이다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동의 차동 네트워크 서비스 사용 제어가 네트워크 혼잡 상태 또는 네트워크 유효 상태에 기반한다. 특정한 실시예에서, 4가지 레벨의 네트워크 혼잡 상태들(비혼잡, 약간 혼잡, 중간 혼잡, 심한 혼잡)이 있다.

도 1의 예에서, 서비스 플랜 선택 엔진(122)은 분석 엔진(118)으로부터 서비스 플랜 선택 데이터를 수신한다. 서비스 플랜 선택 데이터는 액세스 네트워크(102) 상의 장치로부터, 액세스 네트워크(102)로부터, 또는 이들의 조합으로부터 유래될 수 있다. 특정한 실시예에서, 서비스 플랜 선택 데이터는 사용자에 의해 장치에 입력되고, 액세스 네트워크(102)를 통해 서비스 플랜 선택 엔진(122)으로 전달될 수 있다.

서비스 플랜 선택 데이터의 수신 시에, 서비스 플랜 선택 엔진(122)은 적절하다면 전술한 방식으로 액세스 네트워크(102)에 제공하기 위해 네트워크 제공 명령어 세트(114) 내에서 새로운 네트워크 제공 명령어 세트를 선택할 수 있다. (서비스 플랜 선택 엔진(122)은 서비스 설계 엔진(106)이 서비스 플랜을 수정하도록 유발할 수 있거나, 그렇지 않을 수 있고, 서비스 플랜은 서비스 플랜 선택 엔진(122)에 의해 선택되기 위해 네트워크 제공 명령어 세트로 해석된다.)

도 2는 서비스 플랜 설계 및 제공을 이해하는 데에 유용한 계층 구조의 일례의 개념도(200)를 도시한다. 개념도(200)는 서비스 플랜들과 연관된 데이터스토어들의 집합(202), 가입자들과 연관된 데이터스토어들의 집합(204), 플랜 카탈로그 데이터스토어(206), 및 서비스 설계 엔진(208)을 포함한다.

데이터스토어들의 집합(202)은 필터 데이터스토어(210), 컴포넌트 데이터스토어(212), 플랜 데이터스토어(214), 규칙 데이터스토어(218), 트래픽 제어 정책 데이터 구조(220), 과금 데이터 구조(222), 및 통지 데이터 구조(224)를 포함한다. 필터 데이터스토어(210)는 예컨대, 사용 시에, 매칭된 트래픽 이벤트를 허용, 차단, 감속(throttle), (정해진 기간 동안) 지연, 및 (이벤트까지) 연기하는 트래픽 제어 필터 데이터 구조들을 포함할 수 있다. 필터가 맵핑되는 트래픽 이벤트의 양상들은, 몇 가지만 말하자면, 예컨대 원격 지정별, 애플리케이션별, 컨텐츠별(예컨대, 스트리밍과 같은 일반적인 컨텐츠, 규칙적 표현들을 사용하여 식별 가능한 특정한 컨텐츠 등), 프로토콜별, 포트별, 타겟 동작 시스템별을 포함할 수 있다. 서비스 설계의 맥락에서, 트래픽 제어 필터를 액션과 결합시키는 설계자 필터 패키지들을 제안하는 것이 편리하다고 판명되었다. 이러한 액션들은 통지하기(통지가 통지 수신지로 전송되도록 유발한다), 캡핑하기(cap)(계수를 증가시킨다), 가두기(다른 필터가 이후 매칭되는지 확인하기 위해 커넬 레벨에 매칭상대를 가둔다), 및 명령어들(다른 명령어가 실행될 수 있게 한다)을 포함할 수 있다.

컴포넌트 데이터스토어(212)는 예컨대 적어도 하나의 필터를 포함하는 필터 패키지들의 세트와 정책들의 세트를 포함할 수 있다. 컴포넌트들이 정책을 계승할 수 있기 때문에, 컴포넌트가 적어도 하나의 정책을 포함하는 것은 명시적 요건이 아니다. 그러나, 컴포넌트가 서비스 플랜 제안 내에 조립되면, 컴포넌트는 정책들의 세트 내의 정책을 가지거나, 정책을 계승할 것이다.

플랜 데이터스토어(214)는 예컨대 컴포넌트들의 계층을 포함할 수 있다. 컴포넌트들은 예컨대 캐리어, 네트워크 보안, 애플리케이션(유료 또는 후원), 인터셉터(마켓팅 인터셉터 또는 부모 통제), 벌크, 포스트-벌크(post-bulk), 및 수명 종료(end-of-life)를 포함할 수 있는 등급들로 조직화된다. 적어도 하나의 실시예에서, 수명 종료 등급은 컴포넌트 데이터스토어(212)에 저장된 컴포넌트가 아닌 디폴트에 의해 처리된다.

규칙 데이터스토어(218)는 정책 규칙들을 포함한다. 예시를 위해, 3가지 정책 유형 데이터 구조들(트래픽 제어 정책 데이터 구조(220), 과금 정책 데이터 구조(222), 및 통지 정책 데이터 구조(224))이 규칙 데이터스토어(218)를 향해 유도되는 것으로 도시된다. 트래픽 제어 정책 데이터 구조(220)는 허용 또는 차단과 같이 트래픽의 흐름을 제어하도록 그리고 캡-앤-매치(cap-and-match)와 같이 트래픽 제어와 연관된 소정의 액션들을 취하도록 설계된 다양한 필터 패키지들을 포함할 수 있다. 과금 정책 데이터 구조(222)는 사용자 또는 (네트워크 서비스 사용을 후원할 수 있는) 후원자에게 유도될 수 있고, 과금 코드를 포함할 수 있다.

통지 정책 데이터 구조(224)는 사용자, 후원자, 또는 통지 내의 변수들 또는 일정한 매개변수들에 따라 추가 액션을 취하는 엔진으로 유도될 수 있고, 통지의 타겟에 의해 사용되기 위한 컨텐츠와 트리거(예컨대, 관련 명령어들의 실행을 야기하는 선택 가능한 버튼)를 포함할 수 있다. 통지 유형들은 플랜 제한 임계값들(플랜이 과금 정책 캡의 명시된 %에 도달했다), 플랜 캡 제한(과금 정책 캡에 도달했기 때문에 요청된 네트워크 활동이 캡핑되었다), 플랜 제한 오버리지(overage)(오버리지가 명시된 %에 도달하였다; 오버리지의 옵션을 제안, 새로운 서비스 플랜, 진행 중인 사용의 차단), 플랜 만료(플랜이 만료되었다; 새로운 플랜을 구입하는 옵션을 제안), 활동 차단 이벤트(필터에 의한 활동 차단 또는 활동 상태 변화), 가능하지 않은 플랜(플랜은 요청된 네트워크 활동이 차단된 경우 지원하지 않는다), 마케팅 인터셉터(현재 활동 또는 상태에 기반한 특정한 메시지 또는 제안), 프로모션 메시지(플랜이 제공하는 것에 대한 개요), 업셀 제안(현재 사용에 기반한 업셀 티어 플랜(upsell tiered plan)을 포함한다. 통지 액션들이 통지들에 추가되어, 통지들을 "액션 가능하게(actionable)" 만들 수 있고, 이는 통지의 수신자가 통지에 응답하여 피드백 또는 명령어를 제공할 수 있다는 것을 의미한다. 통지 액션들은 예컨대 OK/거부, 취소, 승인, 구입(구입 워크플로우로의 링크), 더 많은 정보(예컨대, 트래픽 이벤트가 차단된 이유에 관한 더 많은 정보, 트래픽 활동 변경 또는 서비스 플랜 구매를 위한 제안), 뒤로(이전 워크플로우 화면을 호출), 앞으로(다음 워크플로우 화면을 호출), 런칭(URL 또는 애플리케이션을 런칭)을 포함할 수 있다. 통지 맞춤화는 전경(foreground), 배경(background), 전경/배경(활동이 전경에 있으면 전경에, 배경에 있으면 배경에 표시), 타이틀, 서브타이틀, 텍스트, 아이콘, 버튼들/액션들, "다시 보이지 않음(명시된 시간 동안 다시 보이지 않을 것이다)", 디폴트 타겟 버튼(디폴트 응답 액션을 명시) 등을 포함할 수 있다.

가입자들과 연관된 데이터스토어들의 집합(204)은 가입자 데이터스토어(226)와 가입자 그룹 데이터스토어(228)를 포함한다. 가입자 데이터스토어(226)는 가입자들에 관한 정보를 포함하는 가입자 데이터 구조들을 포함한다. 최소 가입자 데이터 구조는 적어도, 시스템(200) 내에서 고유하거나 또는 국제 모바일 가입자 식별번호(International Mobile Subscriber Identity, IMSI)와 같이 보편적인 가입자 ID를 포함할 가능성이 높다. 전화번호, 장치 유형, 및/또는 국제 모바일 기기 식별번호(International Mobile Equipment Identity, IMEI)와 같은 정보를 포함하는 것 역시 유용할 수 있다.

가입자 그룹 데이터스토어(228)는 가입자들의 그룹핑을 포함하는 가입자 그룹 데이터 구조들을 포함한다. 시스템 내에서 이행될 수 있는 그룹핑 유형들은 가입자에 관해 알려진 정보량에 따라 좌우된다. 예컨대, 가입자들은 장치 유형, 장치 특성, 가입자의 인구통계적 특성, 지역 등에 의해 그룹핑될 수 있다.

플랜 카탈로그 데이터스토어(206)는 네트워크 서비스 플랜들의 소비자들 또는 제공자들에게 사용 가능한 플랜 카탈로그 데이터 구조들을 포함한다. 플랜 카탈로그 데이터 구조들은 서비스 플랜들과 연관된 데이터스토어들의 집합(202) 및 가입자들과 연관된 데이터스토어들의 집합(204)으로부터의 컴포넌트들의 조합들이다.

서비스 설계 엔진(208)은 도 2의 예에 도시된 데이터스토어들을 관리할 수 있다. 서비스 설계 및/또는 제공의 양상들이 시스템(200)의 에이전트들에게 배정될 수 있다. 에이전트에게 부여된 시스템에 대한 제어량은 역할 데이터스토어(230)에 기록될 수 있는 에이전트의 역할에 기반한다. 역할들은 슈퍼 사용자, 포탈 운영자, 시스템 운영자, 또는 설계 센터의 능력들에 적용 가능한 다른 역할(예컨대, 캐리어 설계 센터 또는 기업용 샌드박스인지 여부에 따라, 애플리케이션 개발자, 컴뮤니티-기반 조직, 기프팅(gifiting) 조직, 가상 이동 통신망 사업자(Mobile Virtual Network Operator, MVNO)), 및 시스템을 사용 중인 인간 에이전트로 설정될 수 있다.

서비스 설계 엔진(208)과 같은 서비스 설계 엔진의 특정한 실시예를 위한 사용자 인터페이스의 화면 캡쳐들이 서비스 설계 엔진(208)의 일부 기능을 예시하기 위해 사용될 수 있다. 도 3은 서비스 설계 시스템의 특정한 실시예를 위한 사용자 인터페이스(UI)의 화면 캡쳐들을 도시한다.

도 3a의 예에서, 로그인에 이어, 설계자는 오픈 태스크 필드(302), 최근 활동 필드(304), 및 메뉴 버튼 필드(306)를 가진 서비스 설계 센터 UI 홈페이지로 안내된다. 오픈 태스크 필드(302)는 승인을 기다리는 초안들, 공개/전개(publication/deployment)를 기다리는 베타 테스트들, 및 완료를 목표로 하는 전개된 플랜들, 또는 다른 오픈 태스크들을 포함할 수 있다. 최근 활동 필드(304)는 설계자들에게 유용하다고 간주되는 양의 정보를 포함할 수 있다.

메뉴 버튼 필드(306)는 8개의 버튼들(가입자 버튼, 가입자 그룹 버튼, 플랜 버튼, 플랜 카탈로그 버튼, 템플릿 버튼, 리포트 버튼, 설정 버튼, 및 내 프로필 버튼)을 포함한다. 내 프로필 버튼을 선택하면, 설계자는 화면 캡쳐(300B; 도 3b)로 안내되고, 여기서 설계자는 이름, 성, 암호, 및 역할과 같은 정보를 입력할 수 있다. 역할들은 슈퍼 사용자, 포탈 운영자, 시스템 관리자, 또는 설계 센터의 능력들에 적용 가능한 다른 역할(예컨대, 캐리어 설계 센터 또는 기업용 샌드박스인지 여부에 따라, 애플리케이션 개발자, 컴뮤니티-기반 조직, 기프팅 조직, 가상 이동 통신망 사업자(MVNO), 및 시스템을 사용 중인 특정한 설계자로 설정될 수 있다.

메뉴 버튼 필드(306)의 설정 버튼을 선택하면, 설계자는 화면 캡쳐(300C; 도 3c)로 안내되고, 여기서 설계자는 탭 메뉴(308)로부터 역할 탭, 사용자 탭, 또는 사전설정 탭을 선택할 수 있다. 탭 메뉴(308)로부터 역할 탭을 선택하면, 설계자는 컴포넌트 편집자, 플랜 생성자, 플랜 그룹 공개자, 플랜 뷰어, 리포트 뷰어, 및 시스템 운영자와 같은 역할들을 추가할 수 있다. 설계자가 이 탭 안의 모든 역할을 반드시 다 볼 수 있지는 않다는 것과, 비슷한 실시예에서 설계자가 자신이 가지고 있지 않은 권한들을 가진 역할을 생성할 수는 없다는 것을 주목할 수 있다(예컨대, 시스템 운영자는 슈퍼 사용자보다 더 적은 권한들을 가질 수 있고, 포탈 운영자와는 다른 권한들을 가질 수 있다). 탭 메뉴(308)로부터 사용자 탭을 선택하면, 설계자는 사용자들을 추가 및 편집할 수 있다. 도 3d(화면 캡쳐(300D))의 예에서, 사용자 das가 선택되었고, 사용자명(이메일 주소), 이름, 성, 사용자의 인에이블 여부, 역할, 및 사용 가능한 역할과 같은 das의 세부사항들이 나타난다. 탭 메뉴(308)로부터 사전설정 탭을 선택하면, 설계자는 화면 캡쳐(300E; 도 3e)의 예에 도시된 바와 같이 디폴트 플랜 아이콘을 선택할 수 있다.

메뉴 버튼 필드(306)의 가입자 버튼을 선택하고, 신규 가입자를 선택하면, 설계자는 도 3f(화면 캡쳐(300F))로 안내된다. 특정한 실시예에서, 가입자 정보는 장치명, 가입자 그룹, 소유자명, 지역(locale), EID, 전화번호, 장치 유형, 운영체계 버전, CDMA 가입자 세부사항, 및 GSM/LTE 가입자 세부사항을 포함한다. 이러한 정보는 또한 가입자 데이터스토어에 이미 존재하는 가입자들을 위해 편집될 수 있다.

메뉴 버튼 필드(306)의 가입자 그룹 버튼을 선택하면, 설계자는 화면 캡쳐(300G; 도 3g)로 안내되고, 여기서 설계자는 특성 탭 또는 불러오기(import) 탭을 선택할 수 있다. 신규 가입자 그룹의 생성을 선택하면, 설계자는 그룹명과 설명을 입력하고, 가입자들을 그룹으로 드래그한다. 불러오기 탭을 선택하면, 설계자는 배치 동작(batch operation) 시에 가입자 데이터스토어로부터 가입자들을 불러올 수 있다. 예컨대, 도 3h(화면 캡쳐(300H))를 참조한다. 정보는 또한 가입자 데이터스토어에 이미 존재하는 가입자들을 위해 편집될 수 있다.

메뉴 버튼 필드(306)의 플랜 버튼을 선택하고 새로운 플랜을 선택하면, 설계자는 화면 캡쳐(300I; 도 3i)로 안내된다. 특정한 실시예에서, 플랜 정보는 플랜 아이콘, 플랜명, 플랜 간략 설명, 플랜 설명, 플랜 버전, 플랜 유형(예컨대, 후원, 유료, 또는 캐리어), 디폴트(is default) 체크박스, 재구매 가능(is repurchaseable) 체크박스, 청구 가격, 및 표시 가격(청구 가격이 청구 가격과 같지 않은 경우)을 포함한다. 다음 화면 캡쳐(300J; 도 3j)는 과금 정책(예컨대, 사용 데이터 또는 소요 시간, 사용 제한, 및 오버리지 허용에 기반함), 청구 정책(예컨대, 일회성 또는 반복성, 사용 보고, 및 사전 또는 사후 청구)을 포함하는, 플랜에 관한 추가 정보의 입력을 가능하게 하는 과정을 포함한다. 특정한 실시예에서는 장치 상의 정책 라벨을 보여주고 청구 식별자들을 포함하는 것이 가능하다. 과금 코드 역시 설계자에 의해 생성 또는 선택될 수 있다. 다음 화면 캡쳐(300K; 도 3k)는 새로운 컴포넌트를 생성하거나 기존의 컴포넌트를 복제함으로써 컴포넌트들을 추가하는 옵션을 포함한다. 도 3k의 예에서, 명시적 우선순위 1, 2, 3을 가진 3개의 컴포넌트들이 플랜을 위한 컴포넌트 리스트에 추가되었다. 특정한 실시예에서, 탭 메뉴(310)가 우선순위 탭, 과금&청구 탭, 컴포넌트 탭, 정책 이벤트 탭, 및 리뷰 탭을 포함할 때까지, 데이터가 플랜을 위해 입력됨에 따라, 탭 메뉴(310)의 탭들의 개수가 증가한다는 것을 주목한다.

설계자가 "Copy of No Youtube"와 같은 컴포넌트를 선택할 때, 특성 탭, 필터 탭, 및 정책 이벤트 탭을 포함하는 탭 메뉴(312)를 포함하는 컴포넌트 화면 캡쳐(300L; 도 3l)가 표시된다. (과금 정책이 컴포넌트를 위해 정의되면, 탭 메뉴(312)는 또한 과금 정책 탭을 포함할 수 있다.) 탭 메뉴(312)로부터 특성 탭을 선택하면, 설계자는 컴포넌트명, 서비스 등급(예컨대, 캐리어, 네트워크 보안, 후원, 특수 애플리케이션, 마켓 인터셉터, 부모 통제, 오픈 액세스, 및 포스트-벌크), 및 컴포넌트가 명시적으로 정의된 과금 정책을 가지는지 또는 플랜으로부터 과금 정책을 계승하는지 여부를 편집할 수 있다. 서비스 등급은 가입자가 잔여 서비스 플랜 옵션들을 가지고 있지 않은 경우에 대한 "수명 종료" 서비스 등급을 포함하도록 특징지어질 수 있지만, 특정한 실시예에서 수명 종료 설정은 서비스 등급으로서 기재되지 않는다는 것(후술함)을 주목할 수 있다.

탭 메뉴(312)로부터 필터 탭을 선택하면, 설계자는 화면 캡쳐(300M; 도 3m)으로 안내되고, 여기서 선택된 컴포넌트(본 예에서, "No Youtube" 컴포넌트)를 위해 필터들을 선택할 수 있다. 설계자가 편집할 필터를 선택할 때, 설계자는 화면 캡쳐(300N; 도 3n)으로 안내되고, 이는 필터명, 설명, 필터가 단지 연관형(associative)인지 여부, 필터가 "노매치(no-match)"인지 여부, 필터링 매개변수들(예컨대, 원격 수신지별 필터, 애플리케이션별 필터, 타겟 운영체계별 필터, 컨텐츠별 필터, 프로토콜별 필터, 포트별 필터), 및 런처 위젯 내의 표시 여부 및 표시 방법의 편집을 용이하게 한다.

탭 메뉴(312)로부터 정책 이벤트 탭을 선택하고 새로운 정책 이벤트를 생성하면, 설계자는 화면 캡쳐(300O; 도 3o)로 안내되고, 여기서 설계자는 소정의 조건들(예컨대, 캡&노매치, 캡&매치, 장치에 대한 차단, 비허용 및 매치, 비허용 및 노매치, 이 네트워크 상태에 있음, 이 네트워크 상태로 전이, 및 이 네트워크 상태로부터 전이)이 만족될 때 네트워크 상태에 기반하여 정책 이벤트들을 선택할 수 있다. 다음 화면 캡쳐(300P; 도 3p)로 진행하여, 설계자는 정책 이벤트명, 설명, 전경 또는 배경에 이벤트와 연관된 통지들을 표시할지 여부, 서비스로 통지 결과들을 전송할지 여부, 통지를 전송하는 최대 회수, 및 사용자가 향후 통지를 폐지할 수 있는지 여부와 같은 이벤트 특성들을 입력한다. 특정한 실시예에서, 탭 메뉴(314)가 정책 이벤트 탭, 특성 탭, 메시지 탭, 및 버튼 탭을 포함할 때까지, 데이터가 정책 이벤트를 위해 입력됨에 따라, 탭 메뉴(314)의 탭들의 개수가 증가한다는 것을 주목한다.

다음 화면 캡쳐(300Q; 도 3q)로 진행하여, 설계자는 타이틀, 서브타이틀,단문, 및 장문과 같은 메시지 세부사항을 입력한다. "변수들의 사용법"을 클릭하면, 몇 가지만 말하자면, 서비스 플랜명, 과금 코드명, 필터(예컨대, 차단, 감속 등), 바이트 또는 시간 단위의 플랜 활용 백분율, 애플리케이션명, 오버리지 제한, 현재 오버리지, 감속율, 사이클의 리프레쉬 날짜, 사이클의 지속 기간, 현재 플랜이 캡에 도달한 후 매칭된 플랜명, 비허용 매칭된 후 매칭된 플랜명, 현재 로밍 상태, 현재 능동 네트워크, 또는 호스트 혹은 도메인과 같이 통지들에 추가될 수 있는 변수들에 관해 설계자에게 알려준다.

다음 화면 캡쳐(300R; 도 3r)로 진행하여, 설계자는 업셀 플랜들을 표시할지 여부를 결정하고, 통지에 대한 가입자 응답을 가능하게 하는 버튼들을 입력한다(본 예에서는, 카탈로그 보기 및 취소 버튼이 인에이블된다). 전화기 이미지(316)는 메시지들과 버튼들이 장치 내에 어떻게 나타나는지를 예시하기 위해 의도되었지만, 이미지가 반드시 완벽한 표현인 것은 아니다.

플랜 레벨로 복귀할 때(도 3k 참조), 설계자는 탭 메뉴(310)로부터 정책 이벤트 탭을 선택하여, 화면 캡쳐(300S; 도 3s)를 표시하고, 플랜 레벨에서 정책 이벤트들을 입력할 수 있다. 도 3o 내지 도 3r의 예들을 참조하여 설명된 정책 이벤트들이 개별 컴포넌트와 연관되었다는 것을 주목할 수 있다. 도 3s의 예에서, 네트워크 상태("WiFi 네트워크 상에서" 및 "월요일부터 금요일까지")와 연관된 정책 이벤트는 캡&매치가 보일 때 통지가 전송되게 한다. 도 3p 내지 도 3r을 참조하여 설명된 것과 유사한 방식으로 다른 정책 이벤트 매개변수들이 설정될 수 있다.

도 3i 내지 도 3s를 참조하여 설명된 플랜의 완료 시에, 설계자는 탭 메뉴(310)로부터 리뷰 탭을 선택하여(예컨대, 도 3k 참조), 화면 캡쳐(300T; 도 3t)를 표시할 수 있다. 리뷰 화면이 "차단(cut off)"되어 정책 이벤트들의 관찰을 방지하고 있지만, 이는 리뷰 화면의 특질을 이해하는 데에 필요하지 않다는 것을 주목할 수 있다. 본 예에서, "초안" 플랜으로 저장된 플랜이 베타 테스트를 위해 공개될 수 있다(그리고 승인을 위해 제출될 수 있다).

다시 홈페이지(예컨대, 도 3a)를 참조하면, 메뉴 버튼 필드(306)로부터 플랜 카탈로그 버튼을 선택하면, 설계자는 화면 캡쳐(300U; 도 3u)로 안내된다. 여기서, 설계자는 플랜 카탈로그명, 플랜 카탈로그 설명, 플랜 카탈로그 버전을 입력할 수 있다(또는 플랜 카탈로그 데이터스토어의 플랜 카탈로그들로부터 플랜 카탈로그를 선택할 수 있다). 설계자가 "다음"을 클릭할 때, 탭 메뉴는 도 3v의 예에 도시된 바와 같이 특성 탭, 플랜 탭, 플랜 우선순위 탭, 탭 탭, 가입자 그룹 탭, LCP 에러 탭, 업셀 탭, 프로모션 탭, 및 리뷰 탭을 포함하는 탭 메뉴(318)로 확장된다. 플랜 탭 아래서, 설계자는 플랜들을 플랜 카탈로그 내로 드래그할 수 있다.

탭 메뉴(318)로부터 플랜 우선순위 탭을 선택하면, 설계자는 화면 캡쳐(300W; 도 3w)로 안내되고, 여기서 플랜 카탈로그의 플랜들을 우선순위화할 수 있다. 플랜들은 플랜 유형(예컨대, 캐리어 플랜, 유료 플랜)마다 우선순위화되며, 다수의 플랜들이 하나의 플랜 유형 내에 있으면, 플랜들은 플랜 유형들 내에서도 우선순위화될 수 있다. 플랜들 중 일부 또는 모두가 또한 활성화 시에 사용 가능한 것으로 지정될 수 있다. 버전화(versioning)에 의해, 이전 플랜 버전을 가진 가입자들은 계속 이전 버전을 사용할 수 있지만, 신규 가입자들은 가장 최신의 버전을 제안받을 수 있다. 또한, 오래된 플랜이 만료되면, 가입자 역시 가장 최신의 버전을 제안받을 수 있다.

설계자가 탭 메뉴(318)로부터 탭들을 선택하면, 설계자는 화면 캡쳐(300X; 도 3x)로 안내되고, 여기서 설계자는 플랜들의 표시를 위해 탭들을 조직화할 수 있다. 가입자 장치는 예컨대 게임, 소셜, 생산성, 매체, 무료, 유료, 전부와 같은 하나 이상의 탭을 표시할 수 있고, 탭들 아래서, 다양한 플랜들이 설계자에 의해 결정 가능한 순서로 기재될 수 있다.

설계자가 탭 메뉴(318)로부터 가입자 그룹 탭을 선택하면, 설계자는 화면 캡쳐(300Y; 도 3y)로 안내되고, 여기서 설계자는 가입자 그룹들을 드래그 및 드롭할 수 있다.

능동 서비스 플랜이 없는 동안 트래픽 이벤트가 수신될 때, LCP(Lacks Compatible Plan) 에러가 발생한다. LCP 에러는 특정한 종류의 정책 이벤트로서 처리될 수 있다. 정책 이벤트들의 매개변수들을 지정할 때와 같이, 설계자가 메뉴(318)로부터 LCP 에러 탭을 선택할 때, 설계자는 도 3p 내지 도 3r을 참조하여 설명된 것과 유사한 옵션들을 가진다. 다시 말하면, 설계자는 적용 가능한 수명 종료 특성들, 메시지들, 및 버튼들을 선택할 수 있다.

컴포넌트, 플랜, 또는 플랜 카탈로그로부터 제안된 업셀이 발생하고, 트래픽 이벤트들에 응답할 수 있거나(예컨대, 가입자가 페이스북 애플리케이션들을 사용하기 위해 더 비싼 네트워크 서비스들을 소비하고 있을 때, 페이스북 애플리케이션들의 사용 시에 더 저렴한 네트워크 서비스에 대한 업셀이 발생할 수 있다), 또는 다른 이벤트들에 응답할 수 있다. 설계자가 메뉴(318)로부터 업셀 탭을 선택할 때, 설계자는 예컨대 플랜 카탈로그 또는 그 플랜들이나 컴포넌트들 중 임의의 플랜 또는 컴포넌트 내의 통지들로부터 제안된 업셀 기회들을 편집할 수 있다. 업셀들은 마치 정책 이벤트들처럼 편집될 수 있다(예컨대, 특성들, 메시지들, 및 버튼들).

프로모션들이 일회성으로 또는 주기적으로 제안될 수 있다. 설계자가 메뉴(318)로부터 프로모션 탭을 선택할 때, 설계자는 화면 캡쳐(300Z; 도 3z) 내의 프로모션의 빈도를 편집할 수 있다. 프로모션들은 마치 정책 이벤트들처럼 편집될 수 있다(예컨대, 특성들, 메시지들, 및 버튼들).

설계자가 메뉴(318)로부터 리뷰 탭을 선택할 때, 설계자는 화면 캡쳐(300AA; 도 3aa)에 도시된 바와 같이 플랜 카탈로그를 리뷰할 수 있다.

다시 홈페이지(예컨대, 도 3a)를 참조하면, 메뉴 버튼 필드(306)로부터 템플릿 버튼을 선택하면, 설계자는 필터 템플릿들 상에서 작업할 수 있다. 컴포넌트들은 버전들을 가지기 때문에, 템플릿형 필터들을 생성하는 것이 바람직할 수 있고, 이들은 컴포넌트 내에 배치될 때 그 복사본을 자동 생성한다. 그런 식으로, 필터가 하나의 버전을 위해 변경될 때, 다른 버전을 위해서는 변경되지 않는다. 컴포넌트들 내에서 필터를 간단히 재사용하는 것 역시 가능하고, 이 경우에는, 필터가 변경되면, 필터가 재사용된 모든 컴포턴트들에 대해 필터가 변경된다.

메뉴 버튼 필드(306)로부터 리포트 버튼을 선택하면, 설계자는 리포트들을 리뷰할 수 있다. 도 3ab는 사용, 매출, 인지도, 건강(부정(fraud)), 가입자당 등을 포함하는 여러 범주들로 나누어진 리포트들을 가진 화면 캡쳐(300AB)를 도시한다. 리포트들은 서비스 설계 시스템의 데이터스토어들로부터 입수 가능한 정보를 사용하여 생성되고, 이는 가입자 장치들로부터 또는 더 일반적으로는 액세스 네트워크들로부터의 데이터를 통지들 내에 포함시킬 수 있다.

도 4는 가입자 그룹들을 생성하기 위한 방법의 일례의 흐름도(400)를 도시한다. 이 흐름도 및 다른 흐름도들이 직렬 배치된 모듈들로서 본 명세서의 도면들에 도시된다. 그러나, 흐름도들의 모듈들은 적절한 병렬 실행을 위해 재정리 또는 배치될 수 있다.

도 4의 예에서, 흐름도(400)는 가입자 기록을 생성하는 모듈(402)에서 시작한다. 본 명세서에 사용된 바와 같이, "기록"이라는 용어는 데이터스토어에 저장된 모든 적용 가능한 포맷의 데이터 구조를 가리킬 수 있다. 가입자 기록은 장치명, 소유자명, EID(예컨대, IMSI 또는 국가 코드 + 오퍼레이터 코드 + MIN), 장치 유형, 가입자 그룹, 지역, 전화번호(예컨대, MSISDN 또는 MDN), 운영체계 버전, CDMA 가입자 세부사항(예컨대, 장치 ID/MEID 및/또는 MSID), 및 GSM/LTE 가입자 세부사항(예컨대, IMSI 및/또는 IMEI)과 같은 정보를 포함할 수 있다. 일반적으로, 더 많은 정보는 설계자들이 상이한 방식들로 (예컨대, 인구통계적 정보별로) 가입자들을 함께 그룹핑할 수 있게 할 것이며, 이는 목표한 통지들의 수락률(accept rate)을 개선할 수 있다.

도 4의 예에서, 흐름도(400)는 서비스 설계 시스템 가입자 데이터스토어에 가입자 기록을 저장하는 모듈(404)로 진행한다. 데이터스토어는 거의 모든 데이터 저장소에 적용될 수 있는 일반적인 용어이다. 그러나, 이러한 예를 위해, 특정한 포맷이 예상된다. 서비스 설계 시스템 가입자 데이터스토어(및 이후 언급되는 서비스 설계 시스템 가입자 그룹 데이터스토어)는 실시현- 및/또는 구성-특정이지만 반드시 독점적(proprietary)은 아닌 포맷을 가질 가능성이 있으며, 심지어 가능성이 높다. 가입자 기록은 서비스 설계 시스템 가입자 데이터스토어의 예상 포맷으로 저장하기에 적절한 포맷을 가질 것으로 예상된다. 가입자 데이터가 예상 포맷 외의 포맷으로 서비스 설계 시스템에 수신된 경우, 가입자 기록은 예상 포맷으로 생성되며(402), 수신된 가입자 데이터의 일부 또는 전부, 그리고 잠재적으로는 (예컨대, 데이터스토어로부터 또는 운영자 혹은 다른 입력 프로세스를 통해) 서비스 설계 시스템에 의해 획득된 추가적인 데이터로 채워진다.

도 4의 예에서, 흐름도(400)는 생성될 추가적인 가입자 기록들이 있는지 여부를 판단하는 결정점(406)으로 진행한다. 생성될 추가적인 가입자 기록들이 있다고 판단되면(406-Y), 흐름도(400)는 모듈(402)로 되돌아가고, 다음 가입자 기록에 대해 전술한 바와 같이 계속된다. 모듈들(402, 404)과 결정점(406)을 포함하는 "와일 루프(while loop, 408)"는 도 4의 예에서 점선으로 둘러싸여 있다. 와일 루프(408)는 데이터 소스로부터 가입자 데이터를 불러옴으로써 배치 모드(batch mode)로 실행될 수 있다. 가입자 데이터의 포맷은 서비스 설계 시스템 가입자 데이터스토어의 포맷 또는 서비스 설계 엔진이 적절한 포맷으로 변환할 수 있는 포맷들로 제한될 수 있다. 대안으로 또는 추가로, 와일 루프(408)는 서비스 설계 시스템의 기계 혹은 인간 에이전트로부터 또는 잠재적 혹은 현재 가입자로부터 데이터를 수신할 때, 한 번에 한 명의 가입자에 대해, 입력 프로세스를 통해 실행될 수 있다.

다른 한편으로, 생성될 추가적인 가입자 기록이 없다고 판단되면(406-N), 흐름도(400)는 서비스 설계 시스템 가입자 데이터스토어의 가입자 기록들로부터 가입자 그룹 기록을 생성하는 모듈(410)로 진행한다. 가입자 그룹 기록은 상당량의 메타데이터를 포함할 수도 있고, 그렇지 않을 수도 있다. 예컨대, 가입자 그룹 기록에는, 가입자 그룹들을 위한 서비스 플랜들을 생성할 때 가입자 그룹 기록을 사용하기가 훨씬 더 쉽도록 이름과 설명이 배정될 수 있다. 가입자 그룹 기록의 대안적인 필드는 공통 가입자 데이터이지만, 이 또한 설명의 일부로 고려될 수 있다.

도 4의 예에서, 흐름도(400)는 서비스 설계 시스템 가입자 그룹 데이터스토어에 가입자 그룹 기록을 저장하는 모듈(412)로 진행한다. 가입자 그룹 기록들의 포맷에 관련된 사안들은 모듈(404)을 참조하여 전술한 것들과 유사하다.

도 4의 예에서, 흐름도(400)는 생성될 추가적인 가입자 그룹 기록들이 있는지 여부를 판단하는 결정점(414)으로 진행한다. 생성될 추가적인 가입자 그룹 기록들이 있다고 판단되면(414-Y), 흐름도(400)는 모듈(410)로 되돌아가고, 다음 가입자 그룹 기록에 대해 전술한 바와 같이 계속된다. 모듈들(410, 412)과 결정점들(414, 416)을 포함하는 "와일 루프(418)"는 도 4의 예에서 점선으로 둘러싸여 있다. 와일 루프(416)는 가입자 데이터스토어로부터 가입자 기록들을 불러옴으로써 배치 모드로 실행될 수 있다. 대안으로 또는 추가로, 와일 루프(418)는 서비스 설계 시스템의 기계 혹은 인간 에이전트로부터 또는 잠재적 혹은 현재 가입자로부터 데이터를 수신할 때, 한 번에 한 명의 가입자에 대해, 입력 프로세스를 통해 실행될 수 있다. 예컨대, 운영자는 유효 가입자들을 가입자 그룹 내로 드래그 및 드롭할 수 있고, 서비스 설계 엔진은 이런 방식으로 가입자 그룹에 추가된 유효 가입자들로부터 가입자 그룹 기록을 생성할 수 있다.

특정한 실시예에서, 가입자 데이터 배치(batch)가 서비스 설계 시스템 내로 불려올 수 있고, 가입자 그룹을 채우기 위해 사용될 수 있다. 흐름도(400)의 논리적 흐름은 가입자 기록들을 생성하고(412), 반복적으로(406) 가입자 기록들을 저장하고(404), 서비스 설계 시스템 가입자 데이터스토어의 가입자 기록들로부터 가입자 그룹을 생성하는(410) 것임을 주목할 수 있다. 그러나, 불러오기 절차는 가입자 그룹을 생성하기 전에 각각의 가입자 기록을 생성할 필요가 없다.

특정한 실시예에서, 기존의 가입자 그룹 기록의 일부로서 가입자 기록을 식별하는 특성을 가진 가입자 기록이 생성되고, 서비스 설계 시스템 가입자 데이터스토어에 저장될 때, 가입자는 기존의 가입자 그룹 기록에 자동 추가될 수도 있고, 그렇지 않을 수도 있다(또는 업데이트 절차가 서비스 설계 시스템의 에이전트 또는 가입자에 의해 개시될 때, 가입자 그룹 기록에 사전 추가되지 않은 관련 특성들을 가진 모든 가입자 기록을 추가할 수 있다).

다시 한번 결정점(414)을 참조하면, 생성될 추가적인 가입자 그룹 기록이 없다고 판단되면(414-N), 흐름도(400)는 생성될 추가적인 가입자 기록들이 있는지 판단하는 결정점(416)으로 진행한다. 생성될 추가적인 가입자 기록들이 있다고 판단되면(416-Y), 흐름도(400)는 모듈(402)로 되돌아가고, 전술한 바와 같이 계속된다. 다른 한편으로, 생성될 추가적인 가입자 기록이 없다고 판단되면(416-N), 흐름도(400)는 종료된다. 통상적인 실시예에서, 생성될 다른 가입자 기록 또는 다른 가입자 그룹 기록이 있다면, 상기 방법은 모듈(402) 또는 모듈(410)에서 재시작될 수 있다는 것을 주목할 수 있다. 그러므로, 종료는 흐름도(400)에 대한 논리적 종료이지만, 프로세스는 필요에 따라 계속될 수 있다.

도 5는 서비스 플랜 컴포넌트들을 생성하기 위한 방법의 일례의 흐름도를 도시한다. 도 5의 예에서, 흐름도(500)는 필터 인스턴스를 생성하는 모듈(502)에서 시작한다. 이러한 액션에 의해 필터 기록이 생성되지만, 필터가 시스템에서 사용되는 방식 때문에 "인스턴트"라는 용어가 사용된다. 구체적으로, 2개의 서비스 플랜 컴포넌트들이 필터 인스턴스를 포함하고, 필터 인스턴스가 이후 변경되면, 이러한 변경이 서비스 플랜 컴포넌트들 모두에 적용된다는 점에서, 필터는 전체적(global) 특성을 가질 수 있다. 그러므로, 다수의 컴포넌트들에서 사용되는 단일 필터 인스턴스가 있다. 대안으로, 2개의 서비스 플랜 컴포넌트들이 필터 인스턴스를 포함하고, 필터 인스턴스들 중 하나가 변경되면, 이러한 변경이 다른 필터 인스턴스에 적용되지 않는다는 점에서, 필터 인스턴스가 템플릿으로부터 생성될 수 있다. 따라서, 필터 템플릿의 각각의 애플리케이션은 별개의 필터 인스턴스이다. 특정한 실시예에서, 필터 인스턴스들은 전체적 또는 국부적인 것으로 명시적으로 설정될 수 있다. 변경이 시스템을 통해 캐스케이드 하지 않으면서, 서비스 플랜 컴포넌트들 내에서 변경될 수 있는 국부 필터 인스턴스들뿐만 아니라, (전체적 필터 템플릿에 대한 변경이 필터의 모든 인스턴스들에 적용되게 하는) 전체적 필터 템플릿을 생성하는 것 역시 가능하다.

도 5의 예에서, 흐름도(500)는 서비스 설계 시스템 필터 데이터스토어에 필터 인스턴스를 저장하는 모듈(504)로 진행한다. 서비스 설계 시스템 필터 데이터스토어는 필터 인스턴스를 위한 명시적 데이터 구조 요건들을 가질 수 있지만, 필터와 매칭되는 트래픽 인스턴스를 적어도 포함할 것이다. 특정한 실시예에서, 트래픽 인스턴스들은 명시된 원격 수신지(예컨대, 도메인 또는 IP 주소), 명시된 애플리케이션(예컨대, 이름, 해쉬, 인증서, 서명, 다른 안전한 ID 등에 의해 식별됨), 명시된 운영체계, 명시된 컨텐츠, 명시된 프로토콜(예컨대, TCP, UDP, TCP/UDP), 또는 명시된 포트 번호를 포함하는 트래픽 이벤트들을 포함할 수 있다. 도메인 필터들은 레퍼런스들의 로딩을 허용하고/허용하거나 (예컨대, 초 단위 또는 데이터의 바이트 단위로) 연관 필터링을 사용하도록 명시될 수 있다. 애플리케이션 필터들은 애플리케이션들을 인가하도록 명시될 수 있다. 서비스 설계 시스템 필터 데이터스토어에 저장된 각각의 필터 인스턴스는 인간 에이전트들을 위해 필터의 사용이 훨씬 더 쉬워지도록 필터명과 설명을 포함할 수 있다.

특정한 실시예에서, 필터 인스턴스들은 매치 또는 노매치 필터들인 것으로 명시될 수 있다. "매치" 필터는 다른 필터에 트래픽 이벤트를 매칭하려는 시도를 금지하지 않는다. "노매치" 필터는 네트워크 트래픽 검사 엔진이 다른 필터에 트래픽 이벤트를 매칭하려 시도하는 것을 금지한다. 어떤 의미에서는, 이는 필터에 액션을 적용하는 것이고, 필터의 매치 및 노매치 양상은 어느 쪽이든 소정의 문맥 내에서 더 적용 가능한 쪽으로, 필터 양상 또는 연관된 액션 양상으로 처리될 수 있다.

도 5의 예에서, 흐름도(500)는 생성할 더 많은 필터 인스턴스들이 있는지 여부를 판단하는 결정점(506)으로 진행한다. 생성할 더 많은 필터 인스턴스들이 있다고 판단되면(506-Y), 흐름도(500)는 모듈(502)로 되돌아가고, 다음 필터 인스턴스를 위해 전술한 바와 같이 계속된다.

다른 한편으로, 생성될 추가적인 필터 이벤트들이 없다고 판단되면(506-N), 흐름도(500)는 대응하는 정책 이벤트 규칙 기록을 생성하는 모듈(508)로 진행한다. 정책 이벤트 규칙은 서비스 플랜 컴포넌트로 하여금 (임의의 네트워크 상태를 포함하는) 어떤 네트워크 상태가 정책 이벤트에 적용 가능한지를 판단할 수 있게 한다. 특정한 실시예에서, 규칙들은 대응하는 필터 없이 (예컨대, 독립형 규칙으로서) 생성될 수 있다. 필터가 규칙에 의해 명시된 방식으로 트래픽 이벤트와 매칭될 때, 정책 이벤트 규칙이 적용 가능하게 된다. 예컨대, 네트워크 상태가 검출되도록 트래픽 이벤트가 필터 인스턴스와 매칭되면(예컨대, 이 네트워크 상태에 있음, 이 네트워크 상태로 전이, 및 이 네트워크 상태로부터 전이), 이러한 조건들을 명시하는 규칙이 적용 가능하다. 명시된 조건들의 다른 예들은 트래픽 이벤트가 허용, 차단, 감속, 지연, 또는 연기된 경우이고, 각각은 매칭 또는 노매치인 것으로 명시될 수 있다.

정책 규칙들은 캡들을 또한 정의할 수 있고, 이들은 예컨대 시간 또는 바이트의 계수가 소정의 캡에 도달할 때 만족된다. (계수가 통지 정책의 일부로 고려될 수 있다는 것을 주목할 수 있다.) 캡핑된 정책 이벤트가 소정의 캡까지 카운터를 증가시킬 때, 필터는 예컨대 허용(캡을 초과하지 않았을 때)으로부터 차단, 감속, 지연, 또는 연기(캡을 초과했을 때)로 변경될 수 있다. 캡핑된 정책 이벤트는 마찬가지로 예컨대 감속(캡을 초과하지 않았을 때)으로부터 더 많은 감속(캡을 초과했을 때)으로, 또는 캡을 초과하기 전후의 필터링 활동의 다른 조합으로 진행될 수 있다.

도 5의 예에서, 흐름도(500)는 대응하는 정책 이벤트 규칙 기록을 설계 시스템 규칙 데이터스토어에 저장하는 모듈(510)로 진행한다. 정책 이벤트 규칙 기록들은 트래픽 제어 정책, 통지 정책, 및 과금 정책 중 하나 이상을 포함할 수 있다. 트래픽 제어 정책 규칙들은 트래픽 제어 정책 규칙이 대응하는 필터의 유형과 연관된다(예컨대, 허용, 차단, 감속, 지연, 연기, 또는 액션 없음). 적용 가능한 트래픽 제어는 네트워크 상태, 장치 상태, 서비스 플랜 사용 상태 등의 함수일 수 있다.

통지 정책 규칙들은 가입자, 서비스 설계 시스템의 인간 또는 기계 에이전트, 프로그램 등과 같은 상대방(a party)에게 정보를 전송하는 것과 연관된다. 특정한 실시예에서, 통지 정책 기록에는, 이름과 설명, 그리고 통지 세부사항(예컨대, 통지가 전경 또는 배경에 있는지 여부, 통지의 수신지(예컨대, 가입자, 서버, 또는 다른 상대방), 및 통지와 연관되어 인에이블되는 상호작용(예컨대, 통지가 더 이상 사용자에게 표시되지 않을 때까지 통지의 표시 회수, 또는 사용자가 향후에 통지를 폐지할 수 있게 하는 옵션))이 주어질 수 있다. 서비스 설계 시스템의 인간 에이전트들과 가입자들에 대한 통지는 통상적으로 타이틀, 서브타이틀, 단문, 및/또는 장문 설명과 같은 인간-판독 가능한 컨텐츠를 포함할 것이다. 기계 에이전트들에 대한 통지들은 동일한 정보를 포함할 수도 있고, 그렇지 않을 수도 있으며, 인간에 의해 판독될 때 거의 또는 아무 의미가 없는 명령어 세트들을 포함할 수 있다. 특정한 실시예에서, 통지들은 네트워크 상태에 관한 데이터스토어들로부터의 데이터, 또는 시간에 따라 변화될 수 있는 다른 데이터를 삽입하는 변수들을 포함할 수 있다. 서비스 설계 에이전트는 수신자가 피드백 또는 명령어를 제공할 수 있게 하는 선택 옵션들(예컨대, 버튼들)을 통지 내에 포함시킬 수 있다. 유용한 선택 옵션들은 예컨대 업셀 플랜들, 서비스 제안 카탈로그, 더 많은 정보 요청, 오버리지를 원한다는 표시, URL 런칭, 및/또는 거부를 포함할 수 있다. 특정한 실시예에서, 서비스 설계 시스템 에이전트는 통지를 가진 모바일 장치를 표시하는 그래픽 사용자 인터페이스를 사용할 수 있고, 이는 통지의 리뷰를 편리하게 하기 위해 (아마 모바일 장치의 몇몇 아이콘들 또는 다른 특징부들 없이) 표시될 것이다.

과금 정책 규칙들은 사용에 대해 얼마나 청구할지(시간 단위 또는 바이트 단위) 판단하는 것과 연관된다. 특정한 실시예에서, 서비스 플랜 컴포넌트는 컴포넌트가 통합된 플랜으로부터 과금 정책을 계승할 수 있다. 따라서, 엄격히 말하자면, 이러한 실시예에서, 서비스 플랜 컴포넌트 기록은 과금 정책 규칙을 가질 필요가 없지만, 전개 시에, 계승으로 인해 과금 정책 규칙을 가질 수 있다. 과금 정책이 컴포넌트를 위해 정의된 경우, 과금 정책은 사용된 데이터 또는 시간에 기반할 수 있고, 오버리지 허용값(임의적인 최대 오버리지 사용)을 가질 수도 있고, 그렇지 않을 수도 있으며, 과금 코드로 명시될 수 있는 요율을 가질 것이다.

도 5의 예에서, 흐름도(500)는 서비스 설계 시스템 필터 데이터스토어로부터의 필터 인스턴스 및 설계 시스템 규칙 데이터스토어 내의 정책 이벤트 규칙 기록을 포함하는 서비스 플랜 컴포넌트 기록을 생성하는 모듈(512)로 진행한다. 서비스 플랜 컴포넌트가 항상 필터와 정책 이벤트 규칙을 가진다는 것을 관찰할 수 있다. 트래픽 제어 정책이 (몇 가지만 말하자면, 허용, 차단, 감속, 지연, 연기 외에도) "검출"을 포함하도록 정의된다고 가정하면, 서비스 플랜 컴포넌트는 항상 트래픽 제어 정책을 포함하는 것으로서 정의될 수 있고, 여기서 "검출"은 필터와 정책 이벤트 규칙이 트래픽 이벤트와 매칭될 때 정책 이벤트를 유발하는 것에 불과하다. 통지 정책이 "없음(none)"을 포함하도록 정의된다고 가정하면, 서비스 플랜 컴포넌트는 항상 통지 정책을 포함하는 것으로서 정의될 수 있다. 과금 정책이 "계승"을 포함하도록 정의된다고 가정하면, 서비스 플랜 컴포넌트는 항상 과금 정책을 포함하는 것으로서 정의될 수 있고, 이는 컴포넌트가 과금 정책을 계승할 수 있는 플랜에 컴포넌트가 통합될 때 결정된다.

도 5의 예에서, 흐름도(500)는 더 많은 필터 인스턴스들이 생성될지 여부를 판단하는 결정점(514)으로 진행한다. 더 많은 필터 인스턴스들이 생성될 것이라고 판단되면(514-Y), 흐름도는 모듈(502)로 되돌아가고, 전술한 바와 같이 계속된다(그러나, 모듈(512)에서, 서비스 플랜 컴포넌트 기록을 생성하는 대신, 서비스 플랜 컴포넌트 기록을 수정할 수 있다). 다른 한편으로, 필터 인스턴스들이 더 이상 생성되지 않을 것이라고 판단되면(514-N), 흐름도(500)는 필터 기록에 대응하는 더 많은 정책 이벤트 규칙 기록들이 생성될지 여부를 판단하는 결정점(516)으로 진행한다.

필터 기록에 대응하는 더 많은 정책 이벤트 규칙 기록들이 생성될 것이라고 판단되면(516-Y), 흐름도(500)는 모듈(508)로 되돌아가고, 전술한 바와 같이 계속된다(그러나, 모듈(512)에서, 서비스 플랜 컴포넌트 기록을 생성하는 대신, 서비스 플랜 컴포넌트 기록을 수정할 수 있다). 다른 한편으로, 필터 기록에 대응하는 정책 이벤트 규칙 기록들이 더 이상 생성되지 않을 것이라고 판단되면(516-N), 흐름도(500)는 종료된다.

통상적인 실시예에서, 생성될 다른 필터 인스턴스, 정책 이벤트 규칙 기록, 또는 서비스 플랜 컴포넌트 기록이 있다면, 상기 방법은 모듈(502), 모듈(508), 또는 모듈(512)에서 재시작될 수 있다는 것을 주목할 수 있다. 그러므로, 종료는 흐름도(500)에 대한 논리적 종료이지만, 프로세스는 필요에 따라 계속될 수 있다.

도 6은 서비스 플랜 컴포넌트들로부터 서비스 플랜들을 생성하기 위한 방법의 일례의 흐름도(600)를 도시한다. 예시를 위해, 서비스 플랜에서 사용될 필터 인스턴스들, 정책 이벤트 규칙 기록들, 및 서비스 플랜 컴포넌트 기록들이 이미 생성되었다고 가정한다. 흐름도(600)의 임의의 적절한 점(미도시)에서, 필터 인스턴스들, 정책 이벤트 규칙 기록들, 및 서비스 플랜 컴포넌트 기록들 중 일부 또는 전부가 생성될 수 있거나 전혀 생성되지 않을 수 있다는 것을 주목할 수 있다. 특정한 실시예에서, 필터 인스턴스들과 정책 이벤트 규칙 기록들은 서비스 플랜 컴포넌트 레벨(예컨대, 도 5 참조)과 서비스 플랜 레벨 모두에서 사용될 수 있다.

도 6의 예에서, 흐름도(600)는 서비스 플랜 기록을 생성하는 모듈(610)로 진행한다. 서비스 플랜 기록은 예컨대 가입자 장치들 상에 표시되기 위한 아이콘, 플랜명, 플랜 간략 설명, 플랜 설명, 플랜 버전, 플랜 유형(예컨대, 후원, 유료, 또는 캐리어), 플랜이 디폴트 플랜인지 여부, 플랜이 재구매 가능한지 여부, 청구 가격, 및 표시 가격을 포함할 수 있다. 정책 라벨이 가입자 장치에 표시되는지 여부 역시 설정될 수 있다. 후술하는 모듈들과 연관된 정보의 일부 또는 전부가 제공된 후, 서비스 플랜 기록이 대신 생성될 수 있다는 것을 주목할 수 있다.

도 6의 예에서, 흐름도(600)는 서비스 플랜을 위한 과금 정책을 설정하는 모듈(604)로 진행한다. 과금 정책은 데이터 또는 시간 사용에 기반할 수 있고, 일정량의 오버리지가 있거나 없이 사용 제한을 가질 수 있으며, 청구 정책 사이클은 적절하게 구성될 수 있다(예컨대, 지속 기간, 빈도, 리포트 사용, 선불 또는 후불 등). 청구 식별자들(예컨대, 청구명, 캐리어 서비스 ID 등)이 사용되는지 여부 역시 설정될 수 있다. 과금 코드들이 사용되면, 과금 코드들 역시 식별되고, 서비스 플랜에 적합하게 디폴트로 설정되거나 설정되지 않을 수 있다. 과금 정책은 플랜의 과금 정책을 계승하도록 구성된 플랜의 서비스 플랜 컴포넌트들에 의해 계승될 수 있다.

도 6의 예에서, 흐름도(600)는 서비스 플랜 내에 서비스 플랜 컴포넌트들을 계층적으로 배치하는 모듈(606)로 진행한다. 계층적 배치는 컴포넌트들의 순서화 시에 (예컨대, 컴포넌트와 연관된 필드에 우선순위를 나타냄으로써) 명시적일 수 있거나, 내포적일 수 있다. 특정한 실시예에서, 컴포넌트들은 또한 서비스 등급들을 가진다. 예컨대, 컴포넌트들은 캐리어, 네트워크 보안, 후원, 유료, 부모 통제, 마켓팅 인터셉트, 오픈 액세스/벌크, 포스트-벌크, 및 적용 가능하지 않은 서비스 플랜/수명 종료와 같은 서비스 등급들에 속할 수 있다. 그러므로, 서비스 플랜 컴포넌트들의 계층적 배치는 서로 상대적인 서비스 플랜 컴포넌트들의 계층적 배치, 서비스 등급 내의 다른 서비스 플랜 컴포넌트들에 상대적인 서비스 등급 내의 서비스 플랜 컴포넌트들의 계층적 배치, 또는 이들 모두를 가리킬 수 있다.

실시에 따라, 서비스 플랜 컴포넌트들은 생성(또는 편집) 시에 서비스 등급을 갖도록 지정될 수 있거나, 또는 컴포넌트는 서비스 플랜에 추가될 때 서비스 등급에 배정될 수 있다. 예컨대, 서비스 플랜 컴포넌트는 "유료" 서비스 등급에 배정될 수 있지만, 마케팅 인터셉트 서비스 등급에 배정될지라도 역시 적절하게 기능할 수 있다. 실시에 따라, 컴포넌트는 생성 시에 "유로"로 지정될 수 있고, 유사한 "마케팅 인터셉트" 컴포넌트를 생성하기 위해 복제될 수 있거나, 또는 컴포넌트는 생성 시에 유료 또는 마케팅 인터셉트로 지정될 수 있고(또는 서비스 등급 지정이 없을 수 있고), 서비스 플랜 내에 배치될 때 관련 서비스 등급에 삽입될 수 있다. 그러므로, 계층적 배치는 서비스 등급별로 동적일 수 있거나(예컨대, 설계자가 컴포넌트를 배치할 등급을 고를 수 있다), 또는 서비스 등급별로 정적일 수 있다(예컨대, 컴포넌트가 서비스 등급 내에 생성된다). 특정한 구현예에서, 정적 서비스 등급을 가진 서비스 플랜 컴포넌트는 서비스 등급 내의 다른 서비스 플랜 컴포넌트들에 상대적으로 우선순위에 의해 명시적으로 배치될 수 있고, 동적 배정된 서비스 등급을 가진 서비스 플랜 컴포넌트는 서비스 등급 내의 다른 서비스 플랜 컴포넌트들에 상대적으로 우선순위에 의해 명시적으로 배치될 수 있으며, 정적 서비스 등급을 가진 서비스 플랜 컴포넌트는 서비스 등급 내에 우선순위에 의해 내포적으로 배치될 수 있고, 동적 배정된 서비스 등급을 가진 서비스 플랜 컴포넌트는 서비스 등급 내에 우선순위에 의해 내포적으로 배치될 수 있다.

본 명세서에 제공된 예들에서, 캐리어 서비스 등급은 일반적으로 가장 높은 우선순위 서비스 등급으로서 처리된다. 캐리어 플랜들은 기본적인 네트워크 정책을 포함할 것이다. 특정한 실시예에서, 캐리어 플랜들은 가입자 장치 상에서 자동 시행되고, 플랜 카탈로그 내에 제안되지 않는다.

본 명세서에 제공된 예들에서, 두 번째로 높은 우선순위 서비스 등급인 네트워크 보안은 (너무 많은 네트워크 자원들을 소비하고 있는 장치들을 검출하여 감속 또는 차단함으로써) 네트워크 자원들을 보호하도록 설계된 정책과 연관될 수 있다. 네트워크 보안 서비스들은 (예컨대, 배경 처리와 반대로 전경 처리, 속도 등을 인에이블하기 위해) 가입자에 의해 선택 가능한 가변 청구 정책들을 가질 수 있지만, 가입자는 실시에 따라 네트워크 보안 정책을 수정하는 능력을 가질 수도 있고, 그렇지 않을 수도 있다.

본 명세서에 제공된 예들에서, 세 번째로 높은 우선순위 서비스 등급인 후원은 가입자 외의 개체에 의해 전체 또는 일부가 후원되는 서비스 플랜들과 연관될 수 있다. 일부 후원 서비스 플랜들은 보조된(subsidized) 것으로 참조될 수 있지만, "후원(sponsored)"이라는 용어는 문맥에 의해 달리 나타내지 않는 한 보조 플랜들을 포함하도록 의도된다. 실시 및/또는 구성에 따르면, 후원 플랜들은 임의적일 수도 있고, 그렇지 않을 수도 있다. 예컨대, 회사의 직원은 회사 인트라넷에 액세스할 때 적용 가능한 후원 서비스 플랜을 가질 수 있으며, 후원을 거절할 수도 있고, 그렇지 않을 수도 있다. 다른 예로, 페이스북은 가입자가 페이스북 웹사이트에 액세스할 때 네트워크 자원 소비를 보조할 수 있고, 가입자는 보조를 거절할 수도 있고, 그렇지 않을 수도 있다.

본 명세서에 제공된 예들에서, 네 번째로 높은 우선순위 서비스 등급인 유료는 가입자가 구매한 서비스 플랜들과 연관될 수 있다. 이는 일반적으로 가입자에게 예컨대 액션 가능한 서비스 제안을 통해 유료 서비스 플랜을 구매할 옵션이 주어질 경우이다. (액션 가능한 서비스 제안은 가입자가 서비스 제안의 수락을 선택할 수 있게 하는 수락 버튼과 같은 피드백 메커니즘을 포함하는 통지이다.) 서비스 제안들은 플랜이 도울 수 있는 무언가를 하려고 가입자가 시도할 때와 같은 기정의된 조건들에 의해 유발될 수 있다. (서비스 제안들은 또한 후원 서비스들을 위해 유발될 수 있다.)

본 명세서에 제공된 예들에서, 다섯 번째로 높은 우선순위 서비스 등급인 부모 통제는 가입자가 인증 프로세스에 따라 구매 또는 수정한 서비스 플랜들과 연관될 수 있다. 부모 통제 플랜들은 주요 가입자가 정책을 설정할 수 있는 다중(또는 단일)-장치 플랜들과 연관될 수 있다. 실시에 따라, 다중-장치 플랜의 상이한 장치들 역시 상이한 후원 및 유료 플랜들을 가질 수 있다.

본 명세서에 제공된 예들에서, 여섯 번째로 높은 우선순위 서비스 등급인 마켓 인터셉터는 가입자가 벌크 정책 서비스 등급으로 드롭되기 전에 가입자에게 제안된 서비스 플랜들과 연관될 수 있다. 마켓 인터셉터 플랜들은 어떤 식으로든 오픈 액세스 정책에 유리한 서비스 제안들을 포함할 수 있다.

본 명세서에 제공된 예들에서, 일곱 번째로 높은 우선순위 서비스 등급인 오픈 액세스 또는 벌크는 캐치-올(catch-all) 서비스 플랜과 연관될 수 있다.

본 명세서에 제공된 예들에서, 여덟 번째로 높은 우선순위 서비스 등급인 포스트-벌크는 다른 서비스 플랜이 적용 가능하지 않은 경우에 활성화될 수 있는 서비스 플랜들과 연관될 수 있다. 특정한 실시예에서, 포스트-벌크 플랜들은 가입자가 이행하고자 하지만 사용 가능한 서비스 플랜이 없기 때문에 이행할 수 없는 무언가를 위해 서비스 플랜을 활성화할 마지막 기회를 가입자에게 제안하도록 설계된다. 가입자가 통지에 적절하게 응답한다면, 가입자는 현재 활동에 관련된 서비스 플랜(예컨대, 유료 서비스 플랜)을 활성화할 수 있다.

본 명세서에 제공된 예들에서, 아홉 번째로 높은 우선순위 서비스 등급인 수명 종료는 검출된 트래픽 이벤트을 위해 사용 가능한 서비스 플랜이 없다는 통지와 통상적으로 연관된다.

특정한 실시예들에서 서비스 등급 계층을 이용하기 위해 모든 서비스 등급들을 활용할 필요는 없다. 계층 내의 다른 등급들에 대해 위아래로 등급을 이동시키는 것 역시 가능하다. 예컨대, 네트워크 보안 등급에는 유료 서비스 등급 아래의 우선순위가 주어질 수 있다.

도 6의 예에서, 흐름도(600)는 네트워크 상태와 연관된 플랜-레벨 정책 이벤트들을 설정하는 모듈(608)로 진행한다. 전술한 바와 같이, 각각의 서비스 플랜 컴포넌트는 트래픽 제어 정책, 통지 정책, 및 과금 정책을 가질 수 있다. 정책 이벤트들 역시 플랜 레벨로 설정될 수 있다. 특정한 실시예에서, 서비스 플랜 컴포넌트들을 생성할 때 생성된 필터들과 규칙들이 플랜 레벨에서 재사용될 수 있고, 필터들과 규칙들이 서비스 플랜(미도시)을 생성할 때 생성된다면, 필터들과 규칙들은 서비스 플랜 컴포넌트 레벨에서 사용될 수 있다. 특정한 실시예에서, 정책 이벤트들은 네트워크 상태와 연관될 수 있다. 네트워크 상태는 현재 또는 이력 매개변수들(예컨대, 정체, 네트워크 상의 이전 인증 시도 실패 회수, 시각, 지리적 위치, 네트워크 유형, 장치 로밍 등)을 가리킬 수 있다. 정책 이벤트들은 또한 임의의 네트워크 상태에 대해 (즉, 네트워크 상태와 무관하게) 적용 가능하도록 설정될 수 있다.

도 6의 예에서, 흐름도(600)는 서비스 설계 시스템 서비스 플랜 데이터스토어에 서비스 플랜 기록을 저장하는 모듈(612)에서 종료된다. 유리하게, 서비스 플랜은 수정 없이 다수의 서비스 플랜 카탈로그들에서 사용될 수 있다. 대안으로, 서비스 플랜 기록은 수정이 있거나 수정 없이 다양한 서비스 플랜 카탈로그들에서 사용하기 위해 복제될 수 있다. 버전화가 사용되는 경우, 전개된 서비스 플랜들은 (이전 버전들로부터 서비스 플랜 컴포넌트들로의 가입자들의 있을 수 있는 그랜드파더링(grandfathering-in)을 이용하여) 새로운 버전들로 자동 업데이트될 수 있거나, 또는 서비스 플랜들은 서비스 플랜의 새로운 버전들이 전개된 서비스 플랜 제안에 영향을 주지 않도록 전체 또는 일부가 템플릿될 수 있다. 실시에 따라, 설계자는 (예컨대, 서비스 플랜을 리뷰하고, 매개변수를 변경해야 한다고 판단한 후) 매개변수들을 편집하기 위해 임의의 모듈로 되돌아갈 수 있다.

서비스 설계 엔진은 도 4를 참조하여 제공된 예와 같은 프로세스를 사용하여 가입자 그룹들을 생성할 수 있다. 서비스 설계 엔진은 또한 도 6을 참조하여 제공된 예와 같은 프로세스를 사용하여 서비스 플랜들을 생성할 수 있다. 가입자 그룹들과 서비스 플랜들은 자동적 또는 선택적 실시를 위해 네트워크들에 액세스하도록 제공된 서비스 플랜 카탈로그들 내에서 실시될 수 있다. 도 7은 가입자 그룹들과 서비스 플랜들로부터 서비스 플랜 카탈로그들을 생성하기 위한 방법의 일례의 흐름도(700)를 도시한다.

도 7의 예에서, 흐름도(700)는 서비스 플랜 카탈로그 기록을 생성하는 모듈(702)에서 시작한다. 서비스 플랜 카탈로그 기록은 플랜 카탈로그명, 플랜 카탈로그 설명, 플랜 카탈로그 버전 등을 포함할 수 있다. 후술하는 모듈들과 연관된 정보의 전부 또는 일부가 제공된 후, 서비스 플랜 카탈로그 기록이 대신 생성될 수 있다는 것을 주목할 수 있다.

도 7의 예에서, 흐름도(700)는 서비스 플랜 카탈로그 기록 내에 플랜들을 추가하는 모듈(704)로 진행한다. 특정한 실시예에서, 플랜들은 서비스 설계 시스템 서비스 플랜 데이터스토어에 기록들로서 저장된다. 특정한 실시예에서, 플랜들은 리스트로 표현되고, 설계자는 서비스 설계 시스템 UI를 사용하여 리스트로부터 선택된 플랜 리스트로 플랜들을 드래그할 수 있다. 플랜들은 활성화 시에 사용 가능한 것으로 지정될 수 있다(또는 그렇지 않을 수 있다).

도 7의 예에서, 흐름도(700)는 서비스 플랜 카탈로그 기록에 서비스 플랜들을 계층적으로 배치하는 모듈(706)로 진행한다. 플랜들은 서로 상대적인 우선순위에 의해 배치될 수 있고, 더 높은 우선순위의 플랜이 먼저 표시 및/또는 사용된다. 플랜들은 또한 서비스 등급 내의 다른 플랜들에 상대적으로 서비스 등급 내에 배치될 수 있다. 서비스 등급은 플랜들이 생성(또는 편집)될 때 정적으로 배정되거나, 서비스 플랜 카탈로그의 생성 동안 동적으로 배정될 수 있다. 우선순위들은 우선순위 표시기에 기반하여 명시적이거나, 플랜 리스트 내의 플랜의 상대 위치에 기반하여 내포적이거나, 또는 다른 방식으로 나타낼 수 있다. 특정한 실시예에서, 서비스 설계 시스템 UI는 설계자가 우선순위를 설정하기 위해 서비스 등급들 내에서 플랜 리스트의 위아래로 플랜을 드래그할 수 있게 하고, 우선순위는 서비스 등급 내에서 플랜의 상대적인 순서에 대응하는 우선순위 번호에 의해 나타낸다.

도 7의 예에서, 흐름도(700)는 서비스 플랜 카탈로그 제안과 함께 표시하기 위해 탭들 내에 플랜들을 임의적으로 배치하는 모듈(708)로 진행한다. 탭들은 게임, 소셜, 생산성, 매체, 무료, 유료, 전부 등과 같은 범주들을 포함할 수 있다. 서비스 플랜 카탈로그 제안이 예컨대 가입자 장치 상에 표시될 때, 플랜이 연관된 탭 아래에 표시되도록 탭과 플랜 사이의 연관성이 형성될 수 있다. 플랜은 다수의 탭들과 연관될 수 있고, 다수의 탭들 아래에 표시될 수 있다. 탭들의 순서가 구성될 수 있고, 탭들 내의 플랜들의 순서도 구성될 수 있다. 본 명세서에서, 탭 내의 플랜들의 순서는 예컨대 서비스 등급 내의 플랜의 우선순위와 관련이 없지만, 이러한 상호관계가 대안적인 실시예들에서 이루어질 수 있다.

도 7의 예에서, 흐름도(700)는 서비스 플랜 카탈로그 기록에 가입자 그룹들을 추가하는 모듈(710)로 진행한다. 특정한 실시예에서, 가입자 그룹들은 리스트로 표현되고, 설계자는 서비스 설계 시스템 UI를 사용하여 리스트로부터 선택된 가입자 그룹 리스트로 플랜들을 드래그할 수 있다. 예컨대, 가입자 특성들에 따라 가입자 그룹들을 식별하는 것과 같이, 가입자 그룹들을 추가하는 다른 방법들이 예상된다.

서비스 플랜 카탈로그가 공개될 때, 서비스 플랜 카탈로그 내의 서비스 플랜들과 연관된 가입자 그룹들은 가입자들을 자동으로 또는 플랜 선택에 의해 식별하는데, 가입자들은 관련 서비스 플랜의 정책들이 자신들의 장치들에 시행되게 할 것이다. 실시에 따라, 플랜의 공개는 베타 방식일 수 있거나(일반적으로 플랜의 가입자들이 공지가 있거나 공지 없이 변경된 플랜을 가질 수 있다는 것을 의미한다), 또는 전개될 수 있다(이는 일반적으로 가입자들이 (새로운 버전의) 플랜을 재구매할 필요가 있을 때까지 플랜의 미래 버전에 대한 변경이 가입자들에게 영향을 미치지 않을 것이라고 기대할 수 있다는 것을 의미한다).

도 7의 예에서, 흐름도(700)는 업셀 제안들을 구성하는 모듈(712)로 진행한다. 업셀 제안들은 네트워크 상태, 장치 상태, 또는 가입자 상태와 연관된 통지 정책을 가진다. 예컨대, 가입자가 벌크 플랜 내에서 상당한 스트리밍 매체를 사용한다면, 가입자들의 현재 또는 이력 사용에 기반하여 가입자의 돈을 절약해줄 스트리밍 매체 플랜을 제안하는 것이 바람직할 수 있다. 다른 예로, 무선 도시권 네트워크(Municipal Area Network, MAN)를 가진 도시에 있는 가입자는 무선 MAN의 사용과 연관된 업셀 제안들을 수신할 수 있다. 또 다른 예로, 페이스북에 빈번하게 액세스하는 가입자는 페이스북에 의해 후원된 서비스 플랜을 제안받아, 액세스가 페이스북과 연관되는 한 서비스 비용을 줄일 수 있다. 또 다른 예로, 페이스북 경쟁상대에 빈번하게 액세스하는 가입자는 (저렴함을 이유로) 가입자를 페이스북으로 끌어들이기 위해 페이스북에 의해 후원된 서비스 플랜을 제안받을 수 있다. 또 다른 예로, 가입자가 일본어 선호도를 가진 것으로 나타난다면, 업셀 제안은 (예컨대, 일본어 사용자들 사이에서 인기있는 애플리케이션에 액세스하는 후원 서비스를 제안함으로써) 인구통계적으로 타겟팅할 수 있다. 또 다른 예로, 특정한 장치 상태를 가진 가입자(예컨대, 가입자 기록이 가입자가 아이폰을 사용한다는 데이터를 포함한다)는 이러한 장치 상태를 가진 가입자들에게 인기있는 업셀 제안으로 타겟팅될 수 있다.

업셀 제안들은 모든 있을 수 있는 선택들의 세트를 포함할 수 있거나, 또는 특정한 가입자의 특정한 이력 사용에 더 적합한 제안들로 제한될 수 있다. 예컨대, 가입자가 통상적으로 시간 단위당 약 5MB의 데이터를 소비한다면, 시스템은 (가능할지라도) 동시에 10MB, 100MB, 1GB, 10GB, 100GB의 업셀 제안들을 제공할 필요가 없으며, 대신 10MB(또는 예컨대, 10MB와 100MB)의 업셀 제안만을 전송한다. 가입자의 사용이 증가하면, 가입자는 더 큰 크기의 서비스 플랜들에 관해 안내받을 수 있다.

업셀 제안은 대안으로 서비스 플랜 컴포넌트에 추가될 수 있지만, 특정한 실시예에서, 서비스 플랜 카탈로그 레벨의 서비스 플랜 컴포넌트 내에서 식별될 수 있는 업셀 제안들조차도 수정하는 것이 유용하다고 간주되었다. 이런 방식으로, 예컨대 페이스북 플랜의 표준 업셀 컴포넌트들이 소정의 서비스 플랜 카탈로그 또는 특정한 가입자 그룹들을 위한 적절한 통지 또는 다른 구성들로 수정될 수 있다.

도 7의 예에서, 흐름도(700)는 LCP 에러 정책을 설정하는 모듈(714)에서 종료된다. LCP 에러는 트래픽 이벤트가 적용 가능한 서비스 플랜 정책과 매칭되지 않을 때 발생한다. 서비스 플랜 카탈로그에 대한 LCP 에러를 설정하면, LCP 에러는 세련된 방식으로 (예컨대, 트래픽 이벤트가 비활성 서비스 플랜에 따라 처리될 수 있다는 통지(가입자가 비활성 서비스 플랜을 활성화하는 옵션을 포함한다)를 가입자에게 전송함으로써) 처리될 수 있다. LCP 에러 통지 정책은 대안으로 서비스 플랜 컴포넌트에 추가될 수 있지만, 특정한 실시예에서, LCP 에러 정책은 항상 서비스 플랜 카탈로그 제안 내의 모든 활성 플랜들을 매칭하려는 시도의 끝에 이루어지기 때문에, 서비스 플랜 카탈로그 레벨에서 LCP 에러 정책 설정을 가능하게 하는 것이 유용하다고 간주되었다. 이는 서비스 플랜 설계 효율을 개선한다. 실시예 따라, 설계자는 (예컨대, 서비스 플랜 카탈로그를 리뷰하고, 매개변수를 변경해야 한다고 판단한 후) 매개변수들을 편집하기 위해 임의의 모듈로 되돌아갈 수 있다.

도 8은 액세스 네트워크와 네트워크 서비스 플랜 제공 샌드박스 시스템을 포함하는 시스템(800)의 일례를 도시한다. 시스템(800)은 액세스 네트워크(802)와 네트워크 서비스 플랜 제공 시스템(804)을 포함한다. 액세스 네트워크(802)는 도 1을 참조하여 설명된 것과 유사하다.

도 8의 예에서, 네트워크 서비스 플랜 제공 시스템(804)은 서비스 설계 센터(806)와 서비스 설계 샌드박스(808)를 포함한다. 개념상, 서비스 설계 센터(806)와 서비스 설계 샌드박스(808)는 설계 및/또는 제공 책임을 공유한다. 서비스 설계 센터(806)와 서비스 설계 샌드박스(808)는 계층적으로 조직화될 수 있다. 예컨대, 서비스 설계 센터(806)는 서비스 설계 샌드박스(808)에 소정의 역할들을 위임할 수 있고, 서비스 설계 센터(806)의 에이전트들에 대한 감독 능력을 보유하고 있다. 예컨대, 서비스 설계 샌드박스(808)에는, 네트워크 서비스 플랜 제공 시스템(804)의 가입자 그룹들의 서브세트에 정책 제어를 밀착시키는 능력이 주어질 수 있다. 네트워크 서비스 플랜 제공 시스템(804)은 본 예에서 "분산형"으로 참조될 수 있다.

자신의 네트워크들에 서비스 설계 샌드박스(808)를 포함하길 바랄 수 있는 개체들의 몇몇 예들로, 네트워크 서비스들을 소비하는 직원들이 있는 기업들, MVNO들, 애플리케이션 개발자들, 기프터들, 및 컴뮤니티-기반 조직들이 포함된다. 네트워크 서비스들을 소비하는 직원들이 있는 기업들의 경우, 서비스 설계 샌드박스(808)는 (통지 정책뿐만 아니라) 트래픽 제어 및 과금 정책에 대한 정밀-조정 제어를 가능하게 할 수 있다. XYZ 회사가 서비스 설계 샌드박스(808)를 제어한다고 가정한다. XYZ 회사는 XYZ 회사 인트라넷 상의 XYZ 회사 네트워크 서비스들에 특정된 서비스 플랜을 생성할 수 있고, 이는 XYZ 플랜으로 참조될 것이다. 구체적으로, XYZ 회사는 XYZ 회사 직원들을 위해 XYZ 회사 인트라넷 상의 XYZ 회사 네트워크 서비스들을 후원할 수 있다. 예컨대, 서비스 설계 센터(806)를 제어하는 캐리어에 의해 제안된 유료 플랜이 다른 네트워크 서비스들을 사용하는 중인 XYZ 회사 직원들에게 여전히 사용 가능할 수 있다(또는 XYZ 회사는 다른 네트워크 서비스들의 서브세트를 일부 후원할 수 있다). XYZ 플랜은 또한 XYZ 회사 직원들이 XYZ 회사 인트라넷을 통해 소정의 제한된 사이트들에 액세스하는 것을 방지하는 컴포넌트를 포함할 수 있고, 시도된 액세스와 연관된 통지 정책을 가지고 있다. 예를 계속하면, XYZ 회사의 에이전트(IT 관리자)는 XYZ 회사 구성원들을 포함하는 가입자 그룹들을 정의하고, 상이한 XYZ 회사 가입자 그룹들에게 상이한 서비스 플랜들(예컨대, 상이한 트래픽 제어, 통지, 또는 과금 정책들)을 배정할 수 있다. 예컨대, 직원들은 제한된 사용을 얻을 수 있고, 관리자들은 더 많은 사용 및 추가적인 서비스들(예컨대, 이메일)에 대한 액세스를 얻을 수 있으며, 판매팀의 구성원들은 더 나은 로밍 서비스들을 얻을 수 있고, CEO는 XYZ 회사가 모든 서비스들에 대한 후원자로 있는 캐리어의 서비스 플랜 제안 내의 모든 것을 얻을 수 있다. 유리하게는, 이러한 기법들을 사용하여 분할-청구(split-billing)가 가능하고, 그에 따라 XYZ 회사는 후원 서비스들에 대해 지불할 수 있고, XYZ 직원들은 비후원 서비스들에 대해(또는 보조 서비스들의 일부에 대해) 지불할 수 있다.

MVNO들의 경우, MVNO는 캐리어로부터 벌크 데이터를 구매하고, 벌크에 기반하여 플랜들을 제안할 수 있다. MVNO들에 유리하게, 서비스 설계 샌드박스(808)는 예컨대 네트워크 상태에 기반하여 가입자들에 대한 제어를 가능하게 한다. 실제로, MVNO에 의해 "소유된" 모든 가입자들에 대해, (캐리어가 MVNO에 부여하고자 하는 제어량에 기반하여) 상당한 정책 제어가 적용될 수 있다. 샌드박스 모델로부터 이점을 취할 수 있는 다른 제공자들로, 가상 이동 통신망 인에이블러들(Mobile Virtual Network Enablers, MVNE), 이동 공유 스펙트럼 인에이블러들(Mobile Shared Spectrum Enablers, MSSE), 및 서비스 제공자들(Service Providers, SP)이 포함된다.

애플리케이션 개발자들의 경우, 서비스 설계 샌드박스(808)는 서비스 플랜에 의해 커버될 수 있는 애플리케이션들을 명시할 수 있다. 서비스 설계 센터(806)는 기저 제어 메커니즘을 생성할 책임이 있을 수도 있고, 그렇지 않을 수도 있다. 예컨대, amazon.com과 같은 회사에는, amazon.com과 연관된 애플리케이션들을 위한 후원 설정들에 대한 일정한 제어가 주어질 수 있다.

기프터들의 경우, 서비스 설계 샌드박스(808)는 비영리기구와 같은 다른 조직에 기부된 후원량의 설명을 가능하게 할 수 있다. 컴뮤니티-기반 조직들의 경우, 서비스 설계 샌드박스(808)는 특정한 네트워크 서비스에 대한 무료 액세스를 명시할 수 있다. 예컨대, 샌프란시스코 자이언츠팀은 샌프란시스코 자이언츠의 공식 사이트에 대한 무료 액세스를 부여하는 팬들용 플랜 그룹을 가질 수 있다. 다른 예로, AAA는 AAA 구성원들용 서비스들에 대한 액세스를 후원할 수 있다.

네트워크 서비스 플랜 제공 시스템의 에이전트들에는, 서비스 설계 및/또는 제공의 소정의 양상들에 대한 액세스를 부여하는 역할들이 주어질 수 있다. 예컨대, 서비스 설계 센터(806)의 에이전트들은 시스템 운영자, 슈퍼 사용자 등의 역할을 가질 수 있는 반면, 서비스 설계 샌드박스(808)의 에이전트들은 기업 IT 관리자, MVNO 운영자 등과 같은 역할을 가질 수 있다. 서비스 설계 샌드박스(808)의 에이전트들은 실시에 따라, 적용 가능하다면, 역할들을 더 세분할 수 있다.

도 9는 서비스 설계 시스템 샌드박스 실시예의 일례의 개념도(900)를 도시한다. 개념도(900)는 캐리어 네트워크(902), 기존의 네트워크와 IT와 청구 하부구조(904)(하부구조(904)로 참조됨), 인터넷(906), 서비스 프로세서(908), 서비스 제어기(910), 사업자 서비스 설계 센터(SDC, 912), 및 파트너 SDC 샌드박스(914)를 포함한다. 도 9의 예에서, 캐리어 네트워크는 하부구조(904)를 통해 인터넷(906)에 연결된다.

서비스 프로세서(908)는 캐리어 네트워크(902)의 클라이언트 장치 상에서 실시될 수 있다. 특정한 실시예에서, 서비스 프로세서(908)는 서비스 제어 장치 링크를 포함한다. 예컨대, 네트워크 전체의 감독을 포함하는 장치 기반 서비스 제어 기법들이 더욱 정교해짐에 따라, 서비스 정책과 통신하거나 이를 제어, 감시, 또는 검증하는 네트워크 요소들과 장치 에이전트들 사이에 효율적이며 유연한 제어 평면 통신 링크를 가지는 것이 점점 더 중요해진다. 몇몇 구현예들에서, 서비스 제어 장치 링크는 네트워크 요소 기능들로의/로부터의 서비스 에이전트의 송수신을 위한 시스템의 장치측을 제공한다. 몇몇 구현예들에서, 이러한 링크의 트래픽 효율은 송신 시에 다수의 에이전트 메시지들을 버퍼링 및 프레이밍(framing) 함으로써 증진된다. 몇몇 구현예들에서, 트래픽 효율은 송신 빈도를 제어하거나 송신 빈도를 서비스 사용률 또는 트래픽 사용률에 링크함으로써 더욱 개선된다. 몇몇 구현예들에서, 보안 또는 암호화의 하나 이상의 레벨을 사용하여 링크를 탐색, 도청, 또는 노출에 강인하게 만든다. 몇몇 구현예들에서, 서비스 제어 장치 링크는 또한 에이전트 핵심 기능(agent heartbeat function)을 위한 핵심 타이밍과 통신 링크를 제공한다. 서비스 제어 장치 링크는 다른 네트워크 요소들과 서비스 정책 실시, 제어, 감시, 및 검증 정보를 송수신하기 위한 효율적이고 안전한 솔루션을 제공할 수 있다.

특정한 실시예에서, 클라이언트 대시보드가 서비스 프로세서(908)에 의해 표시 장치 내에 제시된다. 클라이언트 대시보드는: 서비스(구매됨, 데이터 사용), 통계(애플리케이션 소비 데이터, 절대항 또는 %로서 사용된 데이터), 구입(가입자를 활성화, 등록, 플랜 선택, 및 구매 워크플로우를 통해 안내), 도움말, 및 설정(선호도, 예컨대 언어)과 같은 메뉴들을 포함할 수 있다.

서비스 제어기(910)는 예컨대 클라우드 내에서 실시될 수 있고, 하부구조(904)에 연결된다.

사업자 SDC(912)는 인터넷 상에 있고, 서비스 제어기에 연결된다. 사업자 SDC(912)는 "샌드백스형(sandboxed)" 서비스를 위한 경계를 설정할 수 있고, 파트너 세트들을 위한 맞춤화를 허용할 수 있다: 소정의 파트너 세트 또는 개별 파트너에 대한 협상률에 기반하여 마스터 요금을 고정하고; 상이한 파트너 세트들 또는 개별 파트너들을 위한 맞춤형 로그인을 생성하며, 서비스 설계 시스템에 적절한 모든 적용 가능한 기법들을 수행한다. 사업자 SDC(912)는 승인된 에이전트들이 서비스 플랜 컴포넌트들과 가입자들을 관리하게 한다. 에이전트들은 그룹들(가입자들, SIM들, 또는 장치들의 집합들)을 관리하여, 그룹들 및 그룹 디렉토리들을 생성할 수 있고, 사업자를 위한 신원 계층, 그룹들과 연관된 식별자들 등을 배정할 수 있다. 에이전트들은 플랜명과 설명을 포함하는 서비스 플랜들(하나 이상의 컴포넌트를 포함), 플랜을 사용하는 그룹들, 서비스 플랜 컴포넌트들, 서비스 활동들, 네트워크 혼잡 상태들과 연결 유형들, 과금 정책들(사용 제한, 임계값, 빈도, 시간, 및 지불 유형을 포함), 통지들(예컨대, 플랜 사용 임계값, 플랜 캡, 만료, 차단, 오버리지, 가능한 플랜 없음 등), 및 이벤트들(예컨대, 플랜 사용 임계값, 플랜 캡, 만료, 차단, 오버리지 등)을 관리할 수 있다. 에이전트들은 컴포넌트명과 설명을 포함하는 서비스 컴포넌트들(하나 이상의 필터와 규칙의 논리적 그룹핑), 컴포넌트를 사용하는 플랜들, 네트워크 혼잡 상태들과 연결 유형들, 과금 정책들(사용 제한, 임계값, 빈도, 시간, 및 지불 유형을 포함), 통지들(예컨대, 플랜 사용 임계값, 플랜 캡, 만료, 차단, 오버리지, 가능한 플랜 없음 등), 및 이벤트들(예컨대, 플랜 사용 임계값, 플랜 캡, 만료, 차단, 오버리지 등)을 관리할 수 있다. 에이전트들은 서비스 활동들(예컨대, 활동명), 활동을 사용하는 플랜들, 활동을 사용하는 컴포넌트들, 필터명과 설명, 및 필터 유형 세부사항들(예컨대, 운영체계, 애플리케이션, 원격, 포트, 프로토콜 등)을 관리할 수 있다. 에이전트들은 플랜 그룹을 배정 및 공개하고, 활성화 워크플로우 화면들을 생성하며, 구입 워크플로우 화면들을 생성하는 과정을 포함하여, 서비스 그룹 플랜들을 관리할 수 있다. 에이전트들은 예컨대 일정 기간 동안 가입자에 대한 수신지별 사용 리포트들, 일정 기간 동안 다양한 가입자들에 대한 수신지별 사용 리포트들에 대한 리포트들을 수신, 관리, 맞춤화, 또는 생성할 수 있다(상위 수신지들).

파트너 SDC 샌드박스(914)는 적용 가능한 편리한 방식으로 사업자 SDC(912)에 연결된다. 파트너 SDC 샌드박스(914)는 SDC 서비스 관리 제어들의 서브세트가 설계되고/설계되거나 사용될 수 있는 안전한 로그인 환경을 제공하고; 관리 하에서 하나 이상의 장치 그룹을 위한 제한된 서비스 맞춤화 옵션들로부터의 선택을 가능하게 하며; 장치 UI 브랜딩(branding)을 맞춤화하고; 서비스 사용, 애플리케이션 사용, 위치 등에 대한 실시간 분석에 액세스하며; 서비스 사용 경고, 사기 경고, 절도 경고 등을 설정하고; 샌드박스형 환경에 위임된, 서비스 설계 시스템에 적절한 모든 적용 가능한 기법들을 수행할 수 있다.

서비스 제어기(910)는 서비스 제어 서버 링크를 포함한다. 특정한 실시예에서, (예컨대, 제어 평면 상의) 네트워크 전체의 감독을 포함하는 장치 기반 서비스 제어 기법들이 더욱 정교해지고, 이 때문에, 서비스 정책과 통신하거나 이를 제어, 감시, 또는 검증하는 (예컨대, 서비스 제어기(910)의) 네트워크 요소들과 (예컨대, 서비스 프로세서(908)의) 장치 에이전트들 사이에 효율적이며 유연한 제어 평면 통신 링크를 가지는 것이 점점 더 중요해진다. 예컨대, 서비스 제어기(910)의 서비스 제어 서버 링크와 서비스 프로세서(910)의 서비스 제어 장치 링크 사이의 통신 링크는 효율적이며 유연한 제어 평면 통신 링크를 제공할 수 있고; 몇몇 구현예들에서, 이러한 제어 평면 통신 링크는 서비스 프로세서(908)와 서비스 제어기(910) 사이의 안전한 양방향 통신을 제공하기 위한 안전한(예컨대, 암호화된) 통신 링크를 제공한다. 몇몇 구현예들에서, 서비스 제어 서버 링크는 네트워크 요소 기능들로의/로부터의 서비스 에이전트의 송수신을 위한 시스템의 네트워크측을 제공한다. 몇몇 구현예들에서, 이러한 링크의 트래픽 효율은 송신 시에 다수의 에이전트 메시지들을 버퍼링 및 프레이밍함으로써 (예컨대, 그로 인해 네트워크 채터를 감소시킴으로써) 증진된다. 몇몇 구현예들에서, 트래픽 효율은 송신 빈도를 제어하고/제어하거나 송신 빈도를 서비스 사용률 또는 트래픽 사용률에 링크함으로써 더욱 개선된다. 몇몇 구현예들에서, 보안 및/또는 암호화의 하나 이상의 레벨을 사용하여 링크 상의 통신의 잠재적 탐색, 도청, 또는 노출로부터 링크를 보호한다. 몇몇 구현예들에서, 서비스 제어 서버 링크는 또한 에이전트 핵심 기능을 위한 핵심 타이밍과 통신 링크를 제공한다. 몇몇 구현예들에서, 서비스 제어 서버 링크는 서비스 제어 링크 상에서 이러한 통신을 전송하기 전에, 통신을 확보, 서명, 암호화, 및/또는 달리 보호한다. 예컨대, 서비스 제어 서버 링크는 송신을 위해 링크층으로 직접 전송하거나 전송층으로 전송할 수 있다. 다른 예로, 서비스 제어 서버 링크는 TCP TLS 또는 다른 안전한 전송층 프로토콜과 같은 전송층 암호화로 통신을 추가로 보호한다. 또 다른 예로, 서비스 제어 서버 링크는, 예컨대 IPSEC, 다양한 있을 수 있는 VPN 서비스들, 다른 형태의 IP층 암호화 및/또는 다른 링크층 암호화 기법을 사용하여, 링크층에서 암호화할 수 있다.

특정한 실시예에서, 서비스 제어기(910)는 액세스 제어 무결성 서버(예컨대, 서비스 정책 보안 서버)를 포함할 수 있다. 몇몇 구현예들에서, 액세스 제어 무결성 서버는 서비스 정책, 서비스 사용, 에이전트 구성, 및/또는 에이전트 거동에 관한 장치 정보를 수집한다. 예컨대, 액세스 제어 무결성 서버는 이러한 정보를 교차 검사하여, 서비스 정책 실시 및 제어 시스템 내의 무결성 침해를 식별할 수 있다. 다른 예로, 액세스 제어 무결성 서버는 서비스 정책 위반(예컨대, QoS 정책 위반 및/또는 네트워크 용량 제어 서비스 정책 위반) 또는 시스템 무결성 침해가 의심될 때 액션을 개시할 수 있다.

특정한 실시예에서, 서비스 제어기(910)의 에이전트(및/또는 액세스 제어 무결성 서버의 다른 에이전트)는 액세스 제어 무결성 에이전트(예컨대, 서비스 정책 보안 에이전트) 리포트들과 에러 조건들에 따라 작동한다. 대부분의 액세스 제어 무결성 에이전트 검사들은 서버에 의해 달성될 수 있다. 예컨대, 액세스 제어 무결성 에이전트 검사들은: 정책들과 일치하는 사용 범위에 대한 서비스 사용 측정(예컨대, 네트워크 및/또는 장치로부터의 사용 측정); 에이전트들의 구성; 에이전트들의 동작; 및/또는 동적 에이전트 다운로드 중 하나 이상을 포함할 수 있다.

특정한 실시예에서, 서비스 제어기(910)의 에이전트(및/또는 액세스 제어 무결성 서버의 다른 에이전트)는, 시행되도록 의도된 정책들(예컨대, QoS 정책 및/또는 네트워크 용량 제어 서비스 정책)을 감안하여, 예상된 서비스 사용 거동과 (예컨대, IPDR들 또는 CDR들을 사용함에 의한 네트워크 감시 정보 및/또는 국부 서비스 사용 감시 정보에 기반한) 다양한 서비스 사용 측정값들을 비교함으로써, 장치 서비스 정책 실시들을 검증한다. 예컨대, 장치 서비스 정책 실시들은 통과된 총 QoS 데이터, 일정 기간에 통과된 QoS 데이터, IP 주소들, IP 주소당 데이터, 및/또는 위치, 다운로드, 액세스된 이메일, URL과 같은 다른 측정값들을 측정하는 과정, 및 시행되도록 의도된 정책들을 감안하여, 예상된 서비스 사용 거동과 이러한 측정값들을 비교하는 과정을 포함할 수 있다.

특정한 실시예에서, 서비스 제어기(910)의 에이전트(및/또는 액세스 제어 무결성 서버의 다른 에이전트)는 장치 서비스 정책을 검증하는데, QoS 서비스 측정값과 QoS 서비스 정책의 미스매치를 나타낼 수 있는 검증 에러 조건들은: 비승인 네트워크 액세스(예컨대, 엠비언트 서비스 제한을 넘어선 액세스); 비승인 네트워크 속도(예컨대, 서비스 정책 제한을 넘어선 평균 속도); QoS 정책 제한과 매칭되지 않는 네트워크 데이터량(예컨대, 장치가 서비스 정책을 재계약/개정하지 않으면서 제한에서 멈추지 않는다); 비승인 네트워크 주소; 비승인 서비스 사용(예컨대, VOIP, 이메일, 및/또는 웹 브라우징); 비승인 애플리케이션 사용(예컨대, 이메일, VOIP, 이메일, 및/또는 웹); 플랜의 너무 높은 서비스 사용률과, 이를 제어/감속하지 않는 정책 제어기; 및/또는 서비스 측정값과 서비스 정책의 다른 미스매치 중 하나 이상을 포함한다. 따라서, 몇몇 구현예들에서, 서비스 제어기(910)의 에이전트(및/또는 액세스 제어 무결성 서버의 다른 에이전트)는 정책/서비스 제어 무결성 서비스를 제공하여, 장치의 서비스 제어가 타협되지 않았고/않았거나 정책(예컨대, QoS 정책 및/또는 네트워크 용량 제어 서비스 정책)을 벗어나지 않았다는 것을 지속적으로(예컨대, 주기적으로 및/또는 트리거 이벤트들에 기반하여) 검증한다.

특정한 실시예에서, 서비스 제어기(910)는 서비스 이력 서버(예컨대, 과금 서버)를 포함한다. 몇몇 구현예들에서, 서비스 이력 서버는 예컨대 서비스 제어기(910)의 서비스 감시 에이전트 및/또는 액세스 네트워크 AAA 서버로부터 서비스 사용 또는 서비스 활동 리포트들을 수집 및 기록한다. 예컨대, 네트워크 요소들로부터의 서비스 사용 이력이 소정의 구현예들에서 장치로부터의 서비스 이력보다 덜 상세할 수 있지만, 예컨대 장치 상의 장치 에러 또는 타협 이벤트가 네트워크 기반 설비와 소프트웨어를 양보하는 것은 굉장히 어렵기 때문에, 네트워크로부터의 서비스 이력이 장치 서비스 정책 실시의 검증을 위한 귀중한 소스를 제공할 수 있다. 예컨대, 장치로부터의 서비스 이력 리포트들은 유사하게 전술한 바와 같이 다양한 서비스 추적 정보를 포함할 수 있다. 몇몇 구현예들에서, 서비스 이력 서버는 요청 시에 서비스 제어기(910)의 다른 에이전트들, 다른 서버들, 및/또는 하나 이상의 다른 에이전트에 서비스 이력을 제공한다. 몇몇 구현예들에서, 서비스 이력 서버는 장치 서비스 이력에 서비스 사용 이력을 제공한다(예컨대, CDR 피드 및 CDR 중재). 몇몇 구현예들에서, (후술하는) 활성화 추적 서비스 기능들을 용이하게 하기 위해, 서비스 이력 서버는 장치가 연결된 네트워크들의 이력을 유지한다. 예컨대, 이러한 네트워크 활동 개요는 액세스된 네트워크들, 연결당 활동 대비 시간, 및/또는 연결당 트래픽 대비 시간의 개요를 포함할 수 있다. 다른 예로, 이러한 활동 개요는 청구 공유 조정의 목적으로 트래픽 활동과 연관된 서비스 플랜의 유형을 추정하기 위해 추가로 분석 또는 보고될 수 있다.

특정한 실시예에서, 서비스 제어기(910)는 QoS 정책들 및/또는 네트워크 용량 제어 서비스 정책들과 같은 서비스 사용 정책들을 관리하기 위한 정책 관리 서버(예컨대, 정책 결정점(policy decision point, PDP) 서버)를 포함한다. 몇몇 구현예들에서, 정책 관리 서버는 서비스 제어 링크를 통해 서비스 프로세서(908)로 정책들을 송신한다. 몇몇 구현예들에서, 정책 관리 서버는 장치 서비스 프로파일에 따라 장치 상의 정책 설정들(예컨대, 다양한 구현예들과 관련하여 본원에 설명된 다양한 정책 설정들)을 관리한다. 몇몇 구현예들에서, 정책 관리 서버는 정책 실시 에이전트들(예컨대, 정책 실시 에이전트) 상에 즉각적인 정책들을 설정한다. 예컨대, 정책 관리 서버는 정책 설정들을 발행하고, 서비스 사용을 감시하며, 필요하다면 서비스 설정들을 수정할 수 있다. 예컨대, 네트워크가 서비스 사용 비용을 관리하는 것을 선호하는 사용자의 경우, 또는 임의의 적응성 정책 관리가 필요한 경우, 정책 관리 서버는 트래픽 및/또는 서비스 측정값들을 수집하고 새로운 정책 설정들을 발행하기 위해 장치와 비교적 높은 통신 빈도를 유지할 수 있다. 본 예에서, 장치 감시 서비스 측정값들과 임의의 사용자 서비스 정책 선호도 변화들이 주기적으로 및/또는 다양한 트리거들/이벤트들/요청들에 기반하여 정책 관리 서버에 보고된다. 본 예에서, 이러한 구성 요청들/정책 설정들이 네트워크 상에서 송신되는 동안 사용자 프라이버시의 다양한 양상들이 적절하게 유지되도록 보장하기 위해, 사용자 프라이버시 설정들은 일반적으로 정책 관리 서버와의 통신과 같이 네트워크와의 안전한 통신(예컨대, 안전한 서비스 제어 링크)을 필요로 한다. 예컨대, 정보가 서비스 정책 관리로 분류될 수 있고, 사용자 프라이버시를 유지하기 위해 CRM을 위해 사용된 다른 데이터베이스들로 전달되지 않을 수 있다.

몇몇 구현예들에서, 정책 관리 서버는 장치 상에 적응성 정책 관리를 제공한다. 예컨대, 정책 관리 서버는 정책 설정들과 목적들을 발행하며, 정책 적응 중 일부 또는 전부에 대해 장치 기반 정책 관리(예컨대, 서비스 프로세서(908))에 의존할 수 있다. 이러한 접근방안은 장치와의 더 적은 상호작용을 요구하여, 장치 정책 관리를 위해 서비스 제어 링크 상의 네트워크 채터를 감소시킬 수 있다(예컨대, 네트워크 채터는 전술한 다양한 서버/네트워크 기반 정책 관리 접근방안들에 대해 감소한다). 이러한 접근방안은 또한, 예컨대 민감한 정보(예컨대, 지리-위치 데이터, 웹사이트 이력, 및/또는 다른 민감한 정보)가 사용자의 승인 없이 네트워크에 전달되지 않도록, 사용자로 하여금 사용자 프라이버시 선호도들/설정들에 대한 장치 정책을 구성하게 함으로써, 견고한 사용자 프라이버시 구현예들을 제공할 수 있다. 몇몇 구현예들에서, 정책 관리 서버는 시각에 기반하여 서비스 정책을 조절한다. 몇몇 구현예들에서, 정책 관리 서버는 네트워크 유효성/용량의 측정값을 수신, 요청, 및/또는 달리 획득하고, 사용 가능한 네트워크 유효성/용량(예컨대, 네트워크 혼잡 상태)에 기반하여 트래픽 형상화 정책 및/또는 다른 정책 설정들을 조절한다.

특정한 실시예에서, 서비스 제어기(910)는 네트워크 트래픽 분석 서버를 포함한다. 몇몇 구현예들에서, 네트워크 트래픽 분석 서버는 장치들 및/또는 장치들의 그룹들에 대한 서비스 사용 이력을 수집/수신하고, 서비스 사용을 분석한다. 몇몇 구현예들에서, 네트워크 트래픽 분석 서버는 네트워크 서비스 품질 및/또는 서비스 수익성의 개선을 식별하기 위해 다양한 포맷들로 서비스 사용 통계를 제시한다. 몇몇 구현예들에서, 네트워크 트래픽 분석 서버는 잠재적 서비스 정책들에 대한 가변 설정들 하에서 네트워크에 대한 서비스 품질 및/또는 서비스 사용을 추정한다. 몇몇 구현예들에서, 네트워크 트래픽 분석 서버는 전체 네트워크 서비스 품질 또는 서비스 비용에 대한 문제점을 야기하는 하나 이상의 장치에 의한 실제 또는 잠재적 서비스 거동들을 식별한다. 몇몇 구현예들에서, 네트워크 트래픽 분석 서버는 잠재적 서비스 정책들에 대한 가변 설정들 하에서 네트워크에 대한 네트워크 유효성/용량을 추정한다. 몇몇 구현예들에서, 네트워크 트래픽 분석 서버는 전체 네트워크 유효성/용량에 영향을 주고/주거나 문제점을 야기하는 하나 이상의 장치에 의한 실제 또는 잠재적 서비스 거동들을 식별한다.

특정한 실시예에서, 서비스 제어기(910)는 베타 테스트 서버(예컨대, 정책 생성점 및 베타 테스트 서버)를 포함한다. 몇몇 구현예들에서, 베타 테스트 서버는 하나 이상의 장치에 후보 서비스 플랜 정책 설정들을 공개한다. 몇몇 구현예들에서, 베타 테스트 서버는 하나 이상의 후보 서비스 플랜 정책 설정에 대한 사용자 피드백 정보 또는 네트워크 서비스 사용의 개요 리포트들을 제공한다. 몇몇 구현예들에서, 베타 테스트 서버는, 상이한 후보 서비스 플랜 정책 설정들에 대한 베타 테스트 결과들을 비교하거나 또는 예컨대 네트워크 용량을 보호하기 위한 추가 정책 설정 최적화를 위한 최적의 후보들을 선택하는 메커니즘을 제공한다.

특정한 실시예에서, 서비스 제어기(910)는 서비스 다운로드 제어 서버(예컨대, 서비스 소프트웨어 다운로드 제어 서버)를 포함한다. 몇몇 구현예들에서, 서비스 다운로드 제어 서버는 본원에 설명된 바와 같이 장치 상의 서비스 소프트웨어 요소들(예컨대, 서비스 프로세서(908) 및/또는 서비스 프로세서(908)의 에이전트들/컴포넌트들)을 설치하고/설치하거나 업데이트하는 다운로드 기능을 제공한다.

특정한 실시예에서, 서비스 제어기(910)는 청구 이벤트 서버(예컨대, 마이크로-CDR 서버)를 포함한다. 몇몇 구현예들에서, 청구 이벤트 서버는 청구 이벤트들을 수집하고, 서비스 프로세서(908)에 서비스 플랜 정보를 제공하며, 서비스 프로세서(908)에 서비스 사용 업데이트들을 제공하고, 장치와 중앙 청구 서버 사이에서 인터페이스 역할을 하고/하거나, 소정의 전자상거래 청구 거래들을 위한 신뢰형 제3자 기능을 제공한다.

특정한 실시예에서, 서비스 프로세서(908)는 추가적인 액세스 제어층을 제공한다. 예컨대, 액세스 네트워크 AAA 서버는 중앙 제공자 액세스 네트워크와 서비스 제공자 네트워크 상에 장치들을 허용하기 위해 필요 액세스 네트워크 AAA 서비스들(예컨대, 장치 액세스층을 위한 액세스 제어 및 인증 기능들)을 제공할 수 있다. 몇몇 구현예들에서, 인터넷, 기업 네트워크, 및/또는 M2M(machine to machine) 네트워크와 같은 다른 네트워크들로의 액세스를 얻기 위해 장치에 다른 액세스 제어층이 요구된다. 몇몇 구현예들에서, 액세스 네트워크 AAA 서버는 또한, 장치를 위한 서비스를 유보하고 서비스 제어기(910)로부터 수신된 통신들에 기반하여 장치를 위한 서비스를 재개하는 능력을 제공한다. 몇몇 구현예들에서, 액세스 네트워크 AAA 서버는 또한, 장치 트래픽의 검역 네트워크로의 라우팅을 유도하거나 장치 검역 조건이 유발될 때 네트워크 액세스를 제한 또는 한정하는 능력을 제공한다. 몇몇 구현예들에서, 액세스 네트워크 AAA 서버는 또한 장치 네트워크 서비스 사용을 기록 및 보고한다.

몇몇 구현예들에서, 상이한 프로파일들이 선택된 네트워크 연결에 기반하여 선택되고(예컨대, WWAN, WLAN, WPAN, 이더넷 및/또는 DSL 네트워크 연결들을 위한 상이한 서비스 프로파일들/정책들), 이는 다중-모드 프로파일 설정으로 참조될 수 있다. 예컨대, 서비스 프로파일 설정들은, Wi-Fi(또는 예컨대, DSL/케이블 또는 위성 또는 T-1과 같은 다른 네트워크)가 아닌 경우, Wi-Fi 다음으로 실제 액세스 네트워크(예컨대, 홈 DSL/케이블 또는 작업 네트워크)에 기반할 수 있고, 이는 커피숍에서 Wi-Fi 네트워크에 액세스하는 것과 다르게 관찰된다. 예컨대, DSL 또는 T-1 백홀(backhaul) 상에 상당수의 사용자들이 있는 Wi-Fi 핫스팟 상황에서는, 서비스 제어기가 서비스 제공자 클라우드 또는 MVNO 클라우드 내에 안착될 수 있고, 서비스 제어들이 서비스 제공자에 의해 제안된 VSP 능력에 의해 제공될 수 있거나, 또는 서비스 제어기(910)가 액세스 네트워크 서비스 제공자와 아무런 연관 없이 스스로 서비스 제어기(910)를 사용하는 핫스팟 서비스 제공자에 의해 소유될 수 있다. 예컨대, 서비스 프로세서(908)는 QoS 또는 사용자 공유 규칙들에 따라 핫스팟에서 유효 대역폭을 분할하도록 서비스 제어기(910)에 의해 제어될 수 있다(예컨대, 몇몇 사용자들은 다른 사용자들보다 (예컨대, 잠재적으로 더 높은 서비스 지불에 대해) 더 높은 차별화된 우선순위를 가진다). 다른 예로, (예컨대, 본원에 유사하게 설명된 바와 같은) 엠비언트 서비스들이 검증된 서비스 프로세서들을 위한 핫스팟을 위해 제공될 수 있다.

몇몇 구현예들에서, 서비스 프로세서(908)와 서비스 제어기(910)는 사용자가 개별적으로 또는 패키지로서 조합하여 선택한 다수의 서비스 플랜들과 연관된 다수의 서비스 프로파일들을 배정할 수 있다. 예컨대, 장치는 무료 거래 서비스들을 포함하는 엠비언트 서비스들로 시작되며, 여기서 사용자는 기본 서비스(예컨대, 뉴스 서비스, 전자책, PND 서비스, 용량제 세션 인터넷)가 아닌 거래들 또는 이벤트들에 대해 지불하게 되고, 여기서 각각의 서비스는 거래 서비스들을 제공하기 위한 모든 보조 파트너 청구를 정확하게 담당하는 계정 능력에 의한 청구서에 의해 지원된다(예컨대, Barnes and Noble은 장치로부터 구매된 모든 책 또는 잡지 거래들을 위해, 전자책 서비스에 대해 지불하고 서비스 제공자에게 수익 분배를 제안할 수 있다). 몇몇 구현예들에서, 계정 서비스별 청구서는 또한 거래들을 추적할 수 있고, 몇몇 구현예들에서는 수익 분배를 위한 광고들을 추적할 수 있으며, 모두 본원에 설명된 서비스 감시 능력을 사용한다. 앞서 논의된 무료 엠비언트 서비스로 서비스들을 개시한 후에, 사용자는 이후 후불 월정액 인터넷, 이메일, 및 SMS 서비스를 선택할 수 있다. 이 경우, 서비스 제어기(910)는 네트워크 기반 청구의 경우 청구 시스템으로부터 신규 인터넷, 이메일, 및 SMS 서비스에 대한 청구 플랜 코드를 획득할 것이다(또는 예컨대, 서비스 제어기(910)는 장치 기반 청구의 경우 청구 이벤트 서버로부터 획득할 것이다). 몇몇 구현예들에서, 초기 엠비언트 서비스와 조합하여 새로운 서비스를 위한 적절한 서비스 프로파일을 발견하기 위해, 이러한 코드를 데이터베이스(예컨대, 정책 관리 서버) 내에서 교차 참조한다. 이후, 사용자가 엠비언트 서비스들에 대한 무료 액세스를 유지하도록 새로운 슈퍼세트 서비스 프로파일이 적용되고, 청구 파트너들은 이러한 서비스들을 계속 보조하며, 사용자는 또한 인터넷 서비스들에 대한 액세스를 얻고, (예컨대, 본원에 개시된 구현예들 중 하나로부터의) 서비스 제어 프로파일을 선택할 수 있다. 슈퍼세트 프로파일은 2개 이상의 서비스 프로파일들이 동일한 장치 서비스 프로세서에 적용될 때 프로파일들의 결합된 능력들을 제공하는 프로파일이다. 몇몇 구현예들에서, 2개 이상의 "스택 가능한" 서비스가 사용자에 의해 선택되거나 달리 장치에 적용될 때, 서비스 제어기(910)가 아닌 서비스 프로세서(908)가 슈퍼세트 프로파일을 결정할 수 있다. 본원에 설명된 서비스 프로세서(908)와 서비스 제어기(910) 구현예들의 유연성으로 인해, 다양한 서비스 프로파일들이 원하는 장치 서비스 특성들을 달성하기 위해 개별적으로 또는 슈퍼세트로서 정의 및 적용될 수 있다.

몇몇 구현예들에서, (예컨대, URL별, 네트워크 도메인별, 웹사이트별, 네트워크 트래픽 유형별, 애플리케이션 또는 애플리케이션 유형별, 및/또는 다른 서비스 사용 활동 범주/분류별) 다양한 감시된 활동들을 연관된 IP 주소들과 연관되게 하는 서비스 사용 활동들을 분류 또는 범주화하기 위한 활동맵을 제공하기 위한 장치 보조 서비스(device assisted services, DAS) 기법들을 제공한다. 몇몇 구현예들에서, 서비스 제어기(908)의 정책 제어 에이전트, 서비스 감시 에이전트(예컨대, 과금 에이전트), 또는 다른 에이전트 혹은 기능(또는 이들의 조합)은 DAS 활동맵을 제공한다. 몇몇 구현예들에서, 서비스 프로세서의 정책 제어 에이전트, 서비스 감시 에이전트, 또는 다른 에이전트 혹은 기능(또는 이들의 조합)은 (예컨대, URL별, 네트워크 도메인별, 웹사이트별, 네트워크 트래픽 유형별, (IP 주소, 프로토콜, 및/또는 포트와 같은) 소켓별, (포트 주소/번호와 같은) 소켓 ID별, 포트 번호별, 컨텐츠 유형별, 애플리케이션 또는 애플리케이션 유형별, 및/또는 다른 서비스 사용 활동 범주/분류별) 다양한 감시된 활동들을 연관된 IP 주소들 및/또는 다른 기준들/측정값들과 연관되게 하기 위해 서비스 사용 활동들을 분류 또는 범주화하기 위한 활동맵을 제공한다. 몇몇 구현예들에서, 서비스 프로세서의 정책 제어 에이전트, 서비스 감시 에이전트, 또는 다른 에이전트 혹은 기능(또는 이들의 조합)은 DNS 요청(들)을 스누핑(snoop)하기 위한 다양한 기법들을 사용하여, 감시된 서비스 사용 활동들을 위한 연관된 IP 주소들을 결정한다(예컨대, 장치(100) 상에서 이러한 스누핑 기법들을 수행함으로써, 역 DNS 룩업을 위한 네트워크 요청의 필요성 없이, 연관된 IP 주소들을 결정할 수 있다). 몇몇 구현예들에서, 서비스 프로세서의 정책 제어 에이전트, 서비스 감시 에이전트, 또는 다른 에이전트 혹은 기능(또는 이들의 조합)은 IP 주소들을 기록 및 보고하거나, 또는 감시된 서비스 사용 활동들을 위한 IP 주소들 또는 IP 주소들 및 연관된 URL들을 보고하는 DNS 룩업 기능을 포함한다. 예컨대, 서비스 프로세서의 정책 제어 에이전트, 서비스 감시 에이전트, 또는 다른 에이전트 혹은 기능(또는 이들의 조합)은 DNS 룩업 기능을 수행하기 위한 다양한 기법들을 사용하여(예컨대, 감시된 장치 상의 국부 DNS 캐시를 사용하여), 감시된 서비스 사용 활동들을 위한 연관된 IP 주소들을 결정할 수 있다. 몇몇 구현예들에서, 이러한 기법들 중 하나 이상을 사용하여, 예컨대 IP 주소들에 URL들을 맵핑하고, IP 주소들에 애플리케이션들을 맵핑하며, IP 주소들에 컨텐츠 유형들을 맵핑하고/맵핑하거나, IP 주소들에 적용 가능한 다른 범주화/분류를 맵핑하는 DAS 활동맵을 동적으로 구축 및 유지한다. 몇몇 구현예들에서, DAS 활동맵을 다양한 구현예들과 관련하여 본원에 설명된 바와 같은 다양한 DAS 트래픽 제어 및/또는 감속 기법들을 위해 사용하여, DAS를 위해 QoS를 제공하고/제공하거나, 네트워크 용량을 보호하기 위해 DAS를 제공한다. 몇몇 구현예들에서, DAS 활동맵을 사용하여, 다양한 구현예들과 관련하여 본원에 설명된 바와 같은 서비스 사용과 연관된 다양한 UI 관련 정보 및 통지 기법들을 사용자에게 제공한다. 몇몇 구현예들에서, DAS 활동맵을 사용하여, 서비스 사용 감시, 향후 서비스 사용의 예측/추정, 서비스 사용 청구(예컨대, 계정별 청구서 및/또는 다른 서비스 사용/청구 범주화 기법들), 엠비언트 서비스 사용 감시를 위한 DAS 기법들, 마이크로-CDR들을 생성하기 위한 DAS 기법들, 및/또는 다양한 구현예들과 관련하여 본원에 설명된 바와 같은 다른 다양한 DAS 관련 기술들 중 임의의 기술을 제공한다.

도 10은 서비스 설계 시스템 샌드박스 실시예의 일례의 개념도(1000)를 도시한다. 도 10의 컴포넌트들은 도 9에 도시된 컴포넌트들과 유사하다. 도 10은 다양한 샌드박스들이 다양한 목적들을 위해 생성될 수 있다는 것을 예시하도록 의도된다. 도 10의 예에서, 샌드박스들(1014)은 후원 애플리케이션&웹사이트 샌드박스들(1014-1), 기업 IT 관리자 샌드박스들(1014-2), M2M&가상 서비스 제공자(VSP)(MVNO) 파트너 샌드박스들(1014-3), 장치 OEM 매체 제공자 샌드박스들(1014-4), 부모 통제&다중-장치 샌드박스들(1014-5) 등을 포함한다. 서비스 제어기(1010)에 실시된 공통 서비스 제어기 클라우드 서비스 소프트웨어 및 서비스 프로세서(1008)에 실시된 서버 프로세서 장치 클라이언트 소프트웨어는 사업자들과 파트너들이 맞춤화된 사용자 경험들과 서비스 플랜 정책들을 평가(scale)하게 한다.

몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은: 네트워크 혼잡 상태, 시각, 서비스 활동이 연결된 네트워크, 서비스 활동이 연결된 기지국 또는 통신 채널, 사용자 입력, 사용자 선호도 선택, 연관된 서비스 플랜, 서비스 플랜 변경, 애플리케이션 거동, 메시지층 거동, 랜덤 백오프, 장치 전력 상태, 장치 사용 상태, 시간 기반 기준(예컨대, 시간/날짜/주/달, 향후 시간 슬롯을 위한 유지/지연/연기, 스케쥴링된 시간 슬롯을 위한 유지/지연/연기, 및/또는 혼잡 상태/유효 상태/QoS 상태가 달성될 때까지 유지/지연/연기), 사용자의 서비스 활동과의 상호작용의 감시, 사용자의 장치와의 상호작용의 감시, 서비스 활동을 위한 UI 우선순위의 상태, 서비스 활동의 전력 소모 거동의 감시, 모뎀 전력 사이클링 또는 전력 제어 상태 변화, 모뎀 통신 세션 설정 또는 분해(tear down), 및/또는 네트워크로부터의 정책 업데이트/수정/변경 중 하나 이상에 기반하여 동적이다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 네트워크 서비스 사용 활동의 업데이트된 서비스 사용 거동 분석에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 네트워크 용량 제어 서비스 분류에 대한 업데이트된 활동 거동 응답에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 (예컨대, 네트워크 용량 제어 서비스들을 위한 정책들/제어들에 관련된) 업데이트된 사용자 입력/선호도들에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 서비스 플랜 상태의 업데이트들에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 서비스 플랜 정책들의 업데이트들에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 대안적인 네트워크들의 유효성에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 대안적인 네트워크들을 선택하기 위한 정책 규칙들에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 대안적인 네트워크들에 대한 네트워크 혼잡 상태 또는 유효 상태에 기반한다. 몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은 소정의 네트워크 서비스 활동 또는 네트워크 서비스 활동들의 세트를 위한 특정한 네트워크 선택 또는 선호도 정책들에 기반한다.

몇몇 구현예들에서, 네트워크 서비스 사용 활동을 네트워크 서비스 사용 제어 정책 또는 네트워크 서비스 사용 통지 정책과 연관되게 하는 과정은: 네트워크 혼잡 상태, 시각, 사용자 입력/선호도, 연관된 서비스 플랜(예컨대, 25MB 데이터 플랜, 5G 데이터 플랜, 또는 무제한 데이터 플랜 또는 다른 데이터/서비스 사용 플랜), 애플리케이션 거동, 메시지층 거동, 장치 전력 상태, 장치 사용 상태, 시간 기반 기준, 대안적인 네트워크들의 유효성, 및 대안적인 네트워크들 중 하나 이상에서 트래픽을 선택하고/선택하거나 제어하기 위한 정책 규칙들의 세트 중 하나 이상에 기반하여 동적으로 연관되게 하는 과정을 포함한다.

몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은(예컨대, 네트워크 용량 제어 서비스 정책)은 하나 이상의 서비스 플랜을 위해 네트워크 서비스 사용 제어 정책을 정의하는 과정, 가족 및 기업 플랜들과 같은 단일 또는 다수 사용자 시나리오에서 하나 이상의 장치 또는 장치들의 그룹을 위해 네트워크 액세스 정책 규칙들을 정의하는 과정, 한 명 이상의 사용자 또는 사용자들의 그룹을 위해 네트워크 액세스 정책 규칙들을 정의하는 과정, 네트워크 액세스 이벤트들 또는 시도들을 허용 또는 비허용하는 과정, 네트워크 액세스 이벤트들 또는 시도들의 개수를 조절하는 과정, 네트워크 액세스 이벤트들 또는 시도들을 액세스 이벤트들 또는 시도들의 그룹으로 집합시키는 과정, 네트워크 액세스 이벤트들 또는 시도들을 타임 윈도윙(time windowing)하는 과정, 네트워크 액세스 이벤트들 또는 시도들에 의해 제공되는 애플리케이션 또는 기능에 기반하여 네트워크 액세스 이벤트들 또는 시도들을 타임 윈도윙하는 과정, 기결정된 타임 윈도우들에 네트워크 액세스 이벤트들 또는 시도들을 타임 윈도윙하는 과정, 네트워크 혼잡 상태의 측정값이 범위 내에 있는 타임 윈도우들에 네트워크 액세스 이벤트들 또는 시도들을 타임 윈도윙하는 과정, 허용 가능한 유형의 액세스 이벤트들 또는 시도들을 배정하는 과정, 허용된 네트워크 액세스 이벤트들 또는 시도들인 허용 가능한 기능들 또는 애플리케이션들을 배정하는 과정, 하나 이상의 네트워크 액세스 이벤트 또는 시도의 우선순위를 배정하는 과정, 네트워크 액세스 이벤트들 또는 시도들의 허용 가능한 지속 기간을 정의하는 과정, 네트워크 액세스 이벤트들 또는 시도들의 허용 가능한 속도를 정의하는 과정, 네트워크 액세스 이벤트들 또는 시도들을 위한 허용 가능한 네트워크 수신지들을 정의하는 과정, 네트워크 액세스 이벤트들 또는 시도들을 위한 허용 가능한 애플리케이션들을 정의하는 과정, 하나 이상의 네트워크 액세스 이벤트 또는 시도를 위한 QoS 규칙들을 정의하는 과정, 하나 이상의 애플리케이션을 위한 액세스 정책 규칙들을 정의 또는 설정하는 과정, 하나 이상의 네트워크 수신지를 위한 액세스 정책 규칙들을 정의 또는 설정하는 과정, 하나 이상의 장치를 위한 액세스 정책 규칙들을 정의 또는 설정하는 과정, 하나 이상의 네트워크 서비스를 위한 액세스 정책 규칙들을 정의 또는 설정하는 과정, 하나 이상의 트래픽 유형을 위한 액세스 정책 규칙들을 정의 또는 설정하는 과정, 하나 이상의 QoS 등급을 위한 액세스 정책 규칙들을 정의 또는 설정하는 과정, 장치, 애플리케이션, 네트워크 수신지, 네트워크 서비스, 트래픽 유형, QoS 등급, 및/또는 다른 기준들/측정값들의 임의의 조합에 기반하여 액세스 정책 규칙들을 정의 또는 설정하는 과정을 포함한다.

몇몇 구현예들에서, 네트워크 서비스 사용 제어 정책은(예컨대, 네트워크 용량 제어 서비스 정책)은 트래픽 제어 정책을 포함한다. 몇몇 구현예들에서, 트래픽 제어 정책은 트래픽 제어 설정을 포함한다. 몇몇 구현예들에서, 트래픽 제어 정책은 트래픽 제어/티어(tier)를 포함하고, 트래픽 제어/티어는 트래픽 제어 설정을 포함한다. 몇몇 구현예들에서, 트래픽 제어 정책은: 차단/허용 설정들, 감속 설정들, 적응성 감속 설정들, 패킷 에러율을 포함하는 QoS 등급 설정들, 지터 및 지연 설정들, 큐(queue) 설정들, 및 (예컨대, 소정의 트래픽 흐름들을 패킷 태깅하기 위한) 태그 설정들 중 하나 이상을 포함한다. 몇몇 구현예들에서, QoS 등급 설정들은: 감속 레벨, 다른 장치 트래픽에 대한 우선순위 큐잉, 타임 윈도우 매개변수들, 및 트래픽을 패킷들의 더 큰 스트림/버스트/패킷/그룹으로 축적 또는 집합시키는 동안의 유지 또는 지연 중 하나 이상을 포함한다. 몇몇 구현예들에서, 트래픽 제어 정책은 (예컨대, 캐스케이드 필터링 기법들을 사용하여) 정책 설정들의 상이한 리스트들에 대한 인덱스로서 실시된 필터들을 포함하고, 여기서 정책 필터들은: 네트워크, 서비스 플랜, 애플리케이션, 시각, 및 네트워크 혼잡 상태 중 하나 이상을 포함한다. 예컨대, 2차원 트래픽 제어 실시 스킴이 트래픽 제어 설정에 인덱스로서 네트워크 혼잡 상태 및/또는 시각을 사용하여 제공될 수 있다(예컨대, 소정의 애플리케이션의 우선순위 레벨은 네트워크 혼잡 상태 및/또는 시각에 기반하여 증감될 수 있다). 몇몇 구현예들에서, 트래픽 제어 정책을 사용하여, 사용 가능한 네트워크 리스트로부터 네트워크를 선택하고, 대안적인 네트워크에 연결이 이루어질 때까지 액세스를 차단 또는 감소시키고, 및/또는 애플리케이션들 또는 OS 기능들에 대한 네트워크 소켓 인터페이스 메시지들을 차단 또는 중단하도록 장치의 네트워크 스택 인터페이스를 수정 또는 교체한다.

몇몇 구현예들에서, 트래픽 제어 설정이 네트워크 서비스 사용 제어 정책에 기반하여 선택된다. 몇몇 구현예들에서, 트래픽 제어 설정은 네트워크 서비스 사용 제어 정책에 기반하여 장치 상에 실시된다. 몇몇 구현예들에서, 실시된 트래픽 제어 설정은 네트워크 용량 제어 서비스의 트래픽/트래픽 흐름들을 제어한다. 몇몇 구현예들에서, 트래픽 제어 설정은: 시각, 요일, 특정 시간/날짜(예컨대, 휴일 또는 네트워크 정비 시간/날짜), 네트워크 혼잡 상태, 네트워크 서비스 사용 활동과 연관된 우선순위 레벨, 네트워크 서비스 사용 활동과 연관된 QoS 등급(예컨대, 긴급 트래픽), 네트워크 서비스 활동이 액세스를 획득한 네트워크, 사용 가능한 네트워크들, 네트워크 서비스 활동이 연결된 네트워크, 네트워크 서비스 활동이 연결된 기지국 또는 통신 채널, 및 네트워크 서비스 활동이 액세스를 얻은 네트워크에 따라 변경될 수 있는 트래픽 제어 정책들의 네트워크 종속 세트(및/또는 본원에 전술한 바와 같은 다른 다양한 기준들/측정값들) 중 하나 이상에 기반하여 선택된다. 몇몇 구현예들에서, 트래픽 제어 설정은: 허용/차단, 지연, 감속, QoS 등급 실시, 큐, 태그, 사용자 통지 생성, 랜덤 백오프, 네트워크 요소로부터 수신된 CTS(clear to send), 스케쥴링된 송신 시간 슬롯의 유지, 사용 가능한 네트워크들로부터의 네트워크의 선택, 및 대안적인 네트워크에 연결이 이루어질 때까지의 액세스의 차단 또는 감소 중 하나 이상을 포함한다. 몇몇 구현예들에서, 트래픽 제어 설정은 네트워크 혼잡 상태와 네트워크 서비스 사용 활동의 네트워크 용량 제어 서비스 우선순위 상태에 기반하여 선택된다. 몇몇 구현예들에서, 트래픽 제어 설정은 네트워크 혼잡 상태와 네트워크 서비스 사용 활동의 네트워크 용량 제어 서비스 우선순위 상태에 기반하여 선택되며, 모든 네트워크 용량 제어 서비스 활동들에 대해 전체적이거나(예컨대, 동일하거나), 또는 네트워크 서비스 사용 활동 우선순위, 사용자 선호도 또는 옵션 선택, 애플리케이션, 시간 기반 기준, 서비스 플랜, 장치 또는 서비스 활동이 액세스를 얻은 네트워크, 사전 결정된 네트워크 혼잡 상태에 적응한 후의 네트워크 정체 상태의 재결정, 및/또는 본원에 설명된 바와 같은 다른 기준들/측정값들에 기반하여 변화된다.

몇몇 구현예들에서, 네트워크 용량 제어 서비스 트래픽(예컨대, 트래픽 흐름들)이 네트워크 용량을 보호하기 위해 차동 제어된다. 예컨대, 장치 상의 하나 이상의 애플리케이션 및 OS를 위한 다양한 소프트웨어 업데이트들이 본원에 설명된 다양한 기법들을 사용하여 차동 제어될 수 있다. 다른 예로, 보안/안티멀웨어(antimalware) 소프트웨어(예컨대, 안티바이러스, 방화벽, 컨텐츠 보호, 침입 검출/방지, 및/또는 다른 보안/안티멀웨어 소프트웨어)가 본원에 설명된 다양한 기법들을 사용하여 차동 제어될 수 있다. 또 다른 예로, 네트워크 백업/이미징, 컨텐츠 다운로드(예컨대, 이미지, 음악, 동영상, 전자책 컨텐츠, 이메일 첨부, 컨텐츠/매체 구독, RSS/뉴스 피드, 텍스트/이미지/화상 채팅, 소프트웨어 업데이트, 및/또는 다른 컨텐츠 다운로드에 대해, 개별적으로 및/또는 집합적으로 임계값을 초과)가 본원에 설명된 다양한 기법들을 사용하여 차동 제어될 수 있다.

예컨대, 본원에 설명된 네트워크 용량 기법들을 보호하기 위해 DAS를 사용하면, 네트워크 용량을 보호하기 위한 적응성 정책 제어를 제공할 수 있다. 네트워크 용량 제어 서비스 리스트가 장치에 의해 생성, 업데이트, 보고, 및/또는 수신되고, 장치 상에 저장될 수 있다(예컨대, 리스트는 장치와 연관된 서비스 플랜에 기반하거나 이에 적응될 수 있다). 감시된 네트워크 서비스 사용 활동이 리스트 상에 없으면, (예컨대, 네트워크 혼잡 상태에 기반하여, 시간 기반 기준 및/또는 다른 기준/측정값에 기반하여, 역시 소정의 임계값을 초과하는 감시된 네트워크 서비스 사용 활동에 대해) 장치는 감시된 네트워크 서비스 사용 활동을 네트워크 요소에 보고할 수 있다. 일례로, 감시된 네트워크 서비스 사용 활동이 데이터 사용 임계값(예컨대, 하루당 총 데이터 사용 50MB, 소켓 개방 빈도/속도, 순간적인 시간의 데이터 사용 속도, 또는 (일정 시간 동안, 피크 기간 동안, 컨텐츠 및 시간별, 다른 다양한 매개변수들/임계값들에 의한) 더 복잡한 임계값들을 초과한다면/초과할 때, 감시된 네트워크 서비스 사용 활동이 보고될 수 있다. 다른 예로, 감시된 네트워크 서비스 사용 활동은 애플리케이션 개발자 특성 입력 및/또는 네트워크 서비스 사용 거동의 테스트에 기반하여 보고될 수 있다. 리포트는 네트워크 서비스 사용 활동과 다양한 네트워크 서비스 사용 매개변수들을 식별하는 정보를 포함할 수 있다.

몇몇 구현예들에서, 통지 설정이 서비스 사용 통지 정책에 기반하여 선택된다. 몇몇 구현예들에서, 통지 설정은 사용자 통지 설정(예컨대, 도 18과 관련하여 전술한 바와 같은 다양한 사용자 통지들)을 포함한다.

몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은 (예컨대, 사용 임계값 필터 및/또는 캐스케이딩 필터 기법들을 사용하여) 네트워크 서비스 사용 활동을 네트워크 용량을 보호하기 위한 차동 네트워크 액세스 제어를 위한 복수의 분류 범주들 중 하나 이상으로 분류하는 과정을 더 포함한다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은 네트워크 서비스 사용 활동을 하나 이상의 네트워크 용량 제어 서비스로 분류하는 과정을 더 포함하고, 여기서 네트워크 용량 제어 서비스들은: 데이터 네트워크 액세스를 요구하는 애플리케이션들, 애플리케이션 소프트웨어 업데이트들, 네트워크 정보를 요구하는 애플리케이션들, GPS 또는 물리적 위치를 요구하는 애플리케이션들, 운영체계 소프트웨어 업데이트들, 보안 소프트웨어 업데이트들, 네트워크 기반 백업들, 이메일 다운로드들, 및 서비스 프로파일 및/또는 사용자 입력에 기반한 네트워크 용량 제어 서비스 활동들로서 구성된 활동들의 세트(및/또는 예컨대, 본원에 설명되고 당해 기술분야의 숙련자에게 이제 명백한 다른 다양한 유형의 네트워크 서비스 사용 활동들) 중 하나 이상을 포함한다. 예컨대, 네트워크 용량 제어 서비스들은: OS 및 애플리케이션들을 위한 소프트웨어 업데이트들, OS 배경 네트워크 액세스들, 클라우드 동기화 서비스들, RSS 피드&다른 배경 정보 피드, 브라우저/애플리케이션/장치 거동 보고, 배경 이메일 다운로드들, 컨텐츠 구독 서비스 업데이트들과 다운로드들(예컨대, 음악/동영상 다운로드들, 뉴스 피드들), 텍스트/음성/화상 채팅 클라이언트, 보안 업데이트들(예컨대, 안티멀웨어 업데이트들), P2P(peer-to-peer) 네트워킹 애플리케이션 업데이트들, 빈번한 전력 사이클링 또는 절전 상태 사이클링 동안의 비효율적 네트워크 액세스 시퀀스들, 대량 다운로드들 또는 다른 고대역폭 액세스들, 및 작은 정보 송신들 또는 요청들을 가지고 네트워크에 연속적으로/반복적으로 액세스하는 탐욕스런 애플리케이션 프로그램들을 포함할 수 있다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스 리스트는 정적이며, 적응적이고, 서비스 프로세서를 사용하여 생성되며, 네트워크 요소(예컨대, 서비스 제어기 또는 서비스 클라우드)로부터 수신되고, 네트워크 요소(예컨대, 서비스 제어기 또는 서비스 클라우드)로부터 수신되고, 서비스 프로세서로부터 수신된 장치 활동 리포트들에 적어도 부분적으로 기반하며, 사전-테스트에 의해 설정된 기준들, 애플리케이션 개발자에 의해 수행된 거동 특성화의 보고에 기반하고/기반하거나, 사용자 입력에 적어도 부분적으로 기반한다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스 리스트는 하나 이상의 네트워크 서비스 활동 배경(QoS) 등급을 포함한다.

몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은: 애플리케이션 또는 위젯(예컨대, 아웃룩, 스카이프, 아이튠즈, 안드로이드 이메일, 날씨 채널 날씨 위젯, 아이캘, 파이어폭스 브라우저 등), 애플리케이션 유형(예컨대, 사용자 애플리케이션, 시스템 애플리케이션/유틸리티/기능/프로세스, OS 애플리케이션/유틸리티/기능/프로세스, 이메일, 브라우저, 위젯, (바이러스 또는 수상한 프로세스와 같은) 멀웨어, RSS 피드, 장치 동기화 서비스, 다운로드 애플리케이션, 네트워크 백업/이미징 애플리케이션, 음성/화상 채팅, P2P 컨텐츠 애플리케이션 또는 다른 P2P 애플리케이션, 스트리밍 매체 피드 또는 방송 수신/송신 애플리케이션, 네트워크 미팅 애플리케이션, 채팅 애플리케이션 또는 세션, 및/또는 다른 애플리케이션 또는 프로세스 식별 및 범주화), OS/시스템 기능(예컨대, 임의의 시스템 애플리케이션/유틸리티/기능/프로세스, 및/또는 OS 업데이트 및/또는 OS 에러 보고와 같은 OS 애플리케이션/유틸리티/기능/프로세스), 모뎀 기능, 네트워크 통신 기능(예컨대, 네트워크 탐색 또는 시그널링, EtherType 메시지들, 연결 흐름/스트림/세션 설정 또는 분해, 네트워크 인증 또는 인증 시퀀스들, IP 주소 획득, 및 DNS 서비스들), URL 및/또는 도메인, 수신지/송신지 IP 주소, 프로토콜, 트래픽 유형, 소켓(예컨대, IP 주소, 프로토콜, 및/또는 포트), 소켓 주소/라벨/식별자(예컨대, 포트 주소/포트 번호), 컨텐츠 유형(예컨대, 이메일 다운로드, 이메일 텍스트, 동영상, 음악, 전자책, 위젯 업데이트 스트림, 및 다운로드 스트림), 포트(예컨대, 포트 번호), QoS 분류 레벨, 시각, 온-피크 또는 오프-피크, 네트워크 시간, 네트워크 혼잡 상태, 선택된 액세스 네트워크, 선택된 서비스 플랜, 사용자 선호도, 장치 인증서, 사용자 인증서, 및/또는 상태, 모뎀 전력 사이클링 또는 전력 상태 변화, 모뎀 인증 프로세스, 모뎀 링크 설정 또는 분해, 모뎀 관리 통신, 모뎀 소프트웨어 또는 펌웨어 업데이트, 모뎀 전력 관리 정보, 장치 전력 상태, 및 모뎀 전력 상태 중 하나 이상에 기반하여 네트워크 서비스 사용 활동을 분류하는 과정을 더 포함한다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은 분류된 네트워크 서비스 사용 활동을 ID(예컨대, 고유 번호, 이름, 및/또는 서명일 수 있는 예컨대 애플리케이션 ID)와 연관되게 하는 과정을 더 포함한다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은 애플리케이션 ID, 원격 IP(예컨대, URL, 도메인, 및/또는 IP 주소), 원격 포트, 프로토콜, 컨텐츠 유형, 필터 액션 등급(예컨대, 네트워크 혼잡 상태 등급, QoS 등급, 시각, 네트워크 혼잡 상태, 및/또는 다른 기준들/측정값들), 및 선택된 액세스 네트워크 중 하나 이상을 포함하는 복수의 분류 매개변수들을 사용하여 네트워크 서비스 사용 활동을 분류하는 과정을 더 포함한다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은 앞서 논의된 바와 같은 매개변수들의 조합을 사용하여 네트워크 서비스 사용 활동의 분류를 결정하는 과정을 더 포함한다.

몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은 네트워크 용량 제어 서비스, 비-네트워크 용량 제어 서비스, 차단 또는 비허용된 서비스, 및/또는 미분류/미식별 서비스(예컨대, 미지의/미판단 분류 또는 현안의 분류)로서 네트워크 서비스 사용 활동을 분류하는 과정을 더 포함한다. 몇몇 구현예들에서, 장치가 일정 기간 동안 비활성(또는 예컨대 절전 상태)인 경우(예컨대, 일정 기간 동안 사용자가 장치와 상호작용하지 않은 경우, 일정 기간 동안 장치가 사용자 통지 정책을 표시하지 않고/않거나 사용자 입력이 수신되지 않은 경우, 및/또는 절전 상태가 입력된 경우), 애플리케이션 연결, OS 연결, 및/또는 다른 서비스 활동이 네트워크 용량 제어 서비스 활동으로서 분류된다. 몇몇 구현예들에서, 감시된 네트워크 서비스 사용 활동이 2개 이상의 애플리케이션 연결, OS 연결, 및/또는 다른 서비스 활동에 대해 데이터 사용 임계값을 초과하거나(예컨대, 집합된 데이터 사용이 데이터 사용 임계값을 초과), 또는 특정한 애플리케이션 연결에 대해 데이터 사용 임계값을 초과한 경우, 애플리케이션 연결, OS 연결, 및/또는 다른 서비스 활동이 네트워크 용량 제어 서비스 활동으로서 분류된다. 몇몇 구현예들에서, 감시된 네트워크 서비스 사용 활동이 하나 이상의 데이터 사용 제한의 기결정된 리스트에 기반하여, 네트워크 요소로부터 수신된 리스트, 사용 시간 제한(예컨대, 사용 제한을 초과하는 기간에 기반함)에 기반하여, 및/또는 다른 사용 관련 기준들/측정값들에 기반하여, 데이터 사용 임계값을 초과한 경우, 애플리케이션 연결, OS 연결, 및/또는 다른 서비스 활동이 네트워크 용량 제어 서비스 활동으로서 분류된다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동을 분류하는 과정은 네트워크 피크 시간, 네트워크 혼잡 상태, 또는 소정의 성능 레벨 미만의 장치에 대한 네트워크 연결에 기반하여, 네트워크 서비스 사용 활동을 네트워크 용량 제어 서비스로서 분류하는 과정을 더 포함한다(예컨대, 이러한 다양한 기준들/다른 입력들/인자들에 기반하여 더 높은/더 낮은 우선순위들이 배정된다).

몇몇 구현예들에서, 네트워크 용량 제어 서비스들 중 하나 이상은 하나 이상의 네트워크 및/또는 하나 이상의 대안적인 네트워크를 위한 상이한 네트워크 액세스 정책 세트와 연관된다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스들 중 하나 이상은 하나 이상의 네트워크 및/또는 하나 이상의 대안적인 네트워크를 위한 상이한 통지 정책 세트와 연관된다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스 리스트는 장치 상에 저장된다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스 리스트는 네트워크 요소로부터 수신되거나 주기적으로 업데이트되며, 장치 상에 저장된다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스 리스트는 네트워크 용량 제어 서비스들, 비-네트워크 용량 제어 서비스들(예컨대, 전경 서비스들 또는 다양한 있을 수 있는 동적 기준들에 기반한 서비스들이 네트워크 용량 제어 서비스들로서 분류되지 않는다), 및 비분류된 서비스들의 세트(예컨대, 네트워크 요소, 서비스 제공자, 및/또는 사용자로부터의 추가 분석 및/또는 입력에 기반하여 분류를 미루고 있는 하나 이상의 네트워크 서비스 활동을 포함하는 그레이 리스트)를 포함한다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스 리스트는: (예컨대, 네트워크, 서비스 플랜, 사전-테스트, 및/또는 애플리케이션에 의해 특징지어진) 기정의된/기지정된 기준들; (예컨대, 서비스 프로세서를 사용한) 장치 보조/기반 감시; (예컨대, DPI 게이트웨이를 사용한) 네트워크 기반 감시; (예컨대, DAS 활동 분석의 장치 리포트들에 기반한) 네트워크 보조 분석 중 하나 이상에 기반한다. 예컨대, 장치는 장치 감시 네트워크 서비스 사용 활동들(예컨대, 모든 감시된 네트워크 서비스 사용 활동들, 또는 구성, 임계값, 서비스 플랜, 네트워크, 및/또는 사용자 입력에 기반한 서브세트)을 네트워크 요소에 보고할 수 있다. 다른 예로, 네트워크 요소는 네트워크 용량 제어 서비스 리스트를 업데이트하고, 업데이트된 리스트를 장치로 전송할 수 있다. 또 다른 예로, 네트워크 요소는 장치 기반 및/또는 네트워크 기반 네트워크 서비스 사용 활동 감시/보고에 기반하여 복수의 장치들에 걸쳐 네트워크 서비스 활동들의 통계 분석을 수행할 수 있다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동은 (예컨대, 팝업 및/또는 다른 기준들/측정값들과 같이 장치 및/또는 네트워크 서비스 사용 활동과의 사용자 상호작용에 기반한) 활성 애플리케이션 또는 프로세서인 것으로 판단된다.

몇몇 구현예들에서, 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정이 다양한 기법들을 사용하여 제공된다. 몇몇 구현예들에서, 장치는 네트워크 서비스 사용이 (예컨대, 다양한 측정점들을 사용하여) 제어 또는 관리되는 네트워크 서비스 활동에 의해 생성된 UI 메시지들, 통지들 또는 다른 UI 통신들을 방해, 차단, 수정, 제거 또는 교체하기 위한 서비스 프로세서 에이전트 또는 기능을 포함한다. 예컨대, 이러한 기법은 개선된 사용자 경험을 제공하기 위해(예컨대, 네트워크 용량을 보호하기 위해 제어되는 중인 애플리케이션이 사용자를 향해 반복적 및/또는 혼란스러운 메시지들/경고들을 생성하지 않게 하기 위해) 사용될 수 있다. 몇몇 구현예들에서, 장치의 네트워크 스택 인터페이스가 애플리케이션들 또는 OS 기능들 또는 다른 기능들/소프트웨어에 대한 네트워크 소켓 인터페이스 메시지들을 차단 또는 중단하도록 교체 또는 수정된다.

몇몇 구현예들에서, DAS 기법들을 사용하여 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 네트워크 서비스 사용 활동이 네트워크 용량 제어를 인지하지 못하는(예컨대, 네트워크 용량 제어를 실시하기 위한 API 또는 다른 인터페이스를 지원하지 않는) 다양한 기법들을 사용하여 제공된다. 예컨대, 네트워크 서비스 애플리케이션 메시징 인터페이스 기반 기법들이 트래픽 제어를 실시하기 위해 사용될 수 있다. 예시적인 네트워크 서비스 애플리케이션 메시징 인터페이스들로는: 네트워크 스택 API, 네트워크 통신 스트림/흐름 인터페이스, 네트워크 스택 API 메시지들, EtherType 메시지들, ARP 메시지들, 및/또는 다른 메시징 또는 다른 혹은 유사한 기법들이 포함되며, 이들은 이제 본원에 설명된 다양한 구현예들을 고려할 때 당해 기술분야의 숙련자에게 명백할 것이다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동 제어 정책들 또는 네트워크 서비스 활동 메시지들은 트래픽 제어 정책들 또는 서비스 활동 메시지들의 세트에 기반하여 선택되고, 이는 네트워크 서비스 활동에 적용된 네트워크 용량 제어 서비스 활동 정책들로 인해 서비스 활동에 의한 사용자 통지의 감소 또는 수정으로 이어진다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동 제어 정책들 또는 네트워크 서비스 활동 메시지들은 트래픽 제어 정책들 또는 서비스 활동 메시지들의 세트에 기반하여 선택되고, 이는 네트워크 서비스 활동에 적용된 네트워크 용량 제어 서비스 활동 정책들로 인해 장치 동작의 중단(disruption) 감소로 이어진다. 몇몇 구현예들에서, 네트워크 서비스 사용 활동 제어 정책들 또는 네트워크 서비스 활동 메시지들은 트래픽 제어 정책들 또는 서비스 활동 메시지들의 세트에 기반하여 선택되고, 이는 네트워크 서비스 활동에 적용된 네트워크 용량 제어 서비스 활동 정책들로 인해 네트워크 서비스 활동 동작의 중단 감소로 이어진다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 개방/연결/기입을 차단함으로써 제공된다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 스택 API 레벨 또는 애플리케이션 메시지층 요청들(예컨대, 소켓 개방/전송 요청들)을 차단함으로써 제공된다. 예컨대, 차단된 요청은 (예컨대, 메모리로) 복사되고, 큐잉(예컨대, 지연 또는 감속)되거나 드롭(예컨대, 차단)될 수 있다. 다른 예로, 차단된 요청은 메모리 내로 복사될 수 있고, 이후 송신의 일부가 메모리로부터 검색되고, 재주입(예컨대, 감속)될 수 있다. 또 다른 예로, 메시지 송신들을 차단하는 과정은 인라인 분석되고, 송신 허용(예컨대, 허용)될 수 있고, 송신 또는 송신의 일부는 트래픽 흐름을 분류하기 위해 메모리로 복사될 수 있다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 UI 통지들을 차단 또는 제어 또는 조절함으로써 제공된다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 네트워크 서비스 활동을 제거하거나 유보함으로써 제공된다. 몇몇 구현예들에서, 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 서비스 활동과 연관된 프로세스(들)의 우선순위를 제거함으로써 제공된다(예컨대, CPU 스케쥴링 우선순위 제거).

몇몇 구현예들에서, 네트워크 용량 제어를 인지하지 못하는 네트워크 서비스 사용 활동들에 대해, DAS 기법들을 사용하여 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 네트워크 API 메시징을 모방함으로써(예컨대, 스푸핑 또는 모방된(spoofed or emulated) 네트워크 API를 효과적으로 제공함으로써) 제공된다. 예컨대, 모방된 네트워크 API는 네트워크 소켓 애플리케이션 인터페이스 메시지들 및/또는 EtherType 메시지들(예컨대, EWOULDBLOCK, ENETDOWN, ENETUNREACH, EHOSTDOWN, EHOSTUNREACH, EALRADY, EINPROGRESS, ECONNREFUSED, EINPROGRESS, ETIMEDOUT, 및 이러한 다른 메시지들)을 방해, 수정, 차단, 제거, 및/또는 교체할 수 있다. 다른 예로, 모방된 네트워크 API는 네트워크 서비스 활동 서비스 사용 거동의 제어 또는 관리를 제공하는 네트워크 소켓 애플리케이션 인터페이스 메시지들(소켓(), 연결(), 판독(), 기입(), 폐쇄(), 및 이러한 다른 메시지들)을 수정, 교환, 및/또는 주입할 수 있다. 또 다른 예로, 연결이 개방 허용되기 전에(예컨대, 소켓이 개방되기 전에), 송신 또는 흐름/스트림이 개시되고, 이는 차단되며, 메시지(예컨대, 애플리케이션이 네트워크 액세스 시도가 허용되지 않거나 차단되었고, 네트워크가 사용 가능하지 않고/않거나, 요청된 네트워크 액세스를 위해 이후 다시 시도하는 것을 나타낸다고 이해 및 해석할 수 있는, 동기 요청에 응답하는 리셋 메시지 또는 다른 메시지)가 다시 애플리케이션으로 전송된다. 또 다른 예로, 소켓이 개방 허용될 수 있지만, (예컨대, 네트워크 서비스 사용, 네트워크 혼잡 상태, 시간 기반 기준들, 및/또는 다른 기준들/측정값들에 기반하는) 소정 시점 후에, 스트림이 차단되거나 소켓이 종료된다. 또 다른 예로, 예컨대 일정 기간 동안 네트워크 액세스를 허용하고, 일정 기간 동안 차단하고, 이후 반복하여 무작위로 또는 결정론적으로 네트워크 액세스를 효과적으로 확산시킴으로써, 타임 윈도우 기반 트래픽 제어 기법들이 (예컨대, 비-피크, 네트워크 혼잡 상태가 아닌 시간 동안) 실시될 수 있다. 이러한 기법들을 사용하면, 네트워크 용량 제어 기반 트래픽 제어를 인지하지 못하는 애플리케이션이 표준 메시징을 송수신할 수 있고, 장치는 네트워크 서비스 사용 활동(예컨대, 애플리케이션 또는 OS 또는 소프트웨어 기능)이 통상적으로 예측 가능한 방식으로 이해하고 응답할 수 있는 메시징을 사용하여 네트워크 용량 제어 정책에 기반하여 트래픽 제어를 실시할 수 있고, 이는 이제 당해 기술분야의 숙련자에게 명백할 것이다.

몇몇 구현예들에서, DAS 기법들을 사용하여 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 네트워크 서비스 사용 활동이 네트워크 용량 제어를 인지하지 못하는(예컨대, 네트워크 서비스 사용 활동이 네트워크 용량 제어를 실시하기 위한 API 또는 다른 인터페이스를 지원하지 않는) 다양한 기법들을 사용하여 제공된다. 예컨대, 본원에 설명된 바와 같은 네트워크 액세스 API를 사용하여 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시할 수 있다. 몇몇 구현예들에서, API는: 네트워크 액세스 조건들, 하나 이상의 네트워크 또는 대안적인 네트워크의 네트워크 혼잡 상태 또는 네트워크 유효 상태, 하나 이상의 네트워크 용량 제어 서비스 정책(예컨대, 네트워크 서비스는 허용/차단, 감속, 큐잉, 스케쥴링된 시간/시간 슬롯, 및/또는 연기와 같은 현재 네트워크 액세스 설정으로 이루어질 수 있고, 이는 예컨대 현재 네트워크, 현재 네트워크 혼잡 상태, 시간 기반 기준, 서비스 플랜, 네트워크 서비스 분류, 및/또는 다른 기준들/측정들에 기반할 수 있다), 네트워크 서비스 활동으로부터의 네트워크 액세스 요청, 네트워크 서비스 활동에 대한 질의/설문 요청, (예컨대, 우선순위 설정 및/또는 네트워크 용량 제어 서비스 분류, 스케쥴링된 시간/시간 슬롯, 대안적인 네트워크, 및/또는 다른 기준들/측정값들을 포함하는) 네트워크 서비스 활동에 대한 네트워크 액세스 허가, 네트워크 혼잡 상태 또는 네트워크 유효 상태 또는 네트워크 QoS 상태 중 하나 이상의 전달을 용이하게 한다.

몇몇 구현예들에서, 네트워크 보조/기반 기법들을 사용하여 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 네트워크 서비스 사용 활동이 네트워크 용량 제어를 인지하지 못하는(예컨대, 네트워크 용량 제어를 실시하기 위한 API 또는 다른 인터페이스를 지원하지 않는) 다양한 기법들을 사용하여 제공된다. 몇몇 구현예들에서, DPI 기반 기법들을 사용하여 네트워크 용량 제어 서비스들을 제어한다(예컨대, DPI 게이트웨이에서 네트워크 용량 제어 서비스들을 차단 또는 감속한다).

몇몇 구현예들에서, 네트워크 보조/기반 기법들을 사용하여 네트워크 용량 제어 서비스들을 위한 트래픽 제어를 실시하는 과정은 네트워크 서비스 사용 활동이 네트워크 용량 제어를 인지하는(예컨대, 네트워크 용량 제어를 실시하기 위한 API 또는 다른 인터페이스를 지원하는) 다양한 기법들을 사용하여 제공된다. 몇몇 구현예들에서, 애플리케이션/메시지층(예컨대, 본원에 설명된 바와 같은 네트워크 API)을 사용하여 네트워크 서비스 활동과 통신하여, 연관된 네트워크 용량 제어 서비스 분류들 및/또는 우선순위들, 하나 이상의 네트워크 또는 대안적인 네트워크의 네트워크 혼잡 상태 정보 또는 네트워크 유효성, 네트워크 액세스 요청 및 응답, 및 본원에 유사하게 설명된 바와 같은 다른 기준들/측정값들을 제공한다.

몇몇 구현예들에서, 네트워크 용량을 보호하기 위한 DAS는 (예컨대, 네트워크 용량 제어 서비스들을 포함하는) 네트워크 서비스 사용 활동들에 기반한 차동 과금을 위한 서비스 플랜을 실시하는 과정을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 네트워크 용량 제어 서비스들을 위한 차동 과금을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 네트워크 용량 제어 서비스들을 위한 캡 네트워크 서비스 사용을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 캡을 초과할 때의 통지를 포함한다. 몇몇 구현예들에서, 서비스 플랜은 캡을 초과할 때의 오버리지 과금을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 사용자 입력에 기반하여 과금을 수정하는 과정을 포함한다(예컨대, 본원에 설명된 바와 같은 사용자 오버라이드 선택으로, 여기서 예컨대 오버리지 과금은 네트워크 용량 제어 서비스들에 대해 및/또는 우선순위 레벨들에 기반하여 및/또는 현재 액세스 네트워크에 기반하여 상이하다). 몇몇 구현예들에서, 서비스 플랜은 네트워크 용량 제어 서비스들에 대한 시간 기반 기준 제한들(예컨대, 오버라이드 옵션이 있거나 없는 시각 제한들)을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 네트워크 용량 제어 서비스들에 대한 네트워크 혼잡 상태 기반 기준 제한들(예컨대, 오버라이드 옵션이 있거나 없다)을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 오버라이드될 네트워크 서비스 활동 제어들을 제공한다(예컨대, 1회, 타임 윈도우, 사용량 또는 영구적)(예컨대, 오버라이드에 대한 차동 과금, 오버라이드에 대한 차동 캡, 액션 기반 UI 통지 옵션을 가진 오버라이드, 및/또는 UI 설정을 가진 오버라이드). 몇몇 구현예들에서, 서비스 플랜은 패밀리 플랜 또는 다중-사용자 플랜(예컨대, 다양한 사용자들을 위한 다양한 네트워크 용량 제어 서비스 설정들)을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 다중-장치 플랜(예컨대, 스마트폰 v, 랩톱 v, 넷북 v, 전자책과 같은 다양한 장치들을 위한 다양한 네트워크 용량 제어 서비스 설정들)을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 일정 시각, 네트워크 혼잡 상태(들), 및/또는 다른 기준들/측정값을 위한 무료 네트워크 용량 제어 서비스 사용을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 네트워크 용량 제어 서비스들을 위한 네트워크 종속 과금을 포함한다. 몇몇 구현예들에서, 서비스 플랜은 네트워크 용량 제어 서비스들을 위한 네트워크 선호도/우선순위화를 포함한다. 몇몇 구현예들에서, 서비스 플랜은 수신지, 애플리케이션, 또는 다른 네트워크 용량 제어 서비스에 제공된 액세스에 대해 캐리어 파트너 혹은 후원 서비스 파트너에게 청구하기 위한 중재 청구(arbitration billing)를 포함한다. 몇몇 구현예들에서, 서비스 플랜은 수신지, 애플리케이션, 또는 다른 네트워크 용량 제어 서비스에 제공된 액세스에 대해 애플리케이션 개발자에게 청구하기 위한 중재 청구를 포함한다.

몇몇 응용 시나리오들에서, 초과 네트워크 용량 수요가 장치 상의 모뎀 전력 상태 변화들에 의해 야기될 수 있다. 예컨대, 모뎀이 네트워크에 연결되지 않은 절전 상태에 있을 때, 애플리케이션 또는 OS 기능이 어떤 이유로든 네트워크 연결을 시도하는 경우, 이는 모뎀으로 하여금 절전 상태를 변경하고, 네트워크에 재연결되며, 이후 애플리케이션 네트워크 연결을 개시하게 할 수 있다. 어떤 경우, 이는 또한 네트워크가 모뎀 연결 세션(예컨대, PPP 세션)을 재개할 수 있게 하고, 이는 기본 모뎀 연결에 의해 소비된 네트워크 용량 외에도, PPP 세션을 설정하기 위한 네트워크 자원들도 소비한다. 따라서, 몇몇 구현예들에서, 모뎀 전력 제어 상태 또는 네트워크 연결 상태를 변경하지 않도록 애플리케이션들, OS 기능들, 및/또는 다른 네트워크 서비스 사용 활동들(예컨대, 네트워크 용량 제어 서비스들)의 능력을 제한 또는 제어하는 네트워크 서비스 사용 활동 제어 정책들을 실시한다. 몇몇 구현예들에서, 소정의 타임 윈도우에 도달할 때까지 서비스 사용 활동이 모뎀을 각성시키거나, 모뎀의 전력 상태를 변경하거나, 모뎀이 네트워크에 연결되게 하는 것을 방지 또는 제한한다. 몇몇 구현예들에서, 서비스 사용 활동이 모뎀을 각성시키거나, 모뎀의 전력 상태를 변경하거나, 모뎀이 네트워크에 연결되게 할 수 있는 빈도를 제한한다. 몇몇 구현예들에서, 시간 지연이 지날 때까지 네트워크 서비스 사용 활동이 모뎀을 각성시키거나, 모뎀의 전력 상태를 변경하거나, 모뎀이 네트워크에 연결되게 하는 것을 방지한다. 몇몇 구현예들에서, 다수의 네트워크 서비스 사용 활동들이 모뎀 상태 변경을 요구할 때까지 또는 네트워크 서비스 사용 활동이 네트워크 용량 및/또는 네트워크 자원 활용 효율을 개선하기 위해 집합될 때까지, 네트워크 서비스 사용 활동이 모뎀을 각성시키거나, 모뎀의 전력 상태를 변경하거나, 모뎀이 네트워크에 연결되게 하는 것을 방지한다. 몇몇 구현예들에서, 모뎀의 전력 상태를 변경하는 네트워크 서비스 사용 활동의 능력을 제한하는 과정은 활동이 모뎀의 전력을 오프하거나, 모뎀을 슬립 모드에 놓거나, 모뎀을 네트워크로부터 분리하는 것을 허용하지 않는 과정을 포함한다. 몇몇 구현예들에서, 모뎀을 각성시키고, 모뎀의 전력 상태를 변경하거나, 모뎀이 네트워크에 연결되게 하는 네트워크 서비스 사용 활동에 대한 이러한 제한들은 모뎀으로의 중앙 네트워크 기능(예컨대, 서비스 제어기 또는 다른 네트워크 요소/기능) 정책 전달에 의해 설정된다. 몇몇 구현예들에서, 이러한 전력 제어 상태 정책들은 중앙 네트워크 기능에 의해 업데이트된다.

도 11은 본 명세서에 설명된 기법들이 실시될 수 있는 컴퓨터 시스템(1100)의 일례를 도시한다. 컴퓨터 시스템(1100)은 무선 클라인언트 또는 워크스테이션과 같은 클라이언트 컴퓨터 시스템, 또는 서버 컴퓨터 시스템으로서 사용될 수 있는 종래의 컴퓨터 시스템일 수 있다. 컴퓨터 시스템(1100)은 컴퓨터(1102), I/O 장치들(1104), 및 표시 장치(1106)를 포함한다. 컴퓨터(1102)는 프로세서(1108), 통신 인터페이스(1110), 메모리(1112), 표시 제어기(1114), 비휘발성 저장 장치(1116), 및 I/O 제어기(1118)를 포함한다. 컴퓨터(1102)는 I/O 장치들(1104) 및 표시 장치(1106)에 연결되거나 이들을 포함할 수 있다.

컴퓨터(1102)는 모뎀 또는 네트워크 인터페이스를 포함할 수 있는 통신 인터페이스(1110)를 통해 외부 시스템과 상호작용한다. 통신 인터페이스(1110)는 컴퓨터 시스템(1100)의 일부 또는 컴퓨터(1102)의 일부인 것으로 고려될 수 있음은 물론이다. 통신 인터페이스(1110)는 아날로그 모뎀, ISDN 모뎀, 케이블 모뎀, 토큰링 인터페이스, 위성 송신 인터페이스(예컨대, "direct PC"), 또는 컴퓨터 시스템을 다른 컴퓨터 시스템들에 연결하기 위한 다른 인터페이스들일 수 있다.

프로세서(1108)는 예컨대 인텔 펜티엄 마이크로프로세서 또는 모토롤라 파워 PC 마이크로프로세서와 같은 종래의 마이크로프로세서일 수 있다. 메모리(1112)는 버스(1170)에 의해 프로세서(1108)에 연결된다. 메모리(1112)는 동적 랜덤 액세스 메모리(DRAM)일 수 있고, 또한 정적 랜덤 액세스 메모리(SRAM)를 포함할 수 있다. 버스(1170)는 프로세서(1108)를 메모리(1112)에 연결하며, 비휘발성 저장 장치(1116)와 표시 제어기(1114)와 I/O 제어기(1118)에도 연결한다.

I/O 장치들(1104)은 키보드, 디스크 드라이브, 프린터, 스캐너, 및 마우스 또는 다른 포인팅 장치를 포함하는 입출력 장치들을 포함할 수 있다. 표시 제어기(1114)는 예컨대 음극선관(CRT) 또는 액정 표시 장치(LCD)일 수 있는 표시 장치(1106) 상에서 종래의 방식으로 표시를 제어할 수 있다. 표시 제어기(1114)와 I/O 제어기(1118)는 종래의 주지의 기술로 실시될 수 있다.

비휘발성 저장 장치(1116)는 종종 자기 하드 디스크, 광 디스크, 또는 대량의 데이터를 위한 다른 형태의 저장 장치이다. 이러한 데이터 중 일부는 종종 소프트웨어가 컴퓨터(1102)에서 실행되는 동안 직접 메모리 액세스 프로세스에 의해 메모리(1112)에 기입된다. 당해 기술분야의 숙련자는 "기계-판독 가능한 매체" 또는 "컴퓨터-판독 가능한 매체"라는 용어들이 프로세서(1108)에 의해 액세스 가능한 모든 유형의 저장 장치를 포함하며, 데이터 신호를 부호화하는 반송파 역시 포함한다는 것을 즉각적으로 인식할 것이다.

컴퓨터 시스템(1100)은 상이한 아키텍쳐들을 가진 다수의 있을 수 있는 컴퓨터 시스템들 중 일례이다. 예컨대, 인텔 마이크로프로세서에 기반한 개인용 컴퓨터들은 종종 다수의 버스들을 구비하며, 이들 중 하나는 주변 장치들을 위한 I/O 버스일 수 있고, 하나는 프로세서(1108)와 메모리(1112)를 직접 연결한다(종종 메모리 버스로 참조된다). 버스들은 상이한 버스 프로토콜들로 인해 모든 필요한 해석을 수행하는 브릿지 컴포넌트들을 통해 서로 연결된다.

네트워크 컴퓨터들은 본원에 제공된 교시와 함께 사용될 수 있는 다른 유형의 컴퓨터 시스템이다. 네트워크 컴퓨터들은 보통 하드 디스크 또는 다른 대용량 저장 장치를 포함하지 않으며, 실행 가능한 프로그램들은 프로세서(1108)에 의해 실행되기 위해 네트워크 연결로부터 메모리(1112)로 로딩된다. 당해 기술분야에 알려진 웹 TV 시스템 역시 컴퓨터 시스템으로 고려되지만, 소정의 입출력 장치들과 같이 도 11에 도시된 특징부들 중 몇몇이 부족할 수 있다. 통상적인 컴퓨터 시스템은 적어도 프로세서, 메모리, 및 메모리를 프로세서에 연결하는 버스를 일반적으로 포함할 것이다.

또한, 컴퓨터 시스템(1100)은 디스크 운영체계와 같은 파일 관리 시스템을 포함하는 운영체계 소프트웨어에 의해 제어되고, 이는 운영체계 소프트웨어의 일부이다. 연관된 파일 관리 시스템 소프트웨어를 구비한 운영체계 소프트웨어의 일례로, 마이크로소프트사(워싱턴주 레드몬드 소재)의 Windows®알려진 일 군의 운영체계들, 및 이들의 연관된 파일 관리 시스템들이 있다. 연관된 파일 관리 시스템 소프트웨어를 구비한 운영체계 소프트웨어의 다른 예로, 리눅스 운영체계, 및 이들의 연관된 파일 관리 시스템이 있다. 파일 관리 시스템은 통상적으로 비휘발성 저장 장치(1116)에 저장되며, 프로세서(1108)로 하여금, 비휘발성 저장 장치(1116)에 파일을 저장하는 것을 포함하여, 데이터를 메모리에 저장하고 데이터를 입출력하기 위해 운영체계에 의해 요구되는 다양한 작업들을 실행하게 한다.

전술한 설명의 몇몇 부분들은 컴퓨터 메모리 내의 데이터 비트 동작들에 대한 상징적 표현과 알고리즘의 관점에서 제시되었다. 이러한 알고리즘식 설명과 표현은 데이터 처리 기술분야의 숙련자들이 자신들의 작업의 요지를 상기 기술분야의 다른 숙련자들에게 가장 효과적으로 전달하기 위해 사용하는 수단이다. 알고리즘은, 여기서 그리고 일반적으로, 원하는 결과를 가져오는 동작들의 자기모순 없는 시퀀스로 여겨진다. 동작들은 물리량들의 물리적 조작들을 요구하는 동작들이다. 보통, 이러한 물리량들은 저장, 전달, 결합, 비교, 및 달리 조작될 수 있는 전기 또는 자기 신호들의 형태를 취하지만, 반드시 그런 것은 아니다. 주로 일반적인 사용을 이유로, 이러한 신호들을 비트, 값, 요소, 기호, 문자, 용어, 숫자 등으로 나타내는 것이 때때로 편리하다고 입증되었다.

그러나, 이러한 용어들과 유사한 용어들 모두는 적절한 물리량과 연관되어야 하며, 이러한 물리량들에 적용되는 편리한 라벨들에 불과하다는 것을 명심해야 한다. 구체적으로 달리 명시되지 않는 한, 후술하는 논의에서 명백한 바와 같이, 설명 전반에 걸쳐, "처리(processing)" 또는 "산정(computing)" 또는 "계산(calculating)" 또는 "판단(determining)" 또는 "표시(displaying)" 등과 같은 용어들을 이용한 논의들이 컴퓨터 시스템 또는 유사한 전자 컴퓨팅 장치의 작동 및 프로세스를 가리킴은 물론이고, 이는 컴퓨터 시스템의 레지스터들 및 메모리들 내의 물리(전자)량으로 표현된 데이터를, 컴퓨터 시스템 메모리들 또는 레지스터들 또는 이러한 다른 정보 저장, 전송 또는 표시 장치들 내의 물리량으로 유사하게 표현된 다른 데이터로 조작 및 변형한다.

몇몇 구현예들에서, 본 발명은 또한 본원의 동작들을 수행하기 위한 장치에 관련된다. 이러한 장치는 요구된 목적들을 위해 특별히 구성될 수 있거나, 또는 컴퓨터에 저장된 컴퓨터 프로그램에 의해 선택적으로 활성화 또는 재구성되는 범용 컴퓨터를 포함할 수 있다. 이러한 컴퓨터 프로그램은 읽기 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), EPROM, EEPROM, 자기 또는 광 카드, 플로피 디스크, 광 디스크, CD-ROM, 자기-광 디스크를 포함하는 모든 유형의 디스크, 또는 전자 명령어를 저장하는 데 적합한 모든 유형의 매체와 같은, 그러나 이들에 제한되지 않은, 컴퓨터 판독 가능한 저장 매체에 저장될 수 있고, 각각이 컴퓨터 시스템 버스에 연결된다.

본원에 제시된 알고리즘들과 표시들은 본질적으로 어떤 특정한 컴퓨터 또는 다른 장치와 관련된 것이 아니다. 다양한 범용 시스템들이 본원의 교시에 따라 프로그램들과 사용될 수 있거나, 또는 요구된 방법 단계들을 수행하기 위해서는 더욱 전문화된 장치를 구성하는 것이 편리하다고 입증될 수 있다. 이러한 다양한 시스템들을 위해 필수 구조들이 후술하는 설명에 나타날 것이다. 또한, 본 발명은 임의의 특정한 프로그램 언어를 참조하여 설명되지 않고, 그에 따라 다양한 구현예들이 다양한 프로그램 언어들을 사용하여 실시될 수 있다.

전술한 구현예들은 이해의 명료함을 위해 어느 정도 상세히 설명되었지만, 본 발명은 제공된 세부사항에 제한되지 않는다. 본 발명의 실시를 위한 많은 대안적인 방식들이 있다. 개시된 구현예들은 예시적이며, 제한적이지 않다.

기존의 객체들(예컨대, 서비스 활동들)로부터의 계층적 설계

1. 서비스 설계 시스템이 하나 이상의 필터를 식별하는 단계로, 각각의 필터는 네트워크 데이터 트래픽을 하나 이상의 네트워크 서비스와 연관된 것으로 식별하는 단계;

하나 이상의 필터를 사용하여 하나 이상의 서비스 객체를 생성하는 단계로, 각각의 서비스 객체는 하나 이상의 네트워크 서비스의 범주에 속하는 네트워크 데이터 트래픽을 식별하는 단계;

하나 이상의 서비스 객체를 사용하여 서비스 플랜을 생성하는 단계로, 서비스 플랜은 최종 사용자 장치에 의한 하나 이상의 네트워크 서비스의 사용 또는 하나 이상의 네트워크 서비스의 하나 이상의 범주의 사용을 관리하는 단계;

적어도 하나의 서브-플랜-레벨 정책을 하나 이상의 필터중 적어도 하나 또는 하나 이상의 서비스 객체 중 적어도 하나와 연관되게 하는 단계로, 적어도 하나의 서브-플랜-레벨 정책은 명시된 네트워크 서비스의 사용 규칙들 또는 하나 이상의 네트워크 서비스의 명시된 범주의 사용 규칙들을 정의하는 단계; 및

서비스 플랜의 하나 이상의 필터 및 적어도 하나의 서브-플랜-레벨 정책을 사용하여, 적어도 하나의 서브-플랜-레벨 정책에 따라 최종 사용자 장치 상에서 특정한 네트워크 서비스의 사용 또는 하나 이상의 네트워크 서비스의 특정한 범주의 사용을 관리하도록 정책 실시 요소를 보조하기 위한 컴퓨터 코드를 생성하는 단계를 포함하는 방법.

2. 제1항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 웹 페이지를 포함하는 방법.

3. 제1항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 도메인을 포함하는 방법.

4. 제1항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 애플리케이션을 포함하는 방법.

5. 제1항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 테더링 기능을 포함하는 방법.

6. 제1항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 로밍 데이터 네트워크 기능을 포함하는 방법.

7. 제1항에 있어서, 하나 이상의 범주 중 하나는 이메일 서비스들을 포함하는 방법.

8. 제1항에 있어서, 하나 이상의 범주 중 하나는 소셜 네트워크 서비스들을 포함하는 방법.

9. 제1항에 있어서, 하나 이상의 범주 중 하나는 도메인을 포함하고, 상기 범주의 네트워크 서비스들은 복수의 웹 페이지들을 포함하는 방법.

10. 제1항에 있어서, 하나 이상의 범주 중 하나는 음악 다운로드 서비스를 포함하는 방법.

11. 제1항에 있어서, 하나 이상의 범주 중 하나는 비디오 게임 서비스들을 포함하는 방법.

12. 제1항에 있어서, 하나 이상의 범주 중 하나는 멀티미디어 서비스들을 포함하는 방법.

13. 제1항에 있어서, 규칙들은 사용자 통지 트리거들을 정의하는 통지 규칙들을 포함하는 방법.

14. 제1항에 있어서, 규칙들은 액세스 권리들을 정의하는 액세스 규칙들을 포함하는 방법.

15. 제1항에 있어서, 규칙들은 사용-기반 정산 메트릭(accounting metrics)을 정의하는 정산 규칙들을 포함하는 방법.

16. 제1항에 있어서, 정책 실시 요소는 최종 사용자 장치 상에 있는 방법.

17. 제1항에 있어서, 정책 실시 요소는 최종 사용자 장치로부터 멀리 있는 네트워크 요소 상에 있는 방법.

18. 제1항에 있어서, 각각의 단계는 단일 인터페이스를 통해 수행되는 방법.

19. 제1항에 있어서, 하나 이상의 서비스 객체는 2개의 서비스 객체들을 포함하고, 2개의 서비스 객체들 각각은 동일한 필터의 인스턴스를 포함하는 방법.

20. 제1항에 있어서, 하나 이상의 서비스 객체 중 적어도 하나는 하나 이상의 필터의 그룹을 포함하는 서비스 활동을 포함하며, 하나 이상의 서비스 활동의 그룹을 포함하는 서비스 컴포넌트를 포함하고,

서비스 플랜은 하나 이상의 서비스 컴포넌트를 포함하는 방법.

21. 제20항에 있어서, 적어도 하나의 서브-플랜-레벨 정책 중 하나는 활동-레벨 정책 또는 컴포넌트-레벨 정책 중 적어도 하나를 포함하는 방법.

22. 제1항에 있어서, 하나 이상의 최종 사용자 장치의 장치 그룹을 생성하는 단계; 및

적어도 하나의 서브-플랜-레벨 정책에 따라 장치 그룹의 하나 이상의 최종 사용자 장치 상에서 특정한 네트워크 서비스 또는 네트워크 서비스들의 특정한 범주를 관리하도록, 하나 이상의 정책 실시 요소의 요소 그룹에 컴퓨터 코드를 제공하는 단계를 포함하는 방법.

23. 제22항에 있어서, 장치 그룹은 하나 이상의 최종 사용자 장치의 베타 테스트 그룹을 포함하는 방법.

24. 제22항에 있어서, 베타 테스트 그룹은 장치 그룹과 상이하고,

장치 그룹의 하나 이상의 최종 사용자 장치에 컴퓨터 코드를 제공하기 전에, 적어도 하나의 서브-플랜-레벨 정책에 따라 베타 테스트 그룹의 하나 이상의 최종 사용자 장치 상에서 특정한 네트워크 서비스 또는 네트워크 서비스들의 특정한 범주를 관리하도록 하나 이상의 정책 실시 요소의 베타 테스트 요소 그룹에 컴퓨터 코드를 제공하는 단계를 더 포함하는 방법.

25. 제1항에 있어서, 필터는 모든 네트워크 데이터 트래픽을 이와 연관된 것으로 식별하는 방법.

25++. 제1항에 있어서, 컴퓨터 코드는 프로그램 가능한 회로를 위해 생성되는 방법.

26. 하나 이상의 필터를 식별하기 위한 제1 인터페이스 메커니즘으로, 각각의 필터는 네트워크 데이터 트래픽을 하나 이상의 네트워크 서비스와 연관된 것으로 식별하는 제1 인터페이스 메커니즘;

하나 이상의 필터를 사용하여 하나 이상의 서비스 객체를 생성하기 위한 제2 인터페이스 메커니즘으로, 각각의 서비스 객체는 하나 이상의 네트워크 서비스의 범주에 속하는 네트워크 데이터 트래픽을 식별하는 제2 인터페이스 메커니즘;

하나 이상의 서비스 객체를 사용하여 서비스 플랜을 생성하기 위한 제3 인터페이스 메커니즘으로, 서비스 플랜은 최종 사용자 장치에 의한 하나 이상의 네트워크 서비스의 사용 또는 하나 이상의 네트워크 서비스의 하나 이상의 범주의 사용을 관리하는 제3 인터페이스 메커니즘;

적어도 하나의 서브-플랜-레벨 정책을 하나 이상의 필터중 적어도 하나 또는 하나 이상의 서비스 객체 중 적어도 하나와 연관되게 하기 위한 제4 인터페이스 메커니즘으로, 적어도 하나의 서브-플랜-레벨 정책은 명시된 네트워크 서비스의 사용 규칙들 또는 하나 이상의 네트워크 서비스의 명시된 범주의 사용 규칙들을 정의하는 제4 인터페이스 메커니즘; 및

서비스 플랜의 하나 이상의 필터 및 적어도 하나의 서브-플랜-레벨 정책을 사용하여, 적어도 하나의 서브-플랜-레벨 정책에 따라 최종 사용자 장치 상에서 특정한 네트워크 서비스의 사용 또는 하나 이상의 네트워크 서비스의 특정한 범주의 사용을 관리하도록 정책 실시 요소를 보조하기 위한 컴퓨터 코드를 생성하기 위한 프로세서를 포함하는 서비스 설계 시스템.

27. 제26항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 웹 페이지를 포함하는 시스템.

28. 제26항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 도메인을 포함하는 시스템.

29. 제26항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 애플리케이션을 포함하는 시스템.

30. 제26항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 테더링 기능을 포함하는 시스템.

31. 제26항에 있어서, 하나 이상의 네트워크 서비스 중 적어도 하나는 로밍 데이터 네트워크를 포함하는 시스템.

32. 제26항에 있어서, 하나 이상의 범주 중 하나는 이메일 서비스들을 포함하는 시스템.

33. 제26항에 있어서, 하나 이상의 범주 중 하나는 소셜 네트워크 서비스들을 포함하는 시스템.

34. 제26항에 있어서, 하나 이상의 범주 중 하나는 도메인을 포함하고, 상기 범주의 네트워크 서비스들은 복수의 웹 페이지들을 포함하는 시스템.

35. 제26항에 있어서, 하나 이상의 범주 중 하나는 음악 다운로드 서비스를 포함하는 시스템.

36. 제26항에 있어서, 하나 이상의 범주 중 하나는 비디오 게임 서비스들을 포함하는 시스템.

37. 제26항에 있어서, 하나 이상의 범주 중 하나는 멀티미디어 서비스들을 포함하는 시스템.

38. 제26항에 있어서, 규칙들은 사용자 통지 트리거들을 정의하는 통지 규칙들을 포함하는 시스템.

39. 제26항에 있어서, 규칙들은 액세스 권리들을 정의하는 액세스 규칙들을 포함하는 시스템.

40. 제26항에 있어서, 규칙들은 사용-기반 정산 메트릭을 정의하는 정산 규칙들을 포함하는 시스템.

41. 제26항에 있어서, 정책 실시 요소는 최종 사용자 장치 상에 있는 시스템.

42. 제26항에 있어서, 정책 실시 요소는 최종 사용자 장치로부터 멀리 있는 네트워크 요소 상에 있는 시스템.

43. 제26항에 있어서, 제1, 제2, 제3 및 제4 인터페이스 메커니즘은 단일 인터페이스의 모든 부분들인 시스템.

44. 제26항에 있어서, 하나 이상의 서비스 객체는 2개의 서비스 객체들을 포함하고, 2개의 서비스 객체들 각각은 동일한 필터의 인스턴스를 포함하는 시스템.

45. 제26항에 있어서, 하나 이상의 서비스 객체 중 적어도 하나는 하나 이상의 필터의 그룹을 포함하는 서비스 활동을 포함하며, 하나 이상의 서비스 활동의 그룹을 포함하는 서비스 컴포넌트를 포함하고,

서비스 플랜은 하나 이상의 서비스 컴포넌트를 포함하는 시스템.

46. 제45항에 있어서, 적어도 하나의 서브-플랜-레벨 정책 중 하나는 활동-레벨 정책 또는 컴포넌트-레벨 정책 중 적어도 하나를 포함하는 시스템.

47. 제26항에 있어서, 하나 이상의 최종 사용자 장치의 장치 그룹을 생성하기 위한 제5 인터페이스 메커니즘; 및

적어도 하나의 서브-플랜-레벨 정책에 따라 장치 그룹의 하나 이상의 최종 사용자 장치 상에서 특정한 네트워크 서비스 또는 네트워크 서비스들의 특정한 범주를 관리하도록, 하나 이상의 정책 실시 요소의 요소 그룹에 컴퓨터 코드를 제공하기 위한 송신기 메커니즘을 더 포함하는 시스템.

48. 제47항에 있어서, 장치 그룹은 하나 이상의 최종 사용자 장치의 베타 테스트 그룹을 포함하는 시스템.

49. 제47항에 있어서, 베타 테스트 그룹은 장치 그룹과 상이하고,

송신기 메커니즘은 장치 그룹의 하나 이상의 최종 사용자 장치에 컴퓨터 코드를 제공하기 전에, 적어도 하나의 서브-플랜-레벨 정책에 따라 베타 테스트 그룹의 하나 이상의 최종 사용자 장치 상에서 특정한 네트워크 서비스 또는 네트워크 서비스들의 특정한 범주를 관리하도록 하나 이상의 정책 실시 요소의 베타 테스트 요소 그룹에 컴퓨터 코드를 제공하기 위해 작동하는 시스템.

50. 제26항에 있어서, 필터는 모든 네트워크 데이터 트래픽을 이와 연관된 것으로 식별하는 시스템.

51. 제26항에 있어서, 프로세서는 프로그램 가능한 회로를 위해 컴퓨터 코드를 생성하는 시스템.

설계 및 실시: 데이터의 분류 순서

1. 서비스 설계 시스템이 필터들을 식별하는 단계로, 각각의 필터는 네트워크 데이터 트래픽을 하나 이상의 네트워크 서비스와 연관된 것으로 분류하는 단계;

필터들을 사용하여 서비스 객체들을 생성하는 단계로, 각각의 서비스 객체는 네트워크 데이터 트래픽을 하나 이상의 네트워크 서비스의 그룹과 연관된 것으로 분류하는 단계;

서비스 객체들을 사용하여 서비스 플랜을 생성하는 단계로, 서비스 플랜은 서비스 객체들과 연관된 네트워크 서비스들의 사용을 관리하는 단계;

대안적인 서비스 객체들에 의한 네트워크 데이터 트래픽의 분류들과 충돌하는 것을 방지하기 위해 서비스 객체들을 우선순위화하는 단계로, 대안적인 서비스 객체들은 네트워크 데이터 트래픽을 이들과 연관된 것으로 분류할 수 있는 단계;

정책들을 서비스 객체들과 연관되게 하는 단계로, 각각의 정책은 연관된 서비스 객체에 대응하는 하나 이상의 네트워크 서비스의 그룹의 사용 규칙들을 정의하는 단계; 및

서비스 객체들과 정책들을 사용하여, 최종 사용자 장치 상에서 네트워크 서비스들의 사용을 관리하도록 정책 실시 요소를 보조하기 위한 컴퓨터 코드를 생성하는 단계를 포함하는 방법.

2. 제1항에 있어서, 하나 이상의 네트워크 서비스는 웹 페이지를 포함하는 방법.

3. 제1항에 있어서, 하나 이상의 네트워크 서비스는 도메인을 포함하는 방법.

4. 제1항에 있어서, 하나 이상의 네트워크 서비스는 애플리케이션을 포함하는 방법.

5. 제1항에 있어서, 하나 이상의 네트워크 서비스는 테더링 기능을 포함하는 방법.

6. 제1항에 있어서, 하나 이상의 네트워크 서비스는 로밍 데이터 네트워크 기능을 포함하는 방법.

7. 제1항에 있어서, 하나 이상의 네트워크 서비스는 네트워크 서비스들의 범주를 포함하는 방법.

8. 제1항에 있어서, 그룹은 네트워크 서비스들의 범주를 포함하는 방법.

9. 제1항에 있어서, 그룹은 후원 서비스들을 포함하는 방법.

10. 제1항에 있어서, 하나 이상의 서비스들의 그룹은 단일 개체에 의해 제공된 서비스들을 포함하는 방법.

11. 제1항에 있어서, 그룹은 도메인을 포함하고, 그룹의 네트워크 서비스들은 복수의 웹 페이지들을 포함하는 방법.

12. 제1항에 있어서, 규칙들은 사용자 통지 트리거들을 정의하는 통지 규칙들을 포함하는 방법.

13. 제1항에 있어서, 규칙들은 액세스 권리들을 정의하는 액세스 규칙들을 포함하는 방법.

14. 제1항에 있어서, 규칙들은 사용-기반 정산 메트릭을 정의하는 정산 규칙들을 포함하는 방법.

15. 제1항에 있어서, 정책 실시 요소는 최종 사용자 장치 상에 있는 방법.

16. 제1항에 있어서, 정책 실시 요소는 최종 사용자 장치로부터 멀리 있는 네트워크 요소 상에 있는 방법.

17. 제1항에 있어서, 각각의 단계는 단일 인터페이스를 통해 수행되는 방법.

18. 제1항에 있어서, 서비스 객체들은 동일한 필터의 인스턴스를 각각 포함하는 2개의 서비스 객체들을 포함하는 방법.

19. 제1항에 있어서, 서비스 객체들 중 적어도 하나는 하나 이상의 필터의 그룹을 포함하는 서비스 활동을 포함하며, 하나 이상의 서비스 활동의 그룹을 포함하는 서비스 컴포넌트를 포함하고,

서비스 플랜은 하나 이상의 서비스 컴포넌트를 포함하는 방법.

20. 제19항에 있어서, 정책들 중 적어도 하나는 활동-레벨 정책 또는 컴포넌트-레벨 정책 중 적어도 하나를 포함하는 방법.

21. 제1항에 있어서, 컴퓨터 코드는 프로그램 가능한 회로를 위해 생성되는 방법.

22. 제1항에 있어서, 필터는 모든 네트워크 데이터 트래픽을 이와 연관된 것으로 식별하는 방법.

23. 제1항에 있어서, 적어도 하나의 서비스 객체는 단지 하나의 필터를 사용하여 생성되는 방법.

24. 제1항에 있어서, 우선순위화 단계는 비후원 서비스들보다 먼저 후원 서비스들을 우선순위화하는 단계를 포함하는 방법.

25. 제1항에 있어서, 서비스 객체들은 제1 서비스 객체와 제2 서비스 객체를 포함하고, 제1 및 제2 서비스 객체 각각은 연관된 하나 이상의 네트워크 서비스로 특정한 네트워크 데이터 트래픽을 분류하도록 구성되고,

우선순위화 단계는 소정의 제한까지 제1 서비스 객체를 적용하고 제한 후에 제2 서비스 객체를 적용하도록 구성하는 단계를 포함하는 방법.

26. 제25항에 있어서, 제한은 상태 조건을 포함하는 방법.

27. 제25항에 있어서, 제한은 사용 임계값을 포함하는 방법.

28. 제1항에 있어서, 정책 실시 요소에 컴퓨터 코드를 제공하는 단계를 더 포함하는 방법.

29. 서비스 설계 시스템으로부터 컴퓨터 명령어들을 수신하는 단계;

컴퓨터 명령어들을 사용하여, 최종 사용자 장치 상에 우선순위화된 서비스 객체들 및 서비스 객체들과 연관된 정책들을 설치하는 단계로, 우선순위화된 서비스 객체들 및 연관된 정책들은 하나 이상의 네트워크 데이터 서비스의 사용을 관리하는 단계;

최종 사용자 장치가 네트워크 데이터 트래픽 또는 네트워크 데이터 서비스들에 대한 요청을 수신하는 단계;

우선순위화된 서비스 객체들 중 하나 이상을 정책 실시 요소에 의해 적용하여, 네트워크 데이터 트래픽 또는 네트워크 데이터 서비스들에 대한 요청을 하나 이상의 네트워크 데이터 서비스 중 적어도 하나에 속하는 것으로 그리고 특정한 서비스 객체와 연관된 것으로 분류하는 단계;

특정한 서비스 객체와 연관된 특정한 정책을 정책 실시 요소에 의해 적용하여, 하나 이상의 네트워크 데이터 서비스 중 적어도 하나의 사용 규칙들을 실시하는 단계를 포함하는 방법.

30. 제29항에 있어서,

제1 분류에 속하는 제1 패킷이 수신될 때, 적용 가능한 분류의 사용이 제1 한계값에 도달했다고 판단하는 단계;

제1 패킷에 하나 이상의 추가적인 필터를 적용하는 단계; 및

패킷을 적어도 2개의 상이한 분류들 중 제2 분류에 속하는 것으로 분류하는 단계를 더 포함하는 방법.

31. 제29항에 있어서, 적용 가능한 분류에 대응하는 하나 이상의 정책은 스킵 정책을 포함하고,

적용 가능한 분류를 위한 더 많은 정책들의 적용을 중지하는 단계; 및

데이터 트래픽에 하나 이상의 추가적인 필터를 적용하여, 데이터 트래픽을 위한 다른 적용 가능한 분류를 결정하는 단계를 더 포함하는 방법.

III. 설계 및 실시: 정책 변경자들

A. 분류 및 적어도 하나의 네트워크 정책 변경자(modifier)

35. 액세스 네트워크에 의해 하나 이상의 통신 장치로 제공될 복수의 네트워크 데이터 서비스들을 포함하는 서비스 플랜 그룹을 설계하기 위한 방법에 있어서,

서비스 설계 시스템의 인터페이스가 각각의 서비스 컴포넌트를 위한 하나 이상의 필터를 수신하는 단계로, 각각의 필터는 하나 이상의 매개변수의 세트를 포함하고, 매개변수들의 각각의 세트는 데이터 트래픽을 각각의 서비스 객체와 연관된 것으로 분류하도록 구성되며, 데이터 트래픽은 적어도 하나의 액세스 네트워크 상에서 전달되는 단계;

각각이 복수의 네트워크 상태값들을 가지는 복수의 네트워크 상태 범주들로부터 하나 이상의 네트워크 상태 범주를 선택하고, 선택된 네트워크 상태 범주에 대한 적어도 하나의 네트워크 상태값을 선택하는 인터페이스 메커니즘을 사용자에게 제공하는 단계;

하나 이상의 네트워크 상태 범주 및 선택된 네트워크 상태 범주에 대한 하나 이상의 네트워크 상태값의 선택을 수신하는 단계;

각각의 서비스 객체 및 선택된 네트워크 상태 범주에 대한 적어도 하나의 네트워크 상태값의 조합에 하나 이상의 정책을 지정하는 단계;

복수의 서비스 객체들, 정책들, 및 정책 지정들에 기반하여 서비스 플랜 그룹을 생성하는 단계로, 서비스 플랜 그룹의 정책 지정들은 선택된 네트워크 상태 범주들의 현재 네트워크 상태값들에 기반하여 서비스 플랜에 가입한 통신 장치의 데이터 트래픽을 위한 정책들의 실시를 용이하게 하는 단계; 및

서비스 플랜 그룹을, 통신 장치의 데이터 트래픽을 위한 정책들을 실시하도록 하나 이상의 정책 실시 요소를 프로그래밍하기 위해 사용될 수 있는 명령어들로 해석하는 단계;에 의해 복수의 서비스 객체들 각각을 생성하는 단계를 포함하는 방법.

36. 제35항에 있어서, 서비스 객체는 서비스 컴포넌트, 또는 서비스 컴포넌트들을 포함하는 서비스 플랜인 방법.

37. 제35항에 있어서, 서비스 객체 및 각각의 선택된 네트워크 상태 범주의 각각의 네트워크 상태값의 각각의 조합에 하나 이상의 정책을 지정하는 단계를 더 포함하는 방법.

38. 제35항에 있어서, 서비스 객체 및 각각의 선택된 네트워크 상태 범주의 각각의 네트워크 상태값의 각각의 조합을 위한 하나 이상의 정책을 수신하기 위한 입력 메커니즘을 사용자에게 제공하는 단계를 더 포함하는 방법.

39. 제35항에 있어서, 복수의 사용 상태값들을 수신하는 단계로, 사용 상태값은 서비스 객체로 분류된 네트워크 사용량을 나타내고, 분류는 서비스 객체의 하나 이상의 필터에 의해 결정되는 단계; 및

분류, 사용 상태값, 및 각각의 선택된 네트워크 범주의 각각의 네트워크 상태값의 각각의 조합에 하나 이상의 정책을 지정하는 단계를 더 포함하는 방법.

40. 제35항에 있어서, 인터페이스 메커니즘은 각각의 서비스 객체를 위해 별도로 하나 이상의 네트워크 상태 범주를 선택하는 것을 가능하게 하는 방법.

41. 제35항에 있어서, 인터페이스 메커니즘은 사용자가 하나 이상의 네트워크 상태 구성을 명시하게 하고, 제1 네트워크 상태 구성은:

제1 네트워크 상태 구성을 위해 선택된 각각의 네트워크 상태 범주의 네트워크 상태값; 및

제1 네트워크 상태 구성을 위해 선택되지 않은 네트워크 상태 범주들을 위한 와일드카드 심볼을 포함하고, 와일드카드 심볼은 비선택 범주를 위한 임의의 네트워크 상태값과 매칭되며, 하나 이상의 정책이 각각의 네트워크 상태 구성을 위해 지정되는 방법.

42. 제41항에 있어서, 각각의 네트워크 상태 구성을 위한 하나 이상의 정책을 사용자로부터 수신하는 단계를 더 포함하는 방법.

43. 제41항에 있어서, 네트워크 상태 구성들의 순서를 수신하는 단계로, 하나 이상의 정책 실시 요소에 의해 순서를 사용하여, 통신 장치의 데이터 트래픽을 위해 실시하기 위해 먼저 현재 네트워크 상태값들과 매칭되는 네트워크 상태 구성 및 대응하는 하나 이상의 정책을 결정하는 단계를 더 포함하는 방법.

44. 제42항에 있어서, 인터페이스 메커니즘은 사용자가 각각의 서비스 객체를 위해 하나 이상의 네트워크 상태 구성을 별도로 명시하게 하는 방법.

45. 제35항에 있어서, 정책 지정들은 다차원 어레이 내에 배치되고, 각각의 선택된 네트워크 범주는 다차원 어레이의 별개의 차원이며, 복수의 서비스 객체들은 다차원 어레이의 차원을 포함하는 방법.

46. 제35항에 있어서, 복수의 네트워크 상태 범주들은 정체 상태, 네트워크의 위치, 네트워크의 유형, 및 네트워크 라우팅 식별자들을 포함하는 방법.

47. 제46항에 있어서, 네트워크의 위치에 대한 네트워크 상태값들은 홈 및 적어도 하나의 로밍 네트워크를 포함하는 방법.

48. 제46항에 있어서, 정체 상태에 대한 네트워크 상태값들은 시각, 네트워크 정체의 장치 측정값, 및 네트워크 정체의 네트워크 측정값 중 적어도 하나에 기반하는 방법.

49. 제48항에 있어서, 네트워크 상태값들은 네트워크 정체의 측정값에 기반하고, 네트워크 정체의 측정값은 트래픽 지연, 지연 지터, 및 네트워크 패킷 에러율 중 적어도 하나를 포함하는 방법.

50. 제48항에 있어서, 정체 상태에 대한 네트워크 상태값의 결정 방식의 설명을 사용자로부터 수신하는 단계를 더 포함하는 방법.

51. 제46항에 있어서, 네트워크의 유형에 대한 네트워크 상태값들은 2G, 3G, 4G, 및 WiFi로 이루어진 군에서 선택된 적어도 2개 이상을 포함하는 방법.

52. 제35항에 있어서, 세트 내의 각각의 매개변수는 데이터 트래픽 속성들의 각각의 범주를 위한 것인 방법.

B. 2개의 정책 변경자들

53. 액세스 네트워크에 의해 하나 이상의 통신 장치로 제공될 하나 이상의 네트워크 서비스를 포함하는 서비스 플랜 그룹을 설계하기 위한 방법에 있어서,

각각이 복수의 네트워크 상태값들을 가지는 복수의 네트워크 상태 범주들을 선택하고, 선택된 네트워크 상태 범주에 대한 적어도 하나의 네트워크 상태값을 선택하기 위한 인터페이스 메커니즘을 서비스 설계 시스템에 의해 사용자에게 제공하는 단계;

복수의 네트워크 상태 범주들 및 각각의 선택된 네트워크 상태 범주에 대한 하나 이상의 네트워크 상태값의 선택을 수신하는 단계;

선택된 네트워크 상태 범주들에 대한 네트워크 상태값들의 복수의 조합들에 하나 이상의 정책을 지정하는 단계;

정책들 및 정책 지정들에 기반하여 서비스 플랜 그룹을 생성하는 단계로, 서비스 플랜 그룹의 정책 지정들은 선택된 네트워크 상태 범주들의 현재 네트워크 상태값들에 기반하여 서비스 플랜 그룹에 가입한 통신 장치를 위한 정책들의 실시를 용이하게 하는 단계; 및

서비스 플랜 그룹을, 통신 장치의 데이터 트래픽을 위한 정책들을 실시하도록 하나 이상의 정책 실시 요소를 프로그래밍하기 위해 사용될 수 있는 명령어들로 해석하는 단계를 포함하는 방법.

54. 제53항에 있어서, 선택된 네트워크 상태 범주들에 대한 네트워크 상태값들의 각각의 조합에 하나 이상의 정책을 지정하는 단계를 더 포함하는 방법.

55. 제53항에 있어서, 서비스 설계 시스템의 인터페이스가 각각의 서비스 객체를 위한 하나 이상의 필터를 수신하는 단계로, 각각의 필터는 하나 이상의 매개변수의 세트를 포함하고, 매개변수들의 각각의 세트는 데이터 트래픽을 각각의 서비스 객체와 연관된 것으로 분류하도록 구성되며, 데이터 트래픽은 적어도 하나의 액세스 네트워크 상에서 전달되는 단계; 및

서비스 객체 및 각각의 선택된 네트워크 상태 범주의 각각의 네트워크 상태값의 각각의 조합에 하나 이상의 정책을 지정하는 단계;에 의해 복수의 서비스 객체들 각각을 생성하는 단계를 더 포함하는 방법.

56. 제55항에 있어서, 서비스 객체는 서비스 컴포넌트, 또는 서비스 컴포넌트들을 포함하는 서비스 플랜인 방법.

57. 제53항에 있어서, 네트워크 사용량을 나타내는 복수의 사용 상태값들을 수신하는 단계; 및

사용 상태값 및 각각의 선택된 네트워크 상태 범주의 각각의 네트워크 상태값의 각각의 조합에 하나 이상의 정책을 지정하는 단계를 더 포함하는 방법.

C. 2개의 네트워크 상태 범주들을 이용한 실시

58. 통신 장치가 액세스 네트워크의 네트워크 서비스를 사용하게 하기 위한 정책을 실시하는 방법에 있어서,

네트워크 상태 정보를 획득하는 단계;

네트워크 상태 정보에 기반하여 액세스 네트워크의 현재 상태값들의 세트를 결정하는 단계로, 각각의 현재 상태값은 각각의 네트워크 상태 범주와 연관되고, 각각의 네트워크 상태 범주는 복수의 네트워크 상태값들을 가지는 단계;

현재 상태값들의 세트를 사용하여 정책들의 어레이에 액세스하는 단계;

현재 상태값들의 세트에 대응하는 제1 정책을 어레이로부터 검색하는 단계;

액세스 네트워크의 현재 상태 동안 통신 장치와 연관된 데이터 트래픽의 하나 이상의 패킷을 수신하는 단계; 및

정책 실시 요소에 의해 데이터 트래픽의 하나 이상의 패킷에 제1 정책을 적용하는 단계를 포함하는 방법.

59. 제58항에 있어서, 현재 상태값들을 사용하여 정책들의 어레이에 액세스하는 단계는:

현재 상태값들의 세트를 하나 이상의 네트워크 상태 구성과 비교하여, 현재 상태값들의 세트와 매칭되는 네트워크 상태 구성을 결정하는 단계로, 각각의 네트워크 상태 구성은 하나 이상의 정책과 연관되는 단계를 포함하는 방법.

60. 제59항에 있어서, 비교 단계는 명시된 순서로 수행되고,

현재 상태값들의 세트와 매칭되는 제1 네트워크 상태 구성과 연관된 하나 이상의 정책을 검색하는 단계를 더 포함하는 방법.

61. 제58항에 있어서, 현재 상태값들 중 하나 이상을 각각의 네트워크 상태 범주의 대응하는 기결정된 네트워크 상태값으로 변환하는 단계를 더 포함하는 방법.

62. 제61항에 있어서, 각각의 네트워크 상태 범주는 네트워크 정체에 대응하고, 기결정된 네트워크 상태값들은 상이한 정체 레벨들에 대응하는 방법.

63. 제58항에 있어서, 현재 상태값들의 세트를 정책들의 인덱싱된 어레이의 네트워크 상태 인덱스로 변환하는 단계; 및

네트워크 상태 인덱스를 사용하여 제1 정책을 검색하는 단계를 더 포함하는 방법.

64. 제63항에 있어서, 제1 정책은 다차원 어레이로부터 검색되고, 각각의 선택된 네트워크 상태 범주는 다차원 어레이의 차원에 대응하는 방법.

65. 제63항에 있어서, 인덱싱된 어레이는 정책들에 대한 포인터들을 포함하는 방법.

66. 제63항에 있어서, 네트워크 상태 정보가 변경될 때를 검출하는 단계로, 네트워크 상태 정보를 정책들의 인덱싱된 어레이의 네트워크 상태 인덱스로 변환하는 단계는 네트워크 상태 정보가 변경될 때 이루어지는 단계를 더 포함하는 방법.

67. 제58항에 있어서, 각각의 네트워크 상태 범주는 정체 상태, 네트워크의 위치, 네트워크의 유형, 및 네트워크 라우팅 식별자를 포함하는 방법.

68. 제67항에 있어서, 네트워크의 위치에 대한 네트워크 상태값들은 홈 및 적어도 하나의 로밍 네트워크를 포함하는 방법.

69. 제67항에 있어서, 정체 상태에 대한 네트워크 상태값들은 시각, 네트워크 정체의 장치 측정값, 및 네트워크 정체의 네트워크 측정값 중 적어도 하나에 기반하는 방법.

70. 제69항에 있어서, 네트워크 상태값들은 네트워크 정체의 측정값에 기반하고, 네트워크 정체의 측정값은 트래픽 지연, 지연 지터, 및 네트워크 패킷 에러율 중 적어도 하나를 포함하는 방법.

71. 제67항에 있어서, 네트워크의 유형에 대한 네트워크 상태값들은 2G, 3G, 4G, 및 WiFi로 이루어진 군에서 선택된 적어도 2개 이상을 포함하는 방법.

IV. 정책의 설계: 이벤트들

A. 3개의 정책들 중 2개와 연관된 이벤트

72. 액세스 네트워크에 의해 하나 이상의 통신 장치로 제공될 하나 이상의 네트워크 서비스를 포함하는 서비스 플랜을 설계하기 위한 방법에 있어서,

서비스 플랜에 따른 액세스 네트워크의 사용과 연관된 이벤트를 정의하는 입력을 제공하기 위한 인터페이스 메커니즘을 서비스 설계 시스템에 의해 사용자에게 제공하는 단계;

사용자로부터 이벤트를 정의하는 입력을 수신하는 단계;

사용자로부터 이벤트와 연관된 복수의 서비스 정책들을 수신하는 단계로, 서비스 정책들은 네트워크 서비스에 액세스할 권리를 정의하는 액세스 정책, 네트워크 서비스의 사용료를 정의하는 과금 정책, 및 네트워크 서비스에 대응하는 통지들을 제공할 때를 정의하는 통지 정책 중 적어도 2개를 포함하는 단계; 및

이벤트 및 복수의 서비스 정책들에 기반하여 서비스 플랜을 생성하는 단계; 및

서비스 플랜을, 서비스 플랜에 가입한 통신 장치의 액세스 네트워크 사용에 대해 이벤트가 검출될 때 서비스 정책들을 실시하도록 하나 이상의 정책 실시 요소를 프로그래밍하기 위해 사용될 수 있는 명령어들로 해석하는 단계를 포함하는 방법.

73. 제72항에 있어서, 서비스 플랜에 구속될(bound) 원격 통신 장치들의 제1 그룹을 식별하는 단계; 및

원격 통신 장치들의 제1 그룹을 위한 정책을 실시할 수 있는 정책 실시 요소들의 제2 그룹에 명령어들을 제공하는 단계를 더 포함하는 방법.

74. 제72항에 있어서, 인터페이스 메커니즘은 이벤트를 정의하기 위한 하나 이상의 선택 리스트(picklist)를 포함하고, 각각의 선택 리스트는 복수의 옵션들을 포함하는 방법.

75. 제74항에 있어서, 하나 이상의 선택 리스트는:

네트워크 서비스의 사용량에 대한 측정값에 대응하는 적어도 하나의 옵션을 포함하는 제1 선택 리스트; 및

사용량을 명시하기 위한 옵션들을 포함하는 하나 이상의 제2 선택 리스트를 포함하는 방법.

B. 이벤트 및 장치 상태가 통지를 제공한다

76. 액세스 네트워크에 의해 하나 이상의 통신 장치로 제공될 하나 이상의 네트워크 서비스를 포함하는 서비스 플랜을 설계하기 위한 방법에 있어서,

서비스 플랜에 따른 액세스 네트워크의 사용과 연관된 하나 이상의 이벤트를 정의하는 입력을 제공하기 위한 제1 인터페이스 메커니즘을 서비스 설계 시스템에 의해 사용자에게 제공하는 단계;

사용자로부터 하나 이상의 이벤트를 정의하는 입력을 수신하는 단계;

통신 장치의 하나 이상의 장치 상태를 명시하기 위한 제2 인터페이스 메커니즘을 제공하는 단계로, 장치 상태는 단지 통신 장치만의 특성인 단계;

하나 이상의 장치 상태를 수신하는 단계;

하나 이상의 이벤트 및 하나 이상의 장치 상태와 연관된 통지 정책을 수신하는 단계로, 통지 정책은 하나 이상의 이벤트 및 하나 이상의 장치 상태 사이의 조건부 관계를 정의하여, 통지 메시지가 서비스 플랜에 가입한 통신 장치의 사용자에게 표시되게 하는 단계; 및

하나 이상의 이벤트, 하나 이상의 장치 상태, 및 통지 정책에 기반하여 서비스 플랜을 생성하는 단계; 및

서비스 플랜을, 서비스 플랜에 가입한 통신 장치의 액세스 네트워크 사용에 대해 하나 이상의 이벤트가 검출되고 조건부 관계가 존재할 때 통지 정책을 실시하도록 하나 이상의 정책 실시 요소를 프로그래밍하기 위해 사용될 수 있는 명령어들로 해석하는 단계를 포함하는 방법.

77. 제76항에 있어서, 하나 이상의 이벤트는 통신 장치의 데이터 트래픽을 제1 유형의 데이터 트래픽으로 분류하는 것을 포함하고, 분류는 서비스 플랜의 하나 이상의 필터에 의해 결정되는 방법.

78. 제76항에 있어서, 장치 상태는 장치 상에 현재 실행 중인 애플리케이션, 장치의 위치를 포함하는 방법.

79. 제76항에 있어서, 하나 이상의 이벤트는 단지 하나의 이벤트이고, 조건부 관계는 단지 하나의 이벤트가 검출될 때 존재하는 하나 이상의 장치 상태를 포함하는 방법.

80. 제76항에 있어서, 조건부 관계는 이벤트들 중 하나 이상이 검출되었던 때와 장치 상태들 중 하나가 통신 장치 상에 마지막으로 존재했던 때 사이의 하나 이상의 윈도우 기준(window criteria)을 명시하는 방법.

81. 제80항에 있어서, 윈도우 기준은 시간 및/또는 사용량을 포함하는 방법.

82. 제76항에 있어서, 조건부 관계는 이벤트들의 순서를 명시하는 방법.

83. 제76항에 있어서, 조건부 관계는 장치 상태들이 통신 장치 상에 존재했던 때에 대한 순서를 명시하는 방법.

C. 이벤트 및 장치 상태 유도 통지의 실시

84. 통신 장치가 액세스 네트워크의 네트워크 서비스를 사용하게 하기 위한 통지 정책을 실시하기 위한 방법에 있어서,

서비스 플랜에 따른 통신 장치의 액세스 네트워크 사용과 연관된 하나 이상의 이벤트를 검출하는 단계;

통신 장치의 하나 이상의 현재 또는 최근 장치 상태를 식별하는 단계로, 장치 상태는 단지 통신 장치만의 특성인 단계;

통신 장치가 가입한 서비스 플랜의 통지 정책에 따라 하나 이상의 이벤트와 하나 이상의 현재 또는 최근 장치 상태 사이에 조건부 관계가 존재하는지 여부를 판단하는 단계; 및

조건부 관계를 만족하면 통신 장치 상의 통지 에이전트로 통지 요청을 전송하는 단계를 포함하는 방법.

85. 제84항에 있어서, 통지 요청은 네트워크 요소로부터 통신 장치 상의 통지 에이전트로 전송되는 방법.

86. 제84항에 있어서, 통지 요청은 통신 장치 상의 정책 실시 에이전트로부터 통신 장치 상의 통지 에이전트로 전송되는 방법.

Claims (29)

1. 하나 이상의 무선 최종 사용자 장치에서 하나 이상의 무선 액세스 네트워크에 의해 제공되는 하나 이상의 무선 네트워크 데이터 서비스를 포함하는 서비스 플랜을 실시하기 위해 서비스 설계 시스템을 동작하는 방법으로,
   서비스 설계 시스템 인터페이스 메커니즘을 통해, 서비스 플랜에 따라 무선 액세스 네트워크 중 적어도 하나의 사용과 연관된 이벤트를 규정하는 사용자 입력을 수락하는 단계;
   서비스 설계 시스템 인터페이스를 통해, 규정된 이벤트와 연관된 복수의 서비스 정책을 명시하는 사용자 입력을 수신하는 단계로, 상기 서비스 정책은 무선 네트워크 데이터 서비스에 액세스하기 위한 권리를 규정하는 액세스 정책, 무선 네트워크 데이터 서비스의 사용료를 규정하는 서비스 과금 정책, 및 무선 네트워크 데이터 서비스에 상응하는 통지를 제공하기 위한 경우를 규정하는 통지 정책 중 적어도 두 개를 포함하는, 단계;
   상기 두 개의 서비스 정책과 규정된 이벤트에 적어도 부분적으로 기초하는 서비스 플랜용 규정을 생성하는 단계; 및
   하나 이상의 정책 실시 요소를 프로그래밍하기 위해 사용하는 경우, 서비스 플랜 규정을, 상기 이벤트가 적어도 하나의 무선 액세스 네트워크의 적어도 하나의 적용가능한 무선 최종 사용자 장치의 사용과 서비스 플랜을 조건으로 적어도 하나의 적용가능한 무선 최종 사용자 장치를 검출하기 위한 경우, 하나 이상의 정책 실시 요소가 상기 서비스 정책을 실시하도록 하는 명령어로 해석하는 단계를 포함하는 서비스 설계 시스템을 동작하는 방법.
2. 제1항에 있어서,
   서비스 플랜에 구속될(bound) 무선 최종 사용자 장치의 제1그룹을 식별하는 단계; 및
   무선 최종 사용자 장치의 제1그룹을 위한 서비스 정책을 실시할 수 있도록 하나 이상의 정책 실시 요소들에 명령어를 제공하는 단계를 더 포함하는, 서비스 설계 시스템을 동작하는 방법.
3. 제2항에 있어서,
   상기 무선 최종 사용자 장치의 제1그룹 중 적어도 하나는 상기 서비스 플랜에 가입하는 것인, 서비스 설계 시스템을 동작하는 방법.
4. 제1항에 있어서,
   상기 인터페이스 메커니즘은 이벤트를 규정하기 위한 하나 이상의 선택 리스트(picklist)를 포함하고, 각각의 선택 리스트는 복수의 옵션들을 포함하는 것인, 서비스 설계 시스템을 동작하는 방법.
5. 제4항에 있어서,
   상기 하나 이상의 선택 리스트는:
   무선 네트워크 데이터 서비스의 사용량에 대한 측정값에 대응하는 적어도 하나의 옵션을 포함하는 제1 선택 리스트; 및
   사용량을 명시하기 위한 옵션들을 포함하는 하나 이상의 제2 선택 리스트를 포함하는 것인, 서비스 설계 시스템을 동작하는 방법.
6. 제1항에 있어서,
   상기 서비스 설계 시스템 인터페이스 메커니즘을 통해, 무선 최종 사용자 장치의 하나 이상의 장치 상태를 명시하는 사용자 입력을 수신하는 단계로, 상기 장치 상태는 장치의 특성인, 단계; 및
   상기 장치 상태를 이벤트 규정과 연관시키는 단계를 더 포함하는, 서비스 설계 시스템을 동작하는 방법.
7. 제6항에 있어서,
   상기 장치 상태는 소정의 애플리케이션이 장치 상에서 현재 실행되고 있는지의 여부를 포함하는 것인, 서비스 설계 시스템을 동작하는 방법.
8. 제6항에 있어서,
   상기 장치 상태는 장치의 위치를 포함하는 것인, 서비스 설계 시스템을 동작하는 방법.
9. 제6항에 있어서,
   상기 연관은 조건부 관계를 포함하고, 상기 장치 상태는 규정된 이벤트가 검출된 경우를 나타내는 것인, 서비스 설계 시스템을 동작하는 방법.
10. 제6항에 있어서,
    상기 연관은, 상기 규정된 이벤트가 검출된 경우와 상기 장치 상태가 장치 상에 존재했던 경우 사이의 하나 이상의 윈도우 기준(window criteria)을 명시하는, 조건부 관계를 포함하는 것인, 서비스 설계 시스템을 동작하는 방법.
11. 제10항에 있어서,
    상기 윈도우 기준은 상기 이벤트와 장치 상태 사이의 발생 순서를 포함하는 것인, 서비스 설계 시스템을 동작하는 방법.
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제

Images