KR102398992B1 - 통신 장치, 통신 방법, 및 기억 매체에 저장된 프로그램 - Google Patents

통신 장치, 통신 방법, 및 기억 매체에 저장된 프로그램 Download PDF

Info

Publication number
KR102398992B1
KR102398992B1 KR1020170123811A KR20170123811A KR102398992B1 KR 102398992 B1 KR102398992 B1 KR 102398992B1 KR 1020170123811 A KR1020170123811 A KR 1020170123811A KR 20170123811 A KR20170123811 A KR 20170123811A KR 102398992 B1 KR102398992 B1 KR 102398992B1
Authority
KR
South Korea
Prior art keywords
communication device
communication
setting information
bitmap
information
Prior art date
Application number
KR1020170123811A
Other languages
English (en)
Other versions
KR20180076277A (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
Application filed by 가시오게산키 가부시키가이샤 filed Critical 가시오게산키 가부시키가이샤
Publication of KR20180076277A publication Critical patent/KR20180076277A/ko
Application granted granted Critical
Publication of KR102398992B1 publication Critical patent/KR102398992B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W56/00Synchronisation arrangements
    • H04W56/001Synchronization between nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B1/00Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/38Transceivers, i.e. devices in which transmitter and receiver form a structural unit and in which at least one part is used for functions of transmitting and receiving
    • H04B1/3827Portable transceivers
    • H04B1/385Transceivers carried on the body, e.g. in helmets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/18End to end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/72412User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories using two-way short-range wireless interfaces
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72448User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H04W4/21Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel for social networking applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50Service provisioning or reconfiguring

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

본 발명의 일 국면에 의하면, 무선 통신이 가능한 통신 장치는, 통신 패킷을 다른 통신 장치와 송수신하는 통신부와, 하나 이상의 종류의 설정 정보를 저장하는 메모리와, 프로세서를 포함한다. 상기 프로세서는, 상기 다른 통신 장치와의 전회의 통신 후에, 상기 하나 이상의 종류의 설정 정보 중 적어도 하나에 변경이 있는지 여부를 판단하고, 상기 하나 이상의 종류의 설정 정보의 변경 유무를 나타내는 판별 정보를 생성하고, 상기 판별 정보에 기초해서 상기 다른 통신 장치와의 통신을 제어한다.

Description

통신 장치, 통신 방법, 및 기억 매체에 저장된 프로그램{COMMUNICATION DEVICE, COMMUNICATION METHOD, AND PROGRAM STORED IN STORAGE MEDIUM}
본 발명은 통신 장치, 통신 방법, 및 이 통신 방법을 실행하기 위한 기억 매체에 저장된 컴퓨터 프로그램에 관한 것이다.
종래, 블루투스(Bluetooth: 등록상표) 등의 근거리 무선 통신을 이용해서 다양한 정보를 주고 받을 수 있는 전자 장치들이 존재한다. 블루투스는, 근거리에서 각종 장치를 무선으로 연결해서 데이터를 주고 받을 수 있는 근거리 무선 통신 규약이다. 블루투스 통신 방법에는, BR/EDR(Basic Rate/Enhanced Data Rate)과, 저전력 방식인 LE(Low Energy)가 있다. BR/EDR은 블루투스 클래식(Bluetooth Classic)이라고도 불린다. 블루투스 4.0부터 적용된 블루투스 로우 에너지(Bluetooth Low Energy, 이하 "BLE"라고 한다.)는, 적은 전력을 소모해서 수백 킬로바이트(KB)의 정보를 안정적으로 제공할 수 있다. 이러한 BLE 기술은 블루투스 클래식에 비교해서 동작을 간단하게 해서 에너지 소비를 절감한다. 최근 출시된 스마트 밴드, 스마트 워치, 스마트 글라스 등의 웨어러블 무선 통신 장치의 대부분은 BLE 기술을 이용해서 무선 통신을 행한다.
이러한 근거리 무선 통신에 의해, 복수의 전자 장치들의 각각이 개별적으로 취득하거나 보유하거나 하는 정보를, 다른 전자 장치에서 용이하게 취득하는 것이 가능해지고 있다. 예를 들면, 일본특허출원공개 특개2014-175830호 공보에는, 효율적으로 통신을 하기 위해서, 두 개의 통신 장치가 MTU(Maximum Transmission Unit) 값을 교환하고, 교환한 MTU 값에 따라 통신 기간을 할당하는 기술이 개시되어 있다.
일본특허출원공개 특개2014-175830호 공보. 2014.9.22.
그러나, 상기 특허문헌 1에 개시된 기술은, 송수신하는 정보의 종류에 관해서는 고려하고 있지 않다. 따라서, 복수의 종류의 정보를 통신하고자 하는 경우는, 통신 장치 간의 통신 회수가, 통신할 정보의 종류의 수에 따라서 증가한다. 그 때문에, 통신할 정보의 종류의 수가 많으면, 통신 장치의 소비 전류 및 처리 부하가 증가한다.
본 발명의 목적의 하나는, 무선 통신 장치 사이의 통신의 효율성을 높이는 방법, 이 방법을 실행하는 통신 장치 및 프로그램을 제공하는데 있다.
본 발명의 일 국면에 의하면, 무선 통신이 가능한 통신 장치는, 통신 패킷을 다른 통신 장치와 송수신하는 통신부, 하나 이상의 종류의 설정 정보를 저장하는 메모리, 및 프로세서를 포함하고, 상기 프로세서는, 상기 다른 통신 장치와의 전회의 통신 후에, 상기 하나 이상의 종류의 설정 정보 중 적어도 하나에 변경이 있는지 여부를 판단하고, 상기 하나 이상의 종류의 설정 정보의 변경 유무를 나타내는 판별 정보를 생성하고, 상기 판별 정보에 기초해서 상기 다른 통신 장치와의 통신을 제어한다.
또, 본 발명의 다른 국면에 의하면, 무선 통신이 가능한 통신 장치는, 다른 통신 장치로부터 서비스 정보를 수신하고, 상기 다른 통신 장치와 통신 패킷을 송수신하는 통신부, 하나 이상의 종류의 설정 정보를 저장하는 메모리, 및 프로세서를 포함하고, 상기 프로세서는, 상기 다른 통신 장치로부터 상기 하나 이상의 종류의 설정 정보의 갱신의 유무를 나타내는 판별 정보를 수신하고, 상기 판별 정보에 기초해서 상기 다른 통신 장치와의 통신을 제어한다.
이하의 상세한 설명을 도면들과 함께 고려하면, 본원에 대한 보다 깊은 이해를 얻을 수 있다. 이 도면들은 예시에 지나지 않고, 본 발명의 범위를 한정하는 것은 아니다.
도 1은 본 명세서에서 제안된 방법이 적용될 수 있는 무선 통신 시스템의 일 예를 도시하는 도면이다.
도 2a와 도 2b는 각각, 본 명세서에서 제안된 방법을 구현할 수 있는 장치의 내부 블록도의 일 예를 도시한다.
도 3은 본 명세서에서 제안된 방법이 적용될 수 있는 BLE 통신 아키텍처의 일 예를 도시하는 도면이다.
도 4는 전형적인 서비스 디스커버리 메커니즘을 도시하는 도면이다.
도 5는 GATT 서버에 저장되는 애트리뷰트(Attribute)의 통상의 구조의 일 예를 도시한다.
도 6a는 BLE 프로토콜에 의해 정의되는 패킷 구조를 도시하고, 도 6b는 애트리뷰트 값을 주고 받기 위한 애트리뷰트 프로토콜 PDU의 구조의 일 예를 도시한다.
도 7은 애트리뷰트 프로토콜 PDU의 애트리뷰트 옵코드(Attribute Opcode) 및 파라미터의 리스트의 일 예를 나타내는 테이블이다.
도 8은 통상의 애트리뷰트 데이터베이스의 일 예를 도시하는 도면이다.
도 9는 서버와 클라이언트가 데이터 통신을 행하는 통상의 방법을 도시하는 개념도이다.
도 10은 본 발명의 복수의 실시예에서 설정 변경을 나타내는 판별 정보로서 이용되는 비트맵의 일 예를 도시하는 도면이다.
도 11은 비트맵을 이용해서 서버와 클라이언트의 설정을 동기화시키는 방법을 도시하는 개념도이다.
도 12는 본 발명의 일 실시예에 따른 애트리뷰트 데이터베이스의 일 예를 도시하는 도면이다.
도 13은 본 발명의 다른 실시예에 따른 애트리뷰트 데이터베이스의 일 예를 도시하는 도면이다.
도 14는 본 발명의 일 실시예에 따른 서버와 클라이언트가 상시 접속하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시하는 도면이다.
도 15는 본 발명의 일 실시예에 따른 통신 프로세스를 도시하는 흐름도이다.
도 16은 본 발명의 일 실시예에 따른 서버와 클라이언트 사이에 재접속이 발생하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시하는 도면이다.
도 17은 본 발명의 일 실시예에 따른 통신 프로세스를 도시하는 흐름도이다.
도 18은 본 발명의 일 실시예에 따른 서버와 클라이언트 간의 데이터 통신 방법을 도시하는 도면이다.
도 19는 본 발명의 다른 실시예에 따른 애트리뷰트 데이터베이스의 일 예를 도시하는 도면이다.
도 20은 본 발명의 일 실시예에 따른 서버와 클라이언트가 상시 접속하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시하는 도면이다.
도 21은 본 발명의 일 실시예에 따른 서버와 클라이언트 사이에 재접속이 발생하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시하는 도면이다.
본 명세서에 있어서는, 주로 본 발명을 블루투스(등록상표), 특히, BLE에 적용한 실시예들에 대해서 설명하지만, 본 발명의 적용 분야는 블루투스로 한정되지 않는다. 본 발명은, 서비스 디스커버리가 필요한 모든 통신 방식에 대해서 적용가능하다.
이하, 본 발명의 실시예에 대해서, 도면을 참조하면서 상세히 설명한다.
도 1은, 후술하는 실시예들에 공통되는 도면으로서, 본 명세서에서 제안된 방법이 적용될 수 있는 무선 통신 시스템의 일 예를 도시하는 도면이다. 이하에 기술되는 실시예에 있어서, 제1의 장치와 제2의 장치는, 블루투스 로우 에너지(이하, "BLE"라고 부른다.) 기술을 이용해서 근거리 무선 통신을 행한다. 무선 통신 시스템 10은 적어도 제1의 장치 100 및 BLE에 의해 제1의 장치 100과 무선 접속되어 데이터 교환이 가능한 제2의 장치 200으로 이루어진다. 본 발명이 적용될 수 있는 제1의 장치 100은, 예를 들면, 손목 시계형 단말 장치의 일종인 전자 시계다. 그러나, 제1의 장치 100은 이 예로 한정되지 않고, BLE 통신이 가능한 장치라면 그 종류나 형태를 묻지 않는다. 제1의 장치 100은, 예를 들면, 디지털 카메라, 디지털 체중계 등의 헬스 기기, 또는, 스마트 밴드 등의 웨어러블 기기이어도 좋다.
본 발명이 적용될 수 있는 제2의 장치 200은, 예를 들면, 휴대 전화의 일종인 스마트폰이고, 이동 통신망 20에 접속되어 있다. 그러나, 제2의 장치 200은 이 예로 한정되지 않고, 근거리 무선 통신이 가능한 장치라면 그 종류나 형태를 묻지 않는다.
이하에 상세히 설명하는 바와 같이, BLE의 ATT(Attribute Protocol)는 서버/클라이언트의 구조로 상대 장치의 데이터에 액세스하기 위한 규칙을 정의한다. 서버는 서비스를 제공하고, 클라이언트는 서버에 요청해서 서버가 갖는 서비스에 관련된 정보(이하, "서비스 정보"라고도 함)를 취득할 수 있다. 설명의 편의를 위해서, 이하에서는 특별한 설명이 없는 한 제1의 장치 100을 서버로, 제2의 장치 200의 애플리케이션을 클라이언트로 하여 설명한다. 그러나, 제1의 장치 100은 다른 장치와의 관계에서 클라이언트로서 동작할 수 있고, 제2의 장치 200은 다른 디바이스와의 관계에서 서버로서 동작할 수 있다. 즉, BLE 통신 시스템에서 하나의 장치는 서버 또는 클라이언트로서 동작하는 것이 가능하고, 필요한 경우, 동시에 서버 및 클라이언트로서 동작하는 것도 가능하다.
제2의 장치 200은, 제1의 장치 100에 데이터를 요구할 수 있다. 제1의 장치 100은, 제2의 장치 200으로부터 데이터 요구 메시지를 수신하는 경우, 응답(Response) 메시지에 의해 제2의 장치 200에 데이터를 제공한다. 또, 제1의 장치 100은 제2의 장치 200에 데이터를 통지하기 위해서 제2의 장치 200에 대하여 고지(Notification) 메시지 또는 지시(Indication) 메시지를 송신한다. 제1의 장치 100이 제2의 장치 200에 지시 메시지를 송신한 경우에, 당해 지시 메시지가 제2의 장치 200에 의해 성공적으로 수신되면 제2의 장치 200은 당해 지시 메시지에 대한 확인(Confirmation) 메시지를 제1의 장치 100에 송신한다. 또, 제2의 장치 200은, 제1의 장치 100에 대하여 데이터의 기입을 요청하기 위해서 요구(Request) 메시지 또는 명령(Command) 메시지를 송신한다. 제2의 장치 200이 제1의 장치 100에 요구 메시지를 송신한 경우에, 데이터의 기입이 성공적으로 행해지면, 제1의 장치 100은 제2의 장치 200에 응답(Response) 메시지를 송신한다.
제1의 장치 100 또는 제2의 장치 200은, 다른 장치와 메시지를 송수신하는 과정에서 출력부(예를 들면, 디스플레이)를 통해서 사용자에게 데이터 정보를 제공하거나, 입력부(예를 들면, 유저 입력 인터페이스)를 통해서 사용자로부터 입력되는 요청을 수신하거나 할 수 있다. 또, 메모리로부터 데이터를 독출하거나, 새로운 데이터를 메모리에 기입할 수도 있다.
도 2a와 도 2b의 각각은, 본 명세서에서 제안된 방법을 구현할 수 있는 장치의 내부 블록도의 일 예를 도시한다. 도 2a는 제1의 장치 100의 내부 블록도이고, 도 2b는 제2의 장치 200의 내부 블록도이다.
도 2a에 도시된 것처럼, 제1의 장치 100은 근거리 통신부 102와, 프로세서 104와, 전원부 106과, 메모리 108과, 계시(計時)부 110과, 입력부 112와, 표시부 114를 포함한다. 근거리 통신부 102는 근거리 무선 통신 기술(예를 들면, 블루투스)을 이용해서 장치들 간의 요구/응답, 명령, 고지, 지시/확인 메시지, 또는, 데이터의 송수신을 가능하게 하는 인터페이스와, 무선 신호를 처리하는 기저 대역 회로를 포함한다. 본 실시예에서, 근거리 통신부 102는 BLE를 서포트한다. 근거리 통신부 102의 적어도 일부의 기능은 소프트웨어에 의해 구현될 수 있고, 소프트웨어에 의해 구현되는 경우, 상기 기능을 실행하는 프로그램의 형태로서 메모리 108에 저장될 수 있다.
프로세서 104는 제1의 장치 100의 전체적인 동작을 제어한다. 프로세서 104는, 제어 유닛(Control Unit), 컨트롤러 등으로 불리는 경우도 있다. 프로세서 104는 ASIC(application-specific integrated circuit), 다른 칩 세트, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다. 전원부 106은 도시를 생략하지만, 배터리 및 전원 관리부를 포함한다. 메모리 108은 프로세서 104에 의해 실행되는 컴퓨터 프로그램 명령, 펌웨어 등의 각종 소프트웨어, 및/또는, 프로세서 104가 필요로 하는 데이터 또는 프로세서 104의 처리 결과를 기억하기 위해서 사용된다. 메모리 108은 제1의 장치 100에 편입된, 또는, 제1의 장치 100으로부터 탈착가능한 RAM(Random Access Memory), ROM(Read Only Memory), 플래시 메모리, 또는 디스크 드라이브 등의 하나 또는 그 이상의 임의의 기억 장치를 포함한다. 메모리 108은 프로세서 104에 편입시키는 것도 가능하다.
계시부 110은 도시를 생략하지만, 예를 들면, 시스템 클록 또는 발진기에 의해 생성되는 신호로부터 시각 신호를 생성하는 시계 회로인 카운터를 포함하고, 현재의 시각을 계시(計時; 시간 측정)해서 시각 정보를 생성한다. 계시부 110은 생성한 시각 정보를 프로세서 104에 출력한다. 계시부 110을 프로세서 104 내에 편입시킬 수도 있다. 입력부 112는 도시는 생략하지만 각종 키, 스위치 및/또는 터치 패널 등으로 구성되고, 사용자의 입력부 112의 조작에 따라서 각종 데이터가 입력된다. 표시부 114는 도시는 생략하지만 LCD, OLED 등의 표시 장치 및 구동 회로를 포함하고, 현재의 시각 등의 정보를 표시한다.
제1의 장치 100은, 평상시는 표시부 114에 계시부 110에서 카운트되고 있는 현재 시각을 표시한다. 근거리 통신부 102를 통해서 제2의 장치 200으로부터 현재의 시각에 관한 데이터를 수신한 경우는, 당해 데이터가 나타내는 시각을 계시부 110에 설정함으로써, 제1의 장치 100의 시각을 제2의 장치 200의 시각에 동기시킨다.
도 2(b)에 도시된 것처럼, 제2의 장치 200은, 원거리 통신 처리부 202와, 근거리 통신부 204와, 프로세서 206과, 메모리 208과, 전원부 210과, 입력부 212와, 표시부 214를 포함한다. 프로세서 206은 계시부 216을 포함한다. 원거리 통신 처리부 202는, 3G, LTE 등의 휴대 전화 시스템의 기지국과 통신함으로써, 제2의 장치 200을 휴대 전화로서 기능시킨다. 원거리 통신 처리부 202는 안테나를 통해서 수신 또는 송신되는 신호를 증폭하는 앰프, 트랜시버, 디지털 기저 대역 프로세서, 음성 입력 회로, 재생 회로 등을 포함하지만, 이들 주지의 구성 요소에 대하여는 도시 및 설명을 생략한다. 또, 원거리 통신 처리부 202를 통해서 이동 통신망 20으로부터 정확한 시각 데이터를 취득함으로써 계시부 216이 정확한 시각 정보를 보유할 수 있다. 상기한 바와 같이, 제2의 장치 200은 계시부 216이 보유하고 있는 시각 정보를 제1의 장치 100에 전송할 수 있다.
근거리 통신부 204는, 근거리 무선 통신 기술(예를 들면, 블루투스)을 이용해서 장치 간의 요구/응답, 명령, 고지, 지시/확인 메시지, 또는, 데이터의 송수신을 가능하게 하는 인터페이스와, 무선 신호를 처리하는 기저 대역 회로를 포함한다. 본 실시예에서, 근거리 통신부 204는 BLE를 서포트한다. 근거리 통신부 204의 적어도 일부의 기능은 소프트웨어에 의해 구현될 수 있고, 소프트웨어에 의해 구현되는 경우, 상기 기능을 실행하는 프로그램의 형태로서 메모리 208에 저장될 수 있다.
프로세서 206은 제2의 장치 200의 전체적인 동작을 제어하고, 예를 들면, 애플리케이션 프로세서이다. 본 실시예에서는, 프로세서 206이 계시부 216을 포함하도록 구성되어 있지만, 실시예에 따라서는 계시부 216이 별개의 구성 요소로서 포함될 수도 있다. 메모리 208은, 프로세서 206에 의해 실행되는 컴퓨터 프로그램 명령, 펌웨어 등의 각종 소프트웨어, 및/또는, 프로세서 206이 필요로 하는 데이터 또는 프로세서 206의 처리 결과를 기억하기 위해서 사용된다. 메모리 208은 제2의 장치 200에 편입된 또는 제2의 장치 200으로부터 탈착가능한 RAM(Random Access Memory), ROM(Read Only Memory), 플래시 메모리, 또는 디스크 드라이브 등의 하나 또는 그 이상의 임의의 기억 장치를 포함한다. 메모리 208은 프로세서 206에 편입시키는 것도 가능하다.
전원부 210은 도시를 생략하지만, 배터리 및 전원 관리부를 포함한다. 입력부 212는 도시를 생략하지만 각종 키, 스위치 및/또는 터치 패널 등으로 구성되고, 사용자의 입력부 212의 조작에 따라서 각종 데이터가 입력된다. 표시부 214는 도시를 생략하지만 LCD, OLED 등의 표시 장치 및 구동 회로를 포함한다.
도 1에 도시되어 있는 시스템과, 도 2a 및 2b에 도시되어 있는 장치는 예시에 지나지 않고, 본 명세서에 기술된 방법을 구현할 수 있는 시스템 또는 장치의 범위를 제한하는 것은 아니다.
도 3은 본 명세서에서 제안되는 방법을 적용할 수 있는 BLE 통신 아키텍처의 일 예를 도시하는 도면이다. 예를 들면, BLE 프로토콜 스택은 타이밍이 중요한 무선 장치 인터페이스를 제어하도록 동작가능한 컨트롤러 스택(Controller stack) 30과, 하이레벨(high level) 데이터를 처리하도록 동작가능한 호스트 스택(Host stack) 40을 포함한다. 컨트롤러 스택 30은, 통신 모듈과, 예를 들면, 마이크로프로세서 등의 프로세싱 디바이스를 포함하는 프로세서 모듈을 이용해서 구현될 수 있다. 호스트 스택 40은, 프로세서 모듈 상에서 작동하는 OS의 일부로서, 또는, OS 상의 패키지(package)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.
컨트롤러 스택 30은, 물리 레이어(Physical Layer: PHY) 32와, 링크 레이어(Link Layer) 34와, 호스트 컨트롤러 인터페이스(Host Controller Interface: HCI) 36을 포함한다. 물리 레이어(무선 송수신 모듈) 32는, 2.4GHz의 무선 신호를 송수신하는 계층이고, GFSK(Gaussian Frequency Shift Keying) 변조 및 40개의 RF채널을 이용하는 주파수 호핑(frequency hopping) 기법을 사용한다. 블루투스 패킷을 전송하거나 수신하거나 하는 역할을 행하는 링크 레이어 34는, 3개의 애드버타이징(Advertising) 채널을 이용해서 애드버타이징이나 스캐닝 기능을 행한 후에 장치 간의 커넥션을 생성하고, 37개의 데이터 채널을 통해서 최대 42바이트의 데이터 패킷을 주고 받는 기능을 제공한다. HCI 36은, 호스트 스택이 커맨드와 데이터를 컨트롤러 스택에 제공하고, 컨트롤러 스택이 이벤트와 데이터를 호스트 스택에 제공할 수 있도록, 호스트 스택과 컨트롤러 스택 사이의 인터페이스를 제공한다.
호스트 스택 40은, 논리 링크 제어 및 적응 프로토콜(L2CAP) 41과, 보안 매니저(Security Manager: SM) 42와, 애트리뷰트 프로토콜(Attribute Protocol: ATT) 43과, 범용 애트리뷰트 프로파일(Generic Attribute Profile: GATT) 44와, 범용 액세스 프로파일(Generic Access Profile) 45와, LE 프로파일 46을 포함할 수 있다. 단, 호스트 스택 40은 이러한 예로 한정되지 않고, 다양한 프로토콜 및 프로파일을 포함할 수 있다. 호스트 스택 40은 L2CAP를 사용해서 블루투스 사양(스펙)이 제공하는 다양한 프로토콜 및 프로파일 등을 다중화(multiplexing)한다.
논리 링크 제어 및 적응 프로토콜(L2CAP) 41은, 특정의 프로토콜 또는 프로파일에 의해 데이터를 전송하기 위한 하나의 양방향 채널을 제공한다. 보안 매니저(SM) 42는, 장치를 인증하고, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.
애트리뷰트 프로토콜(ATT) 43은 서버/클라이언트 구조로 상대 디바이스의 데이터에 액세스하기 위한 규칙을 정의한다. ATT에는 6종류의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 정의된다.
(1) 요구(Request) 및 응답(Response) 메시지: 요구(Request) 메시지는 클라이언트가 서버에 특정한 정보를 요청하기 위해서 송신하는 메시지이며, 응답(Response) 메시지는 서버가 클라이언트에 송신하는 요구 메시지에 대한 답장이다.
(2) 명령(Command) 메시지: 클라이언트가 서버에 특정한 동작을 요청하기 위해서 송신하는 메시지이며, 서버는 명령(Command) 메시지에 대한 응답을 클라이언트에 송신하지 않는다.
(3) 고지(Notification) 메시지: 서버가 이벤트 등의 통지를 위해서 클라이언트에 송신하는 메시지이며, 클라이언트는 고지(Notification) 메시지에 대한 확인 메시지를 서버에 송신하지 않는다.
(4) 지시(Indication) 및 확인(Confirmation) 메시지: 지시(Indication) 메시지는 서버가 이벤트 등의 통지를 위해서 클라이언트에 송신하는 메시지이다. 고지(Notification) 메시지와는 달리, 클라이언트는 지시(Indication) 메시지에 대한 확인(Confirmation) 메시지를 서버에 송신한다.
범용 애트리뷰트 프로파일(GATT) 44는 서비스의 구성 시에 ATT 43이 어떻게 사용될지를 설명하는 프로토콜로서 이용된다. GATT 44는 서비스와 캐릭터리스틱(Characteristic)이라는 개념을 사용해서 특정 데이터(즉, 애트리뷰트)를 다른 장치에 제공한다. GATT는 서버와 클라이언트의 두 종류의 역할을 정의하고, 애트리뷰트를 제공하는 장치가 서버이고, 애트리뷰트가 제공되는 장치가 클라이언트이다.
서비스는 정보를 제공하거나, 액션을 수행하거나, 다른 엔티티를 대신해서 리소스를 제어하거나 할 수 있는 엔티티이다. 서비스는 소프트웨어, 하드웨어, 또는 이들의 조합으로서 구현될 수 있다. SDP 서버에 의해 보유되는 하나의 서비스에 관한 모든 정보는 하나의 서비스 레코드(service record) 내에 포함된다. 서비스는 데이터를 논리적 엔티티로 나누고, 캐릭터리스틱이라고 불리는 데이터의 묶음을 포함한다. 각각의 서비스는, 하나 또는 그 이상의 캐릭터리스틱을 가질 수 있고, UUID(Universal Unique Identifier)라고 불리는 고유의 ID에 의해 구분된다.
캐릭터리스틱은 서비스에서 사용되는 단일의 데이터 배열이고, 각각의 캐릭터리스틱은 UUID를 갖는다. 또, 각각의 캐릭터리스틱은, 캐릭터리스틱 선언과 캐릭터리스틱 값 선언의 두 개의 애트리뷰트를 갖는다. 캐릭터리스틱 선언은, 애트리뷰트 타입과 애트리뷰트 값을 갖고, 애트리뷰트 값은 캐릭터리스틱 속성(Characteristic Properties)과, 캐릭터리스틱 값 핸들(Characteristic Value Handle)과, 캐릭터리스틱 UUID를 갖는다. 캐릭터리스틱 값 선언은, 캐릭터리스틱 값에 대한 UUID와, 캐릭터리스틱 값에 의해 구성된다.
범용 액세스 프로파일(GAP) 45는 BLE 디바이스 간의 통신을 위한 역할(role)의 선택과, 멀티프로파일 동작의 프로시져를 제어하기 위해서 사용된다. GAP는 주로 디바이스 발견, 커넥션 생성 및 시큐리티에 사용된다.
LE 프로파일 46은 GATT에 의존성을 갖는 프로파일로서, 주로 BLE 디바이스에 적용된다. LE 프로파일은, 예를 들면, Battery, Time, FindMe, Proximity 등이다.
도 4는 전형적인 블루투스 서비스 디스커버리 메커니즘을 도시한다. 서비스 디스커버리 메커니즘은, 클라이언트 애플리케이션이 서버 애플리케이션에 의해 제공되는 서비스의 존재와 이 서비스의 애트리뷰트를 발견하는 수단을 제공한다. 서비스의 애트리뷰트는 서비스의 타입 또는 종류와, 그 서비스를 이용하기 위해서 필요한 메커니즘 또는 프로토콜 정보를 포함한다. 서비스 디스커버리 프로토콜(Service Discovery Protocol: SDP)은 SDP 서버와 SDP 클라이언트 간의 통신과 관련된다. 서버는 당해 서버와 관련된 서비스의 캐릭터리스틱을 기술하는 서비스 레코드의 목록을 보유한다. 각각의 서비스 레코드는 하나의 서비스에 관한 정보를 포함한다. 클라이언트는 SDP 요청을 발행함으로써 SDP 서버에 의해 보유된 서비스 레코드로부터 정보를 검색할 수 있다.
클라이언트 또는 당해 클라이언트와 관련된 애플리케이션이 어떤 서비스를 이용하려고 하는 경우, 당해 서비스를 이용하기 위해서 서비스 제공자로의 별도의 접속을 개시한다. SDP는 서비스와 그 애트리뷰트(관련된 서비스 액세스 프로토콜을 포함함)를 발견하는 메커니즘을 제공한다. SDP에 있어서 서비스의 종류를 구분하기 위해서 UUID가 이용된다. SDP 클라이언트는 찾으려고 하는 서비스의 UUID를 알고 있을 경우는, 이 UUID를 이용해서 서버에 이 서비스를 제공하는지 여부를 문의한다. 찾으려고 하는 서비스의 UUID를 알고 있지 않은 경우는, 서버에 당해 서버가 제공하는 서비스에 관한 정보를 요구한다. 만약 디바이스 상의 다수의 애플리케이션이 서비스를 제공하면, SDP 서버는 이들이 제공하는 서비스에 관한 정보에 대한 요청을 취급하기 위해서 이 서비스 제공자를 대신해서 동작한다. 마찬가지로, 다수의 클라이언트 애플리케이션이 이들을 대신해서 서버에 쿼리를 보내기 위해서 SDP 클라이언트를 이용할 수 있다.
통상의 블루투스 서비스 디스커버리 메커니즘에 있어서, 서비스 검색 명령은 BLE 프로토콜로서 규격화되어 있지만, 검색 방법이나 검색 순서는 OS에 따라서 다르다. 예를 들면, iOS(등록상표)는 프라이머리 서비스(Primary Service)를 전부 검색하고 나서 캐릭터리스틱을 검색하는 반면, 안드로이드(등록상표)는 프라이머리 서비스가 발견될 때마다 캐릭터리스틱을 검색한다. 서비스 디스커버리 프로세스는 시간을 상당히 소비하는 프로세스이고, 다수의 장치가 서로 근접하고 있는 경우 바람직하지 않은 지연을 초래할 수 있다.
도 5는, GATT 서버에 저장되는 애트리뷰트의 통상의 구조의 일 예를 도시한다. 서버는 이러한 형태의 애트리뷰트를 사용해서 서비스를 제공한다. 하나의 애트리뷰트는 4개의 구성요소로 이루어지고, 다음과 같은 의미를 갖는다.
- 애트리뷰트 핸들(Attribute Handle): 특정 애트리뷰트에 대응하는 식별자(인덱스)
- 애트리뷰트 타입(Attribute Type): 애트리뷰트의 유형(애트리뷰트 값을 기술하는 UUID)
- 애트리뷰트 값(Attribute Value): 애트리뷰트의 값(핸들에 의해 인덱싱되는 데이터)
- 애트리뷰트 퍼미션(Attribute Permission): 애트리뷰트에 대한 읽고 쓰기 허가
도 6a는 BLE 프로토콜에 의해 정의되는 통상의 패킷 구조를 도시한다. 링크 레이어는 애드버타이징 채널 패킷과 데이터 채널 패킷 모두를 위해서 사용되는 하나의 패킷 포맷만을 갖는다. 각각의 패킷은 프리앰블(Preamble), 액세스 어드레스(Access Address), PDU 헤더, PDU 페이로드, 및 CRC 필드를 포함한다. 모든 패킷은 PDU 헤더를 갖고, PDU 헤더는 애드버타이징 브로드캐스트 또는 논리 링크의 타입을 정한다. 하나의 패킷이 애드버타이징 물리 채널에서 전송될 때, PDU는 애드버타이징 채널 PDU이고, 데이터 물리 채널에서 전송될 때, PDU는 데이터 채널 PDU이다. 애드버타이징 채널 PDU는, 애드버타이징 PDU와, 스캐닝 PDU와, 개시 PDU(initiating PDU)로 분류된다. 데이터 채널 PDU는 16비트의 헤더와, 다양한 크기의 페이로드를 갖고, 무선 통신 시큐리티(Message Integrity Check: MIC) 필드를 포함할 수 있다.
도 6b는 애트리뷰트 값을 주고 받기 위한 애트리뷰트 프로토콜 PDU의 구조의 일 예를 도시한다. 도 6b에 도시된 바와 같이, 애트리뷰트 프로토콜 PDU는 애트리뷰트 옵코드(Opcode) 필드, 애트리뷰트 파라미터(Attribute Parameters) 필드, 및 인증 서명(Authentication Signature) 필드(선택적)에 의해 구성될 수 있다. 인증 서명은 옵션 필드이고, 선택적으로 존재하거나 존재하지 않는다.
상기 애트리뷰트 옵코드는 옥텟(octet)의 데이터이고, 당해 애트리뷰트 프로토콜 PDU가 어떤 PDU인지를 나타내는 정보를 포함한다. 도 7은 애트리뷰트 프로토콜 PDU의 애트리뷰트 옵코드 및 애트리뷰트 파라미터의 리스트의 일 예를 나타내는 테이블이다. 애트리뷰트 파라미터는 실제 메시지로 전달하려고 하는 정보를 포함하고, 다음과 같은 값을 가질 수 있다.
- 핸들(Handle): 데이터에 대응하는 참조 정보(인덱스). 핸들을 사용해서 GATT 클라이언트가 값을 참조, 액세스, 또는 변경할 수 있다.
- 값(Value): 데이터의 값.
- 데이터 리스트(Data List): 다양한 데이터 값의 목록.
- 길이(Length): 데이터의 길이.
상기와 같은 애트리뷰트 프로토콜 PDU를 통해서 클라이언트는 서버에 저장되어 있는 애트리뷰트 핸들 값, 애트리뷰트 값, 데이터 리스트, 또는 길이 값을 읽어내거나, 서버에 이러한 값을 기억시킬 수 있다.
도 8은 통상의 애트리뷰트 데이터베이스의 일 예를 도시한다. 도 8에 도시된 애트리뷰트 데이터베이스가 구현된 BLE 장치는, 예를 들면, 전자 시계다. 각각의 서비스는 데이터를 논리적으로 나누는 역할을 행하고, 하나 또는 그 이상의 캐릭터리스틱을 포함한다. 도시된 것처럼, 프라이머리 서비스인 Watch Service는 복수의 캐릭터리스틱(ServiceN1, ServiceN2, ..., ServiceNx)을 포함한다. 본 예에 있어서, 서비스인 Watch Service는, x개의 캐릭터리스틱을 포함한다. 도시된 것처럼, 통상의 BLE 장치에서는 하나의 기능(이하, 피처(feature)라고도 함)에 대해서 하나의 캐릭터리스틱을 갖는 형태로서 애트리뷰트 데이터베이스가 구성된다. 각각의 서비스와 각각의 캐릭터리스틱은, UUID, 즉, 16비트 또는 128비트의 식별자를 갖는다. 블루투스 표준 그룹은 공식적인 서비스와 캐릭터리스틱의 UUID의 리스트를 블루투스 스펙으로서 제공하고 있다. 사용자가 새로운 커스텀 서비스/캐릭터리스틱을 정의하는 경우에는, ITU(International Telecommunication Union)의 공식 웹 사이트에 접속해서 새로운 UUID를 생성할 수 있다.
각각의 캐릭터리스틱은, 캐릭터리스틱 선언과 캐릭터리스틱 값 선언의 두 개의 애트리뷰트를 갖는다. 예를 들면, ServiceN1의 캐릭터리스틱 선언은, 애트리뷰트 타입(캐릭터리스틱의 UUID, 구체적으로는, 0x2803)과, 애트리뷰트 값으로서 캐릭터리스틱 속성(0x0a)과, 캐릭터리스틱 값 핸들(0x003b)과, 캐릭터리스틱 UUID(ServiceN1의 UUID)로 구성된다. ServiceN1의 캐릭터리스틱 값 선언은, 캐릭터리스틱 값에 대한 UUID(ServiceN1의 UUID)와, 캐릭터리스틱 값(ServiceN1의 값)으로 구성된다.
클라이언트와 서버의 접속이 확립되면, 두 장치가 데이터 통신을 할 수 있고, 클라이언트는 서버가 제공하는 특정 서비스에 액세스할 수 있다. 예를 들면, 도 9는, 서버와 클라이언트가 데이터 통신을 하는 통상의 방법을 도시한다. 이 예에서는, 제1의 장치 100이 서버로서 동작하고, 제2의 장치 200이 클라이언트로서 동작한다. 제1의 장치 100에는, 도 8의 애트리뷰트 데이터베이스가 구현되어 있다. 서버에 특정 캐릭터리스틱 값을 요구하려고 하는 경우, 클라이언트는 Read Request 메시지를 서버에 송신한다. Read Request메시지는, BLE 사양에 정의된 바와 같이, 서버에 애트리뷰트의 값을 독출해서 그 값을 보내도록 요구하기 위해서 사용되는 메시지이며, 도 7에 도시된 것처럼, 애트리뷰트 핸들(Attribute Handle)을 파라미터로서 사용한다. 이 경우, Read Request 메시지의 Attribute Handle 파라미터는, 캐릭터리스틱 값 핸들(Characteristic Value Handle)로 설정된다. 클라이언트로부터의 Read Request가 유효한 경우, 즉, 클라이언트가 데이터를 요구하는 권한을 갖는 동시에 당해 데이터를 독출하는 것이 가능한 경우에, 서버는 클라이언트가 요구하는 데이터를 Read Response 메시지에 의해 클라이언트에 송신한다. Read Response 메시지는, BLE 사양에 정의된 것처럼, Read Request 메시지에 응답하기 위해서 서버에 의해 송신되는 메시지이며, 독출된 애트리뷰트의 값을 포함한다. 도 7에 도시된 것처럼, Read Response 메시지는, Attribute Value를 파라미터로서 사용하고, 이 경우, Read Response에 의해 전송되는 값은, 상기 캐릭터리스틱 값 핸들에 대응하는 캐릭터리스틱 값(Characteristic Value)이다. 예를 들면, 클라이언트가 ServiceN1의 값을 요구하는 경우는, 클라이언트는 Attribute Handle파라미터가 0x003b로 설정되어 있는 Read Request 메시지를 서버에 송신하고, 이에 대한 응답으로서, 서버는 Attribute Value 파라미터가 (ServiceN1 value)로 설정되어 있는 Read Response 메시지를 클라이언트에 송신한다.
서버에 데이터를 기입하려고 하는 경우, 클라이언트는, Attribute Handle 파라미터와 Attribute Value 파라미터의 각각이, 데이터를 기입할 캐릭터리스틱 값의 핸들과, 기입할 데이터로 설정된 Write Request 메시지를 서버에 송신한다. Write Request 메시지는, BLE 사양에 정의된 것처럼, 서버에 애트리뷰트의 값을 기입하도록 요구하기 위해서 사용되는 메시지이고, 기입의 요구가 유효한 경우, 서버는, 상기 핸들에 대응하는 특정 캐릭터리스틱의 값에 액세스해서 상기 데이터를 기입할 수 있다. 상기 데이터가 성공적으로 기입되면, 서버는 Write Response 메시지를 클라이언트에 송신한다. 데이터의 기입에 실패하면, 서버는 에러 메세지를 클라이언트에 송신한다. 한편, 응답 메시지를 수반하지 않는 Write Command 메시지를 이용해서 데이터의 기입을 요구할 수도 있다. 이 경우, 기입이 성공적으로 행해졌는지 여부를 클라이언트측에서 즉시 확인할 수 없지만, 응답 메시지를 송신하기 위한 전력을 서버가 소비하지 않으므로, 서버가 배터리 용량이 적은 디바이스(예를 들면, 시계형의 웨어러블 디바이스)인 경우는, Write Command를 이용하는 쪽이 전력 소비의 감소 측면에서 보다 유리하다.
서버가 클라이언트에 데이터를 통지하려고 하는 경우, 서버는, Attribute Handle 파라미터와 Attribute Value 파라미터의 각각이, 통지할 데이터인 캐릭터리스틱 값의 핸들과, 당해 데이터로 설정된 Handle Value Indication 메시지를, 클라이언트에 송신한다. Handle Value Indication 메시지는, BLE 사양에 정의된 것처럼, 서버가 애트리뷰트의 값을 통지하기 위해서 송신하는 메시지다. 클라이언트는, Handle Value Indication 메시지를 성공적으로 수신하면, 이에 대한 응답 메시지인 Handle Value Confirmation 메시지를 서버에 송신한다. 따라서, 데이터의 중요도가 높은 경우에는, 지시(Indication) 메시지를 이용하는 것이 바람직하다. 데이터의 중요도가 낮고, 클라이언트의 소비 전력의 절감이 중요한 경우는, Handle Value Notification 메시지를 이용할 수도 있다. Handle Value Notification 메시지는, Handle Value Indication 메시지와 마찬가지로, 서버가 애트리뷰트의 값을 통지하기 위해서 송신하는 메시지이지만, 응답 메시지인 Confirmation을 수반하지 않는다.
클라이언트는 필요할 때, 예를 들면, 소정의 시각이 되었을 때, 또는, 사용자의 조작이 있었을 때, 서버에 데이터를 요구하거나, 데이터의 기입을 요청하거나, 서버로부터 데이터를 수신한다. 종래에는, 전회의 통신 후에 서버의 설정(즉, ServiceN1 내지 ServiceNx의 값)에 변경이 없는 경우에도, 소정의 타이밍에 통신이 발생하기 때문에, 동일한 데이터를 반복해서 주고 받기 위해 전력을 쓸데없이 소모한다. 본 발명의 다수의 실시예는, 전회의 통신 후에, 서버의 설정에 변경이 있었는지 없었는지를 나타내는 판별 정보를 클라이언트에 송신함으로써, 변경이 있었던 부분만을 동기화하도록 구성된다. 이러한 구성에 의해, 서버와 클라이언트 간의 통신 횟수나 통신 데이터의 양을 절감할 수 있다. 본 발명의 복수의 실시예에서는, 상기 판별 정보로서, 전회의 통신 후에 변경이 있었던 부분을 나타내는 비트맵을 채용한다. 이하에서는, 본 발명의 구체적인 실시예에 대해서 설명한다.
도 10은 본 발명의 복수의 실시예에서 설정 변경을 나타내는 판별 정보로서 이용되는 비트맵의 일 예를 도시한다. 상기 비트맵의 비트는, 피처(도 8에 도시된 통상의 애트리뷰트 데이터베이스에 있어서는 캐릭터리스틱 ServiceN1 내지 ServiceNx)에 대응하고, 각 비트의 값은 당해 비트에 대응하는 피처의 값에 변경이 있는지를 나타낸다. 비트의 값이 0이면, 당해 비트에 대응하는 피처의 값에 변경이 없음을, 비트의 값이 1이면, 당해 비트에 대응하는 피처의 값에 변경이 있음을 나타낸다. 본 예에서는, 서비스가 x개의 피처인 ServiceN1 내지 ServiceNx를 포함하고, 이들 피처 가운데 ServiceN3와 ServiceN5의 값에 변경이 있다. 서버와 클라이언트에 있어서 비트맵의 순서를 공통되게 해서, 서버가 비트맵을 클라이언트에 송신하는 것으로, 클라이언트측이 서버의 설정 변경의 유무를 파악할 수 있다.
도 11은, 도 10에 도시된 형태의 비트맵을 이용해서 서버와 클라이언트의 설정을 동기시키는 방법을 도시한 개념도이다. 본 예에서, 제1의 장치 100이 서버로서 동작하고, 제2의 장치 200이 클라이언트로서 동작한다. 서버의 서비스는 8개의 피처를 포함한다. 따라서, 8비트의 비트맵이 사용된다. 제1의 장치 100의 비트맵이 00010000이므로, 서버측에서 변경이 있었던 피처는 ServiceN5이다. 이하, 서버측의 비트맵을 설정 변경 비트맵이라고도 부른다. 한편, 클라이언트인 제2의 장치 200은 ServiceN3을 변경하기를 원하기 때문에, 비트맵 00000100을 보유해 둔다. 클라이언트는 서버측에 비트맵의 독출을 요청해서, 서버로부터 설정 변경 비트맵을 취득한다. 클라이언트는, 취득된 설정 변경 비트맵 00010000과, 클라이언트 내부의 비트맵 00000100의 논리적 OR 연산을 행함으로써, 00010100을 얻을 수 있다. 이에 의해, 클라이언트는 ServiceN3과 ServiceN5만을 동기시키면 된다는 것을 알 수 있게 된다.
도 12는 본 발명의 일 실시예에 관련된 애트리뷰트 데이터베이스의 일 예를 도시한다. 도 12의 애트리뷰트 데이터베이스는, 도 8에 도시된 통상의 애트리뷰트 데이터베이스에, 액세스 제어용의 캐릭터리스틱 My Acc Ctrl을 추가하고, 그 캐릭터리스틱의 값인 액세스 컨트롤 비트맵(Access Control Bitmap)으로서 설정 변경 비트맵을 저장한다. 따라서, 클라이언트는, 필요한 때에, 애트리뷰트 핸들(0x0055)을 사용해서 애트리뷰트 값인 설정 변경 비트맵을 읽어낼 수 있다.
도 13은, 본 발명의 다른 실시예에 관련된 애트리뷰트 데이터베이스의 일 예를 도시한다. 도 8에 도시된 통상의 애트리뷰트 데이터베이스는 Watch Service의 x개의 피처에 대응하는 x개의 캐릭터리스틱을 포함하고 있고, 애트리뷰트 값으로서 각각의 캐릭터리스틱의 값을 저장한다. 본 실시예에 관련된 애트리뷰트 데이터베이스는, 기능의 수에 관계없이, 2개의 캐릭터리스틱, 즉, 액세스 제어용의 캐릭터리스틱인 My Acc Ctrl과, 데이터 통신용의 캐릭터리스틱인 All Features를 포함한다. My Acc Ctrl의 애트리뷰트 값인 액세스 컨트롤 비트맵으로서 서버의 설정 변경 비트맵이 저장된다. 통상의 캐릭터리스틱(즉, ServiceN1 내지 ServiceNx)의 값은, All Features의 애트리뷰트 값으로서 저장될 수 있다. 본 실시예에서는, ServiceN1 내지 ServiceNx의 각각의 값에 1개의 핸들(0x0011)만을 할당할 수 있으므로, 복수의 종류의 데이터를 구별하기 위한 정보인 클래스를 데이터에 부가한다. 다시 말하면, 종래에 UUID 또는 핸들 값에 의해 구별되었던 복수의 종류의 데이터를, 새로운 구별 정보인 클래스에 의해 구별한다. 예를 들면, 도 13에 도시된 것처럼, 각각의 데이터를 기억하도록 할당된 20바이트의 영역의 선두 1바이트에, 각 데이터의 클래스를 기억하고, 나머지 19바이트에 데이터를 기억한다. 본 예에서는, 클래스에 1바이트를 할당하므로, 클래스에 의해 256종류의 데이터를 구별할 수 있다. 통신 장치의 각각이 동일한 클래스 정보를 보유할 수 있도록, 클래스 정보는 사양(스펙이라고도 함)으로서 관리되는 것이 바람직하다. 한편, 데이터와 클래스를 기억하는 영역의 크기는, 상기의 실시예로 한정되지 않는다. 또, 클래스가 기억되는 위치는 데이터 기억 영역의 선두로 한정되지 않는다.
도 14는, 본 발명의 일 실시예에 따른 서버와 클라이언트가 상시 접속하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시한다. 본 실시예에 있어서, 서버에 구현되는 애트리뷰트 데이터베이스는 도 13의 구조를 갖는다. 제1의 장치 100이 서버로서 동작하고, 제2의 장치 200이 클라이언트로서 동작한다. 소정의 타이밍에, 클라이언트는, Attribute Handle 파라미터가 액세스 제어용 애트리뷰트의 핸들(My Acc Ctrl의 캐릭터리스틱 값 핸들인 0x000f)로 설정된 Read Request 메시지를 서버에 송신한다. 상기 소정의 타이밍은, 예를 들면, 소정의 시각이 되었을 때, 또는, 사용자의 소정의 조작이 있었을 때다. 서버는, 상기 메시지에 대한 응답으로서, Attribute Value 파라미터가 액세스 컨트롤 비트맵으로 설정된 Read Response 메시지를 송신한다. 이에 의해, 클라이언트가 서버의 액세스 컨트롤 비트맵을 취득할 수 있다. 도 11과 관련해서 설명한 것처럼, 클라이언트도 변경하고 싶은 데이터를 나타내는 비트맵을 보유해 둔다.
클라이언트는, 액세스 컨트롤 비트맵으로부터 서버측에서 변경이 있었던 피처(본 예에서는, ServiceNi)를 판별하고, 당해 피처의 값을 읽어내기 위해서, Attribute Handle 파라미터가 All Features의 캐릭터리스틱 값 핸들인 0x0011로 설정된 Read Request 메시지를 서버에 송신한다. 이 Read Request 메시지를 수신하면, 서버는 Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, All Features의 캐릭터리스틱 값 핸들인 0x0011과, (ServiceNi의 Class+데이터)로 설정된 Handle Value Notification 메시지를, 클라이언트에 송신한다. 상기 데이터는 변경된 피처(즉, ServiceNi)의 값이다. 이에 의해, 클라이언트가 서버측의 변경된 데이터를 취득하고, 클라이언트측의 설정을 갱신할 수 있다. 액세스 컨트롤 비트맵으로부터 서버측에 있어서 변경된 피처가 없다고 판단된 경우에는, Read Request 메시지를 송신하지 않는다.
도 11과 관련해서 설명한 것처럼, 클라이언트는, 취득된 설정 변경 비트맵과, 클라이언트 내부의 비트맵의 논리적 OR 연산을 행함으로써, 동기시킬 데이터를 판별할 수 있다. 예를 들면, 서버의 설정 중 ServiceNj를 변경하고 싶은 경우, 클라이언트는 Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, All Features의 캐릭터리스틱 값 핸들인 0x0011과, (ServiceNj의 Class+갱신 데이터)로 설정된 Write Request 메시지를, 서버에 송신한다. 상기 갱신 데이터는 ServiceNj의 갱신 값이다. 상기 데이터가 기입되면, 서버는 클라이언트에 Write Response 메시지를 송신한다. Write Request 대신, Response 메시지를 수반하지 않는 Write Command 메시지를 이용하는 것도 가능하다.
ServiceN1 내지 ServiceNx 중에서 갱신할 피처가 겹치는 경우, 예를 들면, 서버측의 설정 변경 비트맵에 있어서 값이 1인 비트와, 클라이언트측의 비트맵에 있어서 값이 1인 비트가 동일한 경우는, 사양에 규정된 규칙에 따라서 처리한다. 예를 들면, 서버측을 우선해서, 서버측의 변경된 피처의 값을 클라이언트에 송신하고, 클라이언트는 당해 피처를 수신한 값으로 갱신한다. 다른 예에서는, 갱신할 피처가 겹친다는 취지를 사용자에게 통지하고, 어느 쪽을 우선할지를 선택하게 한다.
한편, 서버의 애트리뷰트 데이터베이스가 도 12에 도시된 구조를 갖는 경우는, 클라이언트와 서버가 주고받는 메시지의 파라미터가 다음과 같이 바뀐다. 클라이언트는, 전회의 통신 후에 변경이 있었던 피처의 값을 요구하기 위해서, Attribute Handle 파라미터가 ServiceNi의 캐릭터리스틱 값 핸들로 설정된 Read Request 메시지를 서버에 송신하고, 그에 대해서 서버는, Attribute Handle 파라미터와, Attribute Value 파라미터가, ServiceNi의 캐릭터리스틱 값 핸들과, ServiceNi의 값으로 설정된 Handle Value Notification 메시지를 송신한다. 클라이언트가 서버의 설정 중 ServiceNj를 변경하고 싶은 경우는, Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, ServiceNj의 캐릭터리스틱 값 핸들과, 갱신 데이터로 설정된 Write Request 메시지를 서버에 송신한다.
도 15는, 도 13 및 도 14의 실시예에 따른 통신 프로세스를 도시하는 흐름도이다. 하나의 예로서, 도 15는 상시 접속 패턴에 있어서의, 서버의 동작을 실행하기 위한 알고리즘을 나타내는 흐름도이다. 본 실시예에서, 제1의 장치 100이 서버로서 동작하고, 제2의 장치 200이 클라이언트로서 동작한다. 이하에서는, 도 2a를 함께 참조해서 도 15를 상세히 설명한다.
통신 프로세스가 시작하면, 제1의 장치 100과 제2의 장치 200의 페어링이 행해진다(단계 S1500). 페어링이 행해지면, 제1의 장치 100의 프로세서 104는 메모리 108에 저장되어 있는 설정 변경 비트맵, 즉, 애트리뷰트 데이터베이스의 액세스 컨트롤 비트맵(도 10 및 도 13 참조)을 초기화한다(단계 S1502). 이에 의해, 액세스 컨트롤 비트맵의 모든 비트의 값이 0으로 설정된다. 다음으로, 제1의 장치 100의 설정이 변경되었는지 아닌지를 판단한다(단계 S1504). 사용자의 조작 등의 소정의 조건이 충족되어 전회의 통신 후에 제1의 장치 100의 설정이 변경된 경우, 환언하면, ServiceN1 내지 ServiceNx 중 변경된 피처가 있는 경우(단계 S1504: 예), 액세스 컨트롤 비트맵에 있어서의 변경된 피처에 대응하는 비트를 고쳐 쓴다(단계 S1506). 즉, 0으로 설정되어 있는 당해 비트의 값을 1로 갱신한다. 그 다음에, 제1의 장치 100의 설정 정보를 제2의 장치 200과 통신할 타이밍이 되었는지 여부를 판단한다(단계 S1508). 한편, 전회의 통신 후에 제1의 장치 100의 설정이 변경되지 않은 경우(단계 S1504: 아니오), 바로 단계 S1508로 진행한다.
제1의 장치 100의 설정 정보를 제2의 장치 200과 통신하는 타이밍인 경우(단계 S1508: 예), 제1의 장치 100은 제2의 장치 200으로부터 Read Request 메시지가 수신되는지를 확인한다(단계 S1510). 설정 정보를 통신할 타이밍이 아닌 경우에는(단계 S1508: 아니오), 단계 S1504로 되돌아간다.
제1의 장치 100은, 소정의 시간 동안, 제2의 장치 200으로부터 제1의 장치 100의 애트리뷰트 데이터베이스에 저장되어 있는 My Acc Ctrl의 애트리뷰트 값을 요구하는 Read Request 메시지가 수신되는지 여부를 확인한다(단계 S1510: 아니오). 도 13 및 도 14와 관련해서 설명한 바와 같이, 이 Read Request 메시지는 서버인 제1의 장치 100측의 설정 변경 비트맵을 요구하는 메시지이다. 상기 소정의 시간 내에 Read Request 메시지가 수신되지 않는 경우는, 예를 들면, 사용자에게 에러 메세지를 표시해서 설정 정보를 통신할 수 없다는 취지를 알린다. 상기 소정의 시간 내에 제2의 장치 200으로부터 Read Request 메시지가 수신되는 경우(단계 S1510: 예), 제1의 장치 100의 프로세서 104는 메모리 108에 저장되어 있는 설정 변경 비트맵을 읽어내서 제2의 장치 200에 송신한다(단계 S1512).
다음으로, 제1의 장치 100의 프로세서 104는, 메모리 108에 저장되어 있는 설정 변경 비트맵으로부터, 변경이 있었던 피처가 있는지를 판단한다(단계 S1514). 변경된 피처가 있는 경우는(단계 S1514: 예), 제2의 장치 200으로부터 Read Request 메시지가 수신되는지 여부를 확인한다(단계 S1516). 도 13 및 도 14와 관련해서 설명한 바와 같이, 이 Read Request 메시지는 제1의 장치 100의 캐릭터리스틱인 All Features의 핸들 값을 파라미터로서 이용한다. 제1의 장치 100은, 소정의 시간 동안, 제2의 장치로부터 Read Request 메시지가 수신되는지 여부를 확인한다(단계 S1516: 아니오). 상기 소정의 시간 내에 제2의 장치 200으로부터 Read Request 메시지가 수신되는 경우(단계 S1516: 예), 제1의 장치 100은 설정 변경 비트맵에 의해 지정된 피처의 값, 즉, 설정 변경 비트맵에 있어서 값이 1인 비트에 대응하는 피처의 값만을 읽어내서 제2의 장치 200에 송신한다(단계 S1518). 예를 들면, 도 14에 도시된 것처럼, 제1의 장치 100측에서 ServiceNi의 값이 변경된 경우, 제1의 장치 100은 ServiceNi의 값을 저장한 Handle Value Notification 메시지를 제2의 장치 200에 송신한다. 이에 의해, 전회의 통신 후에 변경이 있었던 설정 정보만을 제2의 장치 200에 송신할 수 있다. 상기 소정의 시간 내에 Read Request 메시지가 수신되지 않는 경우는, 예를 들면, 사용자에게 에러 메세지를 표시해서 설정 정보를 통신할 수 없다는 취지를 알린다. 한편, 제1의 장치 100측에서 변경된 피처가 없는 경우는(단계 S1514: 아니오), 바로 단계 S1520으로 진행한다.
다음으로, 제2의 장치 200으로부터 데이터의 기입을 요청하는 Write Request 메시지가 수신되는지 여부를 확인한다(단계 S1520). 예를 들면, 도 14에 도시된 것처럼, 제2의 장치 200측에서 ServiceNj를 변경한 경우, 제2의 장치 200은 All Features의 핸들 값과, (ServiceNj의 Class+갱신 데이터)를 파라미터로 하는 Write Request 메시지를 제1의 장치 100에 송신한다. 상기 갱신 데이터는 ServiceNj의 변경된 값이다. 소정의 시간 내에 제2의 장치 200으로부터 Write Request 메시지가 수신되는 경우(단계 S1520: 예), 제1의 장치 100의 프로세서 104는 상기 Write Request 메시지에 의해 지정된 피처의 값을 갱신한다(단계 S1522). 예를 들면, 도 14에 도시된 것처럼, Write Request 메시지에 포함된 클래스에 대응하는 ServiceNj의 값을, 당해 메시지의 데이터로 갱신한다. 그리고, 설정 변경 비트맵을 초기화하고, 단계 S1504로 되돌아간다(단계 S1524).
제1의 장치 100은, 제2의 장치 200으로부터 Write Request 메시지가 수신되지 않는 경우(단계 S1520: 아니오), 상기 소정의 시간이 경과했는지 여부를 판단한다(단계 S1526). 상기 소정의 시간이 경과하지 않은 경우는(단계 S1526: 아니오), 단계 S1520으로 되돌아간다. 상기 소정의 시간이 경과한 경우, 즉, 타임 아웃이 일어난 경우는(단계 S1526: 예), 제2의 장치 200이 변경을 요청하는 설정 정보가 없다고 판단하고, 설정 변경 비트맵을 초기화하고, 단계 S1504로 되돌아간다(단계 S1528).
도 16은 본 발명의 다른 실시예에 따른 서버와 클라이언트의 사이에 재접속이 발생하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시한다. 본 실시예에서, 서버에 구현되는 애트리뷰트 데이터베이스는 도 13의 구조를 갖는다. 또, 제1의 장치 100이 서버로서 동작하고, 제2의 장치 200이 클라이언트로서 동작한다. 소정의 타이밍에, 서버인 제1의 장치가 애드버타이징 패킷을 송신한다. 상기 소정의 타이밍은, 예를 들면, 소정의 시각이 되었을 때, 또는, 사용자의 소정의 조작이 있었을 때다. 이 애드버타이징 패킷에는, 서버측에 있어서 전회의 통신 후에 변경이 있었던 피처를 나타내는 설정 변경 비트맵이 저장된다. 즉, 본 실시예에서는, 서버와 클라이언트 간의 커넥션이 구축되기 전에, 애드버타이즈 단계에서 서버의 설정 변경 비트맵을 클라이언트에 송신한다. 제2의 장치 200이 상기 애드버타이징 패킷을 수신함으로써, 서버측의 설정 변경 비트맵을 취득할 수 있다. 상술한 실시예와 마찬가지로, 제1의 장치 100의 비트맵과 제2의 장치 200의 비트맵에 있어서 대응하는 비트들을 같은 순서로 배열함으로써, 제2의 장치 200이, 취득한 비트맵으로부터 제1의 장치 100의 어느 피처에 변경이 있었는지를 판단할 수 있다.
상기 애드버타이징 패킷을 수신한 제2의 장치 200이 제1의 장치 100에 커넥션 요구(Connection Request)를 발신하고, 상기 커넥션 요구를 제1의 장치가 수신함으로써, 두 장치 간의 커넥션이 구축된다. Connection Request는, 두 개의 장치의 사이에 L2CAP 채널을 생성하기 위해서 마스터 장치가 슬레이브 장치에 송신하는 패킷이다. 다음으로, 서비스 디스커버리가 행해진다. 이 서비스 디스커버리 세션에서, 클라이언트인 제2의 장치 200은, 제1의 장치 100에 구현된 서비스와 캐릭터리스틱에 관한 정보(도 13을 참조)를 취득한다.
서비스 디스커버리가 종료되면, 클라이언트인 제2의 장치 200은 설정 변경 비트맵으로부터 서버측에서 변경이 있었던 피처(본 예에서는, ServiceNi)를 판별하고, 당해 피처의 값을 읽어내기 위해서, Read Request 메시지를 서버에 송신한다. 도 16의 실시예에 있어서, 데이터의 교환 절차는 도 14의 실시예와 유사하므로, 그에 대해서는 상세한 설명은 생략한다. 상기 Read Request 메시지를 수신하면, 서버는 ServiceNi의 데이터를 포함하는 Handle Value Notification 메시지를, 클라이언트에 송신한다.
서버측의 ServiceNj의 값을 변경하고 싶은 경우는, 클라이언트는, ServiceNj의 갱신 데이터를 포함하는 Write Request 메시지를, 서버에 송신한다. 상기 데이터가 기입되면, 서버는 클라이언트에 Write Response 메시지를 송신한다.
필요한 데이터의 교환이 완료되면, 예를 들면, 제2의 장치 200이 커넥션을 절단하는 절차를 개시하기 위한 메시지(LL_TERMINATE_IND)를 제1의 장치 100에 송신하고, 제1의 장치 100으로부터 확인(Ack) 메시지를 수신함으로써, 커넥션을 절단한다. 제1의 장치 100과 제2의 장치 200과의 양측에 있어서 설정에 변경이 없었을 경우는(즉, 양측의 비트맵의 모든 비트의 값이 0인 경우), 교환할 데이터가 없으므로, 커넥션이 구축된 후에 즉시 커넥션을 절단한다.
도 17은, 도 13 및 도 16의 실시예에 따른 통신 프로세스를 도시하는 흐름도이다. 일 예로서, 도 17은 재접속이 발생하는 패턴에 있어서의, 서버의 동작을 실행하기 위한 알고리즘을 나타내는 흐름도이다. 본 실시예에서, 제1의 장치 100이 서버로서 동작하고, 제2의 장치 200이 클라이언트로서 동작한다. 이하에서는, 도 2a를 함께 참조해서 도 17을 상세히 설명한다. 한편, 본 실시예에 있어서는, 재접속이 발생할 때, 애드버타이징 패킷에 의해 설정 변경 비트맵을 클라이언트측에 송신하므로, 도 13의 애트리뷰트 데이터베이스에 있어서 액세스 제어용의 캐릭터리스틱인 My Acc Ctrl과, 그 애트리뷰트는 사용되지 않는다. 따라서, 서버가 재접속이 발생하는 패턴만으로 동작하는 경우에는, 서버에 캐릭터리스틱 My Acc Ctrl을 구현하지 않아도 좋다. 즉, 서버의 애트리뷰트 데이터베이스에 하나의 캐릭터리스틱 All Features만이 포함되어도 좋다.
통신 프로세스가 시작되면, 제1의 장치 100과 제2의 장치 200의 페어링이 행해진다(단계 S1700). 페어링이 성공적으로 행해지면, 제1의 장치 100의 프로세서 104는 메모리 108에 저장되어 있는 설정 변경 비트맵을 초기화한다(단계 S1702). 이에 의해, 설정 변경 비트맵의 모든 비트의 값이 0으로 설정된다. 다음으로, 제1의 장치 100의 설정이 변경되었는지 아닌지를 판단한다(단계 S1704). 사용자의 조작 등의 소정의 조건이 충족되어 전회의 통신 후에 제1의 장치 100의 설정이 변경된 경우, 환언하면, ServiceN1 내지 ServiceNx 중 변경된 피처가 있는 경우(단계 S1704: 예), 설정 변경 비트맵에 있어서의 변경된 피처에 대응하는 비트를 고쳐 쓴다(단계 S1706). 즉, 0으로 설정되어 있는 당해 비트의 값을 1로 갱신한다. 다음으로, 제1의 장치 100의 설정 정보를 제2의 장치 200과 통신하는 타이밍이 되었는지 아닌지를 판단한다(단계 S1708). 한편, 전회의 통신 후에 제1의 장치 100의 설정이 변경되지 않은 경우(단계 S1704: 아니오), 바로 단계 S1708로 진행한다.
제1의 장치 100의 설정 정보를 제2의 장치 200과 통신할 타이밍인 경우(단계 S1708: 예), 제1의 장치 100은 애드버타이즈를 개시한다(단계 S1710). 도 16에 관련해서 설명한 바와 같이, 제1의 장치 100은 설정 변경 비트맵이 저장된 애드버타이징 패킷을 제2의 장치 200에 송신한다. 제1의 장치 100이 제2의 장치 200으로부터 Connection Request 메시지를 수신함으로써, 제1의 장치 100과 제2의 장치 200의 커넥션이 구축된다(단계 S1712). 한편, 설정 정보를 통신하는 타이밍이 아닌 경우에는(단계 S1708: 아니오), 단계 S1704로 돌아간다.
다음으로, 제1의 장치 100의 프로세서 104는, 메모리 108에 저장되어 있는 설정 변경 비트맵으로부터, 변경이 있었던 피처가 있는지 여부를 판단한다(단계 S1714). 변경된 피처가 있는 경우는(단계 S1714: 예), 제2의 장치 200으로부터 Read Request 메시지가 수신되는지 여부를 확인한다(단계 S1716). 도 13 및 도 16과 관련해서 설명한 바와 같이, 이 Read Request 메시지는 제1의 장치 100의 캐릭터리스틱인 All Features의 핸들 값을 파라미터로서 이용한다. 제1의 장치 100은, 소정의 시간 동안, 제2의 장치로부터 Read Request 메시지가 수신되는지 여부를 확인한다(단계 S1716: 아니오). 상기 소정의 시간 내에 제2의 장치 200으로부터 Read Request 메시지가 수신되는 경우(단계 S1716: 예), 제1의 장치 100은 설정 변경 비트맵에 의해 지정된 피처의 값, 즉, 설정 변경 비트맵에서 값이 1인 비트에 대응하는 피처의 값만을 읽어내서 제2의 장치 200에 송신한다(단계 S1718). 예를 들면, 도 16에 도시된 것과 같이, 제1의 장치 100측에서 ServiceNi의 값이 변경된 경우, 제1의 장치 100은 ServiceNi의 값을 저장한 Handle Value Notification 메시지를 제2의 장치 200에 송신한다. 이에 의해, 전회의 통신 후에 변경이 있었던 설정 정보만을 제2의 장치 200에 송신할 수 있다. 상기 소정의 시간 내에 Read Request 메시지가 수신되지 않는 경우는, 예를 들면, 사용자에게 에러 메세지를 표시해서 설정 정보를 통신할 수 없다는 취지를 알린다. 한편, 제1의 장치 100측에서 변경된 피처가 없는 경우는(단계 S1714: 아니오), 바로 단계 S1720으로 진행한다.
다음으로, 제2의 장치 200으로부터 데이터의 기입을 요청하는 Write Request 메시지가 수신되는지 아닌지를 확인한다(단계 S1720). 예를 들면, 도 16에 도시된 바와 같이, 제2의 장치 200측에서 ServiceNj를 변경한 경우, 제2의 장치 200은 All Features의 핸들 값과, (ServiceNj의 Class+갱신 데이터)를 파라미터로 하는 Write Request 메시지를 제1의 장치 100에 송신한다. 상기 갱신 데이터는 ServiceNj의 변경된 값이다. 소정의 시간 내에 제2의 장치 200으로부터 Write Request 메시지가 수신되는 경우(단계 S1720: 예), 제1의 장치 100의 프로세서 104는 상기 Write Request 메시지에 의해 지정된 피처의 값을 갱신한다(단계 S1722). 예를 들면, 도 16에 도시된 바와 같이, Write Request 메시지에 포함된 클래스에 대응하는 ServiceNj의 값을, 당해 메시지의 데이터로 갱신한다. 그리고, 설정 변경 비트맵을 초기화하고(단계 S1724), 커넥션 절단 처리를 행한다(단계 S1730). 상술한 바와 같이, 커넥션 절단 처리는, 예를 들면, 제2의 장치 200으로부터 LL_TERMINATE_IND를 수신함으로써 개시된다. 커넥션이 절단된 후, 프로세스는 단계 S1704로 되돌아간다.
제1의 장치 100은, 제2의 장치 200으로부터 Write Request 메시지가 수신되지 않는 경우(단계 S1720: 아니오), 상기 소정의 시간이 경과했는지 아닌지를 판단한다(단계 S1726). 상기 소정의 시간이 경과하지 않은 경우는(단계 S1726: 아니오), 단계 S1720으로 되돌아간다. 상기 소정의 시간이 경과한 경우, 즉, 타임 아웃이 발생한 경우는(단계 S1726: 예), 제2의 장치 200이 변경을 요청하는 설정 정보가 없다고 판단해서, 설정 변경 비트맵을 초기화하고(단계 S1728), 커넥션 절단 처리를 행한다(단계 S1730). 커넥션이 절단된 후, 프로세스는 단계 S1704로 되돌아간다.
도 18은 본 발명의 다른 실시예에 따른 서버와 클라이언트 간의 데이터 통신 방법을 도시한다. 도 18은 서버와 클라이언트가 상시 접속하는 패턴을 상정하고 있지만, 본 실시예는 재접속이 발생하는 패턴에 대하여도 적용가능하다. 본 실시예에서, 서버에 구현되는 애트리뷰트 데이터베이스는 도 13의 구조를 갖는다. 한편, 제1의 장치 100이 서버로서, 제2의 장치 200이 클라이언트로서 동작한다. 상술한 실시예에서는, 하나의 Handle Value Notification 메시지나 하나의 Write Request 메시지에 의해 하나의 피처 값만을 송신한다. 따라서, 서버측에서 복수의 피처에 변경이 있었을 경우, 변경이 있었던 피처의 수만큼, Handle Value Notification 메시지를 송신한다. 클라이언트측에서 복수의 피처를 변경하고 싶은 경우에도, 변경하고 싶은 피처의 수만큼, Write Request 메시지와 Write Response 메시지를 주고 받는다. 이와 달리, 본 실시예에서는, 통신 회수를 더욱 줄이기 위해서, 복수의 피처에 대하여 하나의 메시지를 사용해서 통신한다.
소정의 타이밍에, 클라이언트는, Attribute Handle 파라미터가 액세스 제어용 애트리뷰트의 핸들(My Acc Ctrl의 캐릭터리스틱 값 핸들인 0x000f)로 설정된 Read Request 메시지를 서버에 송신한다. 상기 소정의 타이밍은, 예를 들면, 소정의 시각이 되었을 때, 또는, 사용자의 소정의 조작이 있었을 때다. 서버는, 상기 메시지에 대한 응답으로서, Attribute Value 파라미터가 액세스 컨트롤 비트맵으로 설정된 Read Response 메시지를 송신한다. 이에 의해, 클라이언트가 서버의 설정 변경 비트맵을 취득할 수 있다. 상술한 바와 같이, 클라이언트도, 변경하고 싶은 데이터를 나타내는 비트맵을 보유해 둔다. 한편, 재접속이 발생하는 패턴에서는, 서버가 설정 변경 비트맵을 애드버타이징 패킷에 저장하고, 클라이언트에 이를 송신하는 것으로, 클라이언트가 서버의 설정 변경 비트맵을 취득할 수 있다.
클라이언트는, 서버로부터 수신한 설정 변경 비트맵으로부터 변경된 피처가 존재한다고 판단하면, Attribute Handle 파라미터가 All Features의 캐릭터리스틱 값 핸들로 설정된 Read Request 메시지를 서버에 송신한다. 클라이언트로부터 상기 Read Request 메시지를 수신하면, 서버는 변경된 피처의 값을 클라이언트에 송신한다. 예를 들면, 변경이 있었던 피처가 ServiceNa, ServiceNb, ServiceNc, ServiceNd인 경우, 서버는 도 18에 도시된 바와 같이, Attribute Handle 파라미터가 All Features의 캐릭터리스틱 값 핸들인 0x0011로 설정되고, Attribute Value 파라미터로서, 송신할 데이터의 종류의 개수(본 예에서는, 4)와, ServiceNa, ServiceNb, ServiceNc, ServiceNd의 각각의 데이터의 길이(Length 필드 1 바이트) 및 데이터((Length 필드의 값) 바이트)를 저장한 하나의 Handle Value Notification 메시지를 클라이언트에 송신한다. 바람직하게는, 상기 메시지에 저장한 데이터(즉, ServiceNa, ServiceNb, ServiceNc, ServiceNd의 데이터)의 배열 순서가 설정 변경 비트맵의 비트들의 배열 순서와 매칭된다. 더욱 바람직하게는, 상기 데이터의 배열 순서를 설정 변경 비트맵의 대응하는 비트들의 순서와 동일하게 하는 동시에, 각 데이터 앞에 당해 데이터의 길이를 부가함으로써, 클라이언트측에서 복수의 종류의 데이터를 구분할 수 있다. 데이터의 종류의 개수는 선택적인 정보이며, 상기 메시지에 포함되지 않아도 좋다.
클라이언트측에서 변경하고 싶은 피처가 있는 경우는, Attribute Handle 파라미터와, Attribute Value 파라미터와의 각각이, All Features의 캐릭터리스틱 값 핸들인 0x0011과, (클라이언트측의 비트맵+갱신 데이터)로 설정된 Write Request 메시지를, 서버에 송신한다. 변경할 데이터의 종류가 복수인 경우는, 상기 Handle Value Notification 메시지와 마찬가지로, 데이터 필드에 (데이터의 길이+데이터)를 비트맵과 동일한 순서로 저장한다. 클라이언트측의 비트맵에 따라서, 서버는 클라이언트가 변경을 요구하는 피처가 어느 것인지를 판별할 수 있다. 데이터의 기입이 행해지면, 서버는 클라이언트에 Write Response 메시지를 송신한다.
도 19는 본 발명의 다른 실시예에 따른 애트리뷰트 데이터베이스의 일 예를 도시한다. 본 실시예에서의 애트리뷰트 데이터베이스는, 도 13의 애트리뷰트 데이터베이스에 비해서, 데이터 요구용의 캐릭터리스틱인 Read Request for All Features를 더 포함한다. 나머지 부분은 도 13의 애트리뷰트 데이터베이스와 동일하므로, 그에 대해서는 설명을 생략한다. 이하, 서버의 애트리뷰트 데이터베이스가 도 19의 형태를 갖는 경우의 데이터 통신에 대해서 도 20 및 도 21을 참조해서 설명한다. 도 20과 도 21의 양쪽에 있어서, 제1의 장치 100이 서버로서 동작하고, 제2의 장치 200이 클라이언트로서 동작한다.
도 20은, 본 발명의 일 실시예에 따른 서버와 클라이언트가 상시 접속하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시한다. 소정의 타이밍에, 클라이언트는, Attribute Handle 파라미터가 액세스 제어용 애트리뷰트의 핸들(My Acc Ctrl의 캐릭터리스틱 값 핸들인 0x000f)로 설정된 Read Request 메시지를 서버에 송신한다. 상기 소정의 타이밍은, 예를 들면, 소정의 시각이 되었을 때, 또는, 사용자의 소정의 조작이 있었을 때다. 서버는, 상기 메시지에 대한 응답으로서, Attribute Value 파라미터가 액세스 컨트롤 비트맵으로 설정된 Read Response 메시지를 송신한다. 이에 의해, 클라이언트가 서버의 액세스 컨트롤 비트맵을 취득할 수 있다. 도 11과 관련해서 설명한 바와 같이, 클라이언트도, 변경하고 싶은 데이터를 나타내는 비트맵을 보유해 둔다.
클라이언트는, 액세스 컨트롤 비트맵으로부터 서버측에서 변경이 있었던 피처(본 예에서는, ServiceNi)를 판별하고, 당해 피처의 값을 읽어내기 위해서, Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, Read Request for All Features의 캐릭터리스틱 값 핸들인 0x0011과, ServiceNi의 Class로 설정된 Write Command 메시지를 서버에 송신한다. 이 Write Command 메시지를 수신하면, 서버는 Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, All Features의 캐릭터리스틱 값 핸들인 0x0013과, (ServiceNi의 Class+데이터)로 설정된 Handle Value Notification 메시지를, 클라이언트에 송신한다. 상기 데이터는 서버측에서 변경된 피처(ServiceNi)의 값이다. 이에 의해, 클라이언트가 서버측의 변경된 데이터를 취득할 수 있다. 액세스 컨트롤 비트맵으로부터 서버측에 있어서 변경된 피처가 없다고 판단되는 경우는, Write Command 메시지를 송신하지 않는다.
도 11과 관련해서 설명한 바와 같이, 클라이언트는, 취득된 설정 변경 비트맵과, 클라이언트 내부의 비트맵의 논리적 OR 연산을 행하는 것으로, 동기시킬 데이터를 판별할 수 있다. 예를 들면, 서버의 설정 가운데 ServiceNj를 변경하고 싶은 경우, 클라이언트는, Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, All Features의 캐릭터리스틱 값 핸들인 0x0013과, (ServiceNj의 Class+갱신 데이터)로 설정된 Write Command 메시지를, 서버에 송신한다. 상기 갱신 데이터는 피처 ServiceNj의 갱신 값이다. Write Command 대신, Response 메시지를 수반하는 Write Request 메시지를 이용하는 것도 가능하다. 이 경우, 상기 데이터가 기입되면, 서버는 클라이언트에 Write Response 메시지를 송신한다.
도 21은 본 발명의 일 실시예에 따른 서버와 클라이언트의 사이에 재접속이 발생하는 패턴에 있어서 서버와 클라이언트 간의 데이터 통신 방법을 도시한다. 소정의 타이밍에, 서버인 제1의 장치 100이 애드버타이징 패킷을 송신한다. 상기 소정의 타이밍은, 예를 들면, 소정의 시각이 되었을 때, 또는, 사용자의 소정의 조작이 있었을 때다. 이 애드버타이징 패킷에는, 서버측에 있어서 전회의 통신 후에 변경이 있었던 피처를 나타내는 설정 변경 비트맵이 저장된다. 즉, 본 실시예에서는, 서버와 클라이언트 간의 커넥션이 구축되기 전에, 애드버타이즈 단계에서 서버의 설정 변경 비트맵을 클라이언트에 송신한다. 제2의 장치 200이 상기 애드버타이징 패킷을 수신함으로써, 서버측의 설정 변경 비트맵을 취득할 수 있다. 도시된 예에 있어서, 서버측의 설정 변경 비트맵은 00010000이다. 즉, 전회의 통신 후에 5번째의 피처의 설정이 변경되었다. 상술한 바와 같이, 제1의 장치 100의 비트맵과 제2의 장치 200의 비트맵에 있어서 대응하는 비트를 서로 같은 순서로 배열함으로써, 제2의 장치 200이 취득된 상기 비트맵으로부터 제1의 장치 100의 어느 피처에 변경이 있었는지를 판별할 수 있다. 또, 도 11과 관련해서 설명한 바와 같이, 클라이언트도, 변경하고 싶은 데이터를 나타내는 비트맵을 보유해 둔다. 도시된 예에 있어서, 클라이언트측의 비트맵은 00000100이다. 즉, 클라이언트측에서는 3번째의 피처의 설정이 변경되었다.
상기 애드버타이징 패킷을 수신한 제2의 장치 200이, 제1의 장치 100에 Connection Request를 발신하고, 상기 Connection Request를 제1의 장치 100이 수신함으로써, 2개의 장치의 커넥션이 구축된다. 그 다음에, 서비스 디스커버리가 행해진다. 이 서비스 디스커버리 세션에서, 클라이언트인 제2의 장치 200은, 제1의 장치 100에 구현되어 있는 서비스와 캐릭터리스틱에 관한 정보(도 19를 참조)를 취득한다.
서비스 디스커버리가 종료되면, 클라이언트인 제2의 장치 200은 설정 변경 비트맵으로부터 서버측에서 변경이 있었던 피처(본 예에서는, ServiceN5)를 판별하고, 당해 피처의 값을 읽어내기 위해서, Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, Read Request for All Features의 캐릭터리스틱 값 핸들인 0x0011과, ServiceN5의 Class로 설정된 Write Command 메시지를 서버에 송신한다. 이 Write Command 메시지를 수신하면, 서버는 Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, All Features의 캐릭터리스틱 값 핸들인 0x0013과, (ServiceN5의 Class+데이터)로 설정된 Handle Value Notification 메시지를, 클라이언트에 송신한다. 상기 데이터는 ServiceN5의 값이다. 이에 의해, 클라이언트가 서버측의 변경된 데이터를 취득할 수 있다. 설정 변경 비트맵으로부터 서버측에 있어서 변경된 피처가 없다고 판단되는 경우는, Write Command 메시지를 송신하지 않는다.
도 11과 관련해서 설명한 바와 같이, 클라이언트는, 취득된 설정 변경 비트맵과 클라이언트 내부의 비트맵의 논리적 OR 연산을 행하는 것으로, 동기시킬 데이터를 판별할 수 있다. 도시된 예에 있어서는, ServiceN3의 설정 변경이 요구되므로, 클라이언트는 Attribute Handle 파라미터와, Attribute Value 파라미터의 각각이, All Features의 캐릭터리스틱 값 핸들인 0x0013과, (ServiceN3의 Class+갱신 데이터)로 설정된 Write Command 메시지를, 서버에 송신한다. 상기 갱신 데이터는 ServiceN3의 갱신 값이다. Write Command 대신, Response메시지를 수반하는 Write Request 메시지를 이용하는 것도 가능하다. 이 경우, ServiceN3이 상기 데이터로 갱신되면, 서버는 클라이언트에 Write Response 메시지를 송신한다.
필요한 데이터의 교환이 완료되면, 예를 들면, 제2의 장치 200이 커넥션을 절단하는 절차를 개시하기 위한 메시지(LL_TERMINATE_IND)를 제1의 장치 100에 송신하고, 제1의 장치 100으로부터 확인(Ack) 메시지를 수신함으로써, 커넥션을 절단한다. 제1의 장치 100과 제2의 장치 200의 양측에서 설정에 변경이 없었을 경우는(즉, 양측의 비트맵의 모든 비트의 값이 0인 경우), 교환할 데이터가 없으므로, 커넥션이 구축된 후에 즉시 커넥션을 절단한다.
상기 실시예에서는, 서버에 대하여 설정 정보를 요구하는 Write Command 메시지의 Handle Value 파라미터로서, 변경이 있었던 피처의 클래스를 이용한다. 다른 실시예에서는, Write Command 메시지의 Handle Value 파라미터로서 설정 변경 비트맵을 이용한다. 파라미터로서 비트맵을 이용하면, 클래스를 이용하는 경우에 비해서 통신 데이터의 양을 절감할 수도 있다. 예를 들면, 서버측의 피처가 1개인 경우, 비트맵은 1비트의 크기를 가지므로, 1바이트의 크기인 클래스를 이용할 경우에 비교해서 데이터의 양이 1/8로 감소한다. 즉, 비트맵을 파라미터로서 이용하면, 피처의 수에 따라서는, 클래스를 이용하는 경우에 비해서 최대 1/8 정도까지 통신할 데이터의 양을 감소시키는 것이 가능하다.
상기한 복수의 실시예에 있어서, Write Command 메시지는 Write Request 메시지로 바꿀 수 있고, Handle Value Notification 메시지는 Handle Value Indication 메시지로 바꿀 수 있다. 메시지의 종류는, 송신 데이터의 중요도, 메시지를 수신하는 단말 배터리의 용량 등에 의해 결정될 수 있다.
또, 상술한 복수의 실시예에 있어서, 서버는, 클라이언트로부터 요구 메시지(예를 들면, 도 14의 All Features로의 Read Request, 도 20의 Read Request for All Features로의 Write Command)가 수신되면, 전회의 통신 후에 변경이 있었던 설정 정보를 클라이언트에 송신한다. 그러나, 본 발명은, 이 실시예들로 한정되지 않는다. 다른 실시예에서는, 클라이언트가 설정 정보를 요구하는 메시지를 송신하지 않고, 소정의 타이밍이 되면, 서버가 전회의 통신 후에 변경이 있었던 설정 정보를 저장한 고지 또는 지시 메시지를 클라이언트에 송신한다.
또, 도 13 또는 도 19에 도시된 실시예에 의하면, 모든 피처의 값을 통합형 캐릭터리스틱인 All Features를 이용해서 관리함으로써, 서비스 디스커버리에 소요 되는 시간이 단축될 수 있고, 이는 접속 시간을 줄인다. 또, 새로운 피처가 부가되어도 서비스나 캐릭터리스틱을 추가할 필요가 없다. 서버 장치에 현재의 버전의 사양에 포함되어 있는 피처를 추가하려고 하는 경우는, 당해 피처에 대응하는 클래스와 애트리뷰트를 추가하면 된다. 이 경우는, 피처의 추가를 위한 사용자의 프로그래밍 시에 상기 피처에 따라 클래스가 자동적으로 부여되도록 통신 장치의 펌웨어가 설계되어 있으면 사용자의 편의성을 높일 수 있다. 또, 현재의 버전의 사양에 포함되어 있지 않은 새로운 피처를 사용자가 추가(즉, 새로운 클래스를 생성)할 수 있도록 펌웨어가 설계되어도 좋다. 새롭게 생성되는 클래스는 다른 피처의 클래스와 다른, 고유의 값을 갖는 것이 바람직하다. 한편, 사용자가 표준 그룹이 관리하는 웹 사이트를 통해서 피처(클래스)를 추가할 수 있도록 하는 것도 가능하다. 새로운 피처(클래스)가 추가된 사양은, 펌웨어의 업데이트 등에 의해 통신 장치에 적용될 수 있다.
이상, 본 발명을 블루투스(Bluetooth(등록상표)), 특히, BLE에 적용한 실시예들에 대해서 설명했지만, 본 발명의 적용 분야는 이것으로 한정되지 않고, 예를 들면, 다른 무선 통신 기술에도 적용가능하다. 특히, 서비스 디스커버리의 개념을 이용하는 무선 통신 기술에 적용가능하다.
본 발명이 속하는 기술 분야에 있어서의 통상의 지식을 가진 자는, 상기 설명 및 관련 도면으로부터 본 발명의 많은 변형 및 다른 실시예를 도출할 수 있다. 따라서, 본 발명은 개시된 특정의 실시예로 한정되지 않는다. 본 명세서에서는, 복수의 특정 용어들이 사용되고 있지만, 이들은 일반적인 의미로서 단지 설명의 목적을 위해서 사용된 것일 뿐이며, 발명을 제한하려는 목적으로 사용된 것은 아니다. 첨부의 특허청구범위 및 그 균등물에 의해 정의되는 일반적인 발명의 개념 및 사상을 벗어나지 않는 범위에서 다양한 변형이 가능하다.

Claims (20)

  1. 무선 통신이 가능한 통신 장치에 있어서,
    통신 패킷을 다른 통신 장치와 송수신하는 통신부;
    하나 이상의 종류의 설정 정보를 저장하는 메모리; 및
    프로세서를 포함하고,
    상기 프로세서는, 상기 다른 통신 장치와의 전회의 통신 후에, 상기 하나 이상의 종류의 설정 정보 중 적어도 하나에 변경이 있는지 여부를 판단하고, 상기 하나 이상의 종류의 설정 정보의 변경 유무를 나타내는 판별 정보를 생성하고, 상기 판별 정보에 기초해서 상기 다른 통신 장치와의 통신을 제어하고,
    상기 판별 정보는 비트맵이고, 상기 비트맵의 비트의 수는 상기 설정 정보의 종류의 개수와 동일하며,
    상기 비트맵의 각 비트는, 대응하는 상기 설정 정보가 상기 다른 통신 장치와의 전회의 통신 후에 변경된 경우에는 1로 설정되고, 변경되지 않은 경우에는 0으로 설정되는,
    통신 장치.
  2. 제1항에 있어서,
    상기 판별 정보는 비트맵이고, 상기 비트맵의 비트의 수는 상기 설정 정보의 종류의 개수와 동일한,
    통신 장치.
  3. 제2항에 있어서,
    상기 비트맵의 각 비트는, 대응하는 상기 설정 정보가 상기 다른 통신 장치와의 전회의 통신 후에 변경되었는지 아닌지를 나타내는,
    통신 장치.
  4. 삭제
  5. 제1항에 있어서,
    상기 프로세서는, 소정의 타이밍에, 상기 통신부로 하여금 상기 판별 정보를 상기 다른 통신 장치에 송신하게 하는,
    통신 장치.
  6. 제5항에 있어서,
    상기 프로세서는, 상기 다른 통신 장치로부터 상기 판별 정보를 요구하는 메시지가 수신된 경우에, 상기 통신부로 하여금, 상기 판별 정보를 상기 다른 통신 장치에 송신하게 하는,
    통신 장치.
  7. 제5항에 있어서,
    상기 판별 정보는, 상기 다른 통신 장치에 송신되는 애드버타이징 패킷에 저장되는,
    통신 장치.
  8. 제1항에 있어서,
    상기 프로세서는, 상기 통신부로 하여금, 상기 변경된 적어도 하나의 종류의 설정 정보를 상기 다른 통신 장치에 송신하게 하는,
    통신 장치.
  9. 제1항에 있어서,
    상기 프로세서는, 상기 통신부를 통해서 상기 다른 통신 장치로부터 설정 정보를 요구하는 메시지가 수신된 경우에, 상기 통신부로 하여금, 상기 변경된 적어도 하나의 종류의 설정 정보를 상기 다른 통신 장치에 송신하게 하는,
    통신 장치.
  10. 제1항에 있어서,
    상기 프로세서는, 상기 판별 정보에 기초해서, 상기 변경된 적어도 하나의 종류의 설정 정보를 포함하는 갱신 정보를 생성하고,
    소정의 타이밍에, 상기 통신부로 하여금, 상기 갱신 정보를 상기 다른 통신 장치에 송신하게 하는,
    통신 장치.
  11. 제2항에 있어서,
    상기 다른 통신 장치와의 전회의 통신 후에 복수의 종류의 설정 정보가 변경된 경우에, 상기 프로세서는, 상기 판별 정보에 기초해서, 상기 변경된 복수의 종류의 설정 정보를 포함하는 갱신 정보를 생성하고,
    상기 갱신 정보에 포함되는 상기 복수의 종류의 설정 정보의 배열 순서는, 상기 비트맵의 비트의 배열 순서에 매칭되는,
    통신 장치.
  12. 제1항에 있어서,
    상기 프로세서는, 상기 통신부를 통해서 상기 다른 통신 장치로부터 상기 하나 이상의 종류의 설정 정보 중 적어도 하나의 갱신 값을 수신한 경우, 상기 메모리에 저장되어 있는 상기 설정 정보의 값을 상기 갱신 값으로 갱신하는,
    통신 장치.
  13. 제1항의 통신 장치와,
    현재의 시각을 계시하는 계시부
    를 포함하는 전자 시계.
  14. 무선 통신이 가능한 통신 장치에 있어서,
    다른 통신 장치로부터 서비스 정보를 수신하고, 상기 다른 통신 장치와 통신 패킷을 송수신하는 통신부;
    하나 이상의 종류의 설정 정보를 저장하는 메모리; 및
    프로세서를 포함하고,
    상기 프로세서는, 상기 다른 통신 장치로부터 상기 하나 이상의 종류의 설정 정보의 갱신의 유무를 나타내는 판별 정보를 수신하고, 상기 판별 정보에 기초해서 상기 다른 통신 장치와의 통신을 제어하고,
    상기 판별 정보는, 상기 설정 정보의 종류의 개수의 비트를 갖는 제1의 비트맵이고,
    상기 프로세서는, 상기 다른 통신 장치와의 전회의 통신 후에 상기 하나 이상의 종류의 설정 정보에 변경이 있는지를 나타내는 제2의 비트맵을 생성하고,
    상기 제1의 비트맵과 제2의 비트맵에 기초해서, 상기 하나 이상의 종류의 설정 정보를 상기 다른 통신 장치의 설정 정보와 동기시키는,
    통신 장치.
  15. 제14항에 있어서,
    상기 판별 정보는 비트맵이고, 상기 비트맵의 비트의 수는 상기 설정 정보의 종류의 개수와 동일한,
    통신 장치.
  16. 삭제
  17. 무선 통신이 가능한 장치의 통신 방법에 있어서,
    다른 통신 장치와 페어링하는 단계;
    상기 다른 통신 장치와의 전회의 통신 후에, 하나 이상의 종류의 설정 정보 중 적어도 하나에 변경이 있는지를 판단하는 단계;
    상기 하나 이상의 종류의 설정 정보의 변경 유무를 나타내는 판별 정보를 생성하는 단계; 및
    상기 판별 정보에 기초해서, 상기 다른 통신 장치와의 통신을 제어하는 단계
    를 포함하되,
    상기 판별 정보는 비트맵이고, 상기 비트맵의 비트의 수는 상기 설정 정보의 종류의 개수와 동일하며,
    상기 비트맵의 각 비트는, 대응하는 상기 설정 정보가 상기 다른 통신 장치와의 전회의 통신 후에 변경된 경우에는 1로 설정되고, 변경되지 않은 경우에는 0으로 설정되는,
    통신 방법.
  18. 무선 통신이 가능한 장치의 통신 방법에 있어서,
    다른 통신 장치와 페어링 하는 단계;
    상기 다른 통신 장치로부터, 하나 이상의 종류의 설정 정보를 갱신할 것인지 아닌지를 나타내는 판별 정보를 수신하는 단계; 및
    상기 판별 정보에 기초해서, 상기 다른 통신 장치와의 통신을 제어하는 단계
    를 포함하되,
    상기 판별 정보는, 상기 설정 정보의 종류의 개수의 비트를 갖는 제1의 비트맵이고,
    상기 다른 통신 장치와의 전회의 통신 후에 상기 하나 이상의 종류의 설정 정보에 변경이 있는지를 나타내는 제2의 비트맵을 생성하고,
    상기 제1의 비트맵과 제2의 비트맵에 기초해서, 상기 하나 이상의 종류의 설정 정보를 상기 다른 통신 장치의 설정 정보와 동기시키는,
    통신 방법.
  19. 컴퓨터로 읽을 수 있는 비 일시적 기록 매체에 저장된 프로그램에 있어서,
    무선 통신이 가능한 통신 장치를 제어하고, 상기 통신 장치에,
    다른 통신 장치와 페어링하는 단계;
    상기 다른 통신 장치와의 전회의 통신 후에, 하나 이상의 종류의 설정 정보 중 적어도 하나에 변경이 있는지 여부를 판단하는 단계;
    상기 하나 이상의 종류의 설정 정보의 변경 유무를 나타내는 판별 정보를 생성하는 단계; 및
    상기 판별 정보에 기초해서, 상기 다른 통신 장치와의 통신을 제어하는 단계
    를 실행시키고,
    상기 판별 정보는 비트맵이고, 상기 비트맵의 비트의 수는 상기 설정 정보의 종류의 개수와 동일하며,
    상기 비트맵의 각 비트는, 대응하는 상기 설정 정보가 상기 다른 통신 장치와의 전회의 통신 후에 변경된 경우에는 1로 설정되고, 변경되지 않은 경우에는 0으로 설정되는,
    컴퓨터로 읽을 수 있는 비 일시적 기록 매체에 저장된 프로그램.
  20. 컴퓨터로 읽을 수 있는 비 일시적 기록 매체에 저장된 프로그램에 있어서,
    무선 통신이 가능한 통신 장치를 제어하고, 상기 통신 장치에,
    다른 통신 장치와 페어링 하는 단계;
    상기 다른 통신 장치로부터, 하나 이상의 종류의 설정 정보를 갱신할 것인지 아닌지를 나타내는 판별 정보를 수신하는 단계; 및
    상기 판별 정보에 기초해서, 상기 다른 통신 장치와의 통신을 제어하는 단계
    를 실행시키고,
    상기 판별 정보는, 상기 설정 정보의 종류의 개수의 비트를 갖는 제1의 비트맵이고,
    상기 다른 통신 장치와의 전회의 통신 후에 상기 하나 이상의 종류의 설정 정보에 변경이 있는지를 나타내는 제2의 비트맵을 생성하고,
    상기 제1의 비트맵과 제2의 비트맵에 기초해서, 상기 하나 이상의 종류의 설정 정보를 상기 다른 통신 장치의 설정 정보와 동기시키는,
    컴퓨터로 읽을 수 있는 비 일시적 기록 매체에 저장된 프로그램.
KR1020170123811A 2016-12-27 2017-09-25 통신 장치, 통신 방법, 및 기억 매체에 저장된 프로그램 KR102398992B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPJP-P-2016-253430 2016-12-27
JP2016253430A JP6880719B2 (ja) 2016-12-27 2016-12-27 通信装置、通信方法、電子時計及びプログラム

Publications (2)

Publication Number Publication Date
KR20180076277A KR20180076277A (ko) 2018-07-05
KR102398992B1 true KR102398992B1 (ko) 2022-05-16

Family

ID=62630206

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170123811A KR102398992B1 (ko) 2016-12-27 2017-09-25 통신 장치, 통신 방법, 및 기억 매체에 저장된 프로그램

Country Status (4)

Country Link
US (1) US10432771B2 (ko)
JP (1) JP6880719B2 (ko)
KR (1) KR102398992B1 (ko)
CN (1) CN108616289B (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6880719B2 (ja) * 2016-12-27 2021-06-02 カシオ計算機株式会社 通信装置、通信方法、電子時計及びプログラム
KR102323176B1 (ko) * 2017-09-19 2021-11-08 엘지전자 주식회사 디스플레이 장치 및 그를 제어하는 단말기
CN114826946B (zh) * 2022-06-29 2022-09-13 深圳红途科技有限公司 未授权访问接口的检测方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150327005A1 (en) * 2012-02-07 2015-11-12 Seiko Epson Corporation Wireless communication device
US20160128112A1 (en) * 2014-10-31 2016-05-05 Aruba Networks, Inc. Access control in bluetooth® low energy devices
US20160157108A1 (en) * 2013-12-24 2016-06-02 Lg Electronics Inc. Method for ue cancelling interference from neighbouring cells in wireless communication system and apparatus therefor

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002051058A (ja) * 2000-04-20 2002-02-15 Matsushita Electric Ind Co Ltd 通信システム、車載通信システム、通信機器、及び車載機器
GB0124323D0 (en) * 2001-10-10 2001-11-28 Nokia Corp Setting mode of communication
US7941177B2 (en) * 2004-09-15 2011-05-10 Samsung Electronics Co., Ltd Wireless terminal apparatus for automatically changing WLAN standard and method thereof
US20060146805A1 (en) * 2005-01-05 2006-07-06 Krewson Brian G Systems and methods of providing voice communications over packet networks
JP4506658B2 (ja) * 2005-11-30 2010-07-21 ソニー株式会社 無線通信システム,通信装置,設定情報提供方法,設定情報取得方法,およびコンピュータプログラム
EP2063571A1 (en) * 2006-09-13 2009-05-27 Panasonic Corporation Communication device
US20080253326A1 (en) * 2007-04-13 2008-10-16 Qualcomm Incorporated Synchronous adaptive harq
US8843115B2 (en) * 2008-06-23 2014-09-23 Qualcomm Incorporated Method and apparatus for managing system information modification in a wireless communication system
US8774722B2 (en) * 2009-07-09 2014-07-08 Mediatek Inc. Systems and methods for reducing interference between a plurality of wireless communications modules
JP5381448B2 (ja) * 2009-07-21 2014-01-08 富士ゼロックス株式会社 情報伝送システム、情報伝送装置及びプログラム
JP5738790B2 (ja) * 2012-03-06 2015-06-24 オリンパス株式会社 無線通信端末、無線通信システム、無線セットアップ方法、およびプログラム
JP5983380B2 (ja) * 2012-12-11 2016-08-31 富士通株式会社 移動局装置、通信システム、通信方法及びコンピュータプログラム
JP6141053B2 (ja) 2013-03-08 2017-06-07 クラリオン株式会社 端末装置、通信システム、情報処理装置、及び通信プログラム
JP2015076694A (ja) * 2013-10-08 2015-04-20 コニカミノルタ株式会社 画像形成装置
DE102015208547A1 (de) * 2014-05-09 2015-11-12 Apple Inc. Erweiterte bluetooth-kommunikationsmodi
WO2016003018A1 (ko) * 2014-07-02 2016-01-07 엘지전자(주) 이동단말기 및 그 제어방법
US10652243B2 (en) * 2014-09-04 2020-05-12 Lg Electronics Inc. Method and device for controlling device by using Bluetooth Low Energy (LE) technique
JP6454120B2 (ja) * 2014-10-02 2019-01-16 キヤノン株式会社 通信装置、制御方法、及びプログラム
KR20160042569A (ko) * 2014-10-10 2016-04-20 삼성전자주식회사 다중 연결 방법 및 이를 지원하는 전자 장치
KR20160051977A (ko) * 2014-10-30 2016-05-12 삼성전자주식회사 통신 서비스 운용 방법 및 이를 지원하는 전자 장치
JP6413691B2 (ja) * 2014-11-20 2018-10-31 株式会社リコー データ通信装置、データ通信方法、及びデータ通信プログラム
US10524298B2 (en) * 2015-05-07 2019-12-31 Lg Electronics Inc. Method and apparatus for sending and receiving data on Bluetooth
CN104967730A (zh) * 2015-05-12 2015-10-07 广东美晨通讯有限公司 通话方式及终端
US10827391B2 (en) * 2015-07-26 2020-11-03 Lg Electronics Inc. Method and device for connecting substitute communication means by using bluetooth low energy (LE) technique
JP6880719B2 (ja) * 2016-12-27 2021-06-02 カシオ計算機株式会社 通信装置、通信方法、電子時計及びプログラム
JP6667476B2 (ja) * 2017-06-30 2020-03-18 キヤノン株式会社 通信装置、制御方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150327005A1 (en) * 2012-02-07 2015-11-12 Seiko Epson Corporation Wireless communication device
US20160157108A1 (en) * 2013-12-24 2016-06-02 Lg Electronics Inc. Method for ue cancelling interference from neighbouring cells in wireless communication system and apparatus therefor
US20160128112A1 (en) * 2014-10-31 2016-05-05 Aruba Networks, Inc. Access control in bluetooth® low energy devices

Also Published As

Publication number Publication date
JP2018107680A (ja) 2018-07-05
KR20180076277A (ko) 2018-07-05
CN108616289A (zh) 2018-10-02
US10432771B2 (en) 2019-10-01
JP6880719B2 (ja) 2021-06-02
CN108616289B (zh) 2020-09-15
US20180183919A1 (en) 2018-06-28

Similar Documents

Publication Publication Date Title
JP7163995B2 (ja) 通信装置、通信方法、及びプログラム
EP3893109B1 (en) Method and device for connecting bluetooth devices
CN112787685B (zh) 用于支持无线通信的方法、装置及***
US10932313B2 (en) Wireless connection switching method and terminal
EP2557825B1 (en) Methods and apparatus for forming wi-fi p2p group using Wi-Fi Direct
KR20040041677A (ko) 서버로부터의 요청 메시지가 최대 크기를 가지는 경우에동기 시스템에서 서버 개시 동기화를 이루는 방법
US10721611B2 (en) Method and device for controlling device by using Bluetooth technology
JP2017515321A (ja) 無線通信システムにおけるブルートゥース低電力エネルギーを利用してオブジェクト送信サービスを行うための方法及び装置
KR102398992B1 (ko) 통신 장치, 통신 방법, 및 기억 매체에 저장된 프로그램
US10194477B2 (en) Method and apparatus for controlling a device using bluetooth technology
US11367449B2 (en) Method and apparatus for calling voice recognition service by using Bluetooth low energy technology
US10484293B2 (en) Communication device, communication method, and storage medium
US20210243599A1 (en) User authentication method through bluetooth device and device therefor
US20230103916A1 (en) Audio data reception method using short-range wireless communication in wireless communication system, and apparatus therefor
KR102197942B1 (ko) 무선 통신시스템에서 데이터의 송수신 방법, 장치 및 시스템
US20240048990A1 (en) Bluetooth connection method and system, intelligent terminal, and computer storage medium
KR20170056807A (ko) 무선 통신 시스템에서 데이터를 송수신하기 위한 방법 및 장치

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant