KR20220083221A

KR20220083221A - IoT 환경의 허브 장치 및 로컬 네트워크 기반 이벤트 처리 방법

Info

Publication number: KR20220083221A
Application number: KR1020200173244A
Authority: KR
Inventors: 김석현; 김은철; 이종원; 송가진; 이선기
Original assignee: 삼성전자주식회사
Priority date: 2020-12-11
Filing date: 2020-12-11
Publication date: 2022-06-20
Also published as: WO2022124846A1; US20230300197A1

Abstract

다양한 실시예에 따른 전자 장치는, 통신 모듈, 메모리, 및 상기 통신 모듈 및 상기 메모리와 작동적으로(operatively) 연결되는 프로세서를 포함하고, 상기 프로세서는, 제1외부 장치에서 감지되는 트리거 이벤트 및 상기 트리거 이벤트에 대응하는 룰 세트, 목적지, 또는 동작 커맨드 중 적어도 하나를 맵핑한 룰 정보를 상기 통신 모듈을 통해 클라우드 서버로부터 수신하여 상기 메모리의 로컬 룰 데이터베이스에 저장하고, 상기 통신 모듈을 통해 제1외부 장치로부터 트리거 이벤트를 수신하고, 상기 로컬 룰 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 정보를 확인하고, 및 상기 확인된 룰 정보에 기초하여, 상기 트리거 이벤트와 관련된 정보를 상기 통신 모듈을 통해 제2외부 장치로 전송하도록 설정될 수 있다.

Description

IoT 환경의 허브 장치 및 로컬 네트워크 기반 이벤트 처리 방법 {HUB DEVICE OF IOT ENVIRONMENT AND METHOD FOR PROCESSING EVENT BASED ON LOCAL NETWORK THEREOF}

본 문서는 IoT(internet of things)에 대한 것이며, 보다 상세하게는 IoT 환경의 로컬 네트워크에 존재하는 허브 장치의 룰 처리 방법에 대한 것이다.

클라우드 컴퓨팅(cloud computing) 기술은 사용자와 다른 위치에 존재하는 컴퓨팅 자원을 네트워크를 통해 사용자에게 제공하여 서버, 저장소, 소프트웨어, 또는 분석과 같은 컴퓨팅 서비스를 제공하는 기술이다. 사물 인터넷(internet of things, 이하 IoT)에서 생성된 데이터를 처리하기 위해 클라우드 컴퓨팅이 활용되고 있다. IoT 기기에서 수집한 사용자의 데이터나 컨텐츠는 클라우드 서버에 저장되고, 데이터의 가공을 통해 클라우드 서비스가 사용자에게 제공될 수 있다.

급격하게 성장하는 IoT 환경은 다양한 기기들을 연결하여 사용자가 다양한 기기들을 쉽게 관리하고 사용하게 만들어 준다. IoT 환경에서 제공되는 서비스로 자동화 기술을 예로 들 수 있다. 자동화 기술은 연결된 기기들이 미리 설정된 조건에 따라 사용자의 명령이 없을 때도 각 기기들이 상호 작용하며 동작하도록 하는 기술이다. 자동화 기술은 사용자의 IoT 환경이 사용자에게 최적의 환경을 만들 수 있도록 할 수 있다.

IoT 환경의 자동화 기술은 클라우드를 통해 이루어 질 수 있다. 예를 들어, 특정 기기는 자신의 상태 변화나 동작을 클라우드 서버에 전송하고, 클라우드 서버는 사용자가 설치한 룰에 따라 다른 기기에 명령을 내려 자동화를 수행하게 할 수 있다. 이와 같은, 클라우드 기반의 자동화 기술은 IoT 환경의 모든 기기들이 클라우드와 연결되어, 각 기기의 패킷이 클라우드를 통해 다른 기기에 전달될 수 있으며, 이에 따라 딜레이의 증가, 보안상 문제, 및/또는 서버 비용의 증가를 야기할 수 있다.

본 문서의 다양한 실시예에 따르면, 클라우드에 데이터를 전송하지 않고 로컬 네트워크 기반으로 특정 기기에서 발생하는 이벤트에 기초하여 다른 기기를 동작 시킬 수 있다.

다양한 실시예에 따른, 전자 장치의 로컬 네트워크 기반 이벤트 처리 방법은, 제1외부 장치에서 감지되는 트리거 이벤트 및 상기 트리거 이벤트에 대응하는 룰 세트, 목적지, 또는 동작 커맨드 중 적어도 하나를 맵핑한 룰 정보를 클라우드 서버로부터 수신하여 로컬 룰 데이터베이스에 저장하는 동작, 제1외부 장치로부터 트리거 이벤트를 수신하는 동작, 상기 로컬 룰 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작, 및 상기 확인된 룰 정보에 기초하여, 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작을 포함할 수 있다.

다양한 실시예에 따른 전자 장치는, 통신 모듈, 메모리, 및 상기 통신 모듈 및 상기 메모리와 작동적으로(operatively) 연결되는 프로세서를 포함하고, 상기 프로세서는, 트리거 이벤트 및 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 제1외부 장치를 맵핑한 룰 정보를 상기 통신 모듈을 통해 클라우드 서버로부터 수신하여 상기 메모리의 로컬 룰 데이터베이스에 저장하고, 상기 통신 모듈을 통해 제2외부 장치로부터 트리거 이벤트와 관련된 정보를 수신하고, 상기 수신된 트리거 이벤트 관련 정보에 기초하여, 상기 로컬 룰 데이터베이스에서 상기 동작 커맨드 및 상기 동작 커맨드를 수행할 상기 제1외부 장치를 확인하고, 및 상기 통신 모듈을 통해 상기 제1외부 장치에 상기 동작 커맨드를 전송하도록 설정될 수 있다.

본 문서의 다양한 실시예에 따르면, 클라우드에 데이터를 전송하지 않고 로컬 네트워크 기반으로 특정 기기에서 발생하는 이벤트에 기초하여 다른 기기를 동작 시킬 수 있는 IoT 환경의 허브 장치 및 허브 장치의 로컬 네트워크 기반 이벤트 처리 방법을 제공할 수 있다.

도 1은 다양한 실시예에 따른 IoT 환경 내의 장치들을 도시한 것이다.
도 2a 및 도 2b는 다양한 실시예에 따른 IoT 시스템의 각 장치들을 도시한 것이다.
도 3은 다양한 실시예에 따른 클라우드 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.
도 4는 다양한 실시예에 따른 사용자 장치의 블록도이다.
도 5는 다양한 실시예에 따른 허브 장치의 블록도이다.
도 6은 다양한 실시예에 따른 허브 장치가 자동화 룰을 설치하는 과정의 흐름도이다.
도 7은 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.
도 8은 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.
도 9는 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.
도 10은 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.
도 11은 다양한 실시예에 따른 로컬 네트워크 기반 이벤트 자동화 처리 방법의 흐름도이다.
도 12는 다양한 실시예에 따른 로컬 네트워크 기반 이벤트 자동화 처리 방법의 흐름도이다.
도 13은 다양한 실시예에 따른 로컬 네트워크 기반 이벤트 자동화 처리 방법의 흐름도이다.
도 14a, 14b 및 14c는 다양한 실시예에 따른 IoT 기기의 제어를 위해 사용자 장치에서 제공되는 사용자 인터페이스를 도시한 것이다.
도 15a 및 15b는 다양한 실시예에 따른 IoT 기기의 제어를 위해 사용자 장치에서 제공되는 사용자 인터페이스를 도시한 것이다.

도 1은 다양한 실시예에 따른 IoT 환경(또는 IoT 시스템) 내의 장치들을 도시한 것이다.

도 1을 참조 하면, IoT(internet of things) 시스템(또는 엣지 컴퓨팅 시스템)(100)은 적어도 하나의 리프 장치(120)(leaf device), 적어도 하나의 허브 장치(110)(hub device)(또는 엣지 장치(edge device)), 사용자 장치(130)(user device) 및 클라우드 네트워크(140)(cloud network)를 포함할 수 있다. 예를 들면, 리프 장치(120), 허브 장치(110), 및 사용자 장치(130)는 인접하는 위치(예: 집 안)에 배치되어 동일한 홈 네트워크(예: 동일한 AP(access point))에 연결될 수 있고, 클라우드 네트워크(140)는 원격으로 위치하되 인터넷을 통해 리프 장치(120), 허브 장치(110), 및 사용자 장치(130)와 연결될 수 있다.

본 문서의 다양한 실시예들에서 엣지 컴퓨팅 서비스(edge computing service)는 리프 장치와 인접하여 위치하고 동일한 홈 네트워크 상에 위치하는 허브 장치에 리프 장치에서 획득한 데이터를 전송하고, 허브 장치 상에서 일련의 데이터 처리 및 기타 서비스를 제공하는 기술을 의미할 수 있다. 본 문서의 다양한 실시예들에서는 센서를 통해 데이터를 획득하는 장치(예: 카메라(121), 냉장고(122), 전구(123a), 디지털 온도계(123b), 또는 모션 센서(123c))를 리프 장치로 정의하지만, 리프 장치는 엣지 컴퓨팅 서비스의 클라이언트 장치, 엔드 장치, 센서 장치, IoT 장치, 또는 슬레이브 장치와 같이 다른 명칭으로 정의될 수도 있다. 또한, 본 문서의 다양한 실시예들에서는 허브 장치로 정의하지만, 허브 장치는 엣지 컴퓨팅 서비스의 엣지 장치, 엣지 서버, 서버 장치, 마스터 장치, 또는 서비스 장치와 같이 다른 명칭으로 정의될 수도 있다.

본 문서에서는 엣지 컴퓨팅 시스템(edge computing system)(100) 내에서 각 장치의 기능, 또는 동작에 따라서 리프 장치(120), 허브 장치(110), 및 사용자 장치(130)로 분류해서 설명하나, 동일한 장치(예: 스마트 폰, 태블릿 PC)가 경우에 따라 리프 장치(120), 허브 장치(110), 및 사용자 장치(130) 중 어느 하나로 동작할 수도 있다. 다시 말하면, 본 문서의 다양한 실시예들에서 설명하는 장치의 명칭, 및/또는 정의가 해당 장치의 기능 및/또는 동작을 제한하지 않는다.

다양한 실시예에 따르면, 리프 장치(120)는 IoT 시스템(100)의 엔드 포인트(end point)로써 센서를 이용해 다양한 데이터를 수집하여 허브 장치(110) 또는 클라우드 네트워크(140)로 전송할 수 있다. 또한, 리프 장치(120)는 클라우드 네트워크(140) 또는 사용자 장치(130)로부터 전달되는 커맨드에 따라 다양한 동작을 수행할 수 있다. 도 1을 참조 하면, 카메라(121), 냉장고(122), 전구(123a), 디지털 온도계(123b), 또는 모션 센서(123c)와 같은 장치가 리프 장치(120)가 될 수 있다.

다양한 실시예에 따르면, 리프 장치(120) 중 적어도 일부(예: 카메라(121), 냉장고(122))는 인터넷을 통해 클라우드 네트워크(140)에 접속할 수 있으며, 리프 장치(120) 중 인터넷 프로토콜(IP)을 지원하지 않는 장치(예: 전구(123a), 디지털 온도계(123b), 또는 모션 센서(123c))는 지원하는 비 IP 기반 통신(예: Bluetooth, Zigbee)으로 중계 장치(124)에 센싱한 데이터를 전송하고, 중계 장치(124)는 인터넷을 통해 클라우드 네트워크(140)에 각 리프 장치(123a, 123b, 123c)의 센싱 데이터를 전송할 수 있다.

다양한 실시예에 따르면, 클라우드 네트워크(140)는 네트워크 상에 위치하고, IoT 시스템(100)에서 클라우드 컴퓨팅 서비스를 지원하는 다양한 서버 장치(예: IoT 매니지 서버, IoT 허브 서버)를 포함할 수 있다. 클라우드 네트워크(140)는 리프 장치(120)에서 수신한 센싱 데이터에 대한 컴퓨팅 처리를 수행하고, 리프 장치(120)의 제어를 위한 명령을 전송할 수 있다.

다양한 실시예에 따르면, 클라우드 네트워크(140)는 홈 네트워크 내의 특정 장치가 허브 장치(110)로 동작할 수 있도록 운영 및 관리하는 기능을 수행할 수 있다. 예를 들어, 클라우드 네트워크(140)는 IoT 서버(예: IoT 매니지 서버, 또는 IoT 허브 서버)를 포함하며, IoT 서버는 허브 장치(110)와 리프 장치(120)의 등록, 연결, 관리 등 엣지 컴퓨팅 서비스를 수행하고, 엣지 컴퓨팅 서비스를 위해 필요한 모듈(예: 디바이스 모듈, 서비스 모듈)을 허브 장치(110)에 제공할 수 있다.

다양한 실시예에 따르면, 허브 장치(110)는 리프 장치(120)로부터 수신되는 데이터를 직접 처리하거나, 클라우드 네트워크(140)(예: IoT 서버)로 전송할 수 있다. 허브 장치(110)는 TV(112), 또는 태블릿 PC(111)와 같이 엣지 컴퓨팅 서비스를 위해 필요한 하드웨어 및/또는 소프트웨어 자원을 포함하는 장치일 수 있다. 허브 장치(110)는 인터넷을 통해 클라우드 네트워크(140)와 연결될 수 있고, 리프 장치(120)와는 직접 통신(direct communication), 메시 네트워크(mesh network), 또는 액세스 포인트를 통해 통신할 수 있다.

다양한 실시예에 따르면, 홈 네트워크 내에 복수의 허브 장치들(110)이 존재할 수 있으며, 리프 장치(120)는 복수의 허브 장치들(110) 중 어느 하나와 연결되어 데이터를 전송할 수 있다. 예를 들면, 허브 장치(110)는 특정 리프 장치(120)가 연결될 때, 엣지 컴퓨팅 서비스를 위해 필요한 모듈(예: 디바이스 모듈, 서비스 모듈)을 클라우드 네트워크(140)로부터 다운로드 받아 실행할 수 있다.

다양한 실시예에 따르면, 허브 장치(110)는 기기 고유의 기능(예: TV의 영상 출력 기능)을 수행할 수 있으며, 고유 기능의 수행과 적어도 일부 동시에 또는 고유 기능을 수행하지 않는 유휴 시간 동안 하드웨어 및/또는 소프트웨어 자원을 통해 엣지 컴퓨팅 서비스를 수행할 수 있다.

다양한 실시예에 따르면, 허브 장치(110)는 이벤트 자동화 처리를 위한 정보들을 포함하는 룰 정보를 저장할 수 있다. 예를 들어, 룰 정보는 특정 리프 장치에서 발생한 트리거 이벤트에 대응하여, 다른 리프 장치에서 수행할 동작을 지시하는 동작 커맨드를 맵핑한 규칙일 수 있다. 허브 장치(110)는 클라우드 네트워크(140)로부터 룰 정보를 수신하여 허브 장치(110)의 메모리 상에 데이터베이스를 구축 할 수 있다. 허브 장치(110)의 세부 구성 및 동작에 대해서는 도 5를 통해 보다 상세히 설명하기로 한다.

다양한 실시예에 따르면, 사용자 장치(130)는 어플리케이션을 통해 엣지 컴퓨팅 서비스(edge computing service)와 관련된 다양한 사용자 인터페이스(user interface)를 제공할 수 있다. 예를 들어, 사용자 장치(130)는 리프 장치(120)에서 획득한 데이터(예: 카메라 영상 스트리밍) 또는 상기 데이터를 허브 장치(110) 또는 클라우드 네트워크(140)에서 처리한 결과 데이터(예: 사람 인식)를 디스플레이 상에 표시할 수 있다. 또한, 사용자 장치(130)는 허브 장치(110) 및/또는 리프 장치(120)의 연결, 또는 서버 등록과 같은 사용자 입력을 수신하여 클라우드 네트워크(140)로 전송할 수 있다. 사용자 장치(130)의 세부 구성 및 동작에 대해서는 도 4를 통해 보다 상세히 설명하기로 한다.

도 2a 및 도 2b는 다양한 실시예에 따른 엣지 컴퓨팅 시스템의 각 장치들을 도시한 것이다.

도 2a를 참조 하면, 엣지 컴퓨팅 시스템(또는 IoT 시스템)(200)은 리프 장치(220), 허브 장치(210), 사용자 장치(230), IoT 허브 서버(250) 및 IoT 매니지 서버(240)를 포함할 수 있다. 도 1을 통해 설명한 바와 같이, 홈 네트워크 상에 다양한 IoT 기기들이 존재할 수 있으며, 도 2에서는 하나의 리프 장치(예: 도 1의 카메라(121))와 하나의 허브 장치(예: 도 1의 TV(112))를 예로 들어 설명하기로 한다.

다양한 실시예에 따르면, IoT 매니지 서버(240)(예: SmartThings^TM 서버)는 엣지 컴퓨팅 서비스의 결정, 연결 및/또는 운영을 위해 다양한 서비스를 제공하는 서버 장치로써, 프로비전 매니저(242), 모듈 매니저(244), 엣지-리프 매니저(246) 및 자동화 매니저(248)를 포함할 수 있다.

다양한 실시예에 따르면, 프로비전 매니저(242)(provision manager)는 허브 장치(210)가 IoT 허브 서버(250)와 연결될 수 있도록 중간에서 중계하는 기능을 수행할 수 있다. 예를 들어, 프로비전 매니저(242)는 허브 장치(210)가 IoT 매니지 서버(240)에 최초 등록되는 경우에, 허브 장치(210)가 IoT 허브 서버(250)와 연결될 수 있도록 하는 연결 스트링(connection string)을 허브 장치(210)에 전송할 수 있다.

다양한 실시예에 따르면, 모듈 매니저(244)(module manager)는 엣지 컴퓨팅 서비스를 위해 제공하는 다양한 모듈 및 각 서비스를 지원하는 기기에 대한 정보들을 관리할 수 있다. 여기서, 엣지 컴퓨팅 서비스를 수행하기 위해 필요한 모듈은 허브 장치(210)가 리프 장치(220)로부터 전송되는 데이터를 외부 서버(예: IoT 허브 서버(250))로 전송할 수 있도록 하는 디바이스 모듈(219a, 219b) 및 리프 장치(220)에서 전송되는 데이터를 기반으로 허브 장치(210)에서 서비스를 구현하기 위해 실행되는 프로그램들을 포함하는 서비스 모듈(218)을 포함할 수 있다.

다양한 실시예에 따르면, 엣지-리프 매니저(246)(edge-leaf manager)는 여러 홈 네트워크에 존재하는 허브 장치(210)와 리프 장치(220)의 연결 상태를 관리할 수 있다. 예를 들어, IoT 매니지 서버(240)에 등록된 허브 장치(210)와 리프 장치(220)가 서로 연결 또는 연결 해제 되는 경우, 허브 장치(210) 및/또는 리프 장치(220)에서 연결 또는 연결 해제 정보를 IoT 매니지 서버(240)에 전송하고, IoT 매니지 서버(240)는 실시간으로 어떠한 허브 장치(210)와 리프 장치(220)가 연결되었는지, 어떠한 서비스를 수행하는 중인지에 대한 정보를 저장할 수 있다.

다양한 실시예에 따르면, 자동화 매니저(248)는 자동화 룰(automation rule)을 데이터베이스에 저장하고, 자동화 룰을 로컬 네트워크의 허브 장치(210)에 제공하는 기능을 수행할 수 있다. 예를 들어, 자동화 매니저(248)는 허브 장치(210)가 온보딩 시 및/또는 업그레이드 시에 로컬 네트워크에 위치하는 기기들에 대한 룰 정보를 허브 장치(210)에 제공하고, 허브 장치(210)는 로컬 룰 데이터베이스를 저장할 수 있다.

다양한 실시예에 따르면, 리프 장치(220)가 특정 엣지 장치(예: 도 1의 태블릿 PC(111))와 연결되어 엣지 컴퓨팅 서비스를 수행하다가 핸드오버 이벤트에 따라 해당 엣지 장치와 연결을 해제하고 다른 엣지 장치(예: 도 1의 TV(112))와 연결되어 엣지 컴퓨팅 서비스를 수행하는 경우, IoT 매니지 서버(240)는 핸드오버 이벤트에 따라 변경된 허브 장치(210)와 리프 장치(240)의 연결 정보를 업데이트 할 수 있다.

다양한 실시예에 따르면, IoT 허브 서버(250)는 클라우드 컴퓨팅 플랫폼(cloud computing platform)을 지원 하며, 클라우드 환경 내에 있는 리프 장치(220)와 허브 장치(210)가 서로 연결되는 데 필요한 데이터를 제공할 수 있다. IoT 허브 서버(250)는 IoT 허브(252) 및 모듈 레지스트리(254)를 포함할 수 있다.

다양한 실시예에 따르면, 모듈 레지스트리(254)(module registry)는 엣지 컴퓨팅 서비스를 수행하기 위해 필요한 모듈들(예: 디바이스 모듈(219), 서비스 모듈(218))의 저장소일 수 있다.

다양한 실시예에 따르면, IoT 허브(IoT hub)(252)는 허브 장치(210)와 연결을 유지하며, 모듈 레지스트리(254)에 저장된 모듈을 허브 장치(210)에 제공하고, 여러 허브 장치(210)에 설치된 모듈들의 정보를 유지할 수 있다.

다양한 실시예에 따르면, 허브 장치(210)(예: 도 1의 엣지 장치(110))는 TV, 태블릿 PC, 또는 랩톱 PC와 같은 기기 고유의 기능을 가지고, 엣지 컴퓨팅 서비스를 위한 하드웨어 및/또는 소프트웨어 구성(예: 엣지 런타임, 기본 모듈)을 포함하는 장치일 수 있다. 고유 기능의 수행과 적어도 일부 동시에 또는 고유 기능을 수행하지 않는 유휴 시간 동안 하드웨어 및/또는 소프트웨어 자원을 통해 엣지 컴퓨팅 서비스를 수행할 수 있다.

다양한 실시예에 따르면, 허브 장치(210)는 클라우드(예: IoT 매니지 서버(240), IoT 허브 서버(250))와 통신하기 위한 인터페이스(212), 운영 체제(OS, operating system)(214) 엣지 런타임(216), 서비스 모듈(218) 및 디바이스 모듈(219)을 포함할 수 있다. 예를 들면, 허브 장치(210)는 운영 체제(214)를 동작하기 위한 하드웨어 조건(예: CPU 성능)이 필요할 수 있고, RTOS(real time operating system)로 구성될 수 있다.

허브 장치(210)의 공정 과정 또는 소프트웨어 업그레이드를 통해 허브 장치(210)에 엣지 런타임(216)(edge runtime) 및 엣지 컴퓨팅을 위한 기본 모듈이 설치될 수 있다. 여기서, 엣지 런타임(216)은 IoT 서버와 연동을 위한 데몬(daemon) 프로그램을 포함할 수 있으며, 기본 모듈은 IoT 서버와 통신에 필요한 프로그램으로써 컨테이너(container)로 구성될 수 있다. 예를 들면, 기본 모듈은 엣지 런타임(216) 환경에서 설치되는 컨테이너일 수 있다.

다양한 실시예에 따르면, 허브 장치(210)는 특정 리프 장치(220)와 연결되는 경우, IoT 허브 서버(250)로부터 엣지 컴퓨팅 서비스를 수행하기 위한 적어도 하나의 모듈을 수신하여 설치할 수 있다. 예를 들면, 적어도 하나의 모듈은, 연결되는 리프 장치(220)의 종류 및/또는 수행할 수 있는 서비스의 종류에 따라 결정될 수 있으며, 해당 리프 장치(220)에 대응하는 디바이스 모듈(219) 및/또는 수행할 서비스의 종류에 대응하는 서비스 모듈(218)을 포함할 수 있다. 허브 장치(210)가 복수의 리프 장치들(220)과 연결되는 경우, 각각의 리프 장치(220)와 대응하는 디바이스 모듈(219)(예: 디바이스 모듈 1(219a), 디바이스 모듈 2(219b))이 설치될 수 있다. 허브 장치(210)는 프로비전(provision) 과정에서 엣지 런타임(216)을 실행하여 IoT 허브 서버(250)와 연결되고, 리프 장치(220)의 종류에 따라 상기 적어도 하나의 모듈이 추가로 설치되고 실행될 수 있다. 허브 장치(210)는 IoT 허브 서버(250) 또는 IoT 매니지 서버(240)로부터 수신되는 커맨드에 따라 엣지 모드를 활성화 또는 비활성화 할 수 있다. 엣지 모드가 비활성화 된 경우 허브 장치(210)는 고유의 기능(예: TV의 영상 출력 기능)만 수행하게 되고, 디바이스 모듈(219) 및 서비스 모듈(218)은 실행되지 않을 수 있다.

다양한 실시예에 따르면, 리프 장치(220)(예: 도 1의 리프 장치(120))는 센서를 이용해 획득한 데이터를 연결된 허브 장치(210) 또는 클라우드 네트워크(예: IoT 매니지 서버(240), IoT 허브 서버(250))에 전송할 수 있다. 예를 들어, 리프 장치(220)로 동작하는 IP(internet protocol) 카메라의 경우, 허브 장치(210)와 연결되어 영상 스트리밍을 허브 장치(210)에 전송할 수 있다.

다양한 실시예에 따르면, 사용자 장치(230)는 스마트 폰, 또는 태블릿 PC와 같이 다양한 어플리케이션을 실행할 수 있고, 사용자 인터페이스(UI, user interface)를 표시할 수 있는 디스플레이를 포함하는 장치일 수 있다. 사용자 장치(230)는 엣지 컴퓨팅 서비스를 위한 어플리케이션을 설치 및/또는 실행하고, 해당 어플리케이션을 통해 리프 장치(220)에서 생성된 컨텐츠와 알림(notification)을 수신할 수 있다. 허브 장치(210)와 리프 장치(220)가 연결된 경우, 리프 장치(220)에서 생성된 컨텐츠나 알림은, 허브 장치(210)를 통하여 사용자 장치(230)에 전송될 수 있다.

다양한 실시예에 따르면, IoT 허브 서버(250) 및 IoT 매니지 서버(240)의 기능은 하나의 서버 장치(예: 도 2b의 IoT 서버(260))에 의해 수행될 수 있다. 예를 들어, 도 2b를 참조 하면, IoT 서버(260)는 앞서 설명한 IoT 허브 서버(250) 및 IoT 매니지 서버(240)의 구성인 IoT 허브(261)(예: 도 2a의 IoT 허브(252)), 모듈 레지스트리(262)(예: 도 2a의 모듈 레지스트리(254)), 프로비전 매니저(263)(예: 도 2a의 프로비전 매니저(242)), 모듈 매니저(264)(예: 도 2a의 모듈 매니저(244)) 및 엣지-리프 매니저(265)(예: 도 2a의 엣지-리프 매니저(246))를 포함할 수 있다.

또는 상기 기능들은 셋 이상의 복수의 서버 장치들에 의해 수행될 수도 있다. 예를 들어, 도 2a의 IoT 허브 서버(250), IoT 매니지 서버(240)의 각 구성들이 네트워크 상에 존재하는 셋 이상의 복수의 서버 장치들에 의해 분산 배치 되거나, 각 구성에서 수행되는 일부 동작들도 여러 서버 장치들에 의해 분산 수행될 수 있다.

도 3은 다양한 실시예에 따른 클라우드 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.

본 문서에서 자동화 기술은 연결된 기기들이 미리 설정된 조건에 따라 사용자의 명령이 없을 때도 각 기기들이 상호 작용하며 동작하도록 하는 기술이며, 자동화 룰(automation rule)(이하, 룰)은 특정 조건이 되면 설치되어 있는 룰을 실행하라는 시작점을 지시하는 트리거(trigger), 트리거가 발생 하였을 때 실제 실행되는 동작을 지시하는 액터(actor) 및 어떠한 동작을 트리거로 판단하여 어떤 동작을 수행 시킬지에 대한 정보를 포함하는 룰(rule)로 구성될 수 있다.

도 3을 참조 하면, IoT 시스템(300)은 허브 장치(310), 사용자 장치(330), 클라우드 서버(340), 트리거 장치(350) 및 액터 장치(355)를 포함할 수 있다. 이하에서는 IoT 시스템의 특정 장치가 하나의 장치로 기능하는 경우에 대해 설명하기로 하나, 하나의 장치가 다른 기능의 장치, 예를 들어, 모션 센서는 트리거 장치(350)로 및/또는 액터 장치(355)로 동작할 수도 있다.

다양한 실시예에 따르면, 트리거 장치(350)(trigger device)는 IoT 환경에서 특정 이벤트를 감지하는 장치이고, 액터 장치(355)(actor device)는 해당 이벤트에 대응해서 특정 동작을 수행하는 장치일 수 있다. 예를 들어, 트리거 장치(350)인 모션 센서(예: 도 1의 모션 센서(123c))는 주변의 오브젝트의 모션을 감지하여 트리거 이벤트를 발생시킬 수 있고, 액터 장치(355)인 전구(예: 도 1의 전구(123a))는 모션 센서의 모션 감지 시 온/오프 될 수 있다.

다양한 실시예에 따르면, 클라우드 서버(340)는 IoT 자동화와 관련된 룰 데이터베이스(345)를 저장할 수 있다. 여기서, 룰 데이터베이스(345)에 저장되는 룰은 트리거 이벤트(예: 모션 감지)와 트리거 이벤트에 대응하는 룰 세트(rule set), 목적지(destination), 또는 동작 커맨드(action command) 중 적어도 하나를 맵핑하여 저장할 수 있다.

다양한 실시예에 따르면, 허브 장치(310)는 로컬 네트워크 상에서 트리거 장치(350) 및 액터 장치(355)와 근거리 무선 통신으로 연결될 수 있고, 클라우드 서버(340)와 PDN(public data network)을 통해 통신할 수 있다. 허브 장치(310)는 기기 고유의 기능(예: TV의 영상 출력 기능)을 수행할 수 있으며, 고유 기능의 수행과 적어도 일부 동시에 또는 고유 기능을 수행하지 않는 유휴 시간 동안 하드웨어 및/또는 소프트웨어 자원을 통해 자동화 서비스에서 요구되는 동작을 처리할 수 있다.

다양한 실시예에 따르면, 사용자 장치(330)는 어플리케이션을 통해 자동화 서비스와 관련된 다양한 사용자 인터페이스를 제공할 수 있다. 사용자 장치(330)는 어플리케이션 상의 사용자 입력에 기초하여, 자동화 룰을 설정할 수 있다. 예를 들어, 사용자 장치(330)는 사용자 입력에 따라 트리거 장치(350) 및 트리거 장치(350)에서 감지할 수 있는 트리거 이벤트, 해당 트리거 이벤트에 따라서 수행될 동작 및 해당 동작을 수행할 수 있는 액터 장치(355), 트리거 장치(350) 및/또는 액터 장치(355)와 연결될 수 있는 허브 장치(310)를 선택할 수 있다. 사용자 장치(330)는 설정된 자동화 룰을 클라우드 서버(340)로 전송하고, 클라우드 서버(340)는 사용자 장치(330)에서 수신되는 정보에 따라 룰 데이터베이스(345)를 업데이트 할 수 있다.

이하에서는, 도 3을 참조하여, 사용자 장치(330)에 의해 룰이 정의되어 클라우드 서버(340)의 룰 데이터베이스(345)에 저장된 상태에서 트리거 장치(350)(예: 모션 센서)에서 트리거 이벤트 감지 시 각 장치의 동작에 대해 설명하기로 한다.

다양한 실시예에 따르면, 트리거 장치(350)는 오브젝트의 모션이 감지되는 경우, 트리거 이벤트를 발생하고, 연결된 허브 장치(310)에 모션 감지 정보를 전달할 수 있다. 허브 장치(310)는 트리거 장치(350)로부터 수신한 모션 감지 정보를 네트워크를 통해 클라우드 서버(340)로 전송할 수 있다.

다양한 실시예에 따르면, 클라우드 서버(340)는 룰 데이터베이스(345)에서 모션 감지 정보와 맵핑되는 룰 세트를 확인하고, 해당 룰 세트에 정의된 동작 커맨드를 확인할 수 있다. 예를 들어, 모션 감지에 대응하는 동작 커맨드는 전구의 턴 온(turn on) 일 수 있다.

다양한 실시예에 따르면, 클라우드 서버(340)는 확인된 동작 커맨드를 허브 장치(310)에 전송할 수 있다. 허브 장치(310)는 수신된 동작 커맨드를 액터 장치(355)에 전송하고, 액터 장치(355)는 동작 커맨드의 수신에 대응하여 전구를 턴 온 시킬 수 있다.

도 3에서는 클라우드 서버(340)의 룰 데이터베이스(345)를 이용하여 클라우드 기반의 자동화 서비스를 제공하는 실시예에 대해 설명 하였으나, 본 문서의 다양한 실시예들은 트리거 이벤트 발생 시 클라우드 서버(340)에 의존하지 않고, 로컬 네트워크 내의 기기들의 통신에 의해 자동화 룰에 정의된 동작을 수행할 수도 있다.

