KR101283293B1 - 트랜잭션 기반 통신을 위한 파일 프로토콜 - Google Patents

트랜잭션 기반 통신을 위한 파일 프로토콜 Download PDF

Info

Publication number
KR101283293B1
KR101283293B1 KR1020127016789A KR20127016789A KR101283293B1 KR 101283293 B1 KR101283293 B1 KR 101283293B1 KR 1020127016789 A KR1020127016789 A KR 1020127016789A KR 20127016789 A KR20127016789 A KR 20127016789A KR 101283293 B1 KR101283293 B1 KR 101283293B1
Authority
KR
South Korea
Prior art keywords
data
packets
file
interface
packet
Prior art date
Application number
KR1020127016789A
Other languages
English (en)
Other versions
KR20120085341A (ko
Inventor
커티스 씨. 갈로웨이
존 앤드류 라이트
조슈아 버웨이스트 그래슬리
씬 기스
폴 친
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
Priority claimed from US11/760,686 external-priority patent/US20080307102A1/en
Application filed by 애플 인크. filed Critical 애플 인크.
Publication of KR20120085341A publication Critical patent/KR20120085341A/ko
Application granted granted Critical
Publication of KR101283293B1 publication Critical patent/KR101283293B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5603—Access techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Abstract

트랜잭션 기반 통신을 위한 파일 프로토콜에 대해 기술한다. 일 실시예에서, 파일 전송 프로토콜을 제공하는 방법은 헤더를 포함하는 패킷을 수신하는 단계 - 상기 패킷이 인터페이스를 통해 제1 네트워크 스택 소프트웨어에서 수신됨 -, 상기 패킷으로부터 데이터를 추출하는 단계, 및 상기 패킷 내의 데이터로부터 파일을 재구성하는 단계를 포함한다. 상기 추출하는 단계는 제1 네트워크 스택 소프트웨어에 의해 수행될 수 있고, 상기 인터페이스는 IP(Internet Protocol) 주소를 사용하도록 설계되어 있지 않으며, 상기 헤더는 흐름 제어 및 시퀀스를 위한 데이터를 포함하고 파일 전송 애플리케이션에 대한 포트와 연관되어 있으며, 상기 헤더는 다수의 애플리케이션이 USB 호환 또는 BLUETOOTH 호환 인터페이스일 수 있는 인터페이스를 통해 다중 동시 세션을 유지할 수 있게 해준다. 시스템, 컴퓨터 판독가능 매체, 소프트웨어 아키텍처 및 기타 방법들에 대해서도 기술되어 있다.

Description

트랜잭션 기반 통신을 위한 파일 프로토콜{FILE PROTOCOL FOR TRANSACTION BASED COMMUNICATION}
본 출원은 2007년 6월 22일자로 출원된, 발명의 명칭이 "Multiplexed Data Stream Protocol(멀티플렉싱된 데이터 스트림 프로토콜)"인 미국 가특허 출원 제60/945,904호의 출원일을 기초로 우선권을 주장한다. 이 가특허 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다. 본 출원은 2007년 6월 8일자로 출원된, 발명의 명칭이 "Techniques for Communicating Data Between a Host Device and An Intermittently Attached Mobile Device(호스트 장치와 간헐적으로 접속되는 장치 간의 데이터 통신 기법)"인 미국 특허 출원 제11/760,686호의 일부 계속 출원이다.
본 발명의 실시예들은 장치들 간의 데이터 통신에 관한 것이다. 보다 상세하게는, 본 발명의 실시예들은 하나 이상의 호스트 전자 장치들과, 간헐적으로 연결되는 클라이언트 장치 간의 효율적인 데이터 통신 기법에 관한 것이다.
모바일 장치(예를 들어, 이동 전화, 디지털 음악 플레이어, PDA)가 점점 보편화됨에 따라, 하나의 모바일 장치에 의해 제공되는 기능이 증가하였다. 이러한 기능의 증가는, 예를 들어, 모바일 장치 또는 호스트 장치 중 어느 하나에서 행해진 데이터의 변경을 미러링하기 위해 동기화 서비스를 제공하기 위한 동기를 일으키는 것과 연관되어 있다. 게다가, 2개의 장치 간에 하나 이상의 파일을 비롯한 데이터를 교환할 필요가 있을 수 있다. 예를 들어, 2개의 장치 간에 음악 또는 비디오 파일이 교환될 수 있다.
모바일 장치와 호스트 장치 간에 데이터를 동기화시키고 및/또는 데이터를 교환하는 다양한 기법들이 개발되었다. 현재의 기법들은 통상적으로 필요 이상으로 많은 오버헤드를 요구할 수 있는 전기능 파일 시스템(full-function file system) 기반 기법이거나 제한된 기능을 제공하는 특수-목적 기법일 수 있다. 이들 기법은 USB 등의 기존의 인터페이스를 사용한다.
각각의 장치 상의 USB 인터페이스와 같은, 장치들 간의 기존의 인터페이스는 장치가 USB(Universal Serial Bus) 인터페이스 또는 포트에 접속되고 그 다음에 임의적으로 갑자기 USB 인터페이스로부터 제거/분리될 수 있게 해주는 데 어려움이 있으며, 그 장치가 저장 장치인 경우에 특히 그렇다. 게다가, USB는, USB의 표준 통신 프로토콜에서, IP(Internet Protocol) 주소를 지원하도록 설계되어 있지 않으며, USB는 네트워크 인터페이스로 간주되지 않는다. USB는 또한 USB 인터페이스를 통해 데이터를 전송하려고 시도하거나 데이터를 수신하기 위해 대기하고 있는 독립적인 애플리케이션들을 위한 실제상 제한이 없는, 임의의 수의 다중 동시 독립 세션(multiple concurrent independent session)을 지원하도록 설계되어 있지 않으며, 적어도 어떤 시스템들의 경우, USB 인터페이스를 통해 지원되는 인터페이스 또는 세션의 수가 정적이고 시간에 따라 변경될 수 없다. USB 인터페이스가, 적어도 어떤 시스템들의 경우, 다중 세션(multiple session)으로 간주될 수 있는 다중 동시 "인터페이스"를 지원할 수 있지만, 이들의 수가 고정되어 있을 뿐이고 인터페이스가 장치에 대해 정적이다(변화될 수 없다). 반면에, USB는 보편화된 유용한 인터페이스이며, 이러한 인터페이스를 사용하여 호스트 및 클라이언트 장치 등의 2개의 시스템을 연결시키는 것이 종종 바람직하다.
본 설명은 트랜잭션 기반 통신을 위한 파일 프로토콜(예를 들어, 파일 전송 프로토콜)에 관한 것이다. 일 실시예에서, 파일 전송 프로토콜을 사용하는 방법은 헤더를 포함하는 패킷을 수신하는 단계 - 상기 패킷이 USB 인터페이스와 같은 비네트워크 인터페이스를 통해 제1 네트워크 스택 소프트웨어에서 수신됨 -, 상기 패킷으로부터 데이터를 추출하는 단계, 및 상기 패킷 내의 데이터로부터 파일을 재구성하는 단계를 포함한다. 상기 추출하는 단계는 제1 네트워크 스택 소프트웨어에 의해 수행될 수 있고, 상기 헤더는 흐름 제어 및 시퀀싱을 위한 데이터 및 파일 전송 애플리케이션을 전송 및 수신하는 포트를 식별해주는 데이터를 포함하며, 상기 헤더 내의 데이터는 파일 전송 애플리케이션 및 기타 애플리케이션을 비롯한 다수의 독립적인 애플리케이션이 인터페이스(USB 호환(유선 또는 무선) 또는 BLUETOOTH 호환 인터페이스일 수 있음)를 통해 다중 동시 세션을 유지할 수 있게 해준다. 본 방법은 또한 파일의 모든 데이터가 수신된 후에 파일의 유효성을 검사하는 단계를 포함할 수 있고, 이 유효성 검사 단계는 전체 파일에 대해 체크섬 및/또는 해쉬 함수를 사용하여 수행될 수 있다. 파일의 일부분을 포함하는 패킷은 미리 정해진 패킷 포맷을 갖는 패킷 유형 및 이 패킷 유형과 연관된 패킷 기능의 표시를 포함할 수 있다.
인터페이스는 IP(Internet Protocol) 주소를 사용하지 않는 표준 프로토콜을 갖는 USB 유선 또는 무선 인터페이스(또는 BLUETOOTH 무선 인터페이스)일 수 있다. 비네트워크 인터페이스를 통해 전송되는 패킷은 TCP(Transmission Control Protocol)-유사 헤더를 포함할 수 있고 또 IP 호환 헤더를 포함하지 않을 수 있으며, TCP-유사 헤더는 소프트웨어 모듈들 간의 프로세스간 통신을 위한 소켓 API를 사용하여 열려진 열린 소켓과 연관되어 있는 포트 식별자를 지정할 수 있다. 본 방법은 또한 상기 패킷으로부터 추출된 데이터를 포함하는 추가의 패킷을 생성하는 단계를 포함할 수 있고, 추가의 패킷은 IP 헤더가 루프백 주소를 지정하는 TCP/IP 헤더를 포함하고 있으며, 데이터가 추가의 패킷으로부터 추출되고 파일 전송 애플리케이션에 제공된다. 추가의 패킷을 생성하는 단계 및 추가의 패킷으로부터 데이터를 추출하는 단계는 IP 프로토콜을 통해 인터넷에 연결하는 네트워크 인터페이스에 결합되어 동작하는 TCP/IP 스택 소프트웨어에 의해 수행될 수 있다.
다른 실시예는 데이터 처리 시스템에서 실행되도록 구성된 실행가능 프로그램 명령어들을 포함하는 컴퓨터 판독가능 매체를 포함한다. 이 매체는 장치 상의 제1 인터페이스(WiFi, 이더넷 또는 셀룰러 전화 인터페이스 등)를 통해 전송하기 위한 패킷을 생성하고 제1 인터페이스를 통해 수신된 패킷으로부터 데이터를 추출하는 제1 네트워크 스택 소프트웨어, 장치 상의 제2 인터페이스(USB 또는 BLUETOOTH 인터페이스와 같은 비네트워크 인터페이스일 수 있음)를 통해 전송하기 위한 패킷을 생성하고 제2 인터페이스를 통해 수신된 패킷으로부터 데이터를 추출하는 제2 네트워크 스택 소프트웨어, 및 제2 인터페이스를 통해 수신된 패킷으로부터 추출된 데이터를 수신하기 위해 제1 네트워크 스택 소프트웨어와 통신하고 또 패킷으로부터 추출된 데이터로부터 파일을 재구성하기 위해 결합되어 동작하는 파일 전송 프로토콜 소프트웨어(한 장치로부터 다른 장치로 미디어 파일을 전송하도록 구성되어 있는 미디어 플레이어 등)를 포함한다. 제2 네트워크 스택 소프트웨어는 제1 네트워크 스택 소프트웨어와 통신을 하도록 구성되어 있고, 제2 인터페이스는 다른 시스템(예를 들어, 호스트 장치) 상의 제3 인터페이스(예를 들어, USB 또는 BLUETOOTH 인터페이스와 같은 다른 비네트워크 인터페이스)와 결합되도록 구성되어 있다. 제2 네트워크 스택 소프트웨어는 제2 인터페이스를 통해 수신된 패킷으로부터 추출된 데이터를, 제1 네트워크 스택 소프트웨어를 통해, 수신측 파일 전송 프로토콜 애플리케이션으로 전송하도록 구성되어 있다. 제2 네트워크 스택 소프트웨어는 제2 인터페이스에 대해 설계된 프로토콜을 사용하여 패킷을 전송 및 수신하도록 구성되어 있다. 파일 전송 프로토콜 소프트웨어는 파일의 모든 데이터가 수신된 후에 파일의 유효성을 검사할 수 있고(또는 데이터가 수신되고 있을 때 파일을 일부분씩 유효성 검사할 수 있고), 이 유효성 검사가, 예를 들어, 종래의 체크섬 연산(checksum operation) 또는 해쉬 연산(hash operation)을 사용하여 수행될 수 있다. 패킷은 파일 전송 프로토콜의 일부인 정보를 포함할 수 있다. 예를 들어, 패킷은 미리 정해진 패킷 포맷을 갖는 패킷 유형 및 이 패킷 유형과 연관된 패킷 기능의 표시를 포함할 수 있다. 패킷 기능은 파일 전송 프로토콜 소프트웨어의 동작을 지정할 수 있다. 제2 네트워크 스택 소프트웨어에 의해 생성된 패킷은 TCP(Transmission Control Protocol)-유사 헤더를 포함할 수 있고 또 IP 헤더를 포함하지 않을 수 있으며, TCP-유사 헤더는 파일 전송 프로토콜 소프트웨어에 대한 열린 소켓과 (헤더 내의 포트 식별자를 통해) 연관되어 있을 수 있다. 제1 네트워크 스택 소프트웨어 및 제2 네트워크 스택 소프트웨어는 장치 상의 다수의 애플리케이션(제1 전송 프로토콜 소프트웨어를 포함함)이 제2 인터페이스를 통해 다중 동시 세션을 유지할 수 있게 해주도록 구성되어 있고, 파일은 오디오 또는 오디오 비쥬얼 미디어 파일이다. 제1 네트워크 스택 소프트웨어는 TCP/IP 스택을 포함할 수 있고, 제2 네트워크 스택 소프트웨어는 TCP-유사 헤더를 생성하는 TCP-유사 스택을 포함할 수 있다. 파일 전송 프로토콜 소프트웨어(또는 기타 소프트웨어)는 전체 파일의 전송의 실패에 응답하여 오류 메시지 또는 상태 메시지를 발생할 수 있고(예를 들어, USB 연결이 파일 전송 도중에 중단됨), 이 메시지는 나중에 연결이 재설정될 때 파일이 전체적으로 또는 부분적으로(이전에 전송된 부분이 수신자측에 성공적으로 저장되어 있는 경우) 전송되게 하는 데 사용된다. 오류 메시지 또는 상태 메시지는 적어도 연결이 중단되기 전에 부분적으로만 전송되었던 파일의 식별자를 포함한다.
본 명세서는 또한 장치, 시스템, 컴퓨터 판독가능 매체, 소프트웨어 아키텍처, 및 기타 방법에 대해서도 기술하고 있다.
다른 실시예에서, 장치들 간의(예를 들어, 호스트와 장치 간의) 통신 링크는 USB(Universal Serial Bus) 호환 유선 또는 무선 인터페이스이다. 다른 실시예에서, 장치들 간의 통신 링크는 BLUETOOTH 호환 무선 인터페이스이다. 다른 실시예에서, 통신 링크는 네트워크 인터페이스가 아닌 인터페이스이다.
일 실시예에서, 클라이언트 장치는 스마트폰이다. 다른 실시예에서, 클라이언트 장치는 미디어 플레이어 장치이다. 일 실시예에서, 호스트 장치는 데스크톱 컴퓨터 시스템이다. 다른 실시예에서, 호스트 장치는 랩톱 컴퓨터 시스템이다. 다른 실시예에서, 호스트 장치는 팜톱 또는 울트라-모바일(ultra-mobile) 컴퓨터 시스템이다.
트랜잭션 기반 통신을 위한 파일 프로토콜이 제공된다.
유사한 참조 번호가 유사한 구성요소를 지칭하고 있는 첨부 도면의 도면들에, 본 발명이 제한이 아닌 예로서 도시되어 있다.
도 1은 본 명세서에 기술된 기법들을 이용하여 통신을 할 수 있는 호스트 전자 장치 및 클라이언트 전자 장치의 블록도.
도 2는 호스트 장치 등의 데이터 처리 시스템의 일 실시예의 블록도.
도 3은 클라이언트 장치, 핸드헬드 컴퓨터, 또는 기타 유형의 데이터 처리 시스템 등의 데이터 처리 시스템의 일 실시예의 블록도.
도 4는 호스트 전자 장치와 클라이언트 전자 장치 간의 통신에서 사용될 수 있는 패킷 헤더의 표를 나타낸 도면.
도 5는 호스트 전자 장치와 클라이언트 전자 장치 간의 통신에서 사용될 수 있는 패킷 유형의 표를 나타낸 도면.
도 6은 클라이언트 장치로 데이터를 전송하는 기법의 일 실시예의 흐름도.
도 7은 호스트 장치와 클라이언트 장치 간에 데이터를 동기화시키는 기법의 일 실시예의 흐름도.
도 8은 호스트 및 장치라고 하는 2개의 데이터 처리 시스템을 연결시키는 소프트웨어 아키텍처의 일례를 나타낸 도면.
도 9는 본 발명의 일 실시예에 따른, 2개의 시스템 간에 데이터를 교환하는 방법의 일례를 나타낸 플로우차트로서, 여기서 데이터는 파일(예를 들어, MP3 파일, 비디오 파일, 사진, 기타) 또는 구조화된 데이터(주소록에 있는 연락처, 북마크/즐겨찾기, 일정표 데이터, 메모, 또는 할 일 항목, 기타 등등) 또는 기타 유형의 데이터(예를 들어, 위젯 등의 실행가능 소프트웨어, 기타)일 수 있음.
도 10은 본 발명의 일 실시예에 따른 초기화 방법의 플로우차트.
도 11은 일 실시예에 따른, 호스트로부터 장치로 데이터를 전송하는 방법의 일례를 나타낸 플로우차트.
도 12는 일 실시예에 따른, 장치로부터 호스트로 데이터를 전송하는 방법의 일례를 나타낸 플로우차트.
도 13은 호스트 시스템에 대한 대안의 소프트웨어 아키텍처의 일례를 나타낸 도면.
도 14a는 PTP(Picture Transfer Protocol)를 사용하는 2개의 USB 인터페이스를 통한 연결의 종래 기술의 일례를 나타낸 도면.
도 14b는 본 발명의 일 실시예에 따른 연결의 일례를 나타낸 도면.
도 15는 일 실시예에 따른, 시스템들 간에 파일을 교환하는 방법의 일례를 나타낸 플로우차트.
이하의 설명에는, 많은 구체적인 상세가 기재되어 있다. 그렇지만, 본 발명의 실시예들은 이들 구체적인 상세 없이도 실시될 수 있다. 다른 경우에, 본 설명의 이해를 모호하게 하지 않기 위해 공지의 회로, 구조 및 기법에 대해서는 상세히 설명하지 않고 있다.
본 명세서에는 종단점들 간에 파일 및 기타 데이터를 전송하는 프로토콜이 기술되어 있다. 일 실시예에서, 종단점들은 호스트 전자 장치 및 클라이언트 전자 장치이다. 호스트 전자 장치는, 예를 들어, 데스크톱 컴퓨터 시스템 또는 랩톱 컴퓨터 시스템일 수 있다. 클라이언트 전자 장치는, 예를 들어, 랩톱 컴퓨터 시스템, PDA(personal digital assistant), 셀룰러-기반 장치(예를 들어, 셀룰러 전화 또는 스마트폰)일 수 있다.
일 실시예에서, 종단점들 간의 연결은 신뢰성있는 스트림 전송, 예를 들어, TCP(Transmission Control Protocol) 스트림 연결을 이용한다. 다른 스트림 연결들도 역시 지원될 수 있다. 일 실시예에서, 헤더 및 보디를 갖는 패킷을 이용하여 통신이 달성된다. 본 명세서에 표준의 최소 헤더의 일 실시예가 기술되어 있지만, 헤더가 부가의 패킷-관련 구조화된 데이터를 포함할 수 있다. 패킷 데이터가 비구조화된 데이터를 포함할 수 있거나, 비어 있을 수 있다.
도 1은 본 명세서에 기술된 기법들을 이용하여 통신을 할 수 있는 호스트 전자 장치 및 클라이언트 전자 장치의 블록도이다. 도 1의 블록도는 호스트 장치(100)와 클라이언트 장치(150) 간에 통신을 하는 데 이용될 수 있는 컴포넌트들의 개념적 도해를 제공한다. 일례에서, 호스트 장치(100)는 컴퓨터 시스템(예를 들어, 데스크톱 또는 랩톱 컴퓨터 시스템)이고, 클라이언트 장치(150)는 모바일 장치(예를 들어, PDA 또는 스마트폰)이다. 호스트 장치(100) 및 클라이언트 장치(150)는 공지된 임의의 유형의 통신 기법을 통해 통신을 할 수 있다. 예를 들어, 통신 링크(145)는 물리 케이블(예를 들어, USB(Universal Serial Bus) 호환 케이블) 또는 무선 통신 링크(예를 들어, 블루투스
Figure 112012051627367-pat00001
호환 또는 IEEE 802.11 호환)일 수 있다. 블루투스
Figure 112012051627367-pat00002
는 Bluetooth SIG, Inc. 소유의 등록 상표이다.
애플리케이션(110)은 호스트 장치(100)에 의해 실행될 수 있는 임의의 유형의 애플리케이션일 수 있다. 예를 들어, 애플리케이션(110)은 미국 캘리포니아주 쿠퍼티노 소재의 Apple Inc.로부터 입수가능한 iTunes일 수 있다. 애플리케이션(110)은 클라이언트 장치(150)로 전달될 수 있는 및/또는 클라이언트 장치(150)와 동기화될 수 있는 기능 및/또는 데이터를 포함할 수 있다. 예를 들어, 애플리케이션(110)은 클라이언트 장치(150)에 저장되거나 클라이언트 장치(150)에 의해 재생될 수 있는 멀티미디어 컨텐츠를 저장 및/또는 재생할 수 있다. 클라이언트 장치(150)가 호스트 장치(100)와 통신을 할 때, 애플리케이션(110)은 컨텐츠가 호스트 장치(100)와 클라이언트 장치(150) 간에 전송되게 할 수 있다. 다른 유형의 애플리케이션들도 역시 지원될 수 있다.
게이트키퍼 클라이언트(115)는 애플리케이션(110)이 통신 링크(145)에 접속하는 것을 제어하기 위해 애플리케이션(110)과 상호작용한다. 게이트키퍼 클라이언트(115)는 하나 이상의 파라미터에 기초하여 통신 링크(145)에의 접속을 선택적으로 제한할 수 있다. 게이트키퍼 클라이언트(115)는 호스트 장치(100)와 클라이언트 장치(150) 간의 통신을 가능하게 해주기 전에, 예를 들어, 인증 및/또는 유효성 검사 동작을 수행할 수 있다. 게이트키퍼 클라이언트(115)는 또한 호스트 장치(100)와 클라이언트 장치(150) 간의 통신을 위한 다수의 통신 링크들 중 하나를 선택할 수 있다. 도 1의 예가 게이트키퍼 기능을 갖는 경우에 대해 기술되어 있지만, 대안의 실시예들은 게이트키퍼 기능 없이 제공될 수 있다. 게이트키퍼 클라이언트(115) 및 게이트키퍼(180)에 관한 추가의 정보가 2007년 6월 22일자로 출원된 미국 특허 출원 제11/767,447호(대리인 문서 번호 18962-113001/P5408US1)에 제공되어 있으며, 이 미국 특허 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.
게이트키퍼 클라이언트(115)는 링크 인터페이스(140)를 통해 통신 링크(145)에 접속하기 위해 링크 드라이버(link driver)(130)와 통신을 할 수 있다. 일 실시예에서, 링크 드라이버(130)는 호스트 장치(100)와 클라이언트 장치(150) 간의 동기화 기능을 제공하기 위해 구조화된 동기 서비스(structured sync service)(120)와 상호작용한다. 일 실시예에서, 구조화된 동기 서비스(120)는 이하에서 더 상세히 기술되는 명령 및 프로토콜을 이용하여 기능할 수 있다. 링크 드라이버(130)는 링크 서비스(140)로 하여금 데이터를 나타내는 신호(예를 들어, 전기 신호, RF 신호, 적외선 신호, 광 신호)를 통신 링크(145)를 통해 전송하게 할 수 있다.
클라이언트 장치(150) 내에서, 링크 인터페이스(160)는 링크 인터페이스(140)에 대응하는 것이다. 링크 인터페이스(160)는 통신 링크(145)를 통해 신호(예를 들어, 전기 신호, RF 신호, 적외선 신호, 광 신호)를 전송 및/또는 수신할 수 있다. 클라이언트 장치(150)는 또한, 호스트 장치(100) 상의 애플리케이션(110)과 클라이언트 장치(150) 상의 미디어 동기 서비스(190) 간의 통신을 가능하게 해주기 전에, 인증, 유효성 검사 및/또는 기타 허가 기능들을 수행할 수 있는 게이트키퍼(180)를 포함하고 있다.
일 실시예에서, 미디어 동기 서비스(190)는 데이터(195)에의 액세스(예를 들어, 읽기, 쓰기, 수정, 업데이트)를 가능하게 해주기 위해 이하에서 더 상세히 기술되는 메시지 및 프로토콜을 지원할 수 있다. 데이터(195)는 클라이언트 장치(150) 상에 저장된 임의의 유형의 데이터를 나타낸다. 데이터(195)는 하나 이상의 데이터베이스, 표 및/또는 기타 저장 요소(storage element)일 수 있다. 데이터(195)는, 예를 들어, 미디어 파일(예를 들어, 오디오 및/또는 비디오 데이터 파일), 메타데이터, 연락처 정보, 이력 정보(예를 들어, 호 로그, 소프트웨어 버전 정보), 및/또는 상태 정보(예를 들어, 배터리 용량, 일련 번호, 총 메모리, 가용 메모리)일 수 있다.
클라이언트 장치(150)는 또한 클라이언트 장치(150) 상에 데이터를 유지할 수 있는 구조화된 데이터 서비스(185)를 포함할 수 있다. 구조화된 동기 서비스(120) 및 구조화된 데이터 서비스(185)를 이용하여 동기화 및/또는 유지될 수 있는 데이터의 일례로는 북마크, 연락처 정보, 일정표 정보, 기타 등등이 있을 수 있다. 구조화된 동기 서비스(120)는 동기화 소프트웨어(805)(도 8)와 동일하거나 그와 유사할 수 있으며, 구조화된 동기 서비스(185)는 동기 소프트웨어(835)(도 8)와 동일하거나 그와 유사할 수 있다.
일 실시예에서, 애플리케이션(110)이 데이터(190)에 액세스할 수 있게 해주기 위한 호스트 장치(100)와 클라이언트 장치(150) 간의 통신은 이하에서 더 상세히 기술되는 특정의 데이터 패킷 포맷을 이용하여 구조화된 동기 서비스(120) 및 미디어 동기 서비스(190)를 통해 달성될 수 있다. 일 실시예에서, 통신 링크(145)는 호스트 장치(100)와 클라이언트 장치(150) 간의 USB(Universal Serial Bus) 호환 유선 통신 링크일 수 있다. 일 실시예에서, 호스트 장치(100)와 클라이언트 장치(150) 간의 연결은 USB 호환 물리 연결 상부의 TCP 스트림 연결(TCP stream connection over the USB compliant physical connection)을 이용하여 이하에 기술되는 패킷을 전송한다.
도 2는 호스트 장치 등의 데이터 처리 시스템의 일 실시예의 블록도이다. 유의할 점은, 도 2가 컴퓨터 시스템의 다양한 컴포넌트들을 도시하고 있지만, 이러한 상세가 본 발명과 밀접한 관련은 없기 때문에 도 2가 이들 컴포넌트를 상호연결시키는 임의의 특정의 아키텍처 또는 방식을 나타내기 위한 것이 아니라는 것이다. 또한, PDA(personal digital assistant), 셀룰러 전화, 미디어 플레이어(예를 들어, iPod), 이들 장치의 측면들 또는 기능들을 겸비하는 장치(하나의 장치에 PDA 및 셀룰러 전화를 겸비한 미디어 플레이어), 네트워크 컴퓨터, 다른 장치 내에 내장된 처리 장치, 및 더 적은 컴포넌트 또는 어쩌면 더 많은 컴포넌트를 갖는 기타 데이터 처리 시스템이 또한 본 발명의 하나 이상의 실시예를 구현하는 데 사용될 수 있고 또 본 명세서에 기술된 데이터 처리 시스템들 중 하나 이상일 수 있다는 것을 잘 알 것이다. 도 2에 도시된 컴퓨터 시스템은, 예를 들어, Apple Inc.의 Macintosh 컴퓨터이거나 Microsoft Corporation의 Windows 운영 소프트웨어를 실행하는 컴퓨터일 수 있다.
컴퓨터 시스템(200)은 처리 시스템(210)을 구성하는 하나 이상의 마이크로프로세서에 결합된 버스(205)를 포함한다. 버스(205)는 또한 메모리(220) 및 비휘발성 메모리(230)(어떤 실시예들에서 자기 하드 드라이브이거나 다른 실시예들에서 플래쉬 메모리일 수 있음)에도 결합되어 있다. 버스(205)는 또한 디스플레이 제어기 및 디스플레이(240)와 하나 이상의 입/출력(I/O) 장치(250)에도 결합되어 있다.
게다가, 버스(205)는 선택적인 도크(260)와 하나 이상의 무선 송수신기(270)(블루투스
Figure 112012051627367-pat00003
호환 송수신기 또는 WiFi 호환 송수신기 또는 적외선 송수신기일 수 있음)에도 결합되어 있을 수 있다. 무선 송수신기(270)는 도 2에 도시된 바와 같이 선택적이다.
처리 시스템(210)은 선택적으로 캐쉬(215)에 결합되어 있을 수 있다. 처리 시스템(210)은 Intel 또는 IBM의 마이크로프로세서 등의 하나 이상의 마이크로프로세서를 포함할 수 있다. 버스(205)는 공지된 방식으로 이들 다양한 컴포넌트를 서로 상호연결시킨다. 통상적으로, 입/출력 장치(250)는 입/출력 제어기를 통해 시스템에 결합되어 있다.
메모리(220)는 데이터에의 고속 액세스를 제공하지만 메모리(220) 내의 데이터를 리프레쉬 또는 유지하기 위해 계속하여 전원을 필요로 하는 동적 RAM(DRAM)으로서 구현될 수 있다. 비휘발성 메모리(230)는 시스템으로부터 전원이 제거된 후에도 데이터를 보유하는 자기 하드 드라이브 또는 기타 비휘발성 메모리일 수 있다. 도 2에서 비휘발성 메모리(230)가 데이터 처리 시스템 내의 나머지 컴포넌트들에 직접 결합되어 있는 로컬 장치인 것으로 도시되어 있지만, 다른 실시예들이, 모뎀 또는 이더넷 인터페이스 등의 네트워크 인터페이스를 통해 데이터 처리 장치에 결합되어 있는 네트워크 저장 장치와 같은, 시스템으로부터 원격지에 있는 비휘발성 메모리를 이용할 수 있다는 것을 잘 알 것이다.
잘 알려진 바와 같이, 버스(205)는 공지되어 있는 다양한 브리지, 제어기, 및/또는 어댑터를 통해 서로 연결되어 있는 하나 이상의 버스를 포함할 수 있다. 일 실시예에서, I/O 제어기(250)는 USB 호환 주변장치를 제어하는 USB 호환 어댑터 및 IEEE-1394 호환 주변장치에 대한 IEEE-1394 제어기를 포함할 수 있다.
본 명세서에 기술된 본 발명의 측면들은, 적어도 부분적으로, 소프트웨어로 실시될 수 있다. 즉, 이들 기법들은 컴퓨터 시스템 또는 기타 데이터 처리 시스템에서 그의 프로세서 또는 처리 시스템이 메모리(메모리(220) 또는 비휘발성 메모리(230) 또는 도 3에 도시된 메모리(330) 등)에 들어 있는 명령어 시퀀스를 실행하는 것에 응답하여 수행될 수 있다. 다양한 실시예들에서, 본 발명을 구현하기 위해 소프트웨어 명령어와 함께 하드와이어드 회로(hardwired circuitry)가 사용될 수 있다. 따라서, 이들 기법들은 하드웨어 회로 및 소프트웨어의 임의의 특정의 조합 또는 데이터 처리 시스템에 의해 실행되는 명령어들의 임의의 특정의 소스로 제한되지 않는다. 그에 부가하여, 본 설명 전반에 걸쳐, 설명을 간단화하기 위해 다양한 기능들 및 동작들이 소프트웨어 코드에 의해 수행되는 것으로 또는 소프트웨어 코드에 의해 야기되는 것으로 기술되어 있다. 그렇지만, 이러한 표현이 의미하는 바는 그 기능들이 처리 시스템에서 그 코드를 실행한 결과라는 것이다.
도크(260) 및/또는 무선 송수신기(270)는 도 2에 도시된 데이터 처리 시스템을, 도 3에 도시된 데이터 처리 시스템 등의 다른 데이터 처리 시스템에 또는 도 2에 도시된 시스템과 비슷한 다른 데이터 처리 시스템에 결합시키는 물리 인터페이스를 제공한다. 도크(260)는 하나의 데이터 처리 시스템과 다른 데이터 처리 시스템 간에 동기화 프로세스가 수행될 수 있게 해주기 위해 이 2개의 시스템 간의 기계적 및 물리적 연결 둘다를 제공할 수 있다. 다른 실시예들에서, 무선 송수신기(270)는 2개의 시스템 간의 기계적 연결을 제공하지 않고 동기화 프로세스를 위해 2개의 시스템 간의 무선 주파수(RF) 연결을 제공할 수 있다.
도 3은 클라이언트 장치, 핸드헬드 컴퓨터, 또는 도 2에 도시된 시스템이나 도 3에 도시된 것과 유사한 시스템 등의 기타 유형의 데이터 처리 시스템과 같은 데이터 처리 시스템의 일 실시예의 블록도이다. 데이터 처리 시스템(300)은 하나 이상의 마이크로프로세서일 수 있거나 시스템 온 칩(system on a chip) 집적 회로일 수 있는 처리 시스템(310)을 포함한다. 시스템(300)은 또한 데이터 및 처리 시스템(310)에서 실행하기 위한 프로그램을 저장하는 메모리(330)도 포함하고 있다. 시스템(300)은 또한, 예를 들어, 스피커 및 마이크를 통해 음악을 재생하거나 전화 기능을 제공하기 위한 마이크 및 스피커를 포함할 수 있는 오디오 입/출력 서브시스템(340)도 포함하고 있다.
디스플레이 제어기 및 디스플레이 장치(350)는 사용자에게 시각 사용자 인터페이스를 제공하고, 이 디지털 인터페이스는 OS X 운영 체제 소프트웨어를 실행할 때 Macintosh 컴퓨터에 보여지는 것과 유사한 그래픽 사용자 인터페이스를 포함할 수 있다. 시스템(300)은 또한 WiFi 송수신기, 적외선 송수신기, 블루투스
Figure 112012051627367-pat00004
호환 송수신기, 및/또는 무선 셀룰러 전화 송수신기와 같은 하나 이상의 무선 송수신기도 포함하고 있다. 어떤 실시예들에서, 도시되어 있지 않은 부가의 컴포넌트들도 또한 시스템(300)의 일부일 수 있고, 어떤 실시예들에서, 도 3에 도시된 것보다 적은 수의 컴포넌트들이 또한 데이터 처리 시스템에서 사용될 수 있다.
데이터 처리 시스템(300)은 또한 사용자가 시스템(300)에 입력을 제공할 수 있게 해주기 위해 제공되어 있는 하나 이상의 입력 장치(360)도 포함하고 있다. 이들 입력 장치는 키패드, 키보드, 터치 패널 또는 멀티-터치 패널(multi-touch panel)일 수 있다. 데이터 처리 시스템(300)은 또한 도 2에 도시된 도크(260)와 같은 도크에 대한 커넥터일 수 있는 선택적인 입/출력 장치(370)도 포함하고 있다.
도시되어 있지 않은 하나 이상의 버스가 공지된 바와 같이 다양한 컴포넌트들을 상호연결시키는 데 사용될 수 있다. 데이터 처리 시스템(300)은 핸드헬드 컴퓨터 또는 PDA(personal digital assistant), PDA-유사 기능을 갖는 셀룰러 전화, 셀룰러 전화를 포함하는 핸드헬드 컴퓨터, iPod과 같은 미디어 플레이어, 또는 하나의 장치에 PDA 및 셀룰러 전화를 겸비하고 있는 미디어 플레이어와 같은 이들 장치의 특성들 또는 기능들을 겸비하고 있는 장치일 수 있다. 다른 실시예들에서, 데이터 처리 장치(300)는 네트워크 컴퓨터 또는 다른 장치 내에 내장된 처리 장치, 또는 도 3에 도시된 것보다 더 적은 수의 컴포넌트 또는 어쩌면 더 많은 수의 컴포넌트를 갖는 기타 유형의 데이터 처리 시스템일 수 있다.
본 명세서에 기술된 본 발명의 적어도 어떤 실시예들은 미디어를 제공하는 미디어 처리 시스템을 포함할 수 있는 휴대용 음악 및/또는 비디오 미디어 플레이어와 같은 디지털 미디어 플레이어, 미디어를 저장하는 저장 장치의 일부일 수 있고, 안테나 시스템 및 미디어 처리 시스템과 결합되어 있는 RF(radio frequency) 송수신기(예를 들어, 셀룰러 전화의 RF 송수신기)를 더 포함할 수 있다. 어떤 실시예들에서, 원격 저장 장치에 저장된 미디어는 RF 송수신기를 통해 미디어 플레이어로 전송될 수 있다. 이 미디어는, 예를 들어, 음악 또는 기타 오디오, 정지 화상, 또는 동화상 중 하나 이상일 수 있다.
휴대용 미디어 플레이어는 미국 캘리포니아주 쿠퍼티노 소재의 Apple Inc.의 iPod
Figure 112012051627367-pat00005
또는 iPod Nano
Figure 112012051627367-pat00006
미디어 플레이어 상의 클릭 휠(click wheel) 입력 장치, 터치 스크린 입력 장치, 푸시버튼 장치, 이동가능 포인팅 입력 장치 또는 기타 입력 장치와 같은 미디어 선택 장치를 포함할 수 있다. 이 미디어 선택 장치는 저장 장치 및/또는 원격 저장 장치에 저장된 미디어를 선택하는 데 사용될 수 있다.
적어도 어떤 실시예들에서, 휴대용 미디어 플레이어는 입력 장치를 통해 선택되어, 스피커 또는 이어폰(들)을 통해 또는 디스플레이 장치 상에 제공되거나 디스플레이 장치 및 스피커 또는 이어폰(들) 둘다를 통해 제공되는 미디어의 타이틀 또는 기타 표시자를 디스플레이하기 위해 미디어 처리 시스템에 결합되어 있는 디스플레이 장치를 포함할 수 있다. 휴대용 미디어 플레이어의 일례가 공개된 미국 특허 출원 제2003/0095096호 및 제2004/0224638호에 기술되어 있으며, 이들 출원 둘다는 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.
어떤 실시예들에서, 데이터 처리 시스템(300)은 액정 디스플레이와 일체로 되어 있는 멀티-터치 입력 패널 장치일 수 있는 태블릿-유사 입력 장치를 갖는 핸드헬드 컴퓨터와 비슷한 작은 폼팩터로 구현될 수 있다. 이러한 장치의 일례가 2006년 10월 24일자로 출원된, 발명의 명칭이 "AUTOMATED RESPONSE TO AND SENSING OF USER ACTIVITY IN PORTABLE DEVICES(휴대용 장치에서의 사용자 동작의 감지 및 사용자 동작에 대한 자동화된 응답)"인 미국 특허 출원 제11/586,862호에 제공되어 있으며, 이 미국 출원은 본 출원과 동일한 양수인에게 양도되어 있다. 이 상기 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.
이하의 설명에서, 동기화 및 비동기화 처리 동작 둘다에 대해 사용되는 다양한 소프트웨어 컴포넌트에 대해 기술한다. 적어도 어떤 실시예들에서, 이들 다양한 소프트웨어 컴포넌트가 한 유형의 데이터 처리 시스템에 대한 도 2에 도시된 메모리(220) 및/또는 메모리(230)에 저장될 수 있고, 또한 도 3에 도시된 것과 같은 시스템의 경우에, 이들 다양한 서로 다른 소프트웨어 컴포넌트가 휘발성 메모리는 물론, 플래쉬 메모리 또는 자기 하드 드라이브 등의 비휘발성 메모리를 포함할 수 있는 메모리(330)에 저장될 수 있다는 것을 잘 알 것이다.
장치들 간의 적절한 상호연결과 함께 각각의 예시적인 실시예들에서 호스트 장치와 클라이언트 장치에 대해 기술하였으며, 이제부터는 예시적인 패킷 포맷, 패킷 유형, 기능 및 데이터 흐름에 대해 기술한다. 이상의 설명에서와 같이, 이하의 설명은 통신 프로토콜의 예시적인 실시예를 제공한다. 이 프로토콜에 대한 변형들도 역시 지원될 수 있다.
도 4의 표는 패킷 헤더 포맷의 일 실시예를 나타낸 것이다. 기타 포맷들도 역시 사용될 수 있다. 특정의 크기 및 길이가 기술되어 있지만, 기타 필드 이름, 길이 및/또는 설명(description)들도 역시 지원될 수 있다.
일 실시예에서, 패킷 데이터가 리틀-엔디안(little-endian) 또는 빅-엔디안(big-endian) 포맷 중 어느 하나로 연결을 통해 전송될 수 있다. 일 실시예에서, 어느 한쪽 장치가 데이터를 어느 한쪽 포맷으로 전송할 수 있다. 수신측 장치는, 필요한 경우, 데이터 순서를 바꿀 책임이 있다. 일 실시예에서, 각각의 패킷은 일관된 엔디안 방식(endianness)을 사용해야만 한다. 일 실시예에서, 미리 정해진(예를 들어, 일정한) 서명 값(예를 들어, 0x4141504c36414643)이 모든 패킷 헤더에 대해 사용될 수 있다. 이 서명은 수신측 장치가 송신측 장치로부터 전송된 데이터의 엔디안 방식을 판정할 수 있게 해준다. 일 실시예에서, 서명 필드는 길이가 8 바이트이지만, 기타 서명 필드 크기도 역시 지원될 수 있다.
패킷 헤더는 또한 헤더를 포함하는 전체 패킷의 길이를 나타내는 필드도 포함할 수 있다. 일 실시예에서, 패킷 길이 필드가 8 바이트일 수 있지만, 예를 들어, 다른 최대 패킷 크기를 지원하기 위해 기타 패킷 길이 필드 크기가 지원될 수 있다. 패킷 헤더는 또한 패킷 일련 번호를 나타내는 필드도 포함할 수 있다. 패킷 일련 번호는 호스트 장치(100)와 클라이언트 장치(150) 간에 전송되는 패킷에 순서를 부여하는 데 이용될 수 있다. 일 실시예에서, 패킷 일련 번호 필드가 8 바이트일 수 있지만, 기타 패킷 일련 번호 필드 크기가 지원될 수 있다.
패킷 헤더는 또한 패킷 유형에 대한 필드도 포함하고 있다. 패킷 유형 필드는 패킷의 기능을 나타내는, 패킷 내의 메시지의 유형의 숫자 표시자(numerical indicator)를 포함하고 있다. 패킷 유형 및 패킷 유형 값의 한 예시적인 리스트가 도 5에 제공되어 있다. 기타 패킷 이름, 기타 패킷 기능 및/또는 기타 패킷 유형 값도 역시 지원될 수 있다. 일 실시예에서, 패킷 유형 필드가 8 바이트일 수 있지만, 기타 패킷 유형 필드 크기가 지원될 수 있다.
도 5의 표는 종단점들 간에 통신을 하는 데 이용될 수 있는 일련의 패킷의 일 실시예를 나타낸 것이다. 기타 패킷 및/또는 다른 패킷도 역시 이용될 수 있다. 특정의 패킷 유형 식별자 및 패킷 이름이 기술되어 있지만, 기타 패킷 유형 식별자, 패킷 이름 및/또는 설명도 역시 지원될 수 있다.
도 5에 열거된 패킷의 다양한 실시예들에 대해 이하에서 더 상세히 설명한다. 이들 패킷 설명은 제공될 수 있는 단지 하나의 실시예의 일례를 제공한다. 일 실시예에서, 각각의 패킷은 표준의 패킷 헤더를 포함한다. 이 헤더는 도 4에 예시된 것과 같은 포맷으로 되어 있을 수 있다.
Status 패킷은 요청 패킷(request packet)에 응답하여 상태 정보를 제공하는 데 이용될 수 있다. 상태 패킷은 또한 장애 또는 기타 오류 조건의 경우에 오류 정보를 제공하는 데도 이용될 수 있다. 일 실시예에서, 상태 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Status 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Status 8 요청된 동작의 상태를 나타내는 상태 코드
Data 패킷은 호스트 전자 장치와 클라이언트 전자 장치 간에 데이터를 전달하는 데 이용될 수 있다. 일 실시예에서, 데이터 패킷은 임의의 크기일 수 있다. 즉, 데이터 패킷은 '헤더 + 전송될 데이터'의 길이일 수 있다. 대안의 실시예에서, 전송될 데이터가 데이터 패킷의 페이로드 용량(payload capacity)을 초과하는 경우 하나 이상의 부가의 데이터 패킷이 이용될 수 있도록 데이터 패킷이 고정된 길이일 수 있다. 일 실시예에서, Data 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Data 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Data 가변적임 요청된 데이터/전송될 데이터
Read Directory 패킷은 타겟 장치 상의 디렉토리를 읽는 데 이용될 수 있다. 일 실시예에서, Read Directory 패킷은 이하의 표에 따른 포맷으로 되어 있다. 경로 문자열(path string)은 타겟 장치에 대한 적절한 포맷의 경로 문자열일 수 있다. 예를 들어, 경로 문자열은 UTF-8 포맷의 NULL-종료(NULL-terminated) POSIX(Portable Operating System Interface for UNIX) 경로 문자열일 수 있다. 기타 포맷들도 역시 지원될 수 있다. POSIX 표준 계열이 정식으로 IEEE 표준 1003 으로 지정되어 있으며, 국제 표준 명칭은 ISO/IEC 9945이다.
Read Directory 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Path 가변적임 적절한 포맷의 경로 문자열
Read File 패킷은 타겟 장치 상의 하나의 파일 전체를 읽는 데 이용될 수 있다. 일 실시예에서, 그 결과가 Status 패킷 또는 Data 패킷에 넣어 제공된다. 일 실시예에서, Read File 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Read File 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Offset 8 파일의 시작부터 요청된 데이터까지의 오프셋
Length 8 파일로부터 읽어낼 데이터의 길이
Path 가변적임 적절한 포맷의 경로 문자열
Write File 패킷은 타겟 장치에 하나의 파일 전체를 쓰는 데 이용될 수 있다. 일 실시예에서, Write File 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Write File 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Path 가변적임 적절한 포맷의 경로 문자열
Data 가변적임 파일에 써질 데이터
Write Part 패킷은 타겟 장치 상의 파일의 일부분에 데이터를 쓰는 데 이용될 수 있다. 패킷으로부터의 데이터가 써질 때 데이터 및/또는 파일과 연관된 상태 데이터가 유지되지 않는다는 점에서, Write Part 패킷이 무상태(stateless)일 수 있다. 일 실시예에서, Write Part 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Write Part 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Offset 8 파일의 시작부터 쓰기의 시작까지의 오프셋
Path 가변적임 적절한 포맷의 경로 문자열
Data 가변적임 파일에 써질 데이터
Truncate (Trunc) File 패킷은 파일의 길이를 설정하는 데 이용될 수 있다. 그 길이가 대응하는 데이터보다 짧을 수 있거나(이 경우, 데이터 중 일부가 누락됨), 그 길이가 대응하는 데이터보다 클 수 있다(이 경우, 초과 부분이 미리 정해진 데이터 패턴(예를 들어, 모두 "0")으로 채워질 수 있음). 일 실시예에서, Trunc File 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Trunc File 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Length 8 파일의 길이
Path 가변적임 적절한 포맷의 경로 문자열
Remove Path 패킷은 타겟 장치 상의 파일 또는 디렉토리를 삭제하는 데 이용될 수 있다. 일 실시예에서, Remove Path 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Remove Path 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Path 가변적임 적절한 포맷의 경로 문자열
Make Directory 패킷은 타겟 장치 상에 디렉토리를 생성하는 데 이용될 수 있다. 일 실시예에서, Make Directory 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Make Directory 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Path 가변적임 적절한 포맷의 경로 문자열
Get File Info 패킷은 타겟 장치 상의 파일을 설명하는 정보를 검색하는 데 이용될 수 있다. 일 실시예에서, 파일 정보는 Data 패킷에 넣어 전송되는 하나 이상의 키/값 쌍으로서 제공된다. 파일을 설명하는 정보는, 예를 들어, 파일 크기, 최근 수정 일자, 퍼미션(permission)일 수 있다. 부가의 파일 정보 및/또는 다른 파일 정보도 역시 제공될 수 있다. 일 실시예에서, Get File Info 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Get File Info 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Path 가변적임 적절한 포맷의 경로 문자열
Get Device Info 패킷은 타겟 장치를 설명하는 정보를 검색하는 데 이용될 수 있다. 일 실시예에서, 장치 정보는 Data 패킷에 넣어 전송되는 하나 이상의 키/값 쌍으로서 제공된다. 장치를 설명하는 정보는, 예를 들어, 장치 이름, 일련 번호, 운영 체제 버전, 배터리 레벨, 이용가능한 자유 공간일 수 있다. 부가의 장치 정보 및/또는 다른 장치 정보도 역시 제공될 수 있다. 일 실시예에서, Get Device Info 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Get Device Info 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Write File Atomic 패킷은 타겟 장치에 파일을 쓰는 데 이용될 수 있다. Write File Atomic 패킷은 파일 전체가 써지거나 파일이 전혀 써지지 않도록 해준다. Write File Atomic 패킷은, 예를 들어, 데이터베이스 파일을 쓰는 데 사용될 수 있다. 일 실시예에서, Write File Atomic 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Write File Atomic 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Path 가변적임 적절한 포맷의 경로 문자열
File Reference (Ref) Open 패킷은 타겟 장치 상의 열린 파일을 나타내는 토큰 또는 기타 식별자를 획득하는 데 이용될 수 있다. 일 실시예에서, File Ref Open 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Open 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Mode 8 파일을 열 때 사용할 모드(표 16 참조)
Path 가변적임 적절한 포맷의 경로 문자열
일 실시예에서, 모드(Mode) 필드는 파일을 열 때 사용하는 모드의 숫자 표시자를 포함한다. 표 16에서의 모드 이름(Mode Name) 및 모드 값(Mode Value) 지정은 일 실시예에 대한 일례이다. 다른 일군의 모드가 지원될 수 있다. 또한, 다른 모드 값들이 지원될 수 있다.
모드
모드 이름 모드 값
Read Only 1
Read-Write 2
Write-Truncate 3
Read-Write-Truncate 4
Write-Append 5
Read-Write-Append 6
Read Only 모드에서, 파일은 읽기만을 위해 열릴 수 있다. Read-Write 모드에서, 파일은 읽기 및 쓰기만을 위해 열릴 수 있다. Write-Truncate 모드에서, 파일은 쓰기 또는 절단을 위해 열릴 수 있다. Read-Write-Truncate 모드에서, 파일은 읽기, 쓰기 또는 절단을 위해 열릴 수 있다. Write-Append 모드에서, 파일은 쓰기 또는 첨부를 위해 열릴 수 있다. Read-Write-Append 모드에서, 파일은 읽기, 쓰기 또는 첨부를 위해 열릴 수 있다.
File Ref Open Result 패킷은 타겟 장치 상의 파일에 액세스할 때 본 명세서에 기술된 패킷들 중 하나 이상에서 사용될 수 있는 파일 참조 토큰(file reference token)을 반환하는 데 이용될 수 있다. 일 실시예에서, File Ref Open Result 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Open Result 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 File Ref Open 동작으로부터 얻은 파일 참조
File Ref Read 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일을 읽는 데 이용될 수 있다. 일 실시예에서, File Ref Read 동작에 응답하여 파일 내의 위치가 자동적으로 전진한다. 일 실시예에서, File Ref Read 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Read 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 File Ref Open 동작으로부터 얻은 파일 참조
Length 8 파일로부터 읽어낼 데이터의 길이
File Ref Write 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일에 쓰는 데 이용될 수 있다. 일 실시예에서, File Ref Write 동작에 응답하여 파일 내의 위치가 자동적으로 전진한다. 일 실시예에서, File Ref Write 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Write 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 File Ref Open 동작으로부터 얻은 파일 참조
Data 가변적임 파일에 써질 데이터
File Ref Seek 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일 내의 위치를 구하는 데 이용될 수 있다. 일 실시예에서, File Ref Seek 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Seek 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 File Ref Open 동작으로부터 얻은 파일 참조
Whence 8 탐색할 위치(표 21 참조)
Offset 8 파일의 시작부터 읽기 시작까지의 오프셋
일 실시예에서, Whence 필드 내의 값은 탐색이 어떻게 수행되어야 하는지를 나타내는 데 사용될 수 있다. 표 21은 File Ref Seek 패킷에서 사용될 수 있는 Whence 값의 일례를 제공한다.
File Ref Seek 패킷에서 사용되는 Whence 값
Whence 값 설명
0 Offset 필드에 의해 지정된 절대 위치까지 탐색함
1 파일의 현재 위치로부터 탐색함
2 파일의 끝부터 탐색함
File Ref Tell 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일 내의 위치를 구하는 데 이용될 수 있다. 일 실시예에서, File Ref Tell 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Tell 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 위치가 반환될 파일 참조
File Ref Tell Result 패킷은 File Ref Tell 동작의 결과를 반환하는 데 이용될 수 있다. 일 실시예에서, File Ref Tell Result 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Tell Result 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Offset 8 요청된 파일 참조의 현재 위치 오프셋
File Ref Close 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일을 닫는 데 이용될 수 있다. 일 실시예에서, File Ref Close 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Close 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 닫을 파일의 파일 참조
File Ref Set Size 패킷은 File Ref Open 동작으로부터 얻은 참조에 대응하는 파일의 크기를 설정하는 데 이용될 수 있다. 일 실시예에서, File Ref Set Size 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Set Size 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 닫을 파일의 파일 참조
File Size 8 파일의 새로운 크기(단위: 바이트)
File Ref Set Size 패킷은 파일의 길이를 설정하는 데 이용될 수 있다. 그 길이가 대응하는 데이터보다 짧을 수 있거나(이 경우, 데이터 중 일부가 누락됨), 그 길이가 대응하는 데이터보다 클 수 있다(이 경우, 초과 부분이 미리 정해진 데이터 패턴(예를 들어, 모두 "0")으로 채워질 수 있음).
Rename Path 패킷은 타겟 장치 상에 디렉토리 경로의 이름을 변경하는 데 이용될 수 있다. 일 실시예에서, Rename Path 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Rename Path 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Source Path 가변적임 이름 변경될 경로에 대한 적절한 포맷의 경로 문자열
Destination Path 가변적임 새로운 경로 이름에 대한 적절한 포맷의 경로 문자열
경로 문자열(path string)은 타겟 장치에 대한 적절한 포맷의 경로 문자열일 수 있다. 예를 들어, 발신지 및 목적지 경로 문자열은 UTF-8 포맷의 NULL-종료 POSIX 경로일 수 있다. 기타 포맷들도 역시 지원될 수 있다. 일 실시예에서, Rename Path 패킷에서 목적지 경로 필드가 발신지 경로 필드 바로 다음에 온다.
Set FS Block Size 패킷은 타겟 장치 상의 파일 시스템에 대한 블록 크기를 설정하는 데 이용될 수 있다. 일 실시예에서, Set FS Block Size 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Set File System Block Size 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Block Size 8 파일 시스템 동작에 대한 블록 크기
블록 크기는 클라이언트 장치 파일 시스템에서 이용될 수 있다. 예를 들어, 블록 크기가 64 kb인 경우, 클라이언트 장치에 파일 데이터를 쓸 때, 호스트 장치가 데이터를 보다 크거나 보다 작은 블록으로 전송하더라도 한번에 64 kb의 데이터가 써진다. 일 실시예에서, 클라이언트 장치는 데이터가 블록 크기에 따라 써지는 것을 보장하지 않지만, 성능을 위해 이용될 수 있다.
Set Socket Block Size 패킷은 타겟 장치와 호스트 장치 간의 데이터 연결에 대한 블록 크기를 설정하는 데 이용될 수 있다. 일 실시예에서, Set Socket Block Size 패킷은 이하의 표에 따른 포맷으로 되어 있다.
Set Socket Block Size 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
Block Size 8 타겟과 호스트 간의 통신을 위한 블록 크기
블록 크기는 클라이언트 시스템에서 호스트 장치와 클라이언트 장치 간의 연결을 통해 데이터를 읽고 쓰는 데 이용될 수 있다. 예를 들어, 블록 크기가 64 kb인 경우, 연결로부터 데이터를 읽을 때, 클라이언트 장치는 데이터를 64 kb 블록으로서 읽으려고 시도할 수 있다. 일 실시예에서, 클라이언트 장치는 데이터가 블록 크기에 따라 처리되는 것을 보장하지 않지만, 성능을 위해 이용될 수 있다.
File Ref Lock 패킷은 제2 애플리케이션에서 사용하지 못하도록 열린 파일 참조 식별자를 잠그는 데 이용될 수 있다. 일 실시예에서, File Ref Lock 패킷은 이하의 표에 따른 포맷으로 되어 있다.
File Ref Lock 패킷
필드 이름 길이(단위: 바이트) 설명
Header 40 표준의 패킷 헤더(예를 들어, 도 2 참조)
File Ref 8 잠금될 파일의 파일 참조
Lock type 8 파일 참조 식별자에 적용되는 잠금의 유형
주어진 때에 하나의 애플리케이션만이 열린 파일에 액세스할 수 있도록 파일 참조에 대한 액세스가 잠금될 수 있다. 일 실시예에서, 공유 잠금(shared lock), 배타적 잠금(exclusive lock) 및 비차단 잠금(non-blocking lock)이 지원된다. 대안의 실시예들에서, 부가의 잠금 및/또는 다른 잠금이 지원된다. 일 실시예에서, 잠금은 권고사항일 뿐이며, 애플리케이션은 파일이 잠금되어 있는지 여부를 판정하기 위해 파일을 조사할 수 있다. 일 실시예에서, 다수의 애플리케이션/프로세스가 공유 잠금을 획득할 수 있다.
상기한 메시지 및 포맷은 전체 파일 통신 프로토콜(full file communication protocol)을 지원하는 데 이용될 수 있다. 이하의 예들에서, 상기 패킷들의 일부가 프로토콜의 사용을 설명하기 위해 사용된다. 많은 기타 동작들도 역시 지원될 수 있다.
도 6은 클라이언트 장치로 데이터를 전송하는 기법의 일 실시예의 흐름도이다. 도 6의 예에서, 호스트 장치는 클라이언트 장치가 호스트 장치에 연결되어 있는지 여부를 판정할 수 있다(610). 상기한 바와 같이, 호스트 장치와 클라이언트 장치 간의 연결은 유선이거나 무선일 수 있다.
호스트 장치는 임의의 적당한 기법을 이용하여 클라이언트 장치의 존재를 검출할 수 있다. 예를 들어, 클라이언트 장치가 유선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 클라이언트 장치와 유선 인테페이스 간의 물리 연결을 검출하도록 구성되어 있을 수 있다. 클라이언트 장치가 무선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 페어링(pairing) 또는 기타 유형의 무선 연결 절차의 완료에 응답하도록 구성될 수 있다.
일 실시예에서, 클라이언트 장치가 연결되지 않은 경우(610), 호스트 장치는 클라이언트 장치가 연결되기를 기다릴 수 있다. 다른 실시예에서, 호스트 장치는 요청이 인터페이스를 통해 수신되는 경우에만 응답할 수 있다. 예를 들어, 유선 인터페이스는 클라이언트 장치와 호스트 장치 간의 통신을 개시하기 위해 사용자에 의해 눌러지는 버튼을 포함할 수 있다. 다른 예로서, 클라이언트 장치는 사용자가 호스트 장치와의 통신을 요청할 수 있게 해주는 사용자 인터페이스를 가질 수 있다.
클라이언트 장치의 연결(610)에 응답하여, 호스트 장치는 클라이언트 장치에 관한 정보를 수집할 수 있다(620). 클라이언트 장치에 관한 정보의 수집은 상기한 패킷들 중 하나 이상을 전송함으로써 달성될 수 있다. 예를 들어, 호스트 장치는 Get Device Info 패킷 및/또는 Read Directory 패킷을 전송할 수 있다. 클라이언트 장치는 요청된 정보를 호스트 장치에 제공하는 것으로 그 패킷(들)에 응답할 수 있다.
클라이언트 장치로부터 충분한 정보를 수집할 시에, 호스트 장치는 클라이언트 장치가 새로운 장치인지 여부를 판정할 수 있다(630). 즉, 호스트 장치는 클라이언트 장치가 이전에 호스트 장치에 연결된 적이 있는지 여부를 판정할 수 있다. 클라이언트 장치가 새로운 장치인 경우, 호스트 장치는 등록 절차를 수행할 수 있다(635). 등록 절차에 의해 호스트 장치는 연결을 신속히 처리하고 및/또는 백업을 위해, 예를 들어, 인증에 사용될 수 있는 클라이언트 장치에 관한 정보를 유지할 수 있다.
호스트 장치는 클라이언트 장치를 인증할 수 있다(640). 인증은 호스트 장치와 클라이언트 장치 간에, 예를 들어, 키 또는 기타 식별자를 교환하는 것에 의해 달성될 수 있다. 기타 인증 기법들도 역시 사용될 수 있다. 일 실시예에서, 호스트 장치 및 클라이언트 장치에 존재하는 대응하는 동기 서비스에 의해 인증이 수행된다.
인증 후에, 호스트 장치는 본 명세서에 기술된 패킷들을 사용하여 클라이언트 장치로 데이터를 전송할 수 있다(650). 예를 들어, 클라이언트 장치에 새로운 파일을 추가하기 위해(예를 들어, 클라이언트 장치에 새로운 미디어 파일을 로드하기 위해), 호스트 장치는 Write File 패킷을 사용하여 데이터가 클라이언트 장치 상의 파일에 써지게 할 수 있다. 하나의 세션에서 임의의 수의 데이터 전송 패킷들이 사용될 수 있다.
도 7은 호스트 장치와 클라이언트 장치 간에 데이터를 동기화시키는 기법의 일 실시예의 흐름도이다. 도 7의 예는 상기한 패킷 유형들 중 일부만을 이용한다. 그렇지만, 도 7의 예는 본 명세서에 기술된 프로토콜들 및 메시지들을 이용하여 호스트 장치와 클라이언트 장치 간에 일어날 수 있는 세션을 대표하는 것이다.
이하의 예에서, "->"는 대응하는 패킷이 호스트 장치로부터 클라이언트 장치로 전송되는 것을 나타내고, "<-"는 대응하는 패킷이 클라이언트 장치로부터 호스트 장치로 전송되는 것을 나타낸다. 패킷 유형이 먼저 열거되고, 예시적인 값을 갖는 패킷 내의 하나 이상의 필드가 열거되며, "<...>"는 부가의 필드들이 도 7의 예에 나타나 있지 않음을 나타낸다. 패킷의 데이터 섹션은, 있는 경우, "Data=..."로 나타내어져 있다. 패킷들의 리스트에 대해 먼저 설명하고, 패킷들의 리스트 이후에 세션에 대한 설명이 제공된다.
Figure 112012051627367-pat00007
Figure 112012051627367-pat00008
도 7의 예에서, 호스트 장치는 클라이언트 장치가 호스트 장치에 연결되어 있는지 여부를 판정할 수 있다(710). 상기한 바와 같이, 호스트 장치와 클라이언트 장치 간의 연결은 유선이거나 무선일 수 있다.
호스트 장치는 임의의 적당한 기법을 이용하여 클라이언트 장치의 존재를 검출할 수 있다. 예를 들어, 클라이언트 장치가 유선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 클라이언트 장치와 유선 인터페이스 간의 물리 연결을 검출하도록 구성되어 있을 수 있다. 클라이언트 장치가 무선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 페어링(pairing) 또는 기타 유형의 무선 연결 절차의 완료에 응답하도록 구성될 수 있다.
일 실시예에서, 클라이언트 장치가 연결되지 않은 경우(710), 호스트 장치는 클라이언트 장치가 연결되기를 기다릴 수 있다. 다른 실시예에서, 호스트 장치는 요청이 인터페이스를 통해 수신되는 경우에만 응답할 수 있다. 예를 들어, 유선 인터페이스는 클라이언트 장치와 호스트 장치 간의 통신을 개시하기 위해 사용자에 의해 눌러지는 버튼을 포함할 수 있다. 다른 예로서, 클라이언트 장치는 사용자가 호스트 장치와의 통신을 요청할 수 있게 해주는 사용자 인터페이스를 가질 수 있다.
클라이언트 장치의 연결(710)에 응답하여, 호스트 장치는 클라이언트 장치에 관한 정보를 수집할 수 있다(720). 클라이언트 장치에 관한 정보의 수집은 Get Device Info 패킷을 호스트 장치로부터 클라이언트 장치로 전송하고 Data 패킷을 클라이언트 장치로부터 호스트 장치로 전송함으로써 달성될 수 있다. 상기한 바와 같이, 클라이언트 장치에 관한 임의의 유형의 정보가 이러한 방식으로 호스트 장치에 의해 획득될 수 있다. 도 7의 예에서, 클라이언트 장치는 적어도 모델 식별자 및 파일 시스템 크기를 호스트 장치에 제공한다. 부가의 데이터 및/또는 다른 데이터도 역시 제공될 수 있다.
선택적으로, 클라이언트 장치로부터 충분한 정보를 수집하였을 때, 호스트 장치는 클라이언트 장치가 새로운 장치인지 여부를 판정할 수 있다(730). 클라이언트 장치가 새로운 장치인 경우, 호스트 장치는 선택적인 등록 절차를 수행할 수 있다(735). 호스트 장치는 클라이언트 장치를 인증할 수 있다(740). 인증은 호스트 장치와 클라이언트 장치 간에, 예를 들어, 키 또는 기타 식별자를 교환하는 것에 의해 달성될 수 있다. 기타 인증 기법들도 역시 사용될 수 있다. 일 실시예에서, 호스트 장치 및 클라이언트 장치에 존재하는 대응하는 동기 서비스에 의해 인증이 수행된다.
인증 후에, 호스트 장치는 호스트 장치와 클라이언트 장치 간에 데이터의 동기화를 시작할 수 있다. 클라이언트 장치는 클라이언트 장치 상의 경로에 대응하는 File Ref 값을 요청하고 그 경로에서 데이터를 읽을 수 있다(750). 이것은, 예를 들어, 이상에서 열거한 File Ref Open, File Ref Open Result, File Ref Read, Data 패킷들을 사용하여 달성될 수 있다. 요청된 디렉토리가 존재하지 않는 경우, 디렉토리가 생성될 수 있다(760). 요청된 데이터가 획득될 때, File Ref가 닫혀질 수 있다. 이것은 이상에서 열거한 File Ref Close 및 Status 패킷들을 사용하여 달성될 수 있다.
Make Directory 패킷은 타겟 경로가 존재하는지 여부를 판정하는 데 이용될 수 있다. 예를 들어, 이상에서 열거한 패킷들을 사용하여, 'media' 디렉토리가 존재하는지 여부를 판정하기 위해 '/media'을 타겟으로 갖는 Make Directory 패킷이 사용될 수 있다. 'media' 디렉토리가 존재하는 경우, 클라이언트 장치로부터의 그 Status 패킷은 'media' 디렉토리의 존재를 'PATH_EXISTS' 상태로 나타낼 수 있다.
업데이트될 제1 파일(예를 들어, '/media/file1.mp3')에 대해 파일 정보가 요청될 수 있다. 업데이트될 제1 파일에 관련된 정보를 요청하기 위해 Get File Info 패킷이 사용될 수 있다(770). 클라이언트 장치는 업데이트될 제1 파일에 관련된 데이터를 반환하기 위해 Data 패킷을 사용할 수 있다.
호스트 장치는 그 다음에 제1 파일을 업데이트하는 동안 사용할 File Ref 값을 요청할 수 있다. 이것은 File Ref Open Result 패킷 내의 클라이언트 장치로부터의 응답과 함께 File Ref Open 패킷을 사용하여 달성될 수 있다. 호스트 장치는 클라이언트 장치 상의 파일에 데이터를 쓰기 위해 File Ref 값을 사용할 수 있다(775). 이것은 Status 패킷에 의해 전달되는 클라이언트 장치로부터의 확인과 함께 File Ref Write 패킷을 사용하여 달성될 수 있다. 파일에의 쓰기가 완료될 때, 호스트 장치는 클라이언트 장치로부터의 Status 패킷에 의해 확인될 수 있는 File Ref를 해제(release)하기 위해 File Ref Close 패킷을 사용할 수 있다.
Make Directory 패킷은 업데이트될 제2 파일에 대한 타겟 경로가 존재하는지 여부를 판정하는 데 이용될 수 있다. 예를 들어, 이상에서 열거한 패킷들을 사용하여, 'file2.mp3' 파일이 존재하는지 여부를 판정하고 파일에 관련된 정보를 가져오기 위해 '/media/file2.mp3'을 타겟으로 갖는 Get File Info 패킷이 사용될 수 있다(780). 예를 들어, 'file2.mp3' 파일이 존재하는 경우, 클라이언트 장치로부터의 Status 패킷은 'PATH_DOES_NOT_EXIST' 상태를 반환할 수 있다.
호스트 장치는 그 다음에 제2 파일을 업데이트하는 동안 사용할 File Ref 값을 요청할 수 있다. 이것은 File Ref Open Result 패킷 내의 클라이언트 장치로부터의 응답과 함께 File Ref Open 패킷을 사용하여 달성될 수 있다. 호스트 장치는 클라이언트 장치 상의 파일에 데이터를 쓰기 위해 File Ref 값을 사용할 수 있다(785). 이것은 Status 패킷에 의해 전달되는 클라이언트 장치로부터의 확인과 함께 File Ref Write 패킷을 사용하여 달성될 수 있다. 파일에의 쓰기가 완료될 때, 호스트 장치는 클라이언트 장치로부터의 Status 패킷에 의해 확인될 수 있는 File Ref를 해제(release)하기 위해 File Ref Close 패킷을 사용할 수 있다.
임의의 수의 파일이 유사한 방식으로 업데이트될 수 있다. 동기화가 완료되지 않은 경우(790), 부가의 파일들이 상기한 바와 같이 업데이트될 수 있다. 동기화가 완료된 경우(790), 동기화 세션이 종료될 수 있다.
본 발명의 다른 측면들은 멀티플렉싱된 데이터 스트림 프로토콜(multiplexed data stream protocol)에 관한 것이다. 이러한 프로토콜의 사용에 의해, 한 장치 상의 다수의 애플리케이션(또는 동일한 애플리케이션)이 상대방 장치 상의 하나 이상의 애플리케이션과 임의의 수의 다중 동시 세션(multiple concurrent session)을 유지할 수 있고, 애플리케이션이 동적으로 세션의 생성 또는 그의 세션의 닫기를 야기하기 때문에, 동시 세션의 수가 시간에 따라 변할 수 있다. 이러한 프로토콜은 한 장치 및 다른 장치(예를 들어, 호스트) 둘다에서 사용되는 인터페이스(예를 들어, USB 인터페이스 또는 BLUETOOTH 인터페이스)의 전송과 독립적이 되도록 구현될 수 있으며, 다수의 독립적인 연결이 동일한 공통의 링크/인터페이스(예를 들어, USB 인터페이스)를 통해 유지될 수 있다. 일 실시예에서, 하나의 USB 세션이 설정되고, 그 하나의 USB 세션을 통해 임의의 변경가능한 수의 다중 동시 세션이 터널링된다. 일 실시예에서, USB와 같은 특정의 인터페이스가 프레이밍(framing)을 지원하거나, COBS (constant overhead byte stuffing) 또는 PPP/SLIP 스타일의 프레이밍과 같은 어떤 프레이밍 프로토콜이 추가되어야만 한다. 다수의 독립적인 연결이 서로 다른 목적을 위해 동시에 사용될 수 있다(예를 들어, 다른 데이터(예를 들어, 이메일 또는 설정 정보 또는 소프트웨어 위젯)도 역시 장치들 간에 교환되고 있는 동안에 미디어 파일과 같은 파일이 전송될 수 있으면서 주소록 내의 연락처와 같은 구조화된 데이터가 장치들 간에 교환 및/또는 동기화될 수 있다). 다수의 독립적인 연결을 지원할 수 있는 것이 다수의 애플리케이션이 동시에 실행될 수 있게 해주는 멀티-태스킹 운영 체제(OS)를 갖는 장치들에 특히 유용하지만, 이러한 OS가 꼭 필요한 것은 아니다.
도 14b는, 본 발명의 일 실시예를 사용하여, 임의의 수의 다중 "클라이언트" 애플리케이션(예를 들어, 구조화된 데이터를 동기화시키는 동기화 소프트웨어, 파일을 전송하는 파일 전송 소프트웨어, 백업 소프트웨어, 기타)이 USB(유선 또는 무선) 또는 BLUETOOTH와 같은 비네트워크 인터페이스를 통해 다중 동시 연결 또는 세션을 유지할 수 있는 방법을 나타낸 것이다. 도 14a는, 종래 기술에서, 장치들 간에 USB 연결을 사용할 수 있는 각각의 장치 상에 사실상 단지 하나의 클라이언트 애플리케이션이 있는 것을 나타낸 것이다. 도 14a의 상호연결된 시스템(1401)에서, 호스트 상의 클라이언트 애플리케이션(1402)은 그의 USB 인터페이스(1405) 및 연결(1407)을 통해 데이터를 전송 및 수신하기 위해 PTP(picture transfer protocol) 프로토콜(1403)을 사용하고, 장치 상의 클라이언트 애플리케이션(1411)은 장치의 USB 인터페이스(1409)를 통해 데이터를 전송 및 수신하기 위해 PTP 프로토콜(도시 생략)을 사용한다. 연결(1407) 및 USB 인터페이스(1405, 1409)는 단지 하나의 연결 또는 세션만을 지원한다. 이와 반대로, 상호연결된 시스템(1421)은 연결(1429) 및 USB 인터페이스(1427, 1431)를 통해 다중 독립 동시 연결 또는 세션을 지원한다. 호스트 상의 다수의 클라이언트 애플리케이션(1423)은 다수의 클라이언트 애플리케이션(1435)에 있는 그 각자의 상대방과 독립 동시 연결 또는 세션을 유지할 수 있다. 예를 들어, 도 8에 도시된 시스템의 경우에, 장치(801) 상의 동기화 소프트웨어(805)가 호스트 상의 동기 소프트웨어(835)와 열려있는 연결(소프트웨어(807)와 소프트웨어(831) 간의 연결과 독립적임)을 유지하고 있는 동안에, 장치(801) 상의 파일 전송 소프트웨어(807)는 호스트(803) 상의 미디어 소프트웨어(831)(예를 들어, iTunes)(또는 파일 전송 소프트웨어(833))와 열린 채로 유지되는 연결을 가질 수 있다. 다중 독립 동시 연결이 호스트 및 장치 둘다에서 TCP-유사 프로토콜을 통해 구현될 수 있으며, 이 때 TCP-유사 헤더를 갖는 TCP-유사 패킷이 USB 인터페이스(1427, 1431)와 같은 비네트워크 인터페이스를 통해 전송된다. TCP-유사 패킷은 호스트 상의 '인터페이스를 통한 TCP(TCP over interface)'(1425) 소프트웨어 및 장치 상의 '인터페이스를 통한 TCP'(1433) 소프트웨어에 의해 처리된다. '인터페이스를 통한 TCP'(1425) 소프트웨어는 도 8의 '인터페이스를 통한 TCP' 소프트웨어(821)와 동일하거나 그와 유사할 수 있으며, '인터페이스를 통한 TCP'(1431) 소프트웨어는 도 8의 '인터페이스를 통한 TCP' 소프트웨어(841)와 동일하거나 그와 유사할 수 있다. TCP-유사 패킷은 설정된 연결을 갖는 대응하는 발신지(예를 들어, 송신측) 및 목적지(예를 들어, 수신측) 애플리케이션과 연관되어 있는 각자의 발신지 및 목적지 포트를 TCP-유사 헤더에 명시하고, 이들 포트의 명시는 독립 동시 연결들이 유지될 수 있게 해준다. 본 명세서에 기술된 방법은 또한 연결이 갑작스럽게 또는 예측불가능하게 단절되는 경우(사용자가 무선 셀룰러 전화로 받은 전화 호에 응답하기 위해 장치를 그의 USB 케이블 또는 크레이들(cradle)로부터 뽑음으로써 장치를 호스트와 단절시킬 때 등) 정상적으로 복원하는 메카니즘을 제공한다. TCP-유사 프로토콜은, 세션이 단절되었을 때, 발신지 및 목적지 애플리케이션에 통지를 제공하고, 이 통지는 애플리케이션에서 통지를 처리하여 그의 상태를 원상 복구하고 데이터에 대한 임의의 원하는 정정을 구현하기 위해 사용될 수 있다. TCP-유사 프로토콜은 발신지 및 목적지 애플리케이션이 장애있는 연결 세션을 전체적으로 또는 부분적으로 무시함으로써(예를 들어, 부분적으로 수신된 파일 또는 부분적으로 수신된 일련의 구조화된 데이터를 삭제하고, 2개의 장치가 다시 연결될 때 이전에 실패한 연결 세션에서 교환하려고 시도했었던 데이터를 교환하기 위해 그 장치들의 발신지 및 목적지 애플리케이션 간에 새로운 연결을 설정하게 하는 오류 메시지 또는 상태 메시지를 설정함으로써) 신속하고 정상적으로 통신 단절로부터 복원할 수 있게 해줄 수 있다.
TCP-유사 프로토콜은 또한 TCP-유사 프로토콜 상부에서 실행되는 파일 전송 프로토콜에서도 사용될 수 있고, 이 파일 전송 프로토콜은 2개의 장치 간의 파일 전송을 제공하기 위해 사용될 수 있으며, 패킷(예를 들어, TCP-유사 패킷)으로 전송되는 파일이 수신측에서 재구성될 수 있고 데이터 전부(다수의 TCP-유사 패킷으로 수신됨)가 수신된 후에 유효성 검사될 수 있다(또는 파일의 일부분이 수신될 때 부분적으로 유효성 검사될 수 있다). 파일은 종래의 체크섬 연산(checksum operation) 또는 해쉬 연산(hash operation)을 사용하여 유효성 검사될 수 있다. 이러한 TCP-유사 프로토콜의 상부에 계층을 이루고 있을 수 있는 양방향 바이트 스트림을 처리하는 임의의 프로토콜과 같이, 많은 서로 다른 유형의 소프트웨어들이 이러한 TCP-유사 프로토콜에서 사용될 수 있다. 이들 서로 다른 유형의 소프트웨어로는 telnet(예를 들어, 대화형 텔넷 세션의 경우), rsync, 다른 장치 상의 애플리케이션을 원격 디버깅하는 gdb over IP, 기타 등등이 있을 수 있다. 게다가, 이러한 TCP-유사 프로토콜 상부에서 실행되는 소프트웨어는 원자적 트랜잭션(atomic transaction)의 사용을 비롯한 트랜잭션-유형 프로토콜을 구현할 수 있다. TCP-유사 프로토콜은 이러한 TCP-유사 프로토콜의 상부에서 실행되는 하나 이상의 소프트웨어 계층이, 다른 시스템에서 실행되는 다른 소프트웨어와 연결을 설정하여 유지할 책임을 질 필요 없이, 그의 서비스 및 기능을 제공할 수 있게 해준다.
용어 "장치" 및 "호스트"가 바꾸어 사용될 수 있다, 즉 "장치"가 장치 및 호스트 둘다에 적용된다는 것을 잘 알 것이다. 호스트가 장치이고, 장치가 호스트로 간주될 수 있다. 그렇지만, 어떤 실시예들에서, 세션이, 호스트로부터 장치로, 호스트에 의해서만 개시될 수 있고, 그 경우에 호스트가 장치와 바꾸어 사용될 수 없다. 또한, 본 명세서에 기술된 TCP-유사 프로토콜이 독립적인 연결들의 흐름 제어 및 멀티플렉싱을 지원하는 신뢰성있는 전송 메카니즘을 제공하는 통신 프로토콜의 일례이고, 다른 대안으로서 유사한 메카니즘을 제공하는 기타 프로토콜들이 본 발명의 적어도 어떤 실시예들에서 사용될 수 있다는 것을 잘 알 것이다. 또한, 본 발명의 적어도 어떤 실시예들에서, TCP 하드웨어 가속기와 같은 하드웨어가 본 명세서에 기술된 소프트웨어를 전체적으로 또는 부분적으로 대체하기 위해 사용될 수 있다는 것을 잘 알 것이다.
도 8은 (장치 상의) 인터페이스(823) 및 (호스트 상의) 인터페이스(847)를 통해 연결되어 있는 상호연결된 장치(801) 및 호스트(803)의 일례를 나타낸 것이다. 이들 인터페이스는 USB 또는 BLUETOOTH 인터페이스와 같은 비네트워크 인터페이스로 간주될 수 있다. 환언하면, LAN(local area network)과 같은 컴퓨터 네트워크에 연결하는 데 사용되는 것이 아니라 주변 장치(예를 들어, 마우스, 키보드, 저장 장치)에 사용되는 인터페이스가 호스트(803)와 장치(801)를 연결시키는 데 사용된다. 장치(801)는 컴퓨터 네트워크에 연결하도록 설계되어 있는 인터페이스(817)를 포함하고, 호스트(803)는 인터넷과 같은 네트워크에 연결하는 데도 사용되는 인터페이스(845)(WiFi, 이더넷 또는 전화 모뎀 등)를 포함한다. 인터페이스(817)는 TCP/IP 소프트웨어 스택(815)에 의해 처리되는 TCP/IP 패킷을 전송/수신하기 위해 결합되어 있고, 인터페이스(817) 및 TCP/IP 소프트웨어 스택(815)은 장치(801)에 종래의 인터넷 또는 네트워크 연결을 제공한다. 인터페이스(845)는 TCP/IP 소프트웨어 스택(843)에 의해 처리되는 TCP/IP 패킷을 전송/수신하기 위해 결합되어 있고, 인터페이스(845) 및 TCP/IP 소프트웨어 스택(843)은 호스트(803)에 종래의 인터넷 또는 네트워크 연결을 제공한다.
호스트(803)는 인터페이스(823, 847)를 통해 장치(801) 상의 클라이언트 애플리케이션(805, 807, 809)과 데이터 및/또는 파일을 교환할 수 있는 몇개의 클라이언트 애플리케이션(831, 833, 835, 837)을 포함한다. 도 8은 호스트(803) 및 장치(801) 둘다에 있는 어떤 클라이언트 애플리케이션의 일례를 나타낸 것이며, 장치 및 호스트 중 어느 하나 또는 그 둘다에 더 많은 또는 더 적은 또는 다른 클라이언트 애플리케이션이 있을 수 있다. 도 8에 도시된 예에서, 호스트(803) 상의 클라이언트 애플리케이션은 소프트웨어 모듈들 간의 상호통신(intercommunication)을 제공하는 소켓 API(839)를 통해 '인터페이스를 통한 TCP' 소프트웨어(841) 및 TCP/IP 소프트웨어 스택(843)과 통신을 한다. 소켓 API(839)는, 소켓 API에 대한 호출에 응답하여, 스트림 기반 프로토콜에 대한 세션의 각 종단점에 열린 소켓을 제공한다. 소켓 API(819)는 장치(801)에서 유사한 기능을 제공하여, 생성될 열린 소켓이 TCP/IP 소프트웨어 스택(815)과 '인터페이스를 통한 TCP' 소프트웨어(821) 간의 통신을 설정하고 유지할 수 있게 해주고 또 클라이언트 애플리케이션(805, 807, 809)이 (선택적인 게이트키퍼(811)를 통해) TCP/IP 소프트웨어 스택과 통신을 설정하고 유지할 수 있게 해준다. 통상적으로, 한쪽에 있는 각각의 클라이언트 애플리케이션은 상대방측에 있는 대응하는 클라이언트 애플리케이션과 연결을 유지하도록 구성되어 있다. 예를 들어, 동기화 소프트웨어(835)는 장치들 간에 데이터(예를 들어, 구조화된 데이터 또는 위젯, 기타)를 교환하기 위해 동기화 소프트웨어(805)와 연결을 유지하도록 구성되어 있다. 동기화 소프트웨어(835) 및 동기화 소프트웨어(805)의 일례가 2007년 1월 7일자로 출원된, 발명의 명칭이 "Synchronization Methods and Systems(동기화 방법 및 시스템)"인 미국 특허 출원 제11/650,730호에 제공되어 있으며, 이 미국 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다. 미디어 소프트웨어(831)(iTunes와 같은 미디어 플레이어일 수 있음)는 파일 전송 소프트웨어(807)(장치 상의 iTunes와 같은 미디어 플레이어일 수 있음)와 연결을 유지하도록 구성되어 있다. 어떤 실시예들에서, 이 파일 전송 소프트웨어는 또한 파일 전송 소프트웨어(833)와도 연결을 유지하도록 구성되어 있을 수 있다. 파일 공유 소프트웨어(809)는 파일 공유 소프트웨어(837)와 연결을 유지하도록 구성되어 있다. 이들 연결은 게이트키퍼(811)와 같은 하나 이상의 선택적인 게이트키퍼 및 클라이언트 애플리케이션(831, 833, 835, 837)과 '인터페이스를 통한 TCP' 소프트웨어(841) 사이에 있을 수 있는 호스트 상의 대응하는 게이트키퍼(도시 생략)를 통해 유지될 수 있다. 적어도 어떤 실시예들에서, 이 게이트키퍼는 이러한 연결이 요망되는 경우 장치와 호스트 사이에 인증된 연결을 생성하는 역할을 한다. 도 8의 게이트키퍼는 도 1에 도시된 게이트키퍼 클라이언트(115) 및 게이트키퍼(180)와 동일하거나 그와 유사할 수 있다. 어떤 애플리케이션(예를 들어, 파일 공유, telnet 또는 gdb over IP)에 대한 연결들은 장치 상의 게이트키퍼를 완전히 우회할 수 있다.
TCP/IP 소프트웨어 스택(815), '인터페이스를 통한 TCP' 소프트웨어(821) 및 '인터페이스를 통한 TCP' 소프트웨어(841)의 동작이 도 9 내지 도 12의 설명과 관련하여 이하에서 더 기술된다. 이들 소프트웨어 컴포넌트는 본 명세서에 기술되는 멀티플렉싱된 데이터 스트림 프로토콜을 제공한다.
장치(801)는 플래쉬 메모리, 하드 드라이브, 휘발성 반도체 메모리, 기타 등등을 비롯한 복수의 저장 매체들 중 임의의 저장 매체에 저장될 수 있는 데이터(813)를 포함한다. 이 데이터는 주소록, 일정표, 할 일 항목, 및 메모에 대한 구조화된 데이터를 포함할 수 있으며, 이 데이터는 본 명세서에 기술된 바와 같이 동기화 소프트웨어(805) 및 동기화 소프트웨어(835)를 통해 동기화될 수 있다. 게다가, 데이터(813)는 또한 음악에 대한 MP3 파일, 영화에 대한 MPEG 4 파일 또는 기타 오디오 비쥬얼 미디어(audio visual media)와 같은 미디어 파일도 포함할 수 있다. 데이터(813)는 또한 기타 유형의 데이터(예를 들어, 워드 프로세싱 파일, 기타) 또는 심지어 위젯과 같은 실행가능 프로그램, 설정 정보에 관한 데이터, 그리고 이메일 또는 전화 계정 정보, 기타 등등도 포함할 수 있다. 장치측에 있는 다양한 클라이언트 애플리케이션들이 데이터에 액세스하기 위해 데이터(813)가 들어 있는 저장 장치와 통신을 한다는 것을 잘 알 것이다. 예를 들어, 파일 전송 소프트웨어(807)는 파일을 전송하기 위해 데이터(813)를 읽거나 쓸 수 있다. 호스트 장치(803)가 또한 플래쉬 메모리, 하드 드라이브 또는 휘발성 메모리 장치(예를 들어, DRAM)와 같은 데이터 저장 매체, 또는 호스트 장치(803) 상의 클라이언트 애플리케이션에 의해 사용되는 데이터를 저장하는 기타 저장 매체도 포함하고 있다는 것을 잘 알 것이다.
도 8은 호스트 장치(803)의 일례를 나타낸 것인 반면, 도 13은 호스트 장치에 대한 대안의 소프트웨어 아키텍처를 나타낸 것이다. 호스트 장치(1301)는 애플리케이션(1303, 1305, 1307)을 비롯한 몇개의 클라이언트 애플리케이션을 포함하고 있으며, 각각의 애플리케이션은 소켓 API(1309)를 통해 TCP/IP 소프트웨어 스택(1313) 및 '인터페이스를 통한 TCP' 소프트웨어(1311)에 결합될 수 있다. TCP/IP 소프트웨어 스택(1313)은 또한 USB 또는 BLUETOOTH 인터페이스(1315)를 통해 패킷을 전송 및 수신하기 위해 소켓 API(1309)를 통해 '인터페이스를 통한 TCP' 소프트웨어(1311)에도 결합될 수 있다. 루프백 인터페이스(1317)는 TCP/IP 소프트웨어 스택(1313)과 '인터페이스를 통한 TCP' 소프트웨어(1311) 간의 패킷 경로를 제공하기 위해 TCP/IP 소프트웨어 스택(1313)에 결합되어 있다. '인터페이스를 통한 TCP' 소프트웨어(1311)는 도 8의 인터페이스(847)와 유사한 인터페이스(1315)에 결합되어 있다. TCP/IP 소프트웨어 스택(1313)은 도 8에 도시된 인터페이스(817)와 유사한 인터페이스(1319)에 결합되어 있다. 도 13에 도시된 호스트와 도 8에 도시된 호스트 간의 주된 차이점은 인터페이스(847)를 통해 수신 및 전송되는 TCP-유사 패킷이 TCP/IP 소프트웨어 스택(843)에 의해서가 아니라 '인터페이스를 통한 TCP' 소프트웨어(841)에 의해 처리된다는 것이고, 반면에, 도 13에 도시된 호스트 장치의 경우에는, 인터페이스(1315)를 통해 전송 및 수신되는 TCP-유사 패킷이 '인터페이스를 통한 TCP' 소프트웨어(1311) 및 TCP/IP 소프트웨어 스택(1313) 둘다에 의해 처리된다는 것이다.
도 9는 본 발명의 일 실시예에 따른, 호스트 및 장치와 같은 2개의 시스템 간에 데이터를 교환하는 방법의 일례를 나타낸 플로우차트이다. 이 방법은 한쪽에서 시작하고 2개의 장치 간의 데이터 교환이 완료된 후에 상대방측에서 종료된다. 동작(901)에서, USB 또는 BLUETOOTH 인터페이스와 같은 비네트워크 인터페이스를 통해 지원되는 독립적인 세션을 동시에 갖는 복수의 독립적인 애플리케이션 중 적어도 하나의 애플리케이션으로부터 데이터 스트림이 수신된다. 이 데이터 스트림은 소켓 인터페이스를 통해 수신될 수 있다. 예를 들어, 미디어 소프트웨어(831)에 의해 제어되는 미디어 파일은 소켓 인터페이스를 통해 '인터페이스를 통한 TCP' 소프트웨어(841)로 미디어 파일을 전송할 수 있다. 동작(903)에서, 데이터 스트림 내의 데이터에 대한 패킷이 생성되고, 이들 패킷은 TCP-유사 헤더와 같은 헤더를 패킷에 포함하고 있다. 예를 들어, '인터페이스를 통한 TCP' 소프트웨어(841)는 데이터 스트림으로부터 패킷을 생성할 수 있고, 이들 패킷 각각은 TCP-유사 헤더를 각각의 패킷에 포함하고 있다. 동작(905)에서, 이들 패킷은 인터페이스(847)와 같은 비네트워크 인터페이스를 통해 전송된다. 차례로, 이들 패킷은 인터페이스(823)와 같은 유사한 비네트워크 인터페이스를 통해 상대방 시스템에서 수신된다. 그 다음에, 동작(909)에서, 패킷 내의 데이터가, 예를 들어, '인터페이스를 통한 TCP' 소프트웨어(821)에 의해 추출된다. 데이터의 목적지는 패킷 내의 포트 식별자로부터 결정될 수 있고, 이 포트 식별자는 데이터가 수신측 장치 상의 목적지 애플리케이션으로 전송 또는 제공될 수 있게 해준다. 데이터가 MP3 파일 또는 영화 파일, 기타 등등과 같은 파일의 일부인 경우, 동작(911)에서 그 파일이 재구성되고 선택적으로 유효성 검사된다. 이 유효성 검사는 공지된 바와 같이 파일 전체에 대한 체크섬 또는 해쉬 연산의 사용을 포함할 수 있다. 연결 동안의 임의의 시점에서, 사용자 또는 시스템에서 단절이 일어나게 하는 경우(예를 들어, USB 케이블이 장치로부터 뽑아지는 경우), 양측에서 그들의 상태를 원상 복구하고 그들의 소켓을 닫아, 2개의 장치 간의 TCP-유사 연결을 종료한다. 이것은 호스트 상의 클라이언트 및 장치 상의 서비스에 세션이 끝났음을 통지한다. 또한, 장치 상의 서비스 또는 호스트 상의 클라이언트는 언제라도 세션을 닫을 수 있으며, 상대방측은 세션이 종료되었음을 통지받게 된다.
도 10은 본 발명의 일 실시예에 따른 초기화 또는 설정 방법의 일례를 제공한다. 동작(1001)에서, 호스트의 '인터페이스를 통한 TCP' 소프트웨어는 소켓 API를 통해 제공되는 포트 "X"와 같은 포트를 통해 연결하라는 호출을, 호스트상의 iTunes와 같은 애플리케이션으로부터 수신한다. 이 호출에 응답하여, 호스트의 '인터페이스를 통한 TCP' 소프트웨어는, 동작(1003)에서, SYN TCP 패킷과 같은 TCP-유사 패킷을 생성하고, 패킷이 USB 인터페이스 또는 도 8에 도시된 인터페이스(847)와 같은 비네트워크 인터페이스를 통해 전송되게 한다. 장치의 '인터페이스를 통한 TCP' 소프트웨어는 장치의 비네트워크 인터페이스(예를 들어, USB 인터페이스일 수 있는 인터페이스(823))를 통해 TCP-유사 패킷을 수신하고, 소켓을 받아(get) TCP/IP 소프트웨어 스택(815)과 연관된 루프백 주소 상의 포트와 같은 포트를 통해 그 소켓을 연결하라는 하나 이상의 호출을 발생한다. 동작(1007)에서, 장치는 synack TCP 패킷을 생성하고, '인터페이스를 통한 TCP' 소프트웨어는 장치의 비네트워크 인터페이스를 통해 호스트의 비네트워크 인터페이스로 synack TCP-유사 패킷을 전송한다. 동작(1009)에 나타낸 바와 같이, 장치 및 호스트 둘다에 있는 '인터페이스를 통한 TCP' 소프트웨어는 어느 포트/세션이 어느 소켓과 연관되어 있는지의 정보를 유지할 수 있다.
도 11은 호스트로부터 장치로 데이터를 전송하는 방법의 일례를 나타낸 것이다. 동작(1101)에서, 호스트 상의 iTunes와 같은 호스트 상의 애플리케이션은 애플리케이션의 소켓을 통해 호스트 상의 '인터페이스를 통한 TCP' 소프트웨어로 데이터를 전송한다. 예를 들어, 호스트(803)의 경우에, 미디어 소프트웨어(831)는 애플리케이션에 대해 열린 소켓을 통해 '인터페이스를 통한 TCP' 소프트웨어(841)로 데이터를 전송한다. 동작(1103)에서, 호스트 상의 '인터페이스를 통한 TCP' 소프트웨어는 데이터를 수신하고, 패킷 내에 TCP-유사 헤더 및 그 데이터 중 적어도 일부를 갖는 TCP-유사 패킷을 생성하며, 이 패킷을 USB 인터페이스 또는 도 8에 도시된 인터페이스(847)와 같은 비네트워크 인터페이스를 통해 전송한다. 동작(1105)에서, 장치 상의 '인터페이스를 통한 TCP' 소프트웨어는 패킷으로부터 데이터를 추출하고, 이 데이터(때때로 "페이로드"라고 함)를 패킷 내의 포트들에 의해 지정된 소켓 상으로 전송한다. 도 8의 예에서, '인터페이스를 통한 TCP' 소프트웨어(821)는 인터페이스(823)를 통해 수신된 데이터를 추출하고, 이 데이터를 소켓으로 전송하며, 이 소켓은 데이터가 TCP/IP 소프트웨어 스택(815)에 제공되게 한다. 동작(1107)에서, TCP/IP 소프트웨어 스택(815)과 같은 장치 상의 TCP/IP 스택은 장치 상의 '인터페이스를 통한 TCP' 소프트웨어로부터 데이터를 획득하고, IP 및 TCP 헤더를 갖는 패킷을 생성한다. 이 경우에, IP 주소는 TCP/IP 스택에 대한 루프백 주소일 수 있다. 예를 들어, TCP/IP 소프트웨어 스택(815)은 도 13에 도시된 루프백 인터페이스와 같은 루프백 인터페이스(도시 생략)를 포함할 수 있다. 패킷은 루프백 인터페이스로부터 반환되고, 동작(1107)에서, TCP/IP 스택은 TCP 및 IP 헤더를 제거하고 데이터를 소켓을 통해 애플리케이션으로 전송한다. 애플리케이션이 호스트 상의 iTunes 애플리케이션인 도 11에 도시된 예에서, 장치 상의 수신측 애플리케이션은 장치 상의 미디어 플레이어의 일부분일 수 있는 파일 전송 소프트웨어(807)일 수 있다.
도 12는 장치로부터 호스트로 데이터를 전송하는 방법의 일례를 나타낸 것이다. 동작(1201)에서, 동기화 소프트웨어(805) 또는 미디어 플레이어 소프트웨어와 같은 장치 상의 애플리케이션은 애플리케이션에 대한 소켓을 통해 TCP/IP 소프트웨어 스택(815)과 같은 장치 상의 TCP/IP 스택 소프트웨어로 데이터를 전송한다. 동작(1203)에서, TCP/IP 스택 소프트웨어는 데이터를 패킷들로 쪼개고 TCP 및 IP 헤더를 데이터와 함께 포함시켜 패킷을 생성한다. IP 헤더 내의 IP 주소는 패킷이 소프트웨어 스택(815)과 같은 TCP/IP 소프트웨어 스택으로 반환되게 하는 루프백 주소일 수 있다. 동작(1205)에서, 패킷은 루프백 주소로 보내지고 그로부터 반환되어 TCP/IP 소프트웨어 스택에 의해 수신되며, 이 TCP/IP 소프트웨어 스택은 TCP 및 IP 헤더를 제거하고 그 데이터를 데이터 스트림으로서 장치 상의 '인터페이스를 통한 TCP' 소프트웨어(821)와 같은 '인터페이스를 통한 TCP' 소프트웨어로 전송한다. 동작(1207)에서, '인터페이스를 통한 TCP' 소프트웨어는 TCP/IP 소프트웨어 스택(815)으로부터 데이터를 수신하고, 패킷화된 데이터 및 TCP-유사 헤더를 포함하는 패킷을 생성하며, 이 패킷을 USB 프로토콜을 사용하여 인터페이스(823)와 같은 USB 인터페이스를 통해 전송하기 위해 USB 드라이버를 호출한다. 동작(1209)에서, 이들 패킷은 장치의 USB 인터페이스로부터 호스트 상의 인터페이스(847)와 같은 호스트의 USB 인터페이스로 전송된다. 그 다음에, 동작(1211)에서, '인터페이스를 통한 TCP' 소프트웨어(841)와 같은 호스트 상의 '인터페이스를 통한 TCP' 소프트웨어는 패킷을 수신하고, TCP-유사 헤더를 제거하며, 그 데이터를, 예를 들어, 소켓 API를 통해 수신측 애플리케이션으로 전송한다.
도 15는 2개의 장치 간에 파일을 교환하는 방법의 일례를 제공한다. 이 경우에, 데이터는 통상적으로 연락처 정보, 기타 등등과 같은 동기화되는 구조화된 데이터가 아니다. 오히려, 데이터는 파일 전체를 구성한다. 동작(1501)에서, 데이터가 인터페이스(823) 또는 인터페이스(847)와 같은 인터페이스를 통해 TCP-유사 헤더를 갖는 패킷으로 전송된다. 동작(1503)에서, 이들 패킷은 상대방 시스템 상의 다른 인터페이스를 통해 수신되고, 파일을 재조립할 준비를 하기 위해 다수의 패킷으로부터 데이터가 추출된다. 그 다음에, 동작(1505)에서, 파일이 재구성된다. 이것은 파일에 대한 데이터 전부가 수신된 후에 일어날 수 있거나, 데이터가 수신되고 있을 때 일어날 수 있다. 파일 전송 동안에 연결이 끊어지는 경우, 장치들이 재연결될 때 파일이 전송될 수 있도록 파일이 성공적으로 전송되지 않았다는 것을 나타내기 위해 오류 메시지 및/또는 상태 메시지가 저장된다. 파일에 대한 데이터 전부가 수신된 후에 파일이 유효성 검사될 수 있거나, 데이터가 수신되고 있을 때 파일이 일부분씩 유효성 검사될 수 있다. 유효성 검사는 동작(1507)과 같은 선택적인 동작일 수 있고, 예를 들어, 종래의 체크섬 연산 또는 해쉬 연산을 사용하여 수행될 수 있다. 도 15의 방법에 사용되는 패킷은 파일 전송 프로토콜의 일부인 정보를 포함할 수 있다. 예를 들어, 패킷은 미리 정해진 패킷 포맷을 갖는 패킷 유형 및 이 패킷 유형과 연관된 패킷 기능의 표시를 포함할 수 있다. 패킷 기능은 파일 전송 프로토콜 소프트웨어의 동작을 지정할 수 있다. 단절이 있는 경우에 오류 메시지 또는 상태 메시지는, 연결이 재설정될 때 파일이 전송될 수 있도록, 연결이 중단되기 전에 일부만이 전송된 파일의 식별자를 적어도 포함할 수 있다.
이하는 도 8 내지 도 13, 도 14b 및 도 15에 도시된 하나 이상의 실시예의 구현에 대한 설명이며, 이 구현은 장치 및 호스트가 USB를 통해 통신을 할 수 있게 해준다. 이 구현은 장치 통신 프로토콜(Device Communication Protocol)이라고 할 수 있으며, 이 장치 통신 프로토콜은 (예를 들어, iTunes 미디어 동기화를 위한) 파일 전송 소프트웨어(807) 및 구조화된 데이터 동기화(동기화 소프트웨어(805) 등)와 같은 다수의 서비스가 부가의 USB 종단점을 필요로 하지 않고 장치와 동시에 통신을 할 수 있게 해주는 데 사용될 수 있다. 이 구현에서 통신 프로토콜은 벤더 고유의 인터페이스로서 구현된다. 벤더 고유의 인터페이스는 2개의 종단점, 즉 벌크 입력(Bulk Input) 종단점 및 벌크 출력(Bulk Output) 종단점을 이용한다.
이 프로토콜이 정확히 말해서 고전적인 TCP가 아닌 반면에, 흐름 제어, 연결 설정/종료 및 멀티플렉싱을 위해 TCP-유사 메카니즘을 사용한다.
이 장치 통신 프로토콜에 따른 인터페이스는 다음과 같은 인터페이스를 찾아냄으로써 식별된다.
- 장치의 벤더 ID가 Apple (0x05 AC)임
- 인터페이스 클래스가 벤더 고유임(255)
- 인터페이스 서브클래스가 254임
- 인터페이스 프로토콜이 2임
인터페이스 #1 - 벤더 고유
대안의 설정 0
종단점의 수 2
인터페이스 클래스: 255 (벤더 고유)
인터페이스 서브클래스: 254 (벤더 고유)
인터페이스 프로토콜: 2
종단점 0x85 - 벌크 입력(Bulk Input)
주소: 0x85 (IN)
속성: 0x02 (벌크 동기화 없는 데이터 종단점)
최대 패킷 크기: 512
폴링 간격: 0 (종단점이 결코 NAK하지 않음)
종단점 0x04 - 벌크 출력(Bulk Output)
주소: 0x04 (OUT)
속성: 0x02 (벌크 동기화 없는 데이터 종단점)
최대 패킷 크기: 512
폴링 간격: 0 (종단점이 결코 NAK하지 않음)
1) 메시지 헤더
모든 데이터가 메시지 형태로 전송된다. 모든 메시지가 이하의 헤더로 시작한다. 모든 헤더가 네트워크 바이트 순서로 되어 있다.
AppleUSBMobileDeviceMessageHeader
+-----+-----+-----+-----+-----+-----+-----+-----+
｜Type(32 비트) ｜ Length(32 비트) ｜
+-----+-----+-----+-----+-----+-----+-----+-----+
2개의 정의된 메시지 유형이 있다:
0 - 버전 메시지
6 - TCP 메시지
길이 필드는 수신된 USB 데이터그램이 올바른 크기이었는지를 검증하는 데 사용된다. 이 길이는 메시지 헤더의 크기를 포함한다. USB는 데이터를 패킷으로 전송한다. 벌크 USB 종단점의 경우, 최대 패킷 크기가 속도에 의해 결정된다. 전체 크기의 패킷(full sized packet)을 계속 전송하고 있는 한, 데이터가 모두 프레임의 일부인 것으로 간주된다. 프레임을 끝내기 위해, 최대 패킷 크기보다 작은 패킷이 전송되어야만 한다. 프레임이 정확히 2개의 전체 크기의 패킷의 경계에서 정상적으로 끝나는 경우('프레임 크기 % 최대 패킷 크기'가 0인 경우), 프레임의 끝을 나타내기 위해 0 길이의 패킷(zero length packet)이 전송될 수 있다. 헤더 내의 길이 필드가 수신된 프레임의 크기와 일치해야만 한다. 일치하지 않는 경우, 프레임이 폐기되어야만 한다. 장애를 추적하기 위해 오류가 로그되어야만 한다. 대부분의 경우에, 후속 프레임도 역시 엉망으로 되며 폐기되어야만 한다. 이러한 오류는 일어나서는 안된다. 그 손실이 TCP 메시지로 검출되고, 그 TCP 연결이 종료된다.
2) 버전 메시지
사용될 프로토콜의 버전을 협상하기 위해 시작 시에 버전 메시지가 교환된다. 장치가 나타날 때, 장치는 버전 메시지를 기다려야만 한다. 호스트는 제1 버전 메시지를 전송할 책임이 있다. 버전 메시지는 이하의 포맷을 갖는다.
+-----+-----+-----+-----+-----+-----+-----+-----+
｜0 ｜ 이 메시지의 크기 ｜
+-----+-----+-----+-----+-----+-----+-----+-----+
｜Version(32 비트) ｜ Features(32 비트) ｜
+-----+-----+-----+-----+-----+-----+-----+-----+
｜ 0이어야 함(32 비트)
+-----+-----+-----+-----+
Version
호스트->장치 - 요청된 버전
장치 -> 호스트 - 지원되는 버전
Features
호스트->장치
원하는 특징을 나타내는 비트필드
장치->호스트
사용될 특징을 나타내는 비트필드
호스트는 이 구현을 위해 버전을 1로 설정해야 한다. 현재 지원되는 특징이 없기 때문에 특징은 0이어야 한다. 장래에, 버전을 증가시키지 않고 체크섬 등의 특징이 추가될 수 있다. 그에 부가하여, 완전히 새로운 버전을 정의하지 않고 특징 필드를 사용하여 체크섬이 가능하게 될 수 있다. 특징 필드는 버전에 기초하여 해석된다. 버전 1에 대한 특징 필드 내의 다양한 비트들은 버전 2에서의 특징들과 다른 의미를 가질 수 있다. 호스트는 특징 필드 내의 대응하는 비트를 세트(set)시킴으로써 특징을 요청할 수 있다.
장치는 지원되는 버전으로 응답해야만 한다. 장치는 하나의 버전만을 지원할 수 있거나, 다수의 버전들을 지원할 수 있다. 장치가 호스트에 의해 요청되는 버전을 지원하는 경우, 장치는 그 버전으로 응답해야만 한다. 장치가 단지 다른 버전만을 지원하는 경우, 장치는 그가 지원하는 버전으로 응답해야만 한다. 장치가 요청된 버전으로 응답하는 경우, 장치는 지원되지 않는 특징들을 마스킹 제거(masked out)한 채로 특징 비트필드(feature bitfield)를 요청된 비트로 설정해야만 한다. 응답 버전이 요청된 버전과 일치하지 않는 경우, 특징 필드가 0으로 되어야만 한다.
장치가 호스트가 이해하지 못하는 버전을 나타내는 버전 메시지로 응답하는 경우, 호스트는 장치와 통신하기 위해 보다 새로운 소프트웨어를 필요로 할지도 모른다. 장치가 호스트가 지원하는 요청된 버전과 다른 버전으로 응답하는 경우, 호스트는 특정의 특징을 요청하기 위해 특징 필드에서 새로 협상된 버전 및 비트가 세트되어 있는 다른 버전 메시지를 전송할지도 모른다. 장치는 다수의 버전 메시지를 처리할 준비가 되어 있어야 한다.
3) TCP 메시지
USB를 통한 데이터 통신의 경우, TCP 메시지가 사용된다. TCP 메시지는 프로토콜 값이 6이고 그 크기가 헤더를 포함하는 전체 메시지의 크기로 설정되어 있는 AppleUSBMobileDeviceHeader이다. AppleUSBMobileDeviceHeader 다음에 TCP 헤더가 온다. 가변적인 헤더 길이 및 TCP 옵션들이 현재 지원되지 않는다. 페이로드는, 있는 경우, TCP 헤더 다음에 온다.
+-----+-----+-----+-----+-----+-----+-----+-----+
｜6 ｜ 이 메시지의 크기 ｜
+-----+-----+-----+-----+-----+-----+-----+-----+
｜src 포트 ｜dst 포트 ｜순서
+-----+-----+-----+-----+-----+-----+-----+-----+
｜확인응답 ｜h1｜플래그｜윈도우 크기｜
+-----+-----+-----+-----+-----+-----+-----+-----+
｜체크섬 ｜긴급 포인터｜
+-----+-----+-----+-----+
긴급 포인터(urgent pointer) 및 체크섬 필드는 현재 사용되지 않으며, 이 구현에서 0으로 설정되어야만 한다. USB가 신뢰성있어야 하기 때문에, 확인 응답이 묵시적(implicit)이다. 윈도우를 업데이트하기 위해 순서 ACK 패킷이 전송된다.
3.1) 연결의 개시
연결은 호스트가 TCP SYN 패킷을 장치로 전송하는 것에 의해 설정된다. dst(목적지) 포트는 호스트 상의 어느 서비스에 연결해야 하는지를 결정하는 데 사용된다. 이 연결을 임의의 다른 연결들과 구별하기 위해 src(발신지) 포트/dst 포트 튜플(tuple)이 고유해야만 한다.
연결이 수락되는 경우 장치는 SYN 패킷에 대해 SYN/ACK 패킷으로 응답을 한다. 자원이 충분하지 않는 경우 또는 요청된 포트를 통해 리스닝하는 서비스가 없는 경우, 장치는 연결 요청을 거부할 수 있다. 연결을 거부하기 위해, 장치는 TCP RST를 전송해야만 한다.
통상적인 TCP 연결은 3 방향 핸드쉐이크(three way handshake)를 포함한다. USB가 신뢰성있어야 하기 때문에, 이 구현에서 호스트로부터 장치로의 ACK인 세번째 패킷이 폐기(drop)될 수 있다(사용되지 않을 수 있다). 장치가 일단 SYN/ACK 패킷을 전송하면 장치는 연결이 설정된 것으로 간주한다. 호스트가 일단 SYN/ACK 패킷을 수신하면 호스트는 연결이 설정된 것으로 간주한다.
SYN 플래그에 대한 순서 번호(sequence number) 및 확인응답 번호(acknowledgement number)가 증가되는데, 그 이유는 이들 번호가 실제(고전적인) TCP에 있기 때문이다.
8의 윈도우 천이 값이 사용되지만, 이 옵션은 협상되지 않는다.
3.2) 연결의 종료
장치 또는 호스트는 연결을 끊고자 할 때, TCP RST를 전송한다. TCP RST에 응답하여, 호스트 또는 장치는 발신지 및 목적지 TCP 포트에 의해 지정된 연결과 연관된 모든 자원들을 원상 복구해야 한다.
이 구현에서는, FIN 플래그가 사용되지 않는다. 이 구현에서는, 반폐쇄(half close)가 없다.
3.3) 데이터 전송
흐름 제어를 위해 순서 번호 및 확인응답 번호가 사용된다. 호스트 또는 장치가 페이로드를 갖는 TCP 메시지를 전송할 때, 순서 번호가 전송된 페이로드의 크기만큼 증가된다. 호스트 및 장치는 마지막 확인응답된 데이터 및 마지막 광고된 윈도우를 넘어서 데이터를 전송할 수 없다. 이것이 흐름 제어가 구현되는 방법이다. 전송된 모든 데이터가 수신될 것으로 가정된다. 이 구현에서는, 재전송(retransmit)이 지원되지 않는다. 이 특징이 요망되는 경우, 대안의 실시예는 재전송을 사용할 수 있다. 데이터를 전송하는 측은 데이터가 전송되면 그 데이터의 로컬 사본을 폐기할 수 있다.
3.4) 데이터 수신
데이터가 순서대로 도착하는 것으로 가정된다. 호스트 또는 장치가 비순차적(out of order) 전송을 수신하는 경우, 순서 번호에 기초하여, 호스트는 연결을 끊고 TCP RST를 전송해야 한다.
호스트 또는 장치는, 더 많은 버퍼 공간이 이용가능한 경우, 상대방측이 더 많은 데이터를 전송할 수 있다는 것을 알려주기 위해 업데이트된 윈도우를 갖는 TCP ACK 패킷을 전송할 수 있다.
본 명세서에서 "일 실시예" 또는 "실시예"라는 말은 그 실시예와 관련하여 기술된 특정의 특징, 구조 또는 특성이 본 발명의 적어도 하나의 실시예에 포함되어 있다는 것을 의미한다. 본 명세서의 여러 곳에서 등장하는 "일 실시예에서"라는 표현이 모두 동일한 실시예를 말하는 것은 아니다.
이상의 명세서에서, 본 발명이 그의 구체적인 실시예들과 관련하여 기술되어 있다. 그렇지만, 본 발명의 광의의 사상 및 범위를 벗어나지 않고 본 발명에 다양한 수정 및 변경이 행해질 수 있다는 것이 명백할 것이다. 그에 따라, 본 명세서 및 첨부 도면은 제한적인 의미가 아니라 예시적인 것으로 간주되어야 한다.

