WO2014193166A1 - 게이트웨이 및 그 제어방법 - Google Patents

게이트웨이 및 그 제어방법 Download PDF

Info

Publication number
WO2014193166A1
WO2014193166A1 PCT/KR2014/004777 KR2014004777W WO2014193166A1 WO 2014193166 A1 WO2014193166 A1 WO 2014193166A1 KR 2014004777 W KR2014004777 W KR 2014004777W WO 2014193166 A1 WO2014193166 A1 WO 2014193166A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
gateway
meta information
user
change command
Prior art date
Application number
PCT/KR2014/004777
Other languages
English (en)
French (fr)
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 엘지전자 주식회사
Priority claimed from KR1020140064125A external-priority patent/KR20140139987A/ko
Priority claimed from KR1020140064124A external-priority patent/KR20140139986A/ko
Publication of WO2014193166A1 publication Critical patent/WO2014193166A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2834—Switching of information between an external network and a home network

Definitions

  • the present invention relates to a home network, and more particularly, to an information management structure for connecting and controlling various devices using a gateway, a gateway device using the same, and a control method thereof.
  • the gateway it is desirable to standardize the platform in order to control various home appliances of various manufacturers and to perform a linkage function through the same. This is because the metadata management structure of the gateway should be standardized to ensure the cooperative operation between various devices of different manufacturers and to facilitate service development.
  • the present invention is to provide a gateway for providing a more convenient home network service.
  • the present invention is to provide a meta information management structure of a gateway for connecting and controlling various external devices.
  • Another object of the present invention is to provide a method for performing a service requiring participation and control of a plurality of devices in execution by using a meta information management structure.
  • the gateway associated with an embodiment of the present invention for realizing the above object, the communication unit for exchanging signals with at least one external device via wired / wireless; And a first report is received from the first device, the first report comprising meta information about the at least one service in which the first device and the second device participate, and the second report is about the status of the third device from the third device.
  • the meta information of a service that can be joined by the third device among the at least one service is transmitted to the third device, and participates in a specific service among services that the third device can participate from the third device.
  • the control unit may include a control unit configured to transmit a change command to at least one of the first device and the second device.
  • the first device comprising a first report including the meta information about at least one service that the first device and the second device participates; Receiving from; If a second report is received from the third device regarding the status of the third device, transmitting meta information of a service that the third device can participate in the at least one service to the third device; And when a change request for a specific service among the services in which the third device can participate is received from the third device, transmitting a change command to at least one of the first device and the second device.
  • a control method of a gateway comprising: generating a first object resource in a device adapter as a first external device is connected; Registering the first object resource with an object resource management module of a middleware layer; Inputting, by the object resource management module, meta information about the first external device into a meta information management tree according to a preset scheme; Obtaining a device identifier of the first external device and a function identifier for at least one function supported by the first external device through the meta information management tree in a service layer; Querying the object resource management module for the address of the first object resource using the obtained device identifier and at least one function identifier at the service layer; And controlling the first external device using the address of the inquired first object resource in the service layer.
  • the controlling may include receiving meta information on a vendor specific semantic from the first external device in the service layer; Reordering devices and device function items of the meta information management tree through the received meta information at the service layer; And controlling a manufacturer specific function of the first external device by using the rearranged meta information management tree in the service layer.
  • the gateway is efficient because it organizes and manages various meta information about external devices in a tree form.
  • control of a service in which a plurality of devices participate can be performed more efficiently.
  • FIG. 1 illustrates an example of a hierarchical structure applied to a gateway according to an embodiment of the present invention.
  • FIG 2 shows an example of the highest classification form of the meta information management tree according to an embodiment of the present invention.
  • FIG. 3 illustrates an example of a sub configuration of a device item of a meta information management tree according to an embodiment of the present invention.
  • FIG. 4 illustrates an example of an operation performed when an external device is connected to a gateway according to an embodiment of the present invention.
  • FIG. 5 shows an example of a sub configuration of a device function item of a meta information management tree according to an embodiment of the present invention.
  • FIG. 6 illustrates an example of a sub configuration of a location item of a meta information management tree according to an embodiment of the present invention.
  • FIG. 7 to 10 illustrate examples of sub-configurations of a user item, a service item, a device adapter item, and a customer premises device in the meta information management tree according to an embodiment of the present invention.
  • FIG. 11 illustrates an example in which items of a meta information management tree are referred to each other according to an embodiment of the present invention.
  • FIG. 12 illustrates an example of an operation performed when a service of two different users collides in a gateway according to an embodiment of the present invention.
  • FIG. 13 is a block diagram illustrating a schedule management process for performing a conflict resolution procedure according to an embodiment of the present invention.
  • FIG. 14 illustrates an example in which device operation management is applied to a gateway for a smart home service according to an embodiment of the present invention.
  • FIG. 15 illustrates an example of a device operation management process by a controller input according to an embodiment of the present invention.
  • FIG. 16 illustrates an example of a device operation management process by a user input according to an embodiment of the present invention.
  • FIG 17 illustrates an example in which a remote door control using a plurality of gateways is performed according to an embodiment of the present invention.
  • FIG. 18 illustrates an example of a process in which one of the devices participating in providing a service according to an embodiment of the present invention is changed when external devices are connected through a router, and when external devices are connected in a peer-to-peer manner.
  • FIG. 20 illustrates an example of a process of changing a device participating in a mirroring service according to an embodiment of the present invention.
  • FIG. 21 illustrates another example of a process of changing a device participating in a mirroring service according to an embodiment of the present invention.
  • FIG. 22 illustrates an example of an initial configuration process of a master user device and a gateway according to an embodiment of the present invention.
  • 23 and 24 show examples of preparation procedures at the local site and the remote site of the master user device and the gateway according to the embodiment of the present invention, respectively.
  • 25 illustrates an example of a local / remote recognition / switching process between a master user device and a gateway according to an embodiment of the present invention.
  • FIG. 26 illustrates an example in which a device adapter is pre-downloaded in an initial setting process of a master user device and a gateway according to an embodiment of the present invention.
  • FIG. 27 illustrates an example in which a device adapter is later downloaded in an initial configuration process of a master user device and a gateway according to an embodiment of the present invention.
  • 29 illustrates an example of a registration process through authentication between a user device, a gateway, and a server according to an embodiment of the present invention.
  • FIG. 30 illustrates an example of a process in which a gateway key button is used for registration between a user device, a gateway, and a server according to an embodiment of the present invention.
  • FIG. 31 illustrates an example of a process in which a user account is used for registration between a user device, a gateway, and a server according to an embodiment of the present invention.
  • 32 and 33 illustrate an example of a process of managing a lost device in a gateway according to an embodiment of the present invention.
  • 34 is a state diagram showing a relationship between four states according to an embodiment of the present invention.
  • 36 illustrates an example of a process of configuring a manufacturer-specific semantic tag according to an embodiment of the present invention.
  • FIG. 38 illustrates an example of a form in which a manufacturer-specific semantic technology is interpreted in a gateway according to an embodiment of the present invention.
  • 39 shows another example of a form in which a manufacturer-specific semantic technology is interpreted in a gateway according to an embodiment of the present invention.
  • FIG. 40 illustrates an example of a user interface that may be provided to a user as a manufacturer specific semantic technology is interpreted according to an embodiment of the present invention.
  • 41 shows an example of a block diagram of a gateway that can be applied to embodiments of the present invention.
  • the gateway referred to in the present invention may be referred to as a smart home gateway, or customer premises equipment (CPE).
  • CPE customer premises equipment
  • the gateway mentioned in the present invention is preferably installed indoors, but this is exemplary and is not limited to the installation site.
  • the accompanying drawings are intended to facilitate understanding of the embodiments disclosed herein, but are not limited to the technical spirit disclosed herein by the accompanying drawings, all changes included in the spirit and scope of the present invention. It should be understood to include equivalents and substitutes.
  • each device is connected through a gateway. It is suggested to be controlled through.
  • the gateway proposes to perform common management of meta information (executable functions, locations, states, etc.) of connected devices through a tree-type meta information management (ie, a meta data management tree).
  • the meta information management tree may mean a kind of database and defines information for providing a standardized / generalized interface between a service and a middleware platform.
  • gateway configuration including a meta information management tree according to the present invention will be described with reference to FIG. 1.
  • FIG. 1 illustrates an example of a hierarchical structure applied to a gateway according to an embodiment of the present invention.
  • a service is provided in an application layer as a top layer, an interface, a process and a meta information management tree in a middleware platform layer, and a plurality of device adapters as a driver layer in a bottom layer.
  • the interface and process of the middleware platform layer are middleware for facilitating communication between a device adapter and a service connected to an external device, and may operate with reference to the meta information management tree.
  • the device adapter may functionally include a driver and a semantic converter.
  • the driver may provide connectivity with various different devices, and the semantic converter may convert event-related signals from connected devices into signals that can be determined by an application inside the gateway. Can perform the function of converting.
  • meta information management tree structure In order to provide information required by a middleware platform and a service even in a block (not shown) of devices to be connected to the lower part of the driver layer, definition of meta information is required, and the definition is the same as the above-described meta information management tree structure, or at least It is desirable for some to be stored and managed on the device as a list / database in the form of a modified structure.
  • FIG 2 shows an example of the highest classification form of the meta information management tree according to an embodiment of the present invention.
  • the top-level classification of the meta information management tree includes a device, a device function, a location, a user, a service, a device adapter, and a connectivity ( connectivity) and customer home devices (CPEs, ie gateways).
  • each item may be divided into a group 210 for interoperability between the service and the middleware platform and a group 220 for analysis / implementation between the services according to the purpose.
  • FIG. 3 illustrates an example of a sub configuration of a device item of a meta information management tree according to an embodiment of the present invention.
  • Device deals with the classification of device models that are actually connected to gateways.
  • the device may be classified into brown appliances, white appliances, lighting, CPE, etc., and the lowest attributes include owner, priority, supported device function, and cluster. (cluster) and the like.
  • the owner defines the owner of the product, and the priority defines the rank of primary / secondary, etc. for the product family (eg TV).
  • the support function definition is a definition of a function supported by each product family and indicates whether it supports only mandatory items or optional items. It is desirable to determine which of the functions supported by each product family is required / optional in the form of a function profile in advance, and the support function definition item at the end of the tree for each device may refer to such a function profile. .
  • a parameter is settable for each function of the refrigerator, whether a value can be obtained, or whether it is mandatory support.
  • a parameter is settable for each function of the refrigerator, whether a value can be obtained, or whether it is mandatory support.
  • an attribute of a supported device function is required to support item M in Table 1 and option to support item O in support. Therefore, it is preferable that the support is predefined for each device as shown in Table 1. This is because it is not easy for the service developer to investigate and develop all the function support items for each device manufacturer, so it is easy to define the required / optional options.
  • the middleware platform it is desirable for the middleware platform to be able to discover optional items between the service and the driver of the device adapter, i.e., to perform function discovery.
  • the cluster may be applied when the device is classified into a cluster in advance for the situation in which several devices work together, such as a lamp.
  • the device item may include a unique name, a vendor, a utilization internal resource (eg, a tuner in the case of a TV), a location, and the like.
  • a utilization internal resource eg, a tuner in the case of a TV
  • FIG. 4 illustrates an example of an operation performed when an external device is connected to a gateway according to an embodiment of the present invention.
  • information related to the corresponding device may be stored in the meta information management tree. In this case, whether a supported device function is required or optional for the corresponding device may also be set. 2)
  • the service reads the connected device information from the meta information management tree and performs a function discovery on the corresponding item when there is an optional function. 3) To this end, the service sends a function discovery request message to the device adapter, and the device adapter services the optional item of the connected device through the function discovery response message based on the received message. You can reply In this case, if the option item of the connected device is previously defined in the device in a form similar to that of Table 1, this may be used.
  • FIG. 5 shows an example of a sub configuration of a device function item of a meta information management tree according to an embodiment of the present invention.
  • a device function may be in a form of listing functions of devices.
  • the combination of the device functions may represent the entire function of each device, and whether each device function is required or optional may also be defined similarly to Table 1.
  • Device functions may include items such as on, off, display, input, broadcast, web browser, TV program, energy measurement, and the like.
  • the device function may be associated with an open application programmer interface (API) provided by the gateway, and in FIG. 5, an example of a form of input basic key input is further illustrated. Meanwhile, a language / method for describing a general tree structure such as XML, oBIX schema, and SOAP may be used to express such a structure.
  • API application programmer interface
  • FIG. 6 illustrates an example of a sub configuration of a location item of a meta information management tree according to an embodiment of the present invention.
  • a classification of FIG. 6 may be considered. Specifically, there may be a classification of the home, indoor / outdoor, floor, and room from top to bottom, and each room may have a name, a common / personal space, an owner, or a user. Can have attributes for Such a classification scheme can be particularly useful when collectively controlling devices of a specific location / space.
  • FIG. 7 to 10 illustrate examples of sub-configurations of a user item, a service item, a device adapter item, and a customer premises device in the meta information management tree according to an embodiment of the present invention.
  • the service item includes a required function / required semantic item or a required resource item for checking a collision with another service, in addition to the subitems shown.
  • a resource access priority item that defines a priority of resource use for each service may be additionally included.
  • the CPE item may serve as a proxy by supplying a device adapter to the CPE by a non-compliant CPE provider, and in this case, necessary meta information is reflected in the entire meta information management tree. Interconnection can be provided for devices connected on a compatible CPE. In this case, granting all rights to the incompatible CPE may not differentiate the compatible device. Therefore, the restriction on receiving limited meta information prevents the discrimination of incompatible devices (subordinate devices of the non-conpliant CPE). Can be provided. This allows basic compatibility through device adapters even if there are incompatible CPE infrastructures installed in the network.
  • the connectivity item is located at the top of the tree, but this item is not necessarily located at the top item, but may be located in a subtree of another item.
  • FIG. 11 illustrates an example in which items of a meta information management tree are referred to each other according to an embodiment of the present invention.
  • two or more top-level items may be referred to each other in the tree.
  • meta information called supported semantics may be configured.
  • meta information called required semantic may be configured.
  • FIG. 12 illustrates an example of an operation performed when a service of two different users collides in a gateway according to an embodiment of the present invention.
  • a terminal 1110 of user A, a terminal 1140 of user B, and a TV 1130 are connected to a gateway 1120 according to the present invention. That is, it is assumed that the information of each device is already registered in the meta information management tree of the gateway 1120 through the above-described procedure of function discovery.
  • the TV 1130 may be performed directly with the gateway 1120 through wired / wireless.
  • Terminals 1110 and 1140 may be directly connected to a gateway in a local area, or may be connected to a gateway through the Internet in a remote situation. It is also assumed that the priority of user A is higher than that of user B.
  • a user A makes a scheduled recording of a TV 1130 (for example, May 28, 2013 11 channel 200, 1 hour program) through the terminal 1110 to the gateway 1120.
  • the gateway 1120 may set a reservation recording function for the TV 1130 by referring to a device, a device function, a location, a user, a service item, and the like in the meta information management tree.
  • the gateway 1120 may inquire the priority of user A in the user item and check the location of the TV in the location item.
  • the gateway may check whether the TV 1130 supports recording in the device function item in whether the TV 1130 supports the reservation recording function, and obtain information related to the reservation recording from the service.
  • the user B may also request the gateway 1120 to reserve the recording of the TV 1130 (for example, May 28, 2013 10-channel 210, two-hour program) through the terminal 1140. 4) If the scheduled recording requested by the user B overlaps with the reserved recording requested by the user A and the time zone is different, the gateway may transmit the content to the terminal 1140 of the user B by referring to the information registered in the meta information management tree. have. 5) User A has a high priority, User B asks User A whether the scheduled recording can be changed, and User 6 requests User B's request based on the information in the meta information management tree. Received through the gateway 1120.
  • User A can thus communicate the decision of accept / reject to user B, and 8) User B can receive the decision of accept / reject from User A. 9) If the user A accepts, the reservation recording request desired by the user B is again transmitted to the gateway 1120, and 10) the gateway 1120 may transmit the user B's reservation recording request information to the TV 1130. have.
  • the reservation recording may be set according to the information requested by the user B in step 3) only by the user A's acceptance without the steps 9) and 10).
  • FIG. 13 is a block diagram illustrating a schedule management process for performing a conflict resolution procedure according to an embodiment of the present invention.
  • a Check Device Schedule block in a Schedule Admin. Block an event occurs due to a request for schedule setting from a controller, an application, or a device, or a change in state of a device. If there is a conflict, check the schedule DB where relevant data is recorded.
  • the schedule database block records the following information for each device.
  • Schedule Requester Information of the requestor requesting device scheduling.
  • the requester's ID must be unique in the system and is commonly used in other blocks besides Device Operation Management.
  • the user ID may be a user ID, an application ID if an application, or a device ID if the user directly inputs the device.
  • Operation Menu Indicate which function block of the device the scheduling information is to operate through.
  • -Scheduling Property Displays the property of a scheduled operation and indicates whether it has a one-time or continuity characteristic.
  • One-time refers to an operation (eg, washing machine washing execution) that ends in one execution
  • continuity refers to an attribute that can be targeted for re-execution at any time and lasts for a scheduling time such as lighting.
  • Requesting Time indicates the time at which scheduling was requested.
  • -Scheduling Time If the scheduled operation is an event, it can be stored in the form of ⁇ start time, N / A ⁇ , and in case of continuity, ⁇ start time, duration ⁇ or ⁇ start time, end time ⁇ . If it is persistent, it can be something like ⁇ start time, infinite ⁇ .
  • the repetition interval and the number of repetitions may be indicated in the form of ⁇ duration, number ⁇ .
  • a message control block is a block for subsequent processing when a scheduling conflict occurs and performs the following processing.
  • a function for notifying the requester that there is a conflict a function for notifying the user who reserved in advance if the requester wants to negotiate with the user who reserved in advance, and requesting the acceptance of the user who reserved in advance. Receives internally necessary post processing and notifies the requestor
  • FIG. 14 illustrates an example in which device operation management is applied to a gateway for a smart home service according to an embodiment of the present invention.
  • the device operation management unit may include the schedule management block and the schedule database described above with reference to FIG. 13 and may be located in a system service area.
  • the device operation management unit may include other system services such as metadata management (Information / Metadata Management), instance management (Instance Management), event management (Event Management) and the like (eg, device ID, device list). , Device status, etc.) are shared.
  • the device operation manager may adjust the scheduling by applying a user priority rule through interworking with a system service such as an admission control block. For example, even if a user who is the first priority makes a reservation at the same time as a previously reserved time, the schedule may be updated according to the priority, and the information about the update may be notified to the lower priority user who reserved first.
  • FIG. 15 illustrates an example of a device operation management process by a controller input according to an embodiment of the present invention.
  • a device schedule setting may occur as device control starts in a controller of user 1. Accordingly, a scheduling message is sent to the CPE for request device XX scheduling request. At this time, the information required by the schedule DB may be transmitted together.
  • Check Device XX Schedule can be checked in the schedule database. If there is no schedule collision, the schedule may be updated, and if there is a collision, collision information may be transmitted to the message control block. Accordingly, the message control block transmits a collision report to the control unit of user 1.
  • the collision report may include detailed collision related information or may simply include whether a collision occurred.
  • the collision report includes a collision identifier (Collision ID) can be prevented from being confused with other conflicts between each user until the conflict is resolved.
  • collision ID collision identifier
  • the control unit of the user 1 receiving the collision report may notify the user of the collision by using various UIs and allow the user to select whether to proceed with a conflict resolution procedure with the user who is scheduled first.
  • a request adaptation of Device XX Schedule Change message may be transmitted to a user who has previously been scheduled.
  • the message may be delivered through a message control block of the CPE or may be delivered directly through the cloud.
  • the message may include a collision identifier, information of a user requesting a schedule change approval, and schedule change information.
  • a Schedule Reservation Cancel message may be transmitted to the CPE.
  • the message control block receiving the schedule reservation cancellation message may determine that the corresponding conflict has been resolved and may delete the corresponding conflict identifier.
  • a user interface for confirming whether to approve the change may be output to the corresponding user.
  • acknowledgment an ACK message is transmitted to the message control block, and the message control block updates schedule information and information of the user who has been scheduled first.
  • the message control block may delete the collision identifier and transmit an ACK message to the control unit of user 1.
  • the NACK message is transmitted to the message control block, in which case the sketch information does not change. Even in such a case, the collision identifier is deleted, and a NACK message may be transmitted to the control unit of user 1.
  • FIG. 16 illustrates an example of a device operation management process by a user input according to an embodiment of the present invention.
  • the device operation management block updates the schedule information according to the user's input, and the user's control is inputted to the controller of the scheduled user. Inform schedule updates.
  • FIG 17 illustrates an example in which a remote door control using a plurality of gateways is performed according to an embodiment of the present invention.
  • two gateways are used, one of which 1221 is provided in a user's home, and the other 1223 is provided in a user's office, and is connected to each other through the Internet.
  • the front door lock system 1210 is connected to the home gateway 1221 and includes a doorbell, a door lock, and a camera.
  • the user terminal 1230 is directly connected to the office gateway 1223 via a wired / wireless.
  • the gateway 1221 at the gateway 1221 uses a service layer (application) as a device, location, and service information for a door lock system 1210 stored in a meta information management tree. Is passed. 2) Accordingly, the gateway 1221 may operate the camera using the device and the location information. 3) In addition, the gateway 1221 queries the user's location information by using the user and the location information. 4) As a result, when the location of the user is confirmed as the office, the gateway 1221 may perform service interworking with the gateway 1223 provided in the office by using the CPE item and service information.
  • a service layer application
  • the gateway 1221 may perform service interworking with the gateway 1223 provided in the office by using the CPE item and service information.
  • the gateway 1223 provided in the office calls the user terminal 1230 using the information of the device item, and 6) the data transmission and reception of the camera 1210 and the terminal 1230 using the information of the device adapter item. You can check the speed to determine the best video codec. 7) Then, using the device function information, the home gateway 1221 may transmit the screen and voice of the entrance camera to the office gateway 1223 so that the user and the visitor may perform a video call. 8) Here, when the user inputs a door open command through the terminal, the home gateway 1221 may release the door lock and stop the camera by using the device and the device function information.
  • a service control method is provided when some devices are required to be replaced with other devices in a situation in which a plurality of devices are linked to operate to provide one service.
  • the control of the service is performed through the gateway, but the direct data exchange between the devices participating in the service may be performed through a router or without passing through the router in a peer-to-peer (P2P) manner. May be performed.
  • the router is not limited in any way and kind as long as it can provide a path for data exchange between two or more devices by wire / wireless regardless of its name.
  • FIG. 18 illustrates an example of a process in which one of the devices participating in providing a service is changed when the external devices are connected through a router, and when the external devices are connected in a P2P manner. Indicates.
  • device 1 and device 2 are connected to both a router and a gateway, respectively.
  • device 1 and device 2 Exchange service-related data through routers.
  • device 1 and device 2 report the matter (ie meta information) to the gateway (1, 2).
  • the process may be selectively performed. That is, all devices associated with the service may report to the gateway, or the master device (ie, device 1) may report to the gateway together with information of another device (ie, device 2).
  • the meta data reported here includes session state, connectivity name, connectivity service category, channel, service contents, and device type. ), A device address, a device role, and the like.
  • the device type, device address, and device role may be information already held in the gateway.
  • the corresponding information may be managed by the gateway in the form of the above-described meta information management tree.
  • the device 3 may report the request for the on-kerger or the specific service to the gateway (3).
  • the meta information reported here may include connectivity capability, connectivity service capability, device type, device address, device role, and the like. It can also be managed in the gateway in the form of a meta information management tree.
  • the gateway may select an item of a service that can be switched to device 3 among the currently running services based on the meta information reported in step 3 (4).
  • Meta information about the selected service may be reported to the device 3 (5).
  • the meta information reported here may include a connection name, a connection service category, a channel, a device type, a device address, and a device role.
  • the metadata may be visually output through the display means included in the device 3, and may help the user to determine the metadata.
  • a service change request message can be delivered from device 3 to the gateway (7).
  • the service change request message may include meta information such as a connection name, a connection service category, a channel, a device type, a device address, and a device role.
  • the gateway may transmit a control command to the devices 1 and 2 connected to the corresponding service item so as to change the service configuration (8, 9).
  • the control command may include a connection name, a connection service category, a target device address, and the like.
  • Connectivity name WiFi, WiFi Direct, Tunneled Direct Link Setup (TDLS), Bluetooth, Bluetooth Low Energy (LE), etc.
  • TDLS Tunneled Direct Link Setup
  • Bluetooth Bluetooth Low Energy
  • Connectivity service category Miracast, DLNA, Advance Audio Distribution Profile (A2DP), etc.
  • Device type TV, mobile terminal, network attached storage (NAS), etc.
  • DMS digital media server
  • DMP digital media player
  • DMR digital media Renderer
  • DMC digital media controller
  • Session state ongoing, expire, etc.
  • FIG. 20 illustrates an example of a process of changing a device participating in a mirroring service according to an embodiment of the present invention.
  • mirroring refers to a service that outputs a screen displayed on a terminal through an external display as it is, and may be performed through various protocols (eg, Miracast, DLNA, etc.).
  • the living room TV, bedroom TV and the terminal are already registered in the gateway and are connected or can be connected at any time.
  • a mirroring service may be started and the screen of the terminal may be mirrored to the living room TV (1).
  • the terminal may report meta information related to the mirroring service (eg, session state, connection name, connection service category, service content, channel, device type, device address, device role, etc.) to the gateway (2).
  • meta information related to the mirroring service eg, session state, connection name, connection service category, service content, channel, device type, device address, device role, etc.
  • the user may move to the bedroom with the terminal (3).
  • the bedroom TV can report the status of powering on to the gateway (5).
  • the gateway may determine that only the corresponding user exists in the house, and that the bedroom TV is turned on may determine that the user has moved to the bedroom. Meanwhile, the gateway acquires a device function of the bedroom TV upon initial connection and manages it in the form of a meta information management tree. Accordingly, the gateway may extract a service that can be switched from the living room TV to the bedroom TV and transmit the meta information related thereto to the bedroom TV (6).
  • the bedroom TV may output a user interface for confirming from the user whether to change the output device of the mirroring service being executed from the living room TV to the bedroom TV by using the received meta information (7).
  • the bedroom TV may transmit a mirroring scene change request message to the gateway (8).
  • the gateway may transmit a mirroring scene change command message to the terminal according to the request message (9).
  • the mirroring change command message may include meta information such as the address, type, and capability of the bedroom TV to indicate that the role of the living room TV is replaced with the bedroom TV.
  • the terminal receiving the mirroring change command message may change the output device of the mirroring service to the bedroom TV (TV).
  • TV bedroom TV
  • a user interface for receiving confirmation from the user may be provided through the display of the terminal.
  • the terminal may report the mirroring transition completion state to the gateway (11).
  • the gateway may instruct the living room TV to power off (i).
  • the living room TV may be turned off immediately, or information about the off notification may be output on the screen through a predetermined user interface. In this case, if there is no user input for a certain time, the living room TV may be turned off.
  • FIG. 21 illustrates another example of a process of changing a device participating in a mirroring service according to an embodiment of the present invention.
  • FIG. 21 while content stored in a network attached storage (NAS) is transmitted to a living room TV through a wireless router (AP) and played (that is, a share scene), the bedroom TV as the user moves to the bedroom Assume a situation where playback of the corresponding content is continued.
  • NAS network attached storage
  • AP wireless router
  • the bedroom TV Assume a situation where playback of the corresponding content is continued.
  • the user is wearing Bluetooth headphones and can be paired with both the living room TV and the bedroom TV.
  • the Bluetooth earphone when the Bluetooth earphone is connected to the living room TV, the sound of the living room TV is output through the Bluetooth earphone, and as the specific content stored in the NAS is transmitted to the living room TV through the AP, the corresponding content is output through the living room TV.
  • the living room TV accordingly has meta information (e.g., session state, connection name, connection service category, service content, channel, device type, device address, device role, etc.) related to content playback and device connection state information (i.e. Bluetooth Device type, connection name, connection service category, device address, device role, etc. for the headphone may be reported to the gateway (2).
  • meta information e.g., session state, connection name, connection service category, service content, channel, device type, device address, device role, etc.
  • device connection state information i.e. Bluetooth Device type, connection name, connection service category, device address, device role, etc. for the headphone may be reported to the gateway (2).
  • the user While playing the content, the user may move to the bedroom while wearing the Bluetooth headphones (3).
  • the bedroom TV may report that it is powered on to the gateway (5).
  • the gateway may determine that the user has moved to the bedroom. Meanwhile, the gateway acquires a device function of the bedroom TV upon initial connection and manages it in the form of a meta information management tree. Accordingly, the gateway may extract a service that can be switched from the living room TV to the bedroom TV and transmit the meta information related thereto to the bedroom TV (6).
  • the bedroom TV may output a user interface for confirming from the user whether to change the output device of the content sharing service being executed from the living room TV to the bedroom TV using the received meta information (7).
  • the bedroom TV may transmit a share scene change request message to the gateway (8).
  • the gateway may transmit a share scene change command message to the NAS and the bedroom TV according to the request message (9).
  • the share change command message transmitted to the NAS may include meta information such as an address, a type, and a capability of the bedroom TV.
  • the sharing change command message transmitted to the bedroom TV may include connection information on the Bluetooth headphones.
  • the NAS can change the output device of the sharing service to the bedroom TV (10).
  • the bedroom TV may be paired with the Bluetooth headphones so that the sound is output through the Bluetooth headphones (11).
  • the Bluetooth headphones may be released from the living room TV.
  • the bedroom TV may report the completion of the shared transition to the gateway (12).
  • the gateway may instruct the living room TV to power off (i).
  • the living room TV may be turned off immediately, or information about the off notification may be output on the screen through a predetermined user interface. In this case, if there is no user input for a certain time, the living room TV may be turned off.
  • the movement of the user is determined whether there is a new power-on device at a position different from that of the existing operating device, but this is merely an example, and the position of the user such as a motion sensor or a camera may be detected. If possible, the method is not limited to any device.
  • FIG. 22 illustrates an example of an initial configuration process of a master user device and a gateway according to an embodiment of the present invention.
  • -Master User Registration at Server The process of joining a server to use a smart home service and registering as a master user for management of a gateway (Smart Home CPE).
  • CPE Purchase & Claiming at Server The process of purchasing a gateway to be used and registering gateway-related information such as Unique Universal Identifier (UUID) and S / N by mapping it with the master user on the server.
  • UUID Unique Universal Identifier
  • S / N By mapping it with the master user on the server.
  • Application Install at Master User Device The process of installing an application that can manage gateways and other devices that are the basics for using smart home services.
  • the application can be downloaded to the master user device via the server.
  • Gateway power-on This may mean a start time of gateway registration.
  • Gateway IP Configuration The process of assigning an IP address to a gateway to use Ethernet or WiFi.
  • CPE Check Master User Registration of the Gateway
  • Master User Device ⁇ -> CPE Discovery The process of discovering whether a master user device exists locally by using SSDP, UPnP, or Private methods. Depending on whether the above-described application is installed may be excluded from the discovery target. If discovery is complete, proceed to the local path; otherwise, proceed to the remote path. Either local or remote is acceptable if possible.
  • Local Link Creation The process of creating a local link for data exchange between applications when it is found locally.
  • Request CPE Confirmation to Master User Device A process in which the gateway asks the master user to register itself as a gateway.
  • -Master User Confirmation & Register Notifies the master user through UI, etc. through the master user device that has been requested confirmation from the gateway, and when the master user approves it, the master user device for the gateway currently requested to the master user device This is a process of storing information and local network information such as SSID and BSSID.
  • CPE Registers Data relevant to the Master User Device A process in which the master user's information (UUID, etc.) is stored in the gateway according to the acceptance of the master user.
  • Find Master User at Server The process of finding the user registered as the master user of the gateway to which the server sent the request message.
  • Push Notification or e-mail to Master User The process of sending a request message via push notification or e-mail to a device registered as a master user device of a found master user.
  • the master user device is a process of notifying and receiving a request message to the master user through a UI or the like.
  • the gateway that receives the response is the master user device, which has its own ID (ID) associated with the local network through the server. , SSID, BSSID, etc.)
  • Master User Device Ack to CPE & Register A process in which a master user device, which has received local network identification information, sends an ACK to the gateway and stores the information.
  • the master user device may be a master user's smartphone.
  • 23 and 24 show the preparation process at the local site and the remote site.
  • FIG. 24 unlike FIG. 23, a message exchange is performed through a back-end server when a preset time elapses during the discovery process. Description of each process has already been described with reference to FIG. 22, and duplicate descriptions will be omitted for simplicity of the specification.
  • 25 illustrates an example of a local / remote recognition / switching process between a master user device and a gateway according to an embodiment of the present invention.
  • FIG. 25A a transition process from a remote to a local is illustrated.
  • the master user device and the gateway operate in remote mode.
  • the master user device accesses the new WiFi BSS (Join New BSS), whether the connected BSS is the home BSS of the user by checking the SSID and the BSSID stored in the preparation process of the master user device and the gateway. If it is not checked (BSS is My Home BSS?), It continues to operate in remote mode.
  • the new WiFi BSS Job New BSS
  • the master user device If yes, if the master user device is Ethernet, go directly to the local discovery step (Ethernet Connection). It checks whether the master user device and the gateway are stored during the preparation of the master user device and the gateway through SSDP, UPnP, or private discovery (Local Discovery & Confirm). If not, remote mode is maintained. When the discovery process confirms whether the devices are stored with each other, the master user device and the gateway can be switched to local mode (Auto Change to Local Mode Respectively). As a result, each device can operate in local mode. The gateway then periodically sends a check message and receives an ACK message to check whether the master user device is local (Alive Check Periodically). Of course, the master user device may send a check message to the gateway.
  • the discovery process confirms whether the devices are stored with each other, the master user device and the gateway can be switched to local mode (Auto Change to Local Mode Respectively). As a result, each device can operate in local mode.
  • the gateway then periodically sends a check message and receives an ACK message to
  • the master user device and the gateway operate in local mode.
  • a periodic check is performed as in (a) of FIG. 25 (Alive Check Periodically).
  • it may be switched to the remote mode (Auto Change to Remote Mode if can't find Peer during Specific Time).
  • a discovery and confirmation process may be performed between the master user device and the gateway in the remote mode (Remote Discovery & Confirm). If confirmed, it can operate in remote mode (Remote Mode Running). If the discovery fails even remotely, the connection between the local and the remote may be disconnected.
  • the gateway may periodically check if the master user device is able to reconnect later, or re-request the connection to the gateway when the master user device is turned on. This connection re-request may be performed only if there is an application service that must always be connected.
  • FIG. 26 illustrates an example in which a device adapter is pre-downloaded in an initial setting process of a master user device and a gateway according to an embodiment of the present invention.
  • the server delivers a device adapter to the corresponding gateway based on the registered information, and the gateway Installs it (Device adapter Download from Server to CPE).
  • the gateway Installs it (Device adapter Download from Server to CPE).
  • IP based such as Wi-Fi or Ethernet (IP based Device or Not). If it is IP-based, proceed to Device IP Configuration if IP device or Device ⁇ -> Master User Provisioning.
  • Device-Master User Device preparation is the process of installing a device in a place of actual use, checking it with the master user device to manage and control it, and storing each necessary data in each device.
  • Local Link Creation The process of creating a local link for data exchange between applications upon successful discovery.
  • -CPE Internet Connection State A process of determining whether the CPE can connect to the Internet through Ethernet or WiFi.
  • the gateway notifies the preset master user device that the device is registered. This process is the situation where communication is performed by local network.
  • -Master User Device UI The process of providing the user interface to the master user in the process of checking the previously informed message.
  • Master user records setting / property information such as name and location of newly registered device through the executed user interface and saves it in master user device. The process of passing it back to the gateway.
  • the device configuration data received by the master user is stored in the gateway.
  • the server sends new device information to the master user device and requests that it be configured.
  • -Push Notification or e-mail When the master user device can receive a notification message (Notification message) like the mobile terminal, the request can be delivered as a push notification, otherwise the request can be sent to the registered e-mail.
  • a notification message Notification message
  • FIG. 27 illustrates an example in which a device adapter is later downloaded in an initial configuration process of a master user device and a gateway according to an embodiment of the present invention.
  • the user receives the device adapter in advance in the gateway based on the claim for the new device and configures the device.
  • the later download process of the device adapter shown in FIG. 27 is different in that it requests and downloads a device adapter required by the device during the device setting process. This method has the advantage of being independent of the acquisition method of the device.
  • the gateway Upon approval of the master user in the above process, the gateway checks whether there is an existing compatible device adapter based on the information provided from the new device, and if not, requests the server.
  • the server may search for the corresponding device adapter from the registered device item and transmit it to the gateway.
  • the gateway may first provide information of the new device to the server so that the corresponding device adapter is transmitted.
  • a request from a master user device that can be installed through a storage medium such as USB and can be tethered in another way may be used. That is, information related to a WiFi hotspot of the master user device is received through a local network that is already connected, and the master user device may enable the device adapter to be transmitted from the server by activating the hotspot.
  • the gateway is preferably registered in the server in association with a user account using the service.
  • a method for security and convenience in registering a gateway with a server will be described. This method can be applied not only to the gateway but also to the server registration of the devices participating in the smart home service.
  • 29 illustrates an example of a registration process through authentication between a user device, a gateway, and a server according to an embodiment of the present invention.
  • OAuth 1.0a / 2.0 is one of the authentication standards used to use an application that uses an open API provided by a service provider. This embodiment proposes to use this as a means for registering a gateway with a server. More specifically, an OAuth function for authenticating to a server and an OAuth function for authenticating to a gateway may be applied. If the gateway is not equipped with a display or key button for a specific purpose, OAuth's 3-legged model can be applied. If either is present, the 2-legged model can be applied.
  • the user can be authenticated via a PC or smartphone and a smart device that provides a user interface.
  • the gateway and the smart device can be connected by wired methods such as Ethernet, USB, and the like. You can also connect wirelessly.
  • the gateway can provide a web service page for performing registration function after OAuth authentication and a user interface for user authentication and OAuth using the smart device.
  • the gateway performs a function of transmitting related information such as UUID to the server to register the gateway information with the server after OAuth authentication, and the server may provide an API for this.
  • the user is assigned and can be registered as the user's gateway.
  • the server informs that the gateway has been normally registered to the gateway so that it can be switched to the available state. If the gateway's web service has only the functions for registration, shorten the expiration time of the access token issued during OAuth authentication by several minutes to shorten the life cycle of the web service for registration. Resources available to web services can also be restricted so that only resources related to registration are available. This can improve safety.
  • FIG. 30 illustrates an example of a process in which a gateway key button is used for registration between a user device, a gateway, and a server according to an embodiment of the present invention.
  • a user logs in to a server with a smart device and registers gateway information.
  • the web page of the server is provided with a user interface that performs a key button function, and the user manipulates the key button of the web page after registration.
  • the server is triggered by the keybutton for a specific timeout period to monitor whether there is a gateway registration request.
  • a user who wants to register a gateway within a corresponding time may request a gateway registration by pressing a key button of the gateway.
  • the timeout time may be variably determined.
  • the gateway in which the key button is pressed inserts and sends the information indicating that the key button is requested in the previously promised field together with the registration information in the packet requesting registration.
  • the key button of the gateway may be physically configured or software.
  • the smart device may be connected to the gateway and the web user interface provided by the gateway may be displayed to the user through the smart device.
  • the server checks whether the information of the packet entered during the monitoring time matches the information entered by the user in the server. If it matches, the server updates the user information for setting and sends a confirmation message to the gateway. As such, the gateway can be switched to an active state.
  • FIG. 31 illustrates an example of a process in which a user account is used for registration between a user device, a gateway, and a server according to an embodiment of the present invention.
  • an ID and password of a user account used in a server may be transmitted to the gateway after the smart device and the gateway are connected by wire / wireless.
  • the gateway can log in to the server through the received ID / Password and request the gateway registration along with gateway information such as UUID. Accordingly, the server may register the corresponding gateway information in the user information and transmit a confirmation message to the gateway.
  • the gateway receiving the confirmation message can be activated after logging out of the server.
  • CPE Periodically checks whether the device is operating properly at the gateway.
  • Threshold Time This is a process of determining whether the time for which the device does not respond during the previous periodic checking process exceeds a predetermined threshold value, and the threshold value may be set differently for each device.
  • the gateway reports the fact to the registered master user device to inform the master user when a device that exceeds the threshold occurs.
  • the master user device can inform the master user that there is a missing device through the user interface.
  • the master user uses uninstall if the device is not actually used and disappears. If the device has been left unused for a long time, it is determined that maintenance / removal is used. The device can be physically identified. A message corresponding to the determination of the master user may be transmitted from the master user device to the gateway, and the gateway may perform an operation according to the content of the message.
  • an embodiment of the present invention proposes to define a state according to the operation state of devices connected to the gateway and whether the user is local or remote so that the gateway or the server may perform management according to the state. This can provide emergency response, energy savings, reduced signal interference, and convenience.
  • the active state refers to a state in which the device is operating, and an active state may be divided into a local active and a remote active.
  • the active state can be known by the operating time of the device as expected by the command / event invocation and the situation in which the gateway or server sends a command to or receives an event from the device.
  • the criteria for distinguishing between local and remote may be distinguished according to whether a route for delivering commands and events is in a local area or a remote area. Auxiliarily, it may be further determined whether the user's master user device is found locally and whether the user is in the house by context aware / motion sensing or the like.
  • the local active state allows the user to use all features supported by the device.
  • the function of the device may be limited. Limited functionality may be preselected by the device manufacturer. Functions that can be dangerous when supported remotely, for example, start cooking in an oven, can be pre-configured locally only.
  • the park state may mean a state in which there is no change of operation and no schedule for operation except a device related to security and safety or a device that is always on, will be maintained.
  • the method of determining such a state may be, for example, a situation in which the user is determined not to be in the house or a case where a command to enter the state is given by the user regardless of the operation state of the device.
  • the position determination of the user is as described above in the active state.
  • devices and services related to security / safety are activated by commands of a gateway or a server, and devices are turned off except for a device which is always turned on. At this time, the device that is always on may be activated energy-saving function.
  • metadata about an operation state before entering the present state is stored in advance for retention.
  • the sleep state may refer to a state in which it is unclear whether a user is present in the home in a situation where a device other than a device related to security and safety or a device that is always on does not operate continuously for a predetermined time.
  • sleep notifications are delivered to devices except security / safety related devices by commands of a gateway or a server.
  • the device performing the periodic operation may change the period longer.
  • a device that is always on receiving the sleep notification may be activated when there is an energy saving function.
  • the emergency state may refer to a state in which an event is detected by a device or service related to security and safety.
  • each device receiving an emergency notification according to a command of a gateway or a server may stop an operation being performed and perform a preset emergency operation. This allows the user to be notified of immediate conditions and alerts to intruders or those around them.
  • Fig. 34 the transition method and conditions between the states are shown in the direction of the arrow.
  • the circle of origin in the state diagram categorizes the services running in the house and shows in which state each service category operates. Of course, these services may change depending on the devices installed in the house.
  • security / safety and always-on devices / services are shown to operate all the time in all states.
  • sleep and park conditions contribute to energy saving and interference reduction, and the emergency mode service operates in an emergency state and can perform a predetermined service with higher priority than all other operations.
  • the management service for the above state may be included in the system service layer.
  • a command language that can be commonly used between devices of the same group is required.
  • Commands expressed in this common language may be called semantic.
  • Such semantics may correspond to a function item in the above-described meta information management tree, and functions through semantics may be defined and standardized so that control through a gateway may be performed regardless of a manufacturer.
  • many manufacturers' devices have limitations that can only be provided by these standard semantics.
  • the manufacturer-specific semantics are semantics for expressing functions that cannot be standardized by the manufacturer, and may use an application service based on a function predefined in B2B, but may be used by a third party or pre-installation service. In the case of an installed service, it is impossible to know how to use it. Therefore, it is necessary to define how to use such semantics, and an interface for using functions indicated by semantics.
  • standard semantics which can be defined as a standard, are limited in using various functions of the device.
  • the air strength / cooling / dehumidification function supported by most air conditioners or the wind strength level can be standardized. Therefore, it is not enough to support full power mode, motion detection cooling, power saving mode, etc.
  • the present embodiment proposes a method of describing and making use of a semantic classification system for standardization and a vendor specific semantic that is difficult to standardize.
  • a gateway In order to support a remote control environment, interworking with the cloud is preferable, and a gateway is required to interoperate with devices of various manufacturers having various connectivity.
  • the devices are controlled by the gateway's application and the control device (e.g., master user device) and can interoperate with each other.
  • Semantic can be configured in the form of an API by defining commands that can be commonly understood between devices of the same group in order for devices of various manufacturers to be serviced through the gateway as described above, can be managed in the middleware layer have.
  • the embodiments described below describe a classification scheme for semantics and a method of describing manufacturer specific semantics.
  • Semantics may be defined in the form of sensors and actuators, or may be defined by classifying similarities. For example, semantics for setting the temperature of an air conditioner and a temperature of a refrigerator are classified into the same semantics.
  • semantics may be classified into Intrinsic, Behavior, and Vendor Sepecific.
  • Intrinsics can be classified according to device-specific functions.
  • Intrinsic basic TV semantics define essential functions of TV such as channel switching and volume control, and in the case of air conditioner semantics, essential functions of air conditioner such as operation setting and wind direction setting are defined.
  • This classification system provides intuitive information about the basic properties of the device and the basic functions that can be controlled by only information about the semantics supported by the device.
  • Sensible semantics refers to sensor functions such as motion, sound, and time
  • the application searches for devices that support detection semantics and executes the detection function collectively, or selects specific devices to execute detection functions. You can get specific information.
  • Energy Manageable semantics you can find devices with energy-saving features and activate them to save energy. After all, this semantic can be seen as elements that require interworking between devices, and devices and people, in addition to the basic and intuitive functions of devices.
  • the device-specific semantics may be configured in a complex manner, and the characteristics of the device may be intuitively understood.
  • an example of generating a device model using intrinsic, behavior, and manufacturer-specific semantics may provide various semantics in the case of a high-end TV, and may support only less semantics in the case of a simple TV. Modeling is possible.
  • the application service can extract these relationships using the meta-conditioning management tree to know the semantics available for each device model.
  • 36 illustrates an example of a process of configuring a manufacturer-specific semantic tag according to an embodiment of the present invention.
  • An instance called device A sends its own identification information such as an ID to an instance management module, thereby binding may be performed.
  • an instance may refer to a resource allocated to a specific object in object-oriented programming.
  • the instance management module inputs the information according to the meta information management system based on the information received from the device A instance.
  • the application service can obtain the semantic list and identifier supported by a specific device by reading the device list and identifier, or can read the device list e and semantics by reading the device list and identifier supporting the specific semantics.
  • the process of requesting a semantic list and identifier supported by the device A is shown.
  • 3-1 is a process of transmitting an event notification in meta information management (ie, dynamic update) when there is an update in the semantics of the device instance.
  • meta information management ie, dynamic update
  • a semantic list and identifier supported by the device A may be delivered to the application service.
  • the application service can request the instance management of the address of the device A instance that the user wants to use.
  • the instance manager can inform the address of the instance at the request of the application service.
  • the application service can exchange commands with the device A instance through the semantic API.
  • the manufacturer-specific semantics imported during the previous process does not agree with B2B, only the manufacturer-specific semantics in the form of a black box (black-box) is known and the contents are still unknown. Therefore, if there is a manufacturer-specific semantic, it should request information on the functional matters through the manufacturer-specific semantic API.
  • the manufacturer-specific semantic API may be provided with a method of using one or two codes as semantically in the form of pseudo code.
  • A represents whether it is a get function or a set function
  • B represents a resource path
  • C is an object for the parameter for each resource when A is selected as a set function.
  • X can be of type void or an object.
  • A may be a resource path
  • B may be an object for resource-specific arguments
  • X may be a void or object type.
  • a description of the corresponding resource may be returned.
  • the command can be executed using the manufacturer-specific semantic description obtained in the step 8 above.
  • FIG. 37 illustrates a description structure and a format, and if there is an input / output for each function from a higher function to a lower function, the description of the input structure is described as a uniform resource identifier (URI) based method. The form in which descriptions are organized and managing paths to resources is shown.
  • URI uniform resource identifier
  • -functionDescription Can be used to describe the functions to users and the operation between devices by natural language processing.
  • the input / output description format may be applied when there are inputVariableHref and outputVariableHref in the above-described function description.
  • -varType Type of variable, which can be divided into boolean, index, range, and message types. boolean and message types are automatically interpreted as bool and string types. Variable types can provide useful information to represent a user interface.
  • -varAttributeMin Shows the minimum value when varType is a range type.
  • -varAttributeMax Display maximum value when varType is range type.
  • varType is an index type, it is displayed as a string array.
  • the structure as shown in FIG. 38 may be derived, and if it is related to the standard semantics. Associations can be tracked. For example, a vendor specific function 1 may be mapped to a second function of an existing standard semantic 1, and a vendor specific function 2 may be mapped to a standard semantic 3, respectively.
  • the device may be unified using standard semantics and manufacturer-specific semantics.
  • a manufacturer-specific semantic function is an extension of a standard function, it may be provided as a new user interface if it is new due to an extension of a corresponding user interface.
  • the application service does not know the meaning of the corresponding function, the user may know the meaning through the expression on the user interface and thus may provide significant value in terms of the user.
  • FIG. 40 illustrates an example of a user interface that may be provided to a user as a manufacturer specific semantic technology is interpreted according to an embodiment of the present invention.
  • the individual functions of the manufacturer may be provided as UIs, not the standard as shown in FIG. 40. It can also be changed dynamically by selecting a product.
  • 41 shows an example of a block diagram of a gateway that can be applied to embodiments of the present invention.
  • the gateway 100 may include a wireless communication unit 110, a user input unit 120, an output unit 150, an interface unit 160, a memory 170, a controller 180, a power supply unit 190, and the like. have.
  • the components shown in FIG. 41 are not essential to implementing a gateway, so a gateway described herein may have more or fewer components than those listed above.
  • the wireless communication unit 110 of the components, the gateway 100 and the external device, between the gateway 100 and another gateway 100, or the gateway 100 and another gateway 100, or an external server ) May include one or more modules that enable wireless communication between the networks in which are located).
  • the wireless communication unit 110 may include at least one of the broadcast receiving module 111, the mobile communication module 112, the wireless internet module 113, the short range communication module 114, and the location information module 115. .
  • the user input unit 120 may include a touch key, a mechanical key, and the like for receiving a control command from the user.
  • the output unit 150 is used to generate an output related to visual, auditory or tactile senses, and may include at least one of the display unit 151, the audio output unit 152, and the light output unit 153.
  • the display unit 151 forms a layer structure with or is integrally formed with the touch sensor, thereby implementing a touch screen.
  • Such a touch screen may provide an output interface between the gateway 100 and the user while functioning as a user input unit 123 that provides an input interface between the gateway 100 and the user.
  • the interface unit 160 serves as a path to various types of external devices connected to the gateway 100.
  • the interface unit 160 connects a device equipped with a wired / wireless headset port, an external charger port, a wired / wireless data port, a memory card port, and an identification module. It may include at least one of a port, an audio input / output (I / O) port, a video input / output (I / O) port, and an earphone port.
  • the gateway 100 may perform appropriate control related to the connected external device in response to the connection of the external device to the interface unit 160.
  • the memory 170 may store a plurality of application programs (applications) or applications running in the gateway 100, data for operating the gateway 100, instructions, and the above-described meta information management tree. . At least some of these applications may be downloaded from an external server via wireless communication. In addition, at least some of these applications may be configured to provide the gateway 100 with the basic functions of the gateway 100 (eg, providing wired / wireless connectivity with external devices, detecting and registering peripheral devices that can be connected). May be present in the phase.
  • the application program may be stored in the memory 170 and installed on the gateway 100 to be driven by the controller 180 to perform an operation (or function) of the gateway.
  • the controller 180 In addition to the operation related to the application program, the controller 180 typically controls the overall operation of the gateway 100.
  • the controller 180 provides appropriate information or functions to a user by processing signals, data, items of a meta information management tree, or the like, which are input or output through the above-described components, or by running an application program stored in the memory 170. Can be processed.
  • controller 180 may control at least some of the components described with reference to FIG. 41 to drive an application program stored in the memory 170. Furthermore, the controller 180 may operate by combining at least two or more of the components included in the gateway 100 to drive the application program.
  • the controller 180 establishes a data path through the external device and the wireless communication unit 110 or the interface unit 160, and when the external device is connected through this, reads information of the external device according to a predetermined registration procedure. It may be registered in the meta information management tree of the memory 170. Then, when the service request message is transmitted from the external device, information necessary to perform the corresponding service is obtained from the meta information management tree, and necessary procedures (for example, the above-described collision resolution procedure and interworking with other gateways according to user location detection) are performed. Etc.) may be performed.
  • the controller 180 receives meta information about a service being executed from the external devices, determines whether the service can be switched to the external device that is turned on when another external device is turned on, and determines whether the service can be switched. Information can be passed to an external device that is turned on. Afterwards, the device on which a specific service is executed may be changed according to a user's command input. Here, as described above, whether the device is newly turned on may be replaced by other information that may determine whether the user moves the location.
  • controller 180 may map the above-described manufacturer-specific semantics to the existing meta information management tree, and may allow the user to conveniently access and control the manufacturer-specific semantics.
  • the power supply unit 190 receives power from an external power source and an internal power source under the control of the controller 180 to supply power to each component included in the gateway 100.
  • the power supply unit 190 may include a battery.
  • the wireless communication unit 110 and the interface unit 160 may be collectively referred to as a "communication unit" when used for a common purpose of providing a data path with an external device.
  • At least some of the above components may operate in cooperation with each other to implement an operation, control, or control method of the gateway according to various embodiments described below.
  • the operation, control, or control method of the gateway may be implemented on the gateway by driving at least one application program stored in the memory 170.
  • the present invention described above can be embodied as computer readable codes on a medium on which a program is recorded.
  • the computer-readable medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include ROM, RAM, CD-ROM, magnetic tape, floppy disks, optical data storage devices, and the like, which are also implemented in the form of carrier waves (eg, transmission over the Internet). It also includes.
  • the computer may include the controller 180 of the terminal.
  • the present invention can be applied to a gateway for connecting and controlling each device in configuring a smart home service.
  • the gateway according to the present invention can be operated in the home as well as remote.

Abstract

본 발명은 홈 네트워크에 관한 것으로, 보다 상세히는 게이트웨이를 이용하여 다양한 장치를 연결하고 제어하기 위한 메타정보 관리 구조와, 이를 이용한 게이트 웨이 장치 및 그 제어방법에 관한 것이다. 본 발명의 일 실시예와 관련된 게이트웨이는, 적어도 하나의 외부 장치와 유/무선으로 신호를 교환하기 위한 통신부; 및 제 1 장치 및 제 2 장치가 참여하는 적어도 하나의 서비스에 대한 메타 정보를 포함하는 제 1 보고가 상기 제 1 장치로부터 수신되고, 제 3 장치로부터 상기 제 3 장치의 상태에 대한 제 2 보고가 수신되면, 상기 적어도 하나의 서비스 중 상기 제 3 장치가 참여할 수 있는 서비스의 메타 정보가 상기 제 3 장치로 전송되도록 하고, 상기 제 3 장치로부터 상기 제 3 장치가 참여할 수 있는 서비스 중 특정 서비스에 참여를 요청하는 변경 요청이 수신되면, 상기 제 1 장치 및 상기 제 2 장치 중 적어도 하나로 변경 명령이 전송되도록 제어하는 제어부를 포함할 수 있다.

Description