도 4는 다양한 실시예에 따른 사용자 장치의 블록도이다.

도 4은, 다양한 실시예들에 따른, 네트워크 환경 내의 사용자 장치(401)(예: 도 1의 사용자 장치(130), 도 2의 사용자 장치(230) 또는 도 3의 사용자 장치(330))의 블록도이다. 도 4을 참조하면, 네트워크 환경에서 사용자 장치(401)는 제 1 네트워크(498)(예: 근거리 무선 통신 네트워크)를 통하여 전자 장치(402)와 통신하거나, 또는 제 2 네트워크(499)(예: 원거리 무선 통신 네트워크)를 통하여 전자 장치(404) 또는 서버(408)와 통신할 수 있다. 일실시예에 따르면, 사용자 장치(401)는 서버(408)를 통하여 전자 장치(404)와 통신할 수 있다. 일실시예에 따르면, 사용자 장치(401)는 프로세서, 메모리, 입력 모듈(450), 음향 출력 모듈(455), 디스플레이 모듈(460), 오디오 모듈(470), 센서 모듈(476), 인터페이스(477), 연결 단자(478), 햅틱 모듈(479), 카메라 모듈(480), 전력 관리 모듈(488), 배터리(489), 통신 모듈(490), 가입자 식별 모듈(496), 또는 안테나 모듈(497)을 포함할 수 있다. 어떤 실시예에서는, 사용자 장치(401)에는, 이 구성요소들 중 적어도 하나(예: 연결 단자(478))가 생략되거나, 하나 이상의 다른 구성요소가 추가될 수 있다. 어떤 실시예에서는, 이 구성요소들 중 일부들(예: 센서 모듈(476), 카메라 모듈(480), 또는 안테나 모듈(497))은 하나의 구성요소(예: 디스플레이 모듈(460))로 통합될 수 있다.

프로세서는, 예를 들면, 소프트웨어(예: 프로그램(440))를 실행하여 프로세서에 연결된 사용자 장치(401)의 적어도 하나의 다른 구성요소(예: 하드웨어 또는 소프트웨어 구성요소)를 제어할 수 있고, 다양한 데이터 처리 또는 연산을 수행할 수 있다. 일실시예에 따르면, 데이터 처리 또는 연산의 적어도 일부로서, 프로세서는 다른 구성요소(예: 센서 모듈(476) 또는 통신 모듈(490))로부터 수신된 명령 또는 데이터를 휘발성 메모리(432)에 저장하고, 휘발성 메모리(432)에 저장된 명령 또는 데이터를 처리하고, 결과 데이터를 비휘발성 메모리(434)에 저장할 수 있다. 일실시예에 따르면, 프로세서는 메인 프로세서(421)(예: 중앙 처리 장치 또는 어플리케이션 프로세서) 또는 이와는 독립적으로 또는 함께 운영 가능한 보조 프로세서(423)(예: 그래픽 처리 장치, 신경망 처리 장치(NPU: neural processing unit), 이미지 시그널 프로세서, 센서 허브 프로세서, 또는 커뮤니케이션 프로세서)를 포함할 수 있다. 예를 들어, 사용자 장치(401)가 메인 프로세서(421) 및 보조 프로세서(423)를 포함하는 경우, 보조 프로세서(423)는 메인 프로세서(421)보다 저전력을 사용하거나, 지정된 기능에 특화되도록 설정될 수 있다. 보조 프로세서(423)는 메인 프로세서(421)와 별개로, 또는 그 일부로서 구현될 수 있다.

보조 프로세서(423)는, 예를 들면, 메인 프로세서(421)가 인액티브(예: 슬립) 상태에 있는 동안 메인 프로세서(421)를 대신하여, 또는 메인 프로세서(421)가 액티브(예: 어플리케이션 실행) 상태에 있는 동안 메인 프로세서(421)와 함께, 사용자 장치(401)의 구성요소들 중 적어도 하나의 구성요소(예: 디스플레이 모듈(460), 센서 모듈(476), 또는 통신 모듈(490))와 관련된 기능 또는 상태들의 적어도 일부를 제어할 수 있다. 일실시예에 따르면, 보조 프로세서(423)(예: 이미지 시그널 프로세서 또는 커뮤니케이션 프로세서)는 기능적으로 관련 있는 다른 구성요소(예: 카메라 모듈(480) 또는 통신 모듈(490))의 일부로서 구현될 수 있다. 일실시예에 따르면, 보조 프로세서(423)(예: 신경망 처리 장치)는 인공지능 모델의 처리에 특화된 하드웨어 구조를 포함할 수 있다. 인공지능 모델은 기계 학습을 통해 생성될 수 있다. 이러한 학습은, 예를 들어, 인공지능이 수행되는 사용자 장치(401) 자체에서 수행될 수 있고, 별도의 서버(예: 서버(408))를 통해 수행될 수도 있다. 학습 알고리즘은, 예를 들어, 지도형 학습(supervised learning), 비지도형 학습(unsupervised learning), 준지도형 학습(semi-supervised learning) 또는 강화 학습(reinforcement learning)을 포함할 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은, 복수의 인공 신경망 레이어들을 포함할 수 있다. 인공 신경망은 심층 신경망(DNN: deep neural network), CNN(convolutional neural network), RNN(recurrent neural network), RBM(restricted boltzmann machine), DBN(deep belief network), BRDNN(bidirectional recurrent deep neural network), 심층 Q-네트워크(deep Q-networks) 또는 상기 중 둘 이상의 조합 중 하나일 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은 하드웨어 구조 이외에, 추가적으로 또는 대체적으로, 소프트웨어 구조를 포함할 수 있다.

메모리는, 사용자 장치(401)의 적어도 하나의 구성요소(예: 프로세서 또는 센서 모듈(476))에 의해 사용되는 다양한 데이터를 저장할 수 있다. 데이터는, 예를 들어, 소프트웨어(예: 프로그램(440)) 및, 이와 관련된 명령에 대한 입력 데이터 또는 출력 데이터를 포함할 수 있다. 메모리는, 휘발성 메모리(432) 또는 비휘발성 메모리(434)를 포함할 수 있다.

프로그램(440)은 메모리에 소프트웨어로서 저장될 수 있으며, 예를 들면, 운영 체제(442), 미들 웨어(444) 또는 어플리케이션(446)을 포함할 수 있다.

입력 모듈(450)은, 사용자 장치(401)의 구성요소(예: 프로세서)에 사용될 명령 또는 데이터를 사용자 장치(401)의 외부(예: 사용자)로부터 수신할 수 있다. 입력 모듈(450)은, 예를 들면, 마이크, 마우스, 키보드, 키(예: 버튼), 또는 디지털 펜(예: 스타일러스 펜)을 포함할 수 있다.

음향 출력 모듈(455)은 음향 신호를 사용자 장치(401)의 외부로 출력할 수 있다. 음향 출력 모듈(455)은, 예를 들면, 스피커 또는 리시버를 포함할 수 있다. 스피커는 멀티미디어 재생 또는 녹음 재생과 같이 일반적인 용도로 사용될 수 있다. 리시버는 착신 전화를 수신하기 위해 사용될 수 있다. 일실시예에 따르면, 리시버는 스피커와 별개로, 또는 그 일부로서 구현될 수 있다.

디스플레이 모듈(460)은 사용자 장치(401)의 외부(예: 사용자)로 정보를 시각적으로 제공할 수 있다. 디스플레이 모듈(460)은, 예를 들면, 디스플레이, 홀로그램 장치, 또는 프로젝터 및 해당 장치를 제어하기 위한 제어 회로를 포함할 수 있다. 일실시예에 따르면, 디스플레이 모듈(460)은 터치를 감지하도록 설정된 터치 센서, 또는 상기 터치에 의해 발생되는 힘의 세기를 측정하도록 설정된 압력 센서를 포함할 수 있다.

오디오 모듈(470)은 소리를 전기 신호로 변환시키거나, 반대로 전기 신호를 소리로 변환시킬 수 있다. 일실시예에 따르면, 오디오 모듈(470)은, 입력 모듈(450)을 통해 소리를 획득하거나, 음향 출력 모듈(455), 또는 사용자 장치(401)와 직접 또는 무선으로 연결된 외부 전자 장치(예: 전자 장치(402))(예: 스피커 또는 헤드폰)를 통해 소리를 출력할 수 있다.

센서 모듈(476)은 사용자 장치(401)의 작동 상태(예: 전력 또는 온도), 또는 외부의 환경 상태(예: 사용자 상태)를 감지하고, 감지된 상태에 대응하는 전기 신호 또는 데이터 값을 생성할 수 있다. 일실시예에 따르면, 센서 모듈(476)은, 예를 들면, 제스처 센서, 자이로 센서, 기압 센서, 마그네틱 센서, 가속도 센서, 그립 센서, 근접 센서, 컬러 센서, IR(infrared) 센서, 생체 센서, 온도 센서, 습도 센서, 또는 조도 센서를 포함할 수 있다.

인터페이스(477)는 사용자 장치(401)가 외부 전자 장치(예: 전자 장치(402))와 직접 또는 무선으로 연결되기 위해 사용될 수 있는 하나 이상의 지정된 프로토콜들을 지원할 수 있다. 일실시예에 따르면, 인터페이스(477)는, 예를 들면, HDMI(high definition multimedia interface), USB(universal serial bus) 인터페이스, SD카드 인터페이스, 또는 오디오 인터페이스를 포함할 수 있다.

연결 단자(478)는, 그를 통해서 사용자 장치(401)가 외부 전자 장치(예: 전자 장치(402))와 물리적으로 연결될 수 있는 커넥터를 포함할 수 있다. 일실시예에 따르면, 연결 단자(478)는, 예를 들면, HDMI 커넥터, USB 커넥터, SD 카드 커넥터, 또는 오디오 커넥터(예: 헤드폰 커넥터)를 포함할 수 있다.

햅틱 모듈(479)은 전기적 신호를 사용자가 촉각 또는 운동 감각을 통해서 인지할 수 있는 기계적인 자극(예: 진동 또는 움직임) 또는 전기적인 자극으로 변환할 수 있다. 일실시예에 따르면, 햅틱 모듈(479)은, 예를 들면, 모터, 압전 소자, 또는 전기 자극 장치를 포함할 수 있다.

카메라 모듈(480)은 정지 영상 및 동영상을 촬영할 수 있다. 일실시예에 따르면, 카메라 모듈(480)은 하나 이상의 렌즈들, 이미지 센서들, 이미지 시그널 프로세서들, 또는 플래시들을 포함할 수 있다.

전력 관리 모듈(488)은 사용자 장치(401)에 공급되는 전력을 관리할 수 있다. 일실시예에 따르면, 전력 관리 모듈(488)은, 예를 들면, PMIC(power management integrated circuit)의 적어도 일부로서 구현될 수 있다.

배터리(489)는 사용자 장치(401)의 적어도 하나의 구성요소에 전력을 공급할 수 있다. 일실시예에 따르면, 배터리(489)는, 예를 들면, 재충전 불가능한 1차 전지, 재충전 가능한 2차 전지 또는 연료 전지를 포함할 수 있다.

통신 모듈(490)은 사용자 장치(401)와 외부 전자 장치(예: 전자 장치(402), 전자 장치(404), 또는 서버(408)) 간의 직접(예: 유선) 통신 채널 또는 무선 통신 채널의 수립, 및 수립된 통신 채널을 통한 통신 수행을 지원할 수 있다. 통신 모듈(490)은 프로세서(예: 어플리케이션 프로세서)와 독립적으로 운영되고, 직접(예: 유선) 통신 또는 무선 통신을 지원하는 하나 이상의 커뮤니케이션 프로세서를 포함할 수 있다. 일실시예에 따르면, 통신 모듈(490)은 무선 통신 모듈(492)(예: 셀룰러 통신 모듈, 근거리 무선 통신 모듈, 또는 GNSS(global navigation satellite system) 통신 모듈) 또는 유선 통신 모듈(494)(예: LAN(local area network) 통신 모듈, 또는 전력선 통신 모듈)을 포함할 수 있다. 이들 통신 모듈 중 해당하는 통신 모듈은 제 1 네트워크(498)(예: 블루투스, WiFi(wireless fidelity) direct 또는 IrDA(infrared data association)와 같은 근거리 통신 네트워크) 또는 제 2 네트워크(499)(예: 레거시 셀룰러 네트워크, 5G 네트워크, 차세대 통신 네트워크, 인터넷, 또는 컴퓨터 네트워크(예: LAN 또는 WAN)와 같은 원거리 통신 네트워크)를 통하여 외부의 전자 장치(404)와 통신할 수 있다. 이런 여러 종류의 통신 모듈들은 하나의 구성요소(예: 단일 칩)로 통합되거나, 또는 서로 별도의 복수의 구성요소들(예: 복수 칩들)로 구현될 수 있다. 무선 통신 모듈(492)은 가입자 식별 모듈(496)에 저장된 가입자 정보(예: 국제 모바일 가입자 식별자(IMSI))를 이용하여 제 1 네트워크(498) 또는 제 2 네트워크(499)와 같은 통신 네트워크 내에서 사용자 장치(401)를 확인 또는 인증할 수 있다.

