KR20140061482A - 콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법 - Google Patents

콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법 Download PDF

Info

Publication number
KR20140061482A
KR20140061482A KR1020147008597A KR20147008597A KR20140061482A KR 20140061482 A KR20140061482 A KR 20140061482A KR 1020147008597 A KR1020147008597 A KR 1020147008597A KR 20147008597 A KR20147008597 A KR 20147008597A KR 20140061482 A KR20140061482 A KR 20140061482A
Authority
KR
South Korea
Prior art keywords
server
information
mobile device
web server
user
Prior art date
Application number
KR1020147008597A
Other languages
English (en)
Inventor
맥슨 알. 휠러
윌리엄 엔. 2세 캠프
리엔 티. 마미트수카
크리스토퍼 에이. 미트라
스캇 아이. 퍼터맨
사이러스 피. 마스터
스티븐 제이. 세위리네크
밀란 에스. 브라함바트
아니쉬 엠. 샤아
폴 웨인 한가스
신 후
사프나 사하니
토니 로빈슨
헤더 엠. 리로이
크리스토퍼 린핀스키
카이 웨이
Original Assignee
모토로라 모빌리티 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 모토로라 모빌리티 엘엘씨 filed Critical 모토로라 모빌리티 엘엘씨
Publication of KR20140061482A publication Critical patent/KR20140061482A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

사용자 장치 및 복수의 상이한 콘텐츠 공급자와 통신하도록 구성되어 있는 통합 서비스 서버를 제공한다. 복수의 상이한 콘텐츠 공급자로부터 콘텐츠를 획득하도록 구성되어 있고 획득된 콘텐츠를 사용자 장치로 푸시하도록 추가적으로 구성되어 있는 프로세서를 제공한다.

Description

콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법{SYSTEM, SERVER, AND MOBILE DEVICE FOR CONTENT PROVIDER WEBSITE INTERACTION AND METHOD THEREFOR}
본 발명은 모바일 장치를 수반하는 통신에 관한 것으로서, 보다 상세하게는, 이러한 모바일 장치와 인터넷 콘텐츠 공급자 웹 사이트 간의 통신에 관한 것이다.
소셜 네트워킹 웹 사이트(social networking website, SNW), 뉴스 피드, 음악 및 사진 웹 사이트는 물론, B2B(business-to-business) 또는 B2C(business-to-consumer) 웹 사이트와 같은 기타 유형의 웹 사이트 등의 콘텐츠 공급자 웹 사이트(content provider website, CPW)는 뉴스, 날씨, 개인 및/또는 기업 정보, 사진, 비디오, 및 노래와 같은 다양한 형태의 데이터의 다운로드 및/또는 업로드(예컨대, 포스팅)를 가능하게 해주고 그로써 사람들 및 사람들의 그룹들 사이에서 사람간 연결(interpersonal connection)을 생성 및 유지하는 것을 용이하게 해주는 대화형 웹 사이트이다. 한 사용자가 데이터를 CPW에 업로드하는 것은 다른 사용자들이 업로드된 데이터에 액세스하고 및/또는 그를 다운로드하는 것을 가능하게 해줄 수 있다. 전형적으로, SNW는 무수한 사용자들이 각자의 개인적 또는 직업적 공간 - 각각의 사용자를 제각기 식별해주고 업로드된 데이터가 각각의 공간과 연관될 수 있게 해줌 - 을 생성하는 아키텍처를 제공한다.
CPW는 각종의 상이한 유형의 장치들 - 종종 인터넷-유형 네트워크를 통해 CPW와 연결되어 있음 - 중 임의의 것을 조작하고 있는 사용자와 통신하고 있을 수 있다. 점점 더, 사용자는 CPW와 상호작용하기 위해 모바일 장치를 이용한다. 이러한 통신 활동이 증가함에 따라, 이러한 통신 활동을 수행함에 있어서 품질 및/또는 사용자 친숙성을 향상시킬 필요성이 점점 더 많아지고 있다. 게다가, 모바일 장치의 배터리 성능을 향상시키고 모든 장치에 대한 데이터 전송을 감소시키기 위해, 이러한 통신 활동의 효율을 향상시킬 필요성도 역시 점점 더 많아지고 있다.
따라서, 상기한 드러나는 요구사항들 중 하나 이상을 적어도 부분적으로 해결하는 데 도움을 주게 될, 향상된 모바일 장치 및/또는 기타 장치의 형태로의 향상 및/또는 모바일 장치가 CPW와 통신할 수 있게 해주는 향상된 방법이 제공될 수 있다면 유리할 것이다.
도 1은 복수의 콘텐츠 공급자 웹 사이트와 통신하고 있는 복수의 모바일 장치를 포함하는 예시적인 통신 시스템을 개략적인 형태로 나타낸 도면으로서, 여기서 통신들 중 일부는 중개 웹 서버를 통해 행해짐.
도 2는 도 1의 모바일 장치들 중 하나의 모바일 장치의 예시적인 구성요소를 나타낸 블록도.
도 3은 도 1의 중개 웹 서버의 예시적인 구성요소를 나타낸 블록도.
도 4 내지 도 9는 도 1의 중개 웹 서버 및 모바일 장치의 동작의 다양한 예시적인 단계들을 나타낸 예시적인 플로우차트.
도 10은 중개 서버의 동작을 나타낸 예시적인 플로우차트.
도 11은 모바일 장치의 동작을 나타낸 예시적인 플로우차트.
도 12는 중개 서버의 동작을 나타낸 예시적인 플로우차트.
도 13은 중개 서버의 동작을 나타낸 예시적인 플로우차트.
도 14는 모바일 장치의 예시적인 동작을 나타낸 도면.
도 15는 모바일 장치의 동작을 나타낸 예시적인 플로우차트.
도 16은 중개 서버의 동작을 나타낸 예시적인 플로우차트.
도 17은 일 실시예에 따른 다른 예시적인 통신 시스템을 나타낸 도면.
도 18은 일 실시예에 따른 또 다른 예시적인 통신 시스템을 나타낸 도면.
도 19는 클라이언트 장치와 중간 서버 사이의 예시적인 통신을 나타낸 도면.
도 20은 중간 서버의 백 엔드의 예시적인 푸시 서비스를 나타낸 도면.
도 21은 일 실시예에 따른, 연락처를 가져오기하는 예시적인 방법을 나타낸 도면.
도 22는 일 실시예에 따른 예시적인 시퀀스를 나타낸 도면.
도 23 내지 도 30은 일 실시예에 따른 클라이언트 장치로부터의 예시적인 화면을 나타낸 도면.
도 31은 일 실시예에 따른 다른 예시적인 통신 시스템을 나타낸 도면.
도 32는 일 실시예에 따른 예시적인 프로토콜을 나타낸 도면.
도 1을 참조하면, 예시적인 통신 시스템(100)의 블록도가 간략화된 개략 형태로 도시되어 있다. 도시된 바와 같이, 이 실시예에서, 통신 시스템(100)은 3개의 모바일 장치(102)를 포함하며, 그 중 하나는 통신 링크(105)를 통해 서버 - 본 실시예에서, 웹 서버(104)임 - 와 통신하고 있는 것으로 도시되어 있다. 모바일 장치(102)는, 각각, 사람(또는 사용자)에 의해 또는 어쩌면 통신 기능을 원하거나 필요로 하는 다른 엔터티(예컨대, 넷북 또는 기타 컴퓨터)에 의해 조작되는 통신 장치를 나타낸다. 일부 실시예에서, 예를 들어, 모바일 장치(102)는 네트워크[통신 링크(105)]와 연결되어 그와 통신할 수 있는, 휴대폰, PDA(personal digital assistant)와 같은 기타 무선 장치, 및/또는 랩톱 및 데스크톱 컴퓨터와 같은 장치 중 어느 것이라도 될 수 있다.
통신 시스템(100)은 그에 부가하여 3개의 콘텐츠 공급자 웹 사이트(content provider website, CPW)(106)를 포함하는 것으로 도시되어 있고, 그 중 하나는 통신 링크(108)를 통해 중개 웹 서버(104)와 통신하고 있는 것으로 도시되어 있다. 게다가, 웹 서버(104)와 통신하고 있는 모바일 장치들(102) 중 하나의 모바일 장치가, 웹 서버(104)의 중개 없이, 역시 웹 서버와 통신하고 있는 CPW들(106) 중 하나의 CPW와 직접 통신할 수 있게 해주는 통신 링크(110)가 또한 제공되어 있다. 모바일 장치들(102) 중 하나의 모바일 장치 및 CPW들(106) 중 하나의 CPW만이 웹 서버(104)와 통신하고 있는 것으로 도시되어 있지만, 시간 또는 동작 상황에 따라, 모바일 장치들(102) 및 CPW들(106) 중 일부 또는 전부가 웹 서버와 통신하고 있을 수 있다는 것을 잘 알 것이다. 이와 마찬가지로, 시간 또는 동작 상황에 따라, 모바일 장치들(102) 중 임의의 것이, 링크(110)와 같은 직접 통신 링크를 통해, CPW들(106) 중 임의의 것과 통신하기 시작할 수 있다.
도 1에 3개의 모바일 장치(102)가 도시되어 있지만, 다른 실시예에서, 단지 하나의 모바일 장치가 웹 서버(104)와 통신하고 있거나, 다른 대안으로서, 임의의 수의 모바일 장치가 웹 서버(104)와 통신하고 있을 수 있다. 이와 마찬가지로, 도 1에 3개의 CPW(106)가 도시되어 있지만, 다른 실시예에서, 단지 하나의 CPW가 웹 서버(104)와 통신하고 있거나, 다른 대안으로서, 임의의 수의 CPW가 웹 서버(104)와 통신하고 있을 수 있다. 그에 부가하여, 다른 실시예에서, 링크(110)와 같은 직접 통신 링크를 통해 임의의 수의 모바일 장치(들)가 임의의 수의 CPW(들)와 통신하고 있을 수 있다. 즉, 도 1은 웹 서버 인터페이스를 통해 간접적으로 서로 통신하거나 서로 직접 통신하고 있는 임의의 수의 모바일 장치 및 임의의 수의 CPW를 이용하는 각종의 시스템들 중 임의의 시스템을 나타내기 위한 것이다.
실시예에 따라, 통신 링크(105, 108, 110)는 단일 네트워크 또는 다수의 네트워크의 일부일 수 있고, 각각의 링크는 하나 이상의 유선 및/또는 무선 통신 경로 - 예를 들어, 지상선(landline wiring)(예컨대, 광섬유, 구리), 마이크로파 통신, 무선 채널, 무선 경로, 인트라넷, 인터넷, 및/또는 월드 와이드 웹 통신 경로(그 자체가, 예를 들어, 수많은 라우터 등을 비롯한 수많은 중개 하드웨어 및/또는 소프트웨어 장치를 이용할 수 있음) - 를 포함할 수 있다. 그에 부가하여, 모바일 장치(102), 웹 서버(104) 및 CPW(106) 사이에서 통신 링크(105, 108, 110)를 통해 통신을 수행하기 위해 각종의 통신 프로토콜 및 방법 - 예를 들어, TCP/IP(transmission control protocol/internet protocol), XMPP(extensible messaging and presence protocol), FTP(file transfer protocol) 등을 포함함 - 이 사용될 수 있다. 다른 실시예에서, 복수의 모바일 장치(102)와 CPW(106) 사이에서의 신호의 전송을 용이하게 해주는 다른 형태의 통신 링크도 역시 이용될 수 있다. 본 실시예에서, 통신 링크/네트워크 및 서버 각각이 웹-기반인 것으로 기술되어 있지만, 다른 실시예에서, 링크/네트워크 및 서버가 다양한 웹-기반이 아닌 형태를 취할 수 있다.
도 3 내지 도 16과 관련하여 이하에서 더 상세히 논의할 것인 바와 같이, 웹 서버(104)는 모바일 장치(102)와 CPW(106) 사이의 매개체로서 역할하도록 구성되어 있다. 예를 들어, 파일(예컨대, 사진, 음악, 비디오, 텍스트 엔트리 등)의 업로드 및 다운로드, 블로그 포스팅, 및 메시징[예컨대, SMS(Short Message Service), MMS(Multimedia Messaging Service), 및 IM(Instant Messaging)]을 수반하는 통신을 비롯한 모바일 장치(102)와 CPW(106) 사이의 다양한 유형의 통신은 웹 서버(104)를 통해 전달되고, 그에 의해 처리 및/또는 모니터링된다. CPW는 일반적으로 개인 및/또는 기업 정보, 사진, 비디오, 및 노래와 같은 다양한 형태의 데이터의 다운로드 및 업로드(예컨대, 포스팅)를 가능하게 해주고 그로써 사람들 및 사람의 그룹들 사이에서 사람간 연결을 생성 및 유지하는 것을 용이하게 해주는 각종의 대화형 웹 사이트를 포괄하기 위한 것이다. CPW의 일례는, 예를 들어, Facebook™, MySpace™, hi5™, LinkedIn™, 및 Twitter™를 포함한다. 본 발명의 목적상, CPW는 또한 완전히 또는 주로 소셜 네트워킹에 중점을 두고 있지는 않지만, 그럼에도 불구하고 소셜 네트워킹-유형의 특징도 포함하는 다양한 기타 유형의 웹 사이트[예컨대, B2B(business-to-business) 또는 B2C(business-to-consumer) 웹 사이트]를 포괄하는 것으로 이해될 수 있다. 다른 콘텐츠 공급자 웹 사이트는 RSS 또는 기타 뉴스 피드의 소스, Picasa™ 또는 Photobucket™과 같은 사진 서비스, 및 LastFM™과 같은 음악 서비스를 포함한다.
RSS(Really Simple Syndication)는 블로그 엔트리, 주요 뉴스, 오디오 및 비디오와 같은 빈번히 업데이트되는 저작물을 게시하는 데 사용되는 웹 피드 형식을 말한다. RSS 문서("피드" 또는 "채널"이라고 함)는 전체 또는 요약된 텍스트와, 게시 날짜 및 원작자와 같은 메타데이터를 포함하고, 사진을 포함할 수 있다.
도 2를 참조하면, 일 실시예에 따른 모바일 장치(102)와 같은 모바일 장치의 예시적인 내부 구성요소(200)를 나타내는 블록도가 제공되어 있다. 도 2에 도시된 바와 같이, 구성요소(200)는 하나 이상의 무선 송수신기(202, 203, 205), 프로세서(204)[예컨대, 마이크로프로세서, 마이크로컴퓨터, ASIC(application-specific integrated circuit) 등], 메모리 부분(206), 하나 이상의 출력 장치(208), 및 하나 이상의 입력 장치(210)를 포함한다. 적어도 일부 실시예에서, 하나 이상의 출력 장치(208)(디스플레이 등) 및 하나 이상의 입력 장치(210)(키패드 또는 터치 센서 등)를 포함하는 사용자 인터페이스가 존재한다. 내부 구성요소(200)는 부가적인 또는 향상된 기능에 대한 보조 구성요소 또는 액세서리로의 직접 연결을 제공하기 위해 구성요소 인터페이스(212)를 추가로 포함할 수 있다. 내부 구성요소(200)는 바람직하게는 또한 모바일 장치를 휴대가능하도록 만들어주면서 다른 내부 구성요소에 전력을 제공하는 배터리와 같은 전원 공급 장치(214)를 포함한다. 내부 구성요소(200) 모두는 서로 결합되어 있을 수 있고, 하나 이상의 내부 통신 링크(232)(예컨대, 내부 버스)를 통해 서로 통신하고 있을 수 있다.
각각의 무선 송수신기(202)는, 예를 들어, 아날로그 통신(AMPS를 사용함), 디지털 통신(CDMA, TDMA, GSM, iDEN, GPRS, EDGE 등을 사용함), 및 차세대 통신(UMTS, WCDMA, LTE, IEEE 802.16 등을 사용함) 또는 이들의 변형과 같은 셀룰러-기반 통신 기술, 또는 HomeRF(radio frequency), Bluetooth 및 IEEE 802.11(a, b, g 또는 n)과 같은 피어-투-피어 또는 애드혹 통신 기술, 또는 적외선 기술과 같은 기타 무선 통신 기술(이들로 제한되지 않음)을 포함할 수 있는 무선 통신 기술을 이용한다. 본 실시예에서, 무선 송수신기(202)는 셀룰러 송수신기(203) 및 WLAN(wireless local area network) 송수신기(205)를 포함하지만, 다른 실시예에서, 이들 유형의 무선 송수신기 중 단지 하나만이 존재한다(어쩌면 이들 유형의 무선 송수신기 및/또는 다른 유형의 무선 송수신기 중 어느 것도 존재하지 않음). 무선 송수신기(202)의 사용에 의해, 모바일 장치(102)는 통신 링크(110)를 통해 CPW(106)와는 물론 통신 링크(105)를 통해 웹 서버(104)와도[따라서, 다시 말하지만, CPW(106)와 간접적으로] 통신할 수 있다.
모바일 장치(102)의 내부 구성요소(200)의 다른 것들과 관련하여 무선 송수신기(202)의 예시적인 동작은 다양한 형태를 취할 수 있고, 예를 들어, 무선 신호의 수신 시에, 내부 구성요소가 통신 신호를 검출하고 송수신기(202)가 무선 신호에 의해 전송되는 들어오는 정보(음성 및/또는 데이터 등)를 복원하기 위해 통신 신호를 복조하는 동작을 포함할 수 있다. 송수신기(202)로부터 들어오는 정보를 수신한 후에, 프로세서(204)는 하나 이상의 출력 장치(208)를 위해 들어오는 정보를 형식 설정(format)한다. 이와 마찬가지로, 무선 신호의 전송을 위해, 프로세서(204)는 입력 장치(210)에 의해 활성화되거나 활성화되지 않을 수 있는 나가는 정보를 형식 설정하고, 통신 신호로 변조하기 위해 나가는 정보를 무선 송수신기들(202) 중 하나 이상의 무선 송수신기로 전달한다. 무선 송수신기(들)(202)는 변조된 신호를 무선 통신 링크를 통해(어쩌면 유선 통신 링크를 통해서도) 웹 서버(104) 및 CPW들(106) 중 하나 이상의 CPW와 같은 다른 장치로(뿐만 아니라, 어쩌면 셀 타워, 액세스 포인트, 또는 다른 서버 또는 각종의 원격 장치 중 임의의 원격 장치와 같은 다른 장치로도) 전달한다.
이 실시예에 따르면, 내부 구성요소(200)의 입력 및 출력 장치(208, 210)는 각종의 시각적, 오디오, 및/또는 기계적 출력을 포함할 수 있다. 예를 들어, 출력 장치(들)(208)는 액정 디스플레이 및 발광 다이오드 표시기와 같은 하나 이상의 시각적 출력 장치(216), 스피커, 알람, 및/또는 부저(buzzer)와 같은 하나 이상의 오디오 출력 장치(218), 및/또는 진동 메커니즘 또는 기타 햅틱 피드백 시스템과 같은 하나 이상의 기계적 출력 장치(220)를 포함할 수 있다. 시각적 출력 장치(216)는, 그 중에서도 특히, 비디오 화면을 포함할 수 있다. 이와 마찬가지로, 일례로서, 입력 장치(들)(210)는 광학 센서(예를 들어, 카메라)와 같은 하나 이상의 시각적 입력 장치(222), 마이크로폰과 같은 하나 이상의 오디오 입력 장치(224), 및 플립 센서(flip sensor), 키보드, 키패드, 선택 버튼, 내비게이션 클러스터, 터치 패드, 터치 스크린, 정전용량 센서, 움직임 센서, 및 스위치와 같은 하나 이상의 기계적 입력 장치(226)를 포함할 수 있다. 입력 장치들(210) 중 하나 이상의 입력 장치를 작동시킬 수 있는 동작은 버튼 또는 기타 작동기를 물리적으로 누르는 것/작동시키는 것을 포함할 수 있을 뿐만 아니라, 예를 들어, 모바일 장치를 여는 것, 장치를 잠금 해제하는 것, 움직임을 작동시키기 위해 장치를 이동시키는 것, 위치 확인 시스템을 작동시키기 위해 장치를 이동시키는 것, 및 장치를 조작하는 것을 포함할 수 있다.
도 2에 도시된 바와 같이, 모바일 장치(102)의 내부 구성요소(200)는 또한 다양한 유형의 센서들(228) 중 하나 이상의 센서를 포함할 수 있다. 센서(228)는, 예를 들어, 근접 센서(광 검출 센서, 초음파 송수신기 또는 적외선 송수신기), 터치 센서, 고도 센서, 위치 회로 - 예를 들어, GPS(Global Positioning System) 수신기, 삼각측량 수신기, 가속도계, 기울기 센서, 자이로스코프, 또는 현재 위치를 식별해줄 수 있는 임의의 다른 정보 수집 장치를 포함할 수 있음 - 또는 모바일 장치(102)의 사용자-장치 인터페이스(휴대 모드)를 포함할 수 있다.
내부 구성요소(200)의 메모리 부분(206)은 각종의 형태들[예컨대, 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 정적 랜덤 액세스 메모리(SRAM), 동적 랜덤 액세스 메모리(DRAM) 등] 중 임의의 형태의 하나 이상의 메모리 장치를 포함할 수 있고, 데이터를 저장 및 검색하기 위해 프로세서(204)에 의해 사용될 수 있다. 메모리 부분(206)에 의해 저장되는 데이터는 운영 체제, 응용 프로그램, 및 정보 데이터(이들로 제한될 필요는 없음)를 포함할 수 있다. 각각의 운영 체제는 내부 구성요소들(200) 중에 포함된 다양한 구성요소들 사이의 상호작용, 무선 송수신기(202) 및/또는 구성요소 인터페이스(212)를 통해 외부 장치와 통신하는 것, 그리고 메모리 부분(206)으로/으로부터 응용 프로그램 및 데이터를 저장/검색하는 것과 같은 통신 장치의 기본 기능을 제어하는 실행가능 코드를 포함한다. 각각의 응용 프로그램은 파일 시스템 서비스와 메모리 부분(206)에 저장된 보호(protected) 및 비보호(unprotected) 데이터를 처리하는 것과 같은, 통신 장치에 대한 보다 구체적인 기능을 제공하기 위해 운영 체제를 이용하는 실행가능 코드를 포함한다. 정보 데이터는 통신 장치의 기능을 수행하기 위해 운영 체제 또는 응용 프로그램에 의해 참조 및/또는 조작될 수 있는 비실행가능 코드 또는 정보이다.
그 다음에 도 3을 참조하면, 도 1의 웹 서버(104)의 부가의 예시적인 구성요소가 보다 상세히 도시되어 있다. 도시된 바와 같이, 웹 서버(104)는 메모리 부분(302), 그 메모리 부분과 통신하고 있는 프로세서 부분(304), 및 통신 링크(105, 108)와 프로세서(304)를 연결시키는 하나 이상의 입/출력(I/O) 인터페이스(도시 생략)를 포함한다. 프로세서 부분(304)은 백 엔드 부분(306)(또는 소셜 네트워크 프로세서) 및 프런트 엔드 부분(308)을 추가로 포함한다. 백 엔드 부분(306)은 통신 링크(108)를 통해 CPW(106)(파선으로 도시되어 있음)와 통신하고, 프런트 엔드 부분(308)은 통신 링크(105)를 통해 모바일 장치(102)(역시 파선으로 도시되어 있음)와 통신한다.
이하에서 더 상세히 논의되는 바와 같이, 적어도 일부 실시예에서, 백 엔드 부분(306)은 CPW(106)와 같은 CPW와의 풀 통신(pull communications)을 지원한다. 풀 통신은, 예를 들어, 웹에 전형적인 유형의 REST(Representation State Transfer) 아키텍처를 사용하여 구현될 수 있고, 그에 따라 백 엔드 부분(306)은 웹 서버(104)에 의해 결정되는 때/상황에서 CPW(106)와 같은 CPW로부터 백엔드 부분(306)에 제공될 정보에 대한 요청을 생성하도록 구성되어 있고, 그에 응답하여 CPW(106)는 요청된 데이터를 검색하여 웹 서버(104)에 다시 제공한다. 또한 이하에서 더 상세히 논의되는 바와 같이, 적어도 일부 실시예에서, 프런트 엔드 부분(308)은 모바일 장치(102)와 같은 모바일 장치와 관련하여 푸시 채널(push channel)을 설정한다.
적어도 일부 이러한 실시예에서, 푸시 채널은 웹 서버(104)에 의해 결정된 때/상황에서 프런트 엔드 부분(308)이 (프런트 엔드 부분에 의해 발생된) 웹 서버(104)로부터의 통지를 모바일 장치(102)에 제공할 수 있게 해준다. 통지는 모바일 장치에 제공될 수 있는 정보 내용을 나타낼 수 있다. 모바일 장치(102)는 차례로, 모바일 장치(102)에 의해 적절한 것으로 생각되는 방식(들)으로, 통지에 응답할 수 있다. 이러한 응답은 종종(항상 그럴 필요는 없음) 이용가능한 정보 내용 중 일부 또는 전부를 중개 웹 서버(104)의 프런트 엔드 부분으로부터 모바일 장치에 제공하라는 요청을 구성한다.
도 4를 참조하면, 특히 모바일 장치 및 CPW[도 1에 도시된 모바일 장치(102) 및 CPW(106) 등]와 상호작용하여 이들 사이의 통신을 중개할 때의 도 1 및 도 3의 웹 서버(104)의 예시적인 동작 단계들을 나타낸 플로우차트가 제공되어 있다. 시작 단계(400)에서 도 4의 플로우차트로 표현된 프로세스를 시작하면, 웹 서버(104)는 단계(402)에서 모바일 장치와 통신 링크[도 1의 모바일 장치(102)와 통신 링크(105)]를 설정하는 것에 의해 동작을 시작한다. 이하에서 더욱 상세히 기술될 것인 바와 같이, 모바일 장치와 통신 링크를 설정하는 것은, 실시예에 따라, 실제로는 그 모바일 장치와 다수의 통신 링크(병렬로 또는 상이한 때에 존재할 수 있음)를 설정하는 것을 포함할 수 있다.
어떤 이러한 경우에, 다수의 통신 링크는 상이한 유형(예를 들어, 푸시 채널 또는 푸시 채널 이외의 통신 프로토콜을 포함함)이다. 또한, 모바일 장치(102)와 통신 링크를 설정하는 것이 전형적으로 기지국과 회선 교환 연결을 설정하는 것을 포함하고 따라서 통신 장치가 기지국에 식별 정보를 제공하고 그에 의해 모바일 장치가 그 자신을 통신 네트워크에 확인시켜 주는 반면, 웹 서버(104)에의 연결도 역시 모바일 장치와 통신하고 있는 기지국과 부하 분산 장치/방화벽 사이의 IP(internet protocol) 연결 또는 P2P(point-to-point) 통신 연결을 통할 수 있고 또한 웹 서버로부터의 응답 신호를 다시 모바일 장치에 제공하는 것을 포함할 수 있으며 그에 의해 모바일 장치는 자신이 웹 서버와 연결되어 있음을 인식한다.
단계(402)의 완료 시에, 단계(404)에서, 웹 서버(104)는 또한 CPW와 통신 링크[도 1에 도시된 CPW(106)와의 통신 링크(108) 등]를 설정한다. 단계(404)에서 통신 링크를 설정하는 것은, 예를 들어, 하나 이상의 웹 서비스 호출 및/또는 기타 기법을 제공하는 것을 포함할 수 있다. 단계(404) 이후에, 웹 서버(104)는 CPW(106)와 지속적인 통신(주기적인 통신일 수 있지만, 꼭 그럴 필요는 없음)을 유지하고 한번 이상 CPW로부터 정보를 획득(풀링)한다. CPW로부터 획득된 정보는, 예를 들어, 연락처 또는 친구(연락처 목록을 포함함), 새로운 친구 또는 업데이트된 연락처, 특별 메시지, 뉴스, 사건에 관한 정보, 및 어쩌면 파일(이미지 파일 또는 텍스트 파일 등) 또는 기타 형태의 데이터를 포함하는 기타 유형의 정보를 비롯한 각종의 상이한 유형의 정보 중 임의의 것을 포함할 수 있다. 단계(406)에서 정보를 획득하면, 웹 서버는 이어서 단계(408)에서 획득된 정보를 처리한다.
그에 부가하여 도 5를 참조하면, 일 실시예에 따른, 도 4의 단계(406, 408)에 대응하는 예시적인 서브단계들이 도시되어 있다. 도시된 바와 같이, 단계(406)(획득하는 단계)는 몇개의 서브단계 - 시작 서브단계(500)에서 시작하고 3개의 부가적인 서브단계(502, 504, 506)를 추가로 포함함 - 를 포함하는 것으로 이해될 수 있다. 보다 상세하게는, 서브단계(502)에서, 웹 서버(104)는 풀 신호(pull signal)를 CPW(106)로 전송하고, 서브단계(504)에서, 정보가 다시 CPW로부터 웹 서버의 백 엔드 부분(306)에 수신된다. 정보가 백 엔드 부분(306)에 수신된 후에, 단계(506)에서, 이 정보는 이어서 백 엔드 부분으로부터 웹 서버(104)의 프런트 엔드 부분(308)으로 푸시된다.
게다가, 도 5에 도시된 바와 같이, 단계(408)(처리하는 단계)는, 일 실시예에서, 서브단계(508)에서 시작하여 서브단계(518)에서 종료하는 몇개의 서브단계를 포함할 수 있다[도 5는 단계(408)에 대응하는 서브단계들을 단계(406)에 대응하는 서브단계들에 계속하는 것으로 나타내고 있다]. 보다 상세하게는, 서브단계(508)에서, 웹 서버(104)의 프런트 엔드 부분(308)이 서브단계(506)에서 백 엔드 부분(306)으로부터 푸시된 정보를 수신하면, 그 정보는 이어서 공통 전송 큐에 위치된다. 그 다음에, 서브단계(510)에서, 정보가 선택적으로 압축될 수 있다. 게다가, 서브단계(512)에서, 정보가 선택적으로 상이한 형식(예를 들어, 이진 형식)으로 변환될 수 있다. 그에 부가하여, 블록(509)(파선으로 도시되어 있음)으로 나타낸 바와 같이, 서브단계(512)에서 일어나는 형식 변환은, 정보의 형식 설정을 표준화하고 소스 아이덴티티가 아닌 사이트-고유 형식 정보를 제거하거나, 정보의 형식 설정을, 정보의 소스였던 CPW 형식 설정에 상관없이 모바일 장치에 제공되는 균일한 또는 범용 형식으로 수정하기 위해, CPW(106)에 의해 제공되었던 특정의 형식 설정 정보를 제거하는 것을 포함할 수 있다.
그 다음에, 서브단계(514)에서, 정보가 상위 중요도(high importance) 정보인지 하위 중요도(low importance) 정보인지에 기초하여 정보가 필터링된다. 또한 서브단계(511, 513, 515, 517)(파선으로 도시되어 있음)에 나타낸 바와 같이, 이 필터링 동작은 추가적인 판정을 포함할 수 있다. 즉, 서브단계(511)에 도시된 바와 같이, 웹 서버(104)는 정보가 친구, 새로운 친구, 특별 메시지, 뉴스 또는 사건에 관한 것인지를 판정할 수 있다. 그러한 경우, 서브단계(513)에서, 그 정보는 하위 레벨 상태를 할당받는다. 그렇지만, 정보가 이들 그룹 중 하나에 속하지 않는 경우, 필터링 프로세스는 웹 서버가 정보가 상태 업데이트에 관한 것인지를 판정하는 서브단계(515)로 진행한다. 그러한 경우, 서브단계(517)에서 상위 레벨 상태가 정보에 할당된다. 본 예시적인 실시예에서, 서브단계(515)에서 정보가 상태 업데이트에 관한 것이 아니라고 판정되는 경우, 프로세스는 다시 서브단계(513)로 되돌아간다. 웹 서버(104)가 정보가 사용자에 대한 상태 업데이트인지를 판정할 수 있고, 그러한 경우, 정보를 상위 레벨 또는 상위 우선순위로 취급하고 그렇지 않은 경우 정보를 하위 레벨 또는 하위 우선순위로 취급할 수 있다는 것을 잘 알 것이다. 기타 유형의 정보가 또한 상위 우선순위로 취급될 수 있지만, 통신 장치의 활동의 증가를 가져오는 메시지의 수를 제한하는 것이 바람직하다.
필터링 서브단계(514)를 완료하면, 프로세스는 이어서 웹 서버(104)[구체적으로는 웹 서버의 프런트 엔드 부분(308)]가 단계(406)에서 CPW(106)로부터 획득되었던 정보와 동일한 CPW로부터 앞서 수신되었던 이전 정보 사이에 존재할지도 모르는 하나 이상의 차이점을 확인하는 서브단계(516)로 진행한다. 본 실시예에서, 궁극적으로 다시 모바일 장치(102)로 전송되는 것은 이러한 차이점 정보뿐이다. 이미 살펴본 바와 같이, 도 4의 단계(408)에 대응하는 도 5에 나타낸 서브단계들은 서브단계(518)에서 종료된다. 단계(516)가 유리하게도 단계(504)와 단계(506) 사이에서 백 엔드 부분(306)에서 행해질 수 있고, 이 경우 이전에 특정의 가입자에 대해 콘텐츠가 풀링되었던 때로부터의 CPW 정보에 변화가 있는 경우에만 정보가 웹 서버(104)에서 추가로 처리될 것임을 잘 알 것이다. 이것은 장치(102)의 사용자 또는 중개 웹 서버 및 CPW를 사용하는 다른 사용자를 위해 CPW로부터 계속하여 정보를 풀링하도록 서버 자원을 해방시킬 것이다.
도 4로 돌아가서, 단계(408)를 완료하면, 웹 서버(104)는 처리된 정보의 하나 이상의 부분이 상위 중요도인지 그렇지 않은지(예컨대, 하위 중요도인지 또는 어쩌면 중간 중요도 또는 어떤 다른 중요도 레벨인지)를 고려한다. 처리된 정보가 상위 중요도인 것으로 판정되는 경우, 단계(412)에서, 웹 서버(104)의 프런트 엔드 부분(308)은 상위 중요도의 처리된 정보를, 통신 링크(105)를 통해 설정된 푸시 채널을 거쳐 모바일 장치(102)로 전송한다. 이것은 웹 서버에 의해 결정된 때에 즉각 행해지고, 이는 푸시 채널을 사용함으로써 가능하게 된다. 단계(410)에서, 처리된 정보가 상위 중요도가 아닌 것으로 판정되는 경우, 처리된 정보를 전송하는 것이 다른 보다 적절한 때까지 지연될 수 있고, 그로써 장치와 서버 사이의 통신 활동을 감소시키며 따라서 장치 상의 배터리 소모를 감소시킨다. 따라서, 단계(414)에서, 웹 서버(104)는 처리된 정보를 모바일 장치(102)로 전송하기 위해 적절한 때를 기다린다. 이어서, 적절한 때가 오면, 단계(416)에서, 정보는 이어서 웹 서버(104)에 의해 모바일 장치(102)로 전송된다.
하위 중요도의 처리된 정보가 웹 서버(104)에 의해 모바일 장치(102)로 전송되는 적절한 때는 다양한 고려사항에 기초할 수 있다. 예를 들어, 일부 실시예에서, 이러한 적절한 때는 모바일 장치(102)가 정보를 얻기 위해 웹 서버(104)를 폴링하는 주기적으로 일어나는 때에 불과하다. 이러한 폴링은 전형적으로 모바일 장치(102)로부터 웹 서버(104)로 문의(inquiry) 신호를 반복하여 전송하는 것을 포함한다. 다른 경우에, 적절한 때는 특정의 상황이 발생했을 때에 일어난다. 예를 들어, 하위 중요도의 처리된 정보를 전송하는 적절한 때는 모바일 장치(102)가 요청을 할 때, 그에 부가하여, 바로 그 때쯤에 웹 서버(104)가 특정 양의 하위 중요도의 처리된 정보가 모바일 장치로 전송하기 위해 저장된 것으로 판정한 경우 일어날 수 있다. 이상의 설명에서, 웹 서버(104)에서 정보를 획득하는 것이 풀링하는 것을 포함하는 것으로 기술되어 있는 반면, 모바일 장치에서 웹 서버로부터 하위 중요도의 정보를 획득하는 것이 폴링을 포함하는 것으로 기술되어 있지만, 풀링 또는 폴링 동작 중 어느 하나(및 주기적 또는 비동기적 통신 중 어느 하나)가, 실시예에 따라, 각각 CPW(106) 및 웹 서버(104)로부터 정보를 획득하기 위해, 웹 서버 및 모바일 장치 중 어느 하나에 의해 각각 사용될 수 있다는 것을 잘 알 것이다. 그에 부가하여, 모바일 장치(102)가 시스템(100)에 연결되어 있지 않을 때 서버가 콘텐츠 공급자 웹 사이트(106)로부터 정보를 풀링하고 있을 수 있고, 그 결과로서 모바일 장치가 다시 연결될 때까지 또는 서버가 정보를 삭제할 정도로 충분한 시간이 경과할 때까지 서버가 정보를 보유하고 있을 것임이 생각된다.
단계(412)에서 상위 중요도의 정보가 모바일 장치(102)로 전송되는지 단계(416)에서 하위 중요도의 정보가 모바일 장치(102)로 전송되는지에 상관없이, 이들 단계가 완료되면, 일련의 부가적인 단계가 모바일 장치, CPW 또는 부가의 모바일 장치/CPW와 상호작용할 시에 웹 서버(104)에 의해 수행된다. 보다 상세하게는, 이와 관련하여, 단계(412, 416)를 완료하면, 단계(418 내지 428)에서, 모바일 장치(102)로부터의 정보가 웹 서버(104)에 업로드될 수 있고 게다가 CPW(106)에 제공될 수 있다. 도 4에 도시된 바와 같이, 단계(418)에서, 이러한 상호작용은 웹 서버(104)가 모바일 장치(102)로부터 식별 정보를 수신하는 것에 의해 시작될 수 있다. 예를 들어, 이러한 식별 정보가 단계(402)에서 이미 수신된 경우, 이러한 식별 정보를 수신하는 것이 항상 행해질 필요는 없다. 이어서, 단계(420)에서, 웹 서버(104)는 그에 부가하여 모바일 장치(102)로부터 콘텐츠 정보를 수신한다. 콘텐츠 정보는, 예를 들어, 모바일 장치의 사용자가 CPW에 존재하는 사용자 프로필(예컨대, "벽")에 업로드하고자 하는 이미지 파일 또는 텍스트 파일과 같은 파일 또는 기타 데이터를 포함할 수 있다.
그 다음에, 단계(422)에서, 웹 서버(104)는 콘텐츠 정보를 CPW(106)에 업로드하라고 웹 서버에 지시하는 명령을 모바일 장치(102)로부터 수신한다. 대안의 실시예에서, 이 명령은 모바일 장치(102)에 의해 웹 서버(104)에 명시적으로 제공될 필요가 없는데, 그 이유는, 이러한 실시예에서, 모바일 장치에 의해 제공되는 모든 콘텐츠 정보가 또한 그 모바일 장치와 연관되어 있는 임의의 CPW로 업로드되어야 하는 것으로 웹 서버에 의해 가정되기 때문이다. 게다가, 이어서 단계(424)에서, 웹 서버(104)는, 웹 서버와 CPW 사이의 관계를 인증하기 위해, 모바일 장치(102)로부터 수신된 식별 정보를 CPW(106)로 전송한다. 이 식별 정보를 전송한 것에 응답하여, 단계(426)에 나타낸 바와 같이, 인증이 만족스러운 경우, 전형적으로 토큰이 CPW로부터 다시 수신된다. 단계(418)에서와 같이, 단계(424, 426)가 모든 실시예에서 이 때 명시적으로 수행될 필요는 없으며, 이러한 동작이 단계(402, 404)에서 통신 링크를 설정하는 것의 일부로서 행해진 경우 특히 그렇다. 인증이 언제 행해지는지에 상관없이, 인증 프로세스는 웹 서버(104)가 모바일 장치(102)를 위해 또한 그의 프록시로서 CPW(106)와 상호작용할 수 있게 해준다. 적당한 인증이 행해진 것으로 가정하면, 단계(428)에서, 콘텐츠 정보가 웹 서버(104)에 의해 CPW(106)로 전송된다.
웹 서버(104)가 콘텐츠 공급자 웹 사이트 상의 특정의 사용자 계정에 대해 콘텐츠 공급자 웹 사이트(106)에/로부터 콘텐츠를 업로드/다운로드하는 데 요구되는 사용자 ID 및 비밀번호가, 모바일 장치(102)가 처음으로 서버에 연결되어 웹 서버 상에 콘텐츠 공급자 웹 사이트를 설정할 때, 사용자에 의해 웹 서버(104)에 로드될 수 있는 것이 생각된다. 웹 서버(104)는, 모바일 장치(102)가 연결되어 있는지에 상관없이 CPW와 지속적인 연결을 유지하기 위해, 사용자 ID 및 비밀번호를 메모리(302)에 저장하고, 사용자가 이들을 변경하지 않는 한, 사용자 ID 및 비밀번호를 사용하여 CPW에 액세스할 것이다. 또한, 모바일 장치가 소정의 기간 동안 웹 서버(104)로부터의 정보를 요청하지 않는 경우 또는 콘텐츠를 장치에 다운로드하기 위한 사용자 장치 큐가 연한 임계값(age threshold) 및/또는 저장 용량 임계값을 초과하는 경우, 콘텐츠 공급자(106)로부터 정보를 풀링하는 것이 빈도수가 감소되거나 완전히 정지될 수 있는 것이 생각된다.
앞서 기술한 업로드 프로세스에 부가하여, 어떤 상황에서, 모바일 장치(102)를 조작하는 사용자는 콘텐츠가 CPW들(106) 중 2개 이상의 CPW로 업로드되는 것을 원할 것이다. 이러한 프로세스는 도 4의 단계(430 내지 438)에 나타낸 바와 같이 웹 서버(104)에 의해 용이하게 될 수 있으며, 콘텐츠 정보가 이미 모바일 장치(102)에 의해 웹 서버에 제공된 경우에 특히 그렇다. 보다 상세하게는, 도시된 바와 같이, 단계(430)에서, 콘텐츠 정보를 다른 CPW에 제공하라고 웹 서버에 지시하는 추가의 명령이 모바일 장치(102)로부터 웹 서버에 수신되었는지가 웹 서버(104)에 의해 판정된다. 이러한 명령이 수신된 경우, 그 다음 단계(432)에서, 웹 서버(104)는 통신 링크가 다른 CPW와 이미 설정되었는지를 판정한다. 이러한 통신 링크가 아직 설정되지 않은 경우, 프로세스는 부가의 식별 정보가 모바일 장치(102)로부터 수신되는 단계(434)로 진행하고, 그 후에 단계(436)에서 그 통신 링크가 웹 서버(104)와 다른 CPW(106) 사이에 설정된다. 즉, 단계(432)에서 판정되는 바와 같이 통신 링크가 다른 CPW와 아직 설정되지 않은 경우, 이러한 통신 링크를 설정하기 위해, 웹 서버(104)는 또다시 식별 정보를 모바일 장치(102)로부터 제공받아, 그 웹 서버가 그 다른 CPW와 관련하여 모바일 장치에 대한 프록시로서 동작하기 위해[예컨대, 단계(424 및 426)와 관련하여 전술한 것과 실질적으로 동일한 동작임] 그 다른 CPW와 관련하여 인증될 수 있게 해주어야만 한다.
단계(436)에서 통신 링크가 설정되면, 또는 단계(432)에서 통신 링크가 이미 다른 CPW와 설정되어 있는 것으로 판정되는 경우, 프로세스는 콘텐츠 정보가 다른 CPW에 업로드되는 단계(438)로 진행한다. 따라서, 단계(430 내지 438)에 의해, 단계(428)에서 제1 CPW에 이미 제공된 콘텐츠 정보가 그에 부가하여 다른 CPW에 제공된다. 도 4가 단계(418 내지 438)를 반복 수행함에 있어서의 직접적인 루프(immediate looping)를 나타내고 있지는 않지만, 그 단계들이 정보의 수많은 부분 및 2개 이상의 부가의 CPW와 관련하여 여러번 반복될 수 있다는 것을 잘 알 것이다. 콘텐츠가 모바일 장치(102)로부터 균일한 형태로 제공될 것임과 서버 백 엔드가 콘텐츠가 업로드되고 있는 대상 CPW들 각각에 대해 개별적으로 적절히 데이터를 형식 설정할 것임이 생각된다.
게다가, 도 4와 관련하여, 단계(438)가 완료되면, 또는 단계(430)에서 어떤 명령도 수신되지 않은 것으로 웹 서버(104)에 의해 판정되는 경우에, 웹 서버는 그에 부가하여 계속하여 단계(440)에서 모바일 장치(102)가 웹 서버와 연결해제되었는지를 판정한다. 모바일 장치(102)가 웹 서버(104)와 연결해제되었더라도, 단계(442)로 나타낸 바와 같이, 일반적으로 웹 서버는 CPW(106) - 웹 서버가 이전에 그와 통신하기 시작하였고 웹 서버가 그와 관련하여 연결해제된 모바일 장치를 위해 프록시로서 역할할 수 있음 - 와 그의 통신 링크를 여전히 유지할 것이다. 따라서, 모바일 장치(102) - 웹 서버가 그를 위해 동작하고 있음 - 가 일시적으로 통신 두절될 수 있을지라도 웹 서버(104)는 CPW(106)와 관련하여 지속적으로 계속 동작할 수 있다. 결과적으로, 웹 서버(104)는 다양한 CPW(106)로부터 정보를 풀링하는 동작을 계속할 수 있고, 시간이 지남에 따라 이러한 정보에 액세스하여 그를 모니터링할 수 있으며, 따라서 이전에 연결해제된 모바일 장치가 웹 서버에 다시 연결될 때, 웹 서버는 즉각(적절한 경우) 이용가능한 가장 최근의 업데이트된 CPW 정보를 제공할 수 있다.
이상의 설명에도 불구하고 그리고 도 4에 도시되어 있지 않지만, 특정 실시예에서, 모바일 장치(102)가 웹 서버가 CPW들(106) 중 하나 이상과 관련하여 그를 위해 동작하는 것을 중단하라는 명령어를 웹 서버(104)에 전달하는 것이 가능하며, 이 경우에 웹 서버는 그렇게 할 것이다. 마지막으로, 역시 도 4에 도시된 바와 같이, 단계(442)가 완료되었을 때 또는 단계(440)에서 모바일 장치(102)가 여전히 연결되어 있는 것으로 판정되는 경우 둘다에서, 웹 서버(104)는 모바일 장치들(102) 및/또는 CPW들(106) 중 다른 것과 부가의 통신 링크를 설정하는 것이 필요하거나 요망되는지를 계속하여 판정한다. 이 플로우차트에 따르면, 이러한 필요 또는 요망이 없는 경우, 프로세스는 단계(446)에서 종료하는 반면, 이러한 필요 또는 요망이 있는 경우, 프로세스는 시작 단계(400)로 되돌아간다.
도 4에 도시된 특정의 단계들에도 불구하고, 실시예에 따라 각종의 부가적인 또는 상이한 단계들이 웹 서버(104)에 의해 수행될 수 있고 실시예에 따라 도 4에 도시된 특정의 단계들 중 하나 이상의 단계가 재배열, 반복 또는 완전히 제거될 수 있다는 것을 잘 알 것이다. 또한, 도 4의 플로우차트에 따라 수행되는 단계들 중 일부가, 단계들 중 다른 것이 수행되는 동안 동시에, 지속적으로 또는 연속적으로 반복될 수 있다. 예를 들어, CPW(106)로부터 수신된 정보의 획득 및 처리와 상위 중요도의 정보를 모바일 장치(102)로 즉각(또는 실질적으로 즉각) 전송하는 것에 관련된 단계(406 내지 412)가, 콘텐츠 정보를 모바일 장치로부터 웹 서버에 이어서 CPW들 중 하나 이상의 CPW에 업로드하는 것에 관련된 단계(418 내지 438)로 나타낸 것과 같은 다른 상호작용도 역시 수행되고 있는 동안에도, 지속적으로 또는 연속적으로 반복될 수 있다. 게다가, 도 4가 웹 서버(104)가 연속적으로 또는 동시에 다수의 CPW(106)와 통신할 수 있다는 것을 상세히 나타내고 있고 주어진 모바일 장치와 이러한 하나 이상의 CPW 사이에서 웹 서버에 의해 용이하게 되는 예시적인 상호작용을 나타내고 있지만, 임의의 수의 다른 모바일 장치와 이러한 하나 이상의 CPW 사이에서 유사한 상호작용이 일어날 수 있게 해준다는 점에서 동일한 프로세스가 웹 서버에 의해 동시에 또는 실질적으로 동시에 수행될 수 있다는 것을 잘 알 것이다.
백 엔드 부분(116)이 각각의 CPW(106)에 대해 개별적인 플러그인(plug-in)(그 각자의 CPW에 적절한 각자의 API를 포함함)을 포함할 수 있는 것이 생각된다. 각각의 플러그인은 그 각자의 CPW에 대한 API를 포함하고, 이 API에 의해 플러그인은 웹 사이트로부터 정보를 풀링하고 정보를 모바일 장치(102) 클라이언트의 범용 형식으로 다시 형식 설정한다. 그에 부가하여, 모바일 장치로부터의 콘텐츠가, 백 엔드 부분에 의해 업로드될 때, 모바일 장치(102) 클라이언트 프로그램의 균일한 형식으로부터 그 플러그인과 연관된 CPW에 의해 지정된 적절한 형식으로 다시 형식 설정될 것이다. 이러한 방식으로, 사용자 장치로부터의 콘텐츠가 균일한 형식을 갖는 단일 메시지로 전송될 수 있고, 사용자에 의해 선택된 대로 라우팅되며 그 콘텐츠가 보내지게 되어 있는 각자의 CPW들(106) 각각에 대한 각각의 백 엔드 부분 플러그인에 의해 형식 설정될 것이다.
도 6을 참조하면, 모바일 장치(102)가 웹 서버(104)와 상호작용하고, 이 상호작용에 의해, 하나 이상의 CPW(106)와 상호작용할 수 있을 때 모바일 장치(102)의 예시적인 동작 단계들을 나타낸 부가의 플로우차트가 제공되어 있다. 즉, 도 6은 상기 도 4 및 도 5에 예시된 웹 서버(104)에 의해 수행되는 다수의 단계들과 관련하여 상보적인(또는 대체로 상보적인) 모바일 장치(102)의 예시적인 동작 단계들을 나타내기 위한 것이다. 그에 부가하여, 이하에서 더 기술할 것인 바와 같이, 도 6은 또한 모바일 장치(102)가 웹 서버(104)에 의한 중개 없이 또는 웹 서버에 의한 중개와 동시적으로 함께(그렇지만, 그와 독립적으로) CPW들(106) 중 하나 이상의 CPW와 직접 상호작용할 수 있는 단계들을 포함한다. 도 6에 도시된 바와 같이, 시작 단계(600)에서 동작을 시작하면, 단계(602)에서 모바일 장치(102)는 웹 서버와 통신 링크를 설정하는 것과 따라서, 웹 서버를 통해, CPW와 통신 링크를 설정하는 것에 의해 웹 서버(104)와 상호작용하기 시작한다.
그에 부가하여 도 7을 참조하면, 단계(602)는 도 7에 예시된 몇개의 서브단계를 포함하는 것으로 이해될 수 있다. 도시된 바와 같이, 서브단계(700)에서 시작하면, 서브단계(702)에 나타낸 바와 같이, 모바일 장치(102)는 모바일 장치 상에서 지원되는 푸시 채널 응용 프로그램을 활성화시킨다. 이어서, 서브단계(704)에서, 모바일 장치(102)는 식별 정보를 웹 서버(104)에 제공한다. 이러한 식별 정보는, 예를 들어, 특정의 모바일 장치를 지정하는 식별 코드(예컨대, 일련 번호, 모델 번호 또는 제품 참조 번호), 모바일 장치를 이용하는 사용자의 아이덴티티에 관한 정보, 또는 로그인 또는 비밀번호 코드와 같은 기타 코딩 정보를 포함할 수 있다. 그 다음에, 서브단계(706)에서는, 웹 서버를 통해 CPW들(106) 중 특정의 CPW와 통신 링크를 설정하기를 원하는지가 모바일 장치(102)에서 판정된다. 이 때 그렇게 하기를 원하지 않는 경우, 도 7에 나타낸 프로세스는 서브단계(708)에서 종료된다. 다른 대안으로서, 사용자가 그렇게 하기를 원한다는 것을 나타내는 명령을 모바일 장치(102)에 제공하는 것으로 나타낼 수 있는 바와 같이, 웹 서버(104)를 통해 CPW(106)와 통신 링크를 설정하기를 원하는 경우, 서브단계(710)에서 모바일 장치(102)는 그에 부가하여 이러한 통신 링크를 설정하라고 웹 서버에 지시하는 명령을 웹 서버로 전송한다.
게다가, 서브단계(712)에서, 모바일 장치(102)는 그에 부가하여 웹 서버가 CPW(106)와 통신 링크를 설정할 수 있게 해주고 또 그 CPW와 통신하고 있는 모바일 장치에 대한 프록시로서 역할할 수 있게 해주는 부가의 웹 식별 정보를 웹 서버(104)로 전송한다. 일부 실시예에서, 서브단계(712)에서 전송된 식별 정보는 서브단계(704)에서 제공된 식별 정보와 동일할 수 있으며, 이 경우 서브단계(712)는 수행될 필요가 없다. 서브단계(712)에서 식별 정보가 제공되었으면, 서브단계(714)에서 모바일 장치와 웹 서버 사이에 푸시 채널 링크가 설정된다. 서브단계(714)가 완료하면, 단계(602) 이후에 도 6에 나타낸 프로세스의 나머지 단계들이 수행될 수 있다(블록 "A로 되돌아감"으로 나타내어져 있음).
도 6으로 되돌아가서, 단계(602)에서 웹 서버(104)와 통신 링크를 설정하면, 단계(604)에서, 모바일 장치(102)는 푸시 채널[예컨대, 서브단계(714)에서 설정된 푸시 채널]을 통해 웹 서버로부터 상위 중요도의 정보를 수신한다. 이 정보는, 도 4 및 도 5를 참조하여 이미 기술한 바와 같이, 본 실시예에서, 웹 서버(104)로부터 모바일 장치(102)에 비동기적 방식으로(즉, 모바일 장치에 의해 결정되지 않은 때에) 제공된다. 이러한 상위 중요도의 정보를 비동기적 방식으로 수신한 것에 부가하여, 후속하는 단계(606)에 의해 추가로 나타낸 바와 같이, 모바일 장치(102)는 그에 부가하여 웹 서버에 의해 모바일 장치로 다운로드될 다른 정보에 관한 하나 이상의 문의를 웹 서버(104)로 전송할 수 있다. 도 5를 참조하여 앞서 논의된 바와 같이, 상위 중요도의 정보가 상태 업데이트 정보와 같은 정보를 포함할 수 있는 반면, 다른 정보(예컨대, 하위 중요도의 정보)는 연락처/친구 정보, 새로운 친구 정보, 연락처 목록, 사진 또는 비디오, 특별 메시지, 뉴스 또는 사건 정보와 같은 정보를 포함할 수 있다.
단계(606)에서 모바일 장치(102)에 의해 제공되는 문의는 주기적으로 또는 모바일 장치에 의해 결정되는 다른 때에 제공될 수 있다. 본 실시예에서, 모바일 장치(102)가 웹 서버(104)에 대한 문의가 언제 행해지는지를 결정하고 차례로 상위 중요도의 정보 이외의 정보가 웹 서버로부터 모바일 장치로 전달되는지를 결정하는 것이 생각되지만, 다른 실시예에서, 이러한 문의 및/또는 정보의 다운로드가 웹 서버와 모바일 장치 사이의 상호 합의에 의해 결정된 때에, 웹 서버 단독에 의해서만 결정되는 때에(예컨대, 웹 서버가 충분한 양의 하위 중요도의 정보가 수집된 것으로 판정했을 때), 또는 이들 장치 둘다를 프로그램한 제조업체와 같은 다른 엔터티 또는 당사자에 의해 결정되는 때에 일어날 수 있다. 웹 서버(104)가 다시 모바일 장치로 정보를 전송하는 것을 요청하는 것이 모바일 장치(102)로부터의 문의인지 또는 이러한 정보를 전송하는 것을 요청하는 것이 다른 트리리거인지에 상관없이, 단계(608)에 나타낸 바와 같이, 궁극적으로 이러한 다른 정보가 또한 웹 서버로부터 모바일 장치에 수신된다. 단계(602)가 도 4의 단계(402)에 상보적인 것으로 간주될 수 있지만, 단계(604 내지 608)는 도 4의 단계(406 내지 412)[상세하게는 단계(414 내지 412)]로 나타낸 웹 서버 동작에 상보적인 것으로 간주될 수 있다.
여전히 도 6을 참조하면, 후속하는 단계(609)에서, 웹 서버(104)로부터 모바일 장치(102)에 의해 수신된 정보는 모바일 장치에 의해 디스플레이되거나 다른 방식으로 출력된다. 정보의 이러한 디스플레이/출력이 행해지는 정도는 실시예에 따라 다를 것이다. 적어도 일부 실시예에서, CPW-고유의 형식 설정 정보 또는 특징이 디스플레이된/출력된 정보의 일부로서 제공되지 않도록, 정보가 모바일 장치(102)에 의해 표준화된 방식으로 디스플레이/출력된다. 보다 상세하게는, 어떤 이러한 실시예에서, CPW-고유의 형식 설정 정보 및 특징이 웹 서버(104)에 의해, 또는 어떤 대안의 실시예에서, 모바일 장치에 의해 또는 웹 서버 및 모바일 장치 둘다의 조합에 의해 수정된다.
이러한 수정을 수행할 때, 상이한 CPW에서 발견되는 유사한 유형의 정보는, 상이한 CPW에 의해 상이한 방식으로(예컨대, 포스팅 사이트에서 발견되는 정보라고 또는 그 대신에 벽에서 발견되는 정보라고) 지칭될지라도, 개념적으로 유사한 유형인 것으로 인식되고, 이러한 인식에 기초하여, 이러한 정보는 정보의 출처와 상관없이 모바일 장치 상에 공통의 방식으로 디스플레이(또는 출력)될 수 있다. 즉, 이러한 CPW-고유의 형식 설정 정보 또는 특징이 수정되면, 상이한 CPW로부터의 동일한 개념적 유형의 정보가, 상이한 CPW에서 상이하게 형식 설정될지라도, 그럼에도 불구하고 그 정보의 출처에 상관없이 동일하거나 유사한 일관된 방식으로 모바일 장치 상에 디스플레이되고, 따라서 이러한 정보에 대한 사용자의 검토를 용이하게 해준다. 또한 주목할 점은, 이러한 정보가 텍스트 및 이미지 데이터 뿐만 아니라 아주 다양한 다른 데이터(사용자가 부가의 정보 또는 명령 - 나중에 다시 웹 서버로 전송될 수 있음 - 을 입력할 수 있는 대화형 창 및 데이터 엔트리 필드를 모바일 장치 상에 디스플레이하는 것을 가능하게 해주는 데이터를 포함함)도 포함할 수 있다는 것이다.
그 다음에, 단계(610)에서, 모바일 장치(102)는 모바일 장치에서 현재 이용가능한 콘텐츠 정보를 웹 서버에 및/또는 궁극적으로 CPW(106)에 업로드하는 것이 필요하거나 요망되는지를 판정한다. 이 필요성 또는 요망은 모바일 장치(102)에 의해, 예를 들어, 특정 유형의 정보가 사용자 또는 다른 소스로부터 모바일 장치에 수신되었는지 또는 특정의 이벤트가 발생하거나 시간이 경과하여 이러한 업로드 이벤트를 트리거했는지에 기초하여 자동으로 판정될 수 있다. 종종, 이러한 필요성/요망은 모바일 장치(102)에 제공되는 사용자 명령에 응답하여 일어날 것이다. 단계(610)에서 이러한 필요성/요망이 없는 것으로 판정되는 경우, 도시된 바와 같이, 프로세스는 이하에서 논의되는 단계(622)로 진행한다. 그렇지만, 단계(610)에서 이러한 필요성/요망이 있는 것으로 판정되는 경우, 단계(612)에서, 모바일 장치(102)는 콘텐츠 정보를 웹 서버(104)로 전송하고, 단계(614)에서, 모바일 장치는 그에 부가하여 콘텐츠 정보를 CPW(106)에 업로드하라는 명령을 웹 서버로 전송한다. 단계(418)를 참조하여 논의된 인증을 위해 모바일 장치(102)로부터 제공되는 식별 정보가 도 6에 도시된 단계(602)에서 이미 제공된 것으로 이해될 수 있는 것[다른 대안으로서, 이 목적에 적당한 부가의 식별 정보가 단계(612) 직전에 제공될 수 있는 것]을 제외하고는, 단계(610 내지 614)가 일반적으로 도 4의 단계(418 내지 428)에 상보적인 것으로 이해될 수 있다.
단계(614)가 완료되면, 단계(616)에서, 모바일 장치(102)는 또한 콘텐츠 정보를, 그 정보가 이미 업로드되어 있는 제1 CPW에 부가하여, 하나 이상의 부가적인 CPW에 업로드하는 것이 필요한지/요망되는지를 판정한다. 다시 말하지만, 그 필요성 또는 요망은, 그 중에서도 특히, 모바일 장치의 사용자에 의해 모바일 장치에 제공되는 하나 이상의 명령어를 비롯한 각종의 인자에 기초하여 판정될 수 있다. 단계(616)에서 이러한 필요성 또는 요망이 없는 것으로 판정되는 경우, 프로세스는 이하에서 논의되는 단계(622)로 다시 진행한다. 그렇지만, 단계(616)에서 이러한 필요성 또는 요망이 있는 것으로 판정되는 경우, 프로세스는 부가의 통신 링크가 웹 서버를 통해 모바일 장치와 이러한 부가의 CPW 사이에 설정되는 단계(618)로 진행한다. 단계(618)는 도 4의 단계(432 내지 436)에 상보적인 것으로 간주될 수 있고, 실시예에 따라, 모바일 장치가 먼저 이러한 부가의 CPW와의 통신 링크가 이미 존재하는지를 판정하고, 이러한 통신 링크가 아직 존재하지 않는 것으로 판정되는 경우, 이러한 부가의 CPW와의 이러한 통신 링크를 설정하고 웹 서버가 이러한 통신에서 모바일 장치에 대한 프록시로서 역할할 수 있게 해주기 위해, 부가의 식별 정보를 웹 서버로 전송하는 서브단계들을 포함할 수 있다.
단계(618)에서 부가의 CPW(106)와의 부가의 통신 링크가 설정되면, 단계(620)에서, 모바일 장치(102)는 또한 콘텐츠 정보를 그 부가의 CPW(106)에 업로드하라는 명령을 웹 서버(104)로 전송한다. 단계(620)의 수행은 도 4의 단계(430)에 대응하는 것으로 이해될 수 있고, 또한 단계들(618 및 620)의 수행의 순서가, 이들 단계가 도 4의 단계들(430 내지 436)의 순서에 더 밀접하게 대응하도록, 반대로 될 수 있다는 것을 잘 알 것이다. 그에 부가하여, 도 6과 관련하여, 단계(620)가 완료되면, 웹 서버(104)가 실제로 콘텐츠 정보를 부가의 CPW에 업로드하는 것으로 가정한다. 도시되어 있지는 않지만, 일부 실시예에서, 이러한 업로드가 완료되면, 웹 서버(104)는 이러한 업로드가 일어났다는 것을 확인해주는 표시 신호를 다시 모바일 장치(102)로 전송한다.
도 6의 상기한 단계들은 물론 도 4의 단계들이 모바일 장치(102)와 CPW(106) 사이의 매개체로서 웹 서버(104)를 사용하는 것을 생각하고 있지만, 웹 서버가 항상 이러한 통신을 중개할 필요는 없으며, 오히려 어떤 상황에서 모바일 장치는 CPW들 중 하나 이상의 CPW에 대하여 직접(즉, 어떤 웹 서버도 포함하지 않거나 적어도 상기한 웹 서버를 포함하지 않는 하나 이상의 네트워크를 통해 직접) 상호작용한다. 그와 관련하여, 모바일 장치(102)는, 단계(620)[또는, 어떤 경우에, 상기한 단계(610, 616)]를 완료하면, 단계(622)에서 모바일 장치가 CPW들(106) 중 하나 이상의 CPW와 직접 통신하는 것이 필요하거나 요망되는지를 추가로 판정한다.
모바일 장치(102)가 단계(622)에서 그렇지 않은 것으로 판정하는 경우, 모바일 장치는 그의 동작에서 노드 A로 되돌아갈 수 있고, 그에 응답하여 프로세스는 다시 단계(604)에서 시작하여 계속 진행한다. 이것이 일어난 것으로 가정할 때, 모바일 장치(102)는 따라서 웹 서버(104)로부터 정보를 계속 수신하기도 하고 또한 반복하여 지속적으로 콘텐츠 정보를 웹 서버에 업로드하는 동작을 계속한다. 그렇지만, 단계(622)에서, 모바일 장치(102)가 CPW(106)와 직접 통신하는 것이 필요하거나 요망되는 것으로 판정하는 경우, 모바일 장치는 모바일 장치가 이러한 직접 통신 링크를 설정하는 단계(624)로 진행한다.
CPW(106)와 직접 통신하는 것이 필요하거나 요망되는지는 각종의 고려사항에 기초하여 판정될 수 있다. 어떤 상황에서, 모바일 장치(102)는 이것을 자동으로 판정하고, 그 결과 자동으로 CPW(106)와 직접 통신 링크를 설정하기 시작한다. 예를 들어, 사용자가 특정의 주제에 관한 추가 정보를 요청하고 그 정보를 주어진 CPW로부터 다운로드하는 것이 CPW와의 직접 통신을 통해 최상으로(예컨대, 데이터 전송의 효율성 등의 점에서) 달성되는 경우, 모바일 장치는 CPW에 직접 연결하려고 시도할 수 있다. 또한, 어떤 상황에서, 사용자가 특정의 CPW에서 그 CPW와 연관된 특정의 형식으로 이용가능한 정보를 보기를 원하고 이러한 정보의 수정된 뷰[정보가 모바일 장치로 가는 도중에 웹 서버(104)에 의해 처리되는 경우에 제공될 수 있음]는 보기를 원하지 않는 일이 있을 수 있다. 또한, CPW(106)와 직접 통신하는 것이 필요하거나 요망되는지를 판정하는 것이 이러한 통신을 명시적으로 요청하는 사용자 명령의 수신에 기초하여 판정될 수 있다.
단계(624)에서 직접 통신 링크를 설정하는 것은 모바일 장치에 의한 각종의 특정의 명령 또는 동작을 수반할 수 있고, 이는 어떤 상황에서, 실시예에 따라, 사용자로부터 입력을 수신하는 것을 수반할 수 있다. 예를 들어, 한 상황에서, 사용자는 브라우저 응용 프로그램/프로그램이 모바일 장치 상에서 열려 실행되게 하는 것에 의해 그리고 브라우저에 의해 제공되는 입력 필드에 CPW에 대한 URL(Universal Resource Locator)을 입력하는 것에 의해 이러한 직접 통신 링크의 설정을 시작하며, 그 결과 브라우저는 CPW와 통신하기 시작하고 CPW는 차례로 웹 페이지 또는 기타 정보를 다시 브라우저에 반환하며, 그에 의해 모바일 장치(및 사용자)는 CPW와 추가의 통신을 시작하게 될 수 있다. 다른 실시예에서, 직접 통신 링크의 설정은 어떤 특정의 사용자 동작도 수반하지 않는 자동 프로세스이다.
직접 통신 링크가 어떻게 설정되느냐에 상관없이, 그 링크가 설정되면, 추가의 단계(626)에서, 모바일 장치(102)는 (다시 말하지만, 상기한 웹 서버의 중개 없이) 직접 CPW(106)로 및/또는 CPW(106)로부터 정보를 전송 및/또는 수신한다. 그 후에, 단계(628)에서, 모바일 장치는 또한 웹 서버(104)와의 기존의 통신 링크를 중단하는 것이 필요하거나 요망되는지를 판정한다. 이러한 필요성/요망이 없는 경우, 프로세스는 노드 A로 되돌아가고, 다시 단계(604) 및 후속 단계들이 반복된다. 즉, 모바일 장치와 CPW(들) 사이의 직접 통신(웹 서버 중개 없음) 및 간접 통신(웹 서버를 통함) 둘다가 동시에 계속될 수 있다. 그렇지만, 단계(628)에서, 서버-기반 통신을 중단하는 것이 필요하거나 요망되는 것으로 판정되는 경우, 프로세스는 모바일 장치와 웹 서버 간의 통신이 단절되는 단계(630)[도 4와 관련하여 이상에서 논의된 단계(440)에 대응함]로 진행한다.
본 실시예에서, 앞서 논의된 바와 같이, 웹 서버(104)는, 모바일 장치와의 통신이 종료된 후에도, 이전에 모바일 장치를 위해 통신하고 있었던 CPW 또는 사이트와 그 자신 간의 통신을 유지하도록 구성되어 있으며, 그로써 웹 서버(104)는 계속하여 모바일 장치에 대한 프록시로서 역할한다. 그렇지만, 다른 실시예에서, 모바일 장치가 웹 서버(104)와의 통신을 종료할 때 웹 서버와 CPW(106) 간의 통신이 단절된다. 어느 경우든지, 단계(630)에 후속하여, 단계(632)에서 모바일 장치(102) 측에서 웹 서버(104)와 통신을 재설정하는 것이 새로 필요하거나 요망될 수 있다. 단계(622)에서 CPW(106)와의 직접 통신을 시작하는지 또는 단계(628)에서 웹 서버(104)와의 통신을 중단하는지의 판정에서와 같이, 단계(632)에서 모바일 장치(102) 측에서 웹 서버(104)와 통신을 재설정하는 것이 필요하거나 요망되는지는, 예를 들어, 이러한 활동을 트리거하는 사용자 명령, 배터리 전력 고려사항 등을 비롯한 각종의 고려사항들 중 임의의 것에 기초하여 판정될 수 있다. 단계(632)에서 서버-기반 통신이 재설정되어야만 하는 것으로 판정되는 경우, 프로세스는 시작 단계(600)로 되돌아간다. 그렇지 않은 경우, 도 6에 나타낸 프로세스는 종료 단계(634)에서 종료된다.
도 8 및 도 9를 각각 참조하면, 추가의 실시예에서, 웹 서버(104) 및 모바일 장치(102)에 의해 수행되는 동작은 도 4 내지 도 7에 도시된 것과 약간 상이할 수 있다. 보다 상세하게는, 어떤 다른 실시예에서, 도 4에 도시된 노드 B와 노드 C 사이에서 단계들(408 내지 416)을 수행하기 보다는, 웹 서버(104)는 그 대신에 도 8에 도시된 단계들(800 내지 814)을 수반하는 상이한 방식으로 동작한다. 도시된 바와 같이, 노드 B로부터 계속되면, 처리 단계(408)(도 5에 도시된 대응하는 단계들)를 수행하기 보다는, 웹 서버(104)는 그 대신에 단계들(800, 802, 804)을 수행한다. 상세하게는 단계(800)에서, 웹 서버(104)는 단계(406)에서 CPW(106)로부터 방금 획득된/풀링된 정보와 보다 앞선 때에 그 CPW로부터 이전에 수신된 정보 사이에 변경이 있었는지를 판정한다. 단계(802)에서 변경(들)이 검출되는 경우, 단계(804)에서 웹 서버(104)의 프런트 엔드 부분(308)은 그 변경 정보를 변경 목록에 위치시킨다. 이들 단계가 웹 서버(104)와 연결되어 있는 다수의 CPW와 관련하여 반복하여 수행되는 경우, 각각의 CPW와 관련하여 검출된 변경 정보 모두가 변경 목록(이 경우에, 공통 변경 목록이라고 할 수 있음)에 넣어질 수 있다.
그 다음에, 단계(806)에서, 웹 서버(104)의 프런트 엔드 부분(308)은 처리된 정보가 상위 중요도인지 그렇지 않은지(예컨대, 하위 중요도인지)를 판정한다. 이 판정을 수행함에 있어서, 도 4의 단계(410)와 관련하여 앞서 논의되었던 것과 동일한 고려사항이 고려될 수 있고, 그 때문에 단계(806)는 또한 도 8에서 단계(410)로도 표시되어 있다. 처리된 정보가 상위 중요도인 것으로 판정되는지 하위 중요도인 것으로 판정되는지에 따라, 프로세스는 이어서, 각각, 단계(808) 또는 단계(810)로 진행한다. 단계(808)에서, 처리된 정보가 상위 중요도인 것으로(예컨대, 정보가 상태 업데이트에 관한 것으로) 판정하면, 웹 서버(104)의 프런트 엔드 부분(308)은 상위 중요도의 변경이 일어났다는 것을 나타내는 통지를 푸시 채널을 통해 모바일 장치(102)로 전송한다. 이와 마찬가지로, 단계(810)에서, 처리된 정보가 하위 중요도인 것으로 판정하면, 웹 서버(104)의 프런트 엔드 부분(308)은 하위 중요도의 변경이 일어났다는 것을 나타내는 통지를 역시 푸시 채널을 통해 모바일 장치(102)로 전송한다.
단계(808) 또는 단계(810) 중 어느 하나에서 통지가 전송되었으면, 단계(812)에서 웹 서버(104)의 프런트 엔드 부분(308)은 나중에 변경 정보 자체를 전송하라는 요청을 모바일 장치(102)로부터 수신할 수 있다. 이 요청은 모바일 장치(102)에 의해 결정되는 임의의 때에 수신될 수 있다. 종종, 변경 정보가 상위 중요도인 경우, 모바일 장치(102)는, 즉각 또는 단계(808)에서 통지를 수신한 후 곧바로, 정보에 대한 요청을 전송할 것이다. 이와 달리, 변경 정보가 하위 중요도인 경우, 모바일 장치는 종종 이러한 요청을 위한 소정의 시간(예컨대, 주기적인 또는 비주기적인 폴링 시간)에 도달할 때까지 기다릴 것이다. 예를 들어, 장치는 상위 중요도의 정보를 요청하기 위해 5분 이하 동안 기다릴 수 있고, 하위 중요도의 정보를 다운로드하기 위해 요청들 간에 15 내지 30분 동안 기다릴 수 있다. 어느 경우든지, 변경 정보를 전송하라는 요청이 단계(812)에서 모바일 장치(102)로부터 수신되면, 요청된 변경 정보는 그 후에 웹 서버(104)의 프런트 엔드 부분(308)에 의해 모바일 장치(102)로 전송된다. 이 일례에서, 변경 내용을 수신하기 위해 모바일 장치가 켜져 있는 시간량을 감소시키기 위해 이 변경 정보가 푸시 채널에 의해 전송되지 않는 것, 또는, 다른 대안으로서, 상위 중요도의 변경 정보만이 푸시 채널에 의해 전송되는 것이 바람직하지만, 다른 실시예에서, 모든 변경 정보가 푸시 채널을 통해 전송될 수 있다는 것을 알 것이다. 단계(814)에서 이 정보를 전송하면, 또는 단계(812)에서 정보에 대한 어떤 요청도 수신되지 않은 경우(또는 적어도 소정의 기간 내에 수신되지 않은 경우), 또는 단계(802)에서 CPW(106)로부터 수신된 정보에서 어떤 변경도 검출되지 않은 경우, 프로세스는 도 4의 노드 C로[따라서 단계(418)로] 되돌아간다. 어떤 콘텐츠도 콘텐츠 공급자 웹 사이트에 업로드하도록 요구되지 않은 경우, 서버가 단계(406)로 되돌아갈 것인데, 그 이유는 콘텐츠가 모바일 장치(102) 클라이언트에 업로드되고 있는지에 상관없이 서버가 콘텐츠 공급자 웹 사이트(106)로부터 콘텐츠를 계속 풀링할 것이기 때문임을 잘 알 것이다.
이 일례에서, 변경 정보가 상위 중요도인지 하위 중요도인지에 상관없이 변경 정보의 통지가 단계들(808, 812)에서 푸시 채널을 통해 동일한 방식으로 제공되지만, 항상 이럴 필요는 없다. 다른 실시예에서, 예를 들어, 상위 중요도의 변경에 관한 통지는 하위 중요도의 변경에 관한 통지보다 더 신속하게 또는 그와 다른 어떤 방식으로 전송될 수 있다. 게다가, 도 8의 이 일례에서, 단계(814)에서 변경 정보를 전송하는 것이 단계들(808, 810)에서 통지를 전송하는 것과 상이한 때에 일어나고 있지만, 항상 이럴 필요는 없다. 예를 들어, 한 다른 실시예에서, 상위 중요도의 변경 정보의 콘텐츠가 작은 경우(예컨대, 100개 미만의 문자의 텍스트 메시지인 경우), 그 콘텐츠는 상위 중요도의 변경의 통지와 함께 제공될 수 있다(또는 심지어 그 통지로서 역할할 수 있다). 이상의 설명으로부터, 또한 적어도 일부 실시예에서, 백 엔드 부분 및 프런트 엔드 부분과 CPW(106) 및 모바일 장치(102) 간의 각자의 통신의 점에서 백 엔드 부분의 동작이 대체로 또는 전적으로 프런트 엔드 부분의 동작에 독립적일 수 있다는 것이 명백할 것이다. 각종의 상이한 유형의 통신(예를 들어, 풀링 또는 폴링, 또는 주기적 또는 비동기적 통신을 수반하는 통신)이, 실시예에 따라, 백 엔드 부분 및 프런트 엔드 부분 중 한쪽 부분에 의해 다른 쪽 부분의 동작에 상관없이 이용될 수 있다. 따라서, 벡 엔드는 계속하여 CPW로부터 콘텐츠를 풀링할 수 있고, 프런트 엔드 부분이 무엇을 하고 있는지에 관계없이, 변경을 프런트 엔드 부분으로 전송할 수 있다. 백 엔드가 임의의 특정 순간에 무엇을 하고 있는지에 관계없이, 프런트 엔드 부분은 이와 마찬가지로 모바일 장치로 푸시할 수 있고 변경 콘텐츠를 다운로드하거나 서버와 모바일 장치를 동기화시키라는 요청을 기다릴 수 있다.
도 9에 대해서, 도면에 제공된 플로우차트는, 어떤 다른 실시예에서, 도 6에 도시된 노드 A와 노드 D 사이에서 단계들(604 내지 609)을 수행하기 보다는, 모바일 장치(102)는 그 대신에 단계들(900 내지 914)을 수반하는 상이한 방식으로 동작한다. 도 9에 도시된 모바일 장치(102)에 의해 수행되는 단계들(900 내지 914)은 특히 도 8에 도시된 웹 서버(104)에 의해 수행되는 단계들(800 내지 814)에 대해 상보적이다. 도 9에 도시된 바와 같이, 노드 A로 진행하면, 도 6의 수신 단계(604)를 수행하기 보다는, 모바일 장치(102)는 그 대신에 가장 최근에 또한 보다 앞선 때에 CPW(106)로부터 제공된 정보에서 하나 이상의 변경(들)이 검출되었다는 통지[단계들(808, 810) 중 하나 또는 둘다에서 전송됨]를 웹 서버(104)로부터 수신할 수 있다. 단계(900)에서 통지가 수신되는 경우, 단계(902)에서 모바일 장치(102)는 통지가 변경이 상위 중요도임을 나타내는지 하위 중요도임을 나타내는지를 판정한다.
단계(902)에서 변경이 상위 중요도인 것으로 판정되는 경우, 단계(904)에서 모바일 장치(102)는 상위 중요도의 변경 정보가 웹 서버(104)로부터 즉각 획득되어야 하는지를 판정한다. 일부 실시예에서는, 항상 그렇듯이 상위 중요도의 변경 정보가 가능한 한 빨리 획득되어야 하지만, 다른 실시예에서는, 모바일 장치는 여전히 여러가지 이유로(예컨대, 모바일 장치가 저전력 상태에 있기 때문에) 웹 서버로부터 그 정보를 획득하려고 시도하는 것을 연기하는 것이 바람직할 것으로 판정할 수 있다. 단계(904)에서 모바일 장치(102)가 변경 정보가 즉각 획득되어야 하는 것으로 판정한다고 가정하면, 프로세스는 모바일 장치가 상위 중요도의 변경 정보가 모바일 장치로 즉시 제공되어야 한다고 요청하는 요청 신호를 즉각 웹 서버로 전송하는 단계(906)로 진행한다. 그에 응답하여, 단계(908)에서, 모바일 장치(102)는 궁극적으로 요청된 변경 정보[또는 웹 서버(104)에 의해 결정되는 바와 같은, 그 정보의 적어도 일부]를 웹 서버로부터 수신한다. 이와 관련하여, 단계(908)를 수행하는 것은 도 8의 단계(814)를 수행하는 것을 보완한다.
다른 대안으로서, 단계(902)에서 통지가 변경 정보가 하위 중요도임을 나타내는 것으로 모바일 장치에 의해 판정되는 경우, 또는 단계(904)에서 모바일 장치가 변경 정보가 즉각 획득되어서는 안되는 것으로(또는 즉각 획득될 필요가 없는 것으로) 판정하는 경우, 프로세스는 단계(910)로 진행한다. 단계(910)에서, 모바일 장치(102)는 또한 변경 정보를 얻기 위해 웹 서버(104)를 폴링하기 위한 적절한 때가 되었는지를 판정한다. 이러한 적절한 때는 주기적으로 일어나는 때일 수 있거나, 다른 실시예에서, 각종의 다른 고려사항[예컨대, 다른 이벤트 이후에 소정의 시간이 경과했는지 또는 웹 서버(104)로부터 콘텐츠 정보를 획득하라고 모바일 장치에 지시하는 사용자 명령이 수신되었는지]에 기초하여 모바일 장치(102)에 의해 결정될 수 있다.
단계(910)에서 웹 서버를 폴링하기 위한 적절한 때가 아직 되지 않은 경우, 프로세스는 이러한 때가 될 때까지 그 단계를 반복할 수 있다[또는 프로세스의 다른 단계로 진행하고 및/또는 어쩌면 다른 때에 단계(910)로 되돌아갈 수 있음]. 그렇지만, 단계(910)에서 적절한 때가 된 경우, 프로세스는 폴링/요청 신호가 모바일 장치(102)에 의해 웹 서버(104)로 전송되는 단계(912)로 진행한다. 그 신호를 전송하면, 프로세스는 모바일 장치(102)가 요청된 변경 정보를 수신하는 단계(908)로 되돌아간다. 또한, 도 9에 도시된 바와 같이, 단계(908)를 완료하면, 모바일 장치(102)는, 모바일 장치의 사용자가 정보를 검토할 수 있게 해주기 위해, 수신된 정보가 모바일 장치(102)에 의해 디스플레이되거나 다른 방식으로 출력되는 단계(913)를 수행하기 시작한다. 단계(913)는, 도시된 바와 같이, 도 6의 단계(609)와 동일하거나 유사할 수 있다.
단계(908)에서 웹 서버(104)에 의해 전송된 변경 정보가 종종 모바일 장치(102)의 사용자의 관심을 가장 많이 끌지만, 이 변경 정보는 종종 웹 서버에 의한 그 정보의 처리 이전에 CPW(106)에서 원래 이용가능하였던 각종의 콘텐츠 정보(및 형식 설정 정보)를 제외하고 있다. 즉, 웹 서버(104)에 의해 제공되는 정보가 사건, 최근 상태 정보, 다른 사람으로부터의 코멘트 등과 같은 다양한 콘텐츠를 포함할 수 있고 모바일 장치(102)가 또한 당연히 특정의 표준 정보(예컨대, 사용자의 이름, 사용자와 연결되어 있는 CPW 등)를 그의 사용자 인터페이스의 일부로서 디스플레이할 수 있지만, 웹 서버(104)의 중개로 인해 상당한 양의 콘텐츠 및/또는 기타 정보가 제외될 수 있다. 이 때문에, 단계(913)에서 변경 정보를 디스플레이하면, 사용자는 변경 정보를 획득할 뿐만 아니라 다른 콘텐츠(또는 심지어 형식 설정) 정보도 획득하는 것이 바람직할 것으로 결정할 수 있다. 사용자가 이러한 다른 정보를 획득하기를 원할지도 모르는 경우, 후속 단계(914)에서 모바일 장치는 또한 단계(908)에서 웹 서버(104)로부터 수신되지 않은 다른 정보를 획득하라는 사용자 명령이 수신되었는지를 판정한다. 이러한 명령이, 예를 들어, 사용자가 모바일 장치에 의해 디스플레이되는 아이콘 - 단계(913)에서 변경 정보의 일부로서 디스플레이될 수 있음 - 을 선택할 때 수신될 수 있다.
단계(914)에서 이러한 명령이 수신된 것으로 판정되는 경우, 단계(916)에서 모바일 장치(102)는 CPW(106)와 직접 통신 링크를 설정한다. 직접 통신 링크를 설정하는 이 동작은 이상에서 논의된 단계(624)와 연관된 동작과 동일하거나 유사할 수 있고, 통신 링크를 설정하고 또한 사용자가 원했던 다른 정보를 도출하도록 설계되어 있는 표준의 웹-기반 클라이언트-서버 통신[예컨대, URL(uniform resource locator)의 입력/전송 및/또는 CPW(106)의 웹 페이지와 인터페이스하는 것을 수반함]을 수반할 수 있다. 따라서, 단계(916)에서 직접 통신 링크를 설정하면, 단계(918)에서 사용자가 원하는 다른 정보가 CPW(106)로부터 수신된다. 단계(918)가 완료되는 것은 물론 단계(914)에서 어떤 사용자 명령도 수신되지 않은 것으로 판정되는 경우, 또는 단계(900)에서 웹 서버(104)로부터의 통지가 수신된 경우, 프로세스는 노드 D로 되돌아가고 도 6의 단계(610)에서 계속된다.
본 발명의 다른 대안의 실시예에서, 백 엔드 부분(306)은 복수의 플러그인 또는 프로세서를 포함하고, 이들 각각은 각자의 CPW(106)와 연관되어 있다. 각각의 플러그인은 그의 연관된 콘텐츠 공급자 웹 사이트(106)에 대한 API(application programming interface)를 포함한다. 각각의 플러그인은 그 각자의 콘텐츠 공급자 웹 사이트(106)로부터 정보를 지속적으로 풀링하기 위해 HTTP(hypertext transfer protocol)를 사용한다.
백 엔드 부분(306) 플러그인에 의해 변경이 검출될 때, 변경이 큐에 로드되고, 프런트 엔드 부분(308)은 통지를 장치로 푸시한다. 백 엔드 부분(306)에 있는 모든 플러그인은, 예를 들어, 정보의 소스의 ID(소스 콘텐츠 공급자 웹 사이트 식별), 사용자 장치의 계정 ID, 콘텐츠 유형, 우선순위, 및 정보를 포함하는, 공통 형식에 따라 형식 설정된 정보를 큐에 계속 로드할 것이다. 예를 들어, 상태의 경우에, 형식은 유형(STATUS, MOOD, STATUS_AND_MOOD), 동작(상태 지우기 또는 상태 업데이트), 공급자, 통합 서비스 계정 id, 외부 id, 업데이트가 친구에 대한 것인 경우 친구 id, 상태 텍스트, 포스팅 날짜 및 시간일 수 있다. 웹 서버는 모든 플러그인에 의해 풀링된 콘텐츠를 각자의 장치(또는 사용자 계정) 각각에 대한 공통 변경 목록으로 결합시킴으로써 각각의 사용자 장치(또는 사용자 계정)에 대한 통합된 피드를 작성한다. 콘텐츠가 시간이 지남에 따라 작성되며, 각각의 엔트리가 타임-스탬프될 수 있다.
이하의 알고리즘은 서버 동기화 동안에 변경을 검출하는 데 사용될 수 있으며, 여기서 서버 동기화는 웹 서버(104)와 CPW(106) 간의 동기화를 포함하는 것으로 이해된다(비교로서, 클라이언트 동기화는 모바일 장치(102)와 같은 클라이언트와 웹 서버 간의 동기화를 포함하는 것으로 이해될 수 있다). 웹 서버(104) 프로그램은 각각의 계정에 대해 3개의 숫자(cla, w1, and w2)를 유지한다. cla는 변경 목록 앵커이고, w1은 변경 목록 창의 시작 시간(샘플)이며, w2는 변경 목록 창의 종료 시간(샘플)이다. 서버(104)는 창 [w1,w2] 내에 속하는 변경 목록의 부분을 저장한다. 서버 동기화(즉, 콘텐츠 공급자 웹 사이트로부터의 백 엔드 풀링) 동안 발견된 모든 변경은 현재의(즉, w2가 1만큼 증분되기 이전의) w2와 같은 동기화 앵커로 스탬프된다. 창 크기가 최대 창 크기 mw에 도달하거나 그를 초과하면 프로그램은 서버 동기화(콘텐츠 공급자 웹 사이트 동기화)를 일시 중단시킨다. 일시 중단되면, 서버는 새로운 클라이언트 폴(client poll)이 수신될 때 서버 동기화를 재개할 것이다. 다른 변수 ca는 클라이언트 앵커이고, OFF는 동기화 활동 없음을 나타내는 플래그이다. cla, w1, 및 w2의 값은 이하의 상태 천이 규칙에 따라 업데이트된다:
이벤트 상태 천이
초기화 cla = 0, w1 = 0, w2 = 0, off= 0
서버 동기화 w2 - w1 >= mw인 경우 w2 = w2+ 1, off= 1
클라이언트 동기화, w1 <= ca <= w2 w1 = ca, off= 0
클라이언트 동기화, cla < w1 및 (ca < w1 또는 ca > w2) cla = w2+ 1, w1 = cla, w2 = cla, off= 0(즉, "변경 목록 리셋")
클라이언트가 변경이 있는지 폴링할 때, 클라이언트 앵커 ca가 [w1, w2] 내에 속하는 경우, 부분 동기화가 동작할 것이며, 서버는 다시 [ca, w2] 내에 속하는 변경을 전송한다(그리고 ca보다 오래된 변경을 삭제한다). 동기화의 종료 시에, ca가 업데이트될 것이다. 클라이언트가 변경이 있는지 폴링할 때, 클라이언트 앵커가 [w1, w2]를 벗어나 있는 경우, 웹 서버(104)와 모바일 장치(102) 내의 클라이언트 프로그램 사이에서 새로운 전체 동기화가 행해질 것이다.
창 크기가 mw에 도달할 때 특정의 장치(102) 계정에 대해 서버 동기화[백 엔드 플러그인이 특정의 장치(102)에 대한 콘텐츠를 풀링하는 것]가 일시 중단될 수 있는 것이 생각되며, 이 경우에 클라이언트 폴링이 없다면 몇개의 누락된 푸시로 인해 장치에 대한 서비스 중단이 야기될 수 있다. 마지막 w2 이후에 보류 중인 변경이 있는 경우는 푸시를 전송하는 것이 유리할 수 있고, w1 이후에 보류 중인 변경이 있는 한 푸시가 전송될 수 있는 것이 생각된다.
또한, 2009년 5월 21일자로 출원된 발명의 명칭이 "A MOBILE COMPUTING DEVICE AND METHOD WITH ENHANCED POLLING MANAGEMENT(향상된 폴링 관리를 갖는 모바일 컴퓨팅 장치 및 방법)"인 미국 가특허 출원 제61/180,301호에 기술된 장치 폴링 관리자에서 본 명세서에 기술된 중개 웹 서버(104)가 유리하게도 이용될 수 있는 것이 생각된다.
콘텐츠를 업로드하는 것의 일례로서 사진(그림이라고도 함) 업로드에 대해 이제부터 기술할 것이다. 사진을 중개 서버(104) 메모리(302)에 캐싱함으로써 사진을 사용자 장치(102)로부터 다수의 소셜 네트워킹 시스템(106)으로 업로드하는 프로세스를 최적화하기 위해 중개 웹 서버(104)가 이용될 수 있다. 예시적인 흐름은 다음과 같을 수 있다:
1. 단계(1002)(도 10)에서, 중개 웹 서버 프런트 엔드(308)는 사용자 장치(102)가 사진을 업로드했다는 것을 백 엔드 부분(306)에 알려준다.
2. 단계(1004)에서, 웹 서버 프런트 엔드 또는 백 엔드는 새로운 사진에 사진 URL 및 시스템 전체에 걸쳐 고유한 사진 ID를 제공할 것이다.
3. 단계(1006)에서, 사진 ID가 장치(102)에 다운로드되고, 그에 응답하여 장치 클라이언트 프로그램은 사진 ID를 사진 이름과 연관시킨다.
4. 단계(1008)에서, 백 엔드는 파일을 HTTP를 통해 /tmp/uniquephotoid.tmp와 같은 위치에 다운로드한다.
5. 단계(1010)에서, 각각의 대상 콘텐츠 공급자 웹 사이트와 연관된 각자의 백 엔드 부분(306) 플러그인은 이 사진 파일을 업로드하기 위해 각각의 콘텐츠 공급자 웹 사이트(106)에 대한 work.uploadPhoto를 서브밋한다.
6. 단계(1012)에서, 백 엔드 부분은 사진 공유의 성공 또는 실패의 보고를 다시 프런트 엔드 부분에 제공한다.
7. 단계(1014)에서, 프런트 엔드는 선택적으로 성공 또는 실패를 사용자 장치(102)에 통지할 수 있다.
8. 단계(1016)에서, 소정의 기간이 경과한 후에, 사진이 삭제된다.
동작을 설명하면, 단계(1102)(도 11)에 나타낸 바와 같이, 사용자 장치(102)로부터의 사진은 사용자 장치(102)로부터 네트워크의 프런트 엔드 부분(308)에 업로드된다. 사진이 사용자 장치(102)에 의해 다시 업로드될 것을 필요로 하지 않고 단계(1206)(도 12)에서 프런트 엔드 부분(308) 또는 백 엔드 부분(306)은 동일한 사진이 상이한 시스템의 웹 사이트들로 서브밋될 수 있게 해주기 위해 사진을 중개 서버 메모리(104)에 소정의 기간 동안 캐싱한다. 소정의 기간 후에, 사진이 소거된다. 소정의 기간은 임의의 기간일 수 있고, 메모리 제약조건 및 사용 빈도수에 따라 선택된다. 기간은, 예를 들어, 24 시간일 수 있고, 이 기간은 사진이 메모리(302)에 업로드되는 때에 시작할 수 있고 그로써 사진이 업로드되면 기간이 설정되거나, 기간은 사진을 콘텐츠 공급자(106)에 업로드할 시에 시작할 수 있고 그로써 사진이 새로운 콘텐츠 공급자에 업로드될 때마다 기간이 연장될 것이다.
한 예시적인 실시예의 경우, 단계(1102)(도 11)에서, 사진이, 지정된 콘텐츠 공급자 웹 사이트(106)의 식별과 함께, 동작으로서 모바일 장치(102)로부터 중개 서버 프런트 엔드(308)에 업로드되고 네트워크 서버의 임시 저장 장치에 저장된다. 단계(1004)(도 10)에서, 프런트 엔드(308)는 사진을 백 엔드(306)에서의 플러그인에 전달하고, 플러그인은, 예를 들어, 모바일 장치에 의해 지정된 콘텐츠 공급자 웹 사이트에 전용되어 있을 수 있다. 단계(1006)에서, 네트워크 서버 프런트 엔드 부분(308)은 또한 저장된 사진과 연관된 사진 식별(ID)을 포함하는 메시지를 다시 사용자 장치(102)로 전송한다. 사진 ID는 웹 서버 메모리(302)에서 사진이 저장되어 있는 위치 또는 위치에 대한 포인터를 식별해준다. 모바일 장치는 단계(1104)에서 사진 ID를 수신하고 단계(1106)에 나타낸 바와 같이 사진 ID를 사진의 이름과 연관(매핑)시킨다. 그 후에, 단계(1108)에서, 모바일 장치(102)가 사용자 인터페이스를 통해 동일한 사진을 상이한 소셜 네트워킹 시스템으로 전송하기로 하는 경우, 모바일 장치는 실제 사진 대신에 사진 ID를 네트워크 서버로 전송할 것이다. 그에 응답하여, 단계(1204)(도 12)에 나타낸 바와 같이, 중개 서버(104)는 사진을 검색하고 이를 다른 콘텐츠 공급자 웹 사이트(106)에 전용되어 있는 다른 플러그인으로 전달할 것이다. 단계(1110)에서, 사진이 메모리(302)로부터 제거되면, 사용자 장치가 사진 이름과 사진 ID의 연관을 제거하도록 업데이트가 사용자 장치(102)로 전송될 것이며, 따라서 장치가 사진을 업로드할 것임이 생각된다. 한편, 사진이 더 이상 저장되어 있지 않고 서버가 사진 ID와 연관된 사진을 업로드하라는 요청을 수신하는 경우, 프런트 엔드 부분은 오류 메시지를 가입자 장치로 전송할 것이며, 그에 응답하여 가입자 장치는 다시 사진을 업로드하라고 요청받을 것이다.
다른 실시예의 경우, 웹 서버 백 엔드 부분(306)은 사용자 장치(102)로부터 업로드된 사진이 대상 소셜 네트워킹 시스템의 요구 제한(즉, 치수 및 크기) 내에 있는지를 판정할 것이다. 각각의 플러그인이 사진에 관한 콘텐츠 공급자 웹 사이트 제한을 저장하고 있을 수 있기 때문에, 사진이 메모리(302)로부터 제거될 때 이것이 각각의 콘텐츠 공급자 웹 사이트와 연관된 플러그인에 의해 처리될 수 있는 것이 생각된다. 제한이 충족되는 경우, 백 엔드(306)는 사진을 대상 콘텐츠 공급자 웹 사이트로 전송할 수 있다. 그렇지 않은 경우, 사진이 콘텐츠 공급자 웹 사이트의 요구사항에 따라 크기 조정될 것이다. 사진을 크기 조정하고 및/또는 사진을 대상 크기로 스케일링하기 위해, 크기 조정 인자가 결정된다. 크기 조정 인자 X를 결정하는 데 사용될 수 있는 특히 유리한 알고리즘은 다음과 같으며:
x/100 = ((t-f)/(kc))^(0.5)
여기서,
x는 크기 조정 퍼센트이고,
t는 대상 크기(단위: 바이트)이며, 예를 들어, 대략 1 메가바이트 이하일 수 있고, 유익하게는 200,000 바이트 미만일 수 있으며, 일 구현예에서, 100,000 바이트였고,
f는 파일 크기에 대한 작은 오차 범위(fudge factor)이며,
k는 상수 인자이고, 1 미만일 수 있으며, 유익하게는 0.5 미만일 수 있고, 일 구현예에서 0.23으로 선택되었으며,
c는 원본 파일의 크기(단위: 바이트)이다.
사진을 웹 서버(104)에 저장함으로써, 서버는, 모바일 장치가 미디어를 상이한 때에 상이한 소셜 네트워크 서버로 전송할 수 있게 해주면서 장치가 통신하는 데 이용하는 LAN(local area network) 또는 WAN(wide area network)을 통해 한번만 미디어를 업로드하는 것에 의해, 장치에서의 전력 소비 및 통신 네트워크에 대한 대역폭 부담을 감소시키는 데 도움을 준다. 그에 부가하여, 웹 서버는 각각의 콘텐츠 공급자 웹 사이트가 원하는 형식에 맞는 미디어를 채택할 수 있고, 장치는 미디어를 성공적으로 업로드하기 위해 이들 요구사항을 알고 있거나 수용할 필요가 없다.
또한, 단계(1302)(도 13)에서 사진이 중개 웹 서버(104)를 통해 장치(102)에 다운로드될 수 있는 것이 생각된다. 예를 들어, RSS 뉴스 피드의 경우, RSS 콘텐츠 소스로부터의 사진이 뉴스 피드 요약을 갖는 백 엔드 뉴스 피드에 의해 풀링된다. 단계(1304)에서 백 엔드(306)가 이러한 뉴스 정보가 새로운 것이라는 것, 또는 환언하면, 이전의 RSS 뉴스 피드가 백 엔드 부분에 의해 이 CPW로부터 풀링된 이후에 변경이 있었다는 것을 검출할 때, 서버(104)의 백 엔드 부분(306)은 단계(1306)에서 클라이언트 장치에 맞게 적절히 형식 설정된 피드를 프런트 엔드 부분으로 전송할 것이다. 프런트 엔드 부분(308)은 하위 우선순위 푸시 통지를 발생하여 클라이언트 장치(102)로 보낼 것이고, 장치(102)에 대한 큐에 요약 및 사진이 로드될 것이다. 클라이언트 장치가 그 후에 콘텐츠를 얻기 위해 폴링 요청을 프런트 엔드 부분으로 전송할 때, 단계(1308)에서 프런트 엔드는 형식 설정된 사진 및 요약을 포함하는 뉴스 피드를 비롯한 큐의 콘텐츠를 전송할 것이다. 모바일 장치(102) 상의 클라이언트 프로그램은 요약 및 연관된 사진을 모바일 장치(102) 디스플레이(216) 상에 디스플레이할 것이다. 일례로서, 입력(210)이 디스플레이 상의 터치 센서(통상 터치 스크린이라고 함)를 포함하는 경우, 사용자는 요약 및 사진에서 스크린을 터치할 수 있고, 사용자 인터페이스는 링크(110)를 통해 뉴스 피드 요약/사진과 연관된 콘텐츠 공급자 웹 사이트에 직접 연결되고 사용자가 보도록 디스플레이(216) 상의 뉴스 피드에 관한 부가 정보를 로드할 것이다. 백 엔드 부분(306)은 따라서 장치에 대한 새로운 사진 및 요약을 검출하고 형식 설정하고, 프런트 엔드 부분(308)은 콘텐츠가 이용가능하다는 것을 장치에 통지하고, 뉴스 피드를 모바일 장치(102)에 다운로드하기 위해, 장치로부터의 폴링 요청에 응답한다.
또한, 모바일 장치(102) 내의 클라이언트 프로그램이 사용자가 서버 계정을 가지고 있는 각각의 콘텐츠 공급자 웹 사이트에 대한 콘텐츠 유형 및 특성에 관한 어떤 정의를 저장할 것임이 생각된다. 단계(1502)에서 사용자가 서버 상에서 어느 계정을 설정하는지에 따라 장치의 사용자 인터페이스가 달라질 것이다. 예를 들어, 사용자가 그의 웹 서버(104) 계정으로 Facebook™ 및 Twitter™에 들어가는 것으로 가정한다. 사용자가 콘텐츠 공급자 웹 사이트에 업로드될 메시지(1402)(도 14)를 작성하기 위해 사용자 인터페이스와 상호작용할 때, 사용자 인터페이스 디스플레이는 메시지가 전송될 대상 콘텐츠 공급자 웹 사이트에 대한 "Facebook", "Twitter" 또는 "모두"의 선택 항목(도시 생략)을 제시한다. 어느 선택이 행해지느냐에 따라, 단계(1504)에서 메시지에 대한 파라미터가 달라질 수 있다(예컨대, 문자의 수). 사용자가 모두를 선택하면, 길이(1404)는 2개의 콘텐츠 공급자 웹 사이트 제한 중 작은 쪽이 될 것이다. 또한, 길이 카운트(1404) 및 경고(1406)가 제공될 수 있는 것이 생각된다. 단계(1506)에서 사용자가 텍스트를 입력할 때, 한계에 도달하기 전에 허용되는 나머지 문자가 문자 한계(1404)에 디스플레이된다. 30개 문자와 같은 어떤 임계값에서, 단계(1514)에서 경고(1406)가 디스플레이될 것이다. 한계가 초과될 때, 단계(1516)에서 나머지 문자는 마이너스 카운트로 되거나, 사용자가 부가의 문자를 입력하지 못하게 될 것이다. 사용자가 목적지 콘텐츠 공급자 소스를 변경하면, 한계가 적절히 변할 것이다. 예를 들어, 메시지가 생성된 후에 Twitter™ 웹 사이트가 목적지로서 추가되면, 한계가 감소될 것이다. Twitter™ 웹 사이트가 목적지로서 제거되면, 한계가 증가된다.
모바일 장치(102)는 사용자 장치가 중개 웹 서버 상에 구축하는 하나 이상의 콘텐츠 공급자 웹 사이트에 의존하는 동작 파라미터(1404)를 가지는 사용자 인터페이스 디스플레이(216)를 발생한다. 메시지의 경우, 사용자가 텍스트를 입력할 일반 메시지 엔트리 필드(1402)가 디스플레이(216) 상에 제시되고, 크기 상한은 메시지 텍스트의 목적지로 선택된 하나 이상의 소셜 네트워킹 웹 사이트에 의해 허용되는 가장 작은 최대 메시지 크기에 기초한다. 이 한계가 클라이언트 장치 상에 유지될 수 있다. 메시지 크기가 한계의 소정의 양 내에 있을 때 모바일 장치 클라이언트 프로그램은 경고(1406)를 발생할 수 있다. 단계(1508)에서 하나 이상의 소셜 네트워킹 사이트가 변하면 단계(1510)에서 한계가 변한다. 사용자 인터페이스 입력으로부터의 콘텐츠는 메시지 입력 영역(1402)을 채우고, 한계에 도달될 때 경고를 발생할 수 있다. 단계(1602)(도 16)에서, 클라이언트 프로그램은 하나 이상의 목적지 소셜 네트워킹 웹 사이트의 아이덴티티와 함께 서버 프런트 엔드에 의해 수신되는 메시지를 전송한다. 백 엔드 부분은 단계(1604)에서 하나 이상의 목적지 웹 사이트에 대한 메시지를 형식 설정하고 단계(1606)에서 소셜 네트워킹 웹 사이트가 원하는 형식으로 메시지를 업로드한다.
이상의 설명으로부터, 본 발명이 이상에서 논의된 것과 같은 수많은 상이한 동작 단계들을 이용하는 각종의 방법을 포괄하고 있다는 것이 명백할 것이다. 그에 부가하여, 본 발명이, 이상에서 논의된 특정의 실시예에 부가하여, 이상에서 논의한 것들에 부가하여 또는 그 대신에 다른 동작 단계들을 가지는 방법을 이용하는 실시예는 물론, 이상에서 논의된 단계들의 특정의 순서 또는 조합에 부가하여 또는 그 대신에 각종의 순서 및 조합으로 단계들을 갖는 방법을 이용하는 실시예를 비롯한 각종의 대안의 실시예도 역시 포괄하는 것으로 보아야 한다. 게다가, 이상에서 기술한 실시예들 중 하나 이상의 실시예에 따른 시스템이 사용자에 의해 조작되는 모바일 장치와 소셜 네트워킹 웹 사이트 간의 상호작용을 용이하게 해주는 것과 관련하여 몇가지 점에서 향상된 기능을 제공할 수 있다는 것이 명백할 것이다. 실시예에 따라, 사용자와 소셜 네트워킹 웹 사이트 사이의 통신의 품질, 모바일 장치 사용자가 경험하는 소셜 네트워킹 웹 사이트 및 관련 트랜잭션의 사용자 친숙성, 및/또는 모바일 장치와 이러한 웹 사이트 사이의 통신의 효율성 중 임의의 하나 이상이 향상될 수 있다.
도 17은 다른 예시적인 통신 시스템(1700)을 나타낸 것이다. 도 17의 통신 시스템(1700)은 중간 웹 서버(1704)(본 명세서에서, 웹 서버, 중개 웹 서버, 통합 서버 또는 통합 서비스라고도 함)를 포함한다. 웹 서버(1704)는 콘텐츠 공급자 프로세서(1716), 코어 서비스 프로세서(1718), 및 메모리(1714)를 포함할 수 있고, 이에 대해서는 이하에서 더 기술한다.
웹 서버(1704)는 하나 이상의 사용자 장치(1702, 1703)와 하나 이상의 콘텐츠 공급자 웹 사이트(1706 내지 1708)(콘텐츠 공급자, 소셜 네트워킹 웹 사이트, 뉴스 소스 또는 뉴스 피드라고도 할 수 있음) 사이에서 정보를 교환한다. 사용자 장치(1702, 1703)는 본 명세서에서 논의된 사용자 장치들 중 임의의 것일 수 있다. 중간 웹 서버(1704)는 콘텐츠 공급자 웹 사이트(1706 내지 1708)로부터 정보를 풀링하고 사용자 장치로부터의 폴(poll)에 응답하여 사용자 장치(1702, 1703)가 정보를 이용할 수 있게 해준다. 사용자 장치(1702, 1703)는 또한 콘텐츠를 중간 웹 서버(1704)를 통해 콘텐츠 공급자 웹 사이트로 푸시할 수 있다. 그에 부가하여, 사용자 장치(1702, 1703)는 인터넷(1705)(월드 와이드 웹 또는 간단히 웹이라고도 할 수 있음)을 거쳐 직접 연결(1720)을 통해 직접 콘텐츠 공급자 웹 사이트(CPW)(1706 내지 1708)에 액세스할 수 있다.
사용자 장치(1702, 1703), 중간 웹 서버(1704), 및 콘텐츠 공급자 웹 사이트(1706)는 인터넷(1705)[제1 인터넷 네트워크(1705') 및 제2 인터넷 네트워크(1705")로 예시되어 있음]을 통해 연결되어 있다. 중간 웹 서버(1704)는 각각의 장치(1702, 1703)의 설정에 따라 각각의 특정의 콘텐츠 공급자와 연관되어 있는 선택된 API(application program interface)에 따라 콘텐츠 공급자 웹 사이트가 인터넷 네트워크(1705")를 통해 액세스할 수 있게 해주는 콘텐츠에 액세스하고, 사용자 장치가 콘텐츠를 쉽게 처리되는 형식으로 이용할 수 있게 해준다. 중간 웹 서버(1704)는 또한 사용자 장치(1702, 1703)로부터 발신되어 인터넷(1705)을 통해 또는 셀룰러 네트워크와 같은 다른 통신 네트워크를 통해 전달되는 콘텐츠를 수신하고, 정보를 각자의 콘텐츠 공급자 웹 사이트에 대해 적절한 형식으로 적절한 콘텐츠 공급자(1706 내지 1708)에 제공한다.
도 18은 또 다른 예시적인 통신 시스템(1800)을 나타낸 것이며, 여기서 사용자 장치(1802)는 인터넷 네트워크(1805)를 통해 중간 웹 서버(1804)에 연결되어 있다. 도 18에서 모바일 장치로서 예시되어 있는 사용자 장치(1802)는 또한 P2P 통신 사업자 연결(1822)을 통해 중간 웹 서버(1804)에 연결되어 있을 수 있다. 중간 웹 서버(1804)는 인터넷(1805)을 통해 콘텐츠 공급자 웹 사이트(1806 내지 1808)에 연결되고 P2P 연결(1821)을 통해 통신 사업자 네트워크(1820)에 연결되어 있다. 통신 사업자 네트워크(1820)는 백 엔드 플러그인에의 연결을 가질 수 있는 주소록을 포함할 수 있다.
중간 웹 서버(1804)는, 콘텐츠 공급자 웹 사이트(1806 내지 1808)로부터 정보를 풀링하고 새로운 콘텐츠를 식별하기 위해 정보를 처리하며 새로운 정보가 식별되는 경우 코어 서비스 프로세서(1818)로 전송되는 통지를 발생하는 콘텐츠 공급자 프로세서(1816)를 포함한다. 정보는 웹 서버(1804) 내의 메모리(1814)에 로컬적으로 저장될 수 있다. 코어 서비스 프로세서(1818)는 새로운 정보가 이용가능하다는 것을 사용자 장치(1802, 1803)에 통지하고 사용자 장치와 동기화하기 위해 사용자 장치 정보를 저장한다. 코어 서비스(1818)는 사용자 장치(1802, 1803)로부터의 폴에 응답하여 콘텐츠를 각자의 사용자 장치에 제공한다.
사용자 장치(1802 또는 1803)에 의해 전송되는 정보는 또한 웹 서버(1804)를 통해 콘텐츠 공급자 웹 사이트(1806 내지 1808)에 포스팅될 수 있다. 사용자 장치(1802 또는 1803)로부터 제공된 콘텐츠는 코어 서비스 프로세서(1818)에 의해 수신되고, 콘텐츠 공급자 프로세서(1816)에 의해 콘텐츠 공급자 웹 사이트(1806 내지 1808) 중 하나 또는 모두와 호환되도록 형식 설정되며, 적절한 콘텐츠 공급자(1806 내지 1808)로 전송된다.
콘텐츠 공급자 웹 사이트(1806 내지 1808)의 일례는 Facebook™, Twitter™, 및 Myspace™와 같은 소셜 네트워크 웹 사이트(SNW)를 포함한다. 다른 콘텐츠 공급자 웹 사이트는 Photobucket™과 같은 사진 사이트, 또는 RSS(Really Simple Syndication) 피드를 제공하는 임의의 소스 또는 임의의 다른 뉴스 콘텐츠 소스를 포함하는 뉴스 소스일 수 있다. 상기 일례가 전수적인 것으로 간주되지 않고 오히려 사용자 장치에 콘텐츠를 제공할 수 있는 유형의 소스들의 일례로 간주된다. 소스는 모바일 장치에 대한 특정의 콘텐츠 또는 개인용 컴퓨터에 대한 콘텐츠를 포함할 수 있다.
중간 웹 서버의 콘텐츠 공급자 프로세서(1816)[백엔드, 백 엔드 부분, 또는 소셜 네트워크 프로세서(SNP)라고도 할 수 있음]는 각각의 콘텐츠 공급자에 대한 각자의 플러그인(1824)을 포함한다. 각각의 플러그인(1824)은 그 각자의 콘텐츠 공급자로부터 콘텐츠를 풀링하고 적절한 형식 설정을 사용하여 정보를 장치로부터 각자의 콘텐츠 공급자에 업로드하는 각자의 프로세서 및/또는 정의를 저장하는 프로그램(또는 API)을 가질 수 있다.
코어 서비스 프로세서(1818)는 프런트 엔드라고도 한다. 코어 서비스 프로세서(1818)는 웹 지원 포털 응용 프로그램 서버(1826), 코어 웹 서비스 응용 프로그램 서버(1828), 및 푸시 서버(1830)를 포함한다. 코어 서비스 프로세서(1818) 및 콘텐츠 공급자 프로세서(1816)는 임시 저장소 또는 캐시로서 역할하는 메모리(1814) - 예를 들어, 여러 데이터베이스로 분할되어 있는 대용량 메모리 시스템을 사용하여 구현될 수 있음 - 에 연결되어 있다.
도 18에 예시된 바와 같이, 모바일 장치(1802)는 유선 이더넷 또는 무선 802.xx 연결과 같은 LAN(local area network)을 통해 또는 셀룰러 네트워크를 통해 기지국(1832)에 연결될 수 있다. 통신 사업자는 기지국(1832)과 부하 분산 장치 및 방화벽 SSL(1834) 사이의 P2P 연결(1822)을 통해 중간 웹 서버에 연결될 수 있다. 통신 사업자 기지국(1832)은 또한 인터넷(1805)을 통해 중간 웹 서버(1804)에 연결될 수 있다. P2P 연결(1821)이 또한 플러그인(1824)과 통신 사업자 네트워크(1820) 사이에 존재할 수 있다.
푸시 서버(1830)는, 예를 들어, TCP 연결에 의해 사용자 장치(1802)에 연결될 수 있다. 코어 웹 서비스 서버(1828)와 웹 지원 포털(1826)은 HTTP 연결을 통해 연결될 수 있다. 플러그인(1824)은 또한 HTTP 연결을 통해 콘텐츠 공급자 웹 사이트(1806 내지 1808)와 통신할 수 있다.
앞서 논의된 바와 같이, 각자의 플러그인(1824)은 Facebook™, Twitter™, MySpace™와 같은 소셜 네트워킹 사이트, 및 RSS, ATOM, Podcasts 등과 같은 콘텐츠 피드 등을 지원한다. 그에 부가하여, Yahoo™ 메일, Google™ 메일, 및 Microsoft™ 메일과 같은 메시징 포털에 플러그인(1824)이 제공될 수 있다. 그렇지만, 이메일 서비스는 여전히 모바일 장치(1802, 1803)에 의해 직접 액세스될 수 있고, 메일 서비스로부터의 연락처 목록이 프런트 엔드 서비스를 통해 백업될 수 있다. 데이터 통합(콘텐츠 공급자로부터 장치로의 정보) 및 통지 API(장치로부터 콘텐츠 공급자로)는 상태, 통지(새로운 메일, 피드 변경), 친구 피드, 및 친구/연락처와 같은 각종의 활동을 지원할 수 있다. 웹 서버(1804)는 또한 푸시 채널(통지를 장치에 제공함), 공중 소프트웨어 프로비전, 장치에 대한 중간 웹 서버의 설정 및 구성(예컨대, 사용자의 계정, 선호 사항 등), 및 웹 서비스를 지원한다. 중간 웹 서버(1804)는 사용자 장치 보안, 위젯-기반 웹 액세스, 장치 백업 및 복구, 및 통신 사업자 지원 도구를 특징으로 한다.
중간 웹 서버(1804)는 계정 관리, 푸시 및 데이터 서비스를 장치(1802 또는 1803)에 제공할 수 있다. 계정 관리 서비스는 설정 및 장치 구성, 서비스 식별을 지원하는 것, 사용자에 대한 서버 설정, 및 기타 계정/사용자 구성을 제공할 수 있다. 푸시 서비스는 새로운 컨텐츠 또는 이용가능한 데이터를 가지고 있다는 것을 장치에 통지하는 서비스를 제공할 수 있고, 따라서, 사용자 장치가 직접 콘텐츠 공급자를 폴링할 필요 없이, 상태, 뉴스 및 친구 업데이트와 같은 동적 데이터를 사용자에게 적시에 제시하는 것을 가능하게 해준다. 데이터 서비스는 장치에 대한 다양한 유형의 데이터의 업로드, 검색 및 동기화 서비스를 포함할 수 있다. 예를 들어, 피드는 콘텐츠 공급자 웹 사이트로부터 검색된 정보를 장치에 제공하고, 업로드는 콘텐츠를 장치로부터 콘텐츠 공급자 웹 사이트에 업로드하며, 동기화는 장치(1802 또는 1803)와 서버 상의 캐시 간의 동기화를 가능하게 해준다.
중간 웹 서버(1804)에 연결되어 있는 장치(1802 또는 1803)는 처음에 초기 장치 구성(통합 서비스와 연관시킬 이메일 계정을 입력하는 것, 장치에 의해 액세스될 콘텐츠 공급자 웹 사이트를 설정하는 것, 비밀번호 및 사용자 식별을 입력하는 것, 및 언어와 같은 선호 사항을 설정하는 것 등)을 수행하기 위해 장치 구성 서비스에 연결할 수 있다. 장치 구성이 완료되면, 클라이언트 장치 및 푸시 서비스에 대해 영구적 TCP/IP 연결이 설정된다. 중간 웹 서비스(1804)가 특정의 장치에 대한 데이터에 영향을 주는 변경이 일어났다는 것을 검출할 때, 신호가 푸시 서비스를 통해 장치로 전송된다. 이 시점에서, 관련 데이터 서비스에 직접 연결하여 임의의 새로운 또는 수정된 데이터를 검색할지 여부를 결정하는 것은 장치의 몫이다. 예를 들어, 장치는 정보를 얻기 위해 서버를 폴링할 수 있고, 정보를 사용자 인터페이스(예컨대, 디스플레이)를 통해 사용자에게 제시할 수 있다. 사용자는 정보를 볼 수 있고, 부가 정보를 획득하기 위해 소스에 직접 액세스할지를 결정할 수 있다.
플러그인(1824)에 의해 콘텐츠 공급자 웹 사이트(1806 내지 1808)로부터 풀링된 정보는 중간 웹 서버(1804)에서 처리되고 변경을 식별하기 위해 이전 정보와 비교된다.
콘텐츠 공급자(1806 내지 1808)로부터 이용가능한 정보는 아주 다양한 유형일 수 있다. 변경이 있는지 통합 서비스(1804)에 의해 지원되는 이들 콘텐츠 유형이 모니터링된다. 이벤트가 검출될 때, 사용자 장치에 제공될 변경 목록에 항목이 추가된다. 변경 목록은 초기화부터 또는 마지막 변경 목록 앵커부터 발생한 모든 이벤트를 포함한다. 이벤트는 상태 또는 코멘트, 뉴스 피드, 소셜 네트워크 연락처의 업데이트(이들로 제한되지 않음)를 비롯한 포스팅을 포함한다.
보다 상세하게는, 각각의 콘텐츠 공급자(1806 내지 1808)에 대해, 통합 서비스가 지원하는 콘텐츠 유형들의 부분집합에 대한 일련의 정의가 제공된다. 콘텐츠 공급자와 연관된 플러그인(1824)은 지원되는 콘텐츠를 콘텐츠 공급자 웹 사이트(1806 내지 1808)로부터 풀링할 것이다. 콘텐츠는 이어서 변경이 있는지 검토될 수 있다. 변경이 발생할 때, 변경이 변경 목록의 일부로서 프런트 엔드(1818)로 전달된다.
동작을 설명하면, 서버(1804) 및 장치(1802) 각각은 변경 앵커를 저장한다. 서버(1804)는 콘텐츠 공급자 웹 사이트(1806 내지 1808)와 동기를 유지하기 위해 콘텐츠를 콘텐츠 공급자 웹 사이트(1806 내지 1808)로부터 계속적으로 풀링할 것이다. 백 엔드 부분(1816)은, 콘텐츠를 풀링할 때마다, 변경이 있는지 검사한다. 변경이 검출되면, 변경이, 예를 들어, 메모리(1814)에 저장될 수 있는 변경 목록에 추가된다. 장치(1802)는 변경에 관한 최신 정보를 유지하기 위해 서버(1804)와 동기화하고, 서버(1804) 및 장치(1802)는 앵커를 사용하여 얼마나 많은 정보를 교환해야 하는지를 결정한다.
이하의 용어는 웹 서버(1804) 변경 동기화의 백 엔드 부분과 연관되어 있다:
Figure pat00001
서버 동기화 - 서버가 데이터의 마스터 사본으로부터 동기화하는 것(예컨대, Facebook™, Twitter™ 등과 같은 콘텐츠 공급자 웹 사이트로부터의 백 엔드 동기화)
Figure pat00002
클라이언트 동기화 - 모바일 장치(102) 내의 클라이언트 프로그램이 프런트 엔드(코어 서비스 서버)와 동기화하는 것
Figure pat00003
CLA - 변경 목록 앵커(change list anchor) - 서버에 기록되어 있는(통합 서비스 서버 프로그램에 기록되어 있는) 마지막 전체 또는 부분 동기화가 발생한 샘플(시간 또는 변경)
Figure pat00004
변경 목록 버전 - 변경 목록이 동기화 추적을 돕기 위해 버전 번호를 부여받을 수 있다.
Figure pat00005
W1 - 저장된 변경 목록 창의 하부 샘플(시작)
Figure pat00006
W2 - 저장된 변경 목록 창의 상부 샘플(끝)
Figure pat00007
MW - 최대 창 크기(시간 범위, 변경의 수, 또는 시간 범위와 변경의 수의 조합으로서 지정될 수 있음)
Figure pat00008
OFF - 동기화가 일시 중단되었는지를 나타내는 플래그
Figure pat00009
CA - 클라이언트 앵커(client anchor) - 장치에 기록되어 있는(통합 서비스 클라이언트 프로그램에 기록되어 있는) 마지막 전체 또는 부분 동기화가 발생한 샘플(시간 또는 변경)
이하의 동기화 전송 큐 알고리즘은 서버 동기화 동안 변경을 검출할 때 사용될 수 있고, 새로운 정보가 장치에 제공되어 장치가 업데이트되도록 보장해준다. 웹 서버(1804) 프로그램은 각각의 계정에 대해 3개의 숫자(CLA, W1, 및 W2)를 유지한다. 서버(1804) 프로그램은 창 [W1,W2] 내에 속하는 변경 목록의 부분을 저장한다. 서버 동기화 동안 발견된 모든 변경은 현재의(즉, W2가 1만큼 증분되기 이전의) W2와 같은 동기화 앵커로 스탬프된다. 창 크기가 최대 창 크기 mw에 도달하거나 그를 초과하면 프로그램은 서버 동기화(콘텐츠 공급자 웹 사이트 동기화)를 일시 중단시킨다. 일시 중단되면, 서버(1804)는 새로운 클라이언트 폴이 수신될 때 서버 동기화를 재개할 것이다. CLA, W1, 및 W2의 값은 이하의 상태 천이 규칙에 따라 업데이트된다:
이벤트 상태 천이
초기화 CLA = 0, W1 = 0, W2 = 0, OFF = 0
서버 동기화 W2 - W1 >= MW인 경우 W2 = W2+1, off= 1
클라이언트 동기화, W1 <= CA <= W2 W1 = CA, OFF = 0
클라이언트 동기화, CLA < W1 및 (CA < W1 또는 CA > W2) CLA = W2+ 1, W1 = CLA, W2 = CLA, OFF = 0 (즉, "변경 목록 리셋")
클라이언트(1802 또는 1803)가 변경이 있는지 폴링할 때, 클라이언트 앵커 CA가 [W1, W2] 내에 속하는 경우, 부분 동기화가 동작할 것이며, 서버는 다시 [Ca, W2] 내에 속하는 변경을 전송한다(그리고 CA보다 오래된 변경을 삭제한다). 그렇지 않은 경우, 서버 및 클라이언트가 전체 동기화를 시작한다. 클라이언트 앵커 CA가 W1보다 작거나 W2보다 큰 경우에만(즉, CA가 창을 벗어나 있는 경우에만) 클라이언트는 전체 동기화를 필요로 한다. 이 경우에, 클라이언트 앵커 CA는 "유효하지 않다". 변경 목록 앵커 CLA가 W1보다 작은 경우에만(즉, 서버가 현재 변경 목록의 전체 이력을 가지고 있지 않은 경우에만) 서버(1804)는 그의 변경 목록을 리셋한다. 서버(1804)는 창 [0, W2]을 클라이언트로 전송하며, 여기서 "0"은 클라이언트에게 전체 동기화를 수행해야만 한다는 것을 알려준다.
계정이 하나의 장치와 연관되어 있지만, 사용자는 2개 이상의 장치가 통합 서비스 내의 동일한 사용자 계정과 동기화하기를 원할 수 있다. 변경 목록 리셋이 없는 경우, 다수의 장치는 물론 하나의 장치도 동작한다. 변경 목록 리셋의 경우에, 다수의 장치 사이에 경쟁 상태가 발생할 수 있으며, 이는 변경 목록이 서버 상에서 항상 리셋되는 것을 야기할 것이다. 예를 들어, 장치 1은 변경이 있는지 폴링하고, 유효하지 않은 CA를 전송한다. 서버(1804)는 현재 변경 목록의 전체 이력을 가지고 있지 않으며, 따라서 그의 변경 목록을 리셋한다. 장치 1은 다시 변경이 있는지 폴링하고, 이는 W1을 상승시킨다. 이어서, 장치 2가 변경이 있는지 폴링하고, 그의 CA가 장치 1의 폴링으로 인한 변경 목록 리셋으로 인해 확실히 유효하지 않은 것으로 된다. 서버(1804)는 이어서 어쩔 수 없이 그의 변경 목록을 다시 리셋한다. 장치 2는 이어서 다시 변경이 있는지 폴링할 수 있고, 이는 W1을 상승시킨다. 장치 1은 이어서 변경이 있는지 폴링하고, 그의 CA가 변경 목록 리셋으로 인해 확실히 유효하지 않은 것으로 되며, 서버(1804)는 어쩔 수 없이 그의 변경 목록을 다시 리셋한다.
이 경쟁 상태를 피하기 위해, 서버(1804)는 각각의 장치에 대해 하나의 ACA(acknowledged client anchor)를 유지할 수 있고, 가장 작은 ACA가 현재 W1보다 클 때에만 W1을 상승시킨다. 다른 대안으로서, 서버는 W1에 대한 버퍼 영역을 생성할 수 있다(즉, 서버는 W1을 CA까지 계속하여 상승시키지 않고 CA 또는 W2-MW/2 중 최소값까지 상승시킬 것이다).
콘텐츠 공급자(예컨대, Facebook™)와 동기화하는 것과 관련하여, 콘텐츠 공급자 프로세서(1816)(즉, SNP 프로세서 또는 백 엔드 부분)가 데이터의 마스터 사본을 가지고 있지 않고(즉, Facebook™ 또는 다른 콘텐츠 공급자 웹 사이트(1806 내지 1808) 중 하나로부터의 데이터가 전체적으로 복사되지 않고) 서버(1804)가 변경의 전체 이력을 로컬적으로 저장하고 있지 않다는 사실로 인해, 서버(1804)는 때때로(예컨대, 장치가 아주 오래되어 쓸모없게 될 때) 변경 목록을 리셋(즉, 처음부터 재구성)할 필요가 있을 것이다. 결과적으로, 동일한 타임스탬프/동기화 앵커가 상이한 때에 작성된 변경 목록과 관련하여 상이한 것을 의미할 수 있다.
도 22에 예시된 이하의 이벤트 시퀀스(2200)를 고려해보자. 도 22에서, aX는 "항목 X를 추가"를 의미하고, mX는 "항목 X를 수정"을 의미하며, dX는 "항목 X를 삭제"를 의미한다.
도 22에서 알 수 있는 바와 같이, 서버는 메모리(1814)에 로컬적으로 저장되어 있는 (m2, a2)만을 갖는 변경 목록 CL1으로 시작하고(2210), 클라이언트는 (a1, a2)를 가진다. 클라이언트는 동기화 앵커 t - 이 동기화 앵커는 오래되어 쓸모없는 것이고 따라서 서버는 CL1을 삭제함 - 를 전송하고(2212), 메모리(114)에 로컬적으로 저장되어 있는 (a2, a3)를 사용하여 변경 목록 CL2를 재작성한다(2220). 클라이언트는 이어서 그의 동기화 앵커 t로 되돌아오고(2222) 서버는 (a3)를 다시 전송한다. 클라이언트는 이제 (a1, a2, a3)를 가지고 있고 (d1)를 누락하였다. 그 결과 서버는 (a2, a3)를 다시 전송하고 장치에 전체 동기화를 수행하라고 통지한다. 이 전송이 실패하면, 클라이언트가 또다시 t로 되돌아올 때, 서버는 강제로 전체 동기화를 수행하거나 단지 (a3)를 다시 전송할 수 있다.
이 문제점을 피하기 위해, 단지 개개의 변경이 아니라 버전 번호가 변경 목록에 저장될 수 있다. 즉, 변경 목록이 서버 상에서 리셋될 때마다, 변경 목록의 버전이 1만큼 증분된다. 그러면 이전 버전 번호가 클라이언트로부터 수신될 때, 서버는 클라이언트 장치가 전체 동기화를 필요로 한다는 것을 명확하게 알 것이다. 다른 실시예에서, 웹 서버(1804)는 각각의 장치에 대한 클라이언트 앵커를 저장하고 저장된 클라이언트 앵커가 장치로부터 수신된 동기화 앵커(예컨대, 상기 일례에서의 t)와 동기를 벗어나 있을 때 전체 동기화를 강제로 수행할 수 있다. 임의의 주어진 변경 목록 CL 및 임의의 주어진 변경 C에 대해, C가 CL의 버전보다 낮은 버전을 갖는 변경 목록으로부터 온 경우에만 앵커(C) < 버전(CL)이 있고, 그러면 서버는 서버와 클라이언트 사이에서 부가의 버전 번호를 전달할 필요가 없다 - 서버는 현재 변경 목록의 버전을 서버 상에 저장하고 들어오는 클라이언트 동기화 앵커를 이 버전 번호와 비교하여 클라이언트가 오래된 버전인지(따라서 전체 동기화를 필요로 하는지)를 판정하기만 하면 된다 -. 서버는 동일한 번호 시퀀스로부터 동기화 앵커 및 변경 목록 버전을 선택함으로써 이것을 달성할 수 있다.
이 방식의 한가지 결과는 서버가 외부 타임스탬프(예컨대, Facebook™ 메시지와 함께 오는 타임스탬프)를 동기화 앵커로서 더 이상 사용할 수 없고 그 자신의 동기화 앵커를 할당한다는 것이다.
중개 웹 서버(1804)는 백 엔드에 의해 콘텐츠 공급자 웹 사이트(1806 내지 1808)로부터 풀링했던 콘텐츠를 어느 언어로라도 모바일 장치(1802, 1803)에 제공할 수 있다. 예를 들어, 고객의 Facebook™ 선호사항이 불어인 경우, Facebook™은 콘텐츠를 불어로 전송할 것이고, 콘텐츠는 불어로 중개 웹 서버(1804)의 통합 서비스를 통과할 것이다. 이것은 사용자 장치와 소셜 네트워크 제공자 간의 직접적인 관계와 부합하고, 여기서 계정 보유자는 그의 장치에서 언어 선호 사항을 변경할 수 없고 오히려 소셜 네트워크 제공자 웹 사이트에서 언어를 선택한다.
웹 서버(1804)(즉, 통합 서비스)에 의해 지원되는 "콘텐츠 유형"의 변경이 백 엔드(1816)에 의해 검출될 때, 백 엔드(1816)는 통지를 사용자 장치(1802 또는 1803)로 전송하라고 프런트 엔드 부분(1818)에 통지할 것이다.
웹 서버(1804)는 또한 뉴스 피드의 싱크일 수 있다. 뉴스 소스가 모바일 장치 서비스 공급자(예컨대, 셀룰러 통신 사업자) 또는 사용자 장치에 의해 선택될 수 있다. 중개 웹 서버(1804)는 사용자 장치가 이용되고 있는 각각의 시장 및 언어에 대한 로컬 콘텐츠를 제공할 수 있다. 일 실시예에서, 중개 웹 서버(1804)는 콘텐츠의 언어를 번역하지 않을 수 있고, 단순히 백 엔드 부분(1816)이 뉴스 서비스 콘텐츠 공급자로부터 풀링한 것을 통과시킬 수 있다.
웹 서버(1804)는 또한 관리 피드(admin feed)의 싱크일 수 있다. 관리 피드 메시지가 시스템 관리자에 의해 생성될 수 있고, 로컬화되며, 장치에 대한 올바른 언어로 사용자 장치로 전송된다.
웹 서버(1804)는 또한 친구 목록과 같은 연락처의 싱크일 수 있다. 연락처가 종종 업데이트되지 않는 경우, 통합 서비스의 프런트 엔드(1818)는 이들을 드물게(예를 들어, 하루에 한번 또는 두번 이하) 동기화할 수 있다. 비동기적 변경 통지를 지원하는 공급자는 이 프로세스에 대한 예외이고 이러한 변경은 즉각 동기화된다.
중개 웹 서버(1804) 백 엔드(1816)는, 소셜 네트워크 웹 사이트에서 연락처가 업데이트되었다는 것을 검출할 때, 하위 우선순위 신호를 푸시 채널을 통해 장치(1802 또는 1803)에 저장되어 있는 통합 서비스 클라이언트 프로그램으로 전송한다. 이 신호를 수신하면, 통합 서비스 클라이언트는 서버(1804)의 프런트 엔드에서 통합 서비스의 동기화 웹 서비스를 호출함으로써 양방향 동기화 동작을 시작할 것이다.
통합 서비스 클라이언트는 또한 사용자가 동기화를 수동으로 시작할 수 있게 해줄 수 있다. 예를 들어, 장치(1802)는 사용자가 웹 서비스 프런트 엔드와의 동기화를 요청할 수 있는 메뉴를 포함할 수 있다. 통합 서비스 클라이언트 프로그램에서의 연락처에 대한 변경이 "서서히" 웹 서버와 동기화될 수 있다. 클라이언트 프로그램은 구성가능한 기간에 대한 변경들을 서버 프런트 엔드(1818)로 전송하기 전에 이들을 일괄 처리(batch up)할 것이다.
앞서 논의된 바와 같이, 친구 피드는 소셜 네트워킹 웹 사이트 제공자의 네트워크에서의 연락처/친구에 관한 정보이다. 통합 서비스는, 새로운 피드 요소를 검출할 때, 하위 우선순위 신호를 푸시 채널을 통해 사용자 장치에 있는 통합 서비스 클라이언트 프로그램으로 전송한다. 이 신호를 수신하면, 클라이언트는 적절한 웹 서비스 폴링 교환을 사용하여 통합 서비스로부터 피드를 페치할 것이다. 피드는 몇개의 콘텐츠 공급자(1806 내지 1808)로부터의 요소를 포함할 수 있다.
대부분의 콘텐츠 공급자에 대한 상태는 전형적으로 사용자에 의해 수동으로 설정되지만, 통합 서비스 클라이언트 프로그램은 인스턴트 메시징(IM) 스타일 현재 상태(style presence)도 역시 지원할 수 있다. 가입자에 대한 상태(자기 상태) 및 연관된 친구 모두에 대한 상태(친구 상태)가 모니터링된다. 자기 상태는 또한 공급자에서 적절한 웹 서비스를 사용하여 통합 서비스 클라이언트 프로그램에 의해 설정될 수 있다. 통합 서비스 웹 서버 백 엔드는, 상태(자기 상태 또는 친구 상태)의 변경을 검출할 때, 푸시 채널을 통해 상위 우선순위 신호를 통합 서비스 클라이언트 프로그램으로 전송한다. 이 푸시 신호는 유익하게도 그의 페이로드에 상태 값을 포함할 수 있다.
상태를 지원하는 소셜 네트워킹 공급자는 공급자 설정에 엔트리를 가질 것이다. 각각의 공급자는 공급자와 공급자 ID 간의 매핑, 상태 텍스트의 최대 길이, 기분(mood)이 지원되는 경우, 기분의 목록, 및/또는 이용가능한 반응의 목록을 정의하는 상태 설정을 포함할 것이다. 일 실시예에서, 사용자 또는 공급자는 상태를 소거하기 위해 널 또는 빈 문자열을 입력할 수 있다.
사용자가 기분을 설정하는 경우, 사용자는 기분의 식별, 기분의 설명을 제공할 수 있거나, 기분을 나타내는 소정의 사진을 선택할 수 있거나, 사용자 선택 사진의 URL을 제공할 수 있다.
웹 서버(1804) 백 엔드(1816) 플러그인(1824)은 소셜 네트워킹 사이트로부터 직접 상태 및 기분 업데이트를 획득하고 임의의 변경을 코어 웹 서비스(1828)에 통지할 수 있다. 상태 및 기분 업데이트는 다음과 같은 정보 - 유형(STATUS, MOOD, STATUS_AND_MOOD), 동작(상태 지우기 또는 상태 업데이트), 콘텐츠 공급자[예컨대, 콘텐츠 공급자(1806 내지 1808) 중 하나], 통합 서비스 계정 ID, 외부 ID, 업데이트가 친구에 대한 것인 경우 친구 ID, 상태 텍스트 및/또는 포스팅 날짜 - 를 포함할 수 있다. 업데이트가 MOOD 또는 STATUS_AND_MOOD 업데이트인 경우, 업데이트는 앞서 논의한 바와 같이 ID, 설명, 사진 이름 및/또는 사진 URL을 포함할 수 있다. 사용자 지정 기분(custom mood)을 지원하기 위해 ID, 설명, 사진 이름 및 사진 URL이 포함되어 있다. ID는 종종 숫자이고, 설명, 사진 이름 및 사진 URL은 텍스트이다.
어떤 소셜 네트워킹 공급자는 사용자가 상태에 따라 행동할 수 있게 해준다. 예를 들어, Facebook™은 사용자가 상태에 관해 코멘트할 수 있게 해준다. Twitter™는 사용자가 좋아하는 상태를 표시하는 것은 물론 상태에 반응할 수 있게 해준다. 상태 반응은 이 기능을 제공하고 친구 행동과 아주 유사하며 친구 피드 및 친구 피드 반응과 아주 유사하다.
예를 들어, 통합 서버(1804)를 사용하는 것의 한가지 이점은 변경들 또는 업데이트들 중 임의의 것을 서버에 영구적으로 저장할 필요성이 유익하게도 변경 목록의 주기적인 자발적 재설정을 수행함으로써 제거된다는 것이다. 그 결과, 클라이언트 장치는 통합 서버(1804)와 더 많은 전체 동기화를 수행할 필요가 있을 것이다.
창 크기가 MW에 도달할 때 서버 동기화가 일시 중단되기 때문에, 몇개의 누락된 푸시로 인해 클라이언트 폴링이 없다면 장치에 대한 서비스 중단이 일어날 수 있다. 이러한 일이 덜 일어나도록 하기 위해 특정의 대책이 채택될 수 있다. 예를 들어, 마지막 W2 이후로 보류 중인 변경이 있는 경우에만 푸시를 전송하는 것 대신에, W1 이후로(즉, 다수의 장치인 경우에 각각의 장치의 ACA 이후로) 보류 중인 변경이 있는 한, 푸시가 전송될 수 있다. 이 방식의 결과 중복된 푸시가 전송되고 따라서 클라이언트에 의한 중복된 폴링이 있게 되지만, 후자의 단점은 W1(또는 다수의 장치인 경우에 각각의 장치의 ACA)이 푸시 메시지에 포함되면 최소화될 수 있다.
코어 웹 서비스 응용 프로그램 서버(1828)는 주 기능이 백 엔드(1816)[소셜 네트워킹 프로세서(SNP)]로부터 데이터를 수신하고 이를 패키징하여 클라이언트 장치로 전달하는 것인 코어 서비스 응용 프로그램을 포함한다. 이들 응용 프로그램은 친구 피드, 소셜 네트워킹 친구, 메시징/메일 및 뉴스를 포함한다. 이들은 공통으로 다음과 같은 몇가지 특성 - 데이터 흐름이 서버로부터 클라이언트로의 단방향일 수 있음, 어떤 클라이언트 변경도 코어 웹 서비스 응용 프로그램 서버(1828)로 다시 커밋되지 않을 수 있음, 및 데이터가 코어 웹 서비스 응용 프로그램 서버(1828)에 영속적으로 유지되지 않음 - 을 가질 수 있다.
프런트 엔드(1818)는 데이터를 동기화 채널을 통해 클라이언트 장치(1802 또는 1803)로 전송하는 임시 메커니즘인 동기화 전송 큐를 제공할 수 있다. 코어 웹 서비스 응용 프로그램 서버(1828) 내의 응용 프로그램은 그의 동기화 응용 프로그램 ID를 전송 큐에 등록할 수 있고, 전송 큐는 차례로 프런트 엔드(1818)에 의해 제어되는 동기화 엔진에 응용 프로그램에 대한 프록시로서 등록한다. 전송 큐는 하나 이상의 엔트리를 큐에 인큐잉(enqueueing)하는 것을 가능하게 해준다. 각각의 엔트리는 큐에 불투명한 다수의 필드 - 데이터 블로브(blob of data), 공급자의 이름, 항목이 추가, 수정 또는 삭제를 구성하는지, 및 엔트리에 대한 고유 ID를 포함함 - 를 지정할 수 있다. 동기화 전송 큐는 이들 필드 중 임의의 것에 할당된 값에 상관하지 않고, 데이터가 큐잉되었던 순서로 데이터를 시퀀싱할 뿐이다. 응용 프로그램은 인큐잉 동안 어떤 잠금도 획득하지 않는다. 큐는 응용 프로그램이 데이터를 큐에 연속적으로 추가할 수 있게 해준다.
프런트 엔드(1818)는 또한 각각의 응용 프로그램에 대한 동기화 앵커를 통해 클라이언트 상태의 추적을 제공할 수 있다. 이 동기화 앵커는 응용 프로그램에 노출되지 않을 수 있다. 프런트 엔드(1818)는 또한 클라이언트가 데이터를 수신했다는 것을 확인했을 때 데이터를 큐로부터 제거하는 것을 제공할 수 있다. 이 확인은 클라이언트가 그 다음 업데이트 요청을 받을 때 쉽게 판정될 수 있고, 프런트 엔드(1818)는 클라이언트 장치가 이전의 동기화 앵커에서 임의의 엔트리를 수신하여 처리한 것으로 가정할 수 있다.
프런트 엔드(1818)는 만료 기간 후에 응용 프로그램 데이터를 제거할 수 있다. 각각의 응용 프로그램은 임의의 수의 할당량-크기 및 지속기간 쌍을 지정할 수 있다(예컨대, 1일 후에 1000개 이하의 엔트리를 허용하고, 1주일 후에 100개 이하의 엔트리를 허용하며, 1개월보다 오래된 엔트리를 허용하지 않음). 코어 웹 서비스 응용 프로그램 서버(1828)는 큐를 정기적으로 검사하고 임의의 클라이언트 장치에 대한 큐가 부합하지 않는지를 살펴보는 관리 서비스(custodian service)를 가질 수 있다. 관리 서비스는 이미 클라이언트로 전송한 기록을 삭제함으로써 할당량을 만족시킬 수 있다. 그렇지 않은 경우, 관리 서비스는 할당량 초과 장치에 대해 큐에 있는 그 응용 프로그램의 데이터 전부를 플러시(flush)할 것이다.
큐가 클라이언트의 업데이트 요청을 수행할 수 없을 때, 프런트 엔드(1818)는 응용 프로그램-제공 콜백을 인보크할 수 있다. 장치가 지워진(예컨대, 소거된) 경우 또는 관리 서비스가 큐를 플러시할 정도로 오랫동안 사용자가 오프라인으로 있는 경우 이러한 일이 일어날 수 있다. 이 경우에, 응용 프로그램은 큐가 리셋될 필요가 있다는 것을 통보받으며, 응용 프로그램이 데이터를 처음부터 다시 큐잉할 것으로 예상된다. 클라이언트는 그의 앵커가 더 이상 유효하지 않다는 것을 나타내는 오류 코드를 반환받으며, 클라이언트가 다시 앵커 0으로 리셋될 것으로 예상된다. 응용 프로그램이 큐를 다시 채웠다고 나타낼 때까지 큐는 리셋 상태에 들어간다. 그 때까지, 큐는 임의의 클라이언트 업데이트 요청에 대해 0 엔트리를 반환한다.
프런트 엔드(1818)는 또한 응용 프로그램이 장치에 대한 큐를 강제로 리셋시킬 수 있게 해줄 수 있다. 응용 프로그램이 백 엔드 부분이 파국적인 실패를 겪었고 더 이상 응용 프로그램에 차등적 변경(differential change)을 제공할 수 없다는 것을 검출하는 경우 이것이 필요할 수 있다.
코어 웹 서비스 응용 프로그램 서버(1828) 내의 응용 프로그램은 큐 엔트리의 목록을 클라이언트에 대한 유효한 변경 목록으로 변환할 수 있는 콜백을 큐에 제공할 수 있다. 큐가 데이터 독립적(data-agnostic)이기 때문에, 응용 프로그램은, 큐 데이터가 장치로 전송하기 위해 동기화 엔진으로 다시 넘겨질 수 있기 전에, 큐 데이터를 해석할 수 있다. 큐가 데이터베이스-기반(database-backed)일 수 있다. 클라이언트가 업데이트 요청을 하거나 큐가 리셋될 때마다 잠금이 획득되지만, 이것은 응용 프로그램이 데이터를 큐에 계속하여 넣는 것을 방해하지 않는다.
통합 서비스 웹 서버(1804)는 2개의 동기화-관련 웹 서비스 호출을 노출시킨다.
제1 호출은 업데이트(update)라고 하는 POST 방법이다. 이 호출은 클라이언트 프로그램이 마지막 서버 변경에 병합하기 위해 사용할 수 있는 변경 목록을 서버로부터 검색한다. 클라이언트에 관한 상태 정보가 각각의 동기화 응용 프로그램에 대한 동기화 앵커 - 처음에 0으로 설정되어 있는 롱 값(long value)임 - 를 통해 유지된다. 클라이언트가 주어진 동기화 응용 프로그램 ID에 대한 서버 변경을 요청할 때, 클라이언트는 그의 현재 앵커를 파라미터로서 제공한다. 서버는 형식 설정된 변경 목록을, 마지막 서버 앵커와 함께, 반환한다. 클라이언트가 서버 변경을 성공적으로 병합한 후에, 클라이언트는 그의 앵커를 서버의 값으로 업데이트해야만 한다. 클라이언트는 변경 목록의 크기를 제한하기 위해 페이지-크기 파라미터를 지정할 수 있고, 이 경우에, 클라이언트가 더 많은 업데이트를 페치할 필요가 있다는 것을 나타내기 위해 "is more" 플래그가 설정된다. 업데이트는 클라이언트가 다수의 동기화 응용 프로그램 ID에 대한 서버 업데이트를 동시에 페치할 수 있게 해주는 일괄 처리 호출(batching call)일 수 있다 - 이는 왕복(roundtrip) 횟수를 감소시키는 데 도움이 될 수 있음 -.
제2 호출은 클라이언트의 변경 목록을 서버(1804)로 전송하는 커밋(commit)이라고 하는 POST 방법이다. 클라이언트(1802)는 요청에서 그의 마지막 앵커를 또다시 지정한다. 주목할 점은, 클라이언트(1802)가 마지막 서버 버전으로 업데이트되지 않는 경우 서버(1804)가 (특정의 오류 응답을 통해) 커밋 요청을 거부할 것이라는 것이다. 이 경우에, 클라이언트(1802)는 재시도하기 이전에 업데이트를 호출하고 서버의 마지막 변경을 병합해야만 한다. 따라서, 클라이언트는 일반적으로 그의 변경을 커밋하기 전에 업데이트를 호출해야만 한다.
클라이언트 프로그램은 임의의 충돌을 검출하고 해결한다. 커밋은 충돌이 없어야만 하고, 따라서 클라이언트가 서버 업데이트를 페치하고 이를 경합하는 클라이언트 변경들을 포함할 수 있는 그의 로컬 데이터 저장소에 병합하려고 시도할 때에만 충돌이 발생할 수 있다. 일반적으로, 클라이언트가 처리해야만 하는 다음과 같은 3가지 종류의 충돌이 있다:
Figure pat00010
서버 수정-클라이언트 수정(Server-mod-client-mod). 클라이언트 및 서버 둘다가 마지막 성공적인 동기화 이후에 특정의 데이터 항목을 변경하였다.
*
Figure pat00011
서버 수정-클라이언트 삭제(Server-mod-client-delete). 서버가 마지막 성공적인 동기화 이후에 클라이언트가 삭제했던 데이터 항목을 수정하려고 시도하고 있다.
Figure pat00012
서버 삭제-클라이언트 수정(Server-delete-client-mod). 서버가 마지막 성공적인 동기화 이후에 클라이언트가 수정했던 항목을 삭제하려고 시도하고 있다.
주목할 점은, 동기화 웹 서비스 호출이 클라이언트와 서버 응용 프로그램 사이에서 교환되는 동기화 데이터의 형식에 관해 전혀 모르고 있다는 것이다. 서버 및 클라이언트 변경 목록은 종단점이 동기화 프레임워크를 통해 교환하는 불투명한 블로브(opaque blob)이다. 이 점에서, 동기화 웹 서비스 호출은 원칙적으로 2개의 종단점 사이의 앵커 방식 전송 메커니즘(anchored transport mechanism)이다.
통합 서비스 웹 서버(1804)는 또한 도 19에 기술되어 있는 동기식 유한 상태 기계인 통합 서비스 동기화 프로토콜 핸들러를 가질 수 있다. 통합 서비스 동기화 작업이 동기화 엔진 제어기에 의해 디큐잉(dequeue)되면, 제어기는 핸들러의 executeSync() 메소드를 호출하고, 이 메소드는 시작에서 시작하는 플로우차트를 아래쪽으로 진행한다. executeSync 호출이 완료 때까지 차단되지만, 전체 작업이 끝나야 하는 타임아웃(전형적으로 2 분이지만, 이것은 구성가능함)이 있다.
도 19는 예시적인 동기화 동작을 나타낸 플로우차트(1900)이다. 가장 간단한 시나리오는 시작(1901)으로부터 바로 아래쪽으로 도 19의 플로우차트를 따라가는 것으로부터 얻어진다. 동기화가 강제되는 경우(즉, 서버 푸시 통지 또는 다른 응용 프로그램에 의한 명시적인 강제의 결과임) 또는 핸들러와 연관된 동기화 어댑터가 로컬 변경을 갖는 경우, 동기화가 시작된다(단계 1902). 핸들러가 어떤 변경도 갖지 않는 경우, 프로세스가 종료한다 (단계 1903). 변경이 있거나 동기화가 강제되는 경우, 핸들러는 클라이언트의 앵커를 획득하고(단계 1904), 차등적 서버 변경을 얻기 위해 동기화 WS 핸들러를 호출한다 (단계 1905). 요청이 성공적인 경우(단계 1906), 핸들러는 이제 updateClient() 호출을 통해 어댑터에 병합할 블로브(바이트 어레이)를 가진다(단계 1907). 병합이 성공하면(단계 1908), 클라이언트 어댑터는 그의 앵커를 서버의 앵커로 업데이트했어야만 하며, 이 값이 캐시로 전송된다(단계 1909). 핸들러가 페이지 단위로 업데이트를 검색하도록 구성될 수 있고, 10의 페이지 크기는 클라이언트가 클라이언트에 대한 그 다음 10개의 앵커 값을 갖는 기록만을 원한다는 것을 나타낸다. 페이지가 사용되는 경우, 핸들러는 서버 상에 더 이상 데이터가 없다는 것을 명시적으로 통보받을 때까지 업데이트를 계속하여 페치 및 병합할 것이다(단계 1910). 그 다음에, 핸들러는 임의의 로컬 클라이언트 변경이 있는지를 판정한다(단계 1911). 클라이언트 변경이 없는 경우, 프로세스가 종료한다(단계 1912). 클라이언트 변경이 있는 경우, 핸들러는 변경을 검색하고(단계 1913), 변경을 서버로 커밋한다(단계 1914). 핸들러는 이어서 커밋이 성공적이었다는 것을 확인할 것이다(단계 1915). 커밋이 성공적인 경우, 서버는 그의 새로운 앵커를 전송할 것이다(단계 1916). 커밋이 확인될 때 앵커가 어댑터에 제공되고, 어댑터는 확인을 수신할 때까지 커밋이 실패한 것으로 가정해야만 한다. 마지막으로, 새로운 앵커가 캐시로 중계된다(단계 1916).
플로우차트(1900)의 측면 분기는 몇개의 실패 사례가 어떻게 처리되는지를 나타낸다. 서버는 업데이트 요청에서 클라이언트 앵커를 거부할 수 있다. 앵커가 마이너스인 경우 또는 클라이언트가 서버 앵커보다 큰 앵커를 전송하는 경우에 이것이 일어날 것이다(하나의 예외적인 경우가 이하에 있음). 이 경우에, 클라이언트는 그의 데이터를 플러시하고 처음부터 시작하라고 지시받는다(단계 1917). 서버는 클라이언트가 오염된 상태에 있는 것으로 추측할 수 있고 클라이언트에게 요청하도록 요구할 수 있다(단계 1917). 이것은 상기한 것과 본질적으로 동일한 경우이다. 서버는 복구를 요청할 수 있고(단계 1918), 이는 서버가 클라이언트 데이터로부터 복구할 수 있도록 클라이언트가 그의 데이터 전부를 서버로 전송(전체 동기화)할 필요가 있다는 것을 나타낸다. 이것은 재난 복구 동안 또는 클라이언트가 새로운 클라우드로 마이그레이션될 때[한 서버(104)로부터 그의 데이터를 갖지 않는 다른 서버(104)로 이동할 때] 일어날 수 있다. 서버는 또한, 클라이언트 앵커가 영이 아닌 동안 서버 앵커가 0인 경우, 복구의 필요성을 검출할 수 있다.
플로우차트는 또한 충돌 처리 프로세스(단계 1919)를 나타내고 있다. 충돌 처리는, 예를 들어, 클라이언트 프로그램에서 행해질 수 있다. 서버는 클라이언트 프로그램이 장치 변경을 커밋하려고 시도할 때 클라이언트 프로그램이 오래되어 쓸모없다는 것을 클라이언트 프로그램에 통지할 수 있다. 간단함을 위해, 서버는 클라이언트가 마지막 서버 데이터로 업데이트될 때에만 커밋을 허용한다. 결과적으로, 서버측 충돌이 결코 없다.
통합 서비스 클라이언트 전화기[예컨대, 도 18의 모바일 장치(1802)]의 기본적인 특징들 중 하나의 특징은 사용자가 가입해 있는 다양한 소셜 네트워크로부터의 새로운 데이터로 적시에 효율적으로 업데이트될 수 있는 것이다. 이것을 하기 위해, 장치가 도 18의 통합 서비스 코어 서비스 응용 프로그램 서버(1818)로부터 새로운 데이터를 언제 검색해야 하는지를 알 수 있도록, 통합 서비스가 통지를 장치로 전송하는 메커니즘을 포함하는 것으로 판정되었다.
이러한 서비스를 제공하기 위해, 통지가 푸시 채널을 통해 사용자 장치(1802 또는 1803)로 전송되는 것이 바람직하다. 푸시 채널은 메시징 프로토콜에 대한 기초로서 XMPP를 사용하는 항상 켜져 있는 TCP/IP 연결(always on TCP/IP connection)일 수 있다. 메시징을 위한 기초로서 사용될 수 있는 시스템의 한 일례는 Jabber XCP 서버(www.jabber.com)이다.
도 20은 도 18의 푸시 서버(1830)에 의해 구현될 수 있는 예시적인 푸시 채널에 대한 서버측 PUSH 아키텍처(2000)를 나타낸 것이다. PUSH 아키텍처(2000)는 푸시 서비스 통지 API(2002), 푸시 서비스 요청 핸들러(2004), 푸시 서비스 스케줄러(2006), 푸시 서비스 XMPP 메시지 발생기(2008), 및 Jabber XCP(2012)에 대한 푸시 서비스 인증 플러그인(2010)을 포함한다.
푸시 서비스 통지 API(2002)는 통지 및 데이터를 특정의 계정 장치로 전송하기 위해 백 엔드 서비스[예컨대, 도 18의 푸시 서버(1830)]에 의해 사용된다. 일 실시예에서, API는 다음과 같이 정의될 수 있다:
public class SignalData {
public enum Action {
ADD, REPLACE, DELETE
};
새로운 SignalData 객체를 생성함
* @param key - 이 데이터 항목을 탐색할 때 일치하는지 대조될 수 있는 키
* @param data - 클라이언트로 전송될 불투명한 데이터를 보유하는 문자열
* @param maxDelay - 이 데이터를 전송하기 전에 기다리는 최대 기간(초)
* @param expiresAfter - 이 데이터를 삭제해야 하는 현재 시간으로부터의 기간(초)
* @param Action - 이 특정의 데이터 항목에 대해 취해질 조치
* Action.ADD - 키에 상관없이 데이터 항목을 추가함
* Action.REPLACE - 이 키와 일치하는 다른 데이터 항목이 있는 경우, 그것을 대체함. 그렇지 않은 경우, 데이터 항목을 추가함
* Action.DELETE - 현재 키와 일치하는 데이터 항목을 찾아내고 그것을 삭제함. 이것에서 키 및 데이터가 널일 수 있음.
*/
public SignalData(String key, String data, int maxDelay, int expiresAfter, Action action);
/*
* 간단한 게터(getter)들
*/
public String getKey();
public String getData();
public int getMaxDelay();
public int getExpiresAfter();
public Action getAction();
}
public interface Signaling {
/**
* 특정의 계정과 연관된 장치로 전송될 데이터의 목록을 큐잉할 준비를 함.
* @param appId - 이 데이터를 전송한 응용 프로그램의 id
** @param accountId - 이 데이터를 전송받을 장치의 계정의 id
* @param deviceId - 이 데이터를 전송받을 장치의 id
* @param SignalData - 장치로 전송할 데이터 항목의 목록. 각각의 데이터에 대해 취할 조치가 각각의 데이터에 삽입되어 있음
*/
public void sendPushData(String appId, String accountId, String deviceId, SignalData[] data);
}
sendPushData 메소드는 푸시 서비스 요청 핸들러(PSRH)(2004)를 호출할 웹 서비스 호출을 생성한다. PSRH(2004)는 다음과 같이 RESTful 자원으로서 표현될 수 있는 웹 서비스 호출을 노출시키는 서버이다: /blur-services- 1.0/ws/push/signaldata. 일 실시예에서, 푸시 서비스 요청 핸들러(2004)는 각각의 POST에 대해 하기의 동작을 수행한다:
Figure pat00013
푸시 데이터를 역직렬화함,
Figure pat00014
이 특정의 계정 id - 장치 id - 에 대해 포스팅된 데이터가 이미 있는지를 검사함,
Figure pat00015
포스팅된 데이터가 이미 있는 경우, 각각의 데이터 항목과 함께 전송된 조치에 기초하여 데이터를 추가/대체 또는 삭제함,
Figure pat00016
데이터가 없는 경우, 이 계정 id - 장치 id - 에 대한 새로운 큐를 생성하고 그에 데이터를 추가함,
Figure pat00017
필요에 따라 큐 상의 임의의 데이터를 만료시킴,
Figure pat00018
데이터를 다시 데이터 저장소에 저장함,
Figure pat00019
추가되는 모든 데이터 항목에 대해, 그 데이터 항목에 대한 새로운 시퀀스 id를 발생하고 그를 저장함, 및
Figure pat00020
이 서비스에 도달하기 전에 API 호출이 실패하는 경우, 분실된 메시지가 기록되지 않을 것임. 한 해결책은 이러한 누락이 포착되도록 API 자체가 시퀀스 id를 데이터베이스에 저장하는 것이다.
시퀀스 id를 데이터베이스에 저장하는 것이 필요한 이유는 API가 각각의 데이터 항목을 조사하고 가장 작은 최대 지연 값을 획득하며 그것을 현재 시간에 가산하고 저장된 스케줄 시간이 상기 값보다 큰 경우 스케줄 요청을 스케줄러로 전송하는 상태 비저장(stateless) 서버에 연계되어 있기 때문이다.
푸시 서비스 요청 핸들러(2004)는, 스케줄 업데이트를 트리거하는 데이터 항목을 수신할 때, 전송될 메시지를 스케줄링하라는 요청을 푸시 서비스 스케줄러(2006)로 전송한다. 푸시 서비스 스케줄러(2006)는 RESTful URL을 통해 단일 자원을 노출시키는 서버이다. RESTful 보디는, 예를 들어, [{"blurAcctId" :"...", "providers" :["facebook", "myspace", ...]}, ...]일 수 있다. 바람직하게는, 클라우드당 이들 스케줄러 중 하나만이 있을 것이지만, 더 많이 있을 수도 있다. 푸시 서비스 스케줄러(2006)가 바람직하게는 전용 서버이지만, 다른 실시예에서는, 푸시 서비스 스케줄러(2006)가 다른 서버의 일부일 수 있다. 푸시 서비스 스케줄러(2006)는 그의 스케줄 전부를 내부 메모리(도시 생략)에 유지하고 있다. 푸시 서비스 스케줄러(2006)는 최적의 처리율을 보장해주기 위해 HTTP 1.1 영구적 연결을 이진 프로토콜과 함께 사용할 수 있다. 일 실시예에서, 새로운 스케줄 요청이 행해질 때, 푸시 서비스 스케줄러(2006)는 스케줄(스케줄은 계정_id, 장치_id 및 스케줄 시간만을 포함함)을 역직렬화하고 스케줄을 스케줄링 큐에 위치시킬 수 있다.
백그라운드 처리 스레드에서, 스케줄링 큐가 계속 대기되고, 적절한 순간에, XMPP 메시지를 발생하기 위해 푸시 서비스 XMPP 메시지 발생기(2008)에 대해 웹 서비스 호출이 행해진다.
푸시 서비스 XMPP 메시지 발생기(2008)는 푸시 서비스 스케줄러(2006)로부터의 요청에 응답하여 XMPP 메시지를 생성한다. 일 실시예에서, 각각의 요청에 대해, 푸시 서비스 XMPP 메시지 발생기(2008)는 요청으로부터 계정 id 및 장치 id를 획득하고, 데이터 저장소에서 계정 id 및 장치 id와 연관된 모든 데이터를 찾아내며 데이터를 검색하여 그를 데이터 저장소로부터 삭제할 수 있다. 푸시 서비스 XMPP 메시지 발생기(2008)는 데이터를 XMPP 메시지 요소로 패키징하고 XMPP 메시지가 XMPP 서버(2012)로 전송될 수 있다.
클라이언트 장치[예컨대, 도 18의 모바일 장치(1802)]에 대한 계정 설정 프로세스는 XMPP 계정을 생성하기 위해 XMPP 서버(2012)를 호출할 수 있다. 다른 대안으로서, 이 부가의 호출을 제거하고 인증을 용이하게 해주기 위해, 특정의 계정에 관한 정보의 유효성 검사 및 검색 둘다를 수행하기 위해 통합 서비스 인증 아키텍처[예컨대, 코어 서비스 프로세서(1818)]를 이용하게 될 구성요소가 XMPP 서버(2012)에 대해 사용될 수 있다.
장치 구성 동안, 사용자는 유익하게도 특정의 장치와 연관될 수 있는 새로운 계정(통합 서비스 계정)을 생성할 수 있다. 이 동작과 연관된 데이터는 계정 서비스가 그를 저장하기로 결정하는 어떤 방식으로든지 계정 데이터베이스에 저장될 것이다. XMPP 서버(2012)는 XMPP 서버에 부착된 패킷 필터로서 역할하는 구성요소를 가질 수 있다. 이 구성요소는, 인증 요청을 수신할 때, 요청으로부터 적절한 인증 토큰을 획득한다. 이 구성요소는 이어서 계정 응용 프로그램에 대해 웹 서비스 호출을 행하여 사용자를 인증하기 위해 이들 토큰을 사용한다. 이 구성요소는 이어서 사용자 인증 성공 또는 실패를 나타내는 신호를 XMPP 서버(2012)로 전송한다.
패킷 필터로서도 역할할 수 있는 보조 구성요소가 또한 XMPP 서버(2012)에 부착되어 있을 수 있다. 이 보조 구성요소는 인증 패킷 대신에 현재 상태 패킷을 탐색할 것이다. 모든 XMPP 클라이언트가 메시지를 수신하기 위해 현재 상태 패킷을 송출하기 때문에, 웹 서버[예컨대, 도 18의 웹 서버(1804)]에 성공적으로 부착되는 임의의 XMPP 클라이언트는 XMPP 현재 상태 패킷을 전송할 것이다. 이 보조 구성요소는 현재 상태 패킷을 검출할 수 있고 푸시 서비스 요청 핸들러(2004)로 하여금 클라이언트가 언제 연결되었는지 또는 연결되지 않았는지를 알아내게 할 수 있다. 이것으로 인해 푸시 서비스 요청 핸들러(2004)는 특정의 클라이언트에 대한 스케줄링을 처리할 필요가 있는지 여부를 푸시 서비스 스케줄러(2006)에 알려줄 수 있다.
푸시 채널은 장치(1802)에 적시의 통지를 제공하는 최선의 노력 서비스(best effort service)이다. 푸시 채널은 채널을 통해 전송된 모든 데이터가 장치(1802)에 도달하도록 보장하지 않을 수 있다. 실제로, 요구사항은 푸시 채널이 비활성화되어 있을 때에도 장치가 동작할 수 있어야 한다는 것이다. 이 요구사항을 지원하는 몇몇 사용 사례가 있다. 첫째, 장치가 듬성듬성한 커버리지로 인해 푸시 채널을 활성화시킬 수 없는 때가 있다. 이러한 경우에, 푸시 채널을 활성화시키는 일 없이 데이터를 수동으로 동기화시키는 것이 가장 최적일 수 있다. 또한, 푸시 채널이 항상 켜져 있는 연결(always on connection)이기 때문에, 전화기가 로밍 모드에 들어가는 경우, 서비스는 푸시 채널을 끄고자 할 수 있다. 따라서, 푸시 서비스의 주요 책무는 적시의 통지를 제공하고 누락된 그 푸시를 검출하는 수단을 장치에 제공하는 것이다.
푸시 서비스는 통지를 불투명한 응용 프로그램 고유의 이산 데이터로서 장치(1802)로 전송한다. 0부터 시작하여 임계값(예를 들어, 2^31)에 도달한 후 다시 0으로 돌아가는 시퀀스 id로 각각의 데이터에 표시를 한다. 일 실시예에서, 시퀀스 id는 다음과 같이 발생될 수 있다. 코어 서비스 서버(1828)는 푸시가 필요하다는 것을 검출하고 데이터를 장치(1802)로 푸시할 준비를 한다. 코어 서비스 서버(1818)는 이어서 준비된 데이터를 사용하여, 푸시 서버(1830)에 의해 제어될 수 있는 푸시 API를 호출한다. 푸시 API는 이어서 계정 id/장치 id를 검색한다. 푸시 API는 영구적 저장소로부터 그 다음 시퀀스 id를 탐색하기 위해 계정 id/장치 id를 사용한다. 푸시 API는 이어서 시퀀스 id로 데이터에 표시를 하고 데이터를 푸시 요청 핸들러로 전송한다. 푸시 API는 이어서 SUCCESS 메시지를 다시 코어 서비스, 예를 들어, 코어 서비스 서버(1828)로 반환한다. 코어 서비스 서버(1828)는 SUCCESS 메시지를 수신하고 전송될 메시지를 고려한다.
푸시 API가 시퀀스 id를 검색하지 못한 경우, 푸시 API는 예외를 발생시키고 푸시 메시지가 전송되지 않는다. 이것이 일어날 때, 푸시 API는 이벤트의 이력을 저장할 수 있고, 시퀀싱 메커니즘이 작업 순서로 되돌아올 때, 시퀀싱 메커니즘은 저장된 이력에 기초하여 시퀀스를 리셋할 수 있다.
푸시 API가 푸시를 푸시 요청 핸들러로 전송할 수 없는 경우, 푸시 API는 다른 예외를 발생시킬 수 있다. 이것이 일어날 때, 시퀀스 id가 영구적 저장소에서 이미 증분되었기 때문에, 그 다음 푸시는 그 다음 시퀀스 id를 수신할 것이고, 그 다음 푸시가 장치(1802)에 대해 우연히 성공하더라도, 장치(1802)는 이제 비순차적으로 될 것이다. 다른 대안으로서, 푸시 요청 핸들러가 요청을 스케줄러로 전송하기 전에 작동되지 않아서 푸시 메시지가 전송되지 않은 경우, 시퀀스에 간극이 생길 수 있다. 이 상황에서, 장치(1802)는 전체 동기화를 요청할 수 있다.
통합 서버(1804)는 통합된 피드를 클라이언트 장치(1802)에 제공할 수 있다. 다수의 피드가 중간 웹 서버(1804)로부터 전송되도록 사용자 장치(1802)에 의해 요청된 경우, 피드 데이터 전부를 제공하기 위해 통합된 피드가 이용될 수 있다. 통합된 피드는 다양한 피드 유형의 하나 이상의 피드를 포함한다. 통합된 피드의 목적은, 친구 피드 데이터, 뉴스 피드 데이터, 및 기타 데이터를 획득하기 위해 개별적인 요청을 하는 대신에, 클라이언트가 단일 요청으로 그의 피드 전부를 획득할 수 있게 해주는 것이다. 피드는, 예를 들어, Facebook™, My Space™, Twitter™, LinkedIn™과 같은 소셜 네트워킹 사이트로부터 이용가능한 사용자의 친구에 관한 업데이트를 포함할 수 있는 친구 피드일 수 있다. 피드는 또한, 예를 들어, 각종의 소스 Yahoo™ News, Digg™ 등으로부터 온 것일 수 있는 RSS 피드로부터 이용가능한 뉴스 정보를 포함하는 뉴스 피드일 수 있다. 다른 대안으로서, 피드는 Yahoo™ Weather와 같은 소스로부터의 날씨 정보를 포함할 수 있는 날씨 피드, 또는 서비스 상태 정보를 포함할 수 있는 관리 피드일 수 있다.
앞서 논의된 바와 같이, 피드는 Facebook™ 또는 뉴스 피드에 대한 각자의 플러그인(1824) 등과 같은 각종의 소스로부터 통합 서버(1804)에 의해 수집될 수 있다. 피드는 사용자별로 웹 서비스 서버(1828)로 포스팅될 수 있다. 피드 관련 웹 서비스는 피드를 공통 피드 형식으로 피드 밀(feed mill)로 포스팅한다. 피드 밀은, 피드를 수신할 때, 앞서 논의된 바와 같이 하위 우선순위 통지를 푸시 관리자로 전송한다. 피드는 피드 밀에 축적되고, 얼마간의 시간 또는 어떤 이벤트 후에, 푸시 관리자는 푸시를 클라이언트로 전송한다. 예를 들어, 클라이언트(1802)는 한번의 요청으로 그의 피드 전부를 획득할 수 있다.
일 실시예에서, 통합된 피드 특징을 제공하기 위해 통합 서버(1804)에 의해 2개의 프로토콜이 이용될 수 있다. 제1 프로토콜은 피드 관련 웹 서비스(친구 피드 웹 서비스, 뉴스 피드 웹 서비스, 기타 등등)가 피드 밀 웹 서비스와 어떻게 상호작용할 것인지를 정의한다. 피드 관련 웹 서비스는, 피드 밀 웹 서비스로 전송할 피드 데이터를 가질 때, /ws/feedmill/0/feedGrain/accountID와 같은 상대 요청 URI를 사용하여 HTTP POST 방식 요청을 한다. 이미 공통 피드 형식으로 되어 있는 피드 데이터가 피드 유형과 함께 요청 보디에 포함될 것이다. 서버는 HTTP 상태 코드로 응답할 것이다.
제2 프로토콜은 피드 밀이 클라이언트(1802)와 어떻게 상호작용할 것인지를 정의한다. 클라이언트(1802)는, 피드 밀로부터의 그의 피드를 요청할 때, 클라이언트에 의해 처리되는 각각의 피드 유형에 대한 시퀀스 번호를 포함하는 간단한 웹 서비스 호출을 한다. 서버 응답은 피드 데이터 전부를 포함할 것이다.
"통합된 피드"는 "피드 밀" 용어와 관련하여 기술되어 있다. 피드 밀 웹 서비스로 전송된 피드 데이터는 공통 피드 형식을 사용하여 전송될 것이다. 이것은 다양한 소스로부터의 임의의 데이터가 일관된 방식으로 처리될 수 있도록 하기 위한 것이다. 이하는 서버가 수신할 것으로 예상할 수 있는 통상적인 및 비통상적인 데이터이다.
통상적인 데이터는 공급자, 계정 id, 보디 유형, 카테고리, ID, 링크, 요약, 포스팅 시간, 제목, 동작 및/또는 지오태그를 포함할 수 있다. 피드의 공급자는 친구 피드, 뉴스 피드, 날씨 피드 및 관리 피드에서 발견된다. 계정 ID는 통합 서비스 계정 ID일 수 있다. 친구 피드는 또한 계정 ID를 포함할 수 있다. 친구 피드는 보디 및 보디 유형을 포함할 수 있고, 뉴스 피드 및 날씨 피드는 원자 콘텐츠(atom Content)를 포함한다. 관리 피드도 역시 보디 및 보디 유형을 포함할 수 있다. 하나 이상의 카테고리가 통합 서비스에 의해 정의된다. 친구 피드 및 관리 피드는 유형 및 서브유형을 포함한다. 피드는 하나 이상의 링크를 포함할 수 있다. 친구 피드는 미디어 항목에 대한 하나 이상의 URL, 스트림 URL(streamURL) 또는 링크를 포함할 수 있다. 뉴스 피드 및 날씨 피드는 원자 링크를 포함할 수 있다. 관리 피드는 또한 URL을 포함할 수 있다. 뉴스 피드 및 날씨 피드는 원자 요약(atomSummary)을 포함할 수 있다. 관리 피드는 요약을 포함할 수 있다. 피드는 각각의 항목이 포스팅되는 시간을 포함할 수 있다. 피드는 또한 피드에 대한 제목 및 제목 유형 또는 피드 내의 데이터를 포함할 수 있다. 뉴스 피드 및 날씨 피드는 원자 제목(atomTitle)을 포함할 수 있다. 피드는 또한 수행될 수 있는 하나 이상의 동작 및 지리적 식별 메타 데이터를 포함할 수 있다.
피드는 또한 외부 ID(externalID)와 같은 비통상적인 데이터 유형을 포함할 수 있고, 사용자의 공급자측 사용자 ID는 친구 피드에서 발견되고, 통합 서비스 ID인 연락처 ID(contactID)는 친구 피드에서 발견될 수 있으며, 연락처의 콘텐츠 공급자 웹 사이트 ID인 외부 연락처 ID(externalContactID)는 친구 피드에서 발견된다.
클라이언트(1802)와 통합 서버(1804) 사이의 예시적인 상호작용에 대해서는 이하의 용어를 사용하여 논의한다:
Figure pat00021
피드 유형 - 피드의 특정의 유형(즉, 뉴스, 친구, 관리, 날씨...),
Figure pat00022
피드 그레인(Feed Grain) - 주어진 피드 유형에서의 특정의 항목. 일례로서, 뉴스 피드의 경우, 피드 그레인은 개개의 뉴스 항목일 수 있다. 각각의 유형의 피드 내에 포함된 실제 데이터가 피드의 유형에 의존하지만, 이들이 모두 동일한 형식으로 되어 있을 것이다(Lien 참조). 각각의 피드 그레인은 피드 밀에 대해 불투명한 문자열로서 취급된다.
Figure pat00023
피드 펠릿(Feed Pellet) - 특정의 유형의 피드 그레인의 모음,
Figure pat00024
피드 백(Feed Bag) - 하나 이상의 펠릿(pellet)으로 이루어진, 서버로부터 클라이언트로 전송되는 데이터,
Figure pat00025
피드 트로프(Feed Trough) - 서버로부터 전송된 피드 펠릿을 분배하는 것을 처리하는 클라이언트 상의 구성요소,
Figure pat00026
피드 밀 - 다수의 소스로부터 피드 펠릿을 수집하는 것을 처리하고 이들을 클라이언트로 전송될 피드 백에 패키징하는 서버 상의 구성요소, 및
Figure pat00027
피드 사일로(Feed Silo) - 장치에 의해 요청될 때까지 피드 그레인을 저장하는 서버 상의 구성요소. 기본적으로, 이는 그 아래에 DB 테이블을 포함하고 있다.
주어진 피드 유형을 사용하고자 하는 클라이언트(1802) 상의 응용 프로그램은 먼저 피드 트로프에 등록할 것이다. 이 등록은 단순히 주어진 응용 프로그램이 어느 피드 유형을 사용하는 것에 관심이 있는지를 나타내는 것 및 새로운 데이터가 존재할 때 응용 프로그램에 통지하기 위해 사용되어야 하는 방법[Android™ 인텐트(intent) 등]을 수반할 것이다. 주어진 응용 프로그램이 많은 피드 유형에 대해 등록되도록 허용될 수 있다. 장치(1802)가 Android™ 장치인 경우, 피드 펠릿이 클라이언트 상에 수신될 때, Android 인텐트 - 이 인텐트에 포함된 데이터의 피드 유형, 서버로부터 전송된 실제 피드 펠릿(등록된 응용 프로그램은 종종 이 데이터를 파싱하는 방식을 가지고 있음), 이 피드 펠릿의 시퀀스 번호, 및 응용 프로그램이 이 인텐트가 피드 트로프로부터 왔다고 검증할 수 있도록 피드 트로프와 응용 프로그램 간에 공유되는 응용 프로그램 암호(등록 시에 설정됨)를 포함함 - 가 모든 등록된 응용 프로그램으로 전송될 것이다.
피드 트로프는 또한 응용 프로그램이 주어진 피드 유형에 대해 자신을 등록 취소하는 방법을 제공할 것이다. 피드 트로프는 또한 응용 프로그램이 처리를 마친 주어진 피드 유형에 대한 마지막 시퀀스 번호를 자신에게 통보할 수 있는 메커니즘을 제공할 수 있다. 이 정보는, 피드 밀이 어느 데이터를 클라이언트에게 전송해야 하는지를 결정할 수 있도록, 클라이언트가 가진 마지막 피드 펠릿을 알려주기 위해 피드 밀과의 통신에서 사용될 것이다. 다수의 응용 프로그램이 주어진 피드 유형에 대해 등록되어 있는 경우, 최소 시퀀스 번호가 유지되고 피드 밀로 전송될 것이다.
피드 트로프는 데이터가 서버 상에서 그를 기다리고 있다는 것을 푸시 관리자가 알려준 것에 응답하여 피드 밀로부터 데이터를 페치한다. 어쩌면, 사용자가 피드의 페치를 수동으로 시작할 수 있는 메커니즘(필요하다고 생각되는 경우)이 또한 존재할 것이다. 피드 트로프로부터의 단지 하나의 페치 요청이 즉시 허용될 것이고, 하나의 페치가 진행 중인 동안 다른 페치가 요청되는 경우, 두번째 페치는 실패할 것이다(해당 오류 코드가 있음).
피드 트로프가 그의 피드를 페치하기 위해 행하게 될 하나의 웹 서비스 호출이 있을 수 있다. 예를 들어, 다음과 같은 HTTP GET 형태(전송될 필요가 있는 임의의 인증/로그인 데이터가 빠져 있음) /ws/feedmill/0/feedMe/accountID?news=X&admin=Y&friend=Z가 있을 수 있고, 여기서 accountID는 사용자의 계정 ID이고, X, Y, 및 Z는 클라이언트가 피드 유형 - 뉴스, 관리 및 친구 - 에 대해 각각 처리한 마지막 시퀀스 번호이다. 장치가 (어떤 외부 설정 메커니즘을 통해) 설정되어 있는 피드 유형만이 상기 라인에 지정되어 있을 것이다. 이 호출로부터 오류 경우를 처리하는 것(userNotAllowed, userNotFound, systemBusy 등)이 사용자에게 나타내어질 수 있다. 시스템이 사용 중인 경우, 서버는 (어쩌면 관리/구성 피드를 통해) 구성되어 있는 어떤 구간을 사용하는 것을 철회할 수 있다.
실제 피드 펠릿의 처리가 응용 프로그램 프로세스에서 행해지고 어쩌면 시간이 많이 걸릴 수 있기 때문에, 피드 트로프 페치 요청은 동일한 데이터를 수신하는 것을 종료시켜 버릴 수 있는데, 그 이유는 시퀀스 번호가 업데이트될 가능성이 없을 수 있기 때문이다. 이러한 일은 드물게 있어야 하지만, 푸시 관리자 피드 트로프 페치의 완료 직후에 사용자가 시작한 피드 트로프 페치에 의해 야기될 수 있고, 많은 푸시가 서버로부터 연속적으로 전송되는 경우 - 이는 클라이언트가 이용가능한 피드 데이터가 있음을 나타냄 -, 장치는 피드 백을 부분적으로/전체적으로 수신한 직후 작동이 중지되거나, 다수의 응용 프로그램이 동일한 피드 유형에 대해 등록되어 있을 때, 악성 응용 프로그램은 그의 시퀀스 번호를 결코 업데이트할 수 없다(또는 위조 값으로 업데이트함).
시퀀스 번호가 수많은 피드 그레인을 포함할 수 있는 전체 피드 펠릿에 적용되기 때문에, 등록된 응용 프로그램은 실제로는 피드 그레인의 부분집합에만 관심을 가지고 있더라도 전체 피드 펠릿을 처리했다는 것을 피드 트로프에 알려주어야만 할 것이다. 본질적으로, 주어진 피드 펠릿의 처리는 전부 또는 전무이며, 더 미세한 세분성이 제공되지 않는다. 시퀀스 번호로 피드 트로프를 업데이트하지 못하면, 다수의 응용 프로그램이 동일한 피드 유형에 대해 등록될 수 있게 된다.
앞서 언급한 바와 같이, 클라이언트 요청은 클라이언트에 의해 처리되는 각각의 피드 유형에 대한 시퀀스 번호를 포함하는 간단한 웹 서비스 호출의 형태를 취한다.
클라이언트 요청에 대한 서버 응답은 이하에서 기술하게 될 실제 피드 백을 포함한다.
피드 백 헤더(feed bag header, FBH)는 몇개의 요소 - 예를 들어, 버전, 콘텐츠 유형(예컨대, DATA 또는 ERROR) 또는 포함된 다수의 피드 펠릿(DATA 경우에 대해서만) 또는 오류 코드(ERROR 유형의 경우에) - 를 가질 수 있다. 각각의 피드 펠릿은 또한 피드 유형, 피드 펠릿의 길이 및 피드 펠릿의 시퀀스 번호를 포함하는 헤더(FPH)를 포함할 수 있다. 일 실시예에서, 피드 백은 다음과 같은 형식으로 되어 있을 수 있다: (FBH)(FPH)(피드 펠릿 데이터)(FPH)(피드 펠릿 데이터)(FPH)(피드 펠릿 데이터)... 오류 경우는, 예를 들어, 단지 (FBH)만을 포함할 수 있다.
피드 밀은 2개의 상이한 위치 - (1) 앞서 논의된 바와 같이, 그의 피드를 요구하는 장치 및 (2) 주어진 사용자에 대한 특정의 피드 유형의 피드 그레인을 제공하는 응용 프로그램 프로세서 - 로부터 오는 요청을 처리해야만 할 것이다. 응용 프로그램 프로세서는 HTTP POST 호출을 통해 피드 그레인을 피드 밀에 제공할 수 있고, 일 실시예에서 이 HTTP POST 호출은 다음과 같은 형식으로 되어 있을 수 있고: /ws/feedmill/0/feedGrain/accountID, 여기서 실제 피드 그레인(공통 형식으로 되어 있음) 및 피드 유형은 요청 보디에 포함될 것이다. 피드 밀은 적절한 HTTP 상태 코드로 응답한다. 각각의 성공적인 피드 그레인 추가 후에, 클라이언트가 이용가능한 피드 데이터가 있다는 것을 나타내는 하위 우선순위 통지가 푸시 관리자로 전송된다. 각각의 사용자는 장치로 전달되기를 기다리고 있는 피드 그레인 전부를 포함하고 있을 피드 사일로(feed silo)를 가질 것이다. 테이블은 유익하게도 피드 유형에 대한 열, 시퀀스 번호[부호없는 정수(단조 증가하는 값)], 및 피드 허용 데이터[문자열 어레이(어쩌면 최대 크기를 가짐)]를 포함할 수 있다.
테이블에서의 각각의 행은 상기 HTTP POST 호출을 통해 추가된 피드 그레인에 대응할 수 있다. 사용자의 피드 테이블에서의 엔트리의 수를 제한하기 위해, 피드 유형별 행의 구성가능한 최대 수가 있을 수 있다. 이 한계에 도달될 때 일어나는 일은 2가지 부류에 속할 것이다:
1. 에이징(aging)이 허용됨 - 이 경우에, 프로세서가 이미 한계에 있는 피드 유형에 대한 피드 그레인을 추가하려고 시도할 때, 가장 오래된 피드 그레인이 제거된다.
2. 에이징이 허용되지 않음 - 이 경우에, 추가가 실제로 실패하고, 오류가 (HTTP 상태 코드를 통해) 응용 프로그램 프로세서로 다시 전송된다.
피드 그레인이 저장된 후에, 피드 밀은 그의 피드(정보)에 대한 피드 트로프의 요청(폴링)에 응답하여 정보를 제공하는 기능을 한다. 피드 밀은 특정의 사용자의 피드에 대한 요청을 받고, 요청이 명시하고 있는 시퀀스 번호를 고려하여 모든 피드에 대해 사용자의 피드 사일로를 쿼리하며, 피드 백을 작성하여 이를 장치로 전송하고 (요청 시퀀스 번호에 기초하여) 오래된 피드 그레인을 사용자의 피드 사일로로부터 제거한다.
각각의 피드 유형의 피드 그레인이 사용자의 피드 테이블에서의 행이기 때문에, 피드 그레인을 실제로 추가하기 위해서는 다수의 데이터베이스 호출이 필요하다. 일 실시예에서, 예를 들어, 피드 밀은 이 피드 유형에 의해 현재 사용되는 행의 수를 획득할 수 있다. 행의 수가 행의 최대 수보다 크고 에이징이 허용되는 경우, 가장 오래된 엔트리를 제거한다. 에이징이 허용되지 않는 경우, 피드 밀은 오류를 반환할 수 있다. 피드 밀은 이어서 피드 그레인을 테이블에 추가할 수 있다.
피드 테이블에 대해 어떤 잠금도 필요하지 않을 수 있다. 이러한 이유는 각각의 행이 독립적이기 때문이고, 주어진 시점에서 모든 피드를 획득하는 프로세스가 새로운 행을 추가하는 것과 충돌해서는 안되는데, 그 이유는 2개의 동작이 동일한 집합에 영향을 미치지 않기 때문이다.
동일한 피드 그레인을 다수의 사용자에 추가하기 위해(즉, 사이트가 정지되었다는 것을 모든 Twitter™ 사용자에게 알려주기 위해) 사용될 수 있는 일괄 처리 메커니즘이 존재한다. 일괄 처리 메커니즘을 수용하기 위해, 일 실시예에서, "/ws/feedmill/0/feedGrainForMany"의 형태를 가질 수 있는 다른 HTTP POST 웹 서비스 호출이 이용될 수 있으며, 이 때 실제 피드 그레인이 사용자의 목록과 함께 요청 보디에 포함될 것이다. 사용자 목록의 정확한 형식은 마스터 사용자 테이블과 피드 밀 사이의 상호작용에 따라 달라질 것이다.
통합 서비스 클라이언트 응용 프로그램 - 예를 들어, 클라이언트 장치(1802) 상에 로드된 응용 프로그램 - 은 연락처 데이터에 액세스하기 위해 상이한 보안 레벨을 갖는 2개의 개별적인 콘텐츠 공급자를 사용할 수 있다. 통합 서비스의 연락처 설계는 어떤 중요한 목표를 염두에 두고서 작성될 수 있다:
Figure pat00028
장치 상의 연락처 저장소는 클라이언트 장치(1802)에 대한 표준(Android™ 장치를 사용할 때 Android™ 표준)을 준수해야만 한다.
Figure pat00029
연락처 데이터가 네트워크 서비스 연락처 데이터와 동기화되어 있어야만 한다.
Figure pat00030
각각의 연락처가 사용자에게 한명의 사람으로서 제시되어야만 하는데, 그 이유는 그것이 사용자가 연락처를 생각하는 방식이기 때문이다.
많은 연락처가 이메일 서버 또는 소셜 네트워크 웹 사이트(1806 내지 1808)로부터 직접 획득될 것이다. 이들 네트워크 중 일부는 제3자 응용 프로그램이 그의 연락처 데이터에 액세스하는 것을 금지하는 서비스 이용 약관을 가진다. 이 때문에, 소셜 네트워크로부터의 연락처(이후부터 친구라고 함)는 클라이언트(1802) 내의 별도의 데이터베이스에 유지될 것이다. 이 제약조건은, 병합된 개인을 제시하는 목표와 결합되어, 기술적인 문제를 제기하는데, 그 이유는 UI에서 병합되는 연락처 레코드가 개별적인 데이터베이스로부터 수집되어야만 하기 때문이다. 이후부터, 본 문서는 이들 용어를 사용한다:
Figure pat00031
연락처 - 표준 Android 데이터베이스에 저장되어 있는 사람들을 말한다.
Figure pat00032
친구 - 개인 소셜 네트워킹 데이터베이스에 저장되어 있는 사람들을 말한다.
Figure pat00033
모든 연락처 - 연락처와 친구의 합집합을 말한다.
Figure pat00034
병합된 연락처 - 연락처와 친구의 교집합을 말한다.
장치 상에서, 연락처는 모든 응용 프로그램에 의해 공유되는 데이터베이스에 저장된다. 통합 서비스는 부가의 데이터 및 기능을 추가하기 위해 표준 연락처를 확장시킨다. 통합 서비스 클라이언트 연락처는 표준 연락처의 상위 집합일 것이며, 제3자 응용 프로그램은 표준 API를 사용하여 연락처에 액세스할 수 있을 것이다.
확장된 연락처 데이터베이스에 부가하여, 통합 서비스 연락처는 소셜 네트워킹 친구에 대한 병렬 데이터베이스를 도입한다. 이 데이터베이스는 제3자 응용 프로그램에 의한 액세스를 방지하는 부가적인 보안을 가진다. 대부분의 방식에서, 데이터베이스의 스키마 및 거동은 연락처에 대해서와 동일하지만, 몇가지 차이점이 있다 - 친구에서 그룹이 지원되지 않음 -. 사용자가 친구를 그룹에 추가하는 경우, 통합 서비스는 자동으로 친구의 데이터의 사본을 갖는 연락처를 생성하고 연락처를 그룹에 추가한다. 또한, 연락처 및 친구에 걸쳐 병합되는 ID를 가능하게 해주기 위해, 친구 데이터베이스는 연락처 ID에 대한 참조를 포함한다.
사용자는 각종의 공급자(1806 내지 1808)로부터의 정보를 사용하도록 장치(1802)를 구성할 수 있다. 이 정보는 이메일, 연락처, 사진, 및 소셜 네트워킹 이벤트를 포함할 수 있다. 통상적인 연락처 공급자의 일례는 Google™, Yahoo™, 및 Facebook™이다. 사용자는 또한, 예를 들어, 이메일 연락처를 획득하기 위해 ActiveSync로부터 또는 SIM(subscriber identity module) 카드 또는 케이블 연결을 통해 이전의 전화기로부터 데이터를 가져오기할 수 있다. 장치를 처음에 구성할 때 또는 그 후에 언제라도 설정에 액세스함으로써 공급자가 추가될 수 있다. 그에 부가하여, 통신 사업자는 통신 사업자(1820)로부터의 연락처를 직접 플러그인(1824)에 제공할 수 있으며, 그로써 연락처가 서버 프런트 엔드 부분을 통해 장치에 다운로드될 수 있다.
도 21은 일 실시예에 따른, 연락처를 가져오기하는 예시적인 방법을 나타낸 것이다. 콘텐츠 공급자(2110)로부터 가져오기된 각각의 연락처는 개별적인 연락처 레코드로서 저장된다. 동일한 개인을 말하는 연락처는 사용자 인터페이스(UI)에서 한명의 개인으로서 나타내어지지만, 레코드는 여전히 데이터베이스에서 별개로 유지되고 있다.
통합 서비스는 코어 서비스 프로세서(2130)와 통신하고 있는 다수의 동기화 어댑터(2220 내지 2128)를 지원할 것이다. 이것은 Google의 gmail™ 연락처에 대한 기본 동기화 어댑터, 주소록 어댑터, 및 통합 서비스용으로 작성된 어댑터 - EAS(Exchange ActiveSync), 소셜 네트워킹 연락처 및 통합 서비스에 동기화되어 있는 연락처를 포함함 - 를 포함한다. 이들 동기화 어댑터 각각은 장치 상에서 그 자신의 것으로서 동기화하는 연락처를 식별해야만 하고, 따라서 연락처에 대한 변경이 단지 원래의 소스에 다시 동기화된다. 통합 서비스용으로 작성된 어댑터의 경우, 연락처 데이터베이스 내의 새로운 열은 동기화 소스를 식별하는 데 사용된다. 이 열에 대한 값을 갖지 않는 연락처는 Google™ 또는 다른 제3자에 속하는 것으로 가정된다.
연락처 소스들 중 하나는 장치 상에서 생성된 연락처가 추가되는 기본 주소록으로서 식별될 것이다. 다른 대안으로서, 기본 연락처 소스는 통합 서비스의 연락처일 수 있다. 사용자는 어느 주소록이 기본인지 및 어느 주소록이 특정의 연락처에 대해 사용되어야 하는지를 선택할 수 있다.
상이한 공급자로부터의 연락처가, 실제로 동일한 개인을 말하고 있는지에 상관없이, 개별적인 연락처 레코드로서 저장되어 있는 반면, UI는 항상 연락처를 사용자에게 개인으로서 제시하려고 시도한다.
새로운 "아이덴티티" 테이블이 클라이언트의 연락처와 동일한 데이터베이스에 생성될 수 있다. 테이블에 각각의 개인에 대한 하나의 행이 있다. 연락처 레코드가 어느 개인에 속하는지를 나타내는 새로운 열이 "사람들" 테이블에 추가될 수 있다. 아이덴티티 테이블이 통합 서버(1804)와 동기화되지 않을 수 있다. 연락처가 추가될 때 아이덴티티 테이블이 클라이언트 장치(1802) 상에 동적으로 생성된다. 예외는 사용자가 연락처 레코드를 수동으로 병합 또는 분할할 수 있다는 것이다. 이러한 아이덴티티에 대한 수동 변경은 유지되어야만 하고, 따라서 통합 서버(1804)와 동기화된다.
연락처는, 클라이언트 장치(1802) 상에서 추가될 때, 동일한 개인을 말하는 것인지를 판정하기 위해 다른 연락처 레코드와 대조된다. 일치하는 것이 없는 경우, 새로운 행이 아이덴티티 테이블에 추가된다. 사람들 테이블 내의 아이덴티티 열이 아이덴티티 행을 가리키도록 업데이트된다.
사람들보다 아이덴티티에 액세스하기 위해 연락처 기관 내의 새로운 콘텐츠 URL이 이용가능할 수 있다. 연락처에 액세스하기 위해 많은 통합 서비스 코드가 이들 URL을 사용할 것이다.
아이덴티티 테이블은 사람으로부터의 가장 최근의 소셜 네트워킹 상태 업데이트를 저장하는 열을 포함한다. 이 데이터는 제품 전체에 걸쳐 나타나는 "아이덴티티 배지" 위젯 - 다양한 연락처 화면, 홈 화면 상호연결 카드(loop card),및 메시지 어드레싱을 포함함 - 상에 디스플레이될 수 있다.
모든 사용자 인터페이스의 연락처 보기 또는 편집은 실제로 통합 서비스가 동일한 사람으로 생각하고 있는 일련의 연락처 레코드에 작용할 것이다. 일련의 연락처 레코드는 아이덴티티 테이블로부터 가져온 것이다.
임의의 병합 전략은 2가지 유형의 오류 - 과잉 병합(즉, 개별적인 개인을 한 사람으로서 제시하는 것) 및 과소 병합(즉, 한 개인을 개별적인 사람으로서 제시하는 것) - 를 발생할 위험을 포함하고 있다. 통합 서비스 서버가 하기의 이유로 과잉 병합 쪽에서 오류를 발생하는 것이 생각된다:
Figure pat00035
양쪽을 해결하는 것보다는 한쪽 오류 카테고리를 해결하는 것이 더 쉽다.
Figure pat00036
2명의 개인이 적절히 동일한 사람인 것처럼 보이는 것보다 한 개인이 다수의 공급자에 저장될 가능성이 더 많다.
Figure pat00037
통합 서비스가 과잉 병합을 하는 경우, 사용자가 실제로는 상이한 사람에 속하는 데이터를 식별하기가 쉽다.
Figure pat00038
통합 서비스가 과소 병합을 하는 경우, 이는 사용자에게 "누락된" 데이터처럼 보인다. 이것은 사용자를 당황케할 것이며, 병합되었어야 하는 다른 연락처 레코드를 찾는 것이 어려울 것이다.
사용자는 통합 서비스가 과잉 병합된 또는 과소 병합된 연락처를 가지고 있을 때를 결정할 수 있다. 이것은 연락처 상세 활동의 "소스" 섹션으로부터 행해진다.
하기의 것들 - 레코드가 정확히 동일한 이름을 가지는 것, 레코드들이 전화 번호를 공유하고 레코드들 중 하나가 번호를 휴대폰 또는 직장으로서 식별해주는 것, 레코드들 모두가 집 이메일로서 식별되고 레코드들 모두가 전화기의 소유자로서 식별되지 않는 한, 레코드들이 이메일 주소를 공유하는 것 - 중 하나가 참일 때 연락처가 통합 서비스에 의해 병합된다.
레코드들이 동일한 소스로부터 동기화된 경우 레코드들이 병합되지 않을 수 있다(예컨대, 동일한 이름을 갖는 2명의 Facebook™ 친구는 병합되지 않을 것이다). 주목할 점은, 연락처가 클라이언트 장치(1802) 상에서 생성될 때, 각각의 기록가능 소스에 대해 연락처의 사본이 생성된다는 것이다. 따라서, 동일한 이름을 갖는 전화기 상에서 생성된 2개의 연락처는 서로 병합될 것인데, 그 이유는 제1 연락처의 통합 서비스 버전이 제2 연락처의 버전과 병합될 것이기 때문이다.
연락처 응용 프로그램에서, 사용자는 그룹을 생성하거나 서비스 공급자로부터 그룹을 가져오기할 수 있다. 사용자는 사용자가 보고 있는 일련의 연락처를 필터링하는 것은 물론 그들과 통신(이메일/SMS)하기 위해 이들 그룹을 사용할 것이다.
그룹 멤버쉽 테이블이 연락처의 테이블에 대한 참조를 포함하기 때문에, 소셜 네트워킹 친구는 기술적으로 그룹의 멤버일 수 없다. 통합 서비스는 사용자가 친구를 그룹에 추가할 때 더미 연락처 레코드를 생성함으로써 이 문제를 극복한다. 연락처의 데이터(전화 또는 주소) 중 어느 것도 더미 레코드에 추가되지 않는다.
사람이 2개 이상의 그룹에 속할 수 있다. 새로운 그룹을 생성하고 멤버를 할당할 때, 사용자는 이 그룹과 연락할 때 멤버에 대해 어느 이메일 또는 전화를 사용할지의 옵션을 갖는다. 예를 들어, 각자의 주 전화 또는 이메일을 사용하여 그룹과 연락할 수 있다. 이것은 그룹과 연락하는 기본 방법일 수 있다. 다른 대안으로서, 상이한 이메일 및/또는 전화 또는 모든 이메일 및/또는 전화 번호를 사용하여 그룹과 연락할 수 있다.
그룹을 수정할 때, 사용자는 그룹의 멤버를 변경할 수 있다. 그에 부가하여, 사용자는 또한 그 그룹과 연락할 때 각각의 멤버에 대해 사용될 연락 방법을 변경할 수 있다. 그룹이, 예를 들어, "연락처 보기" 화면에서 필터링될 수 있고, 이 때 사용자는, 예를 들어, 풀다운(pull-down)을 통해 그룹별로 일련의 연락처를 필터링할 수 있다.
사용자는 그룹에 이메일 또는 SMS를 보낼 수 있다. 일 실시예에서, 사용자는 "연락처 보기" 화면으로부터의 메뉴 옵션을 통해 이것을 한다. 이메일 응용 프로그램에서, 사용자는 그룹을 이메일의 수신자로서 선택할 수 있다. 그룹을 선택할 때, 사용자는 각각의 멤버에 대해 사용될 이메일 주소를 일시적으로 오버라이드할 수 있다. 사용자가 오버라이드하지 않는 경우, 각각의 멤버에 대해 사용자가 지정한 기본 이메일이 사용될 것이다. 그렇지만, 주 이메일이 사용될 가능성이 많은데, 그 이유는 대부분의 사용자가 그룹의 각각의 멤버에 대한 명시적인 이메일 주소를 지정하지 않을 것이기 때문이다.
이메일을 그룹으로 전송할 때(또는 어쩌면 이메일을 보낼 그룹을 선택할 때), UI는 그룹의 각각의 멤버가 이메일을 가지고 있고 이메일을 수신할 수 있을 것인지를 나타낼 것이다.
소유자가 각각의 통신 모드를 사용하여 각각의 연락처와 했던 가장 최근의 통신을 추적하기 위해 테이블이 연락처 데이터베이스에 추가될 수 있다. 연락처 응용 프로그램에서, 목록 보기의 최근 탭은 임의의 통신 모드를 사용한 가장 최근의 통신을 말한다. 연락처 상세 보기의 이력 탭은 모든 연락처 통신 방법에 대한 가장 최근의 활동을 열거하고 있다.
Figure pat00039
연락처가 장치(1802)[또는 통합 서비스 서버(1804)] 상에서 생성될 때, 연락처는 기본적으로 모든 기록가능 공급자 그룹에 추가된다. 사용자는 이들 그룹 중 하나를 포함시키지 않기로, 따라서 새로운 연락처를 그 서비스와 동기화시키지 않기로 할 수 있다. 판독 전용 공급자 그룹이 제공되지 않는다. 이 섹션은 "공급자"라고 한다. "판독 전용 연락처"라는 용어는 판독 전용 공급자 그룹에 속하는 연락처 레코드를 의미한다. 이러한 레코드는, 그의 그룹 멤버쉽을 포함하여, 결코 수정될 수 없다. 다른 연락처는 "기록가능"이라고 한다.
다른 연락처 그룹도 역시 사용자에게 제공되지만, 이들은 기본적으로 선택되지 않는다. 이 섹션은 "그룹"이라고 할 수 있다. 새로운 필드가 모든 기록가능 연락처 레코드에 추가된다. 판독 전용 연락처에만 속하는 필드는 편집가능하지 않다. 적어도 하나의 기록가능 연락처에서 발견되는 필드는 편집가능하다. 필드가 편집될 때마다, 레코드가 이전에 필드를 포함하지 않았더라도, 그 필드 데이터가 모든 기록가능 연락처 레코드에 기록된다. 본질적으로, 이것은 사용자의 공급자들 간에 연락처 정보를 서서히 전파시킨다. 판독 전용 및 기록가능 연락처 둘다에 속한 필드가 수정되는 경우, 필드의 이전 값 및 새로운 값 둘다가 이제 디스플레이될 것이다. 이전 값은 더 이상 편집가능하지 않을 것이다.
판독 전용 연락처에 속했던 필드는 삭제되지 않을 수 있다. 기록가능 연락처에 속했던 필드는 삭제될 때 사라진다. 판독 전용 및 기록가능 연락처 둘다에 속했던 필드는 삭제될 수 있지만, 기록가능 연락처로부터만 제거될 것이다. 따라서, 필드가 여전히 상세에 나타날 것이지만, 판독 전용은 아닐 것이다.
사용자가 연락처를 삭제할 때, 확인 대화상자는 연락처가 속하는 모든 기록가능 공급자로부터도 연락처가 삭제되어야 하는지를 묻는다. 대답이 예인 경우, 모든 기록가능 연락처 레코드가 삭제된다. 연락처가 또한 판독 전용 공급자에도 속하는 경우, 대화상자는 연락처가 그 공급자로부터는 삭제되지 않을 수 있다는 것을 경고한다.
공급자 웹 사이트에 추가된 연락처는, 가져오기 프로세스 동안과 같이, 새로운 연락처 레코드를 발생한다. 공급자에 대해 행해진 변경이 통합 서비스에서의 대응하는 연락처 레코드에 반영된다. 연락처가 공급자에서 삭제될 때, 이는 대응하는 연락처 레코드를 그 공급자 그룹으로부터 제거하는 효과를 가진다. 이는 통합 서비스의 연락처로부터 연락처를 삭제하지 않는다. 한 공급자로부터 가져오기된 연락처가 통합 서비스의 UI에서 다른 공급자에 추가될 수 있다. 이것은 연락처를 한 공급자로부터 다른 공급자로 복사하는 효과를 가진다 - 공급자 자체를 통해 쉽게 달성되지 않은 특징임 -. 연락처를 공급자 그룹으로부터 제거하는 것은 그 연락처를 공급자의 주소록으로부터 삭제한다. 사용자가 공급자와 더 이상 동기화하지 않기로 결정하는 경우, 사용자는 그 공급자로부터 가져오기된 모든 연락처 레코드를 제거할지의 질문을 받는다.
장치(1802) 상에서, 푸시 서비스는 푸시 데이터 통지를 수신할 것이다. 푸시 서비스는 모든 데이터 항목에 대한 시퀀스 번호를 조사하고 비순차적으로 된 것이 있는지를 검사한다. 푸시 서비스는, 이러한 시나리오를 검출하는 경우, 이러한 이벤트의 발생을 나타내는 인텐트를 브로드캐스트할 것이다. 인텐트 수신기는 무엇을 하고자 하는지를 결정하도록 요구받을 것이다. 비순차적인 상황의 경우에도 푸시 서비스는 어떤 데이터도 무시하지 않을 것이다. 푸시 서비스는 검출하는 모든 데이터 항목에 대한 인텐트를 계속하여 발생할 것이다.
사용자 인터페이스의 예시적인 부분이 도 23 내지 도 30에 나타내어져 있다. 소셜 네트워킹 상태가 홈 화면(2300)에 존재한다. 이는 사용자가 그의 가장 최근에 업데이트된 상태(2310)를 전화기 또는 소셜 네트워킹 사이트 상에서 볼 수 있게 해주는 것은 물론, 상태 업데이트를 소셜 네트워킹 사이트로 푸시하는 수단도 제공한다. 이는 소셜 네트워킹 경험의 핵심 부분이다. 상태 업데이트는 Facebook™, MySpace™, 및 Twitter™[여기서 트위트(tweet)라고 함]를 비롯한 다수의 소셜 네트워킹 서비스에 포함되어 있다. 사용자는 상태 업데이트를 사용하여 무엇을 하고 있는지, 어디에 가고 있는지, 또는 임의의 다른 "마이크로-블로깅(micro-blogging)" 생각을 그의 친구에게 전달한다.
사용자는 사용자 장치(1802 또는 1803)의 홈 화면(도 23)으로부터 그의 소셜 네트워킹 상태를 업데이트할 수 있다. 그 자신의 상태를 업데이트하기 위해, 사용자는 현재 상태(2310)를 클릭하고, 사용자가 변경을 입력할 수 있는 텍스트 필드가 제시될 것이다.
홈 화면 상태(2310)는 사용자의 통합 서비스 계정에 링크되어 있는 소셜 네트워킹 웹 사이트(예컨대, 예시된 화면에서 Facebook)에서 업데이트된 가장 최근의 상태를 디스플레이할 것이다. 사용자 인터페이스가 홈 화면(2300) 상에 디스플레이된 상태를 갖지 않는 경우, 영역을 탭핑하면 사용자가 상태를 입력할 수 있게 될 것임을 알려주는 텍스트에 의해 공간이 채워질 수 있다. 상태(2310)가 사용자가 속해 있는 하나 이상의 사용자-선택 소셜 네트워크로 푸시될 것이다. 예를 들어, 상태(2310)를 입력하기로 할 때, 사용자 인터페이스는 사용자에게 풀다운 메뉴 - 이로부터 동작이 전송될 콘텐츠 공급자 웹 사이트가 선택될 수 있음 - 를 제시할 것이다. 사용자는 콘텐츠 공급자 웹 사이트들 중 하나 이상을 선택할 수 있다.
친구(2320)의 가장 최근의 상태가 또한 홈 화면에서 예시적인 헤드라인 "사건" 아래에 디스플레이될 수 있다. 도 24는 사용자가 도 23의 사건 헤드라인(2320)을 클릭한 경우의 예시적인 사건 화면(2400)을 나타낸 것이다. 도 24에서 보는 바와 같이, 사건 화면(2400)은 사용자가 주시하고 있는 계정으로부터의 몇개의 상태 업데이트를 포함한다. 도 25는 사용자가 도 24에 나타낸 상태 업데이트들 중 하나의 상태 업데이트를 선택한 후의 예시적인 화면(2500)을 나타낸 것이다. 도 25에서 보는 바와 같이, 사용자는 상태 업데이트에 코멘트를 추가하는 옵션을 제시받는다. 도 26은 사용자가 도 25에 나타낸 상태 업데이트에 코멘트를 추가하기로 선택한 후의 예시적인 화면(2600)을 나타낸 것이다. 도 26에서 보는 바와 같이, 사용자가 코멘트를 입력할 영역(2610)이 제공된다. 화면(2600)은 또한 코멘트를 전송하는 전송 버튼(2620) 및 코멘트를 무시/취소하는 무시 버튼(2630)을 제공할 수 있다. 일 실시예에서, 도 25에 예시된 바와 같이, 사용자가 친구의 이름(2510)을 선택하는 경우, 선택된 친구에 대한 연락처 정보(이용가능한 경우)가 화면에 나올 수 있다. 도 29는 친구 이름이 선택된 후의 친구 연락처 정보를 나타낸 것이다. 도 29에서 보는 바와 같이, 사용자는 사용자의 휴대폰 및 직장 번호, 다양한 콘텐츠 공급 서버(1806 내지 1808) 상의 다수의 이메일 주소 및 친구 계정을 볼 수 있다. 사용자가 도 29에서 아래쪽 화살표(2910)를 선택하는 경우, 도 30에 예시된 바와 같이, 콘텐츠 공급자 서버들(1806 내지 1808) 중 하나의 콘텐츠 공급자 서버에서의 친구 현재 상태(3010)가 모바일 장치(1802) 상에 나타날 수 있다.
앞서 논의된 바와 같이, 장치(1802)의 사용자는 웹 콘텐츠 공급자들(1806 내지 1808) 중 하나에 직접 연결될 수 있다. 도 27은 사용자가 도 25에 나타낸 친구를 선택한 후의 예시적인 화면(2700)을 나타낸 것이다. 도 27에서 보는 바와 같이, 도 25에서 친구 "Tim"을 선택한 후에, 클라이언트 장치(1802)는, 이 예시적인 실시예에서, Tim의 Facebook™ 페이지인 친구 계정으로 바로 간다. 도 28은 웹 콘텐츠 공급자들 중 하나로의 직접 연결이 행해진 다른 화면(2800)을 나타낸 것이다. 도 23에서 보는 바와 같이, 화면(2300)은 그 상태가 어느 서비스에 대한 것인지를 나타내기 위해 적절한 상자 옆에 각각의 서비스의 시각적 표시(로고)(2340)를 포함할 수 있다. 그에 따라, 사용자가 로고(2340)를 선택하는 경우, 도 28에서 보는 바와 같이, 사용자는 대응하는 서비스로 바로 갈 수 있다.
상태 업데이트는 장치에 적시에 도달해야만 한다. 예를 들어, 시간의 90+%인 상태 업데이트가 장치에 의해 설정된 15분 미만 내에 장치 화면에 도달해야만 한다. 환언하면, 사용자가 장치(1802) 사용자 인터페이스 상에서 그의 상태를 설정하고, 이는 콘텐츠 공급자 웹 사이트(1806) 상에서 업데이트되며 15분 미만 내에 통합 서비스에 의해 업데이트된 후에 장치(1802)로 반환된다. 상태가 바람직하게는 사용자가 장치(1802) 상에서 활성인 동안 5분 미만 내에 업데이트될 것이 생각된다.
웹 사이트(1806 내지 1808)(예컨대, Facebook™, MySpace™)로부터 설정된 소거된 상태는 홈 화면 상에 반영되지 않을 수 있다. 홈 화면(2300)은 단지 각각의 서비스로부터의 가장 최근에 설정된 상태를 반영할 것이다. MySpace™는 사용자가 기분 및 상태 둘다를 널로 설정한 경우, 상태가 자동으로 "연장된 네트워크에 있음"으로 설정되는 기존의 기능을 가진다. 이것이 MySpace™가 그의 API를 작동시키는 방식이고 MySpace 사용자가 그에 익숙해져 있기 때문에, 널 상태 및 기분이 서비스로부터 온라인으로부터 또는 장치로부터 설정될 때 이 기능이 계속 행해질 것이다.
MySpace™ 상태 업데이트의 경우(가장 최근의 업데이트가 MySpace™ 웹 사이트로부터 온 것이거나, 장치로부터의 가장 최근의 업데이트가 MySpace™ 전용 업데이트이었음), "기분"이 지원되고 상태와 동시에 디스플레이된다. 홈 페이지 사용자 인터페이스(UI)(2300)는 또한 바람직하게는 마지막 상태 업데이트(2330)의 날짜 및 시간을 포함한다.
사용자가 소셜 네트워킹 계정을 그의 통합 서비스 계정에 링크하지 않은 경우, 소셜 네트워크 상태 영역이 나타나지 않을 것이다. 홈 화면 칩이 SN 상태가 없음으로써 남게 되는 공간의 일부를 차지하기 위해 수직으로 중앙에 재정렬될 것이 생각된다.
앞서 논의된 바와 같이, 사용자는 상태를 업데이트하기 위해 상태(2310)를 선택 또는 클릭하여 사용자를 상태 업데이트 사용자 인터페이스로 안내할 수 있다. UI는 사용자가 그의 웹 서버(1804) 통합 서비스 계정에 링크시킨 모든 소셜 네트워크 상에서의 그의 현재 상태 전부의 목록을 포함한다. 또한 그 상태가 어느 서비스에 대한 것인지를 나타내기 위해 적절한 상자 옆에 각각의 서비스의 시각적 표시(로고)(2340)가 있을 수 있다. 새로운 상태를 입력하기 위한 UI 공간이 백스페이스에 의해 지워질 수 있는 "...이다"로 채워져 있을 수 있다.
MySpace™와 같은 한 서비스가 선택된 유일한 서비스일 때, 상태 및 기분 둘다는 MySpace™ 상에서의 사용자의 현재 상태 및 기분으로 미리 채워져 있다. 이것은 사용자가 상태 또는 기분 중 어느 하나를 우발적으로 지우는 일 없이 단지 상태 또는 기분을 업데이트할 수 있게 해준다. 각각의 개별적인 소셜 네트워킹 사이트 사이트의 상태 텍스트를 (한번에 하나씩) 변경함으로써 각각의 서비스가 개별적으로 업데이트될 수 있다. MySpace™만을 업데이트할 때, UI는 또한 기분을 선택하는 것을 지원한다. 기분을 선택하는 것에 의해 사용자는 기분 목록 내의 특정 지점으로 점프하기 위해 텍스트를 입력할 수 있고(필터링은 아님) 사용자는 목록을 스크롤할 수 있다.
사용자는 모든 서비스를 한꺼번에 업데이트하기 위해 "모두"를 선택하는 옵션을 가질 수 있다. 상태를 업데이트하고 "모든" 서비스를 선택하는 것은 모든 하기 서비스를 새로운 상태 업데이트로 대체한다. 상태는 사용자가 그의 웹 서버(104) 통합 서비스 계정에 링크시킨 모든 소셜 네트워크로 푸시된다. "모든" 서비스를 업데이트하느 것이 MySpace를 포함할 때, 기분은 MySpace에 대해 업데이트할 옵션이 아니고 기분은 기분 없음으로 설정된다.
사용자가 단지 상태를 지원하는 그의 웹 서버(1804) 통합 서비스 계정에 링크된 하나의 서비스를 가지는 경우, 드롭다운 메뉴가 없고 "모두"에 대한 옵션이 없다. 유일한 서비스 링크가 단지 목적지 서비스로서 열거되어 있다. 일 실시예에서, 홈 화면 상의 상태는, 모바일 장치로부터 온 것이든 소셜 네트워킹 서비스로부터 온 것이든 간에, 가장 최근의 업데이트 상태이다. 홈 화면 상의 상태는 그 상태 업데이트가 어디서 온 것인지(예컨대, 모바일 장치, Facebook, Twitter 등)를 식별해주는 어떤 아이콘(2340)을 그 옆에 가져야만 한다. 일 실시예에서, 사용자는 화면(2300)에서 콘텐츠 공급자 아이콘(2340)을 클릭하고 콘텐츠 공급자에의 직접 액세스로 점프할 수 있다.
빈 상태를 전송하는 것은 선택된 특정의 서비스 또는 선택된 경우 모든 서비스로부터의 상태를 지울 수 있다(주목할 점은, Twitter가 상태 소거의 개념을 가지고 있지 않으며, 따라서 이전의 상태가 그대로 있게 될 것이라는 것이다). 응용 프로그램의 마지막 화면/조건이 전화기 상에서의 다른 활동 동안에 저장될 것이고, 사용자는 SN 상태 업데이트 유틸리티에서의 사용자의 활동을 중단시켰던 활동을 완료할 시에(예를 들어, 전화 통화를 수신한 후에) 이 마지막 화면으로 되돌아갈 것이다.
사건 응용 프로그램에서 지원되는 한가지 반응은 Twitter 항목에 대해 @Reply로 응답하는 것이다. 이 결과 새로운 "나(me)" 상태가 코어 서비스로 전송될 것이며, 이것이 홈 화면에 그리고 상태의 목록의 Twitter 라인에(사용자가 지원되는 Twitter 계정을 갖는 경우) 반영될 것이다.
상태가 웹 서버(1804) 통합 서비스 서버로 전송될 때, 상태는 "전송후 비추적(fire and forget)" 방식으로 전송될 수 있고, 이는 동작이 소셜 네트워킹 서비스로 갔다는 어떤 확인도 사용자로 전송되지 않을 것임을 의미한다(그렇지만, UI에 따라, 반응이 장치로부터 전송되었다는 토스트 확인(toast confirmation)이 보여진다). 상태 업데이트는 그의 문자가 허용된 최대 문자를 초과하지 않는 경우에만 포스팅될 수 있을 것이다. 허용된 상태 업데이트의 길이는 상태가 업로드되고 있는 서비스에 따라 다르다. 예를 들어, Facebook™은 현재 160개 문자를 허용하고, MySpace™는 현재 160개 문자를 허용하며, Twitter™는 현재 140개 문자를 허용한다. "모든 서비스"가 선택되는 경우, 최소 공통 분모가 제한값이 될 것이다(예컨대, Twitter™가 포함되는 경우, 최대는 140임).
30개 이하의 문자가 허용될 때 카운트 다운하는 카운터가 디스플레이될 수 있다. 문자의 최대 수가 초과될 때 카운터는 마이너스 숫자를 디스플레이할 수 있다. 사용자가 포스팅의 모드를 전환하는 경우(예를 들어, Twitter에서 Facebook™으로 변경하는 경우), 카운터가 그에 따라 조정될 수 있다(또는 사용자가 타이핑할 문자가 이제 30개 넘게 남아 있는 경우 사라질 수 있다).
카운터가 마이너스일 때 사용자가 "포스팅"을 선택하는 경우, 포스팅이 계속될 수 없다는 것을 나타내고 어느 서비스가 최대값이 초과되었는지를 설명하는 대화상자가 나타난다.
웹 서버(1804) 통합 서비스 사용자 인터페이스는 Facebook™ 페이지의 제한된 이미지를 제공한다. 이는, 예를 들어, 사건(2320)에서, 목록에 친구 사진 및 이름을 보여줄 수 있다. Facebook™ 사진이 Facebook™으로부터 직접 다운로드될 수 있고 장치 상에 연락처로서 유지될 수 있다. 이는 장치가 서버와 동기화될 때 서버 상에 저장될 것이다. 화면의 영역을 클릭하면 이름, 그의 메인 사진, 그의 마지막 상태, 및 그 상태에 관한 임의의 코멘트를 보여준다. 그 사람의 벽에 대한 Facebook™ 모바일 장치에의 직접 액세스 연결을 열기 위해 사람의 이름을 클릭할 수 있다. 다른 대안으로서, (통합 서비스를 통하지 않고) Facebook™ 직접 액세스로 점프하기 위해 Facebook™ 아이콘을 클릭할 수 있다.
앞서 논의된 RSS 피드와 같은 뉴스 피드의 경우, 간략한 코멘트 및 사진이 장치로 푸시될 수 있다. 사진이 간략한 요약과 함께 디스플레이될 것이다. 사용자는 콘텐츠 공급자로부터 부가 정보를 획득하기 위해 기사를 클릭할 수 있다. 이 프로세스는 파일 입력 필드 - 특수 HTML 유형 파일임 - 를 인식하고 포함시킬 사진을 선택하라고 사용자에게 요청함으로써 자동화될 수 있다. 그렇지만, 이것이 업데이트를 하는 데 필요한 단계들을 구성함으로써 추가로 향상될 수 있다. 각각의 소셜 웹 사이트에 대해, 서버는 사용자가 그 사이트 상에서 수행할 수 있는 동작과, 그 동작을 표준 HTTP 연결을 통해 사이트로 어떻게 전송할지를 지정하는 스크립트를 포함할 수 있고, 브라우저는 이어서 이들 동작을 메뉴에서 사용자에게 제시하고, 필요한 입력을 요청하고, 그 전부를 사이트로 전송할 것이다.
코어 웹 서비스는 동기화 프레임워크 및 SNMAIL 응용 프로그램(프로세서 프록시)을 통한 메시지에 대한 동작을 통해 소셜 네트워크 메시징을 지원할 것이다.
도 31은 예시적인 통합 서비스 시스템(3100)에서의 예시적인 메시징 계층을 나타낸 것이다. 상태 업데이트, 사진 업로드, 메시지 및 코멘트와 같은 동작이 장치(3102)로부터 웹 서버 프런트 엔드 부분(3118)으로 전송된다. 포함되는 대상의 아이덴티티 이외에, 동작은 목적지 콘텐츠 공급자 웹 사이트에 독립적인 범용 형식으로 입력된다. 프런트 엔드는 메시지를 전달하고, 백 엔드 프로세서(3116)는 콘텐츠 공급자 웹 사이트에 전용된 플러그인에서의 동작을 처리한다. 예를 들어, 동작이 메시지를 Facebook™ 및 Twitter™로 포스팅하는 것인 경우, 장치의 범용 메시지는 Facebook 플러그인 및 Twitter 플러그인에서 형식 설정된다. 각각의 플러그인은 그 각자의 적절히 형식 설정된 콘텐츠를 Facebook™ 및 Twitter™에 대한 콘텐츠 공급자 웹 사이트로 계속하여 업로드할 것이다.
또한 도 31에 예시된 바와 같이, 백 엔드(3116)에 의해 풀링되고 프런트 엔드(3118)로 전송된 후에, 메시지 및 그의 속성과 동작 상태 코드가 단방향 동기화를 통해 장치로 전송된다. 메시지 및 동작 상태를 업데이트하는 서비스 호출이 동기적 단방향 동기화 호출을 통해 행해질 것이다.
백 엔드(3116)는 소셜 네트워크 자체로의/로부터의 통신을 지원한다. 프런트 엔드(3118) 및 장치(3102)는 연락처와 같은 특정의 정보를 장치와 서버(104) 사이에서 동기화시키는 동기화 엔진을 유지한다.
서버(3104)는 계정 설정 서비스를 통해 공급자 설정을 장치(3102)로 전송할 수 있다. 이것은 단지 단방향(서비스로부터 장치로)이고, 이 작업을 하는 데 동기화를 필요로 하지 않는다. 각각의 공급자에 의해 지원되는 허용된 메시지 속성 및 데이터에 대해 수행될 수 있는 허용된 동작을 포함할 수 있는 메시지에 대한 카테고리는 장치 상에서 생성된다.
웹 서버(3104) 통합 서비스 전화기는 공급자 ID와 메시지 및 동기화 메타 데이터를 지원하는 모든 필드를 포함하는 메시지의 데이터베이스를 유지해야만 한다. 서비스로부터 데이터를 수신하기 위해, 장치는 서비스로부터의 메시지 속성 및 동작 상태의 변경 목록을 처리해야만 한다. 이것은 메시지의 모든 속성을 포함한다. 예를 들어, 변경 목록은 다음과 같은 것들을 포함할 수 있다:
동기화 메시지 변경 목록
<<동기화 메시지 변경 목록 항목 1>>
<<동기화 메시지 변경 목록 항목 2>>
<<동기화 메시지 변경 목록 항목 3>>
...
<<동기화 메시지 변경 목록 항목 n>>
동기화 메시지 변경 목록 항목
Figure pat00040
메시지 속성
Figure pat00041

Figure pat00042
각괄호 내의 항목은 선택적인 것이다. 예를 들어, 모든 공급자가 주제를 지원하는 것은 아니다. '*'를 갖는 데이터 유형은 목록에 1개가 있거나 전혀 없을 수 있는 선택적인 목록이다[예를 들어, Facebook™은 다수의 주소를 지원하는 반면, 다른 것들은 단지 하나만을 지원한다]. mesgGUID는 장치와 서비스 사이에서 공유되는 전역 ID이다. 공급자와 서비스 사이의 ID는 상이한 ID일 수 있다. 모든 공급자가 GUID에 의해 메시지를 참조하는 것을 지원하는 것으로 가정된다.
이 방식에서, 다음과 같이 가정된다: 1. 동작이 WS 호출을 통해 서비스로 전달된다. 동작 형식은 이하에 정의되어 있다. 2. 서버는 동작이 처리를 위해 수락되었다는 것을 말해주는 즉각 OK를 반환하거나, 이 동작을 큐잉할 수 없는 경우 오류를 반환한다. 3. 서버는 (프로세서에서) 이 요청을 비동기적으로 처리하고, 완료될 때, 푸시 관리자를 사용하여 장치로 푸시를 발행한다. 4. 단방향 동기화를 사용하여, 클라이언트는 그의 마지막 서버 앵커에서 GET 요청을 서브밋하고, 이 결과 응답 보디는 동기화 프로토콜에 의해 정의되는 메시지 및 동작 상태를 포함한다(예컨대, HTTP GET to /ws/sync/1/update/{account_id}/{device_id}/{app_id}/ {last_server_anchor}?devkey=android&format=json). 동기화 app_id 필드는 SNMail에 대해 3일 것이다.
장치는 PUSH가 믿을 수 없고, PUSH 응답을 예상한 경우, 타임아웃되어 동작을 다시 재시도해야만 한다는 것을 인식한다. PUSH 채널이 연결해제되었다는 것을 아는 경우(예컨대, 로밍 경우에), 장치는 폴링 기간에서 동작 및 메시지 동기화를 수행해야만 한다. 일 실시예에서, 2개의 타임아웃 조건이 있다: 1. WS 호출을 전송하는 동작이 타임아웃될 수 있고, 2. 푸시가 결코 수신되지 않을 수 있다. 어느 경우든지, 클라이언트 응용 프로그램은 이들 타임아웃을 처리해야만 한다.
상태 테이블은 클라이언트에 유용한 정보를 포함할 수 있다. 일 실시예에서, 1의 상태 코드는 프로세스가 성공적으로 끝났다는 것을 나타내고, 0의 상태 코드는 데이터가 수신되었고 동작이 진행 중이라는 것을 나타내며, -1의 상태 코드는 오류가 발생했다는 것을 나타낼 수 있다. 동작 ID가 서비스 및 장치에 의해 공유될 수 있다. 이것은 서비스가 동작의 상태에 관해 다시 보고할 수 있게 해주는 데 필요할 수 있다(상태 테이블과의 단방향 동기화를 사용하여 장치와 다시 동기화됨). 동기화를 통해 다시 수신된 데이터를 동기화하는 것은 종래의 동기적인 단방향 동기화를 통하며, 동기화 프레임워크에 대한 어떤 변경도 필요하지 않다.
도 32는 일 실시예에 따른 예시적인 프로토콜을 나타낸 것이다. 메시지 동작은 친구 피드와 유사한 프로토콜을 이용하여 SNMail 응용 프로그램으로 전송될 수 있다. 서버는 서버가 처리하고 있는 메시지 ID인 동작의 인수를 필요로 할 수 있다. 예를 들어, SNMAIL 동작 WS 호출은 다음과 같은 형식을 가진다: /ws/snmail/$version/$res/$accountid/$deviceid?<standardparams>(버전 1 SNMAIL 동작 WS API, $res는 동작에 대해 'a'인 자원임)
예시적인 메시지 속성은 다음과 같다:
이름 값
Body 보디 데이터를 갖는 utf8 문자열
Folder Name 폴더 이름을 갖는 utf8 문자열
Subject 주제 데이터를 갖는 utf8 문자열
ReadState 부울(거짓=미판독, 참=판독)
Priority 정수
Flag 정수
AttachURL utf8 문자열
ThreadID Long
MessageID Long
ToMemberIDs 목적지 목록: ["idl", "id2", "id3",...,"id<n>"
ToSmtpAddresses 목적지 이메일 주소 목록: ["address1@mai1.com,...]
동작이 동작 헤더로 시작될 수 있다. 동작 헤더는 다음과 같은 것을 포함할 수 있다:
이름 설명
actionID 이 동작을 식별해주는 Long GUID
actionType 수행할 동작의 유형(이하의 동작 참조)
ProviderName 공급자에 대한 식별자
동작은 다음과 같은 것들 중 하나 이상일 수 있다:
동작 유형 설명 파라미터
sendMsg 주어진 공급자에 대한 새로운 메시지를 전송함 <메시지 속성>
replyMsg 기존의 메시지에 응답함 <메시지 속성>
deleteMsg 메시지를 삭제함 messageID, folderName(MySpace 전용)
deleteThread 스레드를 삭제함 threadID
forwardMsg 메시지를 연락처로 전달함 <메시지 속성>
markReadMsg 판독 상태를 메시지에 대해 판독됨으로서 표시함 messageID, folderName(MySpace 전용)
markUnReadMsg 판독 상태를 메시지에 대해 미판독됨으로서 표시함 messageID, folderName(MySpace 전용)
moveMsg 메시지를 주어진 폴더로 이동함 messageID, folderName
flagMsg 추가 작업을 위해 메시지를 플래깅함 messageID, flag
setPriMsg 메시지 우선순위/중요도를 설정함 messageID,priority
replyThread 기존의 스레드에 응답함 <메시지 속성>
forwardThread 스레드를 전달함 <메시지 속성>
markReadThread 판독 상태를 스레드에 대해 판독됨으로서 표시함 threadID
markUnReadThread 판독 상태를 스레드에 대해 미판독됨으로서 표시함 threadID
moveThread 스레드를 주어진 폴더로 이동함 threadID, folderName
flagThread 추가 작업을 위해 스레드를 플래깅함 threadID, flag
setPriThread 스레드 우선순위/중요도를 설정함 threadID, priority
createFolder 메시지에 대한 저장 폴더를 생성함 folderName
syncMessages 강제로 공급자가 메시지를 획득하게 함(주문형 동기화) 앵커,[한계(획득할 정수 최대 #)]
동작 및 파라미터가 JSON 어레이로서 전송될 수 있고 목록이 JSON 어레이로서 전송될 수 있다. 동작 결과는 서버에 의해 상태 테이블에 저장될 수 있고, 나중에 클라이언트에 의해 동기화된다. 코드 레벨 실시 및 효율을 위해, 동작 유형이 이름보다는 ENUM - 그의 값이 클라이언트와 서버에 의해 공유될 것임 - 으로서 전송될 것이다. syncMessages 동작은 파라미터로서 앵커를 가지는데, 그 이유는 동기화 동작이 백그라운드에서 행해지기 때문이다. 앵커는 장치가 앵커 0를 전송함으로써 그의 메시지를 지웠을 수 있는 경우 프로세서에 알려줄 것이다.
SNMAIL 응용 프로그램은 동기화가 필요할 때 장치로의 푸시를 구현하는 통지 API를 가질 수 있다. 이것은, 예를 들어, URI: /ws/snmail/0/n일 수 있다.
구체적으로는, 본 발명이 본 명세서에 포함된 실시예 및 예시로 제한되지 않고 실시예의 일부분 및 이하의 특허청구범위의 범위 내에 속하는 다른 실시예의 요소들의 조합을 포함하는 그 실시예의 수정된 형태를 포함하는 것으로 보아야 한다.

Claims (1)

  1. 사용자 장치 및 복수의 상이한 콘텐츠 공급자와 통신하도록 구성되어 있는 통합 서비스 서버로서,
    상기 복수의 상이한 콘텐츠 공급자로부터 콘텐츠를 획득하도록 구성되고 또한 상기 획득된 콘텐츠를 상기 사용자 장치로 푸시하도록 구성된 프로세서
    를 포함하는 통합 서비스 서버.
KR1020147008597A 2009-09-10 2010-09-10 콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법 KR20140061482A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US24137009P 2009-09-10 2009-09-10
US61/241,370 2009-09-10
US12/878,705 US20110231478A1 (en) 2009-09-10 2010-09-09 System, Server, and Mobile Device for Content Provider Website Interaction and Method Therefore
US12/878,705 2010-09-09
PCT/US2010/048420 WO2011031962A1 (en) 2009-09-10 2010-09-10 System, server, and mobile device for content provider website interaction and method therefore

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020127009170A Division KR20120063518A (ko) 2009-09-10 2010-09-10 콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법

Publications (1)

Publication Number Publication Date
KR20140061482A true KR20140061482A (ko) 2014-05-21

Family

ID=43014150

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020147008597A KR20140061482A (ko) 2009-09-10 2010-09-10 콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법
KR1020127009170A KR20120063518A (ko) 2009-09-10 2010-09-10 콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020127009170A KR20120063518A (ko) 2009-09-10 2010-09-10 콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법

Country Status (5)

Country Link
US (1) US20110231478A1 (ko)
EP (1) EP2476068A1 (ko)
KR (2) KR20140061482A (ko)
CN (1) CN102498486A (ko)
WO (1) WO2011031962A1 (ko)

Families Citing this family (86)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9213961B2 (en) 2008-09-21 2015-12-15 Oracle International Corporation Systems and methods for generating social index scores for key term analysis and comparisons
US11620660B2 (en) 2009-08-19 2023-04-04 Oracle International Corporation Systems and methods for creating and inserting application media content into social media system displays
US10339541B2 (en) 2009-08-19 2019-07-02 Oracle International Corporation Systems and methods for creating and inserting application media content into social media system displays
US20120109752A1 (en) * 2009-08-19 2012-05-03 Vitrue, Inc. Systems and methods for delivering targeted content to a consumer's mobile device based on the consumer's physical location and social media memberships
US20120011432A1 (en) 2009-08-19 2012-01-12 Vitrue, Inc. Systems and methods for associating social media systems and web pages
US9026581B2 (en) 2009-09-10 2015-05-05 Google Technology Holdings LLC Mobile device and method of operating same to interface content provider website
US8990338B2 (en) 2009-09-10 2015-03-24 Google Technology Holdings LLC Method of exchanging photos with interface content provider website
US9047612B2 (en) 2009-09-11 2015-06-02 Oracle International Corporation Systems and methods for managing content associated with multiple brand categories within a social media system
US9241012B2 (en) * 2010-04-18 2016-01-19 Tropo, Inc. System and method for telephony and communication services with message-based API
US9704165B2 (en) 2010-05-11 2017-07-11 Oracle International Corporation Systems and methods for determining value of social media pages
CN102263799A (zh) * 2010-05-25 2011-11-30 腾讯数码（天津）有限公司 一种sns网络中好友推荐系统和方法
US20110314048A1 (en) * 2010-06-22 2011-12-22 Microsoft Corporation Social network user list detection and searching
TWI418224B (zh) * 2010-06-30 2013-12-01 Htc Corp 自動設定網路推播服務之語言種類的方法、用戶端及伺服器
US9100385B1 (en) * 2010-10-01 2015-08-04 Google Inc. Management and synchronization of electronic media content information
US10474720B2 (en) * 2010-11-30 2019-11-12 Tw Seagull Acquisition Corp. Information feed update mechanism
US9153000B2 (en) * 2010-12-13 2015-10-06 Microsoft Technology Licensing, Llc Presenting content items shared within social networks
US20120158842A1 (en) * 2010-12-20 2012-06-21 Motorola-Mobility, Inc. Method and System for Facilitating Interaction with Multiple Content Provider Websites
US9037656B2 (en) 2010-12-20 2015-05-19 Google Technology Holdings LLC Method and system for facilitating interaction with multiple content provider websites
JP5646771B2 (ja) * 2010-12-21 2014-12-24 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ 電気通信ネットワークにおいてサービス要求をハンドリングするための方法およびシステム。
US9483570B2 (en) * 2010-12-30 2016-11-01 International Business Machines Corporation Driving a user experience of a web application using rules that establish or change requests based on user behavior
US20120213404A1 (en) 2011-02-18 2012-08-23 Google Inc. Automatic event recognition and cross-user photo clustering
US8666984B2 (en) * 2011-03-18 2014-03-04 Microsoft Corporation Unsupervised message clustering
KR101250028B1 (ko) * 2011-04-25 2013-04-03 한국과학기술원 컨텐츠 프로바이더로부터 미디어 컨텐츠를 수집하는 정보 전달 장치 및 방법
US8825842B2 (en) * 2011-04-28 2014-09-02 Facebook, Inc. Managing notifications pushed to user devices
US9529417B2 (en) 2011-04-28 2016-12-27 Facebook, Inc. Performing selected operations using low power-consuming processors on user devices
US9251021B2 (en) 2011-05-23 2016-02-02 Bradley Gene Calder Asynchronous replication in a distributed storage environment
US9161249B1 (en) * 2011-07-07 2015-10-13 Symantec Corporation Systems and methods for performing internet site security analyses
KR20130017264A (ko) * 2011-08-10 2013-02-20 한국전자통신연구원 지능형 사물에 대한 웹 서비스 제공 시스템 및 방법
CN102438033A (zh) * 2011-08-11 2012-05-02 赵冬 手持终端内容配置系统和方法
US8549047B2 (en) 2011-08-25 2013-10-01 Salesforce.Com, Inc. Computer implemented methods and apparatus for feed-based case management
US20130086072A1 (en) * 2011-10-03 2013-04-04 Xerox Corporation Method and system for extracting and classifying geolocation information utilizing electronic social media
CN102355500B (zh) * 2011-10-08 2018-02-13 中兴通讯股份有限公司 业务推送方法和装置
US8560933B2 (en) * 2011-10-20 2013-10-15 Microsoft Corporation Merging and fragmenting graphical objects
US20130132861A1 (en) * 2011-11-22 2013-05-23 Salesforce.Com, Inc. Social media dashboards
JP5887507B2 (ja) * 2011-11-28 2016-03-16 パナソニックＩｐマネジメント株式会社 通信機器間の接続確立方法、通信機器、及びサーバ装置
US20130139067A1 (en) * 2011-11-30 2013-05-30 Jeffrey Andrew Kanter Changing Identities in a Social Networking System
US9081749B2 (en) * 2011-12-12 2015-07-14 Microsoft Technology Licensing, Llc Automatic language sensitive, event based activity feeds
US20180253189A1 (en) * 2011-12-16 2018-09-06 Google Inc. Controlling display of content
US8996069B2 (en) * 2011-12-27 2015-03-31 Vonage Network, Llc Systems and methods for communication notification and handling
US9069648B2 (en) * 2012-01-25 2015-06-30 Martin Kelly Jones Systems and methods for delivering activity based suggestive (ABS) messages
US9009258B2 (en) 2012-03-06 2015-04-14 Google Inc. Providing content to a user across multiple devices
US9881301B2 (en) 2012-04-27 2018-01-30 Google Llc Conversion tracking of a user across multiple devices
US8892685B1 (en) 2012-04-27 2014-11-18 Google Inc. Quality score of content for a user associated with multiple devices
US9258279B1 (en) 2012-04-27 2016-02-09 Google Inc. Bookmarking content for users associated with multiple devices
US9514446B1 (en) 2012-04-27 2016-12-06 Google Inc. Remarketing content to a user associated with multiple devices
US8978158B2 (en) 2012-04-27 2015-03-10 Google Inc. Privacy management across multiple devices
US8966043B2 (en) 2012-04-27 2015-02-24 Google Inc. Frequency capping of content across multiple devices
KR101414844B1 (ko) * 2012-07-23 2014-07-07 한국과학기술원 푸쉬를 사용하여 웹 객체를 이동시키는 방법 및 장치
KR101414900B1 (ko) * 2012-07-23 2014-07-04 한국과학기술원 인텐트에 기반하여 웹 객체를 이동시키는 방법 및 장치
KR101401236B1 (ko) * 2012-07-23 2014-05-30 한국과학기술원 인텐트에 기반하여 이동된 웹 객체를 처리하는 방법 및 장치
CN103685407A (zh) * 2012-09-18 2014-03-26 高德软件有限公司 一种基于云技术的Telematics平台系统
US9710861B2 (en) * 2012-10-15 2017-07-18 At&T Intellectual Property I, L.P. Optimizing social information signaling
KR102026729B1 (ko) * 2012-12-10 2019-09-30 엘지전자 주식회사 스케줄 인터페이스를 처리하는 방법 및 장치
US20140172805A1 (en) * 2012-12-19 2014-06-19 Microsoft Corporation Contact management
US9930139B2 (en) * 2013-01-31 2018-03-27 International Business Machines Corporation Enabling access to user-chosen and/or preferred content via remote trusted third-party systems
CN104022938A (zh) * 2013-02-28 2014-09-03 腾讯科技（深圳）有限公司 消息同步方法、系统、服务器及客户端
US10303802B2 (en) 2013-03-15 2019-05-28 Gadget Software, Inc. System for mobile application search
WO2015042611A1 (en) * 2013-09-23 2015-03-26 Visible World, Inc. Systems and methods for cache-based content delivery
US9729410B2 (en) * 2013-10-24 2017-08-08 Jeffrey T Eschbach Method and system for capturing web content from a web server
KR101508307B1 (ko) * 2013-12-31 2015-04-07 배재대학교 산학협력단 휴대용 단말기 정보 푸쉬 방법 및 시스템
WO2015103773A1 (zh) * 2014-01-10 2015-07-16 华为技术有限公司 一种消息推送方法及装置
US9961131B2 (en) * 2014-04-25 2018-05-01 Microsoft Technology Licensing, Llc Enhanced reliability for client-based web services
US10460098B1 (en) 2014-08-20 2019-10-29 Google Llc Linking devices using encrypted account identifiers
RU2610418C2 (ru) 2014-08-29 2017-02-10 Общество С Ограниченной Ответственностью "Яндекс" Способ координации сетевого обмена данными
US9894154B2 (en) * 2014-10-11 2018-02-13 Papaya Mobile, Inc. Data synchronization methods and systems
US11574621B1 (en) 2014-12-23 2023-02-07 Amazon Technologies, Inc. Stateless third party interactions
KR102252225B1 (ko) * 2015-02-27 2021-05-14 삼성전자주식회사 하나 이상의 통지들을 관리하는 방법 및 이를 위한 전자 장치
GB2536067B (en) * 2015-03-17 2017-02-22 Openwave Mobility Inc Identity management
KR101582620B1 (ko) * 2015-03-27 2016-01-06 주식회사 비주얼다이브 소셜 액티비티 통합 서비스 제공 방법
US20170208354A1 (en) * 2016-01-15 2017-07-20 Hi Pablo Inc System and Method for Video Data Manipulation
US9946638B1 (en) * 2016-03-30 2018-04-17 Open Text Corporation System and method for end to end performance response time measurement based on graphic recognition
US10257163B2 (en) 2016-10-24 2019-04-09 Fisher-Rosemount Systems, Inc. Secured process control communications
US10619760B2 (en) 2016-10-24 2020-04-14 Fisher Controls International Llc Time-series analytics for control valve health assessment
US10530748B2 (en) * 2016-10-24 2020-01-07 Fisher-Rosemount Systems, Inc. Publishing data across a data diode for secured process control communications
US10877465B2 (en) 2016-10-24 2020-12-29 Fisher-Rosemount Systems, Inc. Process device condition and performance monitoring
US10270745B2 (en) 2016-10-24 2019-04-23 Fisher-Rosemount Systems, Inc. Securely transporting data across a data diode for secured process control communications
US10394654B2 (en) * 2017-03-31 2019-08-27 Intel Corporation Method and apparatus for hybrid firmware boot
US10819669B2 (en) * 2017-04-02 2020-10-27 Charles Russell McNeill Unified computing device interface for assembly of a plurality of types of digital content for transmission to a plurality of target destinations
US10193623B2 (en) * 2017-05-09 2019-01-29 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Wireless transmission of server status information
CN110929129B (zh) * 2018-08-31 2023-12-26 阿里巴巴集团控股有限公司 一种信息检测方法、设备及机器可读存储介质
CN109448427A (zh) * 2018-11-09 2019-03-08 易的物联科技无锡有限公司 一种面向各类停车场的智慧停车管理的系统
CN109660606A (zh) * 2018-12-05 2019-04-19 新华三大数据技术有限公司 网络消息代理方法、装置及系统
CN109657179B (zh) * 2018-12-07 2024-04-16 北京奇虎科技有限公司 一种业务处理方法、系统及存储介质
CN113141383B (zh) * 2020-01-18 2023-01-24 佛山市云米电器科技有限公司 设备信息订阅方法、客户端、服务器、系统及存储介质
FR3110312B1 (fr) * 2021-01-13 2023-04-28 Jc Decaux Procédé et système d’affichage digital, dispositif d’affichage digital et serveur d’affichage digital
CN115118773B (zh) * 2022-06-29 2023-08-18 宁波三星智能电气有限公司 数据文件推送方法、服务器和计算机可读存储介质

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6229534B1 (en) * 1998-02-27 2001-05-08 Sabre Inc. Methods and apparatus for accessing information from multiple remote sources
US20020095312A1 (en) * 2000-09-22 2002-07-18 Tammy Wheat Facilitating realtime information interexchange between a telecommunications network and a service provider
US7043231B2 (en) * 2000-09-22 2006-05-09 Ericsson Inc. System, method and apparatus for polling telecommunications nodes for real-time information
US6976010B2 (en) * 2001-06-28 2005-12-13 International Business Machines Corporation Method for syndicating online content
CA2394503A1 (en) * 2001-07-23 2003-01-23 Research In Motion Limited System and method for pushing information to a mobile device
US6757684B2 (en) * 2001-10-01 2004-06-29 Ipac Acquisition Subsidiary I, Llc Network-based photosharing architecture
US7461094B2 (en) * 2003-02-27 2008-12-02 Qurio Holdings, Inc. Photosharing server filters for automatic storage and sharing of digital files
US20060036674A1 (en) * 2004-05-11 2006-02-16 Walden Chris S Broadcasting network and content delivery system
US20060155698A1 (en) * 2004-12-28 2006-07-13 Vayssiere Julien J System and method for accessing RSS feeds
US7720935B2 (en) * 2005-03-29 2010-05-18 Microsoft Corporation Storage aggregator
US20060271384A1 (en) * 2005-05-31 2006-11-30 Microsoft Corporation Reference data aggregate service population
CN101535952B (zh) * 2005-08-19 2014-06-04 谷歌公司 将来自插件模块的信息内容在用户界面中进行显示的软件架构
US20080242370A1 (en) * 2006-03-31 2008-10-02 Ixi Mobile (R&D) Ltd. Efficient server polling system and method
US8843560B2 (en) * 2006-04-28 2014-09-23 Yahoo! Inc. Social networking for mobile devices
US8176058B2 (en) * 2006-11-30 2012-05-08 Yahoo! Inc. Method and systems for managing playlists
US8504711B1 (en) * 2006-12-12 2013-08-06 Google Inc. Integrating web services with a content item
US20080155112A1 (en) * 2006-12-22 2008-06-26 Nokia Corporation System and method for updating information feeds
US8224298B2 (en) * 2007-02-05 2012-07-17 Boadin Technology, LLC Systems and methods for mobile media services utilizing a short form command structure
US20110055209A1 (en) * 2007-02-23 2011-03-03 Anthony Novac System and method for delivering content and advertisments
US20080267218A1 (en) * 2007-04-27 2008-10-30 Liquid Air Lab Gmbh Media proxy for providing compressed files to mobile devices
US8683065B2 (en) * 2007-06-29 2014-03-25 Microsoft Corporation Multicast content provider
US20090119375A1 (en) * 2007-11-05 2009-05-07 Research In Motion Limited Method and system for optimizing delivery of mobile content using differential metadata updates
US7853558B2 (en) * 2007-11-09 2010-12-14 Vibrant Media, Inc. Intelligent augmentation of media content
GB0723553D0 (en) * 2007-11-30 2008-01-09 The Technology Partnership Plc Media providing service
US20090164554A1 (en) * 2007-12-20 2009-06-25 Jeremy Chi Ching Wei Novel system and method to push content from a website to a remote device
US8260864B2 (en) * 2008-02-13 2012-09-04 Microsoft Corporation Push mechanism for efficiently sending aggregated data items to client
US8869256B2 (en) * 2008-10-21 2014-10-21 Yahoo! Inc. Network aggregator
US8468158B2 (en) * 2008-11-06 2013-06-18 Yahoo! Inc. Adaptive weighted crawling of user activity feeds
US20100179915A1 (en) * 2009-01-13 2010-07-15 International Business Machines Corporation Apparatus, system, and method for aggregating a plurality of feeds
US20100211651A1 (en) * 2009-01-18 2010-08-19 Iskoot, Inc. Method and system for multimedia file transfer to a mobile device
US20100299455A1 (en) * 2009-05-21 2010-11-25 Motorola, Inc. Mobile Computing Device and Method with Enhanced Poling Management

Also Published As

Publication number Publication date
WO2011031962A1 (en) 2011-03-17
CN102498486A (zh) 2012-06-13
EP2476068A1 (en) 2012-07-18
KR20120063518A (ko) 2012-06-15
US20110231478A1 (en) 2011-09-22

Similar Documents

Publication Publication Date Title
KR20140061482A (ko) 콘텐츠 공급자 웹 사이트 상호작용을 위한 시스템, 서버 및 모바일 장치와 그 방법
KR101509871B1 (ko) 사진을 로딩하기 위한 방법 및 장치
US8589516B2 (en) Method and system for intermediating content provider website and mobile device
US20110179378A1 (en) Method Generating a Message for One or More Social Networking Websites
US8051057B2 (en) Processing of network content and services for mobile or fixed devices
JP4546744B2 (ja) 電子メールおよびアラート・メッセージを処理する方法、コンピュータプログラム、および、該コンピュータプログラムを有するコンピュータ読取り可能な記録媒体
CA2707536C (en) Processing of network content and services for mobile or fixed devices
KR101580023B1 (ko) 컨텐츠 프로바이더 웹사이트와 모바일 디바이스를 중개하는 방법 및 시스템
US9832148B2 (en) System and method for attaching a remotely stored attachment to an email
CN102625156B (zh) 一种信息同步的方法和系统
US20120158842A1 (en) Method and System for Facilitating Interaction with Multiple Content Provider Websites
US9037656B2 (en) Method and system for facilitating interaction with multiple content provider websites
US20140324816A1 (en) Extended web search infrastructure supporting hosting client device status
WO2011031569A1 (en) Mobile device and method of operating same to interface content provider website
WO2007012657A1 (fr) Systeme d&#39;echange de donnees informationnelles specifiques entre deux sites web, procede et programme d&#39;ordinateur correspondants

Legal Events

Date Code Title Description
A107 Divisional application of patent