Claims (20)

  1. 데이터 처리 시스템으로 하여금 방법을 수행하도록 야기하는 실행가능 프로그램 명령어들을 포함하는 컴퓨터 판독가능 매체로서,
    상기 방법은,
    제1 네트워크 스택 소프트웨어에서 헤더들을 포함하는 패킷들을 수신하는 단계 - 상기 패킷들은 비네트워크 물리 인터페이스(a non-network physical interface)를 통해 다른 장치로부터 직접적으로 수신됨 -,
    상기 패킷들로부터 데이터를 추출하는 단계 -
    상기 추출하는 단계는 상기 제1 네트워크 스택 소프트웨어에 의해 수행되고,
    상기 비네트워크 물리 인터페이스는 IP(Internet Protocol) 주소들을 사용하도록 설계되어 있지 않으며,
    상기 헤더들은 흐름 제어 및 시퀀싱을 위한 정보를 포함하고 파일 전송 애플리케이션을 위한 포트와 연관되어 있고, 상기 패킷들은 TCP(Transmission Control Protocol)-유사 헤더들을 포함하고,
    상기 헤더들은 n개(n≥2)의 애플리케이션이 상기 비네트워크 물리 인터페이스를 통해 n개의 독립적 동시 세션(n independent concurrent sessions)을 유지할 수 있게 해줌 -, 및
    상기 패킷들 내의 데이터로부터 파일을 재구성하는 단계를 포함하는
    컴퓨터 판독가능 매체.
  2. 제1항에 있어서, 상기 방법은,
    상기 파일에 대한 모든 데이터가 수신된 후에 상기 파일의 유효성을 검사하는 단계를 더 포함하고,
    상기 유효성을 검사하는 단계는 체크섬 연산 또는 해쉬 연산 중 적어도 하나를 포함하는 컴퓨터 판독가능 매체.
  3. 제2항에 있어서, 상기 패킷들은 미리 정해진 패킷 포맷을 갖는 패킷 유형 및 상기 패킷 유형과 연관된 패킷 기능의 표시를 포함하는 컴퓨터 판독가능 매체.
  4. 제3항에 있어서, 상기 비네트워크 물리 인터페이스의 표준 프로토콜은 IP 주소들을 사용하지 않고,
    상기 비네트워크 물리 인터페이스가 USB(Universal Serial Bus) 호환(compliant) 유선 직렬 인터페이스 또는 BLUETOOTH 호환 무선 인터페이스 중 하나인 컴퓨터 판독가능 매체.
  5. 삭제
  6. 제1항에 있어서, 상기 TCP-유사 헤더들은 상기 파일 전송 애플리케이션에 대한 소켓과 연관되어 있는 컴퓨터 판독가능 매체.
  7. 제6항에 있어서, 상기 방법은,
    상기 패킷들로부터 추출된 데이터를 포함하는 추가의 패킷들을 생성하는 단계 - 상기 추가의 패킷들은 TCP/IP 헤더들을 포함하며, 여기서 IP 헤더가 루프백 주소를 지정하고 있음 -, 및
    상기 추가의 패킷들로부터 상기 데이터를 추출하고 상기 추가의 패킷들로부터 추출된 상기 데이터를 상기 파일 전송 애플리케이션에 제공하는 단계를 더 포함하는 컴퓨터 판독가능 매체.
  8. 제7항에 있어서, 상기 추가의 패킷들을 생성하는 단계 및 상기 추가의 패킷들로부터 상기 데이터를 추출하는 단계가 IP 프로토콜을 통해 인터넷에 연결하기 위한 다른 인터페이스에 동작적으로 결합되는 제2 네트워크 스택 소프트웨어에 의해 수행되는 컴퓨터 판독가능 매체.
  9. 기계 구현 방법으로서,
    제1 네트워크 스택 소프트웨어에서 헤더들을 포함하는 패킷들을 수신하는 단계 - 상기 패킷들은 비네트워크 물리 인터페이스를 통해 다른 장치로부터 직접적으로 수신됨 -,
    상기 패킷들로부터 데이터를 추출하는 단계 -
    상기 추출하는 단계는 상기 제1 네트워크 스택 소프트웨어에 의해 수행되고,
    상기 비네트워크 물리 인터페이스는 IP(Internet Protocol) 주소들을 사용하도록 설계되어 있지 않으며,
    상기 헤더들은 흐름 제어 및 시퀀싱을 위한 정보를 포함하고 파일 전송 애플리케이션을 위한 포트와 연관되어 있고, 상기 패킷들은 TCP(Transmission Control Protocol)-유사 헤더들을 포함하고,
    상기 헤더들은 n개의 애플리케이션(n ≥2)이 상기 비네트워크 물리 인터페이스를 통해 n개의 독립적 동시 세션을 유지할 수 있게 해줌 -, 및
    상기 패킷들 내의 데이터로부터 파일을 재구성하는 단계를 포함하는
    기계 구현 방법.
  10. 제9항에 있어서, 상기 방법은
    상기 파일에 대한 모든 데이터가 수신된 후에 상기 파일의 유효성을 검사하는 단계를 더 포함하고,
    상기 유효성을 검사하는 단계는 체크섬 연산 또는 해쉬 연산 중 적어도 하나를 포함하는 기계 구현 방법.
  11. 제10항에 있어서, 상기 패킷들은 미리 정해진 패킷 포맷을 갖는 패킷 유형 및 상기 패킷 유형과 연관된 패킷 기능의 표시를 포함하는 기계 구현 방법.
  12. 제11항에 있어서, 상기 비네트워크 물리 인터페이스의 표준 프로토콜이 IP 주소들을 사용하지 않고,
    상기 비네트워크 물리 인터페이스가 USB(Universal Serial Bus) 호환 유선 직렬 인터페이스 또는 BLUETOOTH 호환 무선 인터페이스 중 하나인 기계 구현 방법.
  13. 삭제
  14. 제9항에 있어서, 상기 TCP-유사 헤더들은 상기 파일 전송 애플리케이션을 위한 소켓과 연관되어 있는 기계 구현 방법.
  15. 제14항에 있어서, 상기 방법은,
    상기 패킷들로부터 추출된 데이터를 포함하는 추가의 패킷들을 생성하는 단계 - 상기 추가의 패킷들은 TCP/IP 헤더들을 포함하고, 여기서 IP 헤더가 루프백 주소를 지정하고 있음 -, 및
    상기 추가의 패킷들로부터 상기 데이터를 추출하고 상기 추가의 패킷들로부터 추출된 상기 데이터를 상기 파일 전송 애플리케이션에 제공하는 단계를 더 포함하는 기계 구현 방법.
  16. 제15항에 있어서, 상기 추가의 패킷들을 생성하는 단계 및 상기 추가의 패킷들로부터 상기 데이터를 추출하는 단계는 IP 프로토콜을 통해 인터넷에 연결하기 위한 다른 인터페이스에 동작적으로 결합되는 제2 네트워크 스택 소프트웨어에 의해 수행되는 기계 구현 방법.
  17. 데이터 처리 시스템으로서,
    네트워크 스택 소프트웨어에서 헤더들을 포함하는 패킷들을 수신하는 수단 - 상기 패킷들은 비네트워크 물리 인터페이스를 통해 다른 장치로부터 직접적으로 수신됨 -,
    상기 패킷들로부터 데이터를 추출하는 수단 -
    상기 추출은 상기 네트워크 스택 소프트웨어에 의해 수행되고,
    상기 비네트워크 물리 인터페이스는 IP(Internet Protocol) 주소들을 사용하도록 설계되어 있지 않으며,
    상기 헤더들은 흐름 제어 및 시퀀싱을 위한 정보를 포함하고 파일 전송 애플리케이션을 위한 포트와 연관되어 있고, 상기 패킷들은 TCP(Transmission Control Protocol)-유사 헤더들을 포함하고,
    상기 헤더들은 n개의 애플리케이션(n ≥2)이 상기 비네트워크 물리 인터페이스를 통해 n개의 독립적 동시 세션을 유지할 수 있게 해줌 -, 및
    상기 패킷들 내의 데이터로부터 파일을 재구성하는 수단을 포함하는
    데이터 처리 시스템.
  18. 데이터 처리 시스템 상에서 실행될 실행가능 프로그램 명령어들을 포함하는 컴퓨터 판독가능 매체로서,
    장치 상의 제1 인터페이스를 통해 전송하기 위한 패킷들을 생성하고 상기 제1 인터페이스를 통해 수신된 패킷들로부터 데이터를 추출하는, 상기 장치 상에 저장된 제1 네트워크 스택 소프트웨어 - 상기 제1 네트워크 스택 소프트웨어는 TCP/IP 스택을 포함함 -,
    상기 장치 상의 제2 인터페이스를 통해 전송하기 위한 패킷들을 생성하고 상기 제2 인터페이스를 통해 수신된 패킷들로부터 데이터를 추출하는, 상기 장치 상에 저장된 제2 네트워크 스택 소프트웨어 - 상기 제2 네트워크 스택 소프트웨어는 상기 제1 네트워크 스택 소프트웨어와 통신을 하도록 구성(configure)되어 있으며, 상기 제2 인터페이스는 다른 시스템 상의 제3 인터페이스에 직접적으로 통신 가능하게 결합되도록 구성되어 있고, 상기 제2 네트워크 스택 소프트웨어는 상기 제2 인터페이스를 통해 수신된 패킷들로부터 추출된 데이터를 상기 제1 네트워크 스택 소프트웨어를 통해 전송하도록 구성되어 있으며, 상기 제2 네트워크 스택 소프트웨어는 상기 제2 인터페이스를 위해 설계된 프로토콜을 사용하여 패킷들을 전송 및 수신하도록 구성되어 있음 -, 및
    상기 제2 인터페이스를 통해 수신된 상기 패킷들로부터 추출된 상기 데이터를 수신하고 또한 상기 패킷들로부터 추출된 상기 데이터로부터 파일을 재구성하기 위해 상기 제1 네트워크 스택 소프트웨어와 통신하도록 동작적으로 결합된, 상기 장치 상에 저장된 파일 전송 프로토콜 소프트웨어를 포함하며,
    상기 제2 네트워크 스택 소프트웨어는 IP 헤더를 생성하지 않는 TCP 호환 스택을 포함하는, 컴퓨터 판독가능 매체.
  19. 제18항에 있어서, 상기 파일 전송 프로토콜 소프트웨어는 체크섬 연산 또는 해쉬 연산 중 적어도 하나에 의해, 상기 파일에 대한 모든 데이터가 수신된 후에 상기 파일의 유효성을 검사하는 컴퓨터 판독가능 매체.
  20. 제19항에 있어서, 상기 패킷들은 미리 정해진 패킷 포맷을 갖는 패킷 유형 및 이 패킷 유형과 연관된 패킷 기능의 표시를 포함하는 컴퓨터 판독가능 매체.