무선 통신 모듈(492)은 4G 네트워크 이후의 5G 네트워크 및 차세대 통신 기술, 예를 들어, NR 접속 기술(new radio access technology)을 지원할 수 있다. NR 접속 기술은 고용량 데이터의 고속 전송(eMBB(enhanced mobile broadband)), 단말 전력 최소화와 다수 단말의 접속(mMTC(massive machine type communications)), 또는 고신뢰도와 저지연(URLLC(ultra-reliable and low-latency communications))을 지원할 수 있다. 무선 통신 모듈(492)은, 예를 들어, 높은 데이터 전송률 달성을 위해, 고주파 대역(예: mmWave 대역)을 지원할 수 있다. 무선 통신 모듈(492)은 고주파 대역에서의 성능 확보를 위한 다양한 기술들, 예를 들어, 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO(multiple-input and multiple-output)), 전차원 다중입출력(FD-MIMO: full dimensional MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 또는 대규모 안테나(large scale antenna)와 같은 기술들을 지원할 수 있다. 무선 통신 모듈(492)은 사용자 장치(401), 외부 전자 장치(예: 전자 장치(404)) 또는 네트워크 시스템(예: 제 2 네트워크(499))에 규정되는 다양한 요구사항을 지원할 수 있다. 일실시예에 따르면, 무선 통신 모듈(492)은 eMBB 실현을 위한 Peak data rate(예: 20Gbps 이상), mMTC 실현을 위한 손실 Coverage(예: 164dB 이하), 또는 URLLC 실현을 위한 U-plane latency(예: 다운링크(DL) 및 업링크(UL) 각각 0.5ms 이하, 또는 라운드 트립 1ms 이하)를 지원할 수 있다.

안테나 모듈(497)은 신호 또는 전력을 외부(예: 외부의 전자 장치)로 송신하거나 외부로부터 수신할 수 있다. 일실시예에 따르면, 안테나 모듈(497)은 서브스트레이트(예: PCB) 위에 형성된 도전체 또는 도전성 패턴으로 이루어진 방사체를 포함하는 안테나를 포함할 수 있다. 일실시예에 따르면, 안테나 모듈(497)은 복수의 안테나들(예: 어레이 안테나)을 포함할 수 있다. 이런 경우, 제 1 네트워크(498) 또는 제 2 네트워크(499)와 같은 통신 네트워크에서 사용되는 통신 방식에 적합한 적어도 하나의 안테나가, 예를 들면, 통신 모듈(490)에 의하여 상기 복수의 안테나들로부터 선택될 수 있다. 신호 또는 전력은 상기 선택된 적어도 하나의 안테나를 통하여 통신 모듈(490)과 외부의 전자 장치 간에 송신되거나 수신될 수 있다. 어떤 실시예에 따르면, 방사체 이외에 다른 부품(예: RFIC(radio frequency integrated circuit))이 추가로 안테나 모듈(497)의 일부로 형성될 수 있다.

다양한 실시예에 따르면, 안테나 모듈(497)은 mmWave 안테나 모듈을 형성할 수 있다. 일실시예에 따르면, mmWave 안테나 모듈은 인쇄 회로 기판, 상기 인쇄 회로 기판의 제 1 면(예: 아래 면)에 또는 그에 인접하여 배치되고 지정된 고주파 대역(예: mmWave 대역)을 지원할 수 있는 RFIC, 및 상기 인쇄 회로 기판의 제 2 면(예: 윗 면 또는 측 면)에 또는 그에 인접하여 배치되고 상기 지정된 고주파 대역의 신호를 송신 또는 수신할 수 있는 복수의 안테나들(예: 어레이 안테나)을 포함할 수 있다.

상기 구성요소들 중 적어도 일부는 주변 기기들간 통신 방식(예: 버스, GPIO(general purpose input and output), SPI(serial peripheral interface), 또는 MIPI(mobile industry processor interface))을 통해 서로 연결되고 신호(예: 명령 또는 데이터)를 상호간에 교환할 수 있다.

일실시예에 따르면, 명령 또는 데이터는 제 2 네트워크(499)에 연결된 서버(408)를 통해서 사용자 장치(401)와 외부의 전자 장치(404)간에 송신 또는 수신될 수 있다. 외부의 전자 장치(402, 또는 404) 각각은 사용자 장치(401)와 동일한 또는 다른 종류의 장치일 수 있다. 일실시예에 따르면, 사용자 장치(401)에서 실행되는 동작들의 전부 또는 일부는 외부의 전자 장치들(402, 404, 또는 408) 중 하나 이상의 외부의 전자 장치들에서 실행될 수 있다. 예를 들면, 사용자 장치(401)가 어떤 기능이나 서비스를 자동으로, 또는 사용자 또는 다른 장치로부터의 요청에 반응하여 수행해야 할 경우에, 사용자 장치(401)는 기능 또는 서비스를 자체적으로 실행시키는 대신에 또는 추가적으로, 하나 이상의 외부의 전자 장치들에게 그 기능 또는 그 서비스의 적어도 일부를 수행하라고 요청할 수 있다. 상기 요청을 수신한 하나 이상의 외부의 전자 장치들은 요청된 기능 또는 서비스의 적어도 일부, 또는 상기 요청과 관련된 추가 기능 또는 서비스를 실행하고, 그 실행의 결과를 사용자 장치(401)로 전달할 수 있다. 사용자 장치(401)는 상기 결과를, 그대로 또는 추가적으로 처리하여, 상기 요청에 대한 응답의 적어도 일부로서 제공할 수 있다. 이를 위하여, 예를 들면, 클라우드 컴퓨팅, 분산 컴퓨팅, 모바일 에지 컴퓨팅(MEC: mobile edge computing), 또는 클라이언트-서버 컴퓨팅 기술이 이용될 수 있다. 사용자 장치(401)는, 예를 들어, 분산 컴퓨팅 또는 모바일 에지 컴퓨팅을 이용하여 초저지연 서비스를 제공할 수 있다. 다른 실시예에 있어서, 외부의 전자 장치(404)는 IoT(internet of things) 기기를 포함할 수 있다. 서버(408)는 기계 학습 및/또는 신경망을 이용한 지능형 서버일 수 있다. 일실시예에 따르면, 외부의 전자 장치(404) 또는 서버(408)는 제 2 네트워크(499) 내에 포함될 수 있다. 사용자 장치(401)는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스(예: 스마트 홈, 스마트 시티, 스마트 카, 또는 헬스 케어)에 적용될 수 있다.

도 5는 다양한 실시예에 따른 허브 장치(500)의 블록도이다.

도 5를 참조 하면, 허브 장치(500)(예: 도 1의 허브 장치(110), 도 2의 허브 장치(210) 또는 도 3의 허브 장치(310))는 프로세서(510), 통신 모듈(520) 및 메모리(530)를 포함할 수 있으며, 도시된 구성 중 일부가 생략 또는 치환되더라도 본 문서의 다양한 실시예들을 구현할 수 있다.

다양한 실시예에 따른 IoT 시스템(예: 도 1의 IoT 시스템(100), 도 2의 IoT 시스템(200) 또는 도 3의 IoT 시스템(300))에서 복수의 허브 장치(500)들이 존재할 수 있고, 각 허브 장치(500)는 서로 다른 종류의 장치일 수 있다. 예를 들어, 허브 장치(500)는 TV, 태블릿 PC, 또는 랩탑 PC와 같은 장치로 구현될 수 있다. 이하에서는, 허브 장치(500)가 기기 고유의 기능을 실행하기 위한 특징들의 설명은 생략하고, IoT 시스템에서 자동화 서비스의 허브 장치(500)로 동작하기 위해 필요한 동작들에 한해서 설명하기로 한다.

다양한 실시예에 따르면, IoT 시스템은 복수의 허브 장치(500)를 포함할 수 있다. 예를 들어, 특정 룰의 실행과 관련하여, 트리거 장치(예: 도 3의 트리거 장치(350)) 및 액터 장치(예: 도 3의 액터 장치(355))가 모두 하나의 허브 장치(500)에 연결될 수 있고, 다른 룰의 실행과 관련해서는 트리거 장치는 제1허브 장치에, 액터 장치는 제2허브 장치에 연결될 수 있다.

다양한 실시예에 따르면, 통신 모듈(520)은 무선 네트워크를 통해 외부 장치와 통신을 지원할 수 있다. 통신 모듈(520)은 로컬 네트워크 내의 장치(예: 트리거 장치, 액터 장치, 다른 허브 장치, 또는 AP(access point))와 NFC(near field communication), 블루투스, BLE(Bluetooth low energy), WiFi Direct, 메시 네트워크(mesh network)(예: Zigbee, Z-wave) 및/또는 UWB(ultra-wideband)와 같은 근거리 무선 통신으로 연결될 수 있고, 클라우드 서버, 사용자 장치와는 근거리 무선 통신 외에 4G 네트워크, 및/또는 5G 네트워크(예: SA(standalone), NSA(non-standalone))와 같은 셀룰러 통신으로 연결될 수도 있다.

다양한 실시예에 따르면, 프로세서(510)는 허브 장치(500)의 각 구성요소들의 제어 및/또는 통신에 관한 연산이나 데이터 처리를 수행할 수 있는 구성으로써, 통신 모듈(520), 또는 메모리(530)와 같은 허브 장치(500)의 각 구성요소와 작동적으로(operatively), 기능적으로(functionally) 및/또는 전기적으로(electrically) 연결될 수 있다.

다양한 실시예에 따르면, 프로세서(510)가 허브 장치(500) 내에서 구현할 수 있는 연산 및 데이터 처리 기능에는 한정됨이 없을 것이나, 이하에서는 허브 장치(500)가 클라우드 서버에서 룰 정보를 수신하여 로컬 룰 데이터베이스를 저장 및 업데이트 하는 동작, 트리거 이벤트에 따라 다른 장치에 트리거 이벤트에 관련된 정보를 전송하는 동작에 대해 상세히 설명하기로 한다.

다양한 실시예에 따르면, 메모리(530)는 휘발성 메모리 및/또는 비휘발성 메모리를 포함할 수 있으며, 허브 장치(500)의 적어도 하나의 구성요소(예: 프로세서(510))에서 사용되는 다양한 데이터를 일시적 및/또는 영구적으로 저장할 수 있다. 메모리(530)는 프로세서(510)에서 수행될 수 있는 다양한 인스트럭션(instruction)들을 저장할 수 있다. 이와 같은 인스트럭션들은 프로세서(510)에 의해 인식될 수 있는 산술 및 논리 연산, 데이터 이동, 입출력을 포함하는 다양한 제어 명령을 포함할 수 있다.

다양한 실시예에 따르면, 메모리(530)는 프로세서(510)의 제어에 따라 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다.

일 실시예에 따르면, 허브 장치(500)는 로컬 네트워크에 위치하는 장치에 관련되어 설정된 모든 룰을 로컬 룰 데이터베이스 상에 미리 설치할 수 있다. 예를 들어, 허브 장치(500)의 제조 단계에서 로컬 룰 데이터베이스에 모든 룰에 관한 정보가 저장될 수 있다. 또는, 허브 장치(500)는 허브 장치(500)를 클라우드 서버에 최초 등록(또는 온보딩(onboarding))하는 시점에 클라우드 서버로부터 로컬 네트워크에 위치하는 기기들에 대한 룰 정보를 다운로드 받아 로컬 룰 데이터베이스에 저장할 수 있다. 또는, 허브 장치(500)는 업그레이드 시(예: FOTA(firmware over the air)) 클라우드 서버로부터 룰 정보를 다운로드 받아 로컬 룰 데이터베이스를 설치 또는 업데이트 할 수 있다.

허브 장치(500)는 메모리(530)의 저장 용량이 충분하고, 미리 정의된 룰에 대한 정보와 기기의 분류가 되어 있을 경우 상기와 같이 모든 룰을 데이터베이스 상에 미리 설치할 수 있으며, 이 경우 모든 종류의 기기와 룰에 대해 자동화 서비스가 가능할 수 있다. 또한, 자동화 룰이 설치된 이후 클라우드의 도움 없이 각 기기에서 전송되는 패킷을 분석하여 자동화 서비스 실행이 가능할 수 있다.

다른 일 실시예에 따르면, 허브 장치(500)는 새로운 룰이 필요할 때 클라우드 서버에 요청하여 룰 정보를 수신 및 설치할 수 있다. 예를 들어, 허브 장치(500)의 메모리(530)의 저장 용량이 충분하지 않거나 룰에 필요한 정보가 계속 업데이트 될 경우, 모든 룰 정보를 미리 설치해 두기는 어려울 수 있다. 이에, 본 실시예와 같이, 로컬 네트워크 내의 다른 기기(예: 트리거 장치, 액터 장치, 다른 허브 장치(500), 사용자 장치)에서 자동화 룰에 대한 요청이 들어오는 경우, 해당 요청에 필요한 룰 정보를 클라우드 서버에 요청하여 다운로드 받아 설치하고, 해당 요청에 대응하는 룰을 수행할 수 있다. 일 실시예에 따르면, 허브 장치(500)는 로컬 네트워크 내에 다른 기기(예: 트리거 장치, 액터 장치, 다른 허브 장치, 사용자 장치)가 포함되는 경우, 다른 기기 또는 클라우드 서버로부터 다른 기기의 룰 정보를 수신 및 설치할 수 있다.

다른 일 실시예에 따르면, 허브 장치(500)는 사용자가 직접 설계한 룰을 로컬 룰 데이터베이스 상에 직접 설치할 수 있다. 예를 들어, 사용자에게 허브 장치(500)에서 사용 가능한 API를 제공하고, 사용자 인터페이스를 통해 룰을 직접 생성하도록 할 수 있다. 이 경우, 사용자가 생성한 룰 정보는 클라우드 서버에 저장되고 허브 장치(500)는 클라우드 서버에서 다운로드 받아 메모리(530)에 저장할 수 있고, 또는 로컬 네트워크에서 사용자 장치와 직접 통신을 통해 사용자 장치로부터 룰 정보를 수신하여 메모리(530)에 저장할 수도 있다.

다양한 실시예에 따르면, 프로세서(510)는 로컬 룰 데이터베이스를 설치한 이후에, 클라우드 서버 및/또는 사용자 장치로부터 새로운 룰 정보가 수신되는 경우, 로컬 룰 데이터베이스에 저장된 정보를 업데이트 할 수 있다.

다양한 실시예에 따르면, 프로세서(510)는 메모리(530)에 로컬 룰 데이터베이스가 저장된 상태에서, 통신 모듈(520)을 통해 트리거 장치(또는 제1외부 장치)로부터 트리거 이벤트를 수신할 수 있다. 트리거 장치는 트리거 장치의 ID 및 발생한 트리거 이벤트의 정보를 허브 장치(500)에 전송할 수 있다. 예를 들어, 트리거 장치는 트리거 이벤트가 발생되는 경우 지정된 허브 장치(500)로 트리거 장치의 ID 및 발생한 트리거 이벤트의 정보를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 프로세서(510)는 로컬 룰 데이터베이스에서 수신된 트리거 이벤트에 맵핑된 룰 정보를 확인하고, 확인된 룰 정보에 기초하여, 트리거 이벤트와 관련된 정보를 통신 모듈(520)을 통해 다른 장치(예: 다른 허브 장치, 또는 액터 장치, 클라우드 서버)로 전송할 수 있다.

일 실시예에 따르면, 허브 장치(500)에 트리거 장치 및 액터 장치가 모두 연결될 수 있으며, 로컬 룰 데이터베이스는 트리거 이벤트, 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함할 수 있다.

본 실시예에 따르면, 트리거 장치(예: 모션 센서)로부터 트리거 이벤트(예: 모션 감지) 수신되는 경우, 허브 장치(500)는 커맨드 데이터베이스에서 해당 트리거 이벤트와 맵핑된 동작 커맨드(예: 전구 턴 온) 및 동작 커맨드를 수행할 액터 장치(예: 전구)를 확인할 수 있다. 허브 장치(500)는 해당 액터 장치로 동작 커맨드를 전송하고, 액터 장치는 동작 커맨드에 대응되는 동작을 실행할 수 있다. 본 실시예에 대해서는 도 7을 통해 보다 상세히 설명하기로 한다.

다양한 실시예에 따르면, 룰 정보는 복수의 허브 장치(500)에 분할되어 설치될 수 있다. 예를 들어, 트리거 장치와 연결된 제1허브 장치에 트리거 룰이 설치되고, 액터 장치와 연결된 제2허브 장치에 액터 룰이 설치될 수 있다.

제1허브 장치가 클라우드 서버로부터 수신하여 메모리(530)의 로컬 룰 데이터베이스에 저장하는 룰 정보 및 그에 따라 트리거 이벤트 발생 시의 프로세서(510)의 동작은 다음과 같이 여러 실시예로 구분될 수 있다.

제1실시예에 따르면, 제1허브 장치는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트를 바이패스 할 목적지를 맵핑하여 저장하는 라우팅(routing) 데이터베이스를 저장할 수 있다. 예를 들어, 라우팅 데이터베이스는 특정 트리거 장치로부터 트리거 이벤트가 발생할 때, 해당 트리거 이벤트를 전달할 제2허브 장치의 식별정보(예: UUID, 또는 IP 주소)를 맵핑한 룰을 정의할 수 있다.

본 실시예에서 제2허브 장치는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트의 발생 시 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 저장할 수 있다.

본 실시예에 따르면, 트리거 장치(예: 모션 센서)로부터 트리거 이벤트(예: 모션 정보 감지)가 수신되는 경우, 프로세서(510)는 라우팅 데이터베이스에서 해당 트리거 이벤트에 맵핑된 제2허브 장치를 확인하고, 로컬 네트워크에서 확인된 제2허브 장치로 트리거 이벤트를 전송할 수 있다. 제2허브 장치는 커맨드 데이터베이스에서 트리거 이벤트와 맵핑되는 동작 커맨드 및 액터 장치를 확인하고, 확인된 동작 커맨드를 액터 장치에 전송할 수 있다. 액터 장치는 수신한 동작 커맨드에 따른 동작(예: 전구 턴 온)을 수행할 수 있다. 제1실시예에 대해서는 도 9를 통해 보다 상세히 설명하기로 한다.

제2실시예에 따르면, 제1허브 장치는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트의 발생 시 수행되는 룰이 정의된 룰 세트들을 맵핑하여 저장하는 목적지 데이터베이스를 저장할 수 있다. 여기서, 룰 세트는 고유의 ID를 가지며, 목적지 데이터베이스는 각각의 룰 세트를 처리할 수 있는 다른 허브 장치(500)의 식별정보를 맵핑하여 저장할 수 있다.

본 실시예에 따르면, 트리거 장치로부터 트리거 이벤트 수신되는 경우, 프로세서(510)는 목적지 데이터베이스에서 해당 트리거 이벤트에 맵핑된 룰 세트 및 해당 룰 세트를 처리할 수 있는 제2허브 장치를 확인하고, 확인된 제2허브 장치로 해당 룰 세트의 정보를 전송할 수 있다. 제2허브 장치는 커맨드 데이터베이스에서 해당 룰 세트를 확인하고, 룰 세트에서 동작 커맨드 및 액터 장치를 확인할 수 있다. 제2허브 장치는 동작 커맨드를 액터 장치로 전송하고, 액터 장치는 수신한 동작 커맨드에 따른 동작을 수행할 수 있다. 제2실시예에 대해서는 도 8을 통해 보다 상세히 설명하기로 한다.

제3실시예에 따르면, 제1허브 장치는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드를 맵핑한 커맨드 데이터베이스 및 동작 커맨드를 수행할 액터 장치의 정보를 맵핑하여 저장하는 목적지 데이터베이스를 저장할 수 있다.

본 실시예에서 제2허브 장치는 로컬 룰 데이터베이스를 포함하지 않을 수 있다.

본 실시예에 따르면, 트리거 장치로부터 트리거 이벤트 수신되는 경우, 제1허브 장치는 커맨드 데이터베이스에서 해당 트리거 이벤트와 맵핑된 동작 커맨드를 확인하고, 목적지 데이터베이스에서 동작 커맨드를 전송할 제2허브 장치를 확인할 수 있다. 제1허브 장치는 확인된 제2허브 장치에 동작 커맨드 및 액터 장치의 정보를 전송할 수 있다. 제2허브 장치는 해당 액터 장치로 동작 커맨드를 바이패스 할 수 있다. 제3실시예에 대해서는 도 10을 통해 보다 상세히 설명하기로 한다.

다양한 실시예에 따르면, 프로세서(510)는 로컬 룰 데이터베이스에서 트리거 이벤트와 관련된 정보를 전송할 외부 장치가 없거나, 외부 장치와 연결이 불가능한 경우, 트리거 이벤트와 관련된 정보를 클라우드 서버로 전송할 수 있다. 이 경우, 도 3에서 설명한 클라우드 기반의 자동화 서비스가 수행될 수 있다.

다양한 실시예에서 로컬 네트워크 내의 다른 장치의 연결 방식은 다양할 수 있다.

일 실시예에 따르면, 허브 장치(500)는 로컬 네트워크의 다른 장치와 direct로 연결될 수 있다. 예를 들어, 허브 장치(500)와 다른 허브 장치, 또는 허브 장치(500)와 트리거 장치(또는 액터 장치)가 근거리 무선 통신으로 직접 연결될 수 있다. 또한, 각 장치가 mesh 네트워크에 연결되어 있고 다른 장치가 mesh 네트워크에 있다는 것을 알고 있는 경우, mesh 네트워크를 통해 직접 통신될 수 있다. 본 실시예에서는 허브 장치(500)가 직접 룰 정보를 생성하여 저장하거나, 및/또는 연결된 다른 장치와 룰 정보를 주고 받을 수 있다.

일 실시예에 따르면, 로컬 네트워크 내의 장치들(예: 트리거 장치, 액터 장치)은 하나의 허브 장치(500)를 통해 연결될 수 있다. 예를 들어, 하나의 허브 장치(500)에 다양한 장치들이 무선 통신 또는 유선 통신으로 연결되거나, 허브 장치(500)가 장치들의 리스트를 가지고 있는 경우에 허브 장치(500)를 통해 각 장치들이 통신할 수 있다. 이 경우, 해당 허브 장치(500)에 자동화 룰이 설치될 수 있고, 허브 장치(500)는 트리거 장치에서 수신되는 패킷을 분석하여 룰을 트리거 시키고, 이에 대응하는 동작 커맨드를 액터 장치에 전송할 수 있다.

일 실시예에 따르면, 로컬 네트워크 내에서 제1허브 장치 및 제2허브 장치가 서로 연결되고, 트리거 장치는 제1허브 장치에, 액터 장치는 제2허브 장치에 연결될 수 있다. 이 경우, 룰 정보는 트리거 룰과 액터 룰을 나누어, 각각 제1허브 장치 및 제2허브 장치에 설치될 수 있다. 또는, 트리거 장치와 연결된 제1허브 장치에만 룰 정보가 설치되고 제2허브 장치는 제1허브 장치에서 수신되는 동작 커맨드를 액터 장치로 바이패스 시킬 수도 있다.

본 실시예에서 제1허브 장치와 제2허브 장치 간의 연결 방식은 다양할 수 있다. 예를 들어, 제1허브 장치 및 제2허브 장치가 같은 스위치에 연결되어 있는 경우 로컬 랜(local lan)을 통해 직접 연결될 수 있고, Wi-Fi direct 또는 mesh 네트워크를 통해 연결될 수 있고, Zigbee 또는 Z-wave와 같은 저전력 통신을 통해 서로 연결될 수도 있다.

일 실시예에 따르면, 트리거 장치와 연결된 제1허브 장치와 액터 장치와 연결된 제2허브 장치는 동일한 AP(access point)를 통해 연결될 수 있다. 이 경우, 제1허브 장치와 제2허브 장치가 동일한 AP에 연결되어 있으므로, 별도의 작업 없이 상호 통신이 가능할 수 있다. 또는, 제1허브 장치와 제2허브 장치는 별도의 프로세스를 통해 상호 IP 주소를 교환할 수 있다. 또는, 제1허브 장치 및/또는 제2허브 장치는 클라우드 서버에 연결 당시 클라우드 서버로 자신의 IP 주소를 업로드 하고, 클라우드 서버로부터 동일한 로컬 네트워크 내의 다른 장치의 IP 주소를 획득할 수 있다.

일 실시예에 따르면, 트리거 장치와 연결된 제1허브 장치와 액터 장치와 연결된 제2허브 장치는 로컬 네트워크를 통해 연결될 수 있다. 예를 들어, 제1허브 장치와 제2허브 장치는 서로 다른 AP에 연결되거나, 서로 다른 스위치에 연결되고 해당 스위치들이 라우터를 통해 연결되어 있거나, 각 허브 장치가 속한 네트워크의 IP 대역이 다를 수 있다. 본 실시예에서는 제1허브 장치 및 제2허브 장치의 통신을 위해 터널링(tunneling)이 필요하고, 경우에 따라 AP 또는 라우터의 접근 권한이 필요할 수 있다.

일 실시예에 따르면, 트리거 장치와 연결된 제1허브 장치와 액터 장치와 연결된 제2허브 장치는 원거리 통신 네트워크(WAN, wide area network)를 통해 연결될 수 있다. 예를 들어, 동일한 사용자가 사용하는 제1허브 장치와 제2허브 장치가 회사, 집과 같이 멀리 떨어져 있는 경우, WAN에서 상대의 네트워크 주소를 획득하여 연결할 수 있다.

다양한 실시예에 따르면, 로컬 네트워크 내의 각 장치의 기능에 따라 연결 방식이 선정될 수 있다.

일 실시예에 따르면, 2개의 허브 장치(500)는 서로 같은 IP 대역을 가지고 있는지 확인하고, 같은 IP 대역인 경우 direct로 연결할 수 있도록 서로 IP 주소를 교환할 수 있다. 2개의 허브 장치(500)가 다른 IP 대역인 경우, 터널링(tunneling)을 시도할 수 있다.

일 실시예에 따르면, 허브 장치(500)와 트리거 장치(또는 액터 장치)의 연결의 경우, 먼저 트리거 장치가 허브 장치(500)에 연결되어 있다면 direct 통신을 시도할 수 있다. 트리거 장치가 해당 허브 장치(500)에 연결되어 있지 않은 경우, 허브 장치(500)는 트리거 장치(또는 액터 장치)가 연결된 다른 허브 장치를 검색하고, 해당 허브 장치 간 통신을 활용하여 룰을 설치할 수 있다.

일 실시예에 따르면, 트리거 장치 및 액터 장치의 연결의 경우, 두 개의 장치가 같은 허브 장치(500)에 연결되어 있는지 확인하고, 같은 허브 장치(500)에 연결된 경우 해당 허브 장치(500)에 룰 정보를 설치할 수 있다. 트리거 장치와 액터 장치가 서로 다른 허브 장치(500)에 연결된 경우, 허브 장치(500) 간의 통신 기능의 점검 후 연결을 시도할 수 있다.

다양한 실시예에 따르면, 룰이 설치된 허브 장치(500)는 주기적으로 해당 룰에 정의된 다른 장치(예: 트리거 장치, 액터 장치, 다른 허브 장치)와 통신을 시도할 수 있다. 이와 같은 주기적인 통신 과정에서 정해진 횟수(예: 2회) 이상 응답이 없는 경우, 허브 장치(500)는 클라우드 서버에 이를 보고하고, 이전 연결을 취소하고, 다시 연결 절차를 개시할 수 있다.

도 6은 다양한 실시예에 따른 허브 장치가 자동화 룰을 설치하는 과정의 흐름도이다.

도시된 방법은 앞서 설명한 허브 장치(예: 도 5의 허브 장치(500))에 의해 수행될 수 있으며, 이하에서는 앞서 설명한 바 있는 기술적 특징 중 일부는 생략할 수도 있다.

다양한 실시예에 따르면, 동작 605에서, 허브 장치는 룰 세트(rule set)의 설치 요청을 수신할 수 있다. 룰 세트의 설치 요청은 사용자 장치(예: 도 3의 사용자 장치(330), 또는 도 4의 사용자 장치(401))의 어플리케이션에 의해 트리거 될 수 있으며, 룰 세트는 클라우드 서버(예: 도 3의 클라우드 서버(340))로부터 전송될 수 있다.

다양한 실시예에 따르면, 동작 610에서, 허브 장치는 룰의 설치가 가능한 지 확인할 수 있다. 다양한 실시예에 따르면, 동작 615에서, 허브 장치는 룰의 설치가 불가능한 경우, 예를 들어, 룰 세트의 설치를 위한 프로세서(예: 도 5의 프로세서(510)) 및/또는 메모리(예: 도 5의 메모리(530)) 리소스가 부족한 경우, 클라우드 서버로 룰 설치 불가능으로 리포트 할 수 있다.

다양한 실시예에 따르면, 동작 620에서, 허브 장치는 로컬 네트워크 상에서 연결 가능한 타겟 장치가 있는지 확인할 수 있다. 예를 들어, 허브 장치는 로컬 네트워크 상을 검색하여 연결 가능한 타겟 장치가 있는지 확인할 수 있다. 여기서, 타겟 장치는 클라우드 서버로부터 수신한 룰 세트에 포함된 트리거 장치(예: 모션 센서) 및/또는 액터 장치(예: 전구)를 포함할 수 있다. 허브 장치는 트리거 장치와만 연결될 수 있거나, 액터 장치와만 연결될 수 있거나, 또는 트리거 장치 및 액터 장치 모두에 연결될 수 있다. 허브 장치가 트리거 장치와 연결될 수 있는 경우, 도시된 동작 630 이하의 동작(예: 동작 630 내지 동작 654 및 동작 670)이 수행되고, 액터 장치와 연결될 수 있는 경우 도시된 동작 660 이하(예: 동작 660 내지 동작 666 및 동작 670)의 동작이 수행될 수 있으며, 트리거 장치 및 액터 장치 모두와 연결될 수 있는 경우에는 동작 630 이하의 동작 및 동작 660 이하의 동작(예: 동작 630 내지 동작 666 및 동작 670)이 모두 수행될 수 있다.

다양한 실시예에 따르면, 동작 630에서, 허브 장치는 트리거 장치와 현재 연결되어 있는지 확인할 수 있다.

다양한 실시예에 따르면, 허브 장치가 트리거 장치와 현재 연결되지 않은 경우, 동작 632에서, 허브 장치는 트리거 장치의 정보를 클라우드 서버에 요청하고, 동작 634에서 트리거 장치와의 다이렉트 링크를 클라우드 서버로부터 수신할 수 있다.

다양한 실시예에 따르면, 동작 640에서, 허브 장치는 트리거 장치와의 다이렉트 링크를 통한 연결이 가능한 지 확인할 수 있다. 다양한 실시예에 따르면, 연결이 불가능한 경우, 동작 642에서, 허브 장치는 클라우드 서버를 통해 트리거 장치와 연결을 요청할 수 있다. 다양한 실시예에 따르면, 연결이 가능한 경우, 동작 644에서, 허브 장치는 트리거 장치와 연결을 수행할 수 있다.

다양한 실시예에 따르면, 트리거 장치와 연결이 수립된 경우, 동작 650에서, 허브 장치는 연결된 트리거 장치에 대응하는 트리거 룰이 설치되어 있는지 확인할 수 있다. 다양한 실시예에 따르면, 트리거 룰이 설치되어 있지 않은 경우, 동작 652에서, 허브 장치는 클라우드 서버로부터 해당 트리거 장치에 대응하는 트리거 룰의 전송을 요청할 수 있다.

다양한 실시예에 따르면, 동작 654에서, 허브 장치는 클라우드 서버로부터 수신한 트리거 룰을 메모리의 로컬 룰 데이터베이스 상에 저장할 수 있다.

다양한 실시예에 따르면, 동작 660에서, 허브 장치는 연결된 액터 장치가 수행할 수 있는 커맨드가 있는지 확인할 수 있다. 예를 들어, 허브 장치는 허브 장치에 룰 수행에 필요한 액터 장치에 대한 커맨드가 저장되어 있는지 확인할 수 있다. 수행 가능한 커맨드가 있는 경우, 동작 662에서, 허브 장치는 허브 장치가 액터 룰을 설치할 수 있는지 확인할 수 있다. 허브 장치가 액터 룰을 설치할 수 있는 경우, 허브 장치에 저장된 액터 룰을 액터 장치에 전달하고, 액터 장치에서 해당 액터 룰을 수신하여 설치 할 수 있다. 이와 달리, 허브 장치에서 수행 가능한 커맨드가 저장되어 있지 않는 경우, 동작 664에서, 허브 장치는 클라우드 서버에 룰 정보를 요청하고, 동작 666에서, 클라우드 서버로부터 액터 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다.

다양한 실시예에 따르면, 동작 670에서, 허브 장치는 클라우드 서버로부터 수신되는 룰 정보에 기초하여, 로컬 룰 데이터베이스를 저장하고, 이 후 트리거 이벤트 발생 시 로컬 룰 데이터베이스에서 대응되는 동작을 확인하여, 그에 따른 동작을 수행할 수 있다.

도 7은 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.

도 7은 하나의 허브 장치(710)에 트리거 장치(750) 및 액터 장치(755)가 모두 연결되는 실시예를 도시한 것이다.

도 7을 참조 하면, 사용자 장치(730)(예: 도 3의 사용자 장치(330), 또는 도 4의 사용자 장치(401))에서 어플리케이션의 사용자 인터페이스를 통해 자동화 룰이 설정되는 경우, 클라우드 서버(740)에 설정된 룰이 등록될 수 있다. 예를 들어, 모션 센서(750)에서 모션 감지 시, 전구(755)를 턴 온 하라는 동작이 설정될 수 있다.

다양한 실시예에 따르면, 허브 장치(710)는 클라우드 서버(740)로부터 트리거 이벤트, 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치(755)를 맵핑한 룰 정보를 수신하고, 로컬 룰 데이터베이스(715)에 설치할 수 있다. 로컬 룰 데이터베이스(715)는 허브 장치(710)의 제조 시 또는 펌웨어 업그레이드 시에 설치될 수 있으며, 설치된 로컬 룰 데이터베이스(715)는 사용자 장치(730) 상에서 새로운 룰이 설정되는 경우에 클라우드 서버(740)로부터 전송되는 룰 정보에 따라 업데이트 될 수 있다. 일 실 시예에 따르면, 허브 장치(710)는 클라우드 서버(740)로부터 트리거 이벤트, 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치(755)를 맵핑한 룰 정보를 수신하는 경우 도 6의 동작들을 수행하여 로컬 룰 데이터베이스(715)에 설치할 수 있다.

다양한 실시예에 따르면, 트리거 장치(750)에서 인접하는 오브젝트의 모션이 감지되는 경우, 트리거 이벤트를 허브 장치(710)에 전송할 수 있다. 허브 장치(710)는 로컬 룰 데이터베이스(715)의 커맨드 데이터베이스에서 모션 감지 트리거 이벤트에 대응하는 동작 커맨드 및 액터 장치(755)를 확인할 수 있다.

다양한 실시예에 따르면, 허브 장치(710)는 확인된 액터 장치(755)에 동작 커맨드를 전송할 수 있다. 예를 들어, 액터 장치(755)가 전구인 경우, 액터 장치(755)는 허브 장치(710)로부터 수신된 동작 커맨드에 따라 전구의 턴 온 동작을 수행할 수 있다.

도 8은 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.

다양한 실시예에 따르면, 룰 정보는 복수의 허브 장치에 분할되어 설치될 수 있다. 예를 들어, 트리거 장치(850)와 연결된 제1허브 장치(810)에 트리거 룰이 설치되고, 액터 장치(855)와 연결된 제2허브 장치(820)에 액터 룰이 설치될 수 있다.

도 8을 참조 하면, 제1허브 장치(810)는 트리거 이벤트 및 트리거 이벤트의 발생 시 수행되는 룰이 정의된 룰 세트들을 맵핑하여 저장하는 트리거 룰 정보를 클라우드 서버(840)로부터 수신하여, 제1허브 장치(810)의 로컬 룰 데이터베이스(815)의 목적지 데이터베이스(817)에 저장할 수 있다. 여기서, 룰 세트는 고유의 ID를 가지며, 목적지 데이터베이스(817)는 각각의 룰 세트를 처리할 수 있는 다른 허브 장치 또는 액터 장치(855)의 식별정보를 맵핑하여 저장할 수 있다.

다양한 실시예에 따르면, 제2허브 장치(820)는 제2허브 장치(820)의 로컬 룰 데이터베이스(825)에 트리거 이벤트 및 트리거 이벤트의 발생 시 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치(855)를 맵핑하여 저장하는 커맨드 데이터베이스(827)를 저장할 수 있다.

다양한 실시예에 따르면, 트리거 장치(850)에서 인접하는 오브젝트의 모션이 감지되는 경우, 트리거 이벤트를 제1허브 장치(810)에 전송할 수 있다. 제1허브 장치(810)는 로컬 룰 데이터베이스(815)의 목적지 데이터베이스(817)에서 트리거 이벤트에 맵핑된 룰 세트를 확인할 수 있다. 목적지 데이터베이스(817)의 룰 세트는 해당 룰 세트를 처리할 수 있는 다른 허브 장치의 식별정보도 포함할 수 있다.

다양한 실시예에 따르면, 제1허브 장치(810)는 확인된 룰 세트의 제2허브 장치(820)로 룰 세트 정보를 전송할 수 있다. 제2허브 장치(820)는 커맨드 데이터베이스(827)에서 해당 룰 세트를 확인하고, 룰 세트에서 동작 커맨드 및 액터 장치(855)를 확인할 수 있다. 제2허브 장치(820)는 동작 커맨드를 액터 장치(855)로 전송하고, 액터 장치(855)는 수신한 동작 커맨드에 따른 동작을 수행할 수 있다.

도 9는 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.

다양한 실시예에 따르면, 제1허브 장치(910)는 트리거 이벤트 및 트리거 이벤트를 바이패스 할 목적지를 맵핑한 트리거 룰 정보를 클라우드 서버(940)로부터 수신하여, 제1허브 장치(910)의 로컬 룰 데이터베이스(915)의 라우팅 룰(routing rule) 데이터베이스(917)에 저장할 수 있다. 예를 들어, 라우팅 룰 데이터베이스(917)는 특정 트리거 장치(950)로부터 트리거 이벤트가 발생할 때, 해당 트리거 이벤트를 전달할 제2허브 장치(920)의 식별정보(예: UUID, IP 주소)를 맵핑한 룰을 정의할 수 있다. 일 실시예에 따르면, 제2허브 장치(920)는 트리거 이벤트 및 트리거 이벤트의 발생 시 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치(955)를 맵핑한 액터 룰 정보를 수신하여, 제2허브 장치(920)의 로컬 룰 데이터베이스(925)의 커맨드 데이터베이스(927)에 저장할 수 있다.

다양한 실시예에 따르면, 트리거 장치(950)에서 인접하는 오브젝트의 모션이 감지되는 경우, 트리거 이벤트를 제1허브 장치(910)에 전송할 수 있다. 제1허브 장치(910)는 라우팅 룰 데이터베이스(917)에서 트리거 장치(950)로부터 수신한 트리거 이벤트에 맵핑된 제2허브 장치(920)를 확인하고, 확인된 제2허브 장치(920)로 트리거 이벤트를 그대로 바이패스 할 수 있다. 예를 들어, 제1허브 장치(910)와 제2허브 장치(920)가 동일한 로컬 네트워크에 포함되는 경우 제1허브 장치(910)는 제2허브 장치(920)로 직접 트리거 이벤트를 바이패스 할 수 있다. 다른 예를 들어, 제1허브 장치(910)와 제2허브 장치(920)가 동일한 로컬 네트워크에 포함되지 않는 경우 제1허브 장치(910)는 서버(예: 클라우드 서버(940))를 통해 제2허브 장치(920)로 트리거 이벤트를 바이패스 할 수 있다.

제2허브 장치(920)는 제1허브 장치(910)로부터 트리거 이벤트가 수신되는 경우, 커맨드 데이터베이스(927)에서 수신된 트리거 이벤트와 맵핑되는 동작 커맨드 및 액터 장치(955)를 확인할 수 있다. 제2허브 장치(920)는 확인된 동작 커맨드를 액터 장치(955)에 전송할 수 있다. 액터 장치(955)는 수신한 동작 커맨드에 따른 동작(예: 전구 턴 온)을 수행할 수 있다.

도 10은 다양한 실시예에 따른 로컬 네트워크 기반의 이벤트 자동화 처리를 위한 각 장치의 동작을 도시한 것이다.

다양한 실시예에 따르면, 제1허브 장치(1010)는 트리거 이벤트 및 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드를 맵핑한 룰 정보를 클라우드 서버(1040)로부터 수신하여 제1허브 장치(1010)의 로컬 룰 데이터베이스(1015)의 커맨드 데이터베이스(1018)에 저장하고, 트리거 이벤트 및 동작 커맨드를 수행할 액터 장치(1055)의 정보를 맵핑한 룰 정보를 클라우드 서버(1040)로부터 수신하여 목적지 데이터베이스(1017)를 저장할 수 있다.

다양한 실시예에 따르면, 제2허브 장치(1020)는 로컬 룰 데이터베이스를 저장하지 않을 수 있다.

트리거 장치(1050)로부터 트리거 이벤트 수신되는 경우, 제1허브 장치(1010)는 커맨드 데이터베이스(1018)에서 해당 트리거 이벤트와 맵핑된 동작 커맨드를 확인하고, 목적지 데이터베이스(1017)에서 동작 커맨드를 전송할 제2허브 장치(1020)를 확인할 수 있다. 제1허브 장치(1010)는 확인된 제2허브 장치(1020)에 동작 커맨드 및 액터 장치(1055)의 정보를 전송할 수 있다. 제2허브 장치(1020)는 해당 액터 장치(1055)로 동작 커맨드를 바이패스 할 수 있다.

액터 장치(1055)는 수신한 동작 커맨드에 따른 동작(예: 전구 턴 온)을 수행할 수 있다.

도 11은 다양한 실시예에 따른 로컬 네트워크 기반 이벤트 자동화 처리 방법의 흐름도이다.

도 11은 특정 룰의 실행과 관련하여, 트리거 장치(1150)(예: 도 7의 트리거 장치(750)) 및 액터 장치(1155)(예: 도 7의 액터 장치(755))가 모두 하나의 허브 장치(1110)(예: 도 7의 허브 장치(710))에 연결된 실시예(예: 도 7)에 대한 것이다.

다양한 실시예에 따르면, 동작 1161 에서, 트리거 장치(1150)는 트리거 장치(1150)를 클라우드 서버(1140)에 등록하기 위해 허브 장치(1110)에 트리거 장치(1150)의 정보를 전송하고, 동작 1162에서, 허브 장치(1110)는 트리거 장치(1150)의 정보를 클라우드 서버(1140)에 전송하여, 트리거 장치(1150)를 등록(또는 onboarding) 할 수 있다.

다양한 실시예에 따르면, 동작 1163 에서, 액터 장치(1155)는 액터 장치(1155)를 클라우드 서버(1140)에 등록하기 위해 허브 장치(1110)에 액터 장치(1155)의 정보를 전송하고, 동작 1164에서, 허브 장치(1110)는 액터 장치(1155)의 정보를 클라우드 서버(1140)에 전송하여, 액터 장치(1155)를 등록(또는 onboarding) 할 수 있다.

다양한 실시예에 따르면, 동작 1166 에서, 클라우드 서버(1140)는 서버에 등록된 트리거 장치(1150) 및 액터 장치(1155)의 디바이스 ID를 허브 장치(1110)에 전송할 수 있다.

다양한 실시예에 따르면, 동작 1163 및 동작 1164는 동작 1161 및 동작 1162 보다 먼저 수행될 수 있고, 동작 1166은 동작 1162 이후에 수행되거나 또는 동작 1166 이후에 복수 번 수행될 수 있다.

다양한 실시예에 따르면, 동작 1170에서, 사용자 장치(1130)(예: 도 3의 사용자 장치(330), 또는 도 4의 사용자 장치(401))는 어플리케이션에서 제공하는 사용자 인터페이스를 통한 사용자 입력에 따라 자동화 룰을 설정할 수 있다. 예를 들어, 자동화 룰은 따라 트리거 장치(1150), 트리거 장치(1150)에서 감지하는 트리거 이벤트를 포함하는 트리거 룰 및 액터 장치(1155), 액터 장치(1155)에서 수행할 동작을 포함하는 액터 룰을 포함할 수 있다. 사용자 장치(1130)는 어플리케이션에서 제공하는 사용자 인터페이스를 통해 클라우드 서버(1140)에 등록된 트리거 장치(1150)와 엑터 장치(1155)의 정보를 확인할 수 있고, 사용자가 자동화 룰을 설정하도록 가이드 할 수 있다. 사용자 장치(1130)에 의해 설정된 룰은 클라우드 서버(1140) 상에 전송되어, 클라우드 데이터베이스에 저장될 수 있다.

다양한 실시예에 따르면, 동작 1172 에서, 허브 장치(1110)는 클라우드 서버(1140)로부터 트리거 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다.

다양한 실시예에 따르면, 동작 1174 에서, 클라우드 서버(1140)로부터 액터 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다.

다양한 실시예에 따르면, 허브 장치(1110)에서 로컬 룰 데이터베이스의 설치 이후, 동작 1180 에서, 트리거 장치(1150)는 트리거 이벤트를 감지할 수 있다. 예를 들어, 모션 센서는 주변 오브젝트의 모션을 감지할 수 있다.

다양한 실시예에 따르면, 동작 1182 에서, 트리거 장치(1150)는 감지된 트리거 이벤트를 허브 장치(1110)로 전송할 수 있다.

다양한 실시예에 따르면, 동작 1184 에서, 허브 장치(1110)는 로컬 룰 데이터베이스의 커맨드 데이터베이스에서 트리거 이벤트와 맵핑된 동작 커맨드 및 해당 동작 커맨드를 실행할 액터 장치(1155)를 확인할 수 있다. 예를 들어, 트리거 장치(1150)는 복수 개의 트리거 이벤트를 감지할 수 있으며, 허브 장치(1110)는 트리거 장치(1150)로부터 수신된 트리거 이벤트와 맵핑된 동작 커맨드 및 해당 동작 커맨드를 실행할 액터 장치(1155)를 로컬 룰 데이터베이스로부터 확인할 수 있다.

다양한 실시예에 따르면, 동작 1186 에서, 허브 장치(1110)는 액터 장치(1155)로 동작 커맨드를 전송하고, 액터 장치(1155)는 요청된 동작을 수행할 수 있다.

도 11의 실시예의 경우, 설치하고자 하는 룰에 관련된 트리거 장치(1150) 및 액터 장치(1155)가 하나의 허브 장치(1110)와 연결되어 있기 때문에, 허브 장치(1110)는 해당 룰을 스스로 설치하고 운영할 수 있다. 하나의 허브 장치(1110)에서 연결된 장치들을 제어하는 것이기 때문에, 해당 장치들이 허브 장치(1110)에서 제거되지 않는 한 클라우드 서버(1140)로부터 별도의 도움 없이 자동화 서비스를 수행할 수 있다.

도 12는 다양한 실시예에 따른 로컬 네트워크 기반 이벤트 자동화 처리 방법의 흐름도이다.

도 12는 특정 룰의 실행과 관련하여, 트리거 장치(1250)가 제1허브 장치(1210)와 연결되고, 액터 장치(1255)가 제2허브 장치(1220)와 연결되어 있으며(예: 도 8 내지 도 10), 제1허브 장치(1210) 및 제2허브 장치(1220)가 direct 연결될 수 있는 실시예에 대한 것이다.

다양한 실시예에 따르면, 동작 1261 에서, 트리거 장치(1250)는 트리거 장치(1250)를 클라우드 서버(1240)에 등록하기 위해 제1허브 장치(1210)에 트리거 장치(1250)의 정보를 전송하고, 동작 1262에서, 제1허브 장치(1210)는 트리거 장치(1250)의 정보를 클라우드 서버(1240)에 전송하여, 트리거 장치(1250)를 등록(또는 onboarding) 할 수 있다.

다양한 실시예에 따르면, 동작 1263 에서, 액터 장치(1255)는 액터 장치(1255)를 클라우드 서버(1240)에 등록하기 위해 제2허브 장치(1220)에 액터 장치(1255)의 정보를 전송하고, 동작 1264에서, 제2허브 장치(1220)는 액터 장치(1255)의 정보를 클라우드 서버(1240)에 전송하여, 액터 장치(1255)를 등록(또는 onboarding) 할 수 있다.

다양한 실시예에 따르면, 동작 1266 에서, 클라우드 서버(1240)는 서버에 등록된 트리거 장치(1250), 액터 장치(1255) 및 제2허브 장치(1220)의 디바이스 ID를 제1허브 장치(1210)에 전송할 수 있다. 동작 1268 에서, 클라우드 서버(1240)는 서버에 등록된 트리거 장치(1250), 액터 장치(1255) 및 제1허브 장치(1210)의 디바이스 ID를 제2허브 장치(1220)에 전송할 수 있다.

다양한 실시예에 따르면, 클라우드 서버(1240)가 제1허브 장치(1210) 및/또는 제2허브 장치(1220)로 서버에 등록된 트리거 장치(1250), 액터 장치(1255) 및 적어도 하나의 허브 장치(예: 제1허브 장치(1210) 및/또는 제2허브 장치(1220))의 디바이스 ID를 전송하는 동작의 순서는 제1허브 장치(1210) 및/또는 제2허브 장치(1220)가 클라우드 서버(1240)에 트리거 장치(1250) 또는 액터 장치(1255)를 등록하는 순서에 따라 변경되거나 복수 번 수행될 수도 있다.

다양한 실시예에 따르면, 동작 1270에서, 사용자 장치(1230)(예: 도 3의 사용자 장치(330), 또는 도 4의 사용자 장치(401))는 어플리케이션에서 제공하는 사용자 인터페이스를 통한 사용자 입력에 따라 자동화 룰을 설정하여 클라우드 서버(1240)로 전송할 수 있다. 예를 들어, 자동화 룰은 따라 트리거 장치(1250), 트리거 장치(1250)에서 감지하는 트리거 이벤트를 포함하는 트리거 룰 및 액터 장치(1255), 액터 장치(1255)에서 수행할 동작을 포함하는 액터 룰을 포함할 수 있다. 사용자 장치(1230)에 의해 설정된 룰은 클라우드 서버(1240) 상에 전송되어, 클라우드 데이터베이스에 저장될 수 있다.

다양한 실시예에 따르면, 동작 1272 에서, 제1허브 장치(1210)는 클라우드 서버(1240)로부터 트리거 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다. 일 실시예(예: 도 9)에 따르면, 제1허브 장치(1210)는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트를 바이패스 할 목적지를 맵핑하여 저장하는 라우팅(routing) 데이터베이스를 저장할 수 있다. 다른 일 실시예(예: 도 8)에 따르면, 제1허브 장치(1210)는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트의 발생 시 수행되는 룰이 정의된 룰 세트들을 맵핑하여 저장하는 목적지 데이터베이스를 저장할 수 있다. 다른 일 실시예(예: 도 10)에 따르면, 제1허브 장치(1210)는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드를 맵핑한 커맨드 데이터베이스 및 동작 커맨드를 수행할 액터 장치(1255)의 정보를 맵핑하여 저장하는 목적지 데이터베이스를 저장할 수 있다.

다양한 실시예에 따르면, 동작 1274 에서, 제2허브 장치(1220)는 클라우드 서버(1240)로부터 액터 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다. 일 실시예(예: 도 9)에 따르면, 제2허브 장치(1220)는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트의 발생 시 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치(1255)를 맵핑하여 저장하는 커맨드 데이터베이스를 저장할 수 있다. 다른 일 실시예(예: 도 8)제2허브 장치(1220)는 로컬 룰 데이터베이스에 트리거 이벤트 및 트리거 이벤트의 발생 시 실행될 동작을 지시하는 동작 커맨드 및 동작 커맨드를 수행할 액터 장치(1255)를 맵핑하여 저장하는 커맨드 데이터베이스를 저장할 수 있다.

다양한 실시예에 따르면, 동작 1280 에서, 제1허브 장치(1210)는 제2허브 장치(1220)와의 연결을 시도하기 위해, 수신한 제2허브 장치(1220)의 ID를 이용하여 Ping(packet internet groper)을 모든 네트워크 인터페이스에 전송할 수 있다. 또는, 동작 1282에서, 제1허브 장치(1210)는 제2허브 장치(1220)와 기 연결된 네트워크(예: Wi-Fi, mesh network)를 통해 ping을 전송할 수 있다. 동작 1284에서, 제2허브 장치(1220)는 ping 전송에 대한 응답을 제1허브 장치(1210)에 전송할 수 있다. 동작 1286에서, 제1허브 장치(1210)는 제2허브 장치(1220)와의 연결을 등록(enroll) 할 수 있다. 일 실시 예에 따르면, 제1허브 장치(1210)와 제2허브 장치(1220)가 연결을 등록하는 동작은 제1허브 장치(1210) 및/또는 제2허브 장치(1220)가 클라우드 서버(1240)로부터 상대 허브 장치의 정보를 수신하는 동작(예: 동작 1266 또는 동작 1268) 이후에 수행될 수도 있다.

다양한 실시예에 따르면, 동작 1290에서, 트리거 장치(1250)는 트리거 이벤트를 감지할 수 있다. 예를 들어, 모션 센서는 주변 오브젝트의 모션을 감지할 수 있다.

다양한 실시예에 따르면, 동작 1292 에서, 트리거 장치(1250)는 감지된 트리거 이벤트를 제1허브 장치(1210)로 전송할 수 있다.

다양한 실시예에 따르면, 동작 1294에서, 제1허브 장치(1210)는 제1허브 장치(1210)의 로컬 룰 데이터베이스에서, 트리거 이벤트에 맵핑된 룰을 확인할 수 있다. 다양한 실시예에 따르면, 동작 1296에서, 제1허브 장치(1210)는 트리거 이벤트에 관련된 정보를 제2허브 장치(1220)에 전송할 수 있다.

일 실시예(예: 도 9)에 따르면, 제1허브 장치(1210)는 라우팅 데이터베이스에서 해당 트리거 이벤트에 맵핑된 제2허브 장치(1220)를 확인할 수 있다. 다른 일 실시예(예 도 8)에 따르면, 제1허브 장치(1210)는 목적지 데이터베이스에서 해당 트리거 이벤트에 맵핑된 룰 세트 및 해당 룰 세트를 처리할 수 있는 제2허브 장치(1220)를 확인하고, 확인된 제2허브 장치(1220)로 해당 룰 세트의 정보를 전송할 수 있다. 다른 일 실시예(예: 도 10)에 따르면, 제1허브 장치(1210)는 커맨드 데이터베이스에서 해당 트리거 이벤트와 맵핑된 동작 커맨드를 확인하고, 목적지 데이터베이스에서 동작 커맨드를 전송할 제2허브 장치(1220)를 확인할 수 있다. 제1허브 장치(1210)는 확인된 제2허브 장치(1220)에 동작 커맨드 및 액터 장치(1255)의 정보를 전송할 수 있다.

다양한 실시예에 따르면, 동작 1298에서, 제2허브 장치(1220)는 제2허브 장치(1220)의 로컬 룰 데이터베이스에서 제1허브 장치(1210)로부터 전송된 트리거 이벤트와 관련된 정보에 맵핑된 룰을 확인할 수 있다. 동작 1299에서, 제2허브 장치(1220)는 액터 장치(1255)로 동작 커맨드를 전송하고, 액터 장치(1255)는 요청된 동작을 수행할 수 있다.

일 실시예(예: 도 9)에 따르면, 제2허브 장치(1220)는 커맨드 데이터베이스에서 트리거 이벤트와 맵핑되는 동작 커맨드 및 액터 장치(1255)를 확인하고, 확인된 동작 커맨드를 액터 장치(1255)에 전송할 수 있다. 다른 일 실시예(예: 도 8)에 따르면, 제2허브 장치(1220)는 커맨드 데이터베이스에서 해당 룰 세트를 확인하고, 룰 세트에서 동작 커맨드 및 액터 장치(1255)를 확인할 수 있다. 다른 일 실시예(예: 도 10)에 따르면, 제2허브 장치(1220)는 제1허브 장치(1210)로부터 수신되는 동작 커맨드를 해당 액터 장치(1255)로 바이패스 할 수 있다.

도 12의 실시예와 같이, 룰에 참가하는 트리거 장치(1250) 및 액터 장치(1255)가 서로 다른 허브 장치에 연결되어 있는 경우, 클라우드 서버(1240)는 각 장치와 연결된 제1허브 장치(1210) 및 제2허브 장치(1220)에 룰의 설치를 요청할 수 있다. 제1허브 장치(1210)는 액터 룰을 가진 제2허브 장치(1220)를 찾기 위해 다양한 통신 수단을 사용해 제2허브 장치(1220)를 탐색할 수 있다. 탐색 과정에서 제2허브 장치(1220)가 발견되는 경우, 제1허브 장치(1210)는 해당 경로를 등록하고, 이후 트리거 이벤트 발생 시 관련 정보를 제2허브 장치(1220)에 전송할 수 있다. 해당 정보를 제2허브 장치(1220)가 수신하면, 제2허브 장치(1220)는 등록된 룰에 따라 동작 커멘드를 실행할 수 있다.

도 13은 다양한 실시예에 따른 로컬 네트워크 기반 이벤트 자동화 처리 방법의 흐름도이다.

도 13은 특정 룰의 실행과 관련하여, 트리거 장치(1350)가 제1허브 장치(1310)와 연결되고, 액터 장치(1355)가 제2허브 장치(1320)와 연결되어 있으며(예: 도 8 내지 도 10), 제1허브 장치(1310) 및 제2허브 장치(1320)가 AP(1345)(access point)를 통해 연결되는 실시예에 대한 것이다.

다양한 실시예에 따르면, 동작 1361 에서, 트리거 장치(1350)는 트리거 장치(1350)를 클라우드 서버(1340)에 등록하기 위해 제1허브 장치(1310)에 트리거 장치(1350)의 정보를 전송하고, 동작 1362에서, 제1허브 장치(1310)는 트리거 장치(1350)의 정보를 AP(1345)에 전송할 수 있다. 동작 1363에서, AP(1345)는 트리거 장치(1350)의 정보를 클라우드 서버(1340)에 전송하여, 트리거 장치(1350)를 등록(또는 onboarding) 할 수 있다.

다양한 실시예에 따르면, 동작 1364 에서, 액터 장치(1355)는 액터 장치(1355)를 클라우드 서버(1340)에 등록하기 위해 제2허브 장치(1320)에 액터 장치(1355)의 정보를 전송하고, 동작 1365에서, 제2허브 장치(1320)는 액터 장치(1355)의 정보를 AP(1345)에 전송할 수 있다. 동작 1366에서, AP(1345)는 액터 장치(1355)의 정보를 클라우드 서버(1340)에 전송하여 액터 장치(1355)를 등록(또는 onboarding) 할 수 있다.

다양한 실시예에 따르면, 동작 1367 에서, 클라우드 서버(1340)는 서버에 등록된 트리거 장치(1350), 액터 장치(1355) 및 제2허브 장치(1320)의 디바이스 ID를 AP(1345)를 통해 제1허브 장치(1310)에 전송할 수 있다. 동작 1368 에서, 클라우드 서버(1340)는 서버에 등록된 트리거 장치(1350), 액터 장치(1355) 및 제1허브 장치(1310)의 디바이스 ID를 AP(1345)를 통해 제2허브 장치(1320)에 전송할 수 있다.

다양한 실시예에 따르면, 동작 1370에서, 사용자 장치(1330)(예: 도 3의 사용자 장치(330), 또는 도 4의 사용자 장치(401))는 어플리케이션에서 제공하는 사용자 인터페이스를 통한 사용자 입력에 따라 자동화 룰을 설정할 수 있다.

다양한 실시예에 따르면, 동작 1372 에서, 제1허브 장치(1310)는 클라우드 서버(1340)로부터 트리거 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다. 제1허브 장치(1310)의 로컬 룰 데이터베이스에 저장되는 룰 정보의 예는 앞서 도 8 내지 10 및 도 12를 통해 상세히 설명한 바 있다.

다양한 실시예에 따르면, 동작 1374 에서, 제2허브 장치(1320)는 클라우드 서버(1340)로부터 액터 룰 정보를 수신하여, 로컬 룰 데이터베이스에 저장할 수 있다. 제2허브 장치(1320)의 로컬 룰 데이터베이스에 저장되는 룰 정보의 예는 앞서 도 8 내지 10 및 도 12를 통해 상세히 설명한 바 있다.

다양한 실시예에 따르면, 동작 1376 에서, 제1허브 장치(1310)는 제2허브 장치(1320)와의 연결을 시도하기 위해, 수신한 제2허브 장치(1320)의 ID를 이용하여 Ping(packet internet groper)을 모든 네트워크 인터페이스에 전송할 수 있다. 다양한 실시예에 따르면, 동작 1378에서, 제1허브 장치(1310)는 제2허브 장치(1320)로부터 ping 요청에 대한 응답이 전송되지 않는 것을 확인할 수 있다.

다양한 실시예에 따르면, 동작 1380에서, 제1허브 장치(1310)는 클라우드 서버(1340)에 제2허브 장치(1320)와의 연결을 요청할 수 있다. 동작 1382에서, 클라우드 서버(1340)는 사용자 장치(1330)에 제1전자 장치와 AP(1345)의 연결 허가를 요청(AP( permission request)할 수 있다. 예를 들어, AP(1345)를 통해 로컬 네트워크의 각 장치와 클라우드 서버(1330)가 통신 시에 AP(1345)에 터널링을 위한 룰 설치가 필요하며, 이 과정에서 AP(1345)에 관리자 계정으로 접속이 필요할 수 있다. 이에, 클라우드 서버(1340)는 사용자 장치(1330)를 통해 사용자에게 AP(1345)에 대한 접근 권한의 허가를 요청할 수 있다. 동작 1384에서, 사용자 장치(1330)는 사용자 입력에 기초하여 클라우드 서버(1340)에 연결 허가 응답을 전송할 수 있다.

다양한 실시예에 따르면, 동작 1386에서, 클라우드 서버(1340)는 AP(1345)로 허브 장치 간 연결 수립을 요청할 수 있다.

다양한 실시예에 따르면, 동작 1388에서, 클라우드 서버(1340)는 제1허브 장치(1310)에 install connection을 전송하고, 동작 1389에서, 제2허브 장치(1320)에 install connection을 전송할 수 있다. 여기서, install connection은 AP(1345)를 통해 연결되는 통신 경로를 수립하기 위한 과정으로, 제1허브 장치(1310) 및 제2허브 장치(1320)는 install connection을 수신하여 AP 터널링을 위한 정보를 설치할 수 있다. 예를 들어, AP(1345)는 제1허브 장치(1310)에서 오는 특정 포트 데이터는 제2허브 장치(1320)로 전달한다는 라우팅 룰을 설치하고, 제1허브 장치(1310)는 트리거 이벤트 발생 시 제2허브 장치(1320)의 주소로 AP(1345)에 설치한 포트로 해당 정보를 전달하는 라우팅 룰을 설치할 수 있다.

다양한 실시예에 따르면, 동작 1390에서, 트리거 장치(1350)는 트리거 이벤트를 감지할 수 있다. 예를 들어, 모션 센서는 주변 오브젝트의 모션을 감지할 수 있다.

다양한 실시예에 따르면, 동작 1392 에서, 트리거 장치(1350)는 감지된 트리거 이벤트를 제1허브 장치(1310)로 전송할 수 있다.

다양한 실시예에 따르면, 동작 1394에서, 제1허브 장치(1310)는 제1허브 장치(1310)의 로컬 룰 데이터베이스에서, 트리거 이벤트에 맵핑된 룰을 확인하고, 동작 1395에서, 트리거 이벤트에 관련된 정보를 AP(1345)에 전송할 수 있다. 동작 1396에서, AP(1345)는 제2허브 장치(1320)에 제1허브 장치(1310)에서 전송된 트리거 이벤트에 관련된 정보를 전송할 수 있다. 제1허브 장치(1310)가 AP(1345)를 통해 제2허브 장치(1320)에 전송하는 트리거 이벤트에 관련된 정보의 자세한 내용은 앞서 도 8 내지 도 10 및 도 12를 통해 상세히 설명한 바 있다.

다양한 실시예에 따르면, 동작 1398에서, 제2허브 장치(1320)는 제2허브 장치(1320)의 로컬 룰 데이터베이스에서 제1허브 장치(1310)로부터 전송된 트리거 이벤트와 관련된 정보에 맵핑된 룰을 확인할 수 있다. 동작 1399에서, 제2허브 장치(1320)는 액터 장치(1355)로 동작 커맨드를 전송하고, 액터 장치(1355)는 요청된 동작을 수행할 수 있다.

도 14a, 14b 및 14c는 다양한 실시예에 따른 IoT 기기의 제어를 위해 사용자 장치에서 제공되는 사용자 인터페이스를 도시한 것이다.

다양한 실시예에 따르면, 사용자 장치는 자동화 서비스를 위한 기기 등록, 룰 설정 및 기기 제어를 제공하는 어플리케이션을 실행하여 표시할 수 있다.

도 14a는 클라우드 기반의 자동화 서비스(예: 도 3)를 지원하는 어플리케이션을 도시한 것이다.

도 14a를 참조 하면, 사용자 장치(1400)(예: 도 3의 사용자 장치(330), 또는 도 4의 사용자 장치(401))는 로컬 네트워크의 각 장치(예: 트리거 장치, 액터 장치, 및/또는 허브 장치)에 대응되는 UI 아이템을 표시할 수 있다. 예를 들어, 사용자 장치는 AV 사운드 바의 UI 아이템(1461), TV의 UI 아이템(1462), 우측 전구의 UI 아이템(1463), 셋톱 박스 리모콘의 UI 아이템(1464), 좌측 전구의 UI 아이템(1465) 및 전동 블라인드 컨트롤러의 UI 아이템(1466)을 표시할 수 있다.

각각의 UI 아이템은 장치를 지시하는 이미지(1461a), 장치의 명칭(1461b), 장치의 동작 상태(예: on/off, available/non-available, open/close)를 지시하는 정보(1461c), 장치의 동작 상태를 변경하는 버튼(1461d)을 포함할 수 있다.

도 14b는 로컬 네트워크 기반의 자동화 서비스(예: 도 7 내지 도 10)를 지원하는 어플리케이션을 도시한 것이다.

도 14b를 참조 하면, 각 장치에 대응되는 UI 아이템(1471)은 장치를 지시하는 이미지(1471a), 장치의 명칭(1471b), 장치의 동작 상태를 지시하는 정보(1471c), 장치의 동작 상태를 변경하는 버튼(1471d) 및 설정된 자동화 서비스의 정보(1471e)를 포함할 수 있다.

예를 들어, AV 사운드 바는 전구(제1전구 또는 제2전구) 자동 끄기 동작에 대한 허브 장치로 동작하도록 설정될 수 있으며, AV 사운드 바의 UI 아이템(1471)에는 AV 사운드 바가 허브 장치로 설정되었음을 지시하는 정보(1471e)가 표시될 수 있다. 또한, 우측 전구의 UI 아이템(1473)에는 전구가 액터 장치로 설정되었음을 지시하는 정보(1473e)가 표시될 수 있다.

도 14c는 로컬 네트워크 기반의 자동화 서비스에서 일부 장치가 복수의 주체로 동작하는 경우 사용자 장치의 어플리케이션을 도시한 것이다.

도 14c를 참조 하면, UI 아이템의 자동화 서비스 정보는 자동화 서비스의 어떠한 주체(예: 허브 장치, 트리거 장치, 및/또는 액터 장치)로 설정 되었는지를 지시하는 정보가 표시될 수 있다. 예를 들어, AV 사운드 바의 UI 아이템(1481)에는 자동화 서비스에서 허브 장치로 설정된 룰이 2개일 수 있다는 정보(1481e)를 표시할 수 있고, 우측 전구의 UI 아이템(1483)에는 2가지 트리거 이벤트에 대해 액터 장치로 동작할 수 있고, 또한 전구에서 감지하는 상황에 대해 트리거 장치로 동작할 수 있다는 정보(1483e)가 표시될 수 있다.

도 15a 및 15b는 다양한 실시예에 따른 IoT 기기의 제어를 위해 사용자 장치에서 제공되는 사용자 인터페이스를 도시한 것이다.

다양한 실시예에 따르면, 사용자 장치(1500)(예: 도 3의 사용자 장치(330), 또는 도 4의 사용자 장치(401))는 사용자에 의해 설정된 자동화 룰을 룰 어플리케이션 상에서 룰 단위로 표시하고, 룰의 활성화/비활성화 및 룰 변경 기능을 제공할 수 있다.

도 15a은 클라우드 기반의 자동화 서비스(예: 도 3)를 지원하는 어플리케이션을 도시한 것이다.

도 15a에서 제1UI 아이템(1510)은 모션 센서의 모션 감지 시, 전구 턴 오프 동작의 룰을 나타낼 수 있다. 제2UI 아이템(1520)은 모션 센서의 모션 감지 시, 전구 턴 온 동작의 룰을 나타낼 수 있다.

도 15b는 로컬 네트워크 기반의 자동화 서비스(예: 도 7 내지 도 10)를 지원하는 어플리케이션을 도시한 것이다.

도 15b에서 제1UI 아이템(1530)은 모션 센서의 모션 감지가 허브 장치에 전달되고, 허브 장치에서 전송되는 동작 커맨드에 따라 전구 턴 오프 동작이 수행되는 것을 지시할 수 있다.

제2UI 아이템(1540)은 모션 센서의 트리거 이벤트, 모션 센서와 연결된 제1허브 장치, 제1허브 장치 및 제2허브 장치의 로컬 네트워크 연결, 전구와 연결된 제2허브 장치, 전구 턴 온 동작을 포함하는 룰을 나타낼 수 있다.

제3UI 아이템(1550)은 모션 센서의 트리거 이벤트, 클라우드를 통한 모션 센서와 전구의 연결, 전구 턴 오프 동작을 포함하는 룰을 나타낼 수 있다.

다양한 실시예에 따른 전자 장치(500)는, 통신 모듈(520), 메모리(530), 및 상기 통신 모듈(520) 및 상기 메모리(530)와 작동적으로(operatively) 연결되는 프로세서(510)를 포함하고, 상기 프로세서(510)는, 제1외부 장치에서 감지되는 트리거 이벤트 및 상기 트리거 이벤트에 대응하는 룰 세트, 목적지, 또는 동작 커맨드 중 적어도 하나를 맵핑한 룰 정보를 상기 통신 모듈(520)을 통해 클라우드 서버로부터 수신하여 상기 메모리(530)의 로컬 룰 데이터베이스에 저장하고, 상기 통신 모듈(520)을 통해 제1외부 장치로부터 트리거 이벤트를 수신하고, 상기 로컬 룰 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 정보를 확인하고, 및 상기 확인된 룰 정보에 기초하여, 상기 트리거 이벤트와 관련된 정보를 상기 통신 모듈(520)을 통해 제2외부 장치로 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 제2외부 장치는 상기 전자 장치(500)와 동일한 로컬 네트워크 상에 위치하는 허브 장치일 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트 및 상기 트리거 이벤트를 바이패스(bypass)할 목적지를 맵핑하여 저장하는 라우팅(routing) 데이터베이스를 포함하고, 상기 프로세서(510)는, 상기 라우팅 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 상기 허브 장치를 확인하고, 상기 허브 장치에 상기 트리거 이벤트를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트 및 상기 트리거 이벤트의 발생 시 수행되는 룰이 정의된 룰 세트들을 맵핑하여 저장하는 목적지 데이터베이스를 포함하고, 상기 프로세서(510)는, 상기 목적지 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 세트를 확인하고, 상기 확인된 룰 세트를 실행할 수 있는 상기 허브 장치를 확인하고, 및 상기 허브 장치에 상기 확인된 룰 세트 정보를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 제3외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고, 상기 프로세서(510)는, 상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제3외부 장치를 확인하고, 상기 제3외부 장치와 연결된 상기 허브 장치에 상기 확인된 동작 커맨드를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 상기 제2외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고, 상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제2외부 장치를 확인하고, 상기 제2외부 장치에 상기 확인된 동작 커맨드를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 프로세서(510)는, 상기 통신 모듈(520)을 통해 상기 제2외부 장치와 연결될 수 없는 경우, 상기 클라우드 서버에 상기 트리거 이벤트와 관련된 정보를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 프로세서(510)는, 상기 통신 모듈(520)의 근거리 무선 통신 기능을 이용하여 상기 제2외부 장치에 상기 트리거 이벤트와 관련된 정보를 직접 전송하거나, 액세스 포인트를 통해 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 프로세서(510)는, 상기 메모리(530)에 상기 로컬 룰 데이터베이스가 저장된 상태에서, 상기 클라우드 서버로부터 업데이트 정보가 수신되는 경우, 상기 로컬 룰 데이터베이스 중 적어도 일부를 업데이트 하도록 설정될 수 있다.

다양한 실시예에 따른, 전자 장치(500)의 로컬 네트워크 기반 이벤트 처리 방법은, 제1외부 장치에서 감지되는 트리거 이벤트 및 상기 트리거 이벤트에 대응하는 룰 세트, 목적지, 또는 동작 커맨드 중 적어도 하나를 맵핑한 룰 정보를 클라우드 서버로부터 수신하여 로컬 룰 데이터베이스에 저장하는 동작, 제1외부 장치로부터 트리거 이벤트를 수신하는 동작, 상기 로컬 룰 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작, 및 상기 확인된 룰 정보에 기초하여, 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작을 포함할 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트 및 상기 트리거 이벤트를 바이패스(bypass)할 목적지를 맵핑하여 저장하는 라우팅(routing) 데이터베이스를 포함하고, 상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은, 상기 라우팅 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 상기 허브 장치를 확인하는 동작을 포함하고, 및 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은, 상기 허브 장치에 상기 트리거 이벤트를 전송하는 동작을 포함할 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트 및 상기 트리거 이벤트의 발생 시 수행되는 룰이 정의된 룰 세트들을 맵핑하여 저장하는 목적지 데이터베이스를 포함하고, 상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은, 상기 목적지 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 세트를 확인하는 동작, 및 상기 확인된 룰 세트를 실행할 수 있는 상기 허브 장치를 확인하는 동작을 포함하고, 및 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은, 상기 허브 장치에 상기 확인된 룰 세트 정보를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 제3외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고, 상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은, 상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제3외부 장치를 확인하는 동작을 포함하고, 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은, 상기 제3외부 장치와 연결된 상기 허브 장치에 상기 확인된 동작 커맨드를 전송하도록 설정될 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스는, 상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 상기 제2외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고, 상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은, 상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제2외부 장치를 확인하는 동작을 포함하고, 및 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은, 상기 제2외부 장치에 상기 확인된 동작 커맨드를 전송하는 동작을 포함할 수 있다.

다양한 실시예에 따르면, 상기 제2외부 장치와 연결될 수 없는 경우, 상기 클라우드 서버에 상기 트리거 이벤트와 관련된 정보를 전송하는 동작을 더 포함할 수 있다.

다양한 실시예에 따르면, 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은, 상기 전자 장치(500)의 근거리 무선 통신 기능을 이용하여 상기 제2외부 장치에 상기 트리거 이벤트와 관련된 정보를 직접 전송하거나, 액세스 포인트를 통해 전송하는 동작을 포함할 수 있다.

다양한 실시예에 따르면, 상기 로컬 룰 데이터베이스가 저장된 상태에서, 상기 클라우드 서버로부터 업데이트 정보가 수신되는 경우, 상기 로컬 룰 데이터베이스 중 적어도 일부를 업데이트 하는 동작을 더 포함할 수 있다.

본 문서에 개시된 다양한 실시예들에 따른 전자 장치는 다양한 형태의 장치가 될 수 있다. 전자 장치는, 예를 들면, 휴대용 통신 장치(예: 스마트폰), 컴퓨터 장치, 휴대용 멀티미디어 장치, 휴대용 의료 기기, 카메라, 웨어러블 장치, 또는 가전 장치를 포함할 수 있다. 본 문서의 실시예에 따른 전자 장치는 전술한 기기들에 한정되지 않는다.

본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", "A 또는 B 중 적어도 하나", "A, B 또는 C", "A, B 및 C 중 적어도 하나", 및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.

본 문서의 다양한 실시예들에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로와 같은 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 상기 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일실시예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.

본 문서의 다양한 실시예들은 기기(machine)(예: 전자 장치(401)) 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리(436) 또는 외장 메모리(438))에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어(예: 프로그램(440))로서 구현될 수 있다. 예를 들면, 기기(예: 전자 장치(401))의 프로세서(예: 프로세서)는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장 매체는, 비일시적(non-transitory) 저장 매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장 매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장 매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.

일실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory(CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두 개의 사용자 장치들(예: 스마트 폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.

다양한 실시예들에 따르면, 상기 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있으며, 복수의 개체 중 일부는 다른 구성요소에 분리 배치될 수도 있다. 다양한 실시예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 상기 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.

Claims

전자 장치에 있어서,
통신 모듈;
메모리; 및
상기 통신 모듈 및 상기 메모리와 작동적으로(operatively) 연결되는 프로세서를 포함하고,
상기 프로세서는,
제1외부 장치에서 감지되는 트리거 이벤트 및 상기 트리거 이벤트에 대응하는 룰 세트, 목적지, 또는 동작 커맨드 중 적어도 하나를 맵핑한 룰 정보를 상기 통신 모듈을 통해 클라우드 서버로부터 수신하여 상기 메모리의 로컬 룰 데이터베이스에 저장하고,
상기 통신 모듈을 통해 제1외부 장치로부터 트리거 이벤트를 수신하고,
상기 로컬 룰 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 정보를 확인하고, 및
상기 확인된 룰 정보에 기초하여, 상기 트리거 이벤트와 관련된 정보를 상기 통신 모듈을 통해 제2외부 장치로 전송하도록 설정된 전자 장치.
제 1항에 있어서,
상기 제2외부 장치는 상기 전자 장치와 동일한 로컬 네트워크 상에 위치하는 허브 장치인 전자 장치.
제 2항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트 및 상기 트리거 이벤트를 바이패스(bypass)할 목적지를 맵핑하여 저장하는 라우팅(routing) 데이터베이스를 포함하고,
상기 프로세서는,
상기 라우팅 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 상기 허브 장치를 확인하고,
상기 허브 장치에 상기 트리거 이벤트를 전송하도록 설정된 전자 장치.
제 2항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트 및 상기 트리거 이벤트의 발생 시 수행되는 룰이 정의된 룰 세트들을 맵핑하여 저장하는 목적지 데이터베이스를 포함하고,
상기 프로세서는,
상기 목적지 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 세트를 확인하고,
상기 확인된 룰 세트를 실행할 수 있는 상기 허브 장치를 확인하고, 및
상기 허브 장치에 상기 확인된 룰 세트 정보를 전송하도록 설정된 전자 장치.
제 2항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 제3외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고,
상기 프로세서는,
상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제3외부 장치를 확인하고,
상기 제3외부 장치와 연결된 상기 허브 장치에 상기 확인된 동작 커맨드를 전송하도록 설정된 전자 장치.
제 1항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 상기 제2외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고,
상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제2외부 장치를 확인하고,
상기 제2외부 장치에 상기 확인된 동작 커맨드를 전송하도록 설정된 전자 장치.
제 1항에 있어서,
상기 프로세서는,
상기 통신 모듈을 통해 상기 제2외부 장치와 연결될 수 없는 경우,
상기 클라우드 서버에 상기 트리거 이벤트와 관련된 정보를 전송하도록 설정된 전자 장치.
제 1항에 있어서,
상기 프로세서는,
상기 통신 모듈의 근거리 무선 통신 기능을 이용하여 상기 제2외부 장치에 상기 트리거 이벤트와 관련된 정보를 직접 전송하거나, 액세스 포인트를 통해 전송하도록 설정된 전자 장치.
제 1항에 있어서,
상기 프로세서는,
상기 메모리에 상기 로컬 룰 데이터베이스가 저장된 상태에서, 상기 클라우드 서버로부터 업데이트 정보가 수신되는 경우, 상기 로컬 룰 데이터베이스 중 적어도 일부를 업데이트 하도록 설정된 전자 장치.
전자 장치의 로컬 네트워크 기반 이벤트 처리 방법에 있어서,
제1외부 장치에서 감지되는 트리거 이벤트 및 상기 트리거 이벤트에 대응하는 룰 세트, 목적지, 또는 동작 커맨드 중 적어도 하나를 맵핑한 룰 정보를 클라우드 서버로부터 수신하여 로컬 룰 데이터베이스에 저장하는 동작;
제1외부 장치로부터 트리거 이벤트를 수신하는 동작;
상기 로컬 룰 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작; 및
상기 확인된 룰 정보에 기초하여, 상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작을 포함하는 방법.
제 10항에 있어서,
상기 제2외부 장치는 상기 전자 장치와 동일한 로컬 네트워크 상에 위치하는 허브 장치인 방법.
제 11항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트 및 상기 트리거 이벤트를 바이패스(bypass)할 목적지를 맵핑하여 저장하는 라우팅(routing) 데이터베이스를 포함하고,
상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은,
상기 라우팅 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 상기 허브 장치를 확인하는 동작을 포함하고, 및
상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은,
상기 허브 장치에 상기 트리거 이벤트를 전송하는 동작을 포함하는 방법.
제 11항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트 및 상기 트리거 이벤트의 발생 시 수행되는 룰이 정의된 룰 세트들을 맵핑하여 저장하는 목적지 데이터베이스를 포함하고,
상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은,
상기 목적지 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 룰 세트를 확인하는 동작; 및
상기 확인된 룰 세트를 실행할 수 있는 상기 허브 장치를 확인하는 동작을 포함하고, 및
상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은,
상기 허브 장치에 상기 확인된 룰 세트 정보를 전송하는 동작을 포함하는 방법.
제 11항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 제3외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고,
상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은,
상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제3외부 장치를 확인하는 동작을 포함하고,
상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은,
상기 제3외부 장치와 연결된 상기 허브 장치에 상기 확인된 동작 커맨드를 전송하는 동작을 포함하는 방법.
제 10항에 있어서,
상기 로컬 룰 데이터베이스는,
상기 트리거 이벤트, 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 상기 제2외부 장치를 맵핑하여 저장하는 커맨드 데이터베이스를 포함하고,
상기 트리거 이벤트에 맵핑된 룰 정보를 확인하는 동작은,
상기 커맨드 데이터베이스에서, 상기 수신된 트리거 이벤트에 맵핑된 동작 커맨드 및 상기 제2외부 장치를 확인하는 동작을 포함하고, 및
상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은,
상기 제2외부 장치에 상기 확인된 동작 커맨드를 전송하는 동작을 포함하는 방법.
제 10항에 있어서,
상기 제2외부 장치와 연결될 수 없는 경우, 상기 클라우드 서버에 상기 트리거 이벤트와 관련된 정보를 전송하는 동작을 더 포함하는 방법.
제 10항에 있어서,
상기 트리거 이벤트와 관련된 정보를 제2외부 장치로 전송하는 동작은,
상기 전자 장치의 근거리 무선 통신 기능을 이용하여 상기 제2외부 장치에 상기 트리거 이벤트와 관련된 정보를 직접 전송하거나, 액세스 포인트를 통해 전송하는 동작을 포함하는 방법.
제 10항에 있어서,
상기 로컬 룰 데이터베이스가 저장된 상태에서, 상기 클라우드 서버로부터 업데이트 정보가 수신되는 경우, 상기 로컬 룰 데이터베이스 중 적어도 일부를 업데이트 하는 동작을 더 포함하는 방법.
전자 장치에 있어서,
통신 모듈;
메모리; 및
상기 통신 모듈 및 상기 메모리와 작동적으로(operatively) 연결되는 프로세서를 포함하고,
상기 프로세서는,
트리거 이벤트 및 상기 트리거 이벤트에 대응하여 실행될 동작을 지시하는 동작 커맨드 및 상기 동작 커맨드를 수행할 제1외부 장치를 맵핑한 룰 정보를 상기 통신 모듈을 통해 클라우드 서버로부터 수신하여 상기 메모리의 로컬 룰 데이터베이스에 저장하고,
상기 통신 모듈을 통해 제2외부 장치로부터 트리거 이벤트와 관련된 정보를 수신하고,
상기 수신된 트리거 이벤트 관련 정보에 기초하여, 상기 로컬 룰 데이터베이스에서 상기 동작 커맨드 및 상기 동작 커맨드를 수행할 상기 제1외부 장치를 확인하고, 및
상기 통신 모듈을 통해 상기 제1외부 장치에 상기 동작 커맨드를 전송하도록 설정된 전자 장치.
제 19항에 있어서,
상기 프로세서는,
상기 메모리에 상기 로컬 룰 데이터베이스가 저장된 상태에서, 상기 클라우드 서버로부터 업데이트 정보가 수신되는 경우, 상기 로컬 룰 데이터베이스 중 적어도 일부를 업데이트 하도록 설정된 전자 장치.