게이트웨이 및 그 제어방법
본 발명은 홈 네트워크에 관한 것으로, 보다 상세히는 게이트웨이를 이용하여 다양한 장치를 연결하고 제어하기 위한 정보 관리 구조와, 이를 이용한 게이트 웨이 장치 및 그 제어방법에 관한 것이다.
최근 스마트 관련 기술이 보급되면서 가정에도 가전제품 간의 연계 기능을 지원하는 스마트 홈(Smart Home) 기술 구축이 주목받고 있다. 스마트 홈을 구축하기 위해서는 다른 장치들의 상호동작성(interoperability) 및 관리(management)가 가능하도록 다양한 유무선 연결성(connectivity)을 지원하는 홈 게이트 웨이(Home Gateway)의 도입이 고려될 수 있다.
그런데, 게이트 웨이를 이용할 경우 다양한 제조사의 다양한 가전제품의 제어와 그를 통한 연계 기능의 수행을 위해 플랫폼의 표준화가 바람직하다. 이는 게이트웨이의 메타정보 관리(Metadata Management) 구조가 표준화되어 있어야 서로 다른 제조사의 다양한 장치들 간의 연계 동작이 보장되고, 서비스 개발 또한 용이해지기 때문이다.
본 발명은 보다 편리한 홈 네트워크 서비스를 제공하기 위한 게이트웨이를 제공하기 위한 것이다.
특히, 본 발명은 다양한 외부 장치를 연결하고 제어하기 위한 게이트웨이의 메타정보 관리 구조를 제공하기 위한 것이다.
또한, 본 발명은 메타정보 관리 구조를 이용하여 실행에 복수의 장치의 참여 및 제어가 요구되는 서비스를 수행하는 방법을 제공하기 위한 것이다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
상기한 과제를 실현하기 위한 본 발명의 일 실시예와 관련된 게이트웨이는, 적어도 하나의 외부 장치와 유/무선으로 신호를 교환하기 위한 통신부; 및 제 1 장치 및 제 2 장치가 참여하는 적어도 하나의 서비스에 대한 메타 정보를 포함하는 제 1 보고가 상기 제 1 장치로부터 수신되고, 제 3 장치로부터 상기 제 3 장치의 상태에 대한 제 2 보고가 수신되면, 상기 적어도 하나의 서비스 중 상기 제 3 장치가 참여할 수 있는 서비스의 메타 정보가 상기 제 3 장치로 전송되도록 하고, 상기 제 3 장치로부터 상기 제 3 장치가 참여할 수 있는 서비스 중 특정 서비스에 참여를 요청하는 변경 요청이 수신되면, 상기 제 1 장치 및 상기 제 2 장치 중 적어도 하나로 변경 명령이 전송되도록 제어하는 제어부를 포함할 수 있다.
상기한 과제를 실현하기 위한 본 발명의 일 실시예와 관련된 게이트웨이의 제어방법은, 제 1 장치 및 제 2 장치가 참여하는 적어도 하나의 서비스에 대한 메타 정보를 포함하는 제 1 보고를 상기 제 1 장치로부터 수신하는 단계; 제 3 장치로부터 상기 제 3 장치의 상태에 대한 제 2 보고가 수신되면, 상기 제 3 장치로 상기 적어도 하나의 서비스 중 상기 제 3 장치가 참여할 수 있는 서비스의 메타 정보를 전송하는 단계; 및 상기 제 3 장치로부터 상기 제 3 장치가 참여할 수 있는 서비스 중 특정 서비스에 대한 변경 요청이 수신되면, 상기 제 1 장치 및 상기 제 2 장치 중 적어도 하나로 변경 명령을 전송하는 단계를 포함할 수 있다.
상기한 과제를 실현하기 위한 본 발명의 다른 실시예와 관련된 게이트웨이의 제어방법은, 제 1 외부기기가 연결됨에 따라 장치 어댑터에서 제 1 객체 자원이 생성되는 단계; 상기 제 1 객체 자원이 미들웨어 계층의 객체 자원 관리 모듈에 등록되는 단계; 상기 객체 자원 관리 모듈을 통해 상기 제 1 외부기기에 대한 메타 정보가 기 설정된 체계에 따라 메타정보 관리 트리에 입력되는 단계; 서비스 계층에서 상기 메타정보 관리 트리를 통해 상기 제 1 외부기기의 기기 식별자 및 상기 제 1 외부기기가 지원하는 적어도 하나의 기능에 대한 기능 식별자를 획득하는 단계; 상기 서비스 계층에서 상기 획득된 기기 식별자 및 적어도 하나의 기능 식별자를 이용하여 상기 객체 자원 관리 모듈에 상기 제 1 객체 자원의 주소를 조회하는 단계; 및 상기 서비스 계층에서 상기 조회된 제 1 객체 자원의 주소를 이용하여 상기 제 1 외부기기를 제어하는 단계를 포함할 수 있다. 여기서 상기 제어하는 단계는, 상기 서비스 계층에서 상기 제 1 외부기기로부터 제조사 특정 기능(vendor specific semantic)에 대한 메타 정보를 수신하는 단계; 상기 서비스 계층에서 상기 수신된 메타 정보를 통해 상기 메타정보 관리 트리의 장치 및 장치 기능 항목을 재정렬하는 단계; 및 상기 서비스 계층에서 상기 재정렬된 메타정보 관리 트리를 이용하여 상기 제 1 외부기기의 제조사 특정 기능을 제어하는 단계를 포함할 수 있다.
본 발명에 의하면, 홈 네트워크 환경에서 보다 다양하고 신뢰성 있는 서비스가 제공될 수 있다.
특히, 게이트웨이에서 외부 장치에 대한 다양한 메타정보를 트리 형태로 구성하고 관리하기 때문에 효율적이다.
또한, 복수의 장치가 참여하는 서비스의 제어가 보다 효율적으로 수행될 수 있다.
본 발명에서 얻은 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 발명의 일 실시예에 따른 게이트웨이에 적용되는 계층구조의 일례를 나타낸다.
도 2는 본 발명의 일 실시예에 따른 메타정보 관리 트리의 최상위 분류 형태의 일례를 나타낸다.
도 3은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 장치 항목의 하위 구성의 일례를 나타낸다.
도 4는 본 발명의 일 실시예에 따른 게이트웨이에 외부 장치가 연결됨에 따라 수행되는 동작 과정의 일례를 나타낸다.
도 5는 본 발명의 일 실시예에 따른 메타정보 관리 트리의 장치 기능 항목의 하위 구성의 일례를 나타낸다.
도 6은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 위치 항목의 하위 구성의 일례를 나타낸다.
도 7 내지 도 10은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 사용자 항목, 서비스 항목, 디바이스 어댑터 항목 및 고객 댁내 장치의 하위 구성의 일례를 각각 나타낸다.
도 11은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 항목들이 서로 참조되는 형태의 일례를 나타낸다.
도 12는 본 발명의 일 실시예에 따른 게이트웨이에서 서로 다른 두 사용자의 서비스가 충돌될 경우 수행되는 동작의 일례를 나타낸다.
도 13은 본 발명의 일 실시예에 따른 충돌 해결 절차를 수행하는 스케쥴 관리과정을 블럭도로 나타낸 것이다.
도 14는 본 발명의 일 실시예에 따른 스마트 홈 서비스를 위해 장치 동작 관리가 게이트웨이에 적용되는 경우의 일례를 나타낸다.
도 15는 본 발명의 일 실시예에 따른 제어부 입력에 의한 장치 동작 관리 과정의 일례를 나타낸다.
도 16는 본 발명의 일 실시예에 따른 사용자 입력에 의한 장치 동작 관리 과정의 일례를 나타낸다.
도 17은 본 발명의 일 실시예에 따른 복수의 게이트웨이를 사용한 원격 도어 제어가 수행되는 형태의 일례를 나타낸다.
도 18은 라우터를 통해 외부 장치들이 연결될 때, 도 19는 피투피 방식으로 외부 장치들이 연결될 때 본 발명의 일 실시예에 따른 서비스 제공에 참여하는 장치 중 하나가 변경되는 과정의 일례를 각각 나타낸다.
도 20은 본 발명의 일 실시예에 따른 미러링 서비스에 참여하는 장치가 변경되는 과정의 일례를 나타낸다.
도 21은 본 발명의 일 실시예에 따른 미러링 서비스에 참여하는 장치가 변경되는 과정의 다른 일례를 나타낸다.
도 22는 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 초기 설정 과정의 일례를 나타낸다.
도 23 및 도 24에는 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 로컬 사이트와 원격 사이트에서의 준비과정의 일례를 각각 나타낸다.
도 25는 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 로컬/리모트 인지/전환 과정의 일례를 나타낸다.
도 26은 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 초기 설정 과정에서 디바이스 어댑터가 미리 다운로드되는 경우의 일례를 나타낸다.
도 27은 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 초기 설정 과정에서 디바이스 어댑터가 나중에 다운로드되는 경우의 일례를 나타낸다.
도 28은 본 발명의 일 실시예에 따른 디바이스 어댑터가 다운로드되는 과정의 일례를 나타낸다.
도 29는 본 발명의 일 실시예에 따른 사용자 기기와 게이트웨이 및 서버 간의 인증을 통한 등록 과정의 일례를 나타낸다.
도 30은 본 발명의 일 실시예에 따른 사용자 기기와 게이트웨이 및 서버 간의 등록에 게이트 웨이 키버튼이 사용되는 과정의 일례를 나타낸다.
도 31은 본 발명의 일 실시예에 따른 사용자 기기와 게이트웨이 및 서버 간의 등록에 사용자 계정이 사용되는 과정의 일례를 나타낸다.
도 32 및 도 33는 본 발명의 일 실시예에 따른 게이트웨이에서 사라진 기기를 관리하는 과정의 일례를 각각 나타낸다.
도 34는 본 발명의 일 실시예에 따른 네 상태의 관계를 나타내는 상태도이다.
도 35는 장치별 시맨틱 구성의 일례를 나타낸다.
도 36은 본 발명의 일 실시예에 따른 제조사 특정 시맨택을 구성하는 과정의 일례를 나타낸다.
도 37은 본 발명의 일 실시예에 따른 제조사 특정 시맨틱 기술 구조의 일례를 나타낸다.
도 38은 본 발명의 일 실시예에 따른 게이트웨이에서 제조사 특정 시맨틱 기술이 해석되는 형태의 일례를 나타낸다.
도 39는 본 발명의 일 실시예에 따른 게이트웨이에서 제조사 특정 시맨틱 기술이 해석되는 형태의 다른 일례를 나타낸다.
도 40은 본 발명의 일 실시예에 따른 제조사 특정 시맨틱 기술이 해석됨에 따라 사용자에게 제공될 수 있는 사용자 인터페이스의 일례를 나타낸다.
도 41은 본 발명의 실시예들에 적용될 수 있는 게이트웨이의 블럭 구성도의 일례를 나타낸다.
이하, 본 발명과 관련된 게이트웨이에 대하여 도면을 참조하여 보다 상세하게 설명한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 발명에서 언급되는 게이트웨이는 스마트 홈 게이트웨이(smart home gateway), 또는 고객 댁내 장치(CPE: customer premises equipment)라 칭할 수도 있다. 물론, 본 발명에서 언급되는 게이트웨이는 실내에 설치되는 것이 바람직하나 이는 예시적인 것으로 그 설치 장소에 제한되지 아니한다. 또한, 본 명세서에 개시된 실시 예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시 예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시 예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
일반적인 홈 네트워크에서는 장치들이 직접 연결되어 신호를 교환하는 방법으로 연계 기능이 수행되도록 하고 있으나, 본 발명에서는 다양한 장치들간의 연결성 및 연계 기능 수행을 보장하기 위하여, 각 장치들이 게이트 웨이를 통해 연결되고 이를 통해 제어되도록 할 것을 제안한다. 또한, 게이트 웨이에서는 트리 형태의 메타정보 관리(즉, 메타정보 관리 트리: Metadata Management Tree)를 통하여 연결된 장치의 메타 정보(실행 가능한 기능, 위치, 상태 등)를 공통 관리하도록 할 것을 제안한다. 여기서 메타정보 관리 트리는 일종의 데이터 베이스를 의미할 수 있으며 서비스와 미들웨어 플랫폼(middleware platform)과의 규격화/일반화된 인터페이스를 제공하기 위한 정보를 정의하는 기능을 한다. 이를 통해 서비스 개발자가 본 발명에 따른 메타정보 관리 트리를 바탕으로 서비스 실행에 필요한 정보의 구조와 내용을 획득하여 서비스의 개발 환경을 개선시킬 수 있다.
이하에서는 도 1을 참조하여 본 발명에 따른 메타정보 관리 트리를 포함하는 게이트웨이 구성을 설명한다.
도 1은 본 발명의 일 실시예에 따른 게이트웨이에 적용되는 계층구조의 일례를 나타낸다.
도 1을 참조하면, 최상위 계층(layer)으로 어플리케이션 레이어에 서비스가, 중간에는 미들웨어 플랫폼 계층으로 인터페스 및 프로세스와 메타정보 관리 트리가, 최하위 계층에는 드라이버 레이어로 복수의 디바이스 어댑터가 각각 구비된다.
서비스는 응용프로그램들을 제어하는 일반적인 어플리케이션 레이어와 그 기능이 유사하므로 명세서의 간명함을 위하여 중복되는 설명은 생략하기로 한다.
미들웨어 플랫폼 계층의 인터페이스 및 프로세스는 외부장치와 연결된 디바이스 어댑터와 서비스 사이의 통신을 원활하게 하기 위한 미들웨어로, 메타정보 관리 트리를 참조하여 동작할 수 있다.
또한 디바이스 어댑터는 기능적으로 드라이버 및 시맨틱 변환부를 포함할 수 있는데, 드라이버는 서로 다른 다양한 장치들과의 연결성을 제공하고, 시맨틱 변환부는 연결된 장치들로부터 오는 이벤트 관련 신호를 게이트웨이 내부 어플리케이션이 판별 가능한 신호로 변환하는 기능을 수행할 수 있다.
한편, 드라이버 레이어 하단에 연결될 장치들의 블록(미도시)에서도 미들웨어 플랫폼과 서비스에서 필요로 하는 정보를 제공하기 위해서는 메타 정보의 정의가 필요한데, 이러한 정의는 상술한 메타정보 관리 트리 구조와 동일하거나, 적어도 일부가 변형된 구조의 형태로 리스트/데이터 베이스로 장치에 저장되고 관리되는 것이 바람직하다.
이하에서는 도 2를 참조하여 본 발명에 따른 메타정보 관리 트리의 구체적인 분류를 설명한다.
도 2는 본 발명의 일 실시예에 따른 메타정보 관리 트리의 최상위 분류 형태의 일례를 나타낸다.
도 2를 참조하면, 메타정보 관리 트리의 최상위 분류에는 장치(device), 장치 기능(device function), 위치(location), 사용자(user), 서비스(service), 디바이스 어댑터(device adapter), 연결성(connectivity), 고객 댁네 장치(CPE, 즉, 게이트웨이)가 포함될 수 있다. 여기서 각 항목은 그 목적에 따라 서비스와 미들웨어 플랫폼간의 상호동작성을 위한 그룹(210)과 각 서비스들 간의 분석/이행을 위한 그룹(220)으로 구분될 수 있다.
이하에서는 최상위 트리에 속하는 각 항목을 도 3 내지 도 10을 참조하여 보다 상세히 설명하기로 한다.
도 3은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 장치 항목의 하위 구성의 일례를 나타낸다.
장치(Device)는 실제로 게이트웨이에 연결되는 장치 모델(device model)에 대한 분류체계를 다룬다. 도 3을 참조하면, 장치는 다시 갈색 가전, 백색 가전, 조명, CPE 등으로 구분될 수 있으며, 최하위 속성으로는 소유자(Owner), 우선순위(Priority), 지원 기능 정의(Supported device function), 클러스터(cluster) 등이 포함될 수 있다.
소유자는 제품의 소유자(ownership)를 정의하고, 우선순위는 제품군(예를 들어, TV)에 대해 주/부(primary/secondary) 등의 순위를 정의한다. 또한, 지원 기능 정의는 각 제품군이 지원하는 기능에 대한 정의로 필수(mandatory) 항목만을 지원하는지 선택사양(optional)도 지원하는지 여부를 나타낸다. 각 제품군이 지원하는 기능들 중 어느 기능이 필수인지/선택사양인지 여부는 미리 기능 프로파일 형태로 결정되어 있는 것이 바람직하며, 각 장치별 트리 말단의 지원 기능 정의 항목은 이러한 기능 프로파일을 참조할 수 있다.
이러한 기능 프로파일의 일례가 아래 표 1에 나타나 있다.
표 1
Funtion Set Get Event Support
start O 　 　 M
stop O 　 　 M
target temperature O O 　 M
wind speed O O 　 M
wind swing O O 　 M
operation fail 　 　 O M
filter change alert 　 　 O M
operation mode O O 　 O
special function O O 　 O
target humidity O O 　 O
smart energy operation O O 　 O
current temperature 　 O 　 O
operation status changed 　 　 O O
smart meter O O O O
motion detector O O O O
Etc. 　 　 　 　
표 1을 참조하면 냉장고의 각 기능에 대하여 설정(set) 가능한 파라미터인지, 값 가져오기(get)가 가능한지, 필수 지원인지 여부가 지시될 수 있다. 예를 들어, 도 3에서 지원 기능 정의(supported device function)의 속성이 필수라 함은 표 1의 서포트에서 M 항목을 지원한다는 것이고 선택사양이라 함은 서포트에서 O 항목을 지원하는 것이다. 따라서 각 장치에 대해서 표 1과 같이 지원 여부가 미리 정의되는 것이 바람직하다. 이는 서비스 개발자에게도 각 장치의 제조사 별로 기능 지원 항목을 모두 조사하고 개발하기는 쉽지 않으므로 이렇게 필수/선택사양 여부가 정의되는 것이 용이하다. 물론, 미들웨어 플랫폼은 서비스와 장치 어탭터의 드라이버 간의 선택사양 항목을 발견할 수 있는, 즉 기능 발견(function discovery)을 수행할 수 있는 것이 바람직하다.
한편, 클러스터(cluster)는 전등과 같이 여러 device가 함께 동작하는 상황을 위해 장치를 미리 클러스터로 분류할 경우 적용될 수 있다.
이 외에도, 장치 항목에는 도시되지는 않았으나 장치의 고유 명칭이나 제조사(Vendor), 활용 내부 자원(resource, 예를 들어, TV의 경우 튜너), 위치 등이 추가로 포함될 수 있다.
상술한 필수/선택사항 여부의 발견을 수행하는 과정의 일례를 도 4를 참조하여 설명한다.
도 4는 본 발명의 일 실시예에 따른 게이트웨이에 외부 장치가 연결됨에 따라 수행되는 동작 과정의 일례를 나타낸다.
도 4를 참조하면, 먼저 1) 외부 장치(Device)가 게이트웨이와 연결됨에 따라 메타정보 관리 트리에 해당 장치와 관련된 정보가 저장될 수 있다. 이때 해당 장치에 대한 지원 기능 정의(supported device function)의 필수/선택사양 여부도 함께 설정될 수 있다. 2) 서비스는 메타정보 관리 트리로부터 연결된 장치 정보를 읽어와 선택사양인 기능이 있을 경우 해당 항목에 대한 기능 발견(function discovery)을 수행한다. 3) 이를 위해 따라 서비스는 디바이스 어댑터에 기능 발견 요청(function discovery request) 메시지를 전송하고, 디바이스 어댑터는 수신된 메시지를 토대로 연결된 장치의 선택사양 항목을 기능 발견 응답(function discovery response) 메시지를 통해 서비스로 회신할 수 있다. 이때, 연결된 장치의 선택사양 항목도 표 1과 유사한 형태로 미리 장치에 정의되어 있는 경우, 이를 이용할 수 있다.
도 5는 본 발명의 일 실시예에 따른 메타정보 관리 트리의 장치 기능 항목의 하위 구성의 일례를 나타낸다.
도 5를 참조하면, 장치 기능(Device Function)은 장치들의 기능들을 나열하는 형태가 될 수 있다. 이러한 장치 기능들의 조합에 의해 각 장치의 전체 기능이 표현될 수 있으며, 각 장치 기능의 필수/선택사양 여부 또한 표 1과 유사하게 정의될 수 있다. 장치 기능은 그 하위 항목으로 온, 오프, 표시, 입력, 방송, 웹브라우저, TV 프로그램, 에너지 측정 등의 항목을 포함할 수 있다. 장치 기능은 게이트웨이에서 제공되는 오픈 API(Open Application Programmer Interface)와 연계될 수 있으며, 도 5에서는 그 예시로 입력(input)의 기본 키 입력의 형태가 추가로 예시된다. 한편, 이러한 구조를 표현하기 위해 XML, oBIX schema, SOAP 등 일반적인 트리 구조를 기술하기 위한 언어/방식이 사용될 수 있다.
도 6은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 위치 항목의 하위 구성의 일례를 나타낸다.
스마트 홈 서비스(smart home service)가 제공되기 위해서는 각 장치의 위치 정보가 제공되는 것이 바람직하며, 이를 위해 도 6과 같은 형태의 분류가 고려될 수 있다. 구체적으로, 상위에서 하위로 집의 위치, 실내/외, 층, 방별 분류가 있을 수 있으며 각 방은 이름(name), 공용/개인(common/personal) 공간 여부, 소유자(owner, 또는 사용자) 등에 대한 속성을 가질 수 있다. 이러한 분류 체계는 특정 위치/공간의 장치를 일괄로 제어하는 경우 특히 유용할 수 있다.
도 7 내지 도 10은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 사용자 항목, 서비스 항목, 디바이스 어댑터 항목 및 고객 댁내 장치의 하위 구성의 일례를 각각 나타낸다.
도 7 내지 도 10에 도시된 바와 같이, 사용자(user), 서비스(service), 디바이스 어댑터(device adapter) 및 CPE 정보 등이 제공되는 경우, 게이트 웨이 상에서 동작하는 독립된 서비스들이 동시에 실행될 때 자원의 공유에 의해 발생할 수 있는 문제들이 우선순위, 소유자, 알림, 충돌 방지절차 등을 통해 해결될 수 있다.
도 8에서 서비스 항목에는 도시된 하위 항목 외에도, 서비스 실행에 필요한 기능이 무엇인지 정의하는 요구 기능(Required function/Required semantic) 항목이나 다른 서비스와의 충돌 발생 확인을 위한 요구 자원(Required Resource) 항목, 서비스 별로 자원 사용의 우선 순위를 정의하는 자원 억세스 우선순위(Resource Access Priority) 항목이 추가로 포함될 수도 있다.
도 9에서 CPE 항목은 비호환(Non-compliant) CPE 공급자가 CPE에 디바이스 어댑터를 공급함으로써 프록시(proxy)와 같은 역할을 수행할 수 있으며 이때 필요한 메타 정보가 전체 메타정보 관리 트리에 반영 되도록 하여 비호환 CPE 상에 연결된 장치들에 대한 상호 연결성이 제공될 수 있다. 이때 비호환 CPE에 대해 모든 권리(authority)를 부여하게 되면 호환 장치에 대한 차별성이 없으질 수 있으므로 제한된 메타 정보를 받도록 제한하여 비호환 장치(Non-conpliant CPE의 하위 connected devices 항목)에 대한 차별성이 제공될 수 있다. 이을 통하여 망내에 설치된 비호환 CPE 인프라(infra)가 있을 지라도 디바이스 어댑터를 통해 기본적인 호환성이 제공될 수 있다.
도 2 및 10에서 연결성(Connectivity) 항목은 트리의 최상위에 위치하고 있으나, 본 항목은 반드시 최상위 항목에 위치할 필요는 없고, 다른 항목의 하위 트리에 위치할 수도 있다.
도 11은 본 발명의 일 실시예에 따른 메타정보 관리 트리의 항목들이 서로 참조되는 형태의 일례를 나타낸다.
도 11을 참조하면, 트리에서 둘 이상의 최상위 항목들이 서로 참조될 수 있다. 예를 들어, 장치와 기능 항목이 함께 참조될 때 장치별 지원 기능(supported semantics)이란 메타 정보가 구성될 수 있다. 다른 예로, 기능 항목과 서비스 항목이 함께 참조될 때 요구 기능(required semantic)이란 메타 정보가 구성될 수 있다.
이하에서는 도 12 및 도 13을 참조하여, 게이트웨이에서 상술한 메타정보 관리 트리를 이용하여 수행될 수 있는 구체적인 기능들을 설명한다.
도 12는 본 발명의 일 실시예에 따른 게이트웨이에서 서로 다른 두 사용자의 서비스가 충돌될 경우 수행되는 동작의 일례를 나타낸다.
도 12에서는 A 사용자의 단말기(1110)와 B 사용자의 단말기(1140) 및 TV(1130)가 본 발명에 따른 게이트웨이(1120)에 등록을 마치고 연결되어 있는 상황을 가정한다. 즉, 상술한 기능 발견 등의 절차를 통하여 각 장치의 정보가 이미 게이트웨이(1120)의 메타정보 관리 트리에 등록된 상황을 가정한다. 장치간 연결 및 메시지 교환에 대하여, TV(1130)는 게이트웨이(1120)와 직접 유/무선을 통해 수행할 수 있다. 단말기들(1110, 1140)의 경우 로컬(Local)에서는 직접 게이트웨이와 연결될 수도 있고, 리모트(remote) 상황에서는 인터넷을 통해 게이트웨와 연결될 수도 있다. 또한, A 사용자의 우선 순위가 B 사용자의 우선순위보다 높은 것으로 가정한다.
도 12를 참조하면, 먼저 1) A 사용자가 단말기(1110)를 통해 TV(1130)에 대한 예약 녹화(예를 들어, 2013.5.28 11시 채널 200번, 1시간 프로그램)를 게이트웨이(1120)에 요청할 수 있다. 2) 그에 따라 게이트웨이(1120)는 메타정보 관리 트리에서 장치, 장치 기능, 위치, 사용자, 서비스 항목 등을 참조하여 TV(1130)에 예약 녹화 기능을 설정할 수 있다. 예를 들어, 게이트웨이(1120)는 사용자 항목에서 A 사용자의 우선 순위를 조회하고, 위치 항목에서 TV의 위치를 확인할 수 있다. 또한, 게이트웨이는 장치 기능 항목에서 TV(1130)가 예약 녹화 기능을 지원하는지 여부에서 녹화를 지원하는지 여부를 확인할 수 있으며, 서비스에서 예약 녹화에 관련된 정보를 획득할 수 있다.
3) 한편, B 사용자도 단말기(1140)를 통해 TV(1130)에 대한 예약 녹화(예를 들어, 2013.5.28 10시 채널 210번, 2시간 프로그램)를 게이트웨이(1120)에 요청할 수 있다. 4) 게이트웨이는 B 사용자가 요청한 예약 녹화가 A 사용자가 요청한 예약 녹화와 시간대가 겹치고 채널이 상이한 경우, 메타정보 관리 트리에 등록된 정보를 참조하여 해당 내용을 B 사용자의 단말(1140)에 전송할 수 있다. 5) A 사용자의 우선순위가 높게 설정된 바, B 사용자는 A 사용자에게 예약 녹화의 변경이 가능한지 여부를 요청하고, 6) A 사용자는 메타정보 관리 트리의 정보를 바탕으로 한 B 사용자의 요청 사항을 게이트웨이(1120)를 통해 수신할 수 있다. 7) 그에 따라 A 사용자는 수락/거절 등의 결정 사항을 B 사용자에게 전달할 수 있으며, 8) B 사용자는 A사용자로부터 수락/거절 등의 결정 사항을 수신할 수 있다. 9) 만일, A 사용자가 수락한 경우 다시 B 사용자가 희망하는 예약 녹화 요청이 게이트웨이(1120)에 전송되고, 10) 게이트웨이(1120)는 TV(1130)로 B 사용자의 예약 녹화 요청 정보를 전달할 수 있다.
물론, 설정에 따라 9) 및 10) 단계가 없이도 A 사용자의 수락만으로 B 사용자가 3) 단계에서 요청한 정보에 따라 예약 녹화가 설정될 수도 있다.
이하에서는 전술한 충돌 해결 절차를 도 13 내지 도 16을 참조하여 보다 상세히 설명한다.
도 13은 본 발명의 일 실시예에 따른 충돌 해결 절차를 수행하는 스케쥴 관리 과정을 블럭도로 나타낸 것이다.
도 13을 참조하면, 스케쥴 관리 블럭(Schedule Admin. Block) 내의 장치 스케쥴 체크(Check Device Schedule) 블럭에서는 제어부, 어플리케이션, 장치들로부터의 스케쥴 세팅에 대한 요청이나 장치의 상태 변동으로 인한 이벤트가 발생하는 경우 관련 데이터가 기록된 스케쥴 데이터 베이스(Schedule DB)를 확인하여 충돌 발생여부를 확인한다.
스케쥴 갱신(Schedule Update) 블럭에서는 스케쥴 충돌이 없을 경우 새로 요청된 스케쥴 및 상태를 스케쥴 데이터 베이스에 갱신한다.
스케쥴 데이터 베이스 블럭은 장치별로 다음과 같은 정보를 기록한다.
-스케쥴 요청자(Schedule Requester): 장치 스케쥴링을 요청한 요청자의 정보로, 요청자의 ID는 시스템 내에서 고유(unique)해야 하며, 장치 동작 관리(Device Operation Management) 외에 다른 블럭에서도 공통적으로 사용된다. 요청자에 따라 사용자에 의한 요청일 경우 user ID, 어플리케이션일 경우 Application ID, 장치를 통해 사용자가 직접 입력한 경우 Device ID가 될 수 있으며 이들은 서로 구분되는 형태를 갖는 것이 바람직하다.
-동작 메뉴(Operation Menu): 스케쥴링 정보가 장치의 어떠한 기능 블럭(function block)을 통해 동작할 것인지 지시한다.
-스케쥴 속성(Scheduling Property): 스케쥴링한 동작의 속성을 표시하는 것으로 일회성인지, 연속성 특성을 갖는지 여부를 지시한다. 일회성은 한번의 실행으로 종료되는 동작(예를 들면, 세탁기 세탁 실행)을 의미하고, 연속성은 조명과 같이 스케쥴링 시간동안 지속되며 언제든지 재실행의 대상이 될 수 있는 속성을 의미한다.
-요청 시간(Requesting Time): 스케쥴링을 요청한 시각을 지시한다.
-스케쥴링 시간(Scheduling Time): 스케쥴링한 동작이 이벤트성인 경우 {start time, N/A}, 연속성의 경우 {start time, duration} 또는 {start time, end time} 과 같은 형태로 저장될 수 있다. 지속적일 경우는 {start time, infinite} 와 같은 형태가 될 수 있다.
-기간(Period): 스케쥴링 동작이 반복성을 가질 경우 반복 간격과 반복 회수를 {duration, number} 형태로 지시할 수 있다.
다음으로, 메시지 제어(Message Control) 블록은 스케쥴링 충돌이 발생한 경우 이에 대한 후속처리를 하기 위한 블록으로 다음과 같은 처리를 수행한다.
-제어부에 의한 요청일 경우: 충돌이 있음을 요청자에게 알리는 기능, 요청자가 미리 예약한 사용자와 협상을 원할 경우 미리 예약한 사용자에게 이를 알려 수락을 요청하는 기능, 미리 예약한 사용자의 수락 여부 메시지를 수신하여 내부적으로 필요한 후속처리 진행과 요청자에게 이를 공지하는 기능
-장치에 의한 요청일 경우(사용자가 직접 입력): 충돌이 있음을 미리 예약한 사용자에게 통보, 내부적으로 필요한 후속처리 진행
도 14는 본 발명의 일 실시예에 따른 스마트 홈 서비스를 위해 장치 동작 관리가 게이트웨이에 적용되는 경우의 일례를 나타낸다.
도 14를 참조하면, 장치 동작 관리(Device Operation Management)부는 도 13을 참조하여 전술한 스케쥴 관리 블럭 및 스케쥴 데이터 베이스를 포함할 수 있으며, 시스템 서비스 영역에 위치할 수 있다. 또한, 장치 동작 관리부에는 메타 데이터 관리(Information/Metadata Management), 인스턴스 관리(Instance Management), 이벤트 관리(Event Management) 등과 같은 다른 시스템 서비스들과 필요로 하는 정보(예를 들어, 장치 ID, 장치 리스트, 장치 상태 등)가 공유된다. 또한, 장치 동작 관리부는 승인 제어(Admission Control) 블럭과 같은 시스템 서비스와의 연동을 통해 사용자 우선순위 규칙(User Priority Rule)을 적용하여 스케쥴링을 조절할 수도 있다. 예를 들어, 1순위인 사용자가 늦게 기 예약된 시간과 같은 시간에 예약을 하더라도 우선 순위에 의해 스케쥴이 갱신되고, 갱신에 대한 정보가 먼저 예약한 낮은 순위의 사용자에게 통보될 수 있다.
도 15는 본 발명의 일 실시예에 따른 제어부 입력에 의한 장치 동작 관리 과정의 일례를 나타낸다.
도 15를 참조하면, 사용자 1의 제어부(Controller of user 1)에서 장치 제어가 시작( Device Control Start)됨에 따라 장치 스케쥴 설정이 발생할 수 있다. 그에 따라 장치 XX 스케쥴링 요청(Request Device XX Scheduling)을 위해 CPE로 스케쥴 설정 메시지가 전달된다. 이때 스케쥴 데이터베이스(Schedule DB)에서 필요로 하는 정보가 함께 전송될 수 있다.
CPE에서는 스케쥴 데이터베이스에서 해당 장치 XX의 스케쥴을 확인(Check Device XX Schedule)할 수 있다. 만일 스케쥴 충돌(Schedule Collision)이 없는 경우 스케쥴은 갱신될 수 있으며, 충돌이 있는 경우 메지시 제어 블럭으로 충돌 정보가 전달될 수 있다. 그에 따라 메시지 제어 블럭은 충돌 보고(Collision Report)를 사용자 1의 제어부로 전달한다. 이때, 충돌 보고에는 자세한 충돌 관련 정보가 포함될 수도 있고 단순히 충돌 발생 여부만이 포함될 수도 있다. 또한, 충돌 보고에는 충돌 식별자(Collision ID)가 포함되어 해당 충돌이 해결될 때까지 각 유저들간에 다른 충돌과의 혼동이 방지될 수 있다.
충돌 보고를 수신한 사용자 1의 제어부는 다양한 UI로 사용자에게 충돌 발생을 알려 사용자가 먼저 스케쥴링한 사용자와 충돌 해결 절차를 진행할지 여부(Schedule negotiation)를 선택하도록 할 수 있다.
사용자가 충돌 해결 절차를 진행하고자 하는 경우, 장치 XX의 스케쥴링 변경 승인 요청(Request Admission of Device XX Schedule Change) 메시지를 미리 스케쥴링한 사용자에 전송할 수 있다. 본 메시지는 CPE의 메시지 제어 블럭을 통해 전달될 수도 있고, 클라우드를 통해 직접 전달될 수도 있다. 또한, 본 메시지에는 충돌 식별자, 스케쥴 변경 승인을 요청하는 사용자의 정보 및 변경 희망 스케쥴 정보가 포함될 수 있다.
만일, 사용자가 충돌 해결 정차를 포기하는 경우에는 스케쥴 예약 취소Schedule Reservation Cancel) 메시지가 CPE로 전송될 수 있다. 스케쥴 예약 취소 메시지를 수신한 메시지 제어 블럭은 해당 충돌이 해결된 것으로 판단하고 해당 충돌 식별자를 삭제할 수 있다.
반대로, 먼저 스케쥴링한 사용자(Controller of Pre-Scheduling User)의 제어부(controller)가 스케쥴링 변경 승인 요청 메시지를 수신한 경우, 해당 사용자에게 변경을 승인할지 여부를 확인받기 위한 사용자 인터페이스를 출력할 수 있다. 승낙(ACK)할 경우 ACK 메시지가 메시지 제어 블럭으로 전송되며, 메시지 제어 블럭은 스케쥴 정보 및 먼저 스케쥴링한 사용자의 정보를 갱신한다. 또한, 메시지 제어 블럭은 충돌 식별자를 삭제하고 사용자 1의 제어부에 ACK 메시지를 전송할 수 있다. 한편, 승낙하지 않는 경우 NACK 메시지가 메시지 제어 블럭으로 전송되며, 이러한 경우 스케쥬 정보는 변동되지 않는다. 이러한 경우에도 충돌 식별자는 삭제되며, 사용자 1의 제어부에 NACK 메시지가 전송될 수 있다.
도 16는 본 발명의 일 실시예에 따른 사용자 입력에 의한 장치 동작 관리 과정의 일례를 나타낸다.
도 16의 경우, 도 15와의 차이점을 위주로 설명한다. 사용자가 장치를 직접 조작하는 경우, 해당 입력의 우선 순위가 최상위로 설정될 수 있다. 따라서 먼저 스케쥴링한 사용자의 제어부(Controller of Pre-Scheduling User)에 의해 미리 설정된 스케쥴이 있더라도, 장치 동작 관리 블럭에서는 사용자의 입력에 따라 스케쥴 정보를 갱신하고, 먼저 스케쥴링한 사용자의 제어부에 사용자 입력에 의한 스케쥴 갱신을 알린다.
다음으로, 도 17을 참조하여 복수의 게이트웨이를 이용한 서비스가 수행되는 경우를 설명한다.
도 17은 본 발명의 일 실시예에 따른 복수의 게이트웨이를 사용한 원격 도어 제어가 수행되는 형태의 일례를 나타낸다.
도 17에서는 두 개의 게이트웨이가 사용되는데, 그 중 하나(1221)는 사용자의 가정에 구비되고, 나머지 하나(1223)는 사용자의 사무실에 구비되며, 서로 인터넷을 통해 연결된 것으로 가정한다. 또한, 현관 도어락 시스템(1210)은 가정 게이트웨이(1221)와 연결되며, 도어벨, 도어 잠금 장치 및 카메라를 포함하는 것으로 가정한다. 아울러, 사용자의 단말기(1230)은 사무실 게이트웨이(1223)와 로컬로 직접 유/무선을 통해 연결된 경우를 가정한다.
도 17를 참조하면, 먼저 1) 방문자가 집 현관의 도어벨을 누름에 따라 게이트웨이(1221)에서는 서비스 계층(어플리케이션)으로 메타정보 관리 트리에 저장된 도어락 시스템(1210)에 대한 장치, 위치 및 서비스 정보가 전달된다. 2) 그에 따라 게이트웨이(1221)는 장치 및 위치 정보를 이용하여 카메라를 동작시킬 수 있다. 3) 또한, 게이트웨이(1221)는 사용자 및 위치 정보를 이용하여 사용자의 위치 정보를 조회한다. 4) 그 결과, 게이트웨이(1221)는 사용자의 위치가 사무실로 확인되면 고객 댁네 장치(CPE) 항목 및 서비스 정보를 이용하여 사무실에 구비된 게이트웨이(1223)와 서비스 연동을 수행할 수 있다. 5) 사무실에 구비된 게이트웨이(1223)는 장치 항목의 정보를 이용하여 사용자의 단말기(1230)를 호출하고, 6) 디바이스 어댑터 항목의 정보를 이용하여 카메라(1210)와 단말기(1230)의 데이터 송수신 속도를 확인하여 최적의 동영상 코덱을 결정할 수 있다. 7) 이후 장치 기능 정보를 이용하여 가정 게이트웨이(1221)는 현관 카메라의 화면과 음성을 사무실 게이트웨이(1223)로 전달하여 사용자와 방문자가 영상통화를 수행하도록 할 수 있다. 8) 여기서 사용자가 단말기를 통해 문열림 명령을 입력하는 경우, 가정 게이트웨이(1221)는 장치 및 장치 기능 정보를 이용하여 도어락을 해제하고 카메라를 정지시킬 수 있다.
이하에서는, 상술한 게이트웨이를 기반으로 복수의 장치가 하나의 서비스 실행에 관여하는 경우 본 발명에 따른 서비스 제어방법을 설명한다.
특히, 본 실시예에서는 하나의 서비스를 제공하기 위하여 복수의 기기가 연동되어 동작하는 상황에서 일부 장치가 다른 장치로 대체가 요구될 때의 서비스 제어방법이 제공된다.
여기서, 서비스의 제어는 게이트웨이를 통해 수행되나, 서비스 제공에 참여하는 장치들간의 직접적인 데이터 교환은 라우터(Router)를 통해 수행될 수도 있고 피투피(P2P: Peer-to-Peer) 방식으로 라우터를 거치지 않고 수행될 수도 있다. 여기서 라우터는 그 명칭과 관계없이, 둘 이상의 장치 사이에서 유/무선으로 데이터 교환을 위한 경로를 제공할 수 있다면 어떠한 방식과 종류에도 제한되지 아니한다.
도 18은 라우터를 통해 외부 장치들이 연결될 때, 도 19는 피투피(P2P) 방식으로 외부 장치들이 연결될 때 본 발명의 일 실시예에 따른 서비스 제공에 참여하는 장치 중 하나가 변경되는 과정의 일례를 각각 나타낸다.
도 18 및 도 19에서는 장치 1(Device 1) 및 장치 2(Device 2)를 통해 하나의 서비스가 실행되던 중, 장치 2가 장치 3(Device 3)으로 대체되는 경우를 가정한다. 여기서 서비스의 주체(즉, 서비스의 컨텐츠를 제공하거나 실행 중 제어를 수행하는 마스터 장치)는 장치 1인 것으로 가정한다.
먼저 도 18을 참조하면, 장치 1 및 장치 2는 각각 라우터(Router)와 게이트웨이(Gateway) 모두에 연결된 상황이며, 기 설정된 절차에 따라 서비스가 개시(standard service session start)되면 장치 1과 장치 2는 라우터를 통해 서비스 관련 데이터를 교환한다.
특정 서비스가 실행됨에 따라, 장치 1과 장치 2는 이에 대한 사항(즉, 메타 정보)을 게이트웨이로 보고한다(①, ②) . 이때 ② 과정은 선택적으로 수행될 수 있다. 즉, 서비스와 연계된 모든 장치가 게이트웨이로 보고를 수행할 수도 있고, 마스터 장치(즉, 장치 1)가 다른 장치(즉, 장치 2)의 정보까지 함께 게이트웨이로 보고를 수행할 수도 있다.
여기서 보고되는 메타 정보(meta data)는 세션 상태(Session state), 연결명(Connectivity name), 연결 서비스 카테고리(Connectivity service category), 채널(Channel), 서비스 컨텐츠(Service contents), 장치 타입(Device type), 장치 주소(Device address), 장치 역할(Device role) 등이 포함될 수 있다. 이들 중 장치 타입, 장치 주소, 장치 역할은 게이트웨이에서 이미 보유된 정보일 수 있다. 이러한 경우 해당 정보들은 상술한 메타정보 관리 트리의 형태로 게이트웨이에서 관리될 수 있다.
이후, 장치 3이 켜지커나 특정 서비스에 대한 요청을 게이트웨이로 보고할 ㅅ수 있다(③). 여기서 보고되는 메타 정보에는 연결 능력(Connectivity capability), 연결 서비스 능력(Connectivity service capability), 장치 타입(Device type), 장치 주소(Device address), 장치 역할(Device role) 등이 포함될 수 있으며, 이러한 정보 역시 메타정보 관리 트리의 형태로 게이트웨이에서 관리될 수 있다.
게이트웨이는 ③ 과정에서 보고된 메타 정보를 바탕으로 현재 실행중인 서비스 중 장치 3으로 전환가능한 서비스의 항목을 선정할 수 있다(④).
선정된 서비스에 대한 메타 정보는 장치 3으로 보고될 수 있다(⑤). 여기서 보고되는 메타 정보에는 연결 이름, 연결 서비스 카테고리, 채널, 장치 타입, 장치 주소, 장치 역할 등이 포함될 수 있다.
수신된 메타 데이터를 이용하여 장치 3에서 서비스에 참여할지 여부가 결정될 수 있다(⑥). 예를 들어, 장치 3에 구비된 디스플레이 수단을 통하여 메타 데이터를 시각적으로 출력하고, 이를 통해 사용자의 결정을 도울 수 있다.
사용자가 장치 3의 서비스 참여(즉, 장치 2 대신 장치 3이 참여)를 결정함에 따라, 게이트웨이로 서비스 변경 요청 메시지가 장치 3에서 전달될 수 있다(⑦). 이때, 서비스 변경 요청 메시지에는 연결 이름, 연결 서비스 카테고리, 채널, 장치 타입, 장치 주소, 장치 역할 등의 메타 정보가 포함될 수 있다.
변경 요청 메시지를 수신한 게이트웨이는 해당 서비스 항목에 연결된 장치 1 및 장치 2에 서비스 설정(configuration)을 변경할 수 있도록 제어 명령(control command)을 전달할 수 있다(⑧, ⑨). 이때, 제어 명령에는 연결 이름, 연결 서비스 카테고리, 대상 장치 주소(Target device address) 등이 포함될 수 있다.
이후 장치 1 및 장치 2 사이의 서비스 세션이 중단되고, 장치 3이 장치 2 대신 서비스 실행에 참여할 수 있다.
한편, 도 19의 경우 라우터를 거치지 않고 각 장치들간에 서비스 관련 데이터가 직접 교환되는 점 외에는 도 13의 과정과 유사하므로 명세서의 간명함을 위하여 중복되는 설명은 생략하기로 한다.
상술한 과정들에서 각 메타 정보의 구체적인 예는 다음과 같다.
- 연결 이름(Connectivity name) : WiFi, WiFi Direct, TDLS(Tunneled Direct Link Setup), Bluetooth, Bluetooth LE(Low Energy), 등
- 연결 서비스 카테고리(Connectivity service category) : Miracast, DLNA, A2DP(Advance Audio Distribution Profile) 등
- 서비스 컨텐츠(Service contents) : 비디오, 오디오, 이미지, 스크린 등
- 장치 타입(Device type) : TV, 이동 단말기, 네트워크 접속 저장소(NAS: Network Attached Storage) 등
- 장치 역할(Device role) : 소스/싱크(source/sink), 마스터/슬레이브(master/slave), 디지털 미디어 서버(DMS: digital media server), 디지털 미디어 플레이어(DMP: digital media player), 디지털 미디어 렌더러(DMR: digital media renderer), 디지털 미디어 제어기(DMC: digital media controller) 등
- 세션 상태(Session state) : 실행중(ongoing), 만료(expire) 등
이하에서는 도 20 및 도 21을 참조하여 상술한 장치 변경 절차를 보다 구체적인 예를 들어 설명한다.
도 20은 본 발명의 일 실시예에 따른 미러링 서비스에 참여하는 장치가 변경되는 과정의 일례를 나타낸다.
도 20에서는 단말기(예를 들어, 스마트폰)를 통해 표시되는 영상이 거실 TV를 통해 미러링(mirroring)되던 중, 사용자가 단말기와 함께 침실로 이동함에 따라 침실 TV를 통해 미러링이 속행되는 상황을 가정한다. 여기서 미러링이란 단말기에 표시되는 화면을 그대로 외부 디스플레이를 통해 출력하는 서비스를 의미하며, 다양한 프로토콜(예를 들어, 미라캐스트, DLNA 등)을 통해 수행될 수 있음은 물론이다. 또한, 거실 TV, 침실 TV 및 단말기는 이미 게이트웨이에 등록되어 연결 중이거나 언제든지 연결이 가능한 상황인 것으로 가정한다.
도 20을 참조하면, 먼저 미러링 서비스가 시작되어 단말기의 화면이 거실 TV로 미러링될 수 있다(①).
그에 따라 단말기는 미러링 서비스에 관련된 메타 정보(예를 들어, 세션 상태, 연결명, 연결 서비스 카테고리, 서비스 컨텐츠, 채널, 장치 타입, 장치 주소, 장치 역할 등)을 게이트웨이로 보고할 수 있다(②).
미러링 진행 중, 사용자가 단말기와 함께 침실로 이동할 수 있다(③).
침실로 이동한 사용자가 침실 TV를 켬에 따라(④), 침실 TV는 게이트웨이로 전원이 켜진 상태를 보고할 수 있다(⑤).
게이트웨이는 자신에 연결 중인 다른 사용자의 단말이 없는 경우 집에는 해당 사용자만이 존재하는 것으로 판단할 수 있으며, 침실 TV가 켜진것은 사용자가 침실로 이동한 것으로 판단할 수 있다. 한편, 게이트웨이는 침실 TV의 기능(device function)을 초기 연결시 획득하여 메타정보 관리 트리의 형태로 관리하고 있다. 따라서, 게이트웨이는 거실 TV에서 침실 TV로 전환이 가능한 서비스를 추출하여 그에 관련된 메타 정보를 침실 TV로 전송할 수 있다(⑥).
침실 TV는 수신된 메타 정보를 이용하여 사용자에게 실행중인 미러링 서비스의 출력 장치를 거실 TV에서 침실 TV로 변경할지 여부를 사용자로부터 확인받기 위한 사용자 인터페이스를 출력할 수 있다(⑦).
여기서 사용자가 침실 TV로의 변경을 선택하는 경우, 침실 TV는 게이트웨이로 미러링 변경 요청(mirroring scene change request) 메지시를 전송할 수 있다(⑧).
게이트웨이는 요청 메시지에 따라 단말기에 미러링 변경 명령(mirroring scene change command) 메시지를 전송할 수 있다(⑨). 이때, 미러링 변경 명령 메시지에는 거실 TV의 역할이 침실 TV로 대체됨을 지시하기 위하여 침실 TV의 주소, 타입, 능력 등의 메타 정보가 포함될 수 있다.
미러링 변경 명령 메시지를 수신한 단말기는 침실 TV로 미러링 서비스의 출력 장치를 변경할 수 있다(⑩). 물론, 이러한 과정에서 사용자의 확인을 받기 위한 사용자 인터페이스가 단말기의 디스플레이를 통해 제공될 수 있음은 물론이다.
거실 TV에서 침실 TV로의 전환이 완료되면, 단말기는 게이트웨이로 미러링 전환 완료 상태를 보고할 수 있다(⑪).
전환 완료가 보고됨에 따라, 게이트웨이는 거실 TV로 전원을 끌 것을 지시할 수 있다(⑫). 이때, 거실 TV는 바로 꺼질 수도 있고, 꺼짐 예고에 대한 정보를 소정의 사용자 인터페이스를 통해 화면에 출력할 수도 있다. 이러한 경우 일정 시간동안 사용자의 입력이 없는 경우 거실 TV가 꺼질 수 있다.
도 21은 본 발명의 일 실시예에 따른 미러링 서비스에 참여하는 장치가 변경되는 과정의 다른 일례를 나타낸다.
도 21에서는 네트워크 연결 저장소(NAS: Network Attached Storage)에 저장된 컨텐츠가 무선 공유기(AP)를 통해 거실 TV로 전송되어 재생(즉, 공유: share scene)되던 중, 사용자가 침실로 이동함에 따라 침실 TV를 해당 컨텐츠의 재생이 속행되는 상황을 가정한다. 또한, 사용자는 블루투스 헤드폰을 착용하고 있으며, 거실 TV 및 침실 TV 모두와 페어링이 가능한 것으로 가정한다.
도 21을 참조하면, 블루투스 이어폰이 거실 TV와 연결되어 거실 TV의 음향이 블루투스 이어폰으로 출력되고 있으며, NAS에 저장된 특정 컨텐츠가 AP를 통해 거실 TV로 전송됨에 따라 해당 컨텐츠가 거실 TV를 통해 출력될 수 있다(①).
거실 TV는 그에 따라 컨텐츠 재생에 관련된 메타 정보(예를 들어, 세션 상태, 연결명, 연결 서비스 카테고리, 서비스 컨텐츠, 채널, 장치 타입, 장치 주소, 장치 역할 등)와 장치 연결 상태 정보(즉, 블루투스 헤드폰에 대한 장치 타입, 연결명, 연결 서비스 카테고리, 장치 주소, 장치 역할 등)을 게이트웨이로 보고할 수 있다(②).
컨텐츠 재생 중, 사용자가 블루투스 헤드폰을 착용한 상태로 침실로 이동할 수 있다(③).
침실로 이동한 사용자가 침실 TV를 켬에 따라(④), 침실 TV는 게이트웨이로 전원이 켜짐을 보고할 수 있다(⑤).
그에 따라 게이트웨이는 사용자가 침실로 이동한 것으로 판단할 수 있다. 한편, 게이트웨이는 침실 TV의 기능(device function)을 초기 연결시 획득하여 메타정보 관리 트리의 형태로 관리하고 있다. 따라서, 게이트웨이는 거실 TV에서 침실 TV로 전환이 가능한 서비스를 추출하여 그에 관련된 메타 정보를 침실 TV로 전송할 수 있다(⑥).
침실 TV는 수신된 메타 정보를 이용하여 사용자에게 실행중인 컨텐츠 공유 서비스의 출력 장치를 거실 TV에서 침실 TV로 변경할지 여부를 사용자로부터 확인받기 위한 사용자 인터페이스를 출력할 수 있다(⑦).
여기서 사용자가 침실 TV로의 변경을 선택하는 경우, 침실 TV는 게이트웨이로 공유 변경 요청(share scene change request) 메지시를 전송할 수 있다(⑧).
게이트웨이는 요청 메시지에 따라 NAS와 침실 TV에 공유 변경 명령(share scene change command) 메시지를 전송할 수 있다(⑨). 이때, NAS로 전송되는 공유 변경 명령 메시지에는 침실 TV의 주소, 타입, 능력 등의 메타 정보가 포함될 수 있다. 또한, 침실 TV로 전송되는 공유 변경 명령 메시지에는 블루투스 헤드폰에 대한 연결 정보가 포함될 수 있다.
미러링 변경 명령 메시지를 수신한 NAS는 침실 TV로 공유 서비스의 출력 장치를 변경할 수 있다(⑩). 또한, 침실 TV는 블루투스 헤드폰과 페어링되어 음향이 블루투스 헤드폰을 통해 출력되도록 할 수 있다(⑪). 이때, 블루투스 헤드폰은 거실 TV와 페어링이 해제될 수 있다.
거실 TV에서 침실 TV로의 전환이 완료되면, 침실 TV는 게이트웨이로 공유 전환 완료 상태를 보고할 수 있다(⑫).
전환 완료가 보고됨에 따라, 게이트웨이는 거실 TV로 전원을 끌 것을 지시할 수 있다(⑬). 전술한 바와 같이, 거실 TV는 바로 꺼질 수도 있고, 꺼짐 예고에 대한 정보를 소정의 사용자 인터페이스를 통해 화면에 출력할 수도 있다. 이러한 경우 일정 시간동안 사용자의 입력이 없는 경우 거실 TV가 꺼질 수 있다.
상술한 도 21에 의하면, 게이트웨이가 직접 블루투스를 지원하지 않는 경우라 하더라도 다른 장치를 통해 페어링의 제어가 가능하므로, 해다 서비스에 참여하는 복수의 장치에 대한 일괄적 서비스 변경이 가능한 장점이 있다.
또한, 상술한 실시예들에서 사용자의 이동은 기존에 동작중인 장치의 위치와 상이한 위치에서 새로이 전원이 들어온 장치가 있는지 여부로 판단하였으나, 이는 예시적인 것으로 모션 센서나 카메라 등 사용자의 위치를 감지할 수 있다면 어떠한 장치를 통한 방법에도 제한되지 아니한다.
이하에서는 도 22 내지 도 31을 참조하여 초기 게이트 웨이 설치 및 장치 연결 과정을 보다 상세히 설명한다.
도 22는 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 초기 설정 과정의 일례를 나타낸다.
도 22에 도시된 각 과정을 설명하면 다음과 같다.
-마스터 사용자 서버 등록(Master User Registration at Server): 스마트 홈 서비스를 이용하기 위해 서버에 가입하는 과정이며 게이트웨이(Smart Home CPE)에 대한 관리를 위해 마스터 사용자(Master User)로 등록한다.
-게이트웨이 구매 및 서버 등록(CPE Purchase & Claiming at Server): 실제로 사용될 게이트웨이를 구매하고 UUID((Unique Universal Identifier) 및 S/N와 같은 게이트웨이 관련 정보를 서버에서 마스터 사용자와 매핑하여 등록하는 과정이다.
-마스터 사용자 장치에 어플리케이션 설치(Application Install at Master User Device): 스마트 홈 서비스를 이용하는데 있어서 기본이 되는 게이트웨이와 다른 장치를 관리할 수 있는 어플리케이션을 설치하는 과정이다. 어플리케이션은 서버를 통해 마스터 사용자 장치에 다운로드될 수 있다.
-게이트웨이 전원 인가(CPE ON): 게이트웨이 등록(registration)의 시작 시점을 의미할 수 있다.
-게이트웨이 IP 설정(CPE IP Configuration): 이더넷이나 WiFi를 이용하기 위해 게이트웨이에 IP 주소를 할당받는 과정이다.
-게이트웨이-마스터 사용자 기기간 준비과정(CPE <-> Master User Device Provisioning): 게이트웨이가 실제 사용될 장소에 설치되고, 이를 관리하고 제어할 마스터 사용자 장치간에 서로 필요한 정보가 교환되는 과정이다.
상기 준비과정을 보다 상세히 설명하면 아래와 같다.
-게이트웨이의 마스터 사용자 등록 확인(Check Master User Registration of CPE): 게이트웨이에 마스터 사용자가 설정되어 있는지 스스로 확인하는 과정이다.
-마스터 유저 장치 발견 준비(Ready for Master User Device Discovery): 이미 마스터 사용자 장치가 등록된 경우 이를 발견할 준비를 수행하는 과정이다.
-마스터 유저 장치 발견(Master User Device <-> CPE Discovery): SSDP, UPnP 또는 프라이빗(Private) 방법 등으로 로컬(Local)에 마스터 사용자 기기가 존재하는지 여부를 발견하는 과정이다. 전술한 어플리케이션의 설치 여부에 따라 발견 대상에서 제외될 수 있다. 발견이 완료되면 로컬 경로로 진행하고, 그렇지 않으면 원격 경로로 진행한다. 로컬/원격 모두 가능한 경우 어느쪽도 무방하다.
-로컬 연결 생성(Local Link Creation): 로컬에서 발견된 경우 어플리케이션 간 데이터 교환을 위한 로컬 연결을 생성하는 과정이다.
-마스터 사용자 장치에 게이트웨이 확인 요청(Request CPE Confirmation to Master User Device): 게이트웨이가 마스터 사용자에게 자신을 게이트웨이로 등록할 것인지를 묻는 과정이다.
-마스터 사용자 확인 및 등록(Master User Confirmation & Register) : 게이트웨이로부터 확인을 요청 받은 마스터 사용자 장치를 통해 마스터 사용자에게 UI 등을 통해 알려 주고, 마스터 사용자가 이를 승인하면 마스터 사용자 장치에 현재 요청한 게이트웨이에 대한 정보와 SSID, BSSID 등과 같은 로컬 망(Local Network) 정보를 저장하는 과정이다.
-마스터 사용자 확인 응답(Response Master User Confirmation to CPE): 요청한 게이트웨이에게 마스터 사용자의 수락을 알리는 과정이다.
-마스터 사용자 장치 관련 정보 저장(CPE Registers Data relevant to the Master User Device): 마스터 사용자의 수락에 따라 마스터 사용자의 정보(UUID 등)가 게이트웨이에 저장되는 과정이다.
-서버에 게이트웨이 확인 요청(Request CPE Confirmation to Server): 원격으로 준비과정을 진행할 경우 서버에 마스터 사용자 장치에 게이트웨이 등록 요청 메시지가 전달되도록 요청하는 과정이다.
-서버의 마스터 유저 찾기(Find Master User at Server): 서버가 요청 메시지를 보낸 게이트웨이의 마스터 사용자로 등록된 사용자를 찾는 과정이다.
-마스터 사용자에 푸쉬 알림/이메일 전송(Push Notification or e-mail to Master User): 찾은 마스터 사용자의 마스터 사용자 장치로 등록된 장치로 푸쉬 알림이나 이메일을 통해 요청 메시지를 전송하는 과정이다.
-마스터 사용자 확인(Master User Confirmation): 마스터 사용자 장치는 마스터 사용자에게 UI 등을 통해 요청 메시지 수신을 알리고 확인받는 과정이다.
-서버를 통한 확인 전달(Response Master User Confirmation to CPE through the Server): 서버를 통해 해당 게이트웨이에 마스터 사용자의 확인 사실을 응답하는 과정이다.
-서버를 통한 게이트웨이 식별자 및 로컬 망 정보 전송(Send CPE ID & Local Network Data to Master User Device through the Server): 응답을 수신한 게이트웨이는 마스터 사용자 장치로 서버를 통해 로컬 망과 관련된 자신의 식별자(ID, SSID, BSSID 등)를 전달하는 과정이다.
-마스터 사용자 장치 ACK(Master User Device Ack to CPE & Register): 로컬망 식별 정보를 전달받은 마스터 사용자 장치가 게이트웨이에 ACK을 전송하고 해당 정보를 저장하는 과정이다.
-게이트웨이의 마스터 사용자 장치 관련 정보 등록(CPE Registers Data relevant to the Master User Device): 마스터 사용자 장치로부터 ACK을 수신한 게이트웨이가 마스터 사용자 장치의 정보를 등록하는 과정이다.
여기서 일반적으로 마스터 사용자 장치는 마스터 사용자의 스마트폰이 될 수 있다.
도 23 및 도 24에는 로컬 사이트와 원격 사이트에서의 준비과정이 도시된다.
도 24에서는 도 23과 달리 발견 과정에서 기 설정된 시간이 경과(advertisement timeout)하면 백엔드 서버를 거쳐 메시지 교환이 수행된다는 차이점이 있다. 각 과정에 대한 설명은 도 22를 참조하여 이미 기술된 바, 명세서의 간명함을 위해 중복되는 설명은 생략하기로 한다.
도 25는 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 로컬/리모트 인지/전환 과정의 일례를 나타낸다.
먼저 도 25의 (a)를 참조하면, 리모트에서 로컬로의 천이 과정이 도시된다.
보다 상세히, 마스터 사용자 장치와 게이트웨이가 원격 모드로 동작한다(Remote Mode Running). 이때, 마스터 사용자 장치가 새로운 WiFi BSS에 접속(Join New BSS)하는 경우, 접속한 BSS가 마스터 사용자 장치와 게이트웨이 준비 과정에서 저장되어 있는 SSID 및 BSSID등의 확인을 통해 사용자의 홈(Home) BSS인지 체크하여(BSS is My Home BSS?) 아닐 경우 원격 모드로 계속 동작한다.
맞을 경우, 마스터 사용자 장치가 이더넷인 경우 로컬 발견(local discovery) 단계로 바로 진행한다(Ethernet Connection). SSDP, UPnP 또는 프라이빗한 발견 과정을 거쳐 마스터 사용자 장치와 게이트웨이 준비 과정에서 저장되어 있는 마스터 사용자 장치 및 게이트웨이 인지 확인한다(Local Discovery & Confirm). 아닐 경우 원격 모드가 유지된다. 발견 과정을 통해 서로 간에 저장된 기기인지 여부가 확인되면 마스터 사용자 장치와 게이트웨이는 로컬 모드로 전환될 수 있다(Auto Change to Local Mode Respectively). 그에 따라 각 장치는 로컬 모드로 동작할 수 있다(Local Mode Running). 이후 게이트웨이는 마스터 사용자 장치가 로컬에 있는지 체크하기 위해 주기적으로 체크 메시지를 보내고 ACK 메시지를 수신한다(Alive Check Periodically). 물론, 마스터 사용자 장치가 체크 메시지를 게이트웨이에 전송할 수도 있다.
다음으로 도 25의 (b)를 참조하면, 로컬에서 리모트로의 천이 과정이 도시된다.
보다 상세히, 마스터 사용자 장치와 게이트웨이가 로컬 모드로 동작한다(Local Mode Running). 이때, 25의 (a)에서와 같이 주기적 체크가 수행된다(Alive Check Periodically). 그에 따른 체크 메시지 수신에 실패하거나 ACK 메시지 수신에 실패하는 경우, 리모트 모드로 전환될 수 있다(Auto Change to Remote Mode if can’t find Peer during Specific Time). 그에 따라 리모트 모드에서 마스터 사용자 장치와 게이트웨이 간에 발견 및 확인 과정이 수행될 수 있다(Remote Discovery & Confirm). 확인 되면 리모트 모드로 동작할 수 있다(Remote Mode Running). 만일, 원격으로도 발견에 실패한 경우 로컬 및 원격 모두 연결이 안 되는 상태로 상호간의 연결이 해제될 수 있다(Disconnect). 차후 마스터 사용자 장치가 다시 연결 될 수 있는 상황이 되었는지 게이트웨이는 주기적으로 확인하거나 마스터 사용자 장치가 켜지는 경우 연결을 게이트웨이에 재요청할 수 있다. 이러한 연결 재요청은 항상 연결되어야 하는 어플리케이션 서비스가 있을 경우에만 수행될 수도 있다.
도 26은 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 초기 설정 과정에서 디바이스 어댑터가 미리 다운로드되는 경우의 일례를 나타낸다.
도 26을 참조하면(도 22와 중복되는 과정은 설명을 생략한다), 제품 구매 및 서버 등록(Device Purchase & Claiming) 이후, 서버는 등록된 정보를 바탕으로 해당 게이트웨이에 디바이스 어댑터를 전달하고, 게이트웨이는 이를 설치한다(Device adapter Download from Server to CPE). 이후 장치가 켜지면(Device ON), 구매한 장치가 Wi-Fi 또는 Ethernet 과 같이 IP 기반인지 여부를 판단한다(IP based Device or Not). IP 기반이면 IP 할당 단계로(Device IP Configuration if IP device), 아니면 장치-마스터 사용자 장치 준비(Device<->Master User Provisioning) 단계로 진행된다.
장치-마스터 사용자 장치 준비단계는, 장치를 실제 사용할 장소에 설치하고 이를 관리하고 컨트롤할 마스터 사용자 장치와 서로 간에 확인하고, 각 필요한 데이터를 각 장치에 저장하는 과정이다.
준비 단계의 상세 과정은 아래와 같다.
-Device<->CPE Discovery : SSDP, UPnP 또는 프라이빗 방법으로 게이트웨이와 장치간에 발견을 수행하는 과정이다.
-Local Link Creation : 발견 성공시 어플리케이션 간의 데이터 교환을 위해 로컬 링크를 형성하는 과정이다.
-Device Registration to CPE : 게이트웨이에 장치가 자신의 UUID 등을 전송하여 실제로 게이트웨이에 장치를 등록하는 과정이다.
-CPE Internet Connection State : CPE가 ethernet 또는 WiFi를 통해 인터넷에 연결될 수 있는 상황인지 판단하는 과정이다.
-Notify Master User Device about Device Registration by CPE : 게이트웨이는 장치가 등록됨을 기 설정된 마스터 사용자 장치에 통보한다. 본 과정은 로컬 망에 의해 통신이 이루어지는 상황이다.
-Master User Device UI : 앞서 통보 받은 메시지를 확인 하는 과정에서 마스터 사용자에게 사용자 인터페이스가 제공되는 과정이다.
-Device Config. & Register by Master User : 마스터 사용자는 실행된 사용자 인터페이스를 통해 새로 등록된 장치에 대한 이름, 위치 등과 같은 설정/속성 정보를 기록하여 마스터 사용자 장치에 저장하고 이를 message를 받은 경로에 맞게 로컬/원격을 통해 다시 게이트웨이에 전달하는 과정이다.
-CPE Register Device Configuration Data : 마스터 사용자에 의해 전달 받은 장치 설정 데이터가 게이트웨이에 저장되는 과정이다.
-Device Registration Report to Server : 게이트웨이가 인터넷 연결이 가능할 경우 서버를 통해 마스터 사용자에게 알리고, 설정받기 위해 서버로 신규 장치가 등록을 요청했음을 알리는 과정이다. 이때 신규 장치에 대한 UUID및 제품명 타입 등의 정보가 함께 전달될 수 있다.
-Notify Master User Device about Device Registration : 서버가 마스터 사용자 장치에 신규 장치 정보를 전달하며, 설정해줄 것을 요청하는 과정이다.
-Push Notification or e-mail : 마스터 사용자 장치가 이동 단말과 같이 알림 메시지(Notification message)를 받을 수 있는 경우 푸쉬 알림으로, 그렇지 않은 경우는 등록된 e-mail 로 요청이 전달될 수 있다.
이후 과정은 인터넷이 불가능한 경우 로컬로 진행되는 과정과 동일하므로 설명을 생략하기로 한다.
도 27은 본 발명의 일 실시예에 따른 마스터 사용자 장치와 게이트웨이의 초기 설정 과정에서 디바이스 어댑터가 나중에 다운로드되는 경우의 일례를 나타낸다.
도 26에 도시된 바와 같이 미리 디바이스 어댑터를 다운로드 받는 과정에서는 사용자가 서버에 신규 장치에 대한 등록(claim)을 바탕으로 게이트웨이에 미리 디바이스 어댑터를 받아놓고 장치를 설정하도록 하였다. 그런데, 도 27에 도시된 디바이스 어댑터를 나중에 다운로드 받는 과정은 장치 설정 과정 중에 장치가 필요로 하는 디바이스 어댑터를 요청하고 다운로드한다는 차이점이 있다. 본 방식은 장치의 획득방법에 구애받지 않는다는 장점이 있다.
도 26과의 차이를 위주로 설명하면, 다음과 같다.
- 장치 설정 이전에 장치를 위한 디바이스 어댑터를 게이트웨이에 설치할 것인가에 대해 로컬/원격 중 가능한 방법으로 마스터 사용자 장치를 통해 마스터 사용자에게 알리고, 사용자가 이를 확인 했음을 다시 게이트웨이에 알리는 과정이 추가된다.
-위 과정에서 마스터 사용자의 승낙이 있으면 게이트웨이는 신규 장치에서 제공 받은 정보를 바탕으로 호환 가능한 기존에 설치되어 있는 디바이스 어댑터가 있는지 여부를 체크하고, 없을 때 이를 서버로 요청한다.
이후 과정은 미리 다운받는 방식과 같기 때문에 중복되는 설명은 생략하기로 한다.
도 28은 본 발명의 일 실시예에 따른 디바이스 어댑터가 다운로드되는 과정의 일례를 나타낸다.
도 28을 참조하면, 게이트웨이가 인터넷 연결이 가능할 경우는 서버가 등록(claim)된 장치 항목으로부터 해당되는 디바이스 어댑터를 검색하여 게이트웨이쪽으로 전송할 수 있다. 또한, 게이트웨이가 먼저 신규 장치의 정보를 서버로 제공하여 해당되는 디바이스 어댑터가 전송되도록 할 수도 있다.
게이트웨이가 인터넷 연결이 불가한 경우, 기존과 같이 USB 등의 저장매체를 통해 설치할 수 있으며 다른 방법으로 테더링이 가능한 마스터 사용자 장치를 통한 요청이 사용될 수도 있다. 즉, 이미 연결되어 있는 로컬 망을 통해 마스터 사용자 장치의 WiFi 핫스팟(Hotspot)에 관련된 정보를 전달받고, 마스터 사용자 장치는 핫스팟을 활성화하여 서버로부터 디바이스 어댑터가 전송되도록 할 수도 있다.
한편, 스마트 홈 서비스를 위해 클라우드 서버와 게이트웨이가 연결되는 경우, 게이트웨이는 서비스를 이용하는 사용자 계정과 연계하여 서버에 등록되는 것이 바람직하다. 이하에서는 게이트웨이를 서버에 등록하는 과정에서 보안과 편의성을 위한 방법에 대해 기술한다. 이러한 방법은 게이트웨이 뿐만 아니라 스마트 홈 서비스에 참여하는 기기들의 서버 등록시에도 적용될 수 있음은 물론이다.
도 29는 본 발명의 일 실시예에 따른 사용자 기기와 게이트웨이 및 서버 간의 인증을 통한 등록 과정의 일례를 나타낸다.
서비스 제공자(Service Provider)가 제공한 오픈 API를 이용하는 어플리케이션을 사용하기 위해 사용되는 인증 표준의 하나로 OAuth 1.0a/2.0이 있다. 본 실시예에서는 이를 서버에 게이트웨이를 등록하기 위한 수단으로 사용할 것을 제안한다. 보다 구체적으로, 서버에는 인증을 해주기 위한 OAuth 기능이, 게이트웨이에는 인증을 받기 위한 OAuth 기능이 각각 적용될 수 있다. 게이트웨이에 디스플레이나 특정 목적의 키버튼이 구비되지 않은 형태라면, OAuth 의 3-legged model이 적용될 수 있으며, 어느 하나가 있는 형태라면 2-legged model도 적용될 수 있다.
3-legged model의 경우 PC 또는 스마트폰과 사용자 인터페이스를 제공하는 스마트 장치를 통해 사용자의 인증을 수행할 수 있는데, 이를 위해 게이트웨이와 스마트 장치를 이더넷, USB 등과 같은 유선 방식으로 연결할 수도 있고 WiFi와 같은 무선방식으로 연결할 수도 있다.
게이트웨이와 스마트 장치가 연결된 상태에서 게이트웨이는 OAuth 인증 후 등록 기능을 수행하기 위한 웹 서비스 페이지를 제공하고, 스마트 장치를 이용해 사용자 인증 및 OAuth 수행을 위한 사용자 인터페이스를 제공할 수 있다. 또한, 게이트웨이에는 OAuth 인증 후 게이트웨이 정보를 서버에 등록하기 위해 UUID 등의 관련 정보를 서버로 전달하는 기능을 수행하고 서버는 이를 위한 API를 제공할 수 있다. OAuth 인증이 된 후에는 사용자가 지정이 되어 있으므로 해당 사용자의 게이트웨이로 등록될 수 있다.
전술한 과정을 통해 서버의 특정 사용자 정보에 게이트웨이가 등록되면, 서버는 게이트웨이에 정상적으로 등록이 되었음을 알려 사용 가능 상태로 전환할 수 있도록 한다. 만일 게이트웨이의 웹 서비스가 등록을 위한 기능만 있을 경우, OAuth 인증시 발급되는 접속 토큰(Access token)의 만료시간(Expire time)을 수 분 정도로 짧게 주어 등록을 위한 웹 서비스의 생명주기를 짧게 하고, 웹 서비스가 이용할 수 있는 자원도 등록에 관련된 자원만 이용할 수 있도록 권한을 제한할 수 있다. 이를 통해 안전성이 향상될 수 있다.
도 30은 본 발명의 일 실시예에 따른 사용자 기기와 게이트웨이 및 서버 간의 등록에 게이트 웨이 키버튼이 사용되는 과정의 일례를 나타낸다.
보통 장치를 자신의 계정에 등록하기 위해서 서버에 로그인 후 UUID와 같은 장치의 고유 ID 등을 등록함에 있어, 등록하는 정보의 유출 우려가 있어 스마트 홈 서비스를 위한 게이트웨이와 같이 보안이 중요시 되는 장치의 경우 보다 강한 보안이 제공될 필요가 있다. 따라서, 도 30에서는 게이트웨이에 구비된 키버튼을 이용하여 로컬 여부 확인(locality check)과 특정 게이트웨이 선택 기능을 제공하여 보다 안전하게 등록하는 방안이 제공된다.
도 30을 참조하면, 먼저 스마트 기기로 사용자가 서버에 로그인한 후 게이트웨이 정보를 등록한다. 서버의 웹 페이지는 키버튼 기능을 수행하는 사용자 인터페이스가 제공되고, 사용자는 등록 후 웹패이지의 키버튼을 조작한다. 키버튼이 조작되면, 서버는 특정 타임아웃 주기동안 키버튼으로 트리거링되어 게이트웨이 등록 요청이 있는지 여부를 모니터링한다. 해당 시간 내에 게이트웨이를 등록하고자 하는 사용자는, 게이트웨이의 키버튼을 눌러 게이트웨이 등록을 요청할 수 있다. 여기서 타임아웃 시간은 가변적으로 결정될 수 있다. 키버튼이 눌린 게이트웨이는 등록을 요청하는 패킷 내에 등록 정보와 함께, 미리 약속된 필드로 키버튼으로 요청한다는 정보를 삽입하여 보낸다. 이때 게이트웨이의 키버튼은 물리적으로 구성되어 있을 수도 있고 소프트웨어로 구성될 수도 있다. 소프트웨어로 구성된 경우는 도 29의 경우와 같이 스마트 기기가 게이트웨이에 연결되고, 게이트웨이에서 제공되는 웹 사용자 인터페이스를 스마트 기기를 통해 사용자에게 보여질 수 있도록 구현될 수 있다. 서버에서는 모니터링 시간 동안 입력된 패킷의 정보가 사용자가 서버에 입력한 정보와 일치하는지 검사하고, 일치할 경우 해당 정보를 설정을 위해 사용자 정보에 갱신하고 게이트웨이로 확인 메시지를 전송한다. 그에 따라 게이트웨이는 활성 상태로 전환될 수 있다.
도 31은 본 발명의 일 실시예에 따른 사용자 기기와 게이트웨이 및 서버 간의 등록에 사용자 계정이 사용되는 과정의 일례를 나타낸다.
도 31을 참조하면, 스마트 기기와 게이트웨이가 유/무선으로 연결된 후 서버에서 사용되는 사용자 계정의 ID와 Password가 게이트웨이에 전달될 수 있다. 게이트웨이는 전달 받은 ID/Password를 통해 서버에 로그인 하고 UUID 등의 게이트웨이 정보와 함께 게이트웨이 등록을 요청할 수 있다. 그에 따라 서버는 사용자 정보에 해당 게이트웨이 정보를 등록할 수 있으며, 확인 메시지를 게이트웨이에 전송할 수 있다. 확인 메시지를 수신한 게이트웨이는 서버에서 로그아웃 후 활성화될 수 있다.
이하에서는 도 32 및 도 33을 참조하여 게이트웨이에서 사라진 기기를 관리하는 과정을 설명한다.
도 32 및 도 33에 도시된 각 과정에 대한 상세한 설명은 아래와 같다.
-Device Alive Check Periodically by CPE : 게이트웨이에서 장치가 제대로 동작하고 있는지 주기적으로 확인하는 과정이다.
-If No Response Time > Disappear Threshold Time : 앞의 주기적 확인 과정 중 장치가 응답을 하지 않는 시간이 정해진 문턱값을 넘었는지 판단하는 과정이다.이때 문턱값은 장치별로 다르게 설정될 수 있다.
-Report Disappeared Device to the Master User Device : 게이트웨이는 해당 문턱값을 넘은 장치가 발생한 경우 마스터 사용자에 이를 알리기 위해 등록되어 있는 마스터 사용자 기기에 해당 사실을 보고한다.
-Pop up UI on the Master User Device : 마스터 사용자 기기에서는 사용자 인터페이스를 통해 사라진 기기가 있음을 마스터 사용자에게 알릴 수 있다.
-Master User Decision : 마스터 사용자는 보고받은 장치 정보를 바탕으로 실제로 사용하지 않고 없어진 장치라면 제거를, 사용하는데 오랜 동안 켜지 않고 방치한 것이라면 판단에 의해 유지/제거를, 사용하고 있다고 생각하는 장치라면 해당 장치를 물리적으로 확인할 수 있다. 마스터 사용자의 결정에 대응되는 메시지가 마스터 사용자 기기에서 게이트웨이로 전송될 수 있으며, 게이트웨이는 메시지 내용에 따른 동작을 수행할 수 있다.
동작 상태 정의
한편, 본 발명의 일 실시예에서는 게이트웨이에 연결된 기기들의 동작 상황 및 사용자의 로컬/원격 여부에 따라 상태(State)를 정의해서 게이트웨이나 서버가 이러한 상태에 따른 관리를 수행하도록 할 것을 제안한다. 이를 통해 위급 상황에 대한 대응과 에너지 절감, 신호 간섭 저하, 편리성 등이 제공될 수 있다.
먼저 액티브 상태를 설명한다.
액티브 상태란, 장치가 동작 중인 상태를 의미하며, 액티브 상태(Active state)는 로컬 액티브와 원격 액티브로 구분될 수 있다.
게이트웨이 또는 서버가 장치로 명령을 보내거나, 장치로부터 동작에 대한 이벤트를 수신하는 상황 및 명령/이벤트 발새에 의해 기대되는 장치의 동작 시간으로 액티브 상태를 알 수 있다.
로컬 및 원격의 구분 기준은 명령 및 이벤트의 전달 경로가 로컬 영역에서인지 원격 영역에서인지에 따라 구분될 수 있다. 보조적으로 사용자의 마스터 사용자 기기가 로컬에서 발견되었는지 여부 및 상황 인식(context aware)/ 모션 센싱( motion sensing) 등으로 사용자가 집안에 있는지 여부가 추가로 판단될 수도 있다
동작 측면에서, 로컬 액티브 상태에서는 사용자가 기기에서 지원되는 모든 기능의 사용이 가능한다. 리모트 액티브 상태의 경우 장치의 기능이 제한적으로 사용될 수 있다. 제한된 기능은 장치 제조사에 의해 미리 선정될 수 있다. 예를 들어 오븐의 조리 개시와 같이 원격에서 지원 시 위험할 수 있는 기능에 대해서는 로컬에서만 가능하도록 미리 설정 가능하다.
다음으로 파크 상태(Parked State)를 설명한다.
파크 상태는 보안, 안전과 관계된 장치나 항상 켜져있는 장치를 제외한 장치에 동작 변화가 없고, 동작하기 위한 스케쥴도 없는 상태가 지속될 것이 확실한 상태를 의미할 수 있다.
이러한 상태를 결정하는 방법은 사용자가 집안에 없다고 판단된 상황 또는 장치의 동작 상태에 상관 없이 사용자에 의해서 해당 상태로 진입하라는 명령이 내려진 경우 등이 될 수 있다. 사용자의 위치 판단은 액티브 상태에서 상술한 바와 같다.
동작 측면에서, 파크 상태에서는 게이트웨이나 서버의 명령에 의해 보안/안전에 관계된 장치 및 서비스가 활성화되고, 항상 켜져있는 장치를 제외한 장치들의 전원이 꺼지게 된다. 이때, 항상 켜져있는 장치도 에너지 절약기능이 활성화될 수 있다. 본 상태에서 다른 상태로 천이하는 경우, 리텐션(retention)을 위해 본 상태로 진입 전의 동작 상황에 대한 메타데이터가 미리 저장되는 것이 바람직하다.
다음으로 슬립 상태를 설명한다.
슬립 상태는 보안, 안전과 관계된 장치나 항상 켜져있는 장치를 제외한 장치가 일정 시간 이상 계속하여 동작하지 않는 상황에서 집안에 유저가 있는지 불확실한 경우의 상태를 의미할 수 있다.
동작 측면에서, 슬립 상태에서는 게이트웨이나 서버의 명령에 의해 보안/안전에 관계된 장치를 제외한 장치들에 슬립 알림이 전달된다. 슬립 알림이 전달되는 경우, 주기적 동작을 수행하는 기기는 해당 주기를 보다 길게 변경할 수 있다. 또한, 슬립 알림을 수신한 항상 켜져있는 장치는, 에너지 절약 기능이 있을 경우 활성화될 수도 있다.
다음으로 비상 상태를 설명한다.
비상 상태는 보안, 안전과 관계된 장치나 서비스에 의해 이벤트 발생이 감지된 상태를 의미할 수 있다.
동작 측면에서, 게이트웨이나 서버의 명령에 따라 비상 알림을 수신한 각 장치는 수행 중인 동작을 정지하고 미리 설정된 비상 동작을 수행할 수 있다. 이를 통해 사용자에게는 즉각적인 상황에 대한 보고를 보내고 침입자 또는 주변인에게는 경고의 메시지를 보낼 수 있다.
상술한 네 상태의 관계가 도 34에 도시된다.
도 34에서는, 각 상태 간 천이 방법 및 조건이 화살표 방향에 표시되어 있다. 상태도(State diagram) 안에 작원 원형 영역은 집안에서 실행되는 서비스들을 카테고리화하여 각 서비스 카테고리가 어느 상태에서 동작하는지를 나타낸다. 물론, 이러한 서비스들은 집안에 설치된 장치에 따라 변경될 수 있다. 또한, 보안/안전 및 항상 동작하는 장치/서비스들은 모든 상태에서 항시 동작하는 것으로 나타나 있다. 한편, 슬립과 파크 상태는 에너지 절약과 간섭 저감(interference reduction)에 기여하고 있으며, 비상 모드 서비스는 비상 상태에서 동작하며 다른 모든 동작보다 높은 우선권을 갖고 정해진 서비스를 수행할 수 있다.
상술한 상태에 대한 관리 서비스는 시스템 서비스 레이어에 포함될 수 있다.
제조사 특정 기능의 지원
다양한 제조사의 기기가 게이트웨이를 통해 서비스되기 위해서는 동일군의 기기간에는 공통으로 사용될 수 있는 명령 언어가 필요하다. 이러한 공통언어로 표현된 명령은 시맨틱(semantic)이라 칭할 수 있다. 이러한 시맨틱은 전술한 메타정보 관리 트리에서 기능(function) 항목에 대응될 수 있는데, 시맨틱에 대한 기능사항이 정의되고 표준화 되어야 제조사에 관계 없이 게이트웨이를 통한 제어가 가능할 수 있다. 그러나 수많은 제조사의 기기들은 이런 표준화된 시맨틱만으로 제공할 수 있는 기능에는 한계가 있다.
보다 상세히, 제조사 특정 시맨틱은 제조사 별로 표준화 될 수 없는 기능들을 표현하기 위한 시맨틱으로 B2B로 미리 정의된 기능을 토대로 어플리케이션 서비스를 구성하여 사용할 수도 있으나, 서드파티(3rd Party) 또는 기 설치 서비스(pre-installed service)의 경우 이를 사용하는 방법에 대해서 알 수 없기 때문에 이러한 시맨틱의 사용 방법을 표현하는 방식과, 시맨틱에서 지시되는 기능을 사용을 위한 인터페이스에 대한 정의가 필요하다.
일반적으로 표준으로 정의될 수 있는 표준 시맨틱만으로는 장치의 다양한 기능을 이용하는데 한계가 있다. 예를 들어, 에어컨의 동작 모드에서는 대부분의 에어컨이 지원하는 냉방/제습 기능이나 송풍 모드에서 바람 강도 정도만 표준화가 가능하다. 따라서 제조사별 특징적인 기능인 풀파워 모드나 모션 감지 냉방, 절전 모드 등을 등을 지원하기에는 부족하다.
더욱이 스마트 홈 서비스를 이미 이용하는 로컬에서 장치가 변경되는 경우 이를 지원하기란 표준 시맨틱으로는 어렵다. 일반적으로 이러한 세부적인 기능까지 이용하기 위해서는 새로운 어플리케이션을 설치하는 과정이 필요하고, 통합 사용자 인터페이스로 사용하기도 어려움이 있다. 또한 제조사가 다양하고 제품이 다양한 환경 속에서는 더 많은 혼란이 야기된다.
에어컨의 경우만 예시로 설명하였으나, 스마트 홈 서비스나 마스터 사용자 기기의 어플리케이션이 여러 종류의 장치와 연동되는 경우 이러한 문제는 더욱 가중되어 사용자에게 일원화된 사용자 인터페이스가 제공되기 어렵다.
따라서, 본 실시예에서는 표준화를 위한 시맨틱의 분류 체계와, 표준화가 어려운 제조사 특정 기능(Vendor Specific Semantic)을 기술하고 이용가능하게 하는 방안을 제안한다.
원격 제어 환경을 지원하기 위해서는 클라우드와의 연동이 바람직하며 다양한 연결성을 갖는 여러 제조사의 장치와 연동하기 위해서는 게이트웨이가 필요하다. 이러한 아키텍쳐 상에서 장치들은 게이트웨이의 어플리케이션과 제어 장치(예를 들어, 마스터 사용자 기기)에 의해 제어되고 장치 상호간 연동이 가능해 진다.
시맨틱(Semantic)은 전술한 바와 같이 다양한 제조사의 기기가 게이트웨이를 통해 서비스 되기 위해, 동일군의 기기간에 공통으로 이해될 수 있는 명령을 정의해 API 형태로 구성될 수 있으며, 미들웨어 계층에서 관리될 수 있다. 이하에서 설명되는 실시예에서는 시맨틱에 대한 분류 체계와 제조사 특정 시맨틱을 기술(description)하는 방법을 설명한다.
먼저 시맨틱 분류 체계를 설명한다.
장치 동작을 표현하기 위한 시맨틱을 정의하는 방식은 다양하다. 시맨틱은 센서 및 구동기(Sensor & Actuator) 형태로 정의할 수도 있고 유사성질을 분류하여 정의할 수도 있다. 예를 들면 에어컨의 온도 설정과 냉장고의 온도 설정을 위한 시맨틱을 동일한 시맨틱으로 분류하는 것이다.
본 실시예에 의하면, 시맨틱은 인트린식(Intrinsic), 행위(Behavior), 제조사 특정(Vendor Sepecific)으로 분류될 수 있다.
인트린식은 기기 고유의 기능에 따라 분류될 수 있다. 인트린식의 기본(Basic) TV 시맨틱은 채널 전환, 볼륨 조절 등과 같이 TV가 갖는 필수적인 기능의 정의가 되고 에어컨 시맨틱의 경우는 동작 설정, 풍향 설정과 같은 에어컨이 갖는 필수적인 기능이 정의되어 있다. 이런 분류 체계는 장치가 지원하는 시맨틱에 대한 정보만으로 장치의 기본적인 속성과 제어 가능한 기본 기능을 직관적으로 알 수 있게 해 준다.
행위(Behavior)는 기기가 갖는 부가적인 기능을 이용하여 발생할 수 있는 기능이다. 예를 들어 감지(Sensible) 시맨틱의 경우 동작, 소리, 시각 등의 센서 기능을 뜻하며 어플리케이션에서는 감지 시맨틱을 지원하는 장치를 찾아 일괄적으로 감지 기능을 실행 시키거나 특정 장치를 선택하여 감지 기능을 실행하여 특정 정보를 얻어 올 수 있게 할 수 있다. 에너지 관리(Energy Manageable) 시맨틱의 경우 에너지 절약 기능이 있는 장치를 찾아 이를 활성화 하여 에너지 절감을 도모할 수 있다. 결국, 본 시맨틱은 장치가 갖는 기본적이고 직관적인 기능 외에 기기간, 기기와 사람간의 연동을 필요로 하는 요소들로 볼 수 있다.
제조사 특정 시맨틱은 제조사 별로 기능이 달라 표준화 되기 힘든 기능들을 표현한다.
도 35는 장치별 시맨틱 구성의 일례를 나타낸다.
도 35를 참조하면, 장치별 시맨틱은 복합적으로 구성될 수 있으며, 이를 통해 직관적으로 장치의 특성을 알 수 있다. 구체적으로, 도 35에서는 인트린식, 행위, 제조사 특정 시맨틱들을 이용하여 장치 모델을 생성하는 예로 High-end TV의 경우 보다 다양한 시맨틱들을 제공할 수 있으며 Simple TV의 경우 보다 적은 시맨틱 만을 지원하는 형태로도 모델링이 가능하다. 어플리케이션 서비스는 메타정조 관리 트리를 이용하여 이러한 관계도를 추출할 수 있어 장치 모델 별로 사용 가능한 시맨틱을 알 수 있다.
도 36은 본 발명의 일 실시예에 따른 제조사 특정 시맨택을 구성하는 과정의 일례를 나타낸다.
각 과정에 대한 상세한 설명은 아래와 같다.
① 장치 A(device A)라는 인스턴스(instance)가 인스턴스 관리 모듈에게 ID등 자신의 식별 정보를 보내 바인딩(binding)이 수행될 수 있다. 여기서 인스턴스란 객체 지향 프로그래밍에서 특정 객체에 할당된 자원을 의미할 수 있다.
② 인스턴스 관리 모듈은 장치 A 인스턴스(device A instance)로부터 받은 정보를 바탕으로 메타 정보 관리의 체계에 맞게 정보를 입력한다.
③ 어플리케이션 서비스는 장치 리스트 및 식별자를 읽어들여 특정 장치가 지원하는 시맨틱 리스트 및 식별자를 얻어 오거나 특정 시맨틱을 지원하는 장치 리스트 및 식별자를 읽어오는 방식으로 장치와e와 시맨틱의 관계를 알 수 있다. 여기서는 장치 A가 지원하는 시맨틱 리스트 및 식별자를 요청하는 과정이 도시되어 있다.
③-1은 장치 인스턴스의 시맨틱에 업데이트가 있을 경우 메타정보 관리에서 이벤트 알림을 전송하는 과정(즉, 동적 업데이트)이다.
④ 장치 A가 지원하는 시맨틱 리스트 및 식별자가 어플리케이션 서비스에 전달될 수 있다.
⑤ 앞의 절차를 통해 장치 식별자나 시맨틱 식별자 등을 이용하여, 어플리케이션 서비스는 실제 사용을 희망하는 장치 A 인스턴스의 주소를 인스턴스 관리에 요청할 수 있다.
⑥ 인스턴스 관리는 어플리케이션 서비스의 요청에 따라 해당 인스턴스의 주소를 알려줄 수 있다.
⑦ 표준화 된 시맨틱의 경우 앞의 과정을 바탕으로 어플리케이션 서비스는 장치 A 인스턴스와 시맨틱 API를 통해 명령를 주고 받을 수 있게 된다. 하지만 현 단계에서는 앞의 과정 중 가져온 제조사 특정 시맨틱의 경우 B2B로 합의된 내용이 아닐 경우 블랙박스(black-box) 형태로 제조사 특정 시맨틱이 있다는 것만 알고 내용에 대해서는 아직 알 수 없다. 따라서 제조사 특정 시맨틱이 있을 경우 이를 제조사 특정 시맨틱 API를 통해 기능 사항에 대한 정보를 요청해야 한다. 제조사 특정 시맨틱 API는 의사 코드(pseudo code)형태의 의미론적으로 보면 다음과 같은 1개 또는 2개의 코드를 사용하는 방법이 제공될 수 있다.
1개의 경우: X vendorSpecificFunction(A, B, C); 여기서 A는 겟 함수(get function)인지 셋 함수(set function)인지 여부를 나타내며, B는 해당 자원의 경로(resource path)이다. C는 A가 셋 함수로 선택 될 경우 해당 자원별 인자를 위한 객체(object)가 해당된다. X는 void 또는 객체 형태가 될 수 있다.
2개의 경우 : X getVendorSpecificFunctionDescription(A); 여기서 A는 자원 경로, X는 객체이다.
X setVendorSpecificFunction(A,B); 여기서 A 는 자원 경로, B는 해당 자원별 인자를 위한 객체, X는 void 또는 객체 형태가 될 수 있다.
⑧ 앞의 ⑦단계에서 제조사 특정 시맨틱을 위한 기술(description)이 요청되면 해당 자원에 대한 기술(description)이 리턴될 수 있다.
⑨ 앞의 ⑧단계에서 얻은 제조사 특정 시맨틱 기술(description)을 이용하여 명령(command)이 실행될 수 있다.
제조사 특정 시맨틱의 description에 대해서 원활히 이해하기 위해서는 미리 설정된 규칙이 있어야 가능하다.
도 37은 본 발명의 일 실시예에 따른 제조사 특정 시맨틱 기술 구조의 일례를 나타낸다.
도 37에서는 기술 구조(description structure)와 포맷(format)에 대한 도식으로, 상위 기능(function)에서 하위 기능으로 그리고 기능 별로 인풋/아웃풋이 있다면 이에 대한 기술을 URI(uniform resource identifier)기반의 방식처럼 자원에 대한 경로를 관리하며 기술(description)이 구성되는 형태가 도시된다.
각 기술별 예약어 및 그에 대한 설명은 다음과 같다.
먼저, 기능 기술 포맷(Function Description Format)을 설명한다.
-Name : 기술 전체에 대한 명칭이다.
-Version : 버전을 의미하며, 자원 당 관리 가능한 체계를 따르면 된다. 예로 0.0.X 형태를 들 수 있다.
-Href : 본 기술 자원(description resource)의 경로를 지시한다.
-Functions : 기술 내의 기능들을 어레이(array) 형태로 관리하기 위한 예약어이다.
-functionName : 기능의 명칭이다.
-relativeTo : 기능이 표준 시맨틱과 연관이 있을 경우 해당 표준 시맨틱의 경로를 지시한다. 이는 표준 시맨틱의 속성(attribute)을 확장하는데 용이하다.
-subFunctionHref : 서브 기능(sub-function)이 있을 경우 경로를 표기하며 URI 처럼 ~/functionName/subFunction 으로 표기한다.
-inputVariableHref : 기능에 대한 인풋이 있을 경우 경로를 표기하며 URI구조처럼 ~/functionName/inputVariable 으로 표기한다.
-outputVariableHref : 기능에 대한 아웃풋이 있을 경우 경로를 표기하며 URI구조처럼 ~/functionName/outputVariable으로 표기한다.
-functionDescription : 자연어 처리에 의한 기기간 동작 및 사용자에게 기능에 대한 설명을 하는데 이용될 수 있다.
다음으로 입출력 기술 포맷(Input/Output Description Format)을 설명한다. 입출력 기술 포맷은 상술한 기능 기술(Function Description)에 inputVariableHref, outputVariableHref 이 있을 경우 적용될 수 있다.
-href : 본 기술 자원의 경로를 지시한다.
-variables : 기술 내의 변수(variable)들을 어레이(array) 형태로 관리하기 위한 예약어이다.
-varName : 변수 명칭이다.
-varType : 변수의 타입으로, boolean, index, range, message 형으로 나눌 수 있다. boolean과 message형일 경우는 자동으로 bool과 string형으로 해석된다. variable type에 의해 user interface를 표현하는데 유용한 정보를 제공할 수 있다.
-varAttributeMin : varType이 레인지(range)형일 경우 최소값을 표시한다.
-varAttributeMax : varType이 레인지(range)형일 경우 최대값을 표시한다.
-varAttributeIndex : varType이 인덱스(index) 형일 경우 스트링 어레이(string array)로 표시한다.
-varDescription : 자연어 처리에 의한 기기간 동작 및 사용자에게 기능에 대한 설명을 하는데 이용될 수 있다.
도 38 및 도 39는 본 발명의 일 실시예에 따른 게이트웨이에서 제조사 특정 시맨틱 기술이 해석되는 형태의 일례를 각각 나타낸다.
어플리케이션 서비스가 도 36의 과정을 통해 제조사 특정 시맨틱의 유무를 확인하고, 기술(description)을 읽어와 해석(interpret)하면 도 38과 같은 구조가 도출될 수 있으며, 이를 통해 표준 시맨틱과 연관이 있을 경우 연관관계가 추적될 수 있다. 예를 들어, 제조사 특정 기능 1(VS function 1)은 기존의 표준 시맨틱 1의 제 2 기능에 맵핑될 수 있고, 제조사 특정 기능 2(VS function 1)은 표준 시맨틱 3에 각각 맵핑될 수 있다.
어플리케이션 서비스가 도 38의 과정을 거치고 나면 도 39와 같이 장치를 표준 시맨틱과 제조사 특정 시맨틱을 통일화 하여 사용할 수 있도록 할 수 있다.
이를 통해 제조사 특정 시맨틱의 기능이 표준 기능의 확장일 경우 해당 사용자 인터페이스의 확장으로 신규일 경우는 신규 사용자 인터페이스로 제공될도 있다. 또한, 제조사 특정 시맨틱의 경우 어플리케이션 서비스가 해당 기능의 의미에 대해서 모른다고 해도 사용자 인터페이스 상의 표현을 통해 사용자는 그 의미를 알 수 있으므로 사용자 측면에서 유의미한 가치를 제공할 수 있다.
도 40은 본 발명의 일 실시예에 따른 제조사 특정 시맨틱 기술이 해석됨에 따라 사용자에게 제공될 수 있는 사용자 인터페이스의 일례를 나타낸다.
앞서 설명한 제조사 특정 시맨틱 기술을 통하여 메타정보 관리 트리가 재구성되면, 도 40과 같이 표준이 아닌 제조사 개별적인 기능까지 UI로 제공할 수 있게 된다. 또한 이는 제품을 선택하는 것에 의해서 동적으로도 변경 가능하다.
다양한 device에 이와 같은 기술을 적용하면 일관된 UI를 제공할 수 있어 사용자에게 편의를 제공할 수 있으며 향후 자연어 인식이나 텍스트 해석(interpret) 기술과 접목 시 기기와 사람간, 또는 기기와 기기간에도 보다 다양한 기능이 제공될 수 있다.
이하에서는 상술한 기능을 수행할 수 있는 게이트웨이의 기구적 구성을 도 41을 참조하여 설명한다.
도 41은 본 발명의 실시예들에 적용될 수 있는 게이트웨이의 블럭 구성도의 일례를 나타낸다.
상기 게이트웨이(100)는 무선 통신부(110), 사용자 입력부(120), 출력부(150), 인터페이스부(160), 메모리(170), 제어부(180) 및 전원 공급부(190) 등을 포함할 수 있다. 도 41에 도시된 구성요소들은 게이트웨이를 구현하는데 있어서 필수적인 것은 아니어서, 본 명세서 상에서 설명되는 게이트웨이는 위에서 열거된 구성요소들 보다 많거나, 또는 적은 구성요소들을 가질 수 있다.
보다 구체적으로, 상기 구성요소들 중 무선 통신부(110)는, 게이트웨이(100)와 외부장치, 게이트웨이(100)와 다른 게이트웨이(100) 사이, 또는 게이트웨이(100)와 다른 게이트웨이(100, 또는 외부서버)가 위치한 네트워크 사이의 무선 통신을 가능하게 하는 하나 이상의 모듈을 포함할 수 있다.
이러한 무선 통신부(110)는, 방송 수신 모듈(111), 이동통신 모듈(112), 무선 인터넷 모듈(113), 근거리 통신 모듈(114), 위치정보 모듈(115) 중 적어도 하나를 포함할 수 있다.
사용자 입력부(120)는 사용자로부터 제어 명령을 입력받기 위한 터치키(touch key), 푸시키(mechanical key) 등을 포함할 수 있다.
출력부(150)는 시각, 청각 또는 촉각 등과 관련된 출력을 발생시키기 위한 것으로, 디스플레이부(151), 음향 출력부(152), 광 출력부(153) 중 적어도 하나를 포함할 수 있다. 디스플레이부(151)는 터치 센서와 상호 레이어 구조를 이루거나 일체형으로 형성됨으로써, 터치 스크린을 구현할 수 있다. 이러한 터치 스크린은, 게이트웨이(100)와 사용자 사이의 입력 인터페이스를 제공하는 사용자 입력부(123)로써 기능함과 동시에, 게이트웨이(100)와 사용자 사이의 출력 인터페이스를 제공할 수 있다.
인터페이스부(160)는 게이트웨이(100)에 연결되는 다양한 종류의 외부 장치와의 통로 역할을 수행한다. 이러한 인터페이스부(160)는, 유/무선 헤드셋 포트(port), 외부 충전기 포트(port), 유/무선 데이터 포트(port), 메모리 카드(memory card) 포트, 식별 모듈이 구비된 장치를 연결하는 포트(port), 오디오 I/O(Input/Output) 포트(port), 비디오 I/O(Input/Output) 포트(port), 이어폰 포트(port) 중 적어도 하나를 포함할 수 있다. 게이트웨이(100)에서는, 상기 인터페이스부(160)에 외부 장치가 연결되는 것에 대응하여, 연결된 외부 장치와 관련된 적절할 제어를 수행할 수 있다.
메모리(170)는 게이트웨이(100)에서 구동되는 다수의 응용 프로그램(application program 또는 애플리케이션(application)), 게이트웨이(100)의 동작을 위한 데이터들, 명령어들 및 상술한 메타정보 관리 트리를 저장할 수 있다. 이러한 응용 프로그램 중 적어도 일부는, 무선 통신을 통해 외부 서버로부터 다운로드 될 수 있다. 또한 이러한 응용 프로그램 중 다른 적어도 일부는, 게이트웨이(100)의 기본적인 기능(예를 들어, 외부 장치와의 유/무선 연결성 제공, 주변의 연결 가능한 장치 탐지 및 등록)을 위하여 출고 당시부터 게이트웨이(100)상에 존재할 수 있다. 한편, 응용 프로그램은, 메모리(170)에 저장되고, 게이트웨이(100) 상에 설치되어, 제어부(180)에 의하여 상기 게이트웨이의 동작(또는 기능)을 수행하도록 구동될 수 있다.
제어부(180)는 상기 응용 프로그램과 관련된 동작 외에도, 통상적으로 게이트웨이(100)의 전반적인 동작을 제어한다. 제어부(180)는 위에서 살펴본 구성요소들을 통해 입력 또는 출력되는 신호, 데이터, 메타정보 관리 트리의 항목 등을 처리하거나 메모리(170)에 저장된 응용 프로그램을 구동함으로써, 사용자에게 적절한 정보 또는 기능을 제공 또는 처리할 수 있다.
또한, 제어부(180)는 메모리(170)에 저장된 응용 프로그램을 구동하기 위하여, 도 41과 함께 살펴본 구성요소들 중 적어도 일부를 제어할 수 있다. 나아가, 제어부(180)는 상기 응용 프로그램의 구동을 위하여, 게이트웨이(100)에 포함된 구성요소들 중 적어도 둘 이상을 서로 조합하여 동작시킬 수 있다.
구체적으로, 제어부(180)는 외부장치와 무선통신부(110) 또는 인터페이스부(160)를 통해 데이터 경로를 설립하고, 이를 통하여 외부장치가 연결된 경우 소정의 등록절차에 따라 외부 장치의 정보를 읽어와 메모리(170)의 메타정보 관리 트리에 등록할 수 있다. 이후 외부 장치로부터 서비스 요청 메시지가 전달되면 해당 서비스의 수행에 필요한 정보를 메타정보 관리 트리로부터 획득하고, 필요한 절차(예를 들어, 상술한 충돌 해결 절차, 사용자 위치 탐지에 따른 다른 게이트웨이와의 연동 동작 등)가 수행되도록 할 수 있다.
또한, 제어부(180)는 외부 장치들로부터 실행중인 서비스에 대한 메타 정보를 보고 받고, 다른 외부 장치가 켜지면 켜진 외부 장치로 실행중인 서비스를 전환할 수 있는지 여부를 판단하고, 전환 가능한 서비스에 대한 정보를 켜진 외부 장치로 전달할 수 있다. 이후 사용자의 명령 입력에 따라 특정 서비스가 실행되는 장치가 변경되도록 제어할 수 있다. 여기서 장치가 새로이 켜졌는지 여부는 사용자의 위치 이동 여부를 판단할 수 있는 다른 정보에 의해 대체될 수 있음은 상술한 바와 같다.
아울러, 제어부(180)는 전술한 제조사 특정 시맨틱을 기존의 메타 정보 관리 트리에 맵핑시키고, 이를 이용하여 제조사 특정 시맨틱을 사용자가 편리하게 접근하고 제어하도록 할 수 있다.
전원공급부(190)는 제어부(180)의 제어 하에서, 외부의 전원, 내부의 전원을 인가 받아 게이트웨이(100)에 포함된 각 구성요소들에 전원을 공급한다. 이러한 전원공급부(190)는 배터리를 포함할 수도 있다.
한편, 무선통신부(110)와 인터페이스부(160)는 외부 장치와의 데이터 경로를 제공하는 공통의 목적으로 사용될 때 "통신부"라 통칭할 수 있다.
상기 각 구성요소들 중 적어도 일부는, 이하에서 설명되는 다양한 실시 예들에 따른 게이트웨이의 동작, 제어, 또는 제어방법을 구현하기 위하여 서로 협력하여 동작할 수 있다. 또한, 상기 게이트웨이의 동작, 제어, 또는 제어방법은 상기 메모리(170)에 저장된 적어도 하나의 응용 프로그램의 구동에 의하여 게이트웨이 상에서 구현될 수 있다.
본 발명은 본 발명의 정신 및 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다.
또한, 전술한 본 발명은, 프로그램이 기록된 매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 매체는, 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 매체의 예로는, ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있으며, 또한 캐리어 웨이브(예를 들어, 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한, 상기 컴퓨터는 단말기의 제어부(180)를 포함할 수도 있다.
따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
본 발명은 스마트 홈 서비스를 구성함에 있어 각 장치들을 연결하고 제어하는 게이트웨이에 적용할 수 있다. 본 발명에 따른 게이트웨이는 댁내는 물론 원격에서도 동작될 수 있음은 물론이다.

Claims (20)

  1. 적어도 하나의 외부 장치와 유/무선으로 신호를 교환하기 위한 통신부; 및
    제 1 장치 및 제 2 장치가 참여하는 적어도 하나의 서비스에 대한 메타 정보를 포함하는 제 1 보고가 상기 제 1 장치로부터 수신되고, 제 3 장치로부터 상기 제 3 장치의 상태에 대한 제 2 보고가 수신되면, 상기 적어도 하나의 서비스 중 상기 제 3 장치가 참여할 수 있는 서비스의 메타 정보가 상기 제 3 장치로 전송되도록 하고, 상기 제 3 장치로부터 상기 제 3 장치가 참여할 수 있는 서비스 중 특정 서비스에 참여를 요청하는 변경 요청이 수신되면, 상기 제 1 장치 및 상기 제 2 장치 중 적어도 하나로 변경 명령이 전송되도록 제어하는 제어부를 포함하되,
    상기 제 3 장치가 참여할 수 있는 서비스의 메타 정보는,
    연결 명, 연결 서비스 카테고리, 채널, 서비스 컨텐츠, 장치 타입, 장치 주소 및 장치 역할 중 적어도 하나를 포함하고,
    상기 제어부는,
    상기 장치 타입, 상기 장치 주소 및 상기 장치 역할을 기 설정된 구조의 트리로 관리하며,
    상기 트리는 미들웨어 플랫폼 계층에서 관리되고 서비스 계층에서 참조되는, 게이트웨이.
  2. 제 1항에 있어서,
    상기 제 1 장치로 상기 변경 명령이 전송되는 경우,
    상기 변경 명령은 상기 제 3 장치의 메타 정보를 포함하는, 게이트웨이.
  3. 제 2항에 있어서,
    상기 제 3 장치의 메타 정보는,
    상기 제 3 장치의 연결 명, 연결 서비스 카테고리, 장치 주소 중 적어도 하나를 포함하는, 게이트웨이.
  4. 제 2항에 있어서,
    상기 변경 명령은,
    상기 제 1 장치에 상기 제 2 장치의 역할을 상기 제 3 장치로 변경할 것을 지시하는, 게이트웨이.
  5. 제 4항에 있어서,
    상기 특정 서비스에 제 4 장치가 더 참여하고, 상기 제 4 장치가 상기 제 2 장치에만 연결된 경우,
    상기 제어부는,
    상기 제 3 장치에 상기 제 4 장치와 연결할 것을 지시하는, 게이트웨이.
  6. 제 1항에 있어서,
    상기 제 2 보고는,
    상기 제 3 장치의 파워 온 상태를 지시하는, 게이트웨이.
  7. 제 1항에 있어서,
    상기 제 2 장치로 상기 변경 명령이 전송되는 경우,
    상기 변경 명령은 파워 오프 명령을 포함하는, 게이트웨이.
  8. 제 7항에 있어서,
    상기 제어부는,
    상기 제 1 장치로부터 상기 변경 명령에 따른 서비스 변경이 완료됨을 지시하는 제 3 보고가 수신되면 상기 변경 명령이 상기 제 2 장치로 전송되도록 제어하는, 게이트웨이.
  9. 게이트웨이의 제어방법에 있어서,
    제 1 장치 및 제 2 장치가 참여하는 적어도 하나의 서비스에 대한 메타 정보를 포함하는 제 1 보고를 상기 제 1 장치로부터 수신하는 단계;
    제 3 장치로부터 상기 제 3 장치의 상태에 대한 제 2 보고가 수신되면, 상기 제 3 장치로 상기 적어도 하나의 서비스 중 상기 제 3 장치가 참여할 수 있는 서비스의 메타 정보를 전송하는 단계; 및
    상기 제 3 장치로부터 상기 제 3 장치가 참여할 수 있는 서비스 중 특정 서비스에 대한 변경 요청이 수신되면, 상기 제 1 장치 및 상기 제 2 장치 중 적어도 하나로 변경 명령을 전송하는 단계를 포함하되,
    상기 제 3 장치가 참여할 수 있는 서비스의 메타 정보는,
    연결 명, 연결 서비스 카테고리, 채널, 서비스 컨텐츠, 장치 타입, 장치 주소 및 장치 역할 중 적어도 하나를 포함하고,
    상기 장치 타입, 상기 장치 주소 및 상기 장치 역할은 상기 게이트웨이에서 기 설정된 구조의 트리로 관리되며,
    상기 트리는 상기 게이트웨이의 미들웨어 플랫폼 계층에서 관리되고 서비스 계층에서 참조되는, 게이트웨이의 제어방법.
  10. 제 9항에 있어서,
    상기 변경 명령을 전송하는 단계는,
    상기 제 1 장치로 상기 제 3 장치의 메타 정보를 포함하는 변경 명령을 전송하는 단계를 포함하는, 게이트웨이의 제어방법.
  11. 제 10항에 있어서,
    상기 제 3 장치의 메타 정보는,
    상기 제 3 장치의 연결 명, 연결 서비스 카테고리, 장치 주소 중 적어도 하나를 포함하는, 게이트웨이의 제어방법.
  12. 제 9항에 있어서,
    상기 변경 명령을 전송하는 단계는,
    상기 제 2 장치로 파워 오프 명령을 전송하는 단계를 더 포함하는, 게이트웨이의 제어방법.
  13. 제 12항에 있어서,
    상기 파워 오프 명령을 전송하는 단계는,
    상기 제 1 장치로부터 상기 변경 명령에 따른 서비스 변경이 완료됨을 지시하는 제 3 보고가 수신되면 수행되는, 게이트웨이의 제어방법.
  14. 제 19항에 있어서,
    상기 제 2 보고는,
    상기 제 3 장치의 파워 온 상태를 지시하는, 게이트웨이의 제어방법.
  15. 제 9항에 있어서,
    상기 변경 명령을 전송하는 단계는,
    상기 제 1 장치에 상기 제 2 장치의 역할을 상기 제 3 장치로 변경할 것을 지시하는 단계를 포함하는, 게이트웨이의 제어방법.
  16. 제 15항에 있어서,
    상기 특정 서비스에 제 4 장치가 더 참여하고, 상기 제 4 장치가 상기 제 2 장치에만 연결된 경우,
    상기 제 3 장치에 상기 제 4 장치와 연결할 것을 지시하는 단계를 더 포함하는, 게이트웨이의 제어방법.
  17. 게이트웨이의 제어방법에 있어서,
    제 1 외부기기가 연결됨에 따라 장치 어댑터에서 제 1 객체 자원이 생성되는 단계;
    상기 제 1 객체 자원이 미들웨어 계층의 객체 자원 관리 모듈에 등록되는 단계;
    상기 객체 자원 관리 모듈을 통해 상기 제 1 외부기기에 대한 메타 정보가 기 설정된 체계에 따라 메타정보 관리 트리에 입력되는 단계;
    서비스 계층에서 상기 메타정보 관리 트리를 통해 상기 제 1 외부기기의 기기 식별자 및 상기 제 1 외부기기가 지원하는 적어도 하나의 기능에 대한 기능 식별자를 획득하는 단계;
    상기 서비스 계층에서 상기 획득된 기기 식별자 및 적어도 하나의 기능 식별자를 이용하여 상기 객체 자원 관리 모듈에 상기 제 1 객체 자원의 주소를 조회하는 단계;
    상기 서비스 계층에서 상기 조회된 제 1 객체 자원의 주소를 이용하여 상기 제 1 외부기기를 제어하는 단계를 포함하는, 게이트웨이의 제어방법.
  18. 제 17항에 있어서,
    상기 제어하는 단계는,
    상기 서비스 계층에서 상기 제 1 외부기기로부터 제조사 특정 기능(vendor specific semantic)에 대한 메타 정보를 수신하는 단계;
    상기 서비스 계층에서 상기 수신된 메타 정보를 통해 상기 메타정보 관리 트리의 장치 및 장치 기능 항목을 재정렬하는 단계; 및
    상기 서비스 계층에서 상기 재정렬된 메타정보 관리 트리를 이용하여 상기 제 1 외부기기의 제조사 특정 기능을 제어하는 단계를 포함하는, 게이트웨이의 제어방법.
  19. 제 18항에 있어서,
    상기 재정렬하는 단계는,
    상기 수신된 메타 정보를 이용하여 상기 제조사 특정 기능의 기술(description)을 해석하는 단계; 및
    상기 해석에 따라 상기 메타정보 관리 트리의 특정 항목에 상기 수신된 메타 정보의 각 항목을 매핑하는 단계를 포함하는, 게이트웨이의 제어방법.
  20. 제 19항에 있어서,
    상기 매핑된 메타 정보의 각 항목을 사용자 인터페이스를 통해 출력하는 단계를 더 포함하는, 게이트웨이의 제어방법.
PCT/KR2014/004777 2013-05-28 2014-05-28 게이트웨이 및 그 제어방법 WO2014193166A1 (ko)

Applications Claiming Priority (20)

Application Number Priority Date Filing Date Title
US201361828171P 2013-05-28 2013-05-28
US61/828,171 2013-05-28
US201361833902P 2013-06-11 2013-06-11
US61/833,902 2013-06-11
US201361841408P 2013-06-30 2013-06-30
US61/841,408 2013-06-30
US201361858614P 2013-07-26 2013-07-26
US61/858,614 2013-07-26
US201361871877P 2013-08-30 2013-08-30
US61/871,877 2013-08-30
US201361897817P 2013-10-30 2013-10-30
US61/897,817 2013-10-30
US201361910034P 2013-11-27 2013-11-27
US61/910,034 2013-11-27
US201361917307P 2013-12-17 2013-12-17
US61/917,307 2013-12-17
KR10-2014-0064124 2014-05-28
KR1020140064125A KR20140139987A (ko) 2013-05-28 2014-05-28 게이트웨이 및 그 제어방법
KR10-2014-0064125 2014-05-28
KR1020140064124A KR20140139986A (ko) 2013-05-28 2014-05-28 게이트웨이 및 그 제어방법

Publications (1)

Publication Number Publication Date
WO2014193166A1 true WO2014193166A1 (ko) 2014-12-04

Family

ID=51989119

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/004777 WO2014193166A1 (ko) 2013-05-28 2014-05-28 게이트웨이 및 그 제어방법

Country Status (1)

Country Link
WO (1) WO2014193166A1 (ko)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105450654A (zh) * 2015-12-08 2016-03-30 深圳市讯方技术股份有限公司 基于中间件技术的智能家居开发平台及其业务开发方法
WO2017010812A1 (ko) * 2015-07-13 2017-01-19 엘지전자(주) 무선 통신 시스템에서 데이터를 송수신하는 방법 및 장치
CN106909078A (zh) * 2015-12-22 2017-06-30 美的集团股份有限公司 家庭网关和智能家居系统、家用电器的控制方法
WO2017126806A1 (ko) * 2016-01-18 2017-07-27 삼성전자(주) 전자장치 및 그 제어방법
CN107547314A (zh) * 2016-06-24 2018-01-05 夏普株式会社 用于智能家居服务的系统和方法
CN109361594A (zh) * 2018-11-21 2019-02-19 深圳奇迹智慧网络有限公司 多功能杆的网关系统及多功能杆
EP3884369A4 (en) * 2019-01-03 2022-01-19 Samsung Electronics Co., Ltd. DISPLAY DEVICE AND METHODS OF CONTROL THEREOF

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060062381A (ko) * 2004-12-03 2006-06-12 한국전자통신연구원 디지털 홈 서비스를 위한 플랫폼 프로파일 관리 방법
KR100866207B1 (ko) * 2007-05-15 2008-10-30 삼성전자주식회사 홈 네트워크 서비스 제어를 위한 멀티 에이전트 프레임 웍제공 시스템 및 방법
KR20110064486A (ko) * 2009-12-08 2011-06-15 한국전자통신연구원 멀티테넌시를 지원하는 ＳａａＳ 플랫폼에서 메타데이터 캐시의 일관성 제어 시스템 및 방법
KR20110083456A (ko) * 2010-01-12 2011-07-20 명지대학교 산학협력단 센서 정보, 사용자 선호 정보, 가상 객체 성능 정보 및 가상 객체 명령 정보를 이용한 멀티미디어 응용 방법 및 시스템
WO2013022317A2 (ko) * 2011-08-10 2013-02-14 엘지전자 주식회사 서버의 명령을 수행하기 위한 방법, 및 그를 위한 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060062381A (ko) * 2004-12-03 2006-06-12 한국전자통신연구원 디지털 홈 서비스를 위한 플랫폼 프로파일 관리 방법
KR100866207B1 (ko) * 2007-05-15 2008-10-30 삼성전자주식회사 홈 네트워크 서비스 제어를 위한 멀티 에이전트 프레임 웍제공 시스템 및 방법
KR20110064486A (ko) * 2009-12-08 2011-06-15 한국전자통신연구원 멀티테넌시를 지원하는 ＳａａＳ 플랫폼에서 메타데이터 캐시의 일관성 제어 시스템 및 방법
KR20110083456A (ko) * 2010-01-12 2011-07-20 명지대학교 산학협력단 센서 정보, 사용자 선호 정보, 가상 객체 성능 정보 및 가상 객체 명령 정보를 이용한 멀티미디어 응용 방법 및 시스템
WO2013022317A2 (ko) * 2011-08-10 2013-02-14 엘지전자 주식회사 서버의 명령을 수행하기 위한 방법, 및 그를 위한 장치

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017010812A1 (ko) * 2015-07-13 2017-01-19 엘지전자(주) 무선 통신 시스템에서 데이터를 송수신하는 방법 및 장치
US10492060B2 (en) 2015-07-13 2019-11-26 Lg Electronics Inc. Method and device for transmitting/receiving data in wireless communication system
CN105450654A (zh) * 2015-12-08 2016-03-30 深圳市讯方技术股份有限公司 基于中间件技术的智能家居开发平台及其业务开发方法
CN106909078A (zh) * 2015-12-22 2017-06-30 美的集团股份有限公司 家庭网关和智能家居系统、家用电器的控制方法
WO2017126806A1 (ko) * 2016-01-18 2017-07-27 삼성전자(주) 전자장치 및 그 제어방법
US10749697B2 (en) 2016-01-18 2020-08-18 Samsung Electronics Co., Ltd. Electronic apparatus and control method thereof
CN107547314A (zh) * 2016-06-24 2018-01-05 夏普株式会社 用于智能家居服务的系统和方法
CN109361594A (zh) * 2018-11-21 2019-02-19 深圳奇迹智慧网络有限公司 多功能杆的网关系统及多功能杆
EP3884369A4 (en) * 2019-01-03 2022-01-19 Samsung Electronics Co., Ltd. DISPLAY DEVICE AND METHODS OF CONTROL THEREOF

Similar Documents

Publication Publication Date Title
WO2014193166A1 (ko) 게이트웨이 및 그 제어방법
WO2014098441A1 (en) System and method of controlling surrounding devices, based on topology
WO2015069030A1 (ko) 블루투스 연결 방법 및 장치
WO2012099378A2 (ko) 콘텐트 송수신 제어 방법 및 장치
WO2014092486A1 (ko) 홈 네트워크 시스템에서 컨텐츠 재생 장치 및 방법
WO2020013677A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2013169043A1 (ko) Nfc를 이용한 콘텐트 다운로드 방법 및 장치
WO2017039223A1 (en) Display apparatus and control method thereof
WO2018038459A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2012141494A2 (ko) 단말 관리 시스템 및 단말 관리 방법
WO2020204505A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2014092503A1 (en) Method and apparatus for controlling devices in home network system
WO2017010760A1 (en) Hub apparatus and method for providing service thereof
WO2013048152A1 (en) User profile-based device access control method and apparatus
WO2014088231A1 (en) Information providing method and mobile terminal therefor
WO2014088234A1 (en) Information providing method and mobile terminal therefor
WO2020060368A2 (en) Method and apparatus for providing notification by interworking plurality of electronic devices
WO2020204269A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2014189323A1 (en) Apparatus and method for performing wireless docking operation in communication system supporting universal plug and play protocol
WO2013062341A1 (en) System and method for controlling an electronic device
WO2011155762A2 (ko) 다른 장치와 통신 하는 방법 및 통신 기기
WO2011155734A2 (ko) 다른 장치와 통신 하는 방법 및 통신 기기
WO2011090287A4 (en) Electronic device and operating method of the same
EP3320655A1 (en) Hub apparatus and method for providing service thereof
WO2022060046A1 (ko) 엣지 컴퓨팅 시스템 및 엣지 컴퓨팅 장치의 핸드오버 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14805144

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14805144

Country of ref document: EP

Kind code of ref document: A1