KR1020127016789A 2007-06-08 2008-05-08 트랜잭션 기반 통신을 위한 파일 프로토콜 KR101283293B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US11/760,686 US20080307102A1 (en) 2007-06-08 2007-06-08 Techniques for communicating data between a host device and an intermittently attached mobile device
US11/760,686 2007-06-08
US94590407P 2007-06-22 2007-06-22
US60/945,904 2007-06-22
US11/770,697 US20080307109A1 (en) 2007-06-08 2007-06-28 File protocol for transaction based communication
US11/770,697 2007-06-28
PCT/US2008/005949 WO2008153651A1 (en) 2007-06-08 2008-05-08 File protocol for transaction based communication

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020107000347A Division KR101179788B1 (ko) 2007-06-08 2008-05-08 트랜잭션 기반 통신을 위한 파일 프로토콜

Publications (2)

Publication Number Publication Date
KR20120085341A KR20120085341A (ko) 2012-07-31
KR101283293B1 true KR101283293B1 (ko) 2013-08-23

Family

ID=39811494

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020107000347A KR101179788B1 (ko) 2007-06-08 2008-05-08 트랜잭션 기반 통신을 위한 파일 프로토콜
KR1020127016789A KR101283293B1 (ko) 2007-06-08 2008-05-08 트랜잭션 기반 통신을 위한 파일 프로토콜

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020107000347A KR101179788B1 (ko) 2007-06-08 2008-05-08 트랜잭션 기반 통신을 위한 파일 프로토콜

Country Status (8)

Country Link
US (1) US20080307109A1 (ko)
EP (2) EP2171972B1 (ko)
KR (2) KR101179788B1 (ko)
CN (1) CN101682634B (ko)
AT (1) ATE475254T1 (ko)
DE (1) DE602008001832D1 (ko)
HK (2) HK1126591A1 (ko)
WO (1) WO2008153651A1 (ko)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8239544B2 (en) * 2005-06-17 2012-08-07 Microsoft Corporation Removable storage content transfer
US8666366B2 (en) 2007-06-22 2014-03-04 Apple Inc. Device activation and access
US7730200B2 (en) * 2007-03-14 2010-06-01 Hewlett-Packard Development Company, L.P. Synthetic bridging for networks
US8649393B2 (en) * 2007-08-30 2014-02-11 Broadcom Corporation Method and system for setting alternative device classes within the MTP protocol
US9477395B2 (en) 2007-09-04 2016-10-25 Apple Inc. Audio file interface
US10091345B2 (en) * 2007-09-04 2018-10-02 Apple Inc. Media out interface
US8230149B1 (en) * 2007-09-26 2012-07-24 Teradici Corporation Method and apparatus for managing a peripheral port of a computer system
US20100036957A1 (en) * 2008-08-08 2010-02-11 Oracle International Corporation Method and System for Implementing Transfer of a Network Session
US8965954B2 (en) * 2008-10-21 2015-02-24 Google Inc. Always ready client/server data synchronization
CA2741216A1 (en) 2008-10-21 2010-04-29 Google Inc. Search based specification for data synchronization
US8103631B2 (en) * 2008-11-19 2012-01-24 Sandisk Il Ltd Merging files on storage and retrieve
US8275315B2 (en) 2009-10-14 2012-09-25 Sony Corporation System and method for transmitting data over an audio communication link
EP2523386B1 (en) * 2010-01-05 2019-03-13 Gemalto SA Communication method for machine-type-communication and equipment thereof
US20130060558A1 (en) * 2011-09-07 2013-03-07 Jason Schultz Updating of interfaces in non-emulated environments by programs in the emulated environment
KR101984217B1 (ko) * 2012-01-26 2019-05-30 삼성전자주식회사 기기들 간 통신 시 기기에 대한 정보를 교환하기 위한 장치 및 방법
US8954640B1 (en) * 2012-02-09 2015-02-10 Xilinx, Inc. In-system programming of memory external to integrated circuit
US9237215B2 (en) * 2012-02-10 2016-01-12 Time Warner Cable Enterprises Llc Remote activation of mobile applications
KR20140124189A (ko) * 2013-04-16 2014-10-24 삼성전자주식회사 전자 장치에서 파일 전송 장치 및 방법
US9355034B2 (en) 2013-12-31 2016-05-31 Samsung Electronics Co., Ltd. Removal and optimization of coherence acknowledgement responses in an interconnect
JP2017034482A (ja) * 2015-07-31 2017-02-09 キヤノン株式会社 画像形成装置、その制御方法、及びプログラム
KR101948622B1 (ko) * 2016-02-15 2019-02-15 한국전자통신연구원 광대역 네트워크 환경을 위한 실시간 전송 파일 재구성 장치 및 방법
US10484181B2 (en) * 2016-12-12 2019-11-19 Datiphy Inc. Streaming non-repudiation for data access and data transaction
US11151120B2 (en) * 2019-03-29 2021-10-19 Paypal, Inc. Framework for data validity during data processing for multiple processing stacks
CN113691589B (zh) * 2021-07-27 2023-12-26 杭州迪普科技股份有限公司 报文传输方法、装置及系统
CN115085791B (zh) * 2022-04-29 2024-03-22 航天科工空间工程发展有限公司 一种星上处理载荷软件在轨上注及重构方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002502189A (ja) * 1998-01-29 2002-01-22 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー 移動データ転送用通信システム
US20060098653A1 (en) * 2002-11-12 2006-05-11 Mark Adams Stateless accelerator modules and methods
WO2006133764A2 (en) * 2005-06-17 2006-12-21 Fotonation Vision Limited A method for establishing a paired connection between media devices

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4914624A (en) * 1988-05-06 1990-04-03 Dunthorn David I Virtual button for touch screen
US5303302A (en) * 1992-06-18 1994-04-12 Digital Equipment Corporation Network packet receiver with buffer logic for reassembling interleaved data packets
EP0626635B1 (en) * 1993-05-24 2003-03-05 Sun Microsystems, Inc. Improved graphical user interface with method for interfacing to remote devices
US6792337B2 (en) * 1994-12-30 2004-09-14 Power Measurement Ltd. Method and system for master slave protocol communication in an intelligent electronic device
US5941988A (en) * 1997-01-27 1999-08-24 International Business Machines Corporation Session and transport layer proxies via TCP glue
US5850218A (en) * 1997-02-19 1998-12-15 Time Warner Entertainment Company L.P. Inter-active program guide with default selection control
US6433801B1 (en) * 1997-09-26 2002-08-13 Ericsson Inc. Method and apparatus for using a touch screen display on a portable intelligent communications device
US6032191A (en) * 1997-10-28 2000-02-29 International Business Machines Corporation Direct coupling for data transfers
US6246683B1 (en) * 1998-05-01 2001-06-12 3Com Corporation Receive processing with network protocol bypass
US6389029B1 (en) * 1998-11-10 2002-05-14 Nortel Networks Limited Local area network incorporating universal serial bus protocol
US6765909B1 (en) * 1999-04-22 2004-07-20 Nortel Networks Limited Method and apparatus for providing support for multiple QoS levels within a third generation packet data session
US6678246B1 (en) * 1999-07-07 2004-01-13 Nortel Networks Limited Processing data packets
US6754709B1 (en) * 2000-03-29 2004-06-22 Microsoft Corporation Application programming interface and generalized network address translator for intelligent transparent application gateway processes
US20030235206A1 (en) * 2001-02-15 2003-12-25 Tantivy Communications, Inc. Dual proxy approach to TCP performance improvements over a wireless interface
US7292588B2 (en) * 2001-05-01 2007-11-06 Milley Milton E Wireless network computing
CA2388938C (en) * 2001-06-08 2010-05-04 The Distributions Systems Research Institute Terminal-to-terminal communication connection control system for ip full service
JP2003005912A (ja) * 2001-06-20 2003-01-10 Hitachi Ltd タッチパネル付きディスプレイ装置及び表示方法
US7345671B2 (en) 2001-10-22 2008-03-18 Apple Inc. Method and apparatus for use of rotational user inputs
US7411934B2 (en) * 2002-02-12 2008-08-12 Broadcom Corporation Packetized audio data operations in a wireless local area network device
US8037224B2 (en) * 2002-10-08 2011-10-11 Netlogic Microsystems, Inc. Delegating network processor operations to star topology serial bus interfaces
US7673074B1 (en) * 2002-10-24 2010-03-02 Emulex Design & Manufacturing Corporation Avoiding port collisions in hardware-accelerated network protocol
US7127541B2 (en) * 2002-12-23 2006-10-24 Microtune (Texas), L.P. Automatically establishing a wireless connection between adapters
US7627343B2 (en) 2003-04-25 2009-12-01 Apple Inc. Media player system
US20050021680A1 (en) * 2003-05-12 2005-01-27 Pete Ekis System and method for interfacing TCP offload engines using an interposed socket library
US7506057B2 (en) * 2005-06-17 2009-03-17 Fotonation Vision Limited Method for establishing a paired connection between media devices
US7287077B2 (en) * 2003-08-07 2007-10-23 International Business Machines Corporation Reservation of TCP/UDP ports using UID, GID or process name
US20090024746A1 (en) * 2003-09-25 2009-01-22 Eric Welch Method and apparatus for host controller operations over a network
US7673066B2 (en) * 2003-11-07 2010-03-02 Sony Corporation File transfer protocol for mobile computer
EP1569491A3 (en) * 2004-02-24 2006-11-02 Lg Electronics Inc. Group network system using bluetooth and generating method thereof
CN1930829B (zh) * 2004-03-08 2011-09-07 皇家飞利浦电子股份有限公司 用于在分布式uwb mac中启用wusb应用的系统和方法
US7861006B2 (en) * 2004-03-23 2010-12-28 Mcnulty Scott Apparatus, method and system for a tunneling client access point
US20060023731A1 (en) * 2004-07-29 2006-02-02 Eduardo Asbun Method and apparatus for processing data in a communication system
US20060045098A1 (en) * 2004-08-31 2006-03-02 Krause Michael R System for port mapping in a network
US7392323B2 (en) * 2004-11-16 2008-06-24 Seiko Epson Corporation Method and apparatus for tunneling data using a single simulated stateful TCP connection
US7353113B2 (en) * 2004-12-07 2008-04-01 Sprague Michael C System, method and computer program product for aquatic environment assessment
US20060165108A1 (en) * 2005-01-21 2006-07-27 Mr. Sezen Uysal Method and system for unidirectional packet processing at data link layer
JP4599196B2 (ja) * 2005-03-11 2010-12-15 株式会社アドイン研究所 中継装置、通信システム、これらの制御方法及び制御プログラム
US20060247057A1 (en) * 2005-04-28 2006-11-02 Green Anthony E Logic Interface Engine System and Method
GB2426897A (en) * 2005-06-01 2006-12-06 Agilent Technologies Inc Transferring control and signalling data between protocol stack layers by inserting it into Destination Options Headers of IPv6 packets
US7551618B2 (en) * 2005-06-09 2009-06-23 Digi International Stack bypass application programming interface
US7675933B2 (en) * 2005-09-23 2010-03-09 Palm, Inc. System and method for enabling radio operations on a wireless computing device
US7633076B2 (en) 2005-09-30 2009-12-15 Apple Inc. Automated response to and sensing of user activity in portable devices
US7644303B2 (en) * 2005-10-07 2010-01-05 Agere Systems Inc. Back-annotation in storage-device array
US8078788B2 (en) * 2005-12-08 2011-12-13 Sandisk Technologies Inc. Media card command pass through methods
EP1798659A1 (en) * 2005-12-19 2007-06-20 Axalto SA Personal token with parental control
CN101110759A (zh) * 2006-07-20 2008-01-23 朗迅科技公司 用于因特网协议电视网络的对等文件下载系统
US8718065B2 (en) * 2006-08-15 2014-05-06 Broadcom Corporation Transmission using multiple physical interface
US8484335B2 (en) * 2006-11-06 2013-07-09 At&T Intellectual Property I, L.P. Methods, systems, and computer products for download status notification
US7778971B2 (en) 2007-01-07 2010-08-17 Apple Inc. Synchronization methods and systems
US7730200B2 (en) * 2007-03-14 2010-06-01 Hewlett-Packard Development Company, L.P. Synthetic bridging for networks
US20080307102A1 (en) * 2007-06-08 2008-12-11 Galloway Curtis C Techniques for communicating data between a host device and an intermittently attached mobile device
US7865142B2 (en) * 2007-06-14 2011-01-04 Broadcom Corporation Method and system for multisession bluetooth communication using multiple physical (PHY) layers
US7818486B2 (en) * 2008-08-15 2010-10-19 Icron Technologies Corporation Method and apparatus for connecting USB devices to a remote computer
EP2445170B1 (en) * 2010-10-19 2014-10-08 Vodafone Holding GmbH Device and method for contactless short range communication
US9619417B2 (en) * 2011-06-17 2017-04-11 Alcatel Lucent Method and apparatus for remote delivery of managed USB services via a mobile computing device

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002502189A (ja) * 1998-01-29 2002-01-22 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー 移動データ転送用通信システム
US20060098653A1 (en) * 2002-11-12 2006-05-11 Mark Adams Stateless accelerator modules and methods
WO2006133764A2 (en) * 2005-06-17 2006-12-21 Fotonation Vision Limited A method for establishing a paired connection between media devices

Also Published As

Publication number Publication date
KR20120085341A (ko) 2012-07-31
KR20100027208A (ko) 2010-03-10
CN101682634B (zh) 2014-09-24
US20080307109A1 (en) 2008-12-11
ATE475254T1 (de) 2010-08-15
DE602008001832D1 (de) 2010-09-02
WO2008153651A1 (en) 2008-12-18
EP2171972A1 (en) 2010-04-07
HK1143255A1 (zh) 2010-12-24
EP2001198B1 (en) 2010-07-21
EP2171972B1 (en) 2016-08-17
EP2001198A1 (en) 2008-12-10
KR101179788B1 (ko) 2012-09-10
HK1126591A1 (en) 2009-09-04
CN101682634A (zh) 2010-03-24

Similar Documents

Publication Publication Date Title
KR101283293B1 (ko) 트랜잭션 기반 통신을 위한 파일 프로토콜
KR101283267B1 (ko) 멀티플렉싱된 데이터 스트림 프로토콜
EP2158743B1 (en) Techniques for communicating data between a host device and an intermittently connected mobile device
US8886600B2 (en) Synchronization methods and systems
US8375112B2 (en) Synchronization methods and systems
US20080168106A1 (en) Synchronization methods and systems
US20080168291A1 (en) Synchronization methods and systems
US20080168184A1 (en) Synchronization methods and systems
EP1727056B1 (en) Data communication protocol
EP2115627A2 (en) Synchronization methods and systems
US20120324056A1 (en) Method and apparatus for hitless redundancy in data streaming
US20050283545A1 (en) Method and system for supporting write operations with CRC for iSCSI and iSCSI chimney

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20160616

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20170616

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20190617

Year of fee payment: 7