WO2013169043A1 - Nfc를 이용한 콘텐트 다운로드 방법 및 장치 - Google Patents

Nfc를 이용한 콘텐트 다운로드 방법 및 장치 Download PDF

Info

Publication number
WO2013169043A1
WO2013169043A1 PCT/KR2013/004102 KR2013004102W WO2013169043A1 WO 2013169043 A1 WO2013169043 A1 WO 2013169043A1 KR 2013004102 W KR2013004102 W KR 2013004102W WO 2013169043 A1 WO2013169043 A1 WO 2013169043A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
request
client device
download
wake
Prior art date
Application number
PCT/KR2013/004102
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 to US14/399,877 priority Critical patent/US9467202B2/en
Publication of WO2013169043A1 publication Critical patent/WO2013169043A1/ko

Links

Images

Classifications

    • H04B5/72—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits

Definitions

  • the present invention relates to a content download method and apparatus, and more particularly, to a method and apparatus for downloading utilizing NFC (Near Field Communication) to a device constituting a network service.
  • NFC Near Field Communication
  • Mobile devices such as smart devices are used in various service fields such as e-commerce, online banking, games, navigation, mobile messenger services, as well as information retrieval through the Internet based on various applications installed in the devices. have.
  • mobile devices are increasingly being used through interworking with home devices in the home network, such as connecting to a home network to control the home device, transmitting content to the home device, or receiving content from the home device.
  • wireless communication may be utilized.
  • communication between the smart devices may be performed through NFC (Near Field Communication).
  • the conventional communication using NFC was mostly to provide a service for transmitting data between devices only when the NFC connection. That is, in the related art, when NFC connection is possible between devices, a download reservation protocol, a download queue request data format, and a download queue protocol are used to support download reservation for specific content in a target device. There is a problem in that there is no definition of a download and content play application interface, and thus, reservation download, download queue request, and playback of downloaded content cannot be performed.
  • the conventional NFC-based technology provides a function of automatically notifying when a content download reservation or download is completed on another device, and event notification through another network interface when the device cannot connect to NFC. There was no capability to do so, so there was a limit to device usability over NFC connections.
  • An object of the present invention for solving the above problems is to reserve a content download using an NFC peer-to-peer model between two client devices capable of NFC connection (queued download by queue request).
  • a method and apparatus for downloading content using NFC including a wake request function for transmitting a queuing request and downloading content after downloading the content.
  • another object of the present invention is to send a download request to the cloud service (Cloud Service) at the same time as the download request to the device connected by NFC, the asset (Asset) associated with the content by sending a queue request to the target client device and the cloud service at the same time (Asset) It is to provide a method and apparatus for downloading content using NFC to be downloaded to the target client device and the cloud service.
  • Cloud Service cloud service
  • another object of the present invention is to define an NFC message for a download reservation request, and after the client device sends a queue request to the target device via NFC, and when the download is completed on the target device, process the reservation request for the completed content. It is to provide a method and apparatus for downloading content using NFC that can provide a specific user interface (UI) of a client device so that one client device can receive it.
  • UI user interface
  • the content download method of the present invention for achieving the above object is performed by a first device, transmitting a content download request requesting to download the content using a second device, receiving the content download request Receiving a confirmation in response to the content download request from a device, receiving a wake-up request from the second device, and downloaded to the second device in response to the content download request Receiving content from the second device.
  • the download method may further include entering a sleep mode in response to the confirmation.
  • At least one of the content download request, the confirmation, and the wake-up request may be transmitted and received using Near Field Communication (NFC).
  • NFC Near Field Communication
  • the receiving of the wake-up request may include at least one of receiving the wake-up request through NFC and receiving a wireless local area network (WLAN) or 3G / 4G wireless communication.
  • WLAN wireless local area network
  • the content download request may include download related information including source URI information on download content, a download time indicating a downloadable time, and wake up time information indicating a wake up time.
  • the content download request is information related to a reception condition of the downloaded content by the first device, and may include at least one of power connection state information, battery state information, network state information, and storage available space information.
  • the transmitting of the content download request may include at least one of transmitting the content download request directly to the second device and transmitting the content download request to a third device.
  • the third device may be a server related to a cloud service or a device for relaying the first device and the second device.
  • the downloading method may further include displaying a user interface for selecting content to be downloaded and selecting content in response to the content selection signal, wherein the transmitting of the content download request is performed based on the content selection. And automatically transmitting the content download request to the second device upon contact with a device.
  • the downloading method may further include discovering an accessible peripheral device using a recently accessed device list and obtaining a source URI of content to be downloaded from the content server.
  • the receiving of the downloaded content may include determining whether a condition for receiving the downloaded content is satisfied, and receiving the downloaded content based on the determination.
  • the content download apparatus of the present invention receives a transmission unit for transmitting a content download request for requesting to download content using a second device, and a confirmation in response to the content download request. And a receiving unit configured to receive a wake-up request from the second device and to receive content downloaded from the second device to the second device by the content download request.
  • the method of downloading a content of the present invention for achieving the above object is performed by a second device, receiving a content download request from at least one of a first device and a third device, and confirming the content download request. transmitting a confirmation, downloading the content to be downloaded based on the content download request, transmitting a wake-up request to the first device, and transmitting the downloaded content to the first content. And transmitting to the device.
  • At least one of the content download request, the confirmation, and the wake-up request may be transmitted and received using Near Field Communication (NFC).
  • NFC Near Field Communication
  • the content download request may be received from a third device different from the first device, and the content to be downloaded may be downloaded from the third device.
  • the transmitting of the wake-up request may include transmitting a wake-up request via NFC and a wireless local area network (WLAN) when there is no response to the wake-up request transmitted through the NFC from the first device for a reference time. Or transmitting the wake up request through 3G / 4G wireless communication.
  • WLAN wireless local area network
  • the downloading of the downloaded content may include determining whether to transmit the downloaded content based on the information related to the downloaded content reception condition of the first device included in the content download request and based on the determination result. And transmitting the downloaded content to the first device.
  • the content download apparatus of the present invention receives a content download request from at least one of a first device and a third device, and based on the content download request, content to be downloaded from the first server.
  • a transmission unit configured to download a reception unit and a confirmation response to the content download request, a wake-up request to the first device, and a transmission to transmit the downloaded content to the first device It may include wealth.
  • the content download system of the present invention transmits a content download request requesting to download content using a second device, receives a confirmation in response to the content download request, and receives the second device.
  • Receiving a wake-up request from the first device the first device receiving the content downloaded to the second device according to the content download request, and the content download request, transmitting the confirmation, and based on the content download request
  • the second device may include downloading a content to be downloaded, transmitting a wake-up request to the first device, and transmitting the downloaded content to the first device.
  • the download system receives the content download request from the first device, transmits a confirmation in response to the content download request to the first device, and transmits the content download request to the second device. It may further include.
  • a user supports downloading reservation and transmission only by contact between NFC-enabled devices, and queue download request and list management using NFC between a NAS (Network Attached Storage) and a smart device.
  • NFC Network Attached Storage
  • the sync function for cloud services can be complemented, so that only selected files are pre-downloaded using the home network or the sync function between cloud services and devices is improved. It can work.
  • the download is made when the remote device is available through a cloud service.
  • the user can reduce the procedure of checking the status of the remote device frequently.
  • FIG. 1 is a block diagram illustrating a configuration of a content service system to which a content download method according to an embodiment of the present invention may be applied;
  • FIG. 2 is a block diagram illustrating a detailed structure and an associated interface of a client device of a content service system
  • FIG. 3 is a diagram for describing the interfaces illustrated in FIG. 2;
  • FIG. 4 is a block diagram illustrating a configuration of a content service system to which a content download method using NFC according to an embodiment of the present invention can be applied;
  • FIG. 5 is a block diagram illustrating a location on an NFC stack protocol of an application related to a content download method using NFC according to an embodiment of the present invention
  • FIG. 6 is a view illustrating a content download and a queue request to another device according to a content download method using NFC according to an embodiment of the present invention
  • FIG. 7 is a view illustrating a flow of signals transmitted and received between a first client device, a second client device, and a content server in a content download method using NFC according to an embodiment of the present invention
  • FIG. 8 is a diagram illustrating a flow of signals transmitted and received between a first client device, a second client device, and a cloud service server in a content download method using NFC according to another embodiment of the present invention
  • FIG. 9 is a diagram illustrating a flow of signals transmitted and received between a first client device, a second client device, and a cloud service server in a content download method using NFC according to another embodiment of the present invention.
  • FIG. 10 is a diagram for describing a flow of signals transmitted and received between a first client device, a second client device, a third client device, and a content server in a content download method using NFC according to another embodiment of the present invention
  • FIG. 11 is a sequence diagram of signals transmitted and received between a first client device, a second client device, and a content server according to an exemplary use example of a method for downloading content using NFC according to another embodiment of the present invention
  • FIG. 12 is a sequence diagram of signals transmitted and received between a first client device, a second client device, and a content server according to an exemplary use example of a method of downloading content using NFC according to another embodiment of the present invention
  • FIG. 13 is a sequence diagram of signals transmitted and received between a first client device, a second client device, and a content server, according to an exemplary use example of a method for downloading content using NFC according to another embodiment of the present invention
  • FIG. 14 is a sequence diagram of signals transmitted and received between a first client device, a second client device, a third client device, and a content server, according to an exemplary use example of a method for downloading content using NFC according to another embodiment of the present invention.
  • FIG. 15 illustrates an example of a user interface for inputting settings in connection with a client application of a method of downloading content using NFC according to another embodiment of the present invention
  • FIG. 16 illustrates an example of a user interface for inputting a content list, a download time, and a content download related setting through a client application of a content download method using NFC according to another embodiment of the present invention
  • 17 is a flowchart schematically illustrating an operation of a first client device in a content download method using NFC according to another embodiment of the present invention.
  • FIG. 18 is a flowchart schematically illustrating an operation of a second client device in a content download method using NFC according to another embodiment of the present invention.
  • FIG. 19 is a flowchart illustrating a device discovery method of a content download method using NFC according to a preferred embodiment of the present invention.
  • 20 is a diagram for explaining the structure of the listened connected device list.
  • 21 is an exemplary diagram illustrating a structure of a unicast device discovery message used for a unicast device discovery request or response.
  • 22 illustrates a content download procedure based on device discovery and device capability exchange.
  • FIG. 23 illustrates a content download procedure based on device capability exchange between a content server and an intermediate device.
  • 24 is a diagram for explaining the structure of device capability.
  • first and second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.
  • the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.
  • FIG. 1 is a block diagram illustrating a configuration of a content service system to which a content download method according to an embodiment of the present invention may be applied.
  • a content service system may be divided into a server domain and a user domain.
  • the server domain may operate a service and a network policy for a content service and provide content to a user domain based on the policy.
  • the server domain may mean a domain including servers for providing a content service.
  • Such a server domain may perform content provision and operation of a service to a user domain such as content creation, sale, distribution, policy operation, and permission restriction.
  • the server domain may include a content server (CS) for providing content, a content policy server (CPS) for operating a policy for a content service, a content policy server (NPS) for operating a network policy, and the like.
  • CS content server
  • CPS content policy server
  • NPS content policy server
  • the server domain may include a content download server for downloading content, a content streaming server for streaming content, and the like.
  • the user domain may include the devices 100 of the user.
  • the device 100 may be, for example, a fixed device such as a PC, a set-top box, or a portable device such as a smart phone, a mobile phone, a mobile handset, a tablet, a personal digital assistant (PDA), a notebook computer, or the like.
  • the devices 100 may access a local network based on UPnP, DLNA, and the like, and may interoperate with each other through wired or wireless communication.
  • the device 100 of the user may be a client device or an intermediate device.
  • the client device may mean a physical hardware device having at least one network interface and local storage.
  • the client device may be a mobile handset, tablet, smartphone, etc. that can consume content.
  • the client device CD may have modules for receiving a content service.
  • the intermediate device may be a dual role client / server device on the network that may be used to stage assets for a client device row.
  • the intermediary device may temporarily hold the asset until the asset is delivered to the client device.
  • the intermediate device typically does not consume the content directly, but may consume the content directly.
  • the intermediate device may stage the content. That is, the intermediate device may download the content from the server, and store and play the content.
  • FIG. 2 is a block diagram illustrating a detailed structure and an associated interface of a client device of a content service system.
  • the client device CD includes a local application / user agent 110, a player 130, a network policy client 140, A virtual storage device 150, a queue / policy engine (QPE) 120, and the like may be included.
  • QPE queue / policy engine
  • the local application / user agent 110 may be software for a content service and may include a local application and a user agent.
  • the local application / user agent 110 may provide a user interface, a service menu, a service selection, a content selection, and the like for allowing a user to receive a content service.
  • the local application may communicate with the queue / policy engine 120 using a particular interface protocol, such as the Q2 interface protocol, as software resident on the client device.
  • the user agent may refer to software that renders and executes a server-supplied application such as, for example, a web browser or middleware of a client device CS.
  • the local application / user agent 100 may be activated when the download of content is started or completed.
  • the player 130 is for playing content provided through a content service.
  • the player 130 may be a media player capable of playing download content or streaming content.
  • the network policy client 140 may acquire a network policy and control the client device CD according to the acquired network policy while communicating with the network policy server NPS.
  • the virtual storage device 150 is a representation of local storage that can be accessed through a cache object.
  • the virtual storage device 150 may be a general local storage such as a hard disk, a USB memory connected to the device, a flash memory, a virtual area such as a daemon, or the like.
  • the queue / policy engine 120 of the client device caches / downloads specific content (asset) of the content server (CS) when it satisfies the policy given by the content policy server (CPS) or the network policy server (NPS).
  • the request may be referred to as a queue request. That is, the queue request may be expressed as a content download request.
  • the queue request may include a URI corresponding to content (asset).
  • the queue request may include not only a codec type media profile, a container type, a multipurpose internet mail extension type, a store name, a total length of the queue request, content information, Policy information and the like.
  • the queue request may include bandwidth information for each source URI estimated by the local application / user agent 110.
  • the queue / policy engine 120 is a module included in the client device CD and may communicate via P1, S, D1, D2, Q2, D3, and Q3 interface protocols.
  • the queue / policy engine 120 may maintain a queue on behalf of each local application and content server, interface with storage, and synchronize queue requests with policies. You can take responsibility. Accordingly, the queue / policy engine 120 may be referred to as a service client for a content sharing service.
  • the queue / policy engine 120 may include a queue manager 122, a policy client 126, an intermediate device manager 124, and the like. Can be.
  • the queue manager 122 may operate a queue for downloading or streaming content.
  • the queue manager 122 may include a stream queue manager and a download manager.
  • the queue manager 122 may send a queue request to an intermediate device (IMD) and receive a response from the intermediate device (IMD), or may receive a queue request from the intermediate device (IMD) and transmit the response.
  • IMD intermediate device
  • IMD intermediate device
  • the queue manager 122 may send a queue request requesting to download specific content from the content server CS to the intermediate device IMD and receive the response.
  • the queue manager 122 may transmit a queue request to the intermediate device IMD to transmit the content downloaded from the content server CS to the client device CD.
  • the queue manager 122 may perform a write check for use of content.
  • the queue manager 122 may write a light check for staging an asset corresponding to the content selected by the local application 110 through the intermediate device IMD, for example, the asset from the content server CS. Write check to download to the IMD).
  • the write check may include a digital right management (DRM) capability check and a license check.
  • DRM digital right management
  • the DRM capability check may verify whether the intermediary device (IMD) can support a DRM system that protects the asset, based on the DRM information of the asset and the DRM capability of the intermediary device (IMD).
  • the license check can verify that the license mediated device (IMD) can obtain a license for use of the asset.
  • the license check may be to check a right defined in a right token.
  • Receipt of the requested assets managed by the queue can be accomplished using unicast downloads, multicast downloads, or a combination of both mechanisms.
  • the queue / policy engine 120 must preserve a single queue even if the commands defined in the queue interface change their priority or order.
  • the policy client 126 maintains a policy object as a subsystem of the queue / policy engine 120.
  • the policy client 126 may control the queue / policy engine 120 in accordance with policies from the content policy server (CPS). For example, the policy client 126 may retrieve policies from the content policy server (CPS) and adjust the queue request behavior.
  • CPS content policy server
  • the intermediary device manager 124 may manage intermediary devices (IMDs) that interoperate with client devices (CDs). For example, the intermediate device manager 124 may discover an intermediate device (IMD) connected to the network and manage a state of the intermediate device (IMD). The intermediate device manager 124 may transmit or receive the intermediate device and the necessary message.
  • IMDs intermediary devices
  • CDs client devices
  • the intermediate device manager 124 may discover an intermediate device (IMD) connected to the network and manage a state of the intermediate device (IMD).
  • IMD intermediate device
  • the intermediate device manager 124 may transmit or receive the intermediate device and the necessary message.
  • FIG. 3 shows a diagram for describing the interfaces shown in FIG. 2.
  • interfaces associated with a content service system may be divided into P, Q, S, and D interface groups. Each interface can work with a client-server architecture.
  • the P interface group may define a link and policy between the queue / policy engine 120 and the content policy server (CPS).
  • This P interface group may include P1 and P2 interfaces.
  • the server may be a content policy server (CPS) and the client may be a queue / policy engine 120.
  • the server may be a network policy client 140 and the client may be a queue / policy engine 120.
  • the server may be a content server (CS) and the client may be an intermediate device (IMD).
  • the Q interface group can define queue request handling.
  • the Q interface group may be a primary command channel interworking between the content server CS, the intermediate devices IMD, and the queue / policy engine 120.
  • the Q interface group can allow Caching Functionality to be called by the local application.
  • the server may be a queue / policy engine 120 and the client may be a local application.
  • Queue requests submitted via the Q2 interface protocol may include a complete URL that can be called from the context of the user agent or the calling local application to download the asset.
  • the queue request may include a local URL for calling a calling local application for pre-negotiate download.
  • the server may be a queue / policy engine 120 and the client may be an intermediary device (IMD).
  • the server may be a content server (CS) and the client may be an intermediate device (IMD).
  • the S interface group can extract storage and cache capabilities to the queue / policy engine.
  • the server may be a virtual storage device 150 and the client may be a queue / policy engine 120.
  • the D interface group may be used for data transmission.
  • the server may be a content server (CS) and the client may be a queue / policy engine 120.
  • the server may be a queue / policy engine 120 and the client may be a player 130.
  • the server may be an intermediary device (IMD) and the client may be a queue / policy engine 120.
  • the server may be a content server (CS) and the client may be an intermediate device (IMD).
  • FIG. 4 is a block diagram illustrating a configuration of a content service system to which a content download method using NFC according to an embodiment of the present invention can be applied.
  • the communication unit 160, 260 is connected to the content service system illustrated in FIG. 1 by a client device (CD) and an intermediate device (IMD). ) Can be applied to a content service system included in each).
  • CD client device
  • IMD intermediate device
  • the client device CD may include a communication unit 160.
  • the communicator 160 may include a transmitter (not shown) and a receiver (not shown).
  • the communicator 160 may transmit a queue request (or a content download request) from the queue / policy engine 120 to the communicator 260 of the intermediate device IMD.
  • the queue request is a request to download specific content (content associated with a source URI) to the intermediate device IMD, and may also include a request to transmit the downloaded content to the client device CD.
  • the client device CD may receive a confirm message for the queue request and a wake up request from the intermediary device IMD.
  • the communication unit 160 may not only support communication with each device but also support communication with other devices or servers.
  • the communicator 160 may receive the queue request, confirm message, and wake-up request based on various wireless communication schemes.
  • the various wireless communication schemes may include 3G / LTE (Long Term Evolution), NFC, and Wireless Local Area Network (WLAN), and the communication unit 160 may include at least one of NFC devices, 3G / 4G, and WLAN-related communication modules. It may include.
  • the communication unit 160 may support other wireless communication schemes based on 802.11 and 802.16, but is not necessarily limited to the above scheme.
  • the communication unit 260 of the intermediate device may also include a transmitter (not shown) and a receiver (not shown), and the communication unit 260 may also include at least one of an NFC device, a 3G / 4G, and a WLAN-related communication module. It may include. Accordingly, the intermediary device (IMD) can also support various wireless communication schemes such as 3G / LTE, NFC, and WLAN. Although not shown in the drawing, the communication unit 260 may support other wireless communication schemes based on 802.11 and 802.16, but is not necessarily limited to the above scheme.
  • the communication unit 260 may receive a queue request from the client device CD, and transmit a confirm message and a wake up request for the queue request. In this case, the NFC device may transmit and receive at least one of the queue request, the confirmation message, and the wake up request through NFC.
  • FIG. 5 is a block diagram illustrating a location on an NFC stack protocol of an application related to a content download method using NFC according to an embodiment of the present invention.
  • an application related to content download using NFC is located at the top of an application in an NFC protocol stack. That is, an application for reservation download and remote wake-up according to an embodiment of the present invention may operate based on the NFC protocol, and the location on the protocol stack of the application may include protocol, data format, and application. It can be located at the top of the application note. Therefore, the content download application using NFC may use a conventional NFC-related data format and protocol as it is.
  • FIG. 6 is a diagram illustrating a content download and a queue request to another device according to a content download method using NFC according to an embodiment of the present invention.
  • the client device CD selects desired content from among a plurality of media contents provided from the content server CS. Then, the queue / policy engine 120 of the client device CD generates a queue request of the selected media content and transmits the queue request to the intermediate device IMD through the communication unit 160. At this time, the client device (CD) may transmit a queue request to the intermediate device (IMD) through a wireless communication scheme such as NFC, 3G / 4G-based wireless communication, WLAN, or Bluetooth using an NFC device or a communication module. . Upon receipt of the queue request, the intermediate device (IMD) may parse the source URI information of the content included in the queue request to queue / download the media content from the content server CS. In addition, the intermediate device IMD may transmit the media content to the other device 300. In this case, home network related technologies such as Digital Entertainment Content Ecosystem (DECE) and UPnP / DLNA may be applied.
  • DECE Digital Entertainment Content Ecosystem
  • UPnP / DLNA may be applied
  • the client device (CD) may support a user configuration (User Configuration). Local applications on the client device (CD) manage policies and queue management on behalf of use. More specifically, the client device CD may manage a policy for download / upload. In addition, the client device (CD) may determine whether to use WLAN or 3G / 4G wireless communication, and may determine through user configuration whether to use a plug-in over a power connection or a battery. In addition, the user configuration may support the determination of whether to perform a queue request or download in the daytime time zone or the night time.
  • User Configuration User Configuration
  • FIG. 7 illustrates a flow of signals transmitted and received between a first client device CD1, a second client device CD2, and a content server CS in a content download method using NFC according to an embodiment of the present invention. It is for the drawing.
  • the first client device CD1 is a device that processes a content download request (or queue request) requesting to perform content download to the second client device CD2.
  • the first client device CD1 may be a fixed terminal such as a PC, a set-top box, or the like, or may be a portable terminal such as a smart phone, a personal digital assistant (PDA), a notebook computer, or the like.
  • the first client device CD1 may support Near Field Communication (NFC) in order to provide uninterrupted content transmission between devices by a simple user operation. That is, as described above, the communication unit 160 of the first client device CD1 may include an NFC device.
  • NFC Near Field Communication
  • the second client device CD2 may be an intermediate device or a target device.
  • the second client device CD2 is a device that downloads content by a request from the first client device CD1.
  • the second client device CD2 may be a remote device remote from the first client device CD1.
  • the second client device CD2 may be a fixed terminal such as a PC, a set-top box, or the like, or may be a portable terminal such as a smart phone, a personal digital assistant (PDA), a notebook computer, or the like. It may be a server or storage. It may also be a network attached storage (NAS).
  • the second client device may also support Near Field Communication (NFC) to provide seamless content transfer between devices.
  • NFC Near Field Communication
  • the communication unit 260 of the second client device CD2 may include an NFC device. If both devices support NFC transmission, the queue request can be easily sent without the complicated setup process by the user as a simple contact between the NFC reader and the NFC tag.
  • the first client device CD1 may select content to be added to the queue of the second client device CD2 while browsing the content list.
  • the first client device CD1 may receive a content list to be downloaded from the content server CS, and request to download any one or a plurality of contents from the received list.
  • the first client device CD1 transmits a content download request (or queue request) to the second client device CD2 (S710).
  • the content download request may be transmitted using NFC.
  • the first client device CD1 may generate a magnetic field of 13.56Mhz and transmit the content download request via NFC.
  • the content download request may include download related information.
  • the download related information may include download related information including source URI information, download time, and wake up time information about the download content.
  • the source URI information may be source URI information of any one or a plurality of contents selected from a list received from the content server CS.
  • the download time represents a period in which the download is set by the user or the application.
  • the wake up time indicates a designated time for the second client device CD2 in the sleep mode to wake up and download content related to the download request from the content server CS.
  • the wake up time is a time for the first client device CD1 to perform wakeup in the sleep mode, that is, the second client device CD2 transmits a wakeup request to the first client device CD1.
  • Can point to time This can be clearly defined by setting. It may also include information related to the transmission of the content download request (queue request).
  • the content download request may further include NFC related information and reception condition information on the download content. This will be described later.
  • the second client device CD2 may transmit a confirmation message for the download request to the first client device CD1 (S712).
  • the confirm message may be an automatic notification message for the queue request status of the second client device CD2.
  • the NFC-capable second client device CD2 may receive a queue request from the first client device CD1 via the NFC interface and send a message to the first client device CD1 that the reception of the content download request has been successfully made. have.
  • the confirm message may include information that the second client device CD2 will start downloading. Alternatively, the acknowledgment of the download start may be transmitted separately from the confirmation message.
  • the confirmation message may also be transmitted through NFC.
  • the first client device CD1 may enter a sleep mode upon receiving the confirmation message.
  • the sleep mode is a mode in which power consumption is assumed to be low in order to minimize battery consumption.
  • the user may want to minimize the first client device CD1 power consumption while the second client device CD2 downloads.
  • the sleep mode may be entered by a command to enter the sleep mode.
  • the oscillator of the device may be turned off and no system clock in the device may be generated.
  • the I / O port may remain in the state just before the sleep mode. Sleep mode can be divided into several levels depending on the settings.
  • sleep mode which maintains the current state memory contents, including open programs or documents, exports the current state stored in the memory to the hard disk, but does not maintain the current state.
  • sleep mode when switching to sleep mode, it can support a sleep mode that only remembers the current state in memory and does not copy contents to the hard disk. This can be selected by the user through system configuration.
  • the sleep mode may be switched to the active mode by a specific timer or by receiving a wake up command from the outside.
  • the active mode is a mode in which the device operates normally, not the sleep mode.
  • the second client device CD2 may download the content asset from the content server CS.
  • the second client device CD2 may hold a list of content to download to the queue by the download request. Then, the content related file included in the stored list may be downloaded from the content server CS. In this case, the second client device CD2 may be downloaded at the download time included in the download request.
  • the second client diabis CD2 wakes up the first client device CD1 via NFC. It may wake up (S714). This can be done by sending a wake up request. As described above, the wake up request may be made based on the wake up time included in the content download request. In this case, if communication using NFC is not possible, the weight-up request may be transmitted using another detailed network interface, for example, 3G / 4G or WLAN. Whether or not NFC communication is set may be determined by setting a reference time based on whether a confirmation message for a wake-up request transmitted through NFC is received within the reference time.
  • the confirmation message reception time for the NFC wake-up request is set to 1 minute
  • the confirmation message is not received for 1 minute after the wake-up request is transmitted, it is determined that NFC communication is not possible, and through another wireless communication network.
  • a wake up request may be sent.
  • the first client device CD1 wakes up after receiving the wake up request. In other words, it switches from the sleep mode to the active mode. Then, the confirmation message for the wake-up may be transmitted to the second client device CD2 (S716).
  • the confirmation message for the wake-up may include information for requesting the transmission of the asset of the downloaded content. Alternatively, an asset transmission request message may be separately transmitted.
  • the first client device CD1 may set a power connection state, a battery state, a network state, and a storage available space state based on a power connection state, a battery state, a network state, and a storage available space state based on a user interface. It may be determined whether the reception is possible by comparing with the download content reception condition associated with the. Based on the determination result, it may be determined whether to transmit the transmission request message of the download content asset.
  • the power connection state, battery state, network state, and storage space of the first client device CD1 included in the content download request are included. It may be determined whether to transmit the content based on the download content reception condition information related to the state of. That is, the second client device CD2 compares the power connection state, the battery state, the network state, and the state of the storage available space of the first client device CD1 to the first client device CD1 by comparing with the download content receiving condition.
  • the download content asset may be determined whether to be transmitted.
  • the current power connection state, the battery state, the network state, and the state information of the available storage space of the first client device CD1 may be separately transmitted or may be included in a content download request.
  • the second client device CD2 is configured to display the second client device CD2 based on the size of the downloaded content and the state information of the current power connection state, the battery state, the network state, and the storage available space of the first client device CD1.
  • the client device CD2 may determine whether the first client device CD1 can be received. Then, based on the determination result, it may be determined whether to download the download content asset.
  • the second client device CD2 may compare its current power connection state, battery state, network state, and state of storage space with at least one of the size of the download content, the battery, and communication resources required for transmission. By comparison, it is possible to determine whether to transmit the downloaded content asset.
  • the determination of the reception / transmission of the download content assets to the plurality of first client devices CD1 may be controlled by the setting of the first client device CD1.
  • the setting information may be included in the content download request.
  • the first client device CD1 may show through the user interface that the queue request has been executed.
  • the asset of the downloaded content is ready to be transferred from the second client device CD2 to the first client device CD1. If the user selects a local download, the selected asset is transmitted from the second client device CD2 to the first client device CD1 (S718).
  • the above pre-downloading process may be automatically performed after selecting a file to be downloaded from the first client device CD1 and placing the first client device CD1 within a predetermined radius of the second client device CD2. That is, the first client device CD1 may control to automatically transmit a content download request (queue request) to the second client device CD2 through user setting.
  • the user of the first client device CD1 may control settings related to storage usage, download duration, power / battery usage for automatic queue requests and automatic downloads.
  • the second client device CD2 may receive the automatic content download request via NFC, automatically download the content after reception, and automatically transmit the downloaded content to the first client device CD1. This can be seen as a complement to the download using DLNA.
  • the content download request may support network interface information to simplify or automate NFC link setup and related protocols.
  • NFC related information automatic D2D for device wake-up policy information for NFC and content download request events (e.g., content download request events may include performance done and stop events) ( Device to Device) may include at least one of information related to the notification message.
  • the network interface information for simplifying or automating the NFC link setup may be added to a plurality of communication network types (eg, LAN, WLAN, 2G, 3G, 4G (including Wimax), USB, UPnP) information supported by the client device.
  • a plurality of communication network types eg, LAN, WLAN, 2G, 3G, 4G (including Wimax), USB, UPnP
  • the first device device may include NFC type (which may include NFC mode and Tag ID information) information.
  • 2 NFC information of the client device CD2 may be registered in a list of recently connected devices.
  • the intermediate device manager 124 may add specific NFC information of the queue / policy engine NFC type, mode, and TagID as follows.
  • the type 1/2/3/4 (Type 1/2/3/4) included in the NFC tag type information “NFCType” is a type described in v1.0 or v2.0 related to the device WG of the NFC forum.
  • RF interfaces, speeds, and protocols may be defined differently according to different types.
  • the NFC mode information "NFCMode” may also be a card emulation, peer-to-peer, lead-write mode, as defined in the NFC forum.
  • the card emulation mode refers to a mode that is always recognized by the reader regardless of whether the terminal is on or off
  • the peer-to-peer mode refers to a mode in which two NFC mobile phones operate as card readers to transmit data to each other.
  • the light mode may indicate a mode in which the mobile phone operates as a card reader by recognizing RFID tag information in an NFC activated state.
  • the NFC tag ID information "NFCID" represents ID information for identifying an NFC tag.
  • the content download request is information related to a condition for receiving the downloaded content of the first client device CD1 when the second client device CD2 completes the download, and includes power connection state information, battery state information, and network state. It may include at least one of the information and available storage space information.
  • the information may include information related to whether the power is connected or not, and the remaining amount of battery information.
  • the network status information provides information related to whether the local area network is connected or the 3G / 4G wireless network is connected, and the storage available space information is related to how much available storage space is currently allocated to the device.
  • the content download request may include setting information related to whether to receive the download content according to a power connection state, a battery state, a network state, and a storage available space.
  • the download content may be set to be received from the second client device CD2 only when the power is connected, and then transmitted.
  • the mobile terminal may be configured to receive the download content only when the battery state is equal to or greater than a specific value (eg, 30%).
  • a specific value eg, 30%.
  • Such setting information may be set as default information in advance, and the user may directly change the setting through the user interface.
  • FIG. 8 illustrates a flow of signals transmitted and received between a first client device CD1, a second client device CD2, and a cloud service server 400 in a content download method using NFC according to another embodiment of the present invention. It is a figure for following.
  • the first client device CD1 may request a content download request with a second client device CD2, a confirm message for the content download request, a wake up request, a confirm message for the wake up request, and download content.
  • the cloud service server 400 may be utilized.
  • the cloud service is a service that allows users to save information in any form or form, whether it is stored on a mobile device, on a PC, or on the web, and then voluntarily saves it in a shared folder and finds it anywhere when they want it. to be.
  • the server managing this is the cloud service server 400. If you specify a specific folder for the cloud service, the folder becomes a shared folder and can be automatically synchronized to the cloud service-related device.
  • the cloud service server 400 may include video storage and store content to be downloaded thereto.
  • the second client device CD2 After receiving the content download request, the second client device CD2 requests the content to be downloaded to the cloud service server 400.
  • the cloud service server 400 may download or synchronize the requested content file from the content server CS in advance. In some cases, if the cloud service server 400 can identify the asset to download, the cloud service server 400 does not download the asset from the content server CS, and the cloud service server 400 does not download the asset. Provide a download link (e.g., source URI).
  • the second client device 400 may receive the requested content from the cloud service server 400. Thereafter, the second client device CD2 transmits a wake up request to the first client device CD1, and after receiving the wake up request, the first client device CD1 wakes up in the sleep mode, and then the second client device CD1. Downloaded content may be received from the device CD2. Alternatively, the first client device CD1 may be provided with content through synchronization with the cloud service server 400.
  • FIG. 9 illustrates a flow of signals transmitted and received between a first client device CD1, a second client device CD2, and a cloud service server 400 in a content download method using NFC according to another embodiment of the present invention. It is a figure for demonstrating.
  • the first client device CD1 may transmit a content download request to the cloud service server 400 (S910).
  • the second client device CD2 is not available (e.g., sleep-mode, powered off, or the network interface is down)
  • the queue of the first client device CD1 is lost.
  • the policy engine 120 may transmit a content download request (queue request) to a designated cloud service.
  • the content download request may include a source URI and download / wake up time information.
  • the download time is a downloadable time set by a user or an application
  • the wake up time information indicates a time for waking up the second client device CD2 in the sleep mode to perform a download.
  • This use case may be advantageous for file synchronization between client devices CD1, CD2 and the cloud service.
  • the first client device CD1 transmits a download request to the cloud service server 400, and the cloud service server 400 sends the second request in response to the download / wake up time. It is possible to wake up the client device CD2.
  • the cloud service server 400 may select a recommended asset through a unique algorithm.
  • the download request may then be sent to the second client device CD2 on behalf of the user. Users can control settings related to storage usage, download duration, and power / battery usage for automatic queue request and downloading.
  • the cloud service server 400 receiving the content download request may transmit a confirmation message for the download request to the first client device CD1 (S912).
  • the first client device CD1 may enter a sleep mode to reduce power consumption.
  • the cloud service server 400 may download an asset of content to be downloaded in advance based on the content download request.
  • the cloud service server 400 may transmit a wake up request to the second client device CD2 (S914). Upon receiving the wake up request, the second client device CD2 performs a wake up to switch from the sleep mode to the active mode.
  • the second client device CD2 may transmit a confirm message for the wake up request (S916).
  • the cloud service server 400 receiving the confirmation message may transmit the requested content to the second client device CD2 (S918). That is, the content in the cloud service can be directly pushed. In some cases, it may be assumed that the content download request is transmitted to the second client device CD2 together with the cloud service server 400 through NFC. In this case, an asset of content to be downloaded may be downloaded to the second client device and the cloud service server 400. If the cloud service server 400 can identify an asset to download, the cloud service server 400 does not download the asset from the content server CS, and the cloud service server 400 downloads the asset for download. A link (eg, source URI or URL) can be provided.
  • a link eg, source URI or URL
  • the second client device CD2 transmits a wake up request to the first client device CD1.
  • the wake up request may be made via NFC.
  • the first client device CD1 wakes up, switches to the active mode, and requests an asset for download (S920). Requests for assets can also be made via NFC.
  • the second client device CD2 transmits the wake-up request through another wireless communication network such as WLAN, 3G / 4G.
  • the second client device CD2 may transmit an asset of the downloaded content to the first client device CD1 (S922).
  • the first client device CD1 may receive the downloaded content through the synchronization function of the cloud service.
  • FIG. 10 is a diagram illustrating a content download method using NFC according to another embodiment of the present invention, wherein a first client device CD1, a second client device CD2, a third client device CD3, and a content server CS are illustrated. It is a figure for explaining the flow of the signal transmitted / received between.
  • the third client device CD3 may refer to client devices other than the first and second client devices CD1 and CD2, and may also include a cloud service server 400.
  • the third client device CD3 may be another home appliance (eg, a smart TV) included in the same home network, and may be capable of NFC communication.
  • the first client device CD1 transmits a content download request to the NFC-enabled third client device CD3 via the NFC interface (S1010).
  • the third client device CD3 transmits a confirmation message for the content download request to the first client device CD1 through the NFC interface (S1012).
  • the third client device CD3 may forward the content download request to the second client device CD2 so that the second client device CD2 downloads the content asset from the content server CD later (S1014). ). That is, the third client device CD3 may serve as a relay of the content download request.
  • the third client device CD3 has a storage device (eg, a USB drive, HDD, flash memory, etc.), the asset may be directly downloaded from the content server CS to its storage device.
  • the second client device CD2 receiving the content download request from the third client device CD3 downloads the asset of the requested content from the content server CS in operation S1016. Then, the third client device CD3 and the second client device CD2 exchange states of the download request with each other (S1018). Then, the second client device CD2 transmits a wake up request to the first client device CD1.
  • the wake up request may be made via NFC.
  • the first client device CD1 wakes up, switches to the active mode, and requests an asset for download (S1020). Requests for assets can also be made via NFC. However, if the confirmation message for the wake-up request transmitted through NFC is not received during the reference time, the second client device CD2 transmits the wake-up request through another wireless communication network such as WLAN, 3G / 4G.
  • the second client device CD2 may transmit the asset of the downloaded content to the first client device CD1 (S1022).
  • FIG. 11 is a diagram illustrating a method of downloading and transmitting content between a first client device CD1, a second client device CD2, and a content server CS according to an exemplary use example of a content download method using NFC according to another embodiment of the present invention. Sequence diagram of the signal.
  • the queue / policy engine 123 (QPE) of the first client device CD1 manages a queue request (content download request) and a process of content download derived from the queue request.
  • the intermediate device manager 124 of the first client device CD1 Prior to sending the queue request, the intermediate device manager 124 of the first client device CD1 discovers the second client device. That is, the first client device CD1 discovers accessible devices by utilizing a list of recently connected devices. It is assumed that the second client device CD2 is registered in the recently connected device list. The procedure related to the recent connected device list will be described below with reference to FIGS. 19 to 24.
  • the first client device CD1 After discovering the second client device CD2, first, the first client device CD1 obtains a source URI of content to be downloaded from the content server CS (S1110).
  • the first client device CD1 wakes up the second client device CD2 using the NFC interface (S1112).
  • the wake up may be performed by transmitting a wake up request.
  • the second client device CD2 may transmit a response to the wake up request to the first client device CD2 (S1114).
  • the response may include information that it is ready to receive the queue request.
  • the first client device CD1 Upon receiving the response to the wake-up request, the first client device CD1 transmits a queue request for storing an asset in the second client device CD2 (S1116).
  • the queue request may include download related information including a source URI.
  • NFC-related information network interface information for simplifying or automating NFC link setup and related protocols, device wake-up policy information for NFC, and content download request events (eg, content download request events are performed and It may include at least one of the information associated with the automatic device to device (D2D) notification message for the stop (it may include a stop event).
  • the content download request is information related to the downloaded content receiving condition of the first client device CD1 when the second client device CD2 completes the download, and includes power connection state information, battery state information, and network state information. And storage available space information.
  • the second client device CD2 Upon receiving the queue request, the second client device CD2 checks the queue request and transmits a confirmation message to start the download of the asset to the first client device CD1 (S1118).
  • the second client device CD2 When the first client device CD1 receives the confirmation message from the second client device CD2, the second client device CD2 enters a sleep mode while downloading the content (S1120). In this case, a predetermined time may be determined, and a wake-up may be performed in the sleep mode through a timer event. When the wake-up request is received from the second client device CD2, the wake-up may be set. Such configuration information may be included in the queue request.
  • the second client device CD2 downloads an asset of content downloaded from the content server CS in operation S1122.
  • the second client device CD2 may find the corresponding address through the source URI included in the queue request and download the content.
  • the second client device CD2 may notify that the download of the asset of the content to be downloaded to the first client device CD1 is completed (S1126).
  • the wake-up request may be transmitted to the first client device CD1 through NFC to notify that the second client device CD2 is completed without transmitting a separate completion message in operation S1128.
  • the first client device CD1 When the first client device CD1 receives the wake-up request through the NFC interface, the first client device CD1 performs a wake-up, switches from the sleep mode to the active mode, and requests an asset for download (S1130). However, at this time, the first client device CD1 determines whether to receive the downloaded content based on its state information (for example, a power connection state, a battery level, a network state, and a storage available space state) to request an asset. You can decide whether to send. If the reception condition is satisfied, the first client device CD1 transmits an asset request to the second client device CD2, and if it is not satisfied, the download content is stored only in the second client device CD2. Asset request may not be sent.
  • state information for example, a power connection state, a battery level, a network state, and a storage available space state
  • the second client device CD2 may transmit the downloaded content (S1132).
  • the second client device CD2 may determine whether to download the download content.
  • the second client device CD2 may determine whether to transmit the content to the first client device CD1 in consideration of the size of the downloaded content, its battery level, or a wireless communication resource.
  • FIG. 12 is a diagram illustrating a method of downloading and transmitting content between a first client device CD1, a second client device CD2, and a content server CS according to an exemplary use example of a method for downloading content using NFC according to another embodiment of the present invention.
  • Sequence diagram of the signal when the second client device CD2 cannot wake up the first client device CD1 by NFC after the download is completed, the wake-up may be performed using WLAN or 3G / 4G wireless communication. have.
  • the intermediate device manager 124 of the first client device CD1 discovers the second client device. That is, the first client device CD1 discovers accessible devices by utilizing a list of recently connected devices. Like the embodiment of FIG. 11, it is assumed that the second client device CD2 is registered in the recently connected device list.
  • the first client device CD1 After discovering the second client device CD2, first, the first client device CD1 obtains a source URI of content to be downloaded from the content server CS (S1210).
  • the first client device CD1 wakes up the second client device CD2 using the NFC interface (S1212).
  • the second client device CD2 may transmit a response to the wake-up request to the first client device CD2 in operation S1214.
  • the response may include information that it is ready to receive the queue request.
  • the first client device CD1 Upon receiving the response to the wake-up request, the first client device CD1 transmits a queue request to store the asset in the second client device CD2 (S1216).
  • the queue request may include at least one of download related information including a source URI, NFC related information, setting information related to a reception condition of the download content, and state information for receiving the download content.
  • the second client device CD2 Upon receiving the queue request, the second client device CD2 checks the queue request and transmits a confirmation message to start the download of the asset to the first client device CD1 (S1218).
  • the second client device CD2 When the first client device CD1 receives the confirmation message from the second client device CD2, the second client device CD2 enters the sleep mode while downloading the content (S1220). In this case, a predetermined time may be determined, and a wake-up may be performed in the sleep mode through a timer event. When the wake-up request is received from the second client device CD2, the wake-up may be set. Such configuration information may be included in the queue request.
  • the second client device CD2 downloads an asset of content downloaded from the content server CS in operation S1222.
  • the second client device CD2 may find the corresponding address through the source URI included in the queue request and download the content.
  • the second client device CD2 may notify that the download of the asset of the content to be downloaded to the first client device CD1 is completed (S1226).
  • the wake-up request may be transmitted to the first client device CD1 through NFC to notify that the second client device CD2 is completed without transmitting a separate completion message (S1228).
  • the wakeup request may include information that the next load is completed.
  • the second client device CD2 may determine that the target device of the NFC is not found (S1230).
  • the second client device CD2 transmits a wake-up request to inform that the asset download is completed through WLAN or 3G / 4G wireless communication (S1232).
  • wake-up may be performed through UPnP or DLNA.
  • the first client device CD1 When the first client device CD1 receives the wake-up request through WLAN or 3G / 4G wireless communication, the first client device CD1 performs a wake-up to switch from the sleep mode to the active mode, and requests the asset for download (S1234).
  • the second client device CD2 may transmit the downloaded content (S1236).
  • FIG. 13 illustrates a method of transmitting and receiving content between a first client device CD1, a second client device CD2, and a content server CS according to an exemplary use example of a method for downloading content using NFC according to another embodiment of the present invention.
  • the content server CS (where the content server CS may be the cloud service server 400) sends a queue request to the second client device CD2, and the second client device CD2.
  • the first client device CD1 cannot wake up via the NFC interface, and performs wake up using WLAN or 3G / 4G.
  • the intermediate device manager 124 of the first client device CD1 discovers the second client device. That is, the first client device CD1 discovers accessible devices by utilizing a list of recently connected devices. Like the embodiment of FIG. 11, it is assumed that the second client device CD2 is registered in the recently connected device list.
  • the first client device CD1 After discovering the second client device CD2, first, the first client device CD1 obtains a source URI of content to be downloaded from the content server CS (S1310).
  • the first client device CD1 transmits a queue request to the content server CS to store the asset in the second client device CD2 (S1312).
  • the queue request may include at least one of a source URI, download related information including a download / wake up time, NFC related information, setting information related to a reception condition of the download content, and state information for receiving the download content. .
  • the content server CS Upon receiving the queue request, the content server CS checks the queue request and checks whether the second client device CD2 is currently on (S1314). That is, the second client device CD2 checks whether the sleep mode or the power is turned off.
  • the content server CS requests a queue to store the asset using the WLAN or 3G / 4G wireless communication network.
  • the wake-up request for notifying the request is transmitted to the second client device CD2.
  • the content server CS downloads the asset to the second client device CD2 (S1318). That is, the second client device CD2 downloads the asset of the content downloaded from the content server CS.
  • the second client device CD2 may find the corresponding address through the source URI included in the queue request and download the content.
  • the confirmation message indicating that the download of the asset is started is transmitted to the first client device CD1 (S1320).
  • the order of starting the download and sending the confirm message can be reversed.
  • the second client device CD2 When the first client device CD1 receives the confirmation message from the content server CS, the second client device CD2 enters the sleep mode while downloading the content (S1322). In this case, a predetermined time may be determined, and a wake-up may be performed in the sleep mode through a timer event. When the wake-up request is received from the second client device CD2, the wake-up may be set. Such configuration information may be included in the queue request.
  • the second client device CD2 may notify that the download of the asset of the content to be downloaded to the first client device CD1 is completed (S1326).
  • the wake-up request may be transmitted to the first client device CD1 through NFC to notify that the second client device CD2 is completed without transmitting a separate completion message in operation S1328.
  • the wakeup request may include information that the next load is completed.
  • the second client device CD2 may determine that a target device of NFC has not been found (S1330).
  • the second client device CD2 transmits a wake-up request to inform that the asset download has been completed through WLAN or 3G / 4G wireless communication (S1332).
  • the first client device CD1 When the first client device CD1 receives the wake-up via WLAN or 3G / 4G wireless communication, the first client device CD1 performs a wake-up to switch from the sleep mode to the active mode, and requests the asset for download (S1334).
  • the second client device CD2 may send the downloaded content (S1336).
  • FIG. 14 illustrates a first client device CD1, a second client device CD2, a third client device CD3, and a method of downloading a content using NFC according to another exemplary embodiment of the present invention.
  • the third client device CD3 relays the queue request to the second client device CD2.
  • the intermediate device manager 124 of the first client device CD1 discovers the second client device. That is, the first client device CD1 discovers accessible devices by utilizing a list of recently connected devices. Like the embodiment of FIG. 11, it is assumed that the second client device CD2 is registered in the recently connected device list.
  • the first client device CD1 After discovering the second client device CD2, first, the first client device CD1 obtains a source URI of content to be downloaded from the content server CS (S1410).
  • the first client device CD1 transmits a queue request to store the asset in the second client device CD2 to the third client device CD3.
  • the queue request may include at least one of a source URI, download related information including a download / wake up time, NFC related information, setting information related to a reception condition of the download content, and state information for receiving the download content.
  • the third client device CD3 may check the queue request and transmit a confirmation message to the first client device CD1 that the queue request has been well received (S1414).
  • the second client device CD2 When the first client device CD1 receives the confirmation message from the content server CS, the second client device CD2 enters the sleep mode while downloading the content (S1416).
  • the third client device CD3 checks whether the second client device CD2 is currently on, and if the second client device CD2 is in the sleep mode at the wake up time included in the queue request, the WLAN Alternatively, the wake-up request is transmitted to the second client device CD2 using the 3G / 4G wireless communication network in operation S1418.
  • the third client device CD3 After waking the second client device CD2, the third client device CD3 forwards the queue request (S1420). After performing the wake-up, the second client device CD2 may transmit a response to the queue request to the third client device CD3 (S1422).
  • the second client device CD2 downloads the asset of the content downloaded from the content server CS (S1424).
  • the second client device CD2 may find the corresponding address through the source URI included in the queue request and download the content.
  • the second client device CD2 may notify that the download of the asset of the content to be downloaded to the first client device CD1 is completed (S1428). Instead of transmitting a separate completion message, the wake-up request may be transmitted to the first client device CD1 through NFC in order to inform that the second client device CD2 is completed (S1438).
  • the wakeup request may include information that the next load is completed.
  • the second client device CD2 and the third client device CD3 may exchange queue request status. For example, the second client device CD2 may exchange information related to whether the download is complete or in progress by the queue request.
  • the second client device CD2 may determine that a target device of NFC has not been found (S1432).
  • the second client device CD2 transmits a wake-up request to inform that the asset download has been completed through WLAN or 3G / 4G wireless communication (S1434).
  • the first client device CD1 When the first client device CD1 receives the wake up via WLAN or 3G / 4G wireless communication, the first client device CD1 performs a wake up to switch from the sleep mode to the active mode, and requests the asset for download (S1436).
  • the second client device CD2 may send the downloaded content (S1438).
  • FIG. 15 is a diagram illustrating an example of a user interface capable of inputting settings in connection with a client application of a content download method using NFC according to another embodiment of the present invention.
  • the first client device CD1 may control basic settings of a client application through a user interface (UI).
  • the user can set to enable Auto Queued Download.
  • the enable automatic queue download setting may be controlled in an on off manner. If you enable the Enable automatic queue download setting, it automatically downloads the contents of the queue on the client device.
  • a target device for example, a second client device or an intermediate device
  • the intermediary device manager 124 discovers client devices, with smartphone 1, user tablet 1 and user TV 1 registered. The user may designate only the smartphone 1 and the user TV 1 as neighbor devices, and designate a target device to receive a content download by transmitting a queue request.
  • the user may control the download setting of the first client device CD1 through the user interface. This can be used to determine whether to receive the downloaded completed content from the second client device CD2 when executing the automatic queue download.
  • the download may be set only when the battery is charged at a specific ratio (for example, 40%, 50% 60%, 70%, etc.) or more.
  • the notification-related settings through the wake-up according to the network status, and may select whether to use NFC, WLAN, 3G / 4G wireless network, or multiple network interfaces.
  • the user may control the download setting of the second client device CD2 through the user interface. This may be used by the second client device CD2 to determine whether to perform a download by a queue request based on the power connection state, battery state, and network state.
  • the user may control the download storage setting of the first client device CD1 through the user interface. That is, the download storage area can be allocated. For example, it is possible to select whether to use an external storage device. For example, when using an external memory such as a USB, HDD, or flash memory, the external storage device may be set to be used, and the available memory may be selected. Percentage allocation can be performed through the download storage area allocation setting. It can be set to store the downloaded content up to a certain percentage of the storage means of the client device. In addition, the user may directly enter a storage size for storing downloaded content. For example, if the user sets the size allocation of 2GB, the downloaded content is downloaded only up to 2GB, and the download is not performed for the capacity exceeding this.
  • an external storage device such as a USB, HDD, or flash memory
  • Percentage allocation can be performed through the download storage area allocation setting. It can be set to store the downloaded content up to a certain percentage of the storage means of the client device.
  • the user may directly enter a storage size for
  • the user can control the download setting of the second client device CD2 via the user interface. This may be used by the second client device CD2 to determine whether to perform a download by a queue request based on the state of the storage available space of the second client device CD2.
  • the information set through the user interface may be transmitted to the second and third client devices CD2 and CD3 by including the corresponding information in the queue request.
  • an exemplary data format for a QueueRequest between the queue / policy engine 120 (QPE) of the client device is as follows.
  • the data format of the queue request "QueuerRequest” contains a plurality of attribute information, information about whether the use is required accordingly (marked as “required” if necessary), and the type of the attribute information. May be included.
  • the queue request "QueueRequest” contains "SourceURI” information (which can be expressed as a string) that is at least one source URI where the content can be found, and "Store_Name” information (string that is used to store cached objects on the virtual storage device).
  • "Type” information (which can be represented as a string) and bytes of MIME content type information of the cached object, as described in IETF RFC 2045, IETF RFC 2046, IETF RFC 4288, IETF RFC 2231.
  • “TotalLength” information (which may be data of a long type), which is size information of an object cached, may be included.
  • the name of the virtual storage device of the second client device CD2 may be provided in the "Store_Name".
  • the value “Type” may be plural, and may be described by being separated by commas.
  • the "TotalLength” information is mandatory when the URI describes a scheme that requires a fixed size object.
  • the queue request may include "policy” information, which is policy structure information set by calling an origin.
  • the queue request may include "key” information, which is DOMString information for identifying a key associated with a stored value.
  • the queue request may include "RequestID" information provided with the unique ID that is set when the request is supplied.
  • the queue request also includes " PullCondition" information which is reception condition information for the download content of the first client device CD1. More specifically, when the first client device CD1 receives the content downloaded by the second client device CD2, whether the content is received by comparing the state of the first client device CD1 based on the reception condition Can be determined.
  • the "PullCondition” information includes “ChargingStatus” information, which is information related to a power connection state, "BatteryPower” information, battery status information, "NetworkConnection” information, which indicates network connection status, and "AvailableMinimumStorage” information, which is status information of a storage available space. At least one of them may be included.
  • "ChargingStatus” information may be expressed as “available”, “charging”, “unavailable”, and “error”.
  • the “ChargingStatus” information is a capability item indicating a charging state of the battery in relation to the power connection, and the value may be information in a string form. If the “ChargingStatus” value is “available”, it indicates that the battery is installed in the device and that the downloaded content can be received when the installed battery is currently working. If “charging”, the device “Unavailable” indicates that the download content can be received when the battery is installed and currently charging, and “unavailable” indicates that the download content can be received even when the battery is not installed on the device. Even if the battery is installed but fails to perform the function correctly, this may indicate that the download content can be received.
  • the “BatteryPower” information can also indicate the current battery level. For example, “30” may mean that 30% of the current total battery amount remains to receive the download content. “BatteryPower” information may be expressed from “0" to "100".
  • the "NetworkConnection” information indicates a connection state condition of a wireless network used between devices transmitting and receiving queue requests.
  • CELL3G or “CELL4G” means a 3G or 4G wireless network
  • WLAN means a WLAN wireless network is connected
  • NFC may allow content reception only when NFC communication is connected.
  • the queue request may include information set to a specific percentage or more of the total storage as minimum available storage space information. For example, when the "AvailableMinimumStorage” information is "40", this may mean that 40% or more of storage space is secured. "AvailableMinimumStorage” information may be expressed from “0" to "100”. In addition, the "AvailableMinimumStorage” information may directly include size information of a certain storage space. For example, "2G” may mean that 2 GB of storage space is required.
  • the first client device CD1 or the second client device CD2 determines whether to receive or transmit the asset of the download content to the first client device CD1 to receive or transmit the asset. Can be.
  • the message to be transmitted to the second client device CD2 through NFC includes a RequestID, which is an ID for identifying a queue request, and a Source URI, which is a URI of content to be downloaded, (or a URL, SourceURL). can do.
  • information on a condition in which the first client device CD2 receives the content may include a power connection state (ChargingStatus) and a battery state (BatteryPower). ), A network state (NetworkConnection) and the storage available space state (AvailableMinimumStorage) at least one.
  • SourceURI "http://www.example.com/asset-test.avi">
  • the name of the queue request is "NFC_QueueRequest”
  • the RequestID which is the ID to identify the queue request
  • the source URI SourceURI
  • source URL which is the URI or URL of the content to download.
  • the "ChargingStatus” information indicates “charging” indicating that the download content can be received when the charging state is in progress. Therefore, when the first client device CD1 is not in the charging state, the first client device CD1 does not satisfy the content reception condition and thus cannot receive the download content.
  • the "BatteryPower” information indicates “30" that the download content is currently received when 30% of the total battery amount remains. If the battery power is less than 30%, the download content may not be received.
  • the "NetworkConnection” information is "NFC ⁇ WLAN” which receives content only when the WLAN wireless network is connected and the NFC communication is connected, but the content may not be received in the network state where the WLAN or NFC is not connected.
  • the "AvailableMinimumStorage” information is set to "30". At least 30% of the storage is reserved to receive the download content.
  • the queue request may include NFC-related information. As described above, this may include NFC tag type information and NFC mode information.
  • Type 1/2/3/4 (Type 1/2/3/4) included in the NFC tag type information “NFCType” is a type described in v1.0 or v2.0 related to the device WG of the NFC forum.
  • RF interfaces, speeds, and protocols may be defined differently.
  • the NFC mode information "NFCMode” may also be a card emulation, peer-to-peer, lead-write mode, as defined in the NFC forum.
  • the card emulation mode refers to a mode that is always recognized by the reader regardless of whether the terminal is on or off
  • the peer-to-peer mode refers to a mode in which two NFC mobile phones operate as card readers to transmit data to each other.
  • the light mode may indicate a mode in which the mobile phone operates as a card reader by recognizing RFID tag information in an NFC activated state.
  • the NFC-related information may further include ID information for identifying the NFC tag with the NFC tag ID information "NFCID".
  • the queue request may include the following characteristic information with respect to the asset.
  • “Asset_name” information which is the name of an asset used to store an object cached in virtual storage
  • “Asset_size” information which indicates the size of a cached object in bytes, and the source from which the asset is retrieved using the D interface.
  • URI “Asset_Source_URI” information, “Asset_Origin” information that owns the asset, “Asset_Locked” information that identifies whether the asset is locked, and “Asset_Type” information that describes the MINE type of the cached object ( This information can be derived from the “Type” information above), “Asset_Metadata” information, which is optional metadata information that can be specified using an XML specification, “Asset_Policy” information, which is an effective policy as an XML string, “Asset_Contentprofile” information, which is the content profile supported by the client device, can be performed before transitioning to the active state.
  • “Asset_Rightcheck” information which is the authorization check information to be performed
  • “Asset_Validitychech” information which is VSD-specific validation information to be performed before consuming or playing the content asset
  • “Asset_Playlist” which indicates that the asset belongs to the playlist file.
  • Information “Asset_Ismpd” information indicating that the asset is a playlist in the form of an MPD file
  • “Asset_Unsolicited” information indicating that the asset is not solicited by the user, and at least one asset accessed from the cache to be rendered. It may include at least one of "Asset_Geolocation” information indicating a location and "Asset_Location_Cell_ID” information indicating at least one location where an asset is accessed by CellID.
  • FIG. 16 illustrates an example of a user interface for inputting a content list, a download time, and a content download related setting through a client application of a content download method using NFC according to another embodiment of the present invention.
  • the first client device CD1 may browse the content list.
  • the user can select content to be added to the queue via the user interface.
  • the plurality of contents may be provided to the user by ranking the current download number in the order of high.
  • the user may be provided with a list of the plurality of contents that recorded the most number of downloads in the past week.
  • the user may add desired content among the provided contents to the queue.
  • the user may set the cloud service to automatically select the recommended content by acquiring the user's preferred content information through the user's SNS video content.
  • a user may place a first client device CD1 (smartphone 1 in this embodiment) on a second client device CD2 (NAS in this embodiment) capable of NFC. .
  • NFC may be located within a certain radius possible.
  • the smartphone 1 can indicate the target device (NAS in this embodiment) and the cue item information.
  • the user selects and confirms that the target device executes the queue request.
  • This step may be omitted by default setting or user setting (eg, automatic queue download setting). In other words, when the smartphone 1 is automatically placed on the NAS, it can control the NAS to download an item currently in the queue.
  • the first client device CD1 (smartphone 1 in this embodiment) sends a queue request to the second client device CD2 (NAS in this embodiment) and enters a sleep mode. do.
  • the NAS then starts downloading (specifically given the time (eg download / wakeup time)).
  • the NAS wakes up the smartphone 1 via NFC. If the wakeup cannot be performed through NFC, the smartphone 1 is woken up through a specific network interface (for example, WLAN or 3G / 4G). Smartphone 1 represents the queue request executed and the assets are ready to be sent from the NAS to smartphone 1. When the user selects local download, the selected asset is sent from the NAS to smartphone 1.
  • a specific network interface for example, WLAN or 3G / 4G.
  • FIG. 17 is a flowchart schematically illustrating an operation of a first client device CD1 in a content download method using NFC according to another embodiment of the present invention.
  • the first client device CD1 first transmits a content download request to download content using NFC to the second client device CD2 using NFC (S1710).
  • the second client device CD2 stays in a wait state until a response indicating that the download request is well received (S1712).
  • the first client device CD1 may receive a confirmation message indicating that the download request is well received from the second client device CD2 (target device) (S1714).
  • the second client device CD2 When the second client device CD2 receives the message that the download has started (S1716), it waits for a predetermined time in the wait mode (S1718). Enter the sleep mode (S1720). At this time, it may enter the sleep mode by a timer event. If a message that cannot be downloaded is received, content download may be terminated.
  • the first client device CD1 in the sleep mode may complete a download from the second client device CD2 and complete the wake up request.
  • the first client device CD1 receives the wake up request, the first client device CD1 performs a wake up to switch from the sleep mode to the active mode (S1724). Then, the response message for the wake up is transmitted to the second client device CD2 (S1726).
  • the download content may be received from the second client device CD2 (S1730).
  • the user in relation to the receiving condition of the asset, the user may control at least one of a power connection state, a battery state, a network state, and a state of a storage space through a user interface, and the first client device CD1. May determine whether an asset is received in consideration of the reception condition and the current state thereof.
  • FIG. 18 is a flowchart schematically illustrating an operation of the second client device CD2 in the method of downloading content using NFC according to another embodiment of the present invention.
  • the second client device CD2 may receive a content download request from the first client device CD1 using NFC (S1810).
  • S1812 a response indicating that the download request has been received is transmitted to the first client device CD1.
  • the second client device CD2 determines whether download is possible. If the content download request includes at least one of a download condition of the second client device CD2 (eg, a power connection state, a battery state, a network state, and a storage available space state of the second client device CD2). The second client device CD2 may determine whether it is downloadable. Alternatively, the second client device CD2 itself determines whether the download is not possible even when there is no special download condition, when there is no battery, when the power is turned off, when there is no storage space, or when other work is required at the download / wakeup time. can do.
  • a download condition of the second client device CD2 eg, a power connection state, a battery state, a network state, and a storage available space state of the second client device CD2.
  • the second client device CD2 may determine whether it is downloadable.
  • the second client device CD2 itself determines whether the download is not possible even when there is no special download condition, when there is no battery, when the power is turned off, when there is no storage
  • a response indicating that the download is impossible is transmitted to the first client device CD1 (S1816), and the download process is terminated. If the download is possible, a confirmation message to start downloading is transmitted to the first client device CD1 (S1918).
  • the content is downloaded (1820).
  • the first client device CD1 transmits a wake-up request using NFC (S1824).
  • NFC NFC wake-up request
  • S1836 it is determined whether there is a response to the WLAN wake-up request. If there is a response, a response indicating that the download is completed may be transmitted to the first client device CD1 (S1828).
  • step S1826 if there is a response to the NFC wake-up request, the download completion message may be immediately transmitted to the first client device CD1 (S1828).
  • the second client device CD2 determines whether the first client device CD1 can receive the downloaded content in consideration of the download content reception condition included in the content download request.
  • the second client device CD2 directly checks its own state to determine whether a condition for transmitting content is satisfied. For example, in consideration of the size or capacity of the currently downloaded content, it may be determined whether to transmit the asset in comparison with the battery state, the power connection state, and the network state of the current second client device CD2.
  • the second client device CD2 transmits the content to the first client device CD1 ( S1832) Otherwise, terminate without transmitting the content.
  • FIG. 19 is a flowchart illustrating a device discovery method according to an exemplary embodiment of the present invention, and exemplarily illustrates a process in which a client device (CD) discovers intermediate devices (IMDs) connected to a network in a content service system.
  • the client device CD may be the first client device CD1
  • the intermediate device IMD may be the second client device CD2.
  • the client device CD manages a Recently Connected Device List by the respective device manager 124 (step: S1).
  • the received connected device list may mean a list of devices (eg, an intermediate device, another client device, etc.) that have recently been connected with the client device CD through the local network.
  • the list of connected devices may be stored in the storage of the client device CD, for example, the virtual storage device 150.
  • the client device (CD) generates a listened connected list using the information obtained through device discovery when first connected to the network, stores it in storage, and then acquires the device each time the device discovery is performed. Based on this information, you can constantly update the listened connected list.
  • the listened connected device list includes a device friendly name, an IP address, a port number, and a last connected time of each device. ), Raster connected network access type (Last Connected Network Access Type) and the like.
  • the device friendly name, IP address, and port number may be string type information representing the friendly name, IP address, and port of the device, respectively.
  • the last connected time may indicate, for example, the time when the signal was last transmitted or received with the device.
  • the last connected network access type may mean a connection type indicating how the device is connected to the network.
  • the last connected network access type may be string type information indicating at least one of Ethernet, 802.11, MoCA, Bluetooth, ZigBee, and the like.
  • the listened connected device list may include a device description (Device Description).
  • the device description may be connection information, for example, a URI, a URL, and the like, which may access information of a device such as device capability.
  • the client device CD may acquire the capability information of the device by using the URI or URL of the device description at the time of device discovery.
  • Device discovery performed by the client device CD may be automatically started when the client device CD connects to the local network or may be started according to a device discovery request from the user to the local application 110.
  • the client device CD may unicast the unicast device discovery request message to devices with a history of recently connected in the network based on the listened connected device list. For example, in the description of the present embodiment, it is assumed that information of the first intermediate device IMD1 is included in the received connected device list.
  • the client device CD may unicast the unicast device discovery request message to the first intermediate device IMD1 based on the listened connected device list (step S2).
  • Each device receiving the unicast device discovery request message may transmit a unicast device discovery response message to a client device (CD) in response to the unicast device discovery request message.
  • the first intermediate device IMD1 may transmit a unicast device discovery response message to the client device CD in response (step S3).
  • the client device CD may update the listened connected device list based on the received unicast device discovery response message (step: S4).
  • the intermediary device manager 124 of the client device may be the last connected time, the last connected time of the first intermediary device (IMD1) on the listened connected device list according to the information included in the unicast device discovery response message. You can update the connected network access type with new information.
  • 21 is an exemplary diagram illustrating a structure of a unicast device discovery message used for a unicast device discovery request or response.
  • the unicast device discovery message includes a message code field.
  • the message code may be information for identifying whether the message is a request message or a response message.
  • the unicast device discovery message also includes at least one unicast device discovery entry field.
  • the unicast device discovery entry field may include a device friendly name field into which a device friendly name is inserted, an IP address field into which an IP address is inserted, a port number field into which a port number is inserted, and a last connected type into which a last connected time is inserted. Field, a network access type field into which a network access type is inserted, and the like.
  • the unicast device discovery message may also include a device information item field.
  • the device information item field may be used to acquire various information of a device where the client device CD is discovered, for example, the first intermediate device IMD1.
  • the client device CD may insert information to be acquired into the device information item field of the unicast device discovery request message, for example, information of a device capability item, and transmit the same to the first intermediate device IMD1.
  • the first intermediate device IMD1 may insert the information of the requested first intermediate device IMD1 into the device information item field of the device discovery response message and transmit it to the client device CD. Then, the client device CD may update the information of the first intermediate device IMD1 based on the received information of the first intermediate device IMD1.
  • the client device CD having updated the listened connected device list may update the active device list (step: S5).
  • the active device list may be information representing network devices that are currently active. For example, since the first intermediate device IMD1 that has transmitted the unicast device discovery response message is currently in an active state, the client device CD may indicate that the state of the first intermediate device IMD1 is active. You can update the list.
  • the local application 110 of the client device CD may display the updated active device list or the updated listened connected device list on the screen of the client device CD. Therefore, the user can quickly identify the devices on the network currently available through the active device list or the listened connected device list displayed on the screen of the client device CD.
  • the client device CD may multicast (or broadcast) a multicast device discovery request message to a device connected to a network.
  • the client device CD may transmit a multicast device discovery request message to the first intermediate device IMD1 and the second intermediate device IMD2 (steps S6 and S7).
  • the second intermediate device IMD2 may transmit a multicast device discovery response message to the client device CD in response to the multicast device discovery message received from the client device CD (step S9).
  • the multicast device discovery response message may be transmitted to the client device CD, but may not be transmitted if the unicast message has already been sent to the client device CD (step: S8). .
  • the client device CD may update the listened connected device list based on the received multicast device discovery response message (step S10). For example, the intermediate device manager 124 of the client device CD may newly add information of the second intermediate device IMD2 to the listened connected device list.
  • the client device CD may update the active device list based on the received multicast device discovery response message.
  • the local application 110 may display the newly updated active device list or the updated listened connected device list on the screen of the client device CD.
  • the client device CD manages recently connected devices through a listened connected device list.
  • the client device (CD) can quickly discover devices on the listened connected device list based on unicast by checking the listened connected device list.
  • the user can quickly check available network devices first, even before the multicast-based device discovery is completed.
  • the device discovery may be applied to various network systems based on Universal Plug and Play (UPnP), Digital Living Network Alliance (DLNA), etc. as well as the illustrated content service system.
  • UPF Universal Plug and Play
  • DLNA Digital Living Network Alliance
  • a DLNA device such as a digital media controller (DMC) typically discovers almost the same device each time device discovery is performed in the same network domain, such as a home network or an office domain.
  • DMS digital media server
  • DMR digital media renderer
  • the DMC may store device information including a device profile and description file connected to the network domain.
  • the device information may be, for example, a listened connected device list.
  • the DMC leaves the network domain, the DMC can manage the device information.
  • the DMC when the DMC enters the network, the DMC sends a unicast message containing a device profile to the devices using the IP address registered in the device information based on the device information. Each can be transmitted. That is, device discovery is performed based on transmitting a unicast message to IP addresses of recently connected devices. Accordingly, the DMC may first display recently connected devices through the user interface.
  • FIG. 22 illustrates a content download procedure based on device discovery and device capability exchange.
  • the client device CD may be provided with a list of contents (for example, media) from the content server CS, and may select media to be downloaded (step S11).
  • the user wants to download the selected media using an intermediate device connected to the network based on the control of the client device (CD).
  • the client device CD may perform a device discovery procedure with the first intermediate device IMD1 (step S12).
  • the device discovery procedure may be performed by the procedure described with reference to FIG. 4.
  • the intermediate device manager 124 of the client device (CD) sends a unicast device discovery request message to the first intermediate device (IMD1) based on the listened connected device list. Send and receive a unicast device discovery response message from the first intermediary device IMD1 in response.
  • the intermediate device manager of the client device CD may transmit a device capability request message for requesting device capability of the first intermediate device IMD1 to the first intermediate device IMD1 (step: S13).
  • the first intermediate device IMD1 may transmit a device capability response message including the requested device capability to the client device CD (step S14).
  • the device capability may be information in the form of Extensible Markup Language (XML), and may include a plurality of capability items.
  • the client device CD uses the structure of the unicast device discovery message shown in FIG. 21 to determine the device capability of the first intermediate device IMD1 when performing device discovery without a device capability request / response. Can also be obtained.
  • the client device CD may insert information of a device capability item to be acquired into the device information item field of the unicast device discovery request message and transmit the information to the first intermediate device IMD1.
  • the first intermediate device IMD1 may insert the requested device capability items into the device information item field of the unicast device discovery response message and transmit the requested device capability items to the client device CD. Therefore, the device capability of the first intermediate device IMD1 may be delivered to the client device CD through the device discovery procedure. In this case, a separate device capability request and response procedure may be omitted.
  • the client device CD having obtained the device capability of the first intermediate device IMD1 may generate a queue request for requesting to download the selected media from a specific entity based on the device capability. (Step: S15).
  • the queue manager of the first intermediate device IMD1 may send a queue request to the first intermediate device IMD1 via the Q3 interface.
  • the queue request may include access information for allowing the first intermediate device IMD1 to download an asset, eg, a media file, suitable for the capability of the first intermediate device IMD1.
  • the queue request may include an identifier for identifying the selected media, an asset to substantially download corresponding to the media, for example, access information for identifying and accessing a media file, and the like.
  • the access information may be information for identifying and accessing a physical 'Avatar file' to be actually downloaded.
  • the access information may include information in the form of URL, URI, file name.
  • the client device CD delivers information to download the media file suitable for the capability of the first intermediate device IMD1 to the first intermediate device IMD1 through a queue request.
  • the client device CD uses the device capability of the first intermediate device IMD1 received from the first intermediate device IMD1 to store storage capacity and storage retention of the first intermediate device IMD1,
  • the media profile may be checked, and the first media device IMD1 may be transmitted to the first mediator device IMD1 through the queue request to download the media corresponding to the downloadable size and the supportable media profile.
  • the first intermediate device IMD1 Upon receiving the queue request, the first intermediate device IMD1 connects to the content server based on the information included in the queue request, and corresponds to the selected media and outputs a media file corresponding to the first media device IMD1. Can be downloaded from the server (step: S16).
  • the client device CD transmits a queue request according to whether a specific device capability of the first intermediate device IMD1 satisfies the policy, based on a policy managed by the client device CD. May be determined.
  • the policy client 140 of the client device CD may store and manage a policy received from the content policy server 300.
  • the policy client 140 determines whether a specific device capability received from the first intermediate device IMD1 satisfies a specific policy, and if so, transmits a queue request to the first intermediate device IMD1. If it is not satisfied, the queue request may be blocked and an error message may be output through the local application 110 or the like.
  • the client device CD uses the device capability delivered from the first intermediate device IMD1 to check the storage capacity and storage indication of the first intermediate device IMD1, and the media file to be downloaded allowed by the policy. It is possible to check whether the size of P is smaller than the remaining storage size of the first intermediate device IMD1. If the size of the media file to be downloaded is larger than the remaining storage size of the first intermediate device IMD1, the client device CD may output an error message and not transmit a queue request.
  • the client device uses the device capability delivered from the first intermediate device (IMD1) and the first intermediate device (IMD1). If the Wi-Fi (802.11) does not exist in the network access type of the first intermediate device (IMD1), an error message may be output and the queue request may be blocked.
  • Wi-Fi 802.11
  • the client device CD allows downloading only if the policy of the first intermediate device IMD1 is 50% or more, then the power level of the device capability of the first intermediate device IMD1 is less than 50%. For example, the client device CD may not transmit the queue request. For example, if the policy of the client device allows downloading only when the supporting media profile of the first intermediary device IMD1 is 'HD', the first intermediary device IMD1 may not be transmitted. ) May not send a queue request if its supporting media profile is 'PD' or 'SD'.
  • the client The device CD sends a queue request to the first intermediate device IMD1 and may not send a queue request if the current number of the queue request is 3 equal to the maximum number of the queue request.
  • FIG. 23 illustrates a content download procedure based on device capability exchange between a content server and an intermediate device.
  • the client device CD may be provided with a list of contents (for example, media) from a content server and select a media to be downloaded (step S21).
  • the client device (CD) wishes to download the selected media using an intermediary device connected to the network.
  • the client device CD may perform a device discovery procedure with the first intermediate device IMD1 (step S22).
  • the device discovery procedure may be performed by the procedure described with reference to FIG. 4.
  • the intermediate device manager of the client device CD transmits a unicast device discovery request message to the first intermediate device IMD1 based on the listened connected device list.
  • the unicast device discovery response message may be received from the first intermediate device IMD1.
  • the client device CD transmits a queue request to the first intermediate device IMD1 requesting to download the selected media from a specific entity (step S23).
  • the queue manager of the first intermediate device IMD1 may send a queue request to the first intermediate device IMD1 via the Q3 interface.
  • the queue request may include an identifier of the media, access information required for downloading an asset corresponding to the media, and the like.
  • the first intermediate device IMD1 Upon receiving the queue request, the first intermediate device IMD1 accesses the content server based on the information included in the queue request, and transmits the device capability of the first intermediate device IMD1 to the content server (step: S24).
  • the content server may download a media file suitable for the first intermediate device IMD1 to the first intermediate device IMD1 based on the device capability (step S25).
  • the content server (CS) is based on the policy managed by the content policy server (PS), the download according to whether or not the specific device capability of the first intermediate device (IMD1) satisfies the policy. It may be determined whether or not to send a queue request.
  • the content server CS checks the storage capacity and the storage indication of the first intermediate device IMD1 using the device capability delivered from the first intermediate device IMD1, and the media file to be downloaded allowed by the policy. It is possible to check whether the size of X is smaller than the remaining storage size of the first device IMD1. If the size of the media file to be downloaded is larger than the remaining storage size of the first intermediate device IMD1, the content server PS may not transmit a queue request.
  • the content server CS may transmit an error message to the client device CD or the first intermediate device IMD1. Similarly, the content server CS may determine whether to request a queue by checking the device capability delivered from the first intermediate device IMD1 based on various items such as a network access type, a pow level, a supporting media profile, and the like of the policy. .
  • FIG. 24 shows a diagram for explaining the structure of device capability.
  • the device capability mentioned in the above description for example, the description with reference to FIGS. 22 to 23, may have the device capability structure shown in FIG. 24.
  • the device capability may include a device ID, a device name, a device friendly name, a user ID, and a current power source. ), Charging Status, Power Level, Supporting Media Profiles, Supporting Codec Types, Storage Capacity, Storage Function Groups , Point Node, Storage Usage, Maximum Size of Queue Request, Maximum Number of Queue Request, Current Number of Queue Request of Queue Request, Network Interface Number of Entries, Network Access Type, Media Transport, Bandwidth Capability items such as a bandwidth limit may be included.
  • the device identifier may mean an identifier that uniquely identifies the device globally.
  • the value of the device identifier may be string type information.
  • the device name may mean a universally-unique identifier for a device.
  • the value of the device name may be, for example, information in the form of a string.
  • the device friendly name is a short description for an end user, and the value may be string type information.
  • the user identifier is an identifier for identifying the end user, and the value of the user identifier may be string type information.
  • the current power source is a description of the current power source of the device, the value of which may be a string.
  • the value of the current power source may be set to, for example, "AC Power” meaning that the device is supplied with AC power, "battery” meaning that the device is powered from the battery. Assuming the device receives AC power from an AC source, the value of the current power source can be set to 'AC Power'. If the device is powered from a battery, the value of the current power source may be set to 'battery'.
  • the charging status is a capability item indicating the current state of charge of the battery, the value of which may be string information.
  • the value of the charging status is 'Available' which means that the battery is installed in the device and the installed battery is currently working, and 'Charging' which means that the battery is installed and charging in the device. It may be set to 'Unavailable' which means that the battery is not installed, or 'Error' which indicates that the battery is installed in the device but fails to function correctly.
  • the power level may represent the current power level of the battery.
  • the value of the power level may be a percentage value.
  • '0' may mean that the battery is completely discharged or no battery is installed.
  • '100' may mean that the battery is fully charged.
  • the supporting media profile may indicate a supportable media profile type.
  • the value of the supporting media profile is string type information such as 'HD' for high definition (HD), 'SD' for standard definition (SD), and portable definition (PD). It may be set to 'PD' which means.
  • the supporting codec type is a list of supported codec types, and a value thereof may be string type information.
  • the storage capacity may represent an available amount of storage.
  • the storage functional group represents a function group associated with storage of a device, for example, a virtual storage device, and a value thereof may be string type information.
  • the value of the functional group may be 'Access Control', 'Capacity Management', 'Expiration', 'Transformation', 'Playlist' and the like.
  • the 'access control' refers to an access control function group that mediates between different applications using a virtual storage device.
  • the access control functional group may, for example, block a particular application from accessing content associated with another application.
  • the “capacity management” may indicate a capacity management function group that allows the virtual storage device to manage its storage space based on the priority.
  • the Capacity Steering Group may discard the lower priority asset, for example, if a higher priority asset is downloaded, to make room for the higher priority asset.
  • the “Transformation” may refer to a transform function group that permits a transform operation while reading or writing content from the virtual storage device.
  • the 'Playlist' may represent a playlist function group that enables the virtual storage device to process the playlist. If there is a playlist function group, the playlist can be used for group objects.
  • the storage usage may indicate the total amount of storage currently available.
  • the value of the storage notice may be a percentage value. For example, if the value of the storage notice is "0", it means that the storage is completely empty (Completely Unoccupied), "100” may mean that the storage is completely occupied (Fully Occupied).
  • Entries may indicate the maximum size of the queue request, the total number of queue requests that can be submitted during a given time, the number of current queue requests other than the complete state, and the number of network interfaces.
  • the network access type may indicate an available network access interface type.
  • the value of the network access type may be string information.
  • the value of the network access type may be, for example, 'Ethernet', '801.11', 'Bluetooth', '3G', 'WiMAX', and the like.
  • the media transport may indicate a supported transport protocol type for D3, D4, and D1 interfaces.
  • the value of the media transport may be, for example, "HTTP”, "RTP”, and the like.
  • the bandwidth limit may represent the available bandwidth of the network interface.
  • CD1 first client device
  • CD2 second client device
  • CD3 Third Client Device
  • CPS Content Policy Server
  • NPS Network Policy Server

Abstract

본 발명은 NFC를 이용한 콘텐트 다운로드 방법 및 장치를 개시하고 있다. 본 발명의 콘텐트 다운로드 방법은 제 1 디바이스에 의해 수행되며, 제 2 디바이스를 사용하여 콘텐트를 다운로드할 것을 요청하는 콘텐트 다운로드 요청을 전송하는 단계, 상기 콘텐트 다운로드 요청을 수신한 디바이스로부터 상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 수신하는 단계, 상기 제 2 디바이스로부터 웨이크 업(wake-up) 요청을 수신하는 단계 및 상기 콘텐트 다운로드 요청에 응답하여 상기 제 2 디바이스에 다운로드된 콘텐트를 상기 제 2 디바이스로부터 수신하는 단계를 포함한다. 따라서, 사용자가 NFC 지원 디바이스 간에 접촉만으로 다운로드 예약 및 전송을 지원하고, NAS(Network Attached Storage)와 스마트 디바이스 간에 NFC를 이용한 큐 다운로드 요청 및 목록 관리를 지원하여, NFC 링크 셋업 후 홈 네트워크를 이용한 큐 요청 및 캐싱을 지원한다.

Description

NFC를 이용한 콘텐트 다운로드 방법 및 장치
본 발명은 콘텐트 다운로드 방법 및 장치에 관한 것으로, 보다 상세하게는 네트워크 서비스를 구성하는 기기에 NFC(Near Field Communication)을 활용하여 다운로드하기 위한 방법 및 장치에 관한 것이다.
최근 들어, 초고속 무선 통신 인프라가 구축되고 다양한 무선 포터블 디바이스의 보급이 대중화되면서, 기존에 PC 등과 같은 고정형 디바이스를 통해 수행되던 작업들을 모바일 디바이스를 사용하여서도 수행 가능하게 되었다. 특히, 스마트 패드 또는 스마트 폰 등과 같은 스마트 디바이스는 모바일 디바이스의 최대 장점인 휴대성은 양호하게 제공하면서, PC 못지 않은 성능에다 화질 및 화면의 크기도 이전보다 훨씬 커져서, 기존의 고정형 디바이스에서는 제공할 수 없었던 새롭고 편기한 형태의 서비스를 제공할 수 있게 되었다.
이러한 스마트 디바이스 등과 같은 모바일 디바이스는 디바이스에 설치되는 다양한 어플리케이션을 기반으로 하여, 인터넷을 통한 정보 검색은 물론이고, 예컨대, 전자상거래, 온라인 뱅킹, 게임, 네비게이션, 모바일 메신저 서비스 등 다양한 서비스 분야에서 이용되고 있다. 또한 모바일 디바이스는 홈 네트워크에 접속하여 홈 디바이스를 제어하거나, 홈 디바이스로 콘텐트를 전송하거나, 홈 디바이스로부터 콘텐트를 수신하는 등 홈 네트워크 내에서 홈 디바이스와의 연동을 통한 사용도 증가하고 있다.
스마트 디바이스의 이동성을 제공하기 위해, 무선 통신을 활용할 수 있다. 스마트 디바이스에 제공되는 무선 통신 자원의 한계를 극복하기 위해, 스마트 디바이스간 NFC(Near Field Communication)을 통한 통신을 수행할 수 있다.
다만, 종래의 NFC를 이용한 통신은 NFC 연결시에만 디바이스 간의 데이터를 전송하는 서비스를 제공하는 것이 대부분이었다. 즉, 종래에는 디바이스 간에 NFC 연결이 가능한 경우, 타겟 디바이스(target device)에서 특정 콘텐트에 대한 다운로드 예약을 지원하기 위해 다운로드 예약 프로토콜(Download Reservation Protocol), 다운로드 큐 요청 데이터 포맷(Download QueueRequest Data Format) 및 다운로드 및 콘텐트 재생 애플리케이션 인터페이스(Download & Content Play Application Interface) 등에 대한 정의가 없어 예약 다운로드, 다운로드 큐 요청 및 다운로드된 콘텐트에 대한 재생을 수행하지 못하는 문제점이 있었다.
또한, 종래의 NFC를 이용 기술은 콘텐트 다운로드 예약이나 다른 디바이스에서 다운로드가 완료되었을시 자동으로 알려주는 기능, 디바이스에서 NFC로 연결이 불가할 경우에 다른 네트워크 인터페이스를 통해 이벤트 통지(event notification)를 해줄 수 있는 기능이 존재하지 않아, NFC 연결을 통한 디바이스 활용성에 제한이 있었다.
상기한 문제점을 해결하기 위한 본 발명의 목적은 NFC 연결이 가능한 두 클라이언트 디바이스 간에 NFC 피어 투 피어(peer-to-peer) 모델을 활용하여 콘텐트 다운로드 예약(큐 요청에 의한 큐잉된 다운로드(Quered Download by Queue Request) 및 콘텐트 다운로드 후 다운로드 콘텐트 전송을 위한 웨이크 업 기능을 포함하는 NFC를 이용한 콘텐트 다운로드 방법 및 장치를 제공하는 것이다.
또한, 본 발명의 다른 목적은 NFC로 연결된 디바이스에게 다운로드 요청과 동시에 클라우드 서비스(Cloud Service)에도 다운로드 요청을 보낼 수 있고, 타겟 클라이언트 디바이스와 클라우드 서비스에게 동시에 큐 요청을 보내서 콘텐트와 관련된 애셋(Asset)이 타겟 클라이언트 디바이스와 클라우드 서비스에게 다운로드 되도록 하는 NFC를 이용한 콘텐트 다운로드 방법 및 장치를 제공하는 것이다.
더욱이, 본 발명의 또 다른 목적은 다운로드 예약 요청에 대한 NFC 메시지를 정의하고, 클라이언트 디바이스가 NFC를 통해 타겟 디바이스에게 큐 요청을 보낸 후, 타겟 디바이스에서 다운로드가 완료되면, 완료된 콘텐트를 예약 요청을 처리한 클라이언트 디바이스가 수신할 수 있도록 클라이언트 디바이스의 구체적인 사용자 인터페이스(UI: User Interface)를 제공할 수 있는 NFC를 이용한 콘텐트 다운로드 방법 및 장치를 제공하는 것이다.
상기한 목적을 달성하기 위한 본 발명의 콘텐트 다운로드 방법은 제 1 디바이스에 의해 수행되며, 제 2 디바이스를 사용하여 콘텐트를 다운로드할 것을 요청하는 콘텐트 다운로드 요청을 전송하는 단계, 상기 콘텐트 다운로드 요청을 수신한 디바이스로부터 상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 수신하는 단계, 상기 제 2 디바이스로부터 웨이크 업(wake-up) 요청을 수신하는 단계 및 상기 콘텐트 다운로드 요청에 응답하여 상기 제 2 디바이스에 다운로드된 콘텐트를 상기 제 2 디바이스로부터 수신하는 단계를 포함할 수 있다.
상기 다운로드 방법은 상기 컨펌에 대응하여 슬립 모드(sleep-mode)로 진입하는 단계를 더 포함할 수 있다.
상기 콘텐트 다운로드 요청, 상기 컨펌 및 상기 웨이크 업 요청 중 적어도 어느 하나는 NFC(Near Field Communication)를 이용하여 송수신될 수 있다.
상기 웨이크 업 요청 수신 단계는 상기 웨이크 업 요청을 NFC를 통해 수신하는 단계 및 WLAN(Wireless Local Area Network) 또는 3G/4G 무선 통신을 통해 수신하는 단계 중 적어도 어느 하나를 포함할 수 있다.
상기 콘텐트 다운로드 요청은 다운로드 콘텐트에 대한 소스 URI 정보, 다운로드가 가능한 시간을 지칭하는 다운로드 타임 및 웨이크 업 시간을 지칭하는 웨이크 업 타임 정보를 포함하는 다운로드 관련 정보를 포함할 수 있다.
상기 콘텐트 다운로드 요청은 상기 제 1 디바이스가 상기 다운로드된 콘텐트의 수신 조건과 관련된 정보로서, 전원 연결 상태 정보, 배터리 상태 정보, 네트워크 상태 정보 및 저장 가용 공간 정보 중 적어도 어느 하나를 포함할 수 있다.
상기 콘텐트 다운로드 요청 전송 단계는 상기 제 2 디바이스로 직접 상기 콘텐트 다운로드 요청을 전송하는 단계 및 제 3 디바이스로 상기 콘텐트 다운로드 요청을 전송하는 단계 중 적어도 어느 하나를 포함할 수 있다.
상기 제 3 디바이스는 클라우드 서비스(cloud service)와 관련된 서버 또는 상기 제 1 디바이스와 상기 제 2 디바이스를 중계하기 위한 디바이스일 수 있다.
상기 다운로드 방법은 다운로드 받을 콘텐트를 선택하는 사용자 인터페이스를 표시하는 단계 및 상기 콘텐트 선택 신호에 응답하여 콘텐트를 선택하는 단계를 더 포함하되, 상기 콘텐트 다운로드 요청 전송 단계는 상기 콘텐트 선택을 기반으로 상기 제 2 디바이스와 접촉시(connected) 상기 제 2 디바이스로 상기 콘텐트 다운로드 요청을 자동으로 전송하는 단계를 포함할 수 있다.
상기 다운로드 방법은 최근 접속한 기기 리스트를 활용하여 접속 가능한 주변 기기를 발견하는 단계 및 콘텐트 서버로부터, 다운로드 받을 콘텐트의 소스 URI를 획득하는 단계를 더 포함할 수 있다.
상기 다운로드된 콘텐트 수신 단계는 다운로드된 콘텐트를 수신할 수 있는 조건을 만족하는지 판단하는 단계 및 상기 판단을 기반으로 하여 다운로드된 콘텐트를 수신하는 단계를 포함할 수 있다.
상기한 목적을 달성하기 위한 본 발명의 콘텐트 다운로드 장치는 제 2 디바이스를 사용하여 콘텐트를 다운로드할 것을 요청하는 콘텐트 다운로드 요청을 전송하는 전송부 및 상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 수신하고, 웨이크 업(wake-up) 요청을 상기 제 2 디바이스로부터 수신하며, 상기 콘텐트 다운로드 요청에 의해 상기 제 2 디바이스에 다운로드된 콘텐트를 상기 제 2 디바이스로부터 수신하는 수신부를 포함할 수 있다.
상기한 목적을 달성하기 위한 본 발명의 콘텐트 다운로드 방법은 제 2 디바이스에 의해 수행되며, 제 1 다바이스 및 제 3 디바이스 중 적어도 어느 하나로부터 콘텐트 다운로드 요청을 수신하는 단계, 상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 전송하는 단계, 상기 콘텐트 다운로드 요청을 기반으로, 다운로드 받을 콘텐트를 다운로드하는 단계, 상기 제 1 디바이스로 웨이크 업(wake-up) 요청을 전송하는 단계 및 상기 다운로드된 콘텐트를 상기 제 1 디바이스로 전송하는 단계를 포함할 수 있다.
상기 콘텐트 다운로드 요청, 상기 컨펌 및 상기 웨이크 업 요청 중 적어도 어느 하나는 NFC(Near Field Communication)를 이용하여 송수신될 수 있다.
상기 콘텐트 다운로드 요청을 상기 제 1 디바이스와 다른 제 3 디바이스로부터 수신하고, 상기 다운로드 받을 콘텐트를 상기 제 3 디바이스로부터 다운로드할 수 있다.
상기 웨이크 업 요청 전송 단계는 상기 웨이크 업 요청을 NFC를 통해 전송하는 단계 및 상기 제 1 디바이스로부터 NFC를 통해 전송된 상기 웨이크 업 요청에 대한 응답이 기준 시간 동안 없는 경우, WLAN(Wireless Local Area Network) 또는 3G/4G 무선 통신을 통해 상기 웨이크 업 요청을 전송하는 단계를 포함할 수 있다.
상기 다운로드 완료된 콘텐트 전송 단계는 상기 콘텐트 다운로드 요청에 포함된, 상기 제 1 디바이스의 상기 다운로드된 콘텐트 수신 조건과 관련된 정보를 기반으로 상기 다운로드된 콘텐트의 전송 여부를 판단하는 단계 및 상기 판단 결과를 기반으로 상기 다운로드된 콘텐트를 상기 제 1 디바이스로 전송하는 단계를 포함할 수 있다.
상기한 목적을 달성하기 위한 본 발명의 콘텐트 다운로드 장치는 콘텐트 다운로드 요청을 제 1 다바이스 및 제 3 디바이스 중 적어도 어느 하나로부터 수신하고, 상기 콘텐트 다운로드 요청을 기반으로 하여, 상기 제 1 서버로부터 다운로드 받을 콘텐트를 다운로드하는 수신부 및 상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 전송하고, 웨이크 업(wake-up) 요청을 상기 제 1 디바이스로 전송하며, 상기 다운로드된 콘텐트를 상기 제 1 디바이스로 전송하는 전송부를 포함할 수 있다.
상기한 목적을 달성하기 위한 본 발명의 콘텐트 다운로드 시스템은 제 2 디바이스를 사용하여 콘텐트를 다운로드할 것을 요청하는 콘텐트 다운로드 요청을 전송하고, 상기 콘텐트 다운로드 요청에 응답하는 컨펌을 수신하며, 상기 제 2 디바이스로부터 웨이크 업 요청을 수신하고, 상기 콘텐트 다운로드 요청에 따라 상기 제 2 디바이스에 다운로드된 콘텐트를 수신하는 제 1 디바이스 및 상기 콘텐트 다운로드 요청을 수신하고, 상기 컨펌을 전송하며, 상기 콘텐트 다운로드 요청을 기반으로, 다운로드 받을 콘텐트를 다운로드하고, 상기 제 1 디바이스로 웨이크 업 요청을 전송하며, 상기 다운로드된 콘텐트를 제 1 디바이스로 전송하는 제 2 디바이스를 포함할 수 있다.
상기 다운로드 시스테은 상기 제 1 디바이스로부터 상기 콘텐트 다운로드 요청을 수신하고, 상기 콘텐트 다운로드 요청에 응답하는 컨펌을 상기 제 1 디바이스로 전송하며, 상기 콘텐트 다운로드 요청을 상기 제 2 디바이스로 전송하는 제 3 디바이스를 더 포함할 수 있다.
본 발명의 NFC를 이용한 콘텐트 다운로드 방법 및 장치에 따르면, 사용자가 NFC 지원 디바이스 간에 접촉만으로 다운로드 예약 및 전송을 지원하고, NAS(Network Attached Storage)와 스마트 디바이스 간에 NFC를 이용한 큐 다운로드 요청 및 목록 관리를 지원하여, NFC 링크 셋업 후 홈 네트워크를 이용한 큐 요청 및 캐싱을 지원할 수 있는 효과가 있다.
또한, 본 발명의 NFC를 이용한 콘텐트 다운로드 방법 및 장치에 따르면, 클라우드 서비스에 대한 싱크(Sync) 기능을 보완할 수 있어 선택된 파일만 홈 네트워크를 이용하여 미리 다운로드 또는 클라우드 서비스와 디바이스간 싱크 기능을 제고할 수 있는 효과가 있다.
더욱이, 본 발명의 NFC를 이용한 콘텐트 다운로드 방법 및 장치에 따르면, 클라이언트 디바이스가 원격 디바이스(remote device)에게 직접적으로 다운로드 예약 요청을 보낼 수 없을 때에는 클라우드 서비스를 통해 상기 원격 디바이스가 가용할 때 다운로드가 이뤄질 수 있게 함으로써 사용자가 번번히 상기 원격 디바이스의 상태를 확인하는 절차를 줄일 수 있는 효과가 있다.
또한, 본 발명의 NFC를 이용한 콘텐트 다운로드 방법 및 장치에 따르면, 다운로드가 수행되는 디바이스만 턴온(turn on)시키고, 타 디바이스는 슬립 모드(sleep mode)에 진입 가능케 함으로써 디바이스 리소스(device resource)의 절약이 가능하므로, 보다 낮은 성능의 디바이스라도 일정 수준 이상의 서비스 제공을 보장하고, 이를 통해 디바이스 생산 단가 절감을 가능케 하는 효과가 있다.
도 1은 본 발명의 일 실시예에 따른 콘텐트 다운로드 방법이 적용될 수 있는 콘텐트 서비스 시스템의 구성을 도시한 블록도,
도 2는 콘텐트 서비스 시스템의 클라이언트 디바이스의 상세 구조 및 관련 인터페이스를 설명하기 위한 블록도,
도 3은 도 2에 도시되어 있는 인터페이스들을 설명하기 위한 도표,
도 4는 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법이 적용될 수 있는 콘텐트 서비스 시스템의 구성을 도시한 블록도,
도 5는 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법과 관련된 애플리케이션의 NFC 스택 프로토콜(stack protocol) 상에서의 위치를 설명하기 위한 블록도,
도 6은 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 따라 다른 디바이스로의 콘텐트 다운로드 및 큐 요청을 설명하기 위한 도면,
도 7은 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스 및 콘텐트 서버 간 송수신되는 신호의 흐름을 설명하기 위한 도면,
도 8은 본 발명의 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스 및 클라우드 서비스 서버 간 송수신되는 신호의 흐름을 설명하기 위한 도면,
도 9는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스 및 클라우드 서비스 서버 간 송수신되는 신호의 흐름을 설명하기 위한 도면,
도 10은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스, 제 3 클라이언트 디바이스 및 콘텐트 서버 간의 송수신되는 신호의 흐름을 설명하기 위한 도면,
도 11은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스 및 콘텐트 서버 간의 송수신되는 신호의 시퀀스 다이어그램,
도 12는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스 및 콘텐트 서버 간의 송수신되는 신호의 시퀀스 다이어그램,
도 13은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스 및 콘텐트 서버 간의 송수신되는 신호의 시퀀스 다이어그램,
도 14는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스, 제 2 클라이언트 디바이스, 제 3 클라이언트 디바이스 및 콘텐트 서버 간의 송수신되는 신호의 시퀀스 다이어그램,
도 15은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 클라이언트 애플리케이션과 관련하여 설정을 입력할 수 있는 사용자 인터페이스의 예를 도시한 도면,
도 16은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 클라이언트 애플리케이션을 통해 콘텐트 리스트, 다운로드 타임 및 콘텐트 다운로드 관련 설정을 입력할 수 있는 사용자 인터페이스의 예를 도시한 도면,
도 17은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스의 동작을 개략적으로 나타낸 흐름도,
도 18은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 2 클라이언트 디바이스의 동작을 개략적으로 나타낸 흐름도,
도 19는 본 발명의 바람직한 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 디바이스 디스커버리 방법을 설명하기 위한 흐름도이다.
도 20은 상기 리슨틀리 커넥티드 디바이스 리스트의 구조를 설명하기 위한 도표를 나타내고 있다.
도 21은 유니캐스트 디바이스 디스커버리 요청 또는 응답에 사용되는 유니캐스트 디바이스 디스커버리 메시지의 구조를 나타내는 예시도이다.
도 22는 디바이스 디스커버리 및 디바이스 커패빌리티 교환(exchange)을 기반으로 하는 콘텐트 다운로드 절차를 나타내고 있다.
도 23은 콘텐트 서버와 매개 디바이스 간의 디바이스 커패빌리티 교환(exchange)을 기반으로 하는 콘텐트 다운로드 절차를 나타내고 있다.
도 24는 디바이스 커패빌리티의 구조를 설명하기 위한 도표이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다.
그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제 1, 제 2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제 1 구성요소는 제 2 구성요소로 명명될 수 있고, 유사하게 제 2 구성요소도 제 1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.
도 1은 본 발명의 일 실시예에 따른 콘텐트 다운로드 방법이 적용될 수 있는 콘텐트 서비스 시스템의 구성을 도시한 블록도이다.
도 1에 도시된 바와 같이, 콘텐트 서비스 시스템은 서버 도메인(Server Domain) 및 사용자 도메인(User Domain)으로 구분될 수 있다.
상기 서버 도메인은 콘텐트 서비스를 위한 서비스 및 네트워크 정책(Policy) 등을 운영하고 그 정책을 기반으로 콘텐트를 사용자 도메인으로 제공할 수 있다. 즉, 서버 도메인은 콘텐트 서비스를 제공하기 위한 서버들을 포함하는 도메인을 의미할 수 있다. 이러한 서버 도메인은 예컨대, 콘텐트의 제작, 판매, 유통, 정책 운영, 권한 제한 등 사용자 도메인으로의 콘텐트 제공 및 서비스의 운영 등을 수행할 수 있다.
상기 서버 도메인은 콘텐트를 제공하는 콘텐트 서버(CS), 콘텐트 서비스를 위한 정책을 운영하는 콘텐트 정책 서버(CPS), 네트워크 정책을 운영하는 콘텐트 정책 서버(NPS) 등을 포함할 수 있다. 콘텐트 서버는 다수 개일 수 있다. 예를 들어, 서버 도메인은 콘텐트의 다운로드를 위한 콘텐트 다운로드 서버, 콘텐트의 스트리밍을 위한 콘텐트 스트리밍 서버 등을 포함할 수 있다.
사용자 도메인은 사용자의 디바이스(100)들을 포함할 수 있다. 상기 디바이스(100)는, 예컨대 PC, 셋톱박스 등과 같은 고정형 디바이스일 수도 있고, 스마트폰, 휴대폰, 모바일 핸드셋, 태블릿, PDA(Personal Digital Assistance), 노트북 등과 같은 포터블 디바이스일 수도 있다. 상기 디바이스(100)들은 UPnP, DLNA 등에 기반한 로컬 네트워크에 접속하고, 유선 또는 무선 통신을 통하여 상호 연동할 수 있다.
사용자의 디바이스(100)는 클라이언트 디바이스(Client Device) 또는 매개 디바이스(Intermediate Device)일 수 있다.
상기 클라이언트 디바이스는 적어도 하나의 네트워크 인터페이스 및 로컬 스토리지를 구비하는 물리적인 하드웨어 디바이스를 의미할 수 있다. 예컨대 상기 클라이언트 디바이스는 콘텐트를 소비(Consume)할 수 있는 모바일 핸드셋, 태블릿, 스마트폰 등일 수 있다. 상기 클라이언트 디바이스(CD)는 콘텐트 서비스를 제공받기 위한 모듈들을 구비할 수 있다.
상기 매개 디바이스는 클라이언트 디바이스 행의(destined for) 애셋(Asset)의 집결(stage)하는 것에 사용될 수 있는 네트워크 상의 듀얼 롤 클라이언트/서버(Dual Role Client/Server) 디바이스일 수 있다. 상기 매개 디바이스는 애셋이 클라이언트 디바이스로 전달될 때까지 애셋을 일시적으로 홀드할 수 있다. 상기 매개 디바이스는 통상적으로는 콘텐트를 직접 소비하지는 않으나, 콘텐트를 직접 소비할 수도 있다. 예를 들어, 매개 디바이스는 콘텐트를 스테이지(Stage)할 수도 있다. 즉 매개 디바이스는 콘텐트를 서버로부터 다운로드하고 이를 저장 및 재생할 수도 있다.
도 2는 콘텐트 서비스 시스템의 클라이언트 디바이스의 상세 구조 및 관련 인터페이스를 설명하기 위한 블록도이다.
도 2에 도시된 바와 같이, 클라이언트 디바이스(CD)는 로컬 어플리케이션/사용자 에이전트(Local Application/User Agent)(110), 플레이어(Player)(130), 네트워크 정책 클라이언트(Network Policy Client)(140), 가상 스토리지 디바이스(Virtual Storage Device)(150), 큐/정책 엔진(QPE : Queue/Policy Engine)(120) 등을 포함할 수 있다.
상기 로컬 어플리케이션/사용자 에이전트(110)는 콘텐트 서비스를 위한 소프트웨어일 수 있으며, 로컬 어플리케이션 및 사용자 에이전트를 포함할 수 있다. 예컨대 상기 로컬 어플리케이션/사용자 에이전트(110)는 사용자가 콘텐트 서비스를 제공받을 수 있도록 하기 위한 사용자 인터페이스, 서비스 메뉴, 서비스 선택, 콘텐트 선택 등을 제공할 수도 있다.
상기 로컬 어플리케이션은 클라이언트 디바이스에 상주(Resident)하는 소프트웨어로서 큐/정책 엔진(120)과 특정한 인터페이스 프로토콜, 예컨대 Q2 인터페이스 프로토콜을 사용하여 통신할 수 있다. 상기 사용자 에이전트는 예컨대 클라이언트 디바이스(CS)의 웹 브라우저 또는 미들웨어(Middleware) 등과 같이 서버-서플라이드(Server-Supplied) 어플리케이션을 렌더(Render) 및 수행(Execute)하는 소프트웨어를 의미할 수 있다. 상기 로컬 어플리케이션/사용자 에이전트(100)은 콘텐트의 다운로드가 시작되거나 완료될 때 액티브될 수 있다.
상기 플레이어(130)는 콘텐트 서비스를 통하여 제공되는 콘텐트를 재생하기 위한 것으로서, 예컨대 다운로드 콘텐트 또는 스트리밍 콘텐트를 재생할 수 있는 미디어 플레이어일 수 있다. 상기 네트워크 정책 클라이언트(140)는 네트워크 정책 서버(NPS)와 통신하면서 네트워크 정책을 취득하고 취득된 네트워크 정책에 따라 클라이언트 디바이스(CD)를 제어할 수 있다.
상기 가상 스토리지 디바이스(150)는 캐시 오브젝트(Cache Object)를 통하여 액세스할 수 있는 로컬 저장소의 표현(representation)이다. 예컨대 가상 스토리지 디바이스(150)는 하드디스크와 같은 일반적인 로컬 저장소, 디바이스에 연결되는 USB 메모리, 플래시 메모리, 대몬(Demon)과 같은 가상 영역 등일 수 있다.
클라이언트 디바이스(CD)의 큐/정책 엔진(120)은 콘텐트 정책 서버(CPS) 또는 네트워크 정책 서버(NPS)에 의하여 주어진 정책을 만족할 때 콘텐트 서버(CS)의 특정 콘텐트(애셋)을 캐싱/다운로딩하기 위하여 콘텐트의 캐싱/다운로드의 요청을 보낼 수 있는데(send), 이러한 요청을 큐 요청이라 칭할 수 있다. 즉, 큐 요청은 콘텐트 다운로드 요청으로 표현될 수 있다. 예를 들어, 상기 큐 요청은 콘텐트(애셋)에 대응되는 URI를 포함할 수 있다. 큐 요청은, 뿐만 아니라, 코덱 타입 미디어 프로파일(Codec Type Media Profile), 컨테이너 타입(Container Type), MIME(Multipurpose Internet Mail Extension) 타입, 스토어 네임(Store Name), 큐 요청의 토털 길이, 콘텐트 정보, 정책 정보 등을 포함할 수 있다. 또한, 상기 큐 요청은 로컬 어플리케이션/사용자 에이전트(110)에 의하여 추정된 각 소스 URI별 대역폭 정보를 포함할 수도 있다.
상기 큐/정책 엔진(120)는 클라이언트 디바이스(CD)에 구비되는 모듈로서 P1, S, D1, D2, Q2, D3, Q3 인터페이스 프로토콜들을 통하여 통신할 수 있다. 큐/정책 엔진(120)는 각 로컬 어플리케이션 및 콘텐트 서버(CS)를 대표하여(on behalf of) 큐(Queue)를 유지(maintaining)할 수 있으며, 스토리지와 인터페이싱하고, 큐 요청을 정책과 동기화하는 책임을 질 수 있다. 따라서 큐/정책 엔진(120)은 콘텐트 공유 서비스를 위한 서비스 클라이언트라 칭할 수도 있다.
이러한 큐/정책 엔진(120), 즉 큐/정책 엔진은 큐 매니저(Queue Manger)(122), 정책 클라이언트(Policy Client)(126) 및 매개 디바이스 매니저(Intermediate Device Manager)(124) 등을 포함할 수 있다.
상기 큐 매니저(122)는 콘텐트의 다운로드 또는 스트리밍을 위한 큐를 운영할 수 있다. 예컨대 큐 매니저(122)는 스트림 큐 운영자(Stream Queue Manager), 다운로드 매니저(Download Manager)를 포함할 수도 있다. 상기 큐 매니저(122)는 매개 디바이스(IMD)로 큐 요청을 전송하고 그 응답을 매개 디바이스(IMD)로부터 수신할 수도 있고, 또는 매개 디바이스(IMD)로부터 큐 요청을 수신하고 그 응답을 송신할 수도 있다. 예를 들어, 큐 매니저(122)는 매개 디바이스(IMD)로 콘텐트 서버(CS)로부터 특정 콘텐트를 다운로드할 것을 요청하는 큐 요청을 전송하고 그 응답을 수신할 수 있다. 큐 매니저(122)는 매개 디바이스(IMD)로 콘텐트 서버(CS)로부터 다운로드 한 콘텐트를 클라이언트 디바이스(CD)로 전송해줄 것을 요청하는 큐 요청을 전송할 수도 있다.
또한 상기 큐 매니저(122)는 콘텐트의 사용을 위한 라이트 체크를 수행할 수 있다. 예를 들어, 큐 매니저(122)는 로컬 어플리케이션(110)에 의하여 선택되는 콘텐트에 대응되는 애셋을 매개 디바이스(IMD)를 통하여 스테이징하기 위한 라이트 체크, 예컨대 애셋을 콘텐트 서버(CS)로부터 매개 디바이스(IMD)로 다운로드하기 위한 라이트 체크를 수행할 수 있다. 상기 라이트 체크는 DRM(Digital Right Management) 커패빌리티(Capability) 체크 및 라이선스 체크를 포함할 수 있다.
상기 DRM 커패빌리티 체크는 애셋의 DRM 정보 및 매개 디바이스(IMD)에 관한 DRM 커패빌리티를 기반으로 하여, 상기 매개 디바이스(IMD)가 상기 애셋을 보호하는 DRM 시스템을 지원할 수 있는지를 검증할 수 있다. 상기 라이선스 체크는 상기 라이선스 매개 디바이스(IMD)가 상기 애셋의 사용을 위한 라이선스를 획득할 수 있는지를 검증할 수 있다. 예컨대 상기 라이선스 체크는 라이트 토큰(Right Token)에 정의된 권한을 체크하는 것일 수 있다.
큐에 의하여 관리되는 요청된 애셋의 수신은 유니캐스트 다운로드나 멀티캐스트 다운로드, 또는 두 메커니즘의 컴비네이션을 사용하여 달성될 수 있다. 큐/정책 엔진(120)은 비록 큐 인터페이스에서 정의된 명령들이 우선순위나 오더가 변경될지라도 싱글 큐를 보존하여야 한다.
정책 클라이언트(126)는 큐/정책 엔진(120)의 서브 시스템으로서 정책 오브젝트를 유지(Maintain)한다. 정책 클라이언트(126)는 콘텐트 정책 서버(CPS)로부터의 정책들에 따라 큐/정책 엔진(120)을 제어할 수 있다. 예를 들어, 정책 클라이언트(126)는 콘텐트 정책 서버(CPS)로부터 정책들을 리트리브(Retrieve)하고 큐 요청 행위를 조정(Adjust)할 수 있다.
상기 매개 디바이스 매니저(124)는 클라이언트 디바이스(CD)와 연동하는 매개 디바이스(IMD)들을 매니징할 수 있다. 예컨대, 매개 디바이스 매니저(124)는 네트워크에 연결된 매개 디바이스(IMD)를 디스커버리하고, 매개 디바이스(IMD)의 상태를 매니징할 수 있다. 매개 디바이스 매니저(124)는 매개 디바이스와 필요한 메시지를 송신 또는 수신할 수 있다.
도 3은 도 2에 도시되어 있는 인터페이스들을 설명하기 위한 도표를 나타낸다.
도 3에 도시된 바와 같이, 콘텐트 서비스 시스템과 관련되는 인터페이스는 P, Q, S 및 D 인터페이스 그룹으로 구분될 수 있다. 각각의 인터페이스는 클라이언트-서버 구조로 연동할 수 있다.
P 인터페이스 그룹은 큐/정책 엔진(120)과 콘텐트 정책 서버(CPS) 간을 링크 및 정책을 정의(define)할 수 있다. 이러한 P 인터페이스 그룹은 P1, P2 인터페이스를 포함할 수 있다. P1 인터페이스에서 서버는 콘텐트 정책 서버(CPS)이며 클라이언트는 큐/정책 엔진(120)일 수 있다. P2 인터페이스에서 서버는 네트워크 정책 클라이언트(140)이며 클라이언트는 큐/정책 엔진(120)일 수 있다. P4 인터페이스에서 서버는 콘텐트 서버(CS)이며 클라이언트는 매개 디바이스(IMD)일 수 있다.
Q 인터페이스 그룹은 큐 요청 핸들링(Queue Request Handling)을 정의할 수 있다. Q 인터페이스 그룹은 콘텐트 서버(CS), 매개 디바이스(IMD)들과 큐/정책 엔진(120) 간을 연동하는 프라이머리 커맨드 채널일 수 있다. Q 인터페이스 그룹은 로컬 어플리케이션에 의하여 호출될 캐싱 기능(Caching Functionality)을 허용(Allow)할 수 있다. Q2 인터페이스에서 서버는 큐/정책 엔진(120)이고 클라이언트는 로컬 어플리케이션일 수 있다.
Q2 인터페이스 프로토콜 즉, 로컬 에이전트 및 큐/정책 엔진 간의 인터페이스 간의 인터페이스를 거쳐 제출되는 큐 요청은 애셋을 다운로드하기 위하여 사용자 에이전트 또는 콜링 로컬 어플리케이션의 콘텍스트로부터 콜될 수 있는 완전한 URL을 포함할 수 있다. 또는 상기 큐 요청은 프리-니고시에이트(Pre-negotiate) 다운로드를 위하여 콜링 로컬 어플리케이션을 호출하는 로컬 URL을 포함할 수도 있다.
Q3 인터페이스에서는 서버가 큐/정책 엔진(120)이고 클라이언트는 매개 디바이스(IMD)일 수 있다. Q4 인터페이스에서 서버는 콘텐트 서버(CS)이고 클라이언트는 매개 디바이스(IMD)일 수 있다.
S 인터페이스 그룹은 스토리지 및 캐시 커패빌리티를 큐/정책 엔진으로 추출(Abstract)할 수 있다. S 인터페이스에서 서버는 가상 스토리지 디바이스(150)이고 클라이언트는 큐/정책 엔진(120)일 수 있다.
D 인터페이스 그룹은 데이터의 전송을 위하여 사용될 수 있다. D1 인터페이스에서 서버는 콘텐트 서버(CS)이고 클라이언트는 큐/정책 엔진(120)일 수 있다. D2 인터페이스에서 서버는 큐/정책 엔진(120)이고 클라이언트는 플레이어(130)일 수 있다. D3 인터페이스에서 서버는 매개 디바이스(IMD)이고 클라이언트는 큐/정책 엔진(120)일 수 있다. D4 인터페이스에서 서버는 콘텐트 서버(CS)이고 클라이언트는 매개 디바이스(IMD)일 수 있다.
도 4는 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법이 적용될 수 있는 콘텐트 서비스 시스템의 구성을 도시한 블록도이다. 도 4에 도시된 바와 같이, 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법은 상기 도 1에 도시된 콘텐트 서비스 시스템에 통신부(160, 260)를 클라이언트 디바이스(CD)와 매개 디바이스(IMD)에 각각 포함시킨 콘텐트 서비스 시스템에 적용될 수 있다.
도 4를 참조하면, 클라이언트 디바이스(CD)는 통신부(160)를 포함할 수 있다. 통신부(160)는 전송부(미도시) 및 수신부(미도시)를 포함할 수 있다. 통신부(160)는 큐/정책 엔진(120)으로부터의 큐 요청(또는 콘텐트 다운로드 요청)을 매개 디바이스(IMD)의 통신부(260)로 전송할 수 있다. 큐 요청은 매개 디바이스(IMD)에 특정 콘텐트(소스 URI와 관련된 콘텐트)를 다운로드할 것을 요청하는 것으로, 다운로드된 콘텐트를 클라이언트 디바이스(CD)로 전송하라는 요청도 포함될 수 있다.
또한, 클라이언트 디바이스(CD)는 상기 큐 요청에 대한 컨펌 메시지 및 웨이크 업 요청을 매개 디바이스(IMD)로부터 수신할 수 있다. 더욱이, 통신부(160)는 반드시 매개 디바이스와의 통신만을 지원하는 것이 아니라 타 디바이스 또는 서버와의 통신도 지원할 수 있다. 통신부(160)는 여러 무선 통신 방식을 기반으로 상기 큐 요청, 컨펌 메시지 및 웨이크 업 요청을 수신할 수 있다. 상기 여러 무선 통신 방식은 3G/LTE(Long Term Evolution), NFC 및 WLAN(Wireless Local Area Network)를 포함할 수 있고, 통신부(160)는 NFC 기기, 3G/4G 및 WLAN 관련 통신 모듈 중 적어도 어느 하나를 포함할 수 있다. 도면에 도시되진 않았지만, 통신부(160)는 802.11, 802.16 기반의 다른 무선 통신 방식도 지원할 수 있으며, 반드시 상기 방식에 한정되는 것은 아니다.
매개 디바이스(IMD)의 통신부(260)도 전송부(미도시) 및 수신부(미도시)를 포함할 수 있고, 상기 통신부(260)도 NFC 기기, 3G/4G 및 WLAN 관련 통신 모듈 중 적어도 어느 하나를 포함할 수 있다. 따라서, 매개 디바이스(IMD)도 3G/LTE, NFC 및 WLAN 등 다양한 무선 통신 방식을 지원할 수 있다. 도면에 도시되진 않았지만, 통신부(260)는 802.11, 802.16 기반의 다른 무선 통신 방식도 지원할 수 있으며, 반드시 상기 방식에 한정되는 것은 아니다. 통신부(260)는 클라이언트 디바이스(CD)로부터 큐 요청을 수신하고, 상기 큐 요청에 대한 컨펌 메시지 및 웨이크 업 요청을 전송할 수 있다. 이때, 상기 NFC 기기를 이용하여 NFC를 통해 상기 큐 요청, 상기 컨펌 메시지 및 웨이크 업 요청 중 적어도 어느 하나를 송수신할 수 있다.
도 5는 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법과 관련된 애플리케이션의 NFC 스택 프로토콜(stack protocol) 상에서의 위치를 설명하기 위한 블록도이다.
도 5를 참조하면, 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드와 관련된 애플리케이션은 NFC 프로토콜 스택(stack)에서 애플리케이션(Application)의 상단에 위치한다. 즉, 본 발명의 일 실시예에 따른 예약 다운로드 및 원격 웨이크 업을 위한 애플리케이션은 NFC 프로토콜을 기반으로 동작할 수 있고, 애플리케이션의 프로토콜 스택 상의 위치는 프로토콜(protocol), 데이터 포맷(data format) 및 애플리케이션 노트(Application note)의 상단에 위치할 수 있다. 따라서, 상기 NFC를 이용한 콘텐트 다운로드 애플리케이션은 종래의 NFC 관련 데이터 포맷 및 프로토콜을 그대로 이용할 수 있다.
도 6은 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 따라 다른 디바이스로의 콘텐트 다운로드 및 큐 요청을 설명하기 위한 도면이다.
도 6을 참조하면, 클라이언트 디바이스(CD)는 콘텐트 서버(CS)로부터 제공되는 복수의 미디어 콘텐트 중 원하는 콘텐트를 선택한다. 그리고는, 클라이언트 디바이스(CD)의 큐/정책 엔진(120)은 선택한 미디어 콘텐트의 큐 요청(Quere request)을 생성하여 통신부(160)를 통해 매개 디바이스(IMD)로 전달한다. 클라이언트 디바이스(CD)는 이때, NFC 기기 또는 통신 모듈을 이용하여 NFC, 3G/4G 기반 무선 통신, WLAN 또는 블루투스(Bluetooth) 등의 무선 통신 방식을 통해 매개 디바이스(IMD)로 큐 요청을 전달할 수 있다. 큐 요청을 수신한 매개 디바이스(IMD)는 큐 요청에 포함된 콘텐츠의 소스 URI 정보를 파싱하여 콘텐트 서버(CS)로부터 미디어 콘텐트를 큐잉/다운로딩(Queuing/Downloading)할 수 있다. 또한, 매개 디바이스(IMD)는 타 디바이스(300)에게 미디어 콘텐트를 전송할 수 있다. 이때, DECE(Digital Entertainment Content Ecosystem), UPnP/DLNA 등의 홈 네트워크 관련 기술이 적용될 수 있다.
본 발명의 일 실시예에 따르면, 클라이언트 디바이스(CD)는 사용자 구성(User Configuration)을 지원할 수 있다. 클라이언트 디바이스(CD) 상의 로컬 애플리케이션은 사용(use)을 대표하여 정책 및 큐 매니징을 관리한다. 보다 구체적으로, 클라이언트 디바이스(CD)는 다운로드/업로드를 위한 정책을 관리할 수 있다. 또한, 클라이언트 디바이스(CD)는 WLAN을 이용할지 3G/4G 무선 통신을 이용할지를 결정할 수 있고, 전원 연결을 통한 플러그 인 방식을 사용할지 배터리를 사용할지를 사용자 구성을 통해 결정할 수 있다. 더욱이, 상기 사용자 구성을 통해 주간 시간대에 큐 요청 또는 다운로드를 수행할지 야간에 수행할지의 결정 등을 지원할 수 있다.
도 7은 본 발명의 일 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2) 및 콘텐트 서버(CS) 간 송수신되는 신호의 흐름을 설명하기 위한 도면이다.
도 7을 참조하면, 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)로 콘텐트 다운로드를 수행하도록 요청하는 콘텐트 다운로드 요청(또는 큐 요청)을 처리하는 디바이스이다. 제 1 클라이언트 디바이스(CD1)는 PC, 셋톱박스 등과 같은 고정형 단말기일 수도 있고, 스마트 폰, PDA(Personal Digital Assistance), 노트북 등과 같은 포터블 단말기일 수도 있다. 특히, 상기 제 1 클라이언트 디바이스(CD1)는 단순한 사용자 동작에 의해 디바이스간 끊기지 않는 콘텐트 전송을 제공하기 위해 NFC(Near Field Communication)를 지원할 수 있다. 즉, 전술한 바와 같이, 제 1 클라이언트 디바이스(CD1)의 통신부(160)는 NFC 기기를 포함할 수 있다.
또한, 제 2 클라이언트 디바이스(CD2)는 매개 디바이스 또는 타겟 디바이스(target device)일 수 있다. 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)로부터의 요청에 의해 콘텐트를 다운로드하는 디바이스이다. 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디비아스(CD1)와 원격으로 떨어진 원격 디바이스일 수 있다. 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)와 마찬가지로, PC, 셋톱박스 등과 같은 고정형 단말기일 수도 있고, 스마트 폰, PDA(Personal Digital Assistance), 노트북 등과 같은 포터블 단말기일 수 있으며, 특정 서버 또는 스토리지일 수도 있다. 또한, NAS(Network Attached Storage)일 수도 있다. 제 2 클라이언트 디바이스도 디바이스간 끊기지 않는 콘텐트 전송을 제공하기 위해 NFC(Near Field Communication)를 지원할 수 있다. 즉, 전술한 바와 같이, 제 2 클라이언트 디바이스(CD2)의 통신부(260)는 NFC 기기를 포함할 수 있다. 두 디비이스가 NFC 전송을 지원하는 경우, 큐 요청은 NFC 리더와 NFC 태그 간의 단순 접촉으로서 사용자에 의한 복잡한 셋업 과정 없이 손쉽게 전송될 수 있다.
본 발명의 일 실시예에 따르면, 제 1 클라이언트 디바이스(CD1)는 콘텐트 리스트를 브라우징(browsing)하는 동안, 제 2 클라이언트 디바이스(CD2)의 큐에 부가되어질 콘텐트를 선택할 수 있다. 예컨대, 제 1 클라이언트 디바이스(CD1)는 콘텐트 서버(CS)로부터 다운받을 콘텐트 리스트를 수신하고, 수신된 리스트 중 어느 하나 또는 복수 개의 콘텐트를 다운로드하도록 요청할 수 있다.
본 발명의 일 실시예에 따르면, 먼저, 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)로 콘텐트 다운로드 요청(Content Download Request)(또는 큐 요청)을 전송한다(S710). 이때, NFC를 이용하여 상기 콘텐트 다운로드 요청을 전송할 수 있다. 제 1 클라이언트 디바이스(CD1)는 13.56Mhz의 자기장(magnetic field)을 발생시켜 NFC를 통해 상기 콘텐트 다운로드 요청을 전송할 수 있다. 상기 콘텐트 다운로드 요청은 다운로드 관련 정보를 포함할 수 있다. 상기 다운로드 관련 정보는 다운로드 콘텐트에 대한 소스 URI 정보, 다운로드 타임 및 웨이크 업 타임 정보를 포함하는 다운로드 관련 정보를 포함할 수 있다. 상기 소스 URI 정보는 콘텐트 서버(CS)로부터 수신된 리스트 중 선택된 어느 하나 또는 복수 개의 콘텐트의 소스 URI 정보일 수 있다. 그리고, 다운로드 타임은 사용자나 애플리케이션이 설정한 다운로드가 가능한 기간(period)를 나타낸다. 예컨대, 10PM ~ 6AM으로 설정하면, 해당 시간 내에 다운로드 시도 및 다운로드를 수행하라는 것을 의미한다. 웨이크 업 타임은 슬립 모드 상태의 제 2 클라이언트 디바이스(CD2)가 웨이크 업을 하여 콘텐트 서버(CS)로부터 다운로드 요청과 관련된 콘텐트를 다운로드 하도록 지정된 시간을 가리킨다. 경우에 따라, 웨이크 업 타임은 제 1 클라이언트 디바이스(CD1)가 슬립 모드에서 웨이크 업을 수행할 시간을, 즉, 제 2 클라이언트 디바이스(CD2)가 제 1 클라이언트 디바이스(CD1)로 웨이크 업 요청을 전송할 시간을 가리킬 수 있다. 이는 설정을 통해 명확히 규정할 수 있다. 또한, 콘텐트 다운로드 요청(큐 요청) 전송과 관련된 정보를 포함할 수 있다. 콘텐트 다운로드 요청은 NFC 관련 정보 및 다운로드 콘텐트에 대한 수신 조건 정보를 더 포함할 수 있다. 이는 추후 설명하기로 한다.
제 1 클라이언트 디바이스(CD1)가 콘텐트 다운로드 요청을 전송하고 나면, 제 2 클라이언트 디바이스(CD2)는 다운로드 요청에 대한 컨펌 메시지를 제 1 클라이언트 디바이스(CD1)로 전송할 수 있다(S712). 컨펌 메시지는 제 2 클라이언트 디바이스(CD2)의 큐 요청 상태에 대한 자동 통지 메시지일 수 있다. NFC 가능 제 2 클라이언트 디바이스(CD2)는 NFC 인터페이스를 매개로 제 1 클라이언트 디바이스(CD1)로부터 큐 요청을 수신하고, 콘텐트 다운로드 요청 수신이 성공적으로 이루어졌다는 메시지를 제 1 클라이언트 디바이스(CD1)로 전송할 수 있다. 상기 컨펌 메시지는 제 2 클라이언트 디바이스(CD2)가 다운로드를 시작하겠다는 정보를 포함할 수 있다. 또는, 컨펌 메시지와 별도로 다운로드 시작에 대한 응답(Acknowledge)을 전송할 수 있다. 상기 컨펌 메시지의 전송도 NFC를 통해 이루어질 수 있다.
제 1 클라이언트 디바이스(CD1)는 상기 컨펌 메시지를 수신하면 슬립 모드(sleep mode)에 들어갈 수 있다. 슬립 모드는 배터리 소모를 최소화하기 위해, 전력 소비가 가정 적은 상태로 동작하는 모드이다. 사용자는 제 2 클라이언트 디바이스(CD2)가 다운로드하는 동안 제 1 클라이언트 디바이스(CD1) 전력 소모가 최소화되길 원할 수 있다. 따라서, 제 2 클라이언트 디바이스(CD2)로부터 컨펌 메시지가 수신되면, 다운로드가 완료될 때까지 제 1 클라이언트 디바이스(CD1)의 전력 소모를 최소화하기 위해, 슬립 모드로 들어갈 수 있다. 이때, 슬립 모드로의 진입 명령에 의해 슬립 모드로 진입할 수 있는데, 이 경우, 디바이스의 오실레이터는 오프(off)되고, 디바이스 내의 아무런 시스템 클럭도 발생되지 않을 수 있다. 다만, 입출력(I/O) 포트는 슬립 모드 직전의 상태로 남아 있을 수 있다. 슬립 모드는 설정에 따라 여러 단계로 나눠질 수 있다. 즉, 열려있는 프로그램이나 문서를 포함하여 현재 상태 메모리 내용을 유지하고 있는 슬립 모드, 메모리에 기억된 현재 상태를 하드 디스크에 내보내고 메모리는 현재 상태를 유지하지 않는 방식의 슬립 모드, 윈도우의 대기 모드와 유사하게 슬립 모드 전환시 메모리에 현재 상태를 기억만 하고 하드 디스크로 내용을 복사하지 않는 슬립 모드 등을 지원할 수 있다. 이는 시스템 환경 설정 등을 통해 사용자가 선택할 수 있다. 슬립 모드는 특정 타이머에 의해 또는 외부로부터의 웨이크 업 명령을 수신하여 액티브 모드(active mode)로 전환될 수 있다. 액티브 모드는 슬립 모드가 아닌 디바이스가 정상 동작하는 모드이다.
상기 제 2 클라이언트 디바이스(CD2)는 요청을 수신한 이후, 콘텐트 서버(CS)로부터 콘텐트 애셋을 다운로드할 수 있다. 제 2 클라이언트 디바이스(CD2)는 다운로드 요청에 의해 큐에 다운로드할 콘텐트 목록을 보관하고 있을 수 있다. 그리고는, 보관된 목록에 포함된 콘텐트 관련 파일을 콘텐트 서버(CS)로부터 다운로드할 수 있다. 이때, 다운로드 요청에 포함된 다운로드 타임에 제 2 클라이언트 디바이스(CD2)의 다운로드가 이루어질 수 있다.
제 2 클라이언트 디바이스(CD2)가 제 1 클라이언트 디바이스(CD1)의 다운로드 요청과 관련된 콘텐트에 대한 다운로드를 완료한 후, 제 2 클라이언트 디아비스(CD2)는 NFC를 통해 제 1 클라이언트 디바이스(CD1)를 웨이크 업(wake-up)할 수 있다(S714). 이는 웨이크 업 요청을 전송함으로써 이루어질 수 있다. 웨이크 업 요청은 전술한 바와 같이, 콘텐트 다운로드 요청에 포함된 웨이크 업 타임을 기반으로 이루어질 수 있다. 이때, 만약 NFC를 이용한 통신이 불가할 경우, 다른 세부 네트워크 인터페이스, 예컨대, 3G/4G 또는 WLAN을 이용하여 웨이트 업 요청을 전송할 수 있다. NFC 통신의 불가 여부는 기준 시간을 설정하여 기준 시간 내에 NFC를 통해 전송한 웨이크 업 요청에 대한 컨펌 메시지가 수신되는지 여부를 통해 판단할 수 있다. 예컨대, NFC 웨이크 업 요청에 대한 컨펌 메시지 수신 시간을 1분으로 정해놓은 경우, 웨이크 업 요청 전송 후, 1분 동안 컨펌 메시지가 수신되지 않으면, NFC 통신이 불가하다고 판단하고, 다른 무선 통신 네트워크를 통해 웨이크 업 요청을 전송할 수 있다.
제 1 클라이언트 디바이스(CD1)는 웨이크 업 요청을 수신한 후, 웨이크 업을 한다. 즉, 슬립 모드에서 액티브 모드로 전환한다. 그리고는, 웨이크 업에 대한 컨펌 메시지를 제 2 클라이언트 디바이스(CD2)로 전송할 수 있다(S716). 웨이크 업에 대한 컨펌 메시지에는 다운로드 완료된 콘텐트의 애셋의 전송을 요청하는 정보가 포함될 수 있다. 또는 애셋의 전송 요청 메시지를 별도로 전송할 수 있다. 이때, 제 1 클라이언트 디바이스(CD1)는 자신의 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태를 기반으로 사용자 인터페이스를 통해 설정된 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태와 관련된 다운로드 콘텐트 수신 조건과 비교하여 수신 가능 여부를 판단할 수 있다. 판단 결과를 기반으로, 다운로드 콘텐트 애셋의 전송 요청 메시지의 전송 여부를 결정할 수 있다.
이와는 다른 케이스(case)로, 제 2 클라이언트 디바이스(CD2)에서 컨펌 메시지를 수신 후, 콘텐트 다운로드 요청에 포함된, 제 1 클라이언트 디바이스(CD1)의 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태와 관련된 다운로드 콘텐트 수신 조건 정보를 기반으로 콘텐트의 전송 여부를 결정할 수 있다. 즉, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)의 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태를 상기 다운로드 콘텐트 수신 조건과 비교하여 제 1 클라이언트 디바이스(CD1)로의 다운로드 콘텐트 애셋의 전송 여부를 결정할 수 있다. 이때, 제 1 클라이언트 디바이스(CD1)의 현재 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태 정보는 별도로 전송될 수 있고, 또는 콘텐트 다운로드 요청에 포함되어 전송될 수 있다.
또 다른 케이스로, 제 2 클라이언트 디바이스(CD2)는 다운로드된 콘텐트의 사이즈와 제 1 클라이언트 디바이스(CD1)의 현재 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태 정보를 기반으로, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)의 수신 가능 여부를 판단할 수 있다. 그리고, 판단 결과를 기반으로 다운로드 콘텐트 애셋의 전송 여부를 결정할 수 있다.
또 다른 케이스로, 제 2 클라이언트 디바이스(CD2)는 자신의 현재 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태를 다운로드 콘텐트의 사이즈, 전송시 소요되는 배터리 및 통신 자원 중 적어도 어느 하나와 비교하여 다운로드 콘텐트 애셋의 전송 여부를 결정할 수 있다.
상기 복수의 제 1 클라이언트 디바이스(CD1)로의 다운로드 콘텐트 애셋의 수신/전송에 대한 판단은 제 1 클라이언트 디바이스(CD1)의 설정에 의해 제어될 수 있다. 상기 설정 정보는 콘텐트 다운로드 요청에 포함될 수 있다.
제 1 클라이언트 디바이스(CD1)는 큐 요청이 실행되었음을 사용자 인터페이스를 통해 보여줄 수 있다.
제 2 클라이언트 디바이스(CD2)에서, 다운로드 완료된 콘텐트의 애셋은 제 2 클라이언트 디바이스(CD2)로부터 제 1 클라이언트 디바이스(CD1)으로 전송되어질 준비를 한다. 만약, 사용자가 로컬 다운로드를 선택한다면, 선택된 애셋은 제 2 클라이언트 디바이스(CD2)로부터 제 1 클라이언트 디바이스(CD1)로 전송되어진다(S718).
상기의 다운로드 전 과정은 제 1 클라이언트 디바이스(CD1)에서 다운받을 파일을 선택한 후, 제 1 클라이언트 디바이스(CD1)를 제 2 클라이언트 디바이스(CD2)의 일정 반경 내에 위치하여 두면, 자동으로 이루어질 수 있다. 즉, 제 1 클라이언트 디바이스(CD1)는 사용자 설정을 통해 자동으로 콘텐트 다운로드 요청(큐 요청)을 제 2 클라이언트 디바이스(CD2)로 전송할 수 있도록 제어할 수 있다. 제 1 클라이언트 디바이스(CD1)의 사용자는 자동 큐 요청 및 자동 다운로드를 위한 스토리지 사용, 다운로드 기간, 전원/배터리 사용과 관련된 설정을 제어할 수 있다.
제 2 클라이언트 디바이스(CD2)는 자동 콘텐트 다운로드 요청을 NFC를 통해 수신하고, 수신 후, 자동으로 콘텐트를 다운로드하고, 다운로드한 콘텐트를 제 1 클라이언트 디바이스(CD1)로 자동으로 전송할 수 있다. 이는 DLNA를 이용한 다운로드를 보완한 것으로 볼 수 있다.
상기 콘텐트 다운로드 요청은 NFC 링크 셋업 및 관련 프로토콜을 단순화 또는 자동화시키기 위한 네트워크 인터페이스 정보를 지원할 수 있다. 또한, NFC 관련 정보로서, NFC를 위한 디바이스 웨이크 업 정책 정보 및 콘텐트 다운로드 요청 이벤트(예컨대, 콘텐트 다운로드 요청 이벤트는 수행 완료(done) 및 중지(stop) 이벤트를 포함할 수 있음)에 대한 자동 D2D(Device to Device) 통지 메시지와 관련된 정보 중 적어도 어느 하나를 포함할 수 있다.
이때, NFC 링크 셋업을 단순화 또는 자동화시키기 위한 네트워크 인터페이스 정보는 클라이언트 디바이스가 지원하는 복수의 통신 네트워크 타입(예컨대, LAN, WLAN, 2G, 3G, 4G(Wimax 포함), USB, UPnP) 정보에 부가될 수 있다. 제 1 클라이언트 디바이스(CD1)의 매개 디바이스 매니저(124)가 NFC에 의해 제 2 클라이언트 디바이스(CD2)를 발견하는 때, NFC 타입(NFC 모드 및 Tag ID 정보를 포함할 수 있음) 정보를 포함하는 제 2 클라이언트 디바이스(CD2)의 NFC 정보는 최근 연결된 디바이스 리스트에 등록될 수 있다. 또한, 상기 매개 디바이스 매니저(124)는 큐/정책 엔진 NFC 타입, 모드 및 TagID의 구체적인 NFC 정보를 다음과 같이 추가할 수 있다.
<!- NFC Tag Type: Type 1/2/3/4 Tag Operation (Published v1.0 for 1-3, v2.0 for 4, Devices WG of NFC Forum)-> <xs:attribute name=??NFCType?? type="xs:string"/>
<!- NFC Mode: Card Emulation, Peer-to-Peer, Read-Write mode defined by NFC Forum -->
<xs:attribute name=??NFCMode?? type="xs:string"/>
<!- NFC Tag ID ->
<xs:attribute name=??NFCID?? type="xs:string"/>
여기서, 상기 NFC 태그 타입 정보 "NFCType"에 포함된 타입 1/2/3/4(Type 1/2/3/4)는 NFC 포럼의 디바이스 WG과 관련된 v1.0 또는 v2.0에 기재된 타입이며, 타입에 따라 RF 인터페이스, 속도 및 프로토콜이 서로 다르게 정의되어 있을 수 있다. 또한, NFC 모드 정보 "NFCMode" 도 NFC 포럼에서 정의된, 카드 에뮬레이션, 피어-투-피어, 리드-라이트 모드일 수 있다. 여기서 카드 에뮬레이션 모드는 단말기의 온/오프와 관계없이 항상 리더기를 통해 인식되는 모드를, 피어-투-피어 모드는 두 대의 NFC 휴대폰이 카드 리더기로서 작동하여 데이터를 상호 간에 전송하는 모드를, 리드-라이트 모드는 NFC 활성화 상태에서 RFID 태그 정보를 인식하여 휴대폰이 카드 리더기로서 작동하는 모드를 나타낼 수 있다. 또한, NFC 태그 ID 정보 "NFCID"는 NFC 태그를 식별할 수 있는 ID 정보를 나타낸다.
또한, 상기 콘텐트 다운로드 요청은 상기 제 2 클라이언트 디바이스(CD2)가 다운로드 완료시에 제 1 클라이언트 디바이스(CD1) 상기 다운로드된 콘텐트 수신에 대한 조건과 관련된 정보로서, 전원 연결 상태 정보, 배터리 상태 정보, 네트워크 상태 정보 및 저장 가용 공간 정보 중 적어도 어느 하나를 포함할 수 있다. 예컨대, 전원이 연결되어 있는지 연결되어 있지 않은지와 관련된 정보, 배터리의 잔량 정보를 포함할 수 있다. 또한, 네트워크 상태 정보로는 현재 근거리 네트워크가 연결되어 있는지, 3G/4G 무선 네트워크가 연결되어 있는지 등과 관련된 정보를 제공하고, 저장 가용 공간 정보는 현재 디바이스에 할당된 가용 저장 공간이 얼마나 되는지와 관련된 정보를 제공한다. 콘텐트 다운로드 요청은 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태에 따른 다운로드 콘텐트에 대한 수신 여부와 관련된 설정 정보를 포함할 수 있다. 예컨대, 전원이 연결된 경우에만 다운로드 콘텐트를 제 2 클라이언트 디바이스(CD2)로부터 수신하도록 설정하여 전송할 수 있다. 또한, 배터리 상태가 특정 수치(예컨대, 30%) 이상인 경우에만 다운로드 콘텐트를 수신하도록 설정할 수 있다. 이와 같은 설정 정보는 디폴트(default) 정보로 미리 설정시켜 놓고, 사용자 인터페이스를 통해 사용자가 직접 설정을 변경할 수 있도록 할 수 있다.
도 8은 본 발명의 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2) 및 클라우드 서비스 서버(400) 간 송수신되는 신호의 흐름을 설명하기 위한 도면이다.
도 8을 참조하면, 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)와 콘텐트 다운로드 요청, 상기 콘텐트 다운로드 요청에 대한 컨펌 메시지, 웨이크 업 요청, 웨이크 업 요청에 대한 컨펌 메시지 및 다운로드 콘텐트의 송수신을 수행할 때, 클라우드 서비스 서버(400)를 활용할 수 있다. 클라우드 서비스는 사용자가 모바일 디바이스를 통해 저장하던지 또는 PC를 통해 저장하던지, 웹을 통해 저장하던지 어떤 형식이나 형태로 정보를 저장하면, 자발적으로 공유 폴더에 저장하고, 또 원하는 때에 아무데서나 찾을 수 있도록 하는 서비스이다. 이를 관리하는 서버가 클라우드 서비스 서버(400)이다. 클라우드 서비스는 특정 폴더를 지정해 놓으면, 해당 폴더가 공유 폴더가 되어 자동으로 클라우드 서비스 관련 디바이스에 동기화될 수 있다. 클라우드 서비스 서버(400)는 비디오 스토리지를 포함할 수 있고, 여기에 다운로드할 콘텐트를 저장할 수 있다.
제 2 클라이언트 디바이스(CD2)는 콘텐트 다운로드 요청을 수신 후, 클라우드 서비스 서버(400)에 다운로드할 콘텐트를 요청한다. 클라우드 서비스 서버(400)는 요청된 콘텐트 파일을 콘텐트 서버(CS)로부터 미리 다운로드하거나 동기화할 수 있다. 경우에 따라, 클라우스 서비스 서버(400)가 다운로드할 애셋을 식별할 수 있다면, 클라우드 서비스 서버(400)는 애셋을 콘텐트 서버(CS)로부터 다운로드하지 않고, 클라우드 서비스 서버(400)가 다운로드할 애셋에 대한 다운로드 링크(예컨대, 소스 URI)를 제공할 수 있다. 제 2 클라이언트 디바이스(400)는 요청된 콘텐트를 클라우드 서비스 서버(400)로부터 수신할 수 있다. 이후, 제 2 클라이언트 디바이스(CD2)는 웨이크 업 요청을 제 1 클라이언트 디바이스(CD1)로 전송하고, 웨이크 업 요청을 수신한 제 1 클라이언트 디바이스(CD1)는 슬립 모드에서 웨이크 업 한 후, 제 2 클라이언트 디바이스(CD2)로부터 다운로드 완료된 콘텐트를 수신할 수 있다. 또는, 제 1 클라이언트 디바이스(CD1)는 클라우드 서비스 서버(400)와의 동기화를 통해 콘텐트를 제공받을 수 있다.
도 9는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2) 및 클라우드 서비스 서버(400) 간 송수신되는 신호의 흐름을 설명하기 위한 도면이다.
도 9를 참조하면, 제 1 클라이언트 디바이스(CD1)는 클라우드 서비스 서버(400)로 콘텐트 다운로드 요청을 전송할 수 있다(S910). 예컨대, 제 2 클라이언트 디바이스(CD2)가 가용하지 않는 경우(예컨대, 슬립 모드(sleep-mode)이거나, 전원이 꺼져 있거나, 또는 네트워크 인터페이스가 다운된 경우)에, 제 1 클라이언트 디바이스(CD1)의 큐/정책 엔진(120)은 콘텐트 다운로드 요청(큐 요청)을 지정된 클라우드 서비스로 전송할 수 있다. 전술한 바와 같이, 상기 콘텐트 다운로드 요청은 소스 URI, 다운로드/웨이크 업 시간 정보를 포함할 수 있다. 여기서, 다운로드 타임은 사용자나 애플리케이션이 설정한 다운로드가 가능한 시간이고, 웨이크 업 타임 정보는 슬립 모드에 있는 제 2 클라이언트 디바이스(CD2)를 웨이크 업시켜 다운로드를 수행하도록 하는 시간을 나타낸다.
이러한 사용 케이스(use case)는 클라이언트 디바이스들(CD1, CD2)과 클라우드 서비스간 파일 동기화에 유리할 수 있다. 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)가 슬립 모드에 있다면, 클라우드 서비스 서버(400)로 다운로드 요청을 전송하고, 클라우드 서비스 서버(400)가 다운로드/웨이크 업 타임에 맞춰 제 2 클라이언트 디바이스(CD2)를 웨이크 업 하도록 할 수 있다. 클라우드 서비스 서버(400)는 고유 알고리즘을 통해 추천된 애셋을 선택할 수 있다. 그리고는, 사용자를 대신하여 제 2 클라이언트 디바이스(CD2)에 다운로드 요청을 전송할 수 있다. 사용자는 자동 큐 요청 및 다운로딩을 위해, 스토리지 사용, 다운로드 기간, 전원/배터리 사용과 관련된 설정을 제어할 수 있다.
콘텐트 다운로드 요청을 수신한 클라우드 서비스 서버(400)는 다운로드 요청에 대한 컨펌 메시지를 제 1 클라이언트 디바이스(CD1)로 전송할 수 있다(S912). 컨펌 메시지를 수신한 제 1 클라이언트 디바이스(CD1)는 전력 소모를 경감하기 위해 슬립 모드에 들어갈 수 있다. 클라우드 서비스 서버(400)는 콘텐트 다운로드 요청을 기반으로 다운로드할 콘텐트의 애셋을 미리 다운로드할 수 있다.
클라우드 서비스 서버(400)는 제 2 클라이언트 디바이스(CD2)로 웨이크 업 요청을 전송할 수 있다(S914). 웨이크 업 요청을 수신한 제 2 클라이언트 디바이스(CD2)는 웨이크 업을 수행하여 슬립 모드에서 액티브 모드로 전환한다.
제 2 클라이언트 디바이스(CD2)는 웨이크 업 요청에 대한 컨펌 메시지를 전송할 수 있다(S916).
컨펌 메시지를 수신한 클라우드 서비스 서버(400)는 요청된 콘텐트를 제 2 클라이언트 디바이스(CD2)로 전송할 수 있다(S918). 즉, 클라우드 서비스에 있는 콘텐트를 직접 전송(push)할 수 있다. 경우에 따라, 콘텐트 다운로드 요청이 클라우드 서비스 서버(400) 뿐만 아니라 NFC를 통해 제 2 클라이언트 디바이스(CD2)에도 함께 전송되는 경우를 가정할 수 있다. 이 경우, 다운로드할 콘텐트의 애셋이 제 2 클라이언트 디바이스와 클라우드 서비스 서버(400)에 다운로드 될 수 있다. 만약, 클라우드 서비스 서버(400)가 다운로드할 애셋을 식별할 수 있다면, 클라우드 서비스 서버(400)는 애셋을 콘텐트 서버(CS)로부터 다운로드하지 않고, 클라우드 서비스 서버(400)가 다운로드할 애셋에 대한 다운로드 링크(예컨대, 소스 URI 또는 URL)를 제공할 수 있다.
콘텐트 다운로드가 완료되면, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)에 웨이크 업 요청을 전송한다. 웨이크 업 요청은 NFC를 통해 이루어질 수 있다. 웨이크 업 요청을 수신한 제 1 클라이언트 디바이스(CD1)는 웨이크 업을 하여 액티브 모드로 전환한 후, 다운로드하기 위해 애셋을 요청한다(S920). 애셋에 대한 요청도 NFC를 통해 이루어질 수 있다. 다만, NFC를 통해 전송한 웨이크 업 요청에 대한 컨펌 메시지가 기준 시간 동안 수신되지 않으면, 제 2 클라이언트 디바이스(CD2)는 WLAN, 3G/4G 등 다른 무선 통신 네트워크를 통해 웨이크 업 요청을 전송한다.
제 2 클라이언트 디바이스(CD2)는 다운로드 완료된 콘텐트의 애셋을 제 1 클라이언트 디바이스(CD1)로 전송할 수 있다(S922). 또는 제 1 클라이언트 디바이스(CD1)는 클라우드 서비스의 동기화 기능을 통해 다운로드 콘텐트를 수신할 수 있다.
도 10은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2), 제 3 클라이언트 디바이스(CD3) 및 콘텐트 서버(CS) 간의 송수신되는 신호의 흐름을 설명하기 위한 도면이다. 여기서 제 3 클라이언트 디바이스(CD3)는 제 1 및 제 2 클라이언트 디바이스(CD1, CD2)가 아닌 다른 클라이언트 디바이스를 의미하며, 클라우드 서비스 서버(400)도 포함할 수 있다. 제 3 클라이언트 디바이스(CD3)는 동일 홈 네트워크에 포함된 다른 가전 기기(예컨대, 스마트 TV)일 수 있고, NFC 통신이 가능할 수 있다.
도 10을 참조하면, 제 1 클라이언트 디바이스(CD1)는 NFC 가능한 제 3 클라이언트 디바이스(CD3)로 NFC 인터페이스를 매개로 하여 콘텐트 다운로드 요청을 전송한다(S1010). 그리고는, 상기 콘텐트 다운로드 요청을 받은 제 3 클라이언트 디바이스(CD3)는 NFC 인터페이스를 매개로 상기 콘텐트 다운로드 요청에 대한 컨펌 메시지를 제 1 클라이언트 디바이스(CD1)로 전송한다(S1012). 이때, 제 3 클라이언트 디바이스(CD3)는 제 2 클라이언트 디바이스(CD2)가 콘텐트 서버(CD)로부터 이후에 콘텐트 애셋을 다운로드 하도록 제 2 클라이언트 디바이스(CD2)로 상기 콘텐트 다운로드 요청을 포워딩할 수 있다(S1014). 즉, 제 3 클라이언트 디바이스(CD3)는 콘텐트 다운로드 요청의 중계자 역할을 할 수 있다. 이때, 제 3 클라이언트 디바이스(CD3)가 저장 장치(예컨대, USB 드라이브, HDD, 플래시 메모리 등)를 가지고 있다면, 콘텐트 서버(CS)로부터 자신의 저장 장치에 상기 애셋을 직접 다운로드받을 수 있다.
다음으로, 상기 콘텐트 다운로드 요청을 제 3 클라이언트 디바이스(CD3)로부터 수신한 제 2 클라이언트 디바이스(CD2)는 요청된 콘텐트의 애셋을 콘텐트 서버(CS)로부터 다운로드 한다(S1016). 그리고는, 상기 제 3 클라이언트 디바이스(CD3)와 상기 제 2 클라이언트 디바이스(CD2)는 다운로드 요청의 상태를 서로 교환한다(S1018). 그리고는, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)에 웨이크 업 요청을 전송한다. 웨이크 업 요청은 NFC를 통해 이루어질 수 있다. 웨이크 업 요청을 수신한 제 1 클라이언트 디바이스(CD1)는 웨이크 업을 하여 액티브 모드로 전환한 후, 다운로드하기 위해 애셋을 요청한다(S1020). 애셋에 대한 요청도 NFC를 통해 이루어질 수 있다. 다만, NFC를 통해 전송한 웨이크 업 요청에 대한 컨펌 메시지가 기준 시간 동안 수신되지 않으면, 제 2 클라이언트 디바이스(CD2)는 WLAN, 3G/4G 등 다른 무선 통신 네트워크를 통해 웨이크 업 요청을 전송한다.
제 2 클라이언트 디바이스(CD2)는 다운로드된 콘텐트의 애셋을 제 1 클라이언트 디바이스(CD1)로 전송할 수 있다(S1022).
도 11은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2) 및 콘텐트 서버(CS) 간의 송수신되는 신호의 시퀀스 다이어그램이다.
도 11을 참조하면, 제 1 클라이언트 디바이스(CD1)의 큐/정책 엔진(123: QPE)은 큐 요청(콘텐트 다운로드 요청) 및 상기 큐 요청으로부터 파생되는 콘텐트 다운로드의 과정을 관리한다. 큐 요청을 전송하기에 앞서, 제 1 클라이언트 디바이스(CD1)의 매개 디바이스 매니저(124)는 제 2 클라이언트 디바이스를 디스커버리(discovery)한다. 즉, 제 1 클라이언트 디바이스(CD1)가 최근 접속한 기기들의 리스트(Recently Connected Device List)를 활용하여 접속 가능한 디바이스들을 발견한다. 제 2 클라이언트 다비이스(CD2)가 최근 접속한 디바이스 리스트에 등록되어 있는 것을 가정한다. 최근 접속 기기 리스트와 관련된 절차는 이하, 도 19 내지 24를 통해 설명하도록 한다.
제 2 클라이언트 디바이스(CD2)를 발견하고 나면, 먼저, 제 1 클라이언트 디바이스(CD1)는 콘텐트 서버(CS)로부터 다운로드 받을 콘텐트의 소스 URI를 획득한다(S1110).
그리고는, 제 1 클라이언트 디바이스(CD1)는 NFC 인터페이스를 이용하여 제 2 클라이언트 디바이스(CD2)를 웨이크 업 한다(S1112). 웨이크 업은 웨이크 업 요청을 전송하는 방식을 통해 이루어질 수 있다.
웨이크 업 요청을 수신한 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD2)로 상기 웨이크 업 요청에 대한 응답을 전송할 수 있다(S1114). 상기 응답에는 큐 요청을 수신할 준비가 되었다는 정보가 포함될 수 있다.
상기 웨이크 업 요청에 대한 응답을 수신한 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)에 애셋을 저장하도록 하기 위한 큐 요청을 전송한다(S1116). 상기 큐 요청은 소스 URI를 포함하는 다운로드 관련 정보를 포함할 수 있다. 또한, NFC 관련 정보로서, NFC 링크 셋업 및 관련 프로토콜을 단순화 또는 자동화시키기 위한 네트워크 인터페이스 정보, NFC를 위한 디바이스 웨이크 업 정책 정보 및 콘텐트 다운로드 요청 이벤트(예컨대, 콘텐트 다운로드 요청 이벤트는 수행 완료(done) 및 중지(stop) 이벤트를 포함할 수 있음)에 대한 자동 D2D(Device to Device) 통지 메시지와 관련된 정보 중 적어도 어느 하나를 포함할 수 있다. 또한, 상기 콘텐트 다운로드 요청은 상기 제 2 클라이언트 디바이스(CD2)가 다운로드 완료시에 제 1 클라이언트 디바이스(CD1)의 상기 다운로드된 콘텐트 수신 조건과 관련된 정보로서, 전원 연결 상태 정보, 배터리 상태 정보, 네트워크 상태 정보 및 저장 가용 공간 정보 중 적어도 어느 하나를 포함할 수 있다.
상기 큐 요청을 수신한 제 2 클라이언트 디바이스(CD2)는 큐 요청을 확인하고, 애셋에 대한 다운로드를 시작하겠다는 컨펌 메시지를 제 1 클라이언트 디바이스(CD1)로 전송한다(S1118).
제 1 클라이언트 디바이스(CD1)가 제 2 클라이언트 디바이스(CD2)로부터 컨펌 메시지를 수신하면, 제 2 클라이언트 디바이스(CD2)가 콘텐트를 다운로드하는 동안 슬립 모드에 들어간다(S1120). 이때, 일정 시간을 정해놓고, 타이머 이벤트를 통해 슬립 모드에서 웨이크 업을 하도록 할 수도 있고, 제 2 클라이언트 디비아스(CD2)로부터 웨이크 업 요청을 수신하는 경우, 웨이크 업을 하도록 설정할 수 있다. 이러한 설정 정보는 큐 요청에 포함될 수 있다.
제 2 클라이언트 디바이스(CD2)는 콘텐트 서버(CS)로부터 다운로드 받은 콘텐트의 애셋을 다운로드한다(S1122). 제 2 클라이언트 디바이스(CD2)는 큐 요청에 포함된 소스 URI를 통해 해당 주소를 찾아가서, 콘텐트를 다운받을 수 있다.
다운로드가 완료되면(S1124), 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)로 다운로드할 콘텐트의 애셋의 다운로드가 완료되었음을 알릴 수 있다(S1126). 다만, 별도의 완료 메시지를 전송하지 않고, 제 2 클라이언트 디바이스(CD2)가 완료되었음을 알리기 위해 NFC를 통해 제 1 클라이언트 디바이스(CD1)로 웨이크 업 요청을 전송할 수 있다(S1128).
제 1 클라이언트 디바이스(CD1)는 상기 웨이크 업 요청을 NFC 인터페이스를 통해 수신한 경우, 웨이크 업을 수행하여 슬립 모드에서 액티브 모드로 전환하고, 다운로드를 위해 애셋을 요청한다(S1130). 다만, 이때, 제 1 클라이언트 디바이스(CD1)는 자신의 상태 정보(예컨대, 전원 연결 상태, 배터리 잔량, 네트워크 상태, 저장 가용 공간의 상태)를 기반으로 다운로드된 콘텐트의 수신 여부를 판단하여 애셋의 요청의 전송할지를 결정할 수 있다. 상기 수신 조건을 만족한다면, 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)로 애셋 요청을 전송하고, 만족하지 못하는 경우, 제 2 클라이언트 디바이스(CD2)에만 다운로드 콘텐트가 저장되도록 한 채, 애셋 요청을 전송하지 않을 수 있다.
제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)가 다운로드를 원할 경우, 다운로드 완료된 콘텐트를 보내줄 수 있다(S1132). 이때, 큐 요청에 다운로드된 콘텐트의 수신 조건과 관련된 설정 정보 및 현재 제 1 클라이언트 디바이스의 수신 상태 정보가 포함되어 있을 때, 제 2 클라이언트 디바이스(CD2)는 다운로드 콘텐트의 전송 여부를 판단할 수 있다. 또한, 제 2 클라이언트 디바이스(CD2)는 다운로드 완료된 콘텐트의 사이즈, 자신의 배터리 잔량 또는 무선 통신 자원 등을 고려하여 제 1 클라이언트 디바이스(CD1)로의 전송 여부를 판단할 수 있다.
도 12는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2) 및 콘텐트 서버(CS) 간의 송수신되는 신호의 시퀀스 다이어그램이다. 본 실시예에서, 제 2 클라이언트 디바이스(CD2)가 다운로드 완료 후, NFC로 제 1 클라이언트 디바이스(CD1)를 웨이크 업 할 수 없는 경우, WLAN이나 3G/4G 무선 통신을 이용하여 웨이크 업을 수행할 수 있다.
도 12를 참조하면, 큐 요청을 전송하기에 앞서, 제 1 클라이언트 디바이스(CD1)의 매개 디바이스 매니저(124)는 제 2 클라이언트 디바이스를 디스커버리(discovery)한다. 즉, 제 1 클라이언트 디바이스(CD1)가 최근 접속한 기기들의 리스트(Recently Connected Device List)를 활용하여 접속 가능한 디바이스들을 발견한다. 도 11의 실시예와 마찬가지로, 제 2 클라이언트 다비이스(CD2)가 최근 접속한 디바이스 리스트에 등록되어 있는 것을 가정한다.
제 2 클라이언트 디바이스(CD2)를 발견하고 나면, 먼저, 제 1 클라이언트 디바이스(CD1)는 콘텐트 서버(CS)로부터 다운로드 받을 콘텐트의 소스 URI를 획득한다(S1210).
그리고는, 제 1 클라이언트 디바이스(CD1)는 NFC 인터페이스를 이용하여 제 2 클라이언트 디바이스(CD2)를 웨이크 업 한다(S1212). 웨이크 업 요청을 수신한 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD2)로 상기 웨이크 업 요청에 대한 응답을 전송할 수 있다(S1214). 상기 응답에는 큐 요청을 수신할 준비가 되었다는 정보가 포함될 수 있다.
상기 웨이크 업 요청에 대한 응답을 수신한 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)에 애셋을 저장하도록 하기 위한 큐 요청을 전송한다(S1216). 상기 큐 요청은 소스 URI를 포함하는 다운로드 관련 정보, NFC 관련 정보, 다운로드 콘텐트의 수신 조건과 관련된 설정 정보 및 다운로드 콘텐트의 수신을 위한 상태 정보 중 적어도 어느 하나를 포함할 수 있다.
상기 큐 요청을 수신한 제 2 클라이언트 디바이스(CD2)는 큐 요청을 확인하고, 애셋에 대한 다운로드를 시작하겠다는 컨펌 메시지를 제 1 클라이언트 디바이스(CD1)로 전송한다(S1218).
제 1 클라이언트 디바이스(CD1)가 제 2 클라이언트 디바이스(CD2)로부터 컨펌 메시지를 수신하면, 제 2 클라이언트 디바이스(CD2)가 콘텐트를 다운로드하는 동안 슬립 모드에 들어간다(S1220). 이때, 일정 시간을 정해놓고, 타이머 이벤트를 통해 슬립 모드에서 웨이크 업을 하도록 할 수도 있고, 제 2 클라이언트 디비아스(CD2)로부터 웨이크 업 요청을 수신하는 경우, 웨이크 업을 하도록 설정할 수 있다. 이러한 설정 정보는 큐 요청에 포함될 수 있다.
제 2 클라이언트 디바이스(CD2)는 콘텐트 서버(CS)로부터 다운로드 받은 콘텐트의 애셋을 다운로드한다(S1222). 제 2 클라이언트 디바이스(CD2)는 큐 요청에 포함된 소스 URI를 통해 해당 주소를 찾아가서, 콘텐트를 다운받을 수 있다.
다운로드가 완료되면(S1224), 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)로 다운로드할 콘텐트의 애셋의 다운로드가 완료되었음을 알릴 수 있다(S1226). 다만, 별도의 완료 메시지를 전송하지 않고, 제 2 클라이언트 디바이스(CD2)가 완료되었음을 알리기 위해 NFC를 통해 제 1 클라이언트 디바이스(CD1)로 웨이크 업 요청을 전송할 수 있다(S1228). 웨이크 업 요청에는 다은로드가 완료되었다는 정보가 포함될 수 있다.
제 1 클라이언트 디바이스(CD1)가 NFC 통신이 불가한 경우를 가정하였을 때, 상기 NFC 인터페이스를 통한 웨이크 업 요청에 대한 컨펌 메시지가 기준 시간 동안 수신되지 않을 것이다. 즉, 기준 시간 동안 웨이크 업 요청에 대한 응답이 없을 경우, 제 2 클라이언트 디바이스(CD2)는 NFC의 타겟 디바이스가 발견되지 않았다고 판단할 수 있다(S1230).
따라서, 제 2 클라이언트 디바이스(CD2)는 WLAN 또는 3G/4G 무선 통신을 통해 애셋 다운로드가 완료되었음을 알리기 위해 웨이크 업 요청을 전송한다(S1232). 이때, UPnP 또는 DLNA를 통해 웨이크 업을 수행할 수 있다.
제 1 클라이언트 디바이스(CD1)는 웨이크 업 요청을 WLAN 또는 3G/4G 무선 통신을 통해 수신한 경우, 웨이크 업을 수행하여 슬립 모드에서 액티브 모드로 전환하고, 다운로드를 위해 애셋을 요청한다(S1234).
그리고는, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)가 다운로드를 원할 경우, 다운로드 완료된 콘텐트를 전송할 수 있다(S1236).
도 13은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2) 및 콘텐트 서버(CS) 간의 송수신되는 신호의 시퀀스 다이어그램이다. 본 실시예에서는, 콘텐트 서버(CS)(여기서, 콘텐트 서버(CS)는 클라우드 서비스 서버(400)일 수 있음)가 제 2 클라이언트 디바이스(CD2)에게 큐 요청을 전송하고, 제 2 클라이언트 디바이스(CD2)가 다운로드 후, NFC 인터페이스를 통해 제 1 클라이언트 디바이스(CD1)를 웨이크 업 할 수 없는 경우, WLAN이나 3G/4G를 이용하여 웨이크 업을 수행한다.
도 13을 참조하면, 큐 요청을 전송하기에 앞서, 제 1 클라이언트 디바이스(CD1)의 매개 디바이스 매니저(124)는 제 2 클라이언트 디바이스를 디스커버리(discovery)한다. 즉, 제 1 클라이언트 디바이스(CD1)가 최근 접속한 기기들의 리스트(Recently Connected Device List)를 활용하여 접속 가능한 디바이스들을 발견한다. 도 11의 실시예와 마찬가지로, 제 2 클라이언트 다비이스(CD2)가 최근 접속한 디바이스 리스트에 등록되어 있는 것을 가정한다.
제 2 클라이언트 디바이스(CD2)를 발견하고 나면, 먼저, 제 1 클라이언트 디바이스(CD1)는 콘텐트 서버(CS)로부터 다운로드 받을 콘텐트의 소스 URI를 획득한다(S1310).
그리고는, 제 1 클라이언트 디바이스(CD1)는 콘텐트 서버(CS)로 제 2 클라이언트 디바이스(CD2)에 애셋을 저장하도록 하기 위한 큐 요청을 전송한다(S1312). 상기 큐 요청은 소스 URI, 다운로드/웨이크 업 타임을 포함하는 다운로드 관련 정보, NFC 관련 정보, 다운로드 콘텐트의 수신 조건과 관련된 설정 정보 및 다운로드 콘텐트의 수신을 위한 상태 정보 중 적어도 어느 하나를 포함할 수 있다.
상기 큐 요청을 수신한 콘텐트 서버(CS)는 큐 요청을 확인하고, 제 2 클라이언트 디바이스(CD2)가 현재 온 상태인지 확인한다(S1314). 즉, 제 2 클라이언트 디바이스(CD2)가 슬립 모드 또는 전원이 꺼져 있는 상태인지 확인한다.
만약, 제 2 클라이언트 디바이스(CD2)가 큐 요청에 포함되어 있는 웨이크 업 타임에 슬립 모드에 있는 경우, 콘텐트 서버(CS)는 WLAN 또는 3G/4G 무선 통신 네트워크를 이용하여 애셋을 저장하기 위한 큐 요청을 통지하기 위한 웨이크 업 요청을 제 2 클라이언트 디바이스(CD2)로 전송한다(S1316).
그리고는, 콘텐트 서버(CS)는 제 2 클라이언트 디바이스(CD2)로 애셋을 다운로드 시킨다(S1318). 즉, 제 2 클라이언트 디바이스(CD2)는 콘텐트 서버(CS)로부터 다운로드 받은 콘텐트의 애셋을 다운로드한다. 제 2 클라이언트 디바이스(CD2)는 큐 요청에 포함된 소스 URI를 통해 해당 주소를 찾아가서, 콘텐트를 다운받을 수 있다.
이때, 애셋의 다운로드를 시작함을 알리는 컨펌 메시지를 제 1 클라이언트 디바이스(CD1)로 전송한다(S1320). 다운로드의 시작과 컨펌 메시지의 전송의 순서는 서로 뒤바뀌어도 문제없다.
제 1 클라이언트 디바이스(CD1)가 콘텐트 서버(CS)로부터 컨펌 메시지를 수신하면, 제 2 클라이언트 디바이스(CD2)가 콘텐트를 다운로드하는 동안 슬립 모드에 들어간다(S1322). 이때, 일정 시간을 정해놓고, 타이머 이벤트를 통해 슬립 모드에서 웨이크 업을 하도록 할 수도 있고, 제 2 클라이언트 디비아스(CD2)로부터 웨이크 업 요청을 수신하는 경우, 웨이크 업을 하도록 설정할 수 있다. 이러한 설정 정보는 큐 요청에 포함될 수 있다.
다운로드가 완료되면(S1324), 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)로 다운로드할 콘텐트의 애셋의 다운로드가 완료되었음을 알릴 수 있다(S1326). 다만, 별도의 완료 메시지를 전송하지 않고, 제 2 클라이언트 디바이스(CD2)가 완료되었음을 알리기 위해 NFC를 통해 제 1 클라이언트 디바이스(CD1)로 웨이크 업 요청을 전송할 수 있다(S1328). 웨이크 업 요청에는 다은로드가 완료되었다는 정보가 포함될 수 있다.
제 1 클라이언트 디바이스(CD1)가 NFC 통신이 불가한 경우를 가정하였을 때, 상기 NFC 인터페이스를 통한 웨이크 업 요청에 대한 컨펌 메시지가 기준 시간 동안 수신되지 않을 것이고, 기준 시간 동안 웨이크 업 요청에 대한 응답이 없을 경우, 제 2 클라이언트 디바이스(CD2)는 NFC의 타겟 디바이스가 발견되지 않았다고 판단할 수 있다(S1330).
따라서, 제 2 클라이언트 디바이스(CD2)는 WLAN 또는 3G/4G 무선 통신을 통해 애셋 다운로드가 완료되었을을 알리기 위해 웨이크 업 요청을 전송한다(S1332).
제 1 클라이언트 디바이스(CD1)는 웨이크 업을 WLAN 또는 3G/4G 무선 통신을 통해 수신한 경우, 웨이크 업을 수행하여 슬립 모드에서 액티브 모드로 전환하고, 다운로드를 위해 애셋을 요청한다(S1334).
그리고는, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)가 다운로드를 원할 경우, 다운로드 완료된 콘텐트를 보내줄 수 있다(S1336).
도 14는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 예시적인 사용예에 따라, 제 1 클라이언트 디바이스(CD1), 제 2 클라이언트 디바이스(CD2), 제 3 클라이언트 디바이스(CD3) 및 콘텐트 서버(CS) 간의 송수신되는 신호의 시퀀스 다이어그램이다. 본 실시예에서는, 제 3 클라이언트 디바이스(CD3)가 제 2 클라이언트 디바이스(CD2)로 큐 요청을 중계한다.
도 14를 참조하면, 큐 요청을 전송하기에 앞서, 제 1 클라이언트 디바이스(CD1)의 매개 디바이스 매니저(124)는 제 2 클라이언트 디바이스를 디스커버리(discovery)한다. 즉, 제 1 클라이언트 디바이스(CD1)가 최근 접속한 기기들의 리스트(Recently Connected Device List)를 활용하여 접속 가능한 디바이스들을 발견한다. 도 11의 실시예와 마찬가지로, 제 2 클라이언트 다비이스(CD2)가 최근 접속한 디바이스 리스트에 등록되어 있는 것을 가정한다.
제 2 클라이언트 디바이스(CD2)를 발견하고 나면, 먼저, 제 1 클라이언트 디바이스(CD1)는 콘텐트 서버(CS)로부터 다운로드 받을 콘텐트의 소스 URI를 획득한다(S1410).
그리고는, 제 1 클라이언트 디바이스(CD1)는 제 3 클라이언트 디바이스(CD3)로 제 2 클라이언트 디바이스(CD2)에 애셋을 저장하도록 하기 위한 큐 요청을 전송한다(S1412). 상기 큐 요청은 소스 URI, 다운로드/웨이크 업 타임을 포함하는 다운로드 관련 정보, NFC 관련 정보, 다운로드 콘텐트의 수신 조건과 관련된 설정 정보 및 다운로드 콘텐트의 수신을 위한 상태 정보 중 적어도 어느 하나를 포함할 수 있다.
상기 큐 요청을 수신한 제 3 클라이언트 디바이스(CD3)는 큐 요청을 확인하고, 상기 큐 요청을 잘 수신했다는 컨펌 메시지를 제 1 클라이언트 디바이스(CD1)로 전송할 수 있다(S1414).
제 1 클라이언트 디바이스(CD1)가 콘텐트 서버(CS)로부터 컨펌 메시지를 수신하면, 제 2 클라이언트 디바이스(CD2)가 콘텐트를 다운로드하는 동안 슬립 모드에 들어간다(S1416).
제 3 클라이언트 디바이스(CD3)는 제 2 클라이언트 디바이스(CD2)가 현재 온 상태인지 확인하고, 만약, 제 2 클라이언트 디바이스(CD2)가 큐 요청에 포함되어 있는 웨이크 업 타임에 슬립 모드에 있는 경우, WLAN 또는 3G/4G 무선 통신 네트워크를 이용하여 웨이크 업 요청을 제 2 클라이언트 디바이스(CD2)로 전송한다(S1418).
제 3 클라이언트 디바이스(CD3)는 제 2 클라이언트 디바이스(CD2)를 깨우고 난 후, 큐 요청을 포워딩 한다(S1420). 제 2 클라이언트 디바이스(CD2)는 웨이크 업을 수행한 후, 큐 요청에 대한 응답을 제 3 클라이언트 디바이스(CD3)로 전송할 수 있다(S1422).
그리고는, 제 2 클라이언트 디바이스(CD2)는 콘텐트 서버(CS)로부터 다운로드 받은 콘텐트의 애셋을 다운로드한다(S1424). 제 2 클라이언트 디바이스(CD2)는 큐 요청에 포함된 소스 URI를 통해 해당 주소를 찾아가서, 콘텐트를 다운받을 수 있다.
다운로드가 완료되면(S1426), 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)로 다운로드할 콘텐트의 애셋의 다운로드가 완료되었음을 알릴 수 있다(S1428). 별도의 완료 메시지를 전송하지 않고, 제 2 클라이언트 디바이스(CD2)가 완료되었음을 알리기 위해 NFC를 통해 제 1 클라이언트 디바이스(CD1)로 웨이크 업 요청을 전송할 수 있다(S1438). 웨이크 업 요청에는 다은로드가 완료되었다는 정보가 포함될 수 있다. 다운로드와 관련하여, 도면에 도시되진 않았지만, 제 2 클라이언트 디바이스(CD2)와 제 3 클라이언트 디바이스(CD3)는 큐 요청 상태를 교환할 수 있다. 예컨대, 제 2 클라이언트 디바이스(CD2)는 큐 요청에 의해 다운로드가 완료 또는 진행 중인지와 관련된 정보를 교환할 수 있다.
제 1 클라이언트 디바이스(CD1)가 NFC 통신이 불가한 경우를 가정하였을 때, 상기 NFC 인터페이스를 통한 웨이크 업 요청에 대한 컨펌 메시지가 기준 시간 동안 수신되지 않을 것이고, 기준 시간 동안 웨이크 업 요청에 대한 응답이 없을 경우, 제 2 클라이언트 디바이스(CD2)는 NFC의 타겟 디바이스가 발견되지 않았다고 판단할 수 있다(S1432).
따라서, 제 2 클라이언트 디바이스(CD2)는 WLAN 또는 3G/4G 무선 통신을 통해 애셋 다운로드가 완료되었을을 알리기 위해 웨이크 업 요청을 전송한다(S1434).
제 1 클라이언트 디바이스(CD1)는 웨이크 업을 WLAN 또는 3G/4G 무선 통신을 통해 수신한 경우, 웨이크 업을 수행하여 슬립 모드에서 액티브 모드로 전환하고, 다운로드를 위해 애셋을 요청한다(S1436).
그리고는, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)가 다운로드를 원할 경우, 다운로드 완료된 콘텐트를 보내줄 수 있다(S1438).
도 15는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 클라이언트 애플리케이션과 관련하여 설정을 입력할 수 있는 사용자 인터페이스의 예를 도시한 도면이다.
도 15-A 도면을 참조하면, 제 1 클라이언트 디바이스(CD1)는 사용자 인터페이스(UI:User Interface)를 통해 클라이언트 애플리케이션의 기본 설정을 제어할 수 있다. 먼저, 사용자는 자동 큐 다운로드(Auto Queued Download)를 인에이블하도록 세팅할 수 있다. 예컨대, 인에이블 자동 큐 다운로드 설정은 온 오프 방식으로 제어할 수 있다. 인에이블 자동 큐 다운로드 설정을 온으로 해 놓으면, 클라이언트 디바이스의 큐에 들어있는 콘텐트를 자동으로 다운로드 한다. 이때, 최근 접속한 디바이스 목록을 통해 자동 큐 다운로드를 통해 다운로드 받은 타겟 디바이스(예컨대, 제 2 클라이언트 디바이스 또는 매개 디바이스일 수 있음)를 선택할 수 있다. 도면에 도시된 바와 같이, 매개 디바이스 매니저(124)는 클라이언트 디바이스들을 발견하는데, 스마트 폰 1, 사용자 태블릿 1 및 사용자 TV 1이 등록되어 있다. 사용자는 스마트 폰 1과 사용자 TV 1만 이웃 디바이스(Neighbor Devices)로 지정하여 큐 요청을 전송하여 콘텐트 다운로드를 받도록 할 타겟 디바이스로 지정할 수 있다.
도 15-B 도면을 참조하면, 사용자는 사용자 인터페이스를 통해 제 1 클라이언트 디바이스(CD1)의 다운로드 설정을 제어할 수 있다. 이는 자동 큐 다운로드를 실행할 때, 제 2 클라이언트 디바이스(CD2)로부터 다운로드 완료된 콘텐트의 수신 여부를 판단하는데 사용될 수 있다. 먼저, 전원 연결 상태에 따라 전원이 연결되어 있을 때만 다운로드를 수행하도록 설정할 수 있다. 그리고, 배터리 상태에 따라 특정 비율(예컨대, 40%, 50% 60% 또는 70% 등) 이상으로 배터리가 충전되어 있을 때만 다운로드를 수행하도록 설정할 수 있다. 또한, 네트워크 상태에 따라 웨이크 업을 통한 통지 관련 설정을 제어할 수 있는데, NFC를 이용할지, WLAN, 또는 3G/4G 무선 네트워크를 이용할지 아니면 복수의 네트워크 인터페이스를 이용할지 선택할 수 있다. 또한, 경우에 따라 사용자는 사용자 인터페이스를 통해 제 2 클라이언트 디바이스(CD2)의 다운로드 설정을 제어할 수 있다. 이는 상기 전원 연결 상태, 배터리 상태, 네트워크 상태를 기반으로 제 2 클라이언트 디바이스(CD2)가 큐 요청에 의한 다운로드의 수행 여부를 판단하는데 사용될 수 있다.
도 15-C 도면을 참조하면, 사용자는 사용자 인터페이스를 통해 제 1 클라이언트 디바이스(CD1)의 다운로드 저장 설정을 제어할 수 있다. 즉, 다운로드 저장 영역을 할당할 수 있다. 예컨대, 외부 저장 장치의 사용 여부를 선택할 수 있다. 예컨대, USB, HDD 또는 플래시 메모리와 같은 외부 메모리를 사용하는 경우, 외부 저장 장치를 사용하도록 설정하고, 사용할 수 있는 메모리를 선택할 수 있다. 다운로드 저장 영역 할당 설정을 통해 퍼센트 할당을 수행할 수 있다. 이는 클라이언트 디바이스의 저장 수단의 특정 비율(퍼센트)까지 다운로드된 콘텐트를 저장하도록 설정할 수 있다. 또한, 사용자는 직접 다운로드 콘텐트 저장을 위한 스토리지 크기를 입력할 수도 있다. 예컨대, 사용자가 2GB의 크기 할당을 설정해 놓으면, 다운로드되는 콘텐트는 2GB까지만 다운로드가 되고, 이를 초과하는 용량에 대해서는 다운로드를 수행하지 않도록 제어된다. 더욱이, 경우에 따라, 사용자는 사용자 인터페이스를 통해 제 2 클라이언트 디바이스(CD2)의 다운로드 설정을 제어할 수 있다. 이는 제 2 클라이언트 디바이스(CD2)의 저장 가용 공간의 상태를 기반으로 제 2 클라이언트 디바이스(CD2)가 큐 요청에 의한 다운로드의 수행 여부를 판단하는데 사용될 수 있다.
이렇게 사용자 인터페이스를 통해 설정된 사항에 대해서는 큐 요청에 해당 정보를 포함시켜 제 2 및 제 3 클라이언트 디바이스(CD2, CD3)로 전송될 수 있다.
큐 요청을 좀더 구체적으로 살펴보면, 클라이언트 디바이스의 큐/정책 엔진(120: QPE) 간의 큐 요청(QueueRequest)를 위한 예시적인 데이터 포맷은 다음과 같다.
XML Schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="QueueRequest">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="Property"/>
</xs:sequence>
<xs:attribute name="name" use="required" type="xs:string"/>
</xs:complexType>
</xs:element>
<xs:element name="Property">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element name="Policy" nillable="true" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="key" use="required" type="xs:string"/>
<xs:attribute name="type" type="xs:string"/>
</xs:complexType>
</xs:element>
<xs:complexType name="RequestList">
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="Property"/>
</xs:sequence>
<xs:attribute name="RequestID" use="required" type="xs:string"/>
<xs:attribute name="SourceURL" type="URLType"/>
</xs:complexType>
<xs:complexType name="PullCondition">
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="Property"/>
</xs:sequence>
<xs:attribute name="ChargingStatus" type="chargingStatusType" />
<xs:attribute name="BatteryPower" type="powerLevel" />
<xs:attribute name="NetworkConnection" type="connectionTypes" />
<xs:attribute name="AvailableMinimumStorage" type="storageUsage" />
</xs:complexType>
<xs:simpleType name="chargingStatusType">
<xs:restriction base="xs:string">
<xs:enemeration value="available"/>
<xs:enemeration value="charging"/>
<xs:enemeration value="unavailable"/>
<xs:enemeration value="error"/>
<xs:restriction>
<xs:simpleType>
<xs:simpleType name="powerLevel">
<xs:restriction base="xs:integer">
<xs:enemeration value="0"/>
<xs:enemeration value="100"/>
<xs:restriction>
<xs:simpleType>
<xs:simpleType name="connectionType">
<xs:restriction base="xs:string">
<xs:enemeration value="WLAN"/>
<xs:enemeration value="CELL3G"/>
<xs:enemeration value="CELL4G"/>
<xs:enemeration value="NFC"/>
<xs:restriction>
<xs:simpleType>
<xs:simpleType name="storageUsage">
<xs:restriction base="xs:integer">
<xs:enemeration value="0"/>
<xs:enemeration value="100"/>
<xs:restriction>
<xs:simpleType>
<xs:schema>
여기서, 큐 요청 "QueuerRequest"의 데이터 포맷에는 복수의 속성(attribute) 정보가 포함되고, 그에 따른 사용이 필요한지(필요하면, "required"로 표시), 및 속성 정보의 타입이 어떻게 되는지에 대한 정보가 포함될 수 있다.
큐 요청 "QueueRequest" 에는 콘텐트를 찾을 수 있는 적어도 하나의 소스 URI인 "SourceURI" 정보(스트링으로 표현될 수 있음), 가상 스토리지 디바이스 상의 캐싱된 객체를 저장하는데 사용되는 이름인 "Store_Name" 정보(스트링으로 표현될 수 있음), IETF RFC 2045, IETF RFC 2046, IETF RFC 4288, IETF RFC 2231에 설명된 바와 같이 캐싱된 객체의 MIME 콘텐트 타입 정보인 "Type" 정보(스트링으로 표현될 수 있음) 및 바이트 내에 캐싱된 객체의 크기 정보인 "TotalLength" 정보(롱(long) 타입의 데이터일 수 있음)가 포함될 수 있다. 본 발명의 실시예에 따르면, 상기 "Store_Name"에는 제 2 클라이언트 디바이스(CD2)의 가상 스토리지 디바이스의 이름이 제공될 수 있다. 상기 "Type" 값은 복수 개일 수 있으며, 콤마(comma)를 통해 나뉘어 기재될 수 있다. 상기 "TotalLength" 정보는 URI가 고정된 크기 객체를 요구하는 스킴을 설명하는 경우에 의무적이다(mendatory).
또한, 큐 요청은 원본(origin)을 콜링(calling)함으로써 세팅되는 정책 구조 정보인 "policy" 정보를 포함할 수 있다. 그리고, 큐 요청은 저장된 값과 연관된 키를 식별하기 위한 DOMString 정보인 "key" 정보를 포함할 수 있다.
큐 요청은 요청이 공급되는 때, 세팅되는 고유 ID로 제공되는 "RequestID" 정보를 포함할 수 있다.
또한, 큐 요청은 제 1 클라이언트 디바이스(CD1)의 다운로드 콘텐트에 대한 수신 조건 정보인 "PullCondition" 정보를 포함한다. 보다 구체적으로, 제 1 클라이언트 디바이스(CD1)가 제 2 클라이언트 디바이스(CD2)가 다운로드한 콘텐트를 수신하는데 있어서, 상기 수신 조건을 기반으로 제 1 클라이언트 디바이스(CD1)의 상태를 비교하여 콘텐트의 수신 여부를 판단할 수 있다.
상기 "PullCondition" 정보에는 전원 연결 상태와 관련된 정보인 "ChargingStatus" 정보, 배터리 상태 정보인 "BatteryPower" 정보, 네트워크 연결 상태를 나타내는 정보인 "NetworkConnection" 정보 및 저장 가용 공간의 상태 정보인 "AvailableMinimumStorage" 정보 중 적어도 어느 하나가 포함될 수 있다.
본 발명의 실시예에 따르면, "ChargingStatus" 정보는 "available", "charging", "unavailable", "error"로 표현될 수 있다. "ChargingStatus" 정보는 전원 연결과 관련하여 배터리의 충전 상태를 나타내는 커패빌리티 아이템으로서, 그 값은 스트링 형태의 정보일 수 있다. 상기 "ChargingStatus" 값이 "available"이면, 디바이스에 배터리가 설치되었으며(Installed) 설치된 배터리가 현재 동작하고 있는(working) 상태일 때 다운로드 콘텐트를 수신할 수 있음을 나타내고, "charging"이면, 디바이스에 배터리가 설치되었으며 현재 충전 중인 상태일 때 다운로드 콘텐트를 수신할 수 있음을 나타내며, "unavailable"이면, 디바이스에 배터리가 설치되지 않은 때도 다운로드 콘텐트를 수신할 수 있음을 나타내며, "error"이면, 디바이스에 배터리가 설치되었으나 기능을 바르게(Correctly) 수행하지 못하는 경우에도, 다운로드 콘텐트를 수신할 수 있음을 나타낼 수 있다.
또한, "BatteryPower" 정보도, 현재의 배터리 잔량의 레벨을 나타내도록 할 수 있다. 예컨대, "30"이면, 현재 전체 배터리량의 30%가 남아 있어야 다운로드 콘텐트를 수신한다는 것을 의미할 수 있다. "BatteryPower" 정보는 "0"에서 "100"까지 표현될 수 있다.
더욱이, "NetworkConnection" 정보는 큐 요청을 송수신하는 디바이스 간 사용하는 무선 네트워크의 연결 상태 조건을 나타낸다. 예컨대, "CELL3G" 또는 "CELL4G"이면 3G 또는 4G 무선 네트워크를, "WLAN"이면 WLAN 무선 네트워크가 연결된 상태를 의미하고, "NFC"면 NFC 통신이 연결된 상태에서만 콘텐트 수신이 이루어지도록 할 수 있다.
"AvailableMinimumStorage" 정보와 관련하여, 큐 요청은 최소 가용 저장 공간 정보로 전체 스토리지 중 특정 퍼센트 이상으로 설정해 놓은 정보를 포함할 수 있다. 예컨대, "AvailableMinimumStorage" 정보가 "40"이면, 전체 스토리지 중 40% 이상의 저장 공간이 확보되어 있어야 함을 의미할 수 있다. "AvailableMinimumStorage" 정보는 "0"에서 "100"까지 표현될 수 있다. 또한, "AvailableMinimumStorage" 정보는 직접 일정 저장 공간의 크기 정보를 포함할 수 있다. 예컨대, "2G" 이면, 2GB의 저장 공간이 필요함을 의미할 수 있다.
이러한, "PullCondition" 정보를 기반으로 제 1 클라이언트 디바이스(CD1) 또는 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)로의 다운로드 콘텐트의 애셋 수신 또는 전송 여부를 판단하여, 애셋을 수신 또는 전송할 수 있다.
다음은, 큐 요청(QuereRequest)을 지원하는 NFC 데이터 포맷에 추가되는 실시예를 나타낼 수 있다.
<?xml>
<QueueRequest>
<RequestList>
RequestID
SourceURI
<Pullcondition>
ChargingStatus
BatteryPower
NetworkConnection
AvailableMinimumStorage
</DownloadEvent>
상기한 XML 언어를 살펴보면, NFC를 통해 제 2 클라이언트 디바이스(CD2)에게 전해줄 메시지는 큐 요청을 식별할 ID인 RequestID, 다운로드할 콘텐트의 URI인 소스 URI(SourceURI)(또는 URL(SourceURL))을 포함할 수 있다.
또한, 제 2 클라이언트 디바이스(CD2)가 다운로드를 완료했을 때, 제 1 클라이언트 디바이스(CD2)가 콘텐트를 수신할(pull) 조건(condition)에 대한 내용은 전원 연결 상태(ChargingStatus), 배터리 상태(BatteryPower), 네트워크 상태(NetworkConnection) 및 저장 가용 공간 상태(AvailableMinimumStorage) 중 적어도 어느 하나를 포함할 수 있다.
다음은 NFC를 매개로 파일 다운로드 요청의 예를 나타낸다.
<?xml version="1.0" encoding="UTF-8"?>
<QueueRequest name="NFC_QueueRequest">
<RequestList
RequestID="o002"
SourceURI="http://www.example.com/asset-test.avi">
<Pullcondition>
ChargingStatus="charging"
BatteryPower="50"
NetworkConnection="NFC│WLAN"
AvailableMinimumStorage="30">
</QueueRequest>
본 실시예에서, 큐 요청의 이름은 "NFC_QueueRequest"이고, 큐 요청을 식별할 ID인 RequestID는 "o002"이며, 다운로드할 콘텐트의 URI 또는 URL인 소스 URI(SourceURI)(또는 소스 URL(SourceURL))는 "http://www.example.com/asset-test.avi"임을 알 수 있다.
본 발명의 실시예에 따르면, "ChargingStatus" 정보는 충전 중인 상태일 때 다운로드 콘텐트를 수신할 수 있음을 나타내는 "charging"을 나타내고 있다. 따라서, 제 1 클라이언트 디바이스(CD1)는 충전 중인 상태가 아닌 경우는 콘텐트 수신 조건을 만족하지 못하므로 다운로드 콘텐트를 수신하지 못한다.
또한, "BatteryPower" 정보는 현재 전체 배터리량의 30%가 남아 있어야 다운로드 콘텐트를 수신한는 "30"을 나타내고 있는데, 30% 미만의 배터리량을 가지고 있다면, 다운로드 콘텐트를 수신하지 못할 수 있다.
더욱이, "NetworkConnection" 정보는 WLAN 무선 네트워크가 연결된 상태 및 NFC 통신이 연결된 상태에만 콘텐트를 수신하는 "NFC│WLAN"인데, WLAN 또는 NFC가 연결되지 않는 네트워크 상태에서는 콘텐트 수신이 이루어지지 않을 수 있다.
"AvailableMinimumStorage" 정보가 "30"으로 설정되어 있는데, 전체 스토리지 중 30% 이상의 저장 공간이 확보되어 있어야 다운로드 콘텐트를 수신할 수 있다.
또한, 큐 요청은 NFC 관련 정보를 포함할 수 있다. 이는 전술한 바와 같이, NFC 태그 타입 정보 및 NFC 모드 정보를 포함할 수 있다. 여기서, NFC 태그 타입 정보 "NFCType"에 포함된 타입 1/2/3/4(Type 1/2/3/4)는 NFC 포럼의 디바이스 WG과 관련된 v1.0 또는 v2.0에 기재된 타입이며, 타입에 따라 RF 인터페이스, 속도 및 프로토콜이 서로 다르게 정의되어 있을 수 있다. 또한, NFC 모드 정보 "NFCMode" 도 NFC 포럼에서 정의된, 카드 에뮬레이션, 피어-투-피어, 리드-라이트 모드일 수 있다. 여기서 카드 에뮬레이션 모드는 단말기의 온/오프와 관계없이 항상 리더기를 통해 인식되는 모드를, 피어-투-피어 모드는 두 대의 NFC 휴대폰이 카드 리더기로서 작동하여 데이터를 상호 간에 전송하는 모드를, 리드-라이트 모드는 NFC 활성화 상태에서 RFID 태그 정보를 인식하여 휴대폰이 카드 리더기로서 작동하는 모드를 나타낼 수 있다. 또한, 경우에 따라, NFC 관련 정보는 NFC 태그 ID 정보 "NFCID"는 NFC 태그를 식별할 수 있는 ID 정보를 더 포함할 수 있다.
또한, 본 발명의 실시예에 따르면, 큐 요청은 애셋과 관련하여 다음의 특성 정보를 포함할 수 있다. 먼저, 가상 스토리지 내에 캐싱되는 객체를 저장하는데 사용되는 애셋의 이름인 “Asset_name”정보, 캐싱되는 객체의 크기를 바이트 단위로 나타낸 “Asset_size” 정보, 애셋이 D 인터페이스를 사용하여 리트리브(retrieved)되는 소스 URI인 “Asset_Source_URI”정보, 애셋을 소유(own)하고 있는 원본인 “Asset_Origin”정보, 애셋이 잠겨있는지(locked) 식별하는 “Asset_Locked”정보, 캐싱된 객체의 MINE 타입을 설명하는 “Asset_Type” 정보(이 정보는 위의 “Type” 정보로부터 유도될 수 있음), XML 명세서를 이용하여 구체화될 수 있는 선택적인 메타데이터 정보인 “Asset_Metadata” 정보, XML 스트링으로서 효과적인(effective) 정책인 “Asset_Policy” 정보, 클라이언트 디바이스에 의해 지원되는 콘텐트 프로파일인 “Asset_Contentprofile” 정보, 액티브 상태로 전이하기 전에 수행되저져야 하는 권한 체크 정보인 “Asset_Rightcheck” 정보, 콘텐트 애셋을 소비하거나 재생하기 전에 수행되어야 하는 VSD-세부(VSD-specific) 유효성 체크 정보인 “Asset_Validitychech” 정보, 애셋이 플레이리스트 파일에 귀속됨을 나타내는 “Asset_Playlist” 정보, 애셋이 MPD 파일의 형태의 플레이리스트임을 나타내는 “Asset_Ismpd”정보, 사용자에 의해 솔리시티드(solicited)되지 않는 애셋임을 나타내는 “Asset_Unsolicited” 정보, 애셋이 랜더링되기 위해 캐쉬로부터 액세싱된는 적어도 하나의 위치를 나타내는 “Asset_Geolocation” 정보 및 애셋이 CellID에 의해 액세싱되는 적어도 하나의 위치를 나타내는 “Asset_Location_Cell_ID” 정보 중 적어도 어느 하나를 포함할 수 있다.
도 16은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법의 클라이언트 애플리케이션을 통해 콘텐트 리스트, 다운로드 타임 및 콘텐트 다운로드 관련 설정을 입력할 수 있는 사용자 인터페이스의 예를 도시한 도면이다.
도 16-A 도면을 참조하면, 제 1 클라이언트 디바이스(CD1)는 콘텐트 리스트를 브라우징할 수 있다. 사용자는 사용자 인터페이스를 통해 큐에 추가되어질 콘텐트를 선택할 수 있다. 이때, 웹을 통해 현재 다운로드 횟수가 높은 순서대로 순위를 매겨 사용자에게 상위 복수 개의 콘텐트를 제공할 수 있다. 예컨대, 사용자는 최근 일주일 동안 가장 많은 다운로드 횟수를 기록한 상위 복수 개의 콘텐트를 리스트로 하여 제공받을 수 있다. 사용자는 제공받은 콘텐트 중 원하는 콘텐트를 큐에 추가할 수 있다. 경우에 따라서는, 클라우드 서비스를 기반으로, 사용자의 SNS 비디오 콘텐트 등을 통해 사용자의 선호 콘텐트 정보를 획득하여, 클라우드 서비스가 자동으로 추천 콘텐트를 선택하도록 설정할 수 있다.
도 16-B 도면을 참조하면, 사용자는 NFC가 가능한 제 2 클라이언트 디바이스(CD2)(본 실시예에서는 NAS) 위에 제 1 클라이언트 디바이스(CD1)(본 실시예에서는 스마트 폰 1)를 올려 놓을 수 있다. 또는 NFC가 가능한 일정 반경 내에 위치하도록 할 수 있다. 그렇게 하면, 스마트 폰 1은 타겟 디바이스(본 실시예에서는 NAS)와 큐 아이템 정보를 나타낼 수 있다. 사용자는 타겟 디바이스가 큐 요청을 실행하도록 선택 및 컨펌한다. 이러한 단계는 디폴트 설정 또는 사용자 설정(예컨대, 자동 큐 다운로드 설정)에 의해 생략될 수 있다. 즉, 자동으로 스마트 폰 1은 NAS 위에 놓으면 현재 큐에 있는 아이템을 NAS가 다운로드하도록 제어할 수 있다.
도 16-C 도면을 참조하면, 제 1 클라이언트 디바이스(CD1)(본 실시예에서는 스마트 폰 1)는 제 2 클라이언트 디바이스(CD2)(본 실시예에서는 NAS)로 큐 요청을 전송하고 슬립 모드에 진입한다. 그리고, NAS는 (구체적으로 주어진다면 주어진 시간에(예컨대, 다운로드/웨이크업 타임)) 다운로드를 시작한다.
도 16-D 도면을 참조하면, NAS가 다운로드할 콘텐트의 애셋에 대한 다운로드를 완료한 후, NAS는 NFC를 매개로 스마트 폰 1을 웨이크 업 한다. 만약, NFC를 통해 웨이크 업을 수행할 수 없는 경우, 구체적인 네트워크 인터페이스(예컨대, WLAN 또는 3G/4G)를 매개로 스마트 폰 1을 웨이크 업 한다. 스마트 폰 1은 실행된 큐 요청을 나타내고 애셋들은 NAS로부터 스마트 폰 1으로 전송되어질 준비를 한다. 사용자가 로컬 다운로드를 선택하면, 선택된 애셋은 NAS로부터 스마트 폰 1으로 전송된다.
도 17은 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 1 클라이언트 디바이스(CD1)의 동작을 개략적으로 나타낸 흐름도이다.
도 17을 참조하면, 제 1 클라이언트 디바이스(CD1)는 먼저, NFC를 사용하여 제 2 클라이언트 다바이스(CD2)에게 NFC를 사용하여 콘텐트를 다운로드하라는 콘텐트 다운로드 요청을 전송한다(S1710).
그리고, 제 2 클라이언트 디바이스(CD2)가 다운로드 요청을 잘 수신하였다는 응답이 올 때까지 대기(wait) 상태로 있는다(S1712).
제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)(타겟 디바이스)로부터 다운로드 요청을 잘 수신하였다는 컨펌 메시지를 수신할 수 있다(S1714).
그리고, 제 2 클라이언트 디바이스(CD2)가 다운로드를 시작했다는 메시지를 받으면(S1716), 대기(wait) 모드에서 일정 시간 있다가(S1718). 슬립(sleep) 모드로 진입한다(S1720). 이때, 타이머 이벤트에 의해 슬립 모드로 진입할 수 있다. 만약, 다운로드가 불가능하는 메시지를 받으면, 콘텐트 다운로드는 종료될 수 있다.
슬립 모드에 있는 제 1 클라이언트 디바이스(CD1)는 제 2 클라이언트 디바이스(CD2)로부터 다운로드가 완료되어 웨이크 업 요청을 수신할 수 있다(S1722). 제 1 클라이언트 디바이스(CD1)는 웨이크 업 요청을 수신하면, 웨이크 업을 수행하여 슬립 모드에서 액티브 모드로 전환한다(S1724). 그리고는, 제 2 클라이언트 디바이스(CD2)로 웨이크 업에 대한 응답 메시지를 전송한다(S1726).
그리고는, 다운로드 콘텐트의 애셋 수신 조건을 만족하는지 판단하여(S1728), 조건에 부합할 경우, 제 2 클라이언트 디바이스(CD2)로부터 다운로드 콘텐트를 수신할 수 있다(S1730). 이때, 애셋의 수신 조건과 관련하여, 사용자는 사용자 인터페이스를 통해 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태 중 적어도 어느 하나의 설정을 제어할 수 있고, 제 1 클라이언트 디바이스(CD1)는 상기 수신 조건과 현재 자신의 상태를 고려하여 애셋 수신 여부를 판단할 수 있다.
도 18는 본 발명의 또 다른 실시예에 따른 NFC를 이용한 콘텐트 다운로드 방법에 있어서, 제 2 클라이언트 디바이스(CD2)의 동작을 개략적으로 나타낸 흐름도이다.
도 18을 참조하면, 제 2 클라이언트 디바이스(CD2)는 NFC를 사용하여 제 1 클라이언트 디바이스(CD1)로부터 콘텐트 다운로드 요청을 수신할 수 있다(S1810). 그리고는 다운로드 요청을 수신하였다는 응답을 제 1 클라이언트 디바이스(CD1)로 전송한다(S1812).
그리고 제 2 클라이언트 디바이스(CD2)는 다운로드가 가능한지 판단한다(S1814). 만약, 콘텐트 다운로드 요청에 제 2 클라이언트 디바이스(CD2)의 다운로드 조건(예컨대, 제 2 클라이언트 디바이스(CD2)의 전원 연결 상태, 배터리 상태, 네트워크 상태 및 저장 가용 공간의 상태 중 적어도 어느 하나를 포함할 수 있음)이 포함되어 있다면, 이를 기준으로 제 2 클라이언트 디바이스(CD2)는 다운로드 가능 여부를 판단할 수 있다. 또는 제 2 클라이언트 디바이스(CD2)는 특별한 다운로드 조건이 없어도, 배터리가 없거나, 전원이 꺼져 있거나, 저장 공간이 없거나 다운로드/웨이크 업 타임에 다른 작업을 해야하는 경우 등 다운로드를 받을 수 없는 상황인지 자체적으로 판단할 수 있다.
다운로드가 불가하다고 판단되면, 다운로드가 불가하다는 응답을 제 1 클라이언트 디바이스(CD1)로 전송하고(S1816) 다운로드 과정을 종료한다. 만약, 다운로드가 가능하면, 제 1 클라이언트 디바이스(CD1)로 다운로드를 시작하겠다는 컨펌 메시지를 전송한다(S1918).
그리고는 콘텐트를 다운로드한다(1820). 다운로드가 완료되면(S1822) 제 1 클라이언트 디바이스(CD1)로 NFC를 이용하여 웨이크 업 요청을 전송한다(S1824). 이때, NFC 웨이크 업 요청에 대한 응답이 있는지 판단하여(S1826), 일정 기간 동안 응답이 수신되지 않으면, NFC 통신이 불가하다고 판단하여 WLAN(또는 3G/4G) 무선 네트워크를 이용하여 웨이크 업 요청을 전송한다(S1834). 그리고는 WLAN 웨이크 업 요청에 대한 응답이 있는지 판단한다(S1836). 응답이 있으면, 다운로드가 완료되었다는 응답을 제 1 클라이언트 디바이스(CD1)로 전송할 수 있다(S1828). NFC 웨이크 업 요청에 대한 응답 여부 판단 단계(S1826)에서, 만약 NFC 웨이크 업 요청에 대한 응답이 있는 경우, 바로 다운로드 완료 메시지를 제 1 클라이언트 다바이스(CD1)로 전송할 수 있다(S1828).
다운로드 완료 메시지를 전송하고 나면, 다운로드 콘텐트의 애셋을 전송할 수 있는 조건을 만족하는지 판단한다(S1830). 즉, 제 2 클라이언트 디바이스(CD2)는 콘텐트 다운로드 요청에 포함된 다운로드 콘텐트 수신 조건을 고려하여 제 1 클라이언트 디바이스(CD1)가 다운로드된 콘텐트를 수신할 수 있을지 여부를 판단한다. 또는 제 2 클라이언트 디바이스(CD2)가 직접 자신의 상태를 확인하여, 콘텐트를 전송할 수 있는 조건을 만족하는지 판단한다. 예컨대, 현재 다운로드된 콘텐트의 크기 또는 용량을 고려하여, 현재 제 2 클라이언트 디바이스(CD2)의 배터리 상태, 전원 연결 상태, 네트워크 상태와 비교하여 애셋의 전송 여부를 결정할 수 있다.
만약, 제 1 클라이언트 디바이스(CD1)의 수신 조건 또는 제 2 클라이언트 디바이스(CD2)의 전송 조건을 만족하는 경우, 제 2 클라이언트 디바이스(CD2)는 제 1 클라이언트 디바이스(CD1)로 콘텐트를 전송해 주고(S1832), 그렇지 않으면, 콘텐트의 전송 없이 종료한다.
도 19는 본 발명의 바람직한 실시예에 따른 디바이스 디스커버리 방법을 설명하기 위한 흐름도로서, 콘텐트 서비스 시스템에서 클라이언트 디바이스(CD)가 네트워크에 연결된 매개 디바이스(IMD)들을 디스커버리하는 과정을 예시적으로 나타내고 있다. 여기서, 클라이언트 디바이스(CD)는 제 1 클라이언트 디바이스(CD1)를, 매개 디바이스(IMD)는 제 2 클라이언트 디바이스(CD2)일 수 있다.
도 19에 도시된 바와 같이, 클라이언트 디바이스(CD)는 매개 디바이스 매니저(124)는 리슨틀리 커넥티드 디바이스 리스트(Recently Connected Device List)를 관리(Manage)한다(단계:S1). 상기 리슨틀리 커넥티드 디바이스 리스트는 클라이언트 디바이스(CD)와 로컬 네트워크를 통하여 최근 연결되었던 디바이스들(예컨대, 매개 디바이스, 다른 클라이언트 디바이스 등)의 리스트를 의미할 수 있다.
상기 리슨틀리 커넥티드 디바이스 리스트는 클라이언트 디바이스(CD)의 스토리지, 예컨대 가상 스토리지 디바이스(150)에 저장되어 있을 수 있다. 예를 들면, 클라이언트 디바이스(CD)는 최초 네트워크에 접속 시 디바이스 디스커버리를 통하여 취득된 정보를 사용하여 리슨틀리 커넥티드 리스트를 생성한 후 스토리지에 저장하고, 이후 디바이스 디스커버리를 수행할 때마다 취득되는 디바이스들의 정보를 기반으로 하여 지속적으로 리슨틀리 커넥티드 리스트를 업데이트할 수 있다.
도 20는 상기 리슨틀리 커넥티드 디바이스 리스트의 구조를 설명하기 위한 도표를 나타내고 있다.
도 20에 도시된 바와 같이, 리슨틀리 커넥티드 디바이스 리스트는 각 디바이스의 디바이스 프렌들리 네임(Device Friendly Name), IP 어드레스(IP Address), 포트 넘버(Port Number), 라스트 커넥티드 타임(Last Connected Time), 라스터 커넥티드 네트워크 액세스 타입(Last Connected Network Access Type) 등의 아이템들을 포함할 수 있다.
상기 디바이스 프렌들리 네임, IP 어드레스 및 포트 넘버는 디바이스의 프렌들리 네임, IP 어드레스 및 포트를 각각 나타내는 스트링 타입의 정보일 수 있다. 상기 라스트 커넥티드 타임은 예컨대 디바이스와 마지막으로 신호를 전송하거나 수신했던 시간을 나타낼 수 있다. 상기 라스트 커넥티드 네트워크 액세스 타입은 디바이스의 어떠한 방식으로 네트워크에 접속하였는지를 나타내는 커넥션 타입을 의미할 수 있다. 예를 들어, 상기 라스트 커넥티드 네트워크 액세스 타입은 이더넷, 802.11, MoCA, 블루투스, ZigBee 등 중 적어도 어느 하나를 나타내는 스트링 타입의 정보일 수 있다.
한편, 상기 리슨틀리 커넥티드 디바이스 리스트는 디바이스 디스크립션(Device Description)을 포함할 수도 있다. 상기 디바이스 디스크립션은 디바이스 커패빌리티 등과 같은 디바이스의 정보에 접근할 수 있는 접속 정보, 예컨대 URI, URL 등일 수 있다. 클라이언트 디바이스(CD)는 디바이스 디스커버리 시에 상기 디바이스 디스크립션의 URI 또는 URL 등을 사용하여 디바이스의 커패빌리티 정보를 취득할 수도 있다.
상기 클라이언트 디바이스(CD)에 의하여 수행되는 디바이스 디스커버리는 상기 클라이언트 디바이스(CD)가 로컬 네트워크에 접속하면 자동으로 시작되거나 또는 사용자로부터 로컬 어플리케이션(110)으로의 디바이스 디스커버리 요청에 따라 시작될 수 있다.
먼저, 클라이언트 디바이스(CD)는 리슨틀리 커넥티드 디바이스 리스트를 기반으로 네트워크 내에서 최근에 연결되었던 이력이 있는 디바이스들로 유니캐스트 디바이스 디스커버리 요청 메시지를 유니캐스트할 수 있다. 예를 들어, 본 실시예의 설명에서 상기 리슨틀리 커넥티드 디바이스 리스트에 제 1 매개 디바이스(IMD1)의 정보가 포함되어 있다고 가정한다. 상기 클라이언트 디바이스(CD)는 상기 리슨틀리 커넥티드 디바이스 리스트를 근거로 하여 제 1 매개 디바이스(IMD1)로 유니캐스트 디바이스 디스커버리 요청 메시지를 유니캐스트할 수 있다(단계:S2).
상기 유니캐스트 디바이스 디스커버리 요청 메시지를 수신한 각각의 디바이스는 상기 유니캐스트 디바이스 디스커버리 요청 메시지에 대한 응답으로 유니캐스트 디바이스 디스커버리 응답 메시지를 클라이언트 디바이스(CD)로 전송할 수 있다. 예를 들어, 상기 유니캐스트 디바이스 디스커버리 요청 메시지를 수신한 제 1 매개 디바이스(IMD1)는 그 응답으로 클라이언트 디바이스(CD)로 유니캐스트 디바이스 디스커버리 응답 메시지를 전송할 수 있다(단계:S3).
유니캐스트 디바이스 디스커버리 응답 메시지를 수신한 클라이언트 디바이스(CD)는, 수신된 유니캐스트 디바이스 디스커버리 응답 메시지를 기반으로 하여 리슨틀리 커넥티드 디바이스 리스트를 업데이트할 수 있다(단계:S4). 예를 들어, 클라이언트 디바이스(CD)의 매개 디바이스 매니저(124)는 유니캐스트 디바이스 디스커버리 응답 메시지에 포함된 정보에 따라 리슨틀리 커넥티드 디바이스 리스트 상에서 제 1 매개 디바이스(IMD1)의 라스트 커넥티드 타임, 라스트 커넥티드 네트워크 액세스 타입 등을 새로운 정보로 업데이트할 수 있다.
도 21은 유니캐스트 디바이스 디스커버리 요청 또는 응답에 사용되는 유니캐스트 디바이스 디스커버리 메시지의 구조를 나타내는 예시도이다.
도 21에 도시된 바와 같이, 유니캐스트 디바이스 디스커버리 메시지는 메시지 코드 필드를 포함한다. 상기 메시지 코드는 상기 메시지가 요청 메시지인지 응답 메시지인지 등을 구분하는 정보일 수 있다.
또한, 상기 유니캐스트 디바이스 디스커버리 메시지는 적어도 하나의 유니캐스트 디바이스 디스커버리 엔트리 필드를 포함한다. 상기 유니캐스트 디바이스 디스커버리 엔트리 필드는 디바이스 프렌들리 네임이 삽입되는 디바이스 프렌들리 네임 필드, IP 주소가 삽입되는 IP 주소 필드, 포트 넘버가 삽입되는 포트 넘버 필드, 라스트 커넥티드 타임이 삽입되는 라스트 커넥티드 타입 필드, 네트워크 액세스 타입이 삽입되는 네트워크 액세스 타입 필드 등을 포함할 수 있다.
또한, 상기 유니캐스트 디바이스 디스커버리 메시지는 디바이스 정보 아이템 필드를 포함할 수도 있다. 상기 디바이스 정보 아이템 필드는 클라이언트 디바이스(CD)가 디스커버리되는 디바이스, 예컨대 제 1 매개 디바이스(IMD1)의 다양한 정보를 취득하는 것에 활용될 수 있다. 예를 들어, 클라이언트 디바이스(CD)는 유니캐스트 디바이스 디스커버리 요청 메시지의 디바이스 정보 아이템 필드에 취득하고자 하는 정보, 예컨대 디바이스 커패빌리티 아이템의 정보 등을 삽입하여 제 1 매개 디바이스(IMD1)로 전송할 수 있다.
제 1 매개 디바이스(IMD1)는, 이에 응답하여, 요청된 제 1 매개 디바이스(IMD1)의 정보를 디바이스 디스커버리 응답 메시지의 디바이스 정보 아이템 필드에 삽입하여 클라이언트 디바이스(CD)로 전송할 수 있다. 그러면, 클라이언트 디바이스(CD)는 수신된 제 1 매개 디바이스(IMD1)의 정보를 근거로 하여 제 1 매개 디바이스(IMD1)의 정보를 업데이트할 수 있다.
한편 유니캐스트 디바이스 디스커버리 응답 메시지에 따라 리슨틀리 커넥티드 디바이스 리스트를 업데이트한 클라이언트 디바이스(CD)는, 액티브 디바이스 리스트를 업데이트할 수 있다(단계:S5). 상기 액티브 디바이스 리스트는 현재 액티브 상태인 네트워크 디바이스들을 나타내는 정보일 수 있다. 예를 들어, 상기 유니캐스트 디바이스 디스커버리 응답 메시지를 전송한 제 1 매개 디바이스(IMD1)는 현재 액티브 상태이므로, 상기 클라이언트 디바이스(CD)는 상기 제 1 매개 디바이스(IMD1)의 상태가 액티브임을 상기 액티브 디바이스 리스트에 업데이트할 수 있다.
클라이언트 디바이스(CD)의 로컬 어플리케이션(110)은 업데이트된 액티브 디바이스 리스트 또는 업데이트된 리슨틀리 커넥티드 디바이스 리스트를 클라이언트 디바이스(CD)의 화면에 표시할 수도 있다. 따라서 사용자는 클라이언트 디바이스(CD)의 화면에 표시되는 액티브 디바이스 리스트 또는 리슨틀리 커넥티드 디바이스 리스트를 통하여 현재 사용 가능한 네트워크 상의 디바이스를 신속히 확인할 수 있다.
한편, 상기 클라이언트 디바이스(CD)는 네트워크에 접속된 디바이스로 멀티캐스트 디바이스 디스커버리 요청 메시지를 멀티캐스트(또는 브로드캐스트)할 수 있다. 예를 들어, 클라이언트 디바이스(CD)는 제 1 매개 디바이스(IMD1) 및 제 2 매개 디바이스(IMD2)로 멀티캐스트 디바이스 디스커버리 요청 메시지를 전송할 수 있다(단계:S6, S7).
상기 리슨틀리 커넥티드 디바이스에 제 2 매개 디바이스(IMD2)는 없다고 가정하면, 제 2 매개 디바이스(IMD2)는 아직 클라이언트 디바이스(CD)에 의하여 디스커버리되지 않은 상태이다. 따라서, 제 2 매개 디바이스(IMD2)는 상기 클라이언트 디바이스(CD)로부터 수신된 멀티캐스트 디바이스 디스커버리 메시지에 응답하여 멀티캐스트 디바이스 디스커버리 응답 메시지를 클라이언트 디바이스(CD)로 전송할 수 있다(단계:S9). 제 1 매개 디바이스(IMD1)의 경우, 멀티캐스트 디바이스 디스커버리 응답 메시지를 클라이언트 디바이스(CD)로 전송할 수도 있지만, 이미 클라이언트 디바이스(CD)로 유니캐스트 메시지를 보냈다면 전송하지 않을 수도 있다(단계:S8).
클라이언트 디바이스(CD)는 수신되는 멀티캐스트 디바이스 디스커버리 응답 메시지를 기반으로 하여 리슨틀리 커넥티드 디바이스 리스트를 업데이트할 수 있다(단계:S10). 예를 들어, 클라이언트 디바이스(CD)의 매개 디바이스 매니저(124)는 리슨틀리 커넥티드 디바이스 리스트에 제 2 매개 디바이스(IMD2)의 정보를 새롭게 추가할 수 있다.
또한, 클라이언트 디바이스(CD)는 수신되는 멀티캐스트 디바이스 디스커버리 응답 메시지를 기반으로 액티브 디바이스 리스트를 업데이트할 수도 있다. 로컬 어플리케이션(110)은 새롭게 업데이트된 액티브 디바이스 리스트 또는 업데이트된 리슨틀리 커넥티드 디바이스 리스트를 클라이언트 디바이스(CD)의 화면에 표시할 수도 있다.
이와 같이, 본 발명의 바람직한 실시예에 따른 디바이스 디스커버리에 따르면, 클라이언트 디바이스(CD)는 최근 연결되었던 디바이스들을 리슨틀리 커넥티드 디바이스 리스트를 통하여 관리한다. 디바이스 디스커버리 시, 클라이언트 디바이스(CD)는 리슨틀리 커넥티드 디바이스 리스트를 체크하여 리슨틀리 커넥티드 디바이스 리스트에 있는 디바이스들을 유니캐스트를 기반으로 신속하게 디스커버리할 수 있다. 따라서 사용자는 멀티캐스트를 기반으로 하는 디바이스 디스커버리의 수행 완료되기 전에도, 사용 가능한 네트워크 디바이스들을 먼저 신속하게 확인할 수 있다.
상기 디바이스 디스커버리는 상기 예시된 콘텐트 서비스 시스템뿐만 아니라 UPnP(Universal Plug and Play), DLNA(Digital Living Network Alliance) 등을 기반으로 하는 다양한 네트워크 시스템에서 적용될 수 있음은 물론이다.
예를 들어, DLNA 디바이스, 예컨대 DMC(Digital Media Controller)는 동일한 네트워크 도메인, 예컨대 홈 네트워크 또는 오피스 도메인 등에서 디바이스 디스커버리를 수행할 때마다 거의 동일한 디바이스를 디스커버리하는 것이 보통이다. 왜냐하면, 홈 네트워크 또는 오피스 도메인에 속하는 디바이스들, 예컨대 DMS(Digital Media Server), DMR(Digital Media Renderer) 등은 거의 고정되어 있기 때문이다. 따라서, 이러한 시스템에서 상기 본 발명에 따른 디바이스 디스커버리는 매우 효율적일 수 있다.
DMC는 네트워크 도메인에 연결되는 디바이스 프로파일 및 디스크립션 파일을 포함하는 디바이스 정보를 저장할 수 있다. 상기 디바이스 정보는 예컨대 리슨틀리 커넥티드 디바이스 리스트일 수 있다. 비록 DMC가 상기 네트워크 도메인을 떠난다(Leave)하더라도, DMC는 상기 디바이스 정보를 관리(Manage)할 수 있다.
효율적이고 빠른 디스커버리를 위하여, DMC가 상기 네트워크에 들어갈 때(enter), DMC는 상기 디바이스 정보를 기반으로 하여 디바이스 프로파일을 포함하는 유니캐스트 메시지를 디바이스 정보에 등록되어 있는 IP 주소를 사용하여 디바이스들로 각각 전송할 수 있다. 즉, 최근에 연결되었던 디바이스들의 IP 주소로 유니캐스트 메시지를 전송하는 것을 기반으로 디바이스 디스커버리를 수행하는 것이다. 따라서, DMC는 최근 연결되었던 디바이스들을 사용자 인터페이스를 통하여 먼저 표시할 수 있다.
도 22은 디바이스 디스커버리 및 디바이스 커패빌리티 교환(exchange)을 기반으로 하는 콘텐트 다운로드 절차를 나타내고 있다.
도 22에 도시된 바와 같이, 클라이언트 디바이스(CD)는 콘텐트 서버(CS)로부터 콘텐트(예컨대, 이하에서는 미디어) 리스트를 제공받고, 다운로드를 원하는 미디어를 선택할 수 있다(단계:S11). 사용자는 클라이언트 디바이스(CD)의 제어를 기반으로 네트워크에 연결된 매개 디바이스를 사용하여 상기 선택된 미디어를 다운로드 하고자 한다.
클라이언트 디바이스(CD)는 제 1 매개 디바이스(IMD1)와 디바이스 디스커버리 절차를 수행할 수 있다(단계:S12). 상기 디바이스 디스커버리 절차는 도 4를 참조하여 설명한 절차에 의하여 수행될 수 있다. 예를 들어, 앞서 설명한 디바이스 디스커버리 절차와 같이, 클라이언트 디바이스(CD)의 매개 디바이스 매니저(124)는 리슨틀리 커넥티드 디바이스 리스트를 기반으로 하여 제 1 매개 디바이스(IMD1)로 유니캐스트 디바이스 디스커버리 요청 메시지를 전송하고, 그 응답으로 유니캐스트 디바이스 디스커버리 응답 메시지를 제 1 매개 디바이스(IMD1)로부터 수신할 수 있다.
디바이스 디스커버리가 완료되면, 클라이언트 디바이스(CD)의 매개 디바이스 매니저는 제 1 매개 디바이스(IMD1)로 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티를 요청하는 디바이스 커패빌리티 요청 메시지를 전송할 수 있다(단계:S13). 디바이스 커패빌리티 요청 메시지를 수신한 제 1 매개 디바이스(IMD1)는 요청된 디바이스 커패빌리티를 포함하는 디바이스 커패빌리티 응답 메시지를 클라이언트 디바이스(CD)로 전송할 수 있다(단계:S14). 상기 디바이스 커패빌리티는 XML(Extensible Markup Language) 형태의 정보일 수 있으며, 다수 개의 커패빌리티 아이템을 포함할 수 있다.
한편, 상기 클라이언트 디바이스(CD)는, 도 21에 도시된 유니캐스트 디바이스 디스커버리 메시지의 구조를 사용하여, 디바이스 커패빌리티 요청/응답 없이 디바이스 디스커버리 수행 시에 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티를 획득할 수도 있다. 예를 들어, 클라이언트 디바이스(CD)는 유니캐스트 디바이스 디스커버리 요청 메시지의 디바이스 정보 아이템 필드에 취득하고자 하는 디바이스 커패빌리티 아이템의 정보를 삽입하여 제 1 매개 디바이스(IMD1)로 전송할 수 있다. 이 경우, 제 1 매개 디바이스(IMD1)는 유니캐스트 디바이스 디스커버리 응답 메시지의 디바이스 정보 아이템 필드에 요청된 디바이스 커패빌리티 아이템들을 삽입하여 클라이언트 디바이스(CD)로 전송할 수 있다. 따라서 디바이스 디스커버리 절차를 통하여 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티가 클라이언트 디바이스(CD)로 전달될 수 있다. 이 경우 별도의 디바이스 커패빌리티 요청 및 응답 절차는 생략될 수도 있다.
제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티를 취득한 클라이언트 디바이스(CD)는, 상기 디바이스 커패빌리티를 기반으로 하여, 상기 선택된 미디어를 특정 개체로부터 다운로드 할 것을 요청하는 큐 요청을 제 1 매개 디바이스(IMD1)로 전송한다(단계:S15). 예를 들면, 제 1 매개 디바이스(IMD1)의 큐 매니저는 Q3 인터페이스를 통하여(via) 제 1 매개 디바이스(IMD1)로 큐 요청을 보낼 수 있다.
상기 큐 요청은 상기 제 1 매개 디바이스(IMD1)가 상기 제 1 매개 디바이스(IMD1)의 커패빌리티에 적합한 애셋, 예컨대 미디어 파일을 다운로드 할 수 있는 접속 정보를 포함할 수 있다. 상기 큐 요청은 상기 선택된 미디어를 식별하기 위한 식별자, 상기 미디어에 대응하여 실질적으로 다운로드 할 애셋, 예컨대 미디어 파일을 식별 및 접근할 수 있는 접속 정보 등을 포함할 수 있다. 예를 들어, 상기 미디어의 식별자가 영화 'Avatar'를 식별하는 정보라고 가정하면, 상기 접속 정보는 실제 다운로드 할 물리적인 'Avatar 파일'을 식별하고 접근하기 위한 정보라 할 수 있다. 예컨대 상기 접속 정보는 URL, URI, 파일명 형태의 정보를 포함할 수 있다.
즉, 클라이언트 디바이스(CD)는 상기 제 1 매개 디바이스(IMD1)의 커패빌리티에 적합한 미디어 파일을 다운로드 할 수 있는 정보를 큐 요청을 통하여 제 1 매개 디바이스(IMD1)로 전달하는 것이다.
예를 들어, 클라이언트 디바이스(CD)는 제 1 매개 디바이스(IMD1)로부터 수신되는 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티를 사용하여 제 1 매개 디바이스(IMD1)의 스토리지 커패시티 및 스토리지 유시지, 미디어 프로파일 등을 확인하고, 제 1 매개 디바이스(IMD1)에서 다운로드 가능한 사이즈, 지원 가능한 미디어 프로파일에 해당하는 미디어를 다운로드할 것을 상기 큐 요청을 통하여 제 1 매개 디바이스(IMD1)에 전달할 수 있다.
이러한 큐 요청을 수신한 제 1 매개 디바이스(IMD1)는 큐 요청에 포함된 정보를 기반으로 하여 콘텐트 서버에 접속하고, 선택된 미디어에 대응하며 상기 제 1 매개 디바이스(IMD1)에 적합한 미디어 파일을 상기 콘텐트 서버로부터 다운로드 할 수 있다(단계:S16).
한편, 상기 클라이언트 디바이스(CD)는 클라이언트 디바이스(CD)가 관리하는 정책을 근거로 하여, 상기 제 1 매개 디바이스(IMD1)의 특정 디바이스 커패빌리티가 상기 정책을 만족하는지의 여부에 따라 큐 요청을 전송할 것인지의 여부를 결정할 수도 있다. 예를 들어, 상기 클라이언트 디바이스(CD)의 정책 클라이언트(140)은 콘텐트 정책 서버(300)으로부터 수신된 정책을 저장 및 관리할 수 있다. 상기 정책 클라이언트(140)는 제 1 매개 디바이스(IMD1)로부터 수신되는 특정한 디바이스 커패빌리티가 특정 정책을 만족하는지의 여부를 판단하고, 만족할 경우 제 1 매개 디바이스(IMD1)로 큐 요청을 전송하도록 큐 매니저(122)를 제어하고, 만족하지 않을 경우 큐 요청을 차단하고 로컬 어플리케이션(110) 등을 통하여 에러 메시지를 출력할 수 있다.
예컨대, 클라이언트 디바이스(CD)는 제 1 매개 디바이스(IMD1)로부터 전달된 디바이스 커패빌리티를 사용하여 제 1 매개 디바이스(IMD1)의 스토리지 커패시티 및 스토리지 유시지를 확인하고, 정책에서 허용하는 다운로드 될 미디어 파일의 사이즈가 제 1 매개 디바이스(IMD1)의 잔여 스토리지 사이즈보다 작은지를 확인할 수 있다. 만약 상기 다운로드될 미디어 파일의 사이즈가 제 1 매개 디바이스(IMD1)의 잔여 스토리지 사이즈보다 클 경우, 클라이언트 디바이스(CD)는 에러 메시지를 출력하고 큐 요청을 전송하지 않을 수 있다.
예컨대, 정책에서 허용하는 네트워크 액세스 타입이 Wi-Fi(802.11)뿐이라 가정하면, 클라이언트 디바이스(CD)는 제 1 매개 디바이스(IMD1)로부터 전달된 디바이스 커패빌리티를 사용하여 제 1 매개 디바이스(IMD1)의 네트워크 액세스 타입을 확인하고, 제 1 매개 디바이스(IMD1)의 네트워크 액세스 타입에 상기 Wi-Fi(802.11)가 없다면 에러 메시지를 출력하고 큐 요청을 차단할 수 있다.
예컨대, 클라이언트 디바이스(CD)는, 정책이 제 1 매개 디바이스(IMD1)의 파워 레벨이 50% 이상일 경우에만 다운로드를 허용한다면, 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티의 파워 레벨이 50% 미만이면 큐 요청을 전송하지 않을 수 있다.예컨대, 클라이언트 디바이스(CD)는, 정책이 제 1 매개 디바이스(IMD1)의 서포팅 미디어 프로파일이 ‘HD’일 경우에만 다운로드를 허용한다면, 제 1 매개 디바이스(IMD1)의 서포팅 미디어 프로파일이 ‘PD’ 또는 ‘SD’면 큐 요청을 전송하지 않을 수도 있다.
한편, 예컨대, 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티의 큐 요청의 맥시멈 넘버가 3이라고 가정하고, 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티의 큐 요청의 현재 넘버가 2 이하이면, 클라이언트 디바이스(CD)는 제 1 매개 디바이스(IMD1)으로 큐 요청을 전송하고, 큐 요청의 현재 넘버가 큐 요청의 맥시멈 넘버와 같은 3이라면, 큐 요청을 보내지 않을 수도 있다.
도 23은 콘텐트 서버와 매개 디바이스 간의 디바이스 커패빌리티 교환(exchange)을 기반으로 하는 콘텐트 다운로드 절차를 나타내고 있다.
도 23에 도시된 바와 같이, 클라이언트 디바이스(CD)는 콘텐트 서버로부터 콘텐트(예컨대, 이하에서는 미디어) 리스트를 제공받고, 다운로드를 원하는 미디어를 선택할 수 있다(단계:S21). 클라이언트 디바이스(CD)는 네트워크에 연결된 매개 디바이스를 사용하여 상기 선택된 미디어를 다운로드 하고자 한다.
클라이언트 디바이스(CD)는 제 1 매개 디바이스(IMD1)와 디바이스 디스커버리 절차를 수행할 수 있다(단계:S22). 상기 디바이스 디스커버리 절차는 도 4를 참조하여 설명한 절차에 의하여 수행될 수 있다. 예를 들어, 앞서 설명한 디바이스 디스커버리 절차와 같이, 클라이언트 디바이스(CD)의 매개 디바이스 매니저는 리슨틀리 커넥티드 디바이스 리스트를 기반으로 하여 제 1 매개 디바이스(IMD1)로 유니캐스트 디바이스 디스커버리 요청 메시지를 전송하고, 그 응답으로 유니캐스트 디바이스 디스커버리 응답 메시지를 제 1 매개 디바이스(IMD1)로부터 수신할 수 있다.
디바이스 디스커버리가 완료되면, 클라이언트 디바이스(CD)는 상기 선택된 미디어를 특정 개체로부터 다운로드 할 것을 요청하는 큐 요청을 제 1 매개 디바이스(IMD1)로 전송한다(단계:S23). 예를 들면, 제 1 매개 디바이스(IMD1)의 큐 매니저는 Q3 인터페이스를 통하여(via) 제 1 매개 디바이스(IMD1)로 큐 요청을 보낼 수 있다. 상기 큐 요청은 상기 제 1 매개 디바이스(IMD1)가 상기 미디어의 식별자, 상기 미디어에 대응하는 애셋을 다운로드 하기 위하여 필요한 접속 정보 등을 포함할 수 있다.
이러한 큐 요청을 수신한 제 1 매개 디바이스(IMD1)는 큐 요청에 포함된 정보를 기반으로 하여 콘텐트 서버에 접속하고, 콘텐트 서버로 제 1 매개 디바이스(IMD1)의 디바이스 커패빌리티를 전송한다(단계:S24). 콘텐트 서버는 상기 디바이스 커패빌리티를 근거로 하여 제 1 매개 디바이스(IMD1)에 적합한 미디어 파일을 제 1 매개 디바이스(IMD1)로 다운로드 할 수 있다(단계:S25).
한편, 상기 콘텐트 서버는(CS)는 콘텐트 정책 서버(PS)가 관리하는 정책을 근거로 하여, 상기 제 1 매개 디바이스(IMD1)의 특정 디바이스 커패빌리티가 상기 정책을 만족하는지의 여부에 따라 다운로드를 위한 큐 요청을 전송할 것인지의 여부를 결정할 수도 있다. 예컨대, 콘텐트 서버(CS)는 제 1 매개 디바이스(IMD1)로부터 전달된 디바이스 커패빌리티를 사용하여 제 1 매개 디바이스(IMD1)의 스토리지 커패시티 및 스토리지 유시지를 확인하고, 정책에서 허용하는 다운로드 될 미디어 파일의 사이즈가 제 1 디바이스(IMD1)의 잔여 스토리지 사이즈보다 작은지를 확인할 수 있다. 만약 상기 다운로드될 미디어 파일의 사이즈가 제 1 매개 디바이스(IMD1)의 잔여 스토리지 사이즈보다 클 경우, 콘텐트 서버(PS)는 큐 요청을 전송하지 않을 수 있다. 이 경우 콘텐트 서버(CS)는 클라이언트 디바이스(CD) 또는 제 1 매개 디바이스(IMD1)으로 에러 메시지를 전송할 수 있다. 마찬가지로, 콘텐트 서버(CS)는 정책의 네트워크 액세스 타입, 파우 레벨, 서포팅 미디어 프로파일 등 다양한 아이템들을 근거로 하여 제 1 매개 디바이스(IMD1)으로부터 전달되는 디바이스 커패빌리티를 확인하여 큐 요청 여부를 결정할 수 있다.
도 24는 디바이스 커패빌리티의 구조를 설명하기 위한 도표를 도시하고 있다. 상술한 내용, 예컨대 도 22 내지 도 23을 참조한 설명 등에서 언급되는 디바이스 커패빌리티는 도 24에 도시된 디바이스 커패빌리티 구조를 가질 수 있다.
도 24에 도시된 바와 같이, 디바이스 커패빌리티는 디바이스 식별자(Device ID), 디바이스 네임(Device Name), 디바이스 프렌들리 네임(Device Friendly Name), 사용자 식별자(User ID), 커런트 파워 소스(Current Power Source), 차징 스테이터스(Charging Status), 파워 레벨(Power Level), 서포팅 미디어 프로파일(Supporting Media Profiles), 서포팅 코덱 타입(Supporting Codec Types), 스토리지 커패시티(Storage Capacity), 스토리지 기능 그룹(Storage Function Groups), 포인트 노드(Point Node), 스토리지 유시지(Storage Usage), 큐 요청의 맥시멈 사이즈(Maximum Size of Queue Request), 큐 요청의 맥시멈 넘버(Maximum Number of Queue Request), 큐 요청의 현재 넘버(Current Number of Queue Request), 엔트리의 네트워크 인터페이스 넘버(Network Interface Number of Entries), 네트워크 액세스 타입(Network Access Type), 미디어 트랜스포트(Media Transport), 대역폭 제한(Bandwidth Limit) 등과 같은 커패빌리티 아이템(Item)들을 포함할 수 있다.
상기 디바이스 식별자는 글로벌리(Globally) 유니크하게 디바이스를 식별하는 식별자를 의미할 수 있다. 상기 디바이스 식별자의 값은 스트링 타입의 정보일 수 있다. 상기 디바이스 네임(Device Name)은 디바이스를 위한 유니버셜리(Universally)-유니크 식별자를 의미할 수 있다. 상기 디바이스 네임의 값은 예컨대 스트링 형태의 정보일 수 있다. 디바이스 프렌들리 네임은 엔드 유저(end user)를 위한 쇼트 디스크립션(Short Description)으로서, 그 값은 스트링 타입의 정보일 수 있다. 사용자 식별자는 엔드 유저를 식별하는 식별자로서, 사용자 식별자의 값은 스트링 타입의 정보일 수 있다.
상기 커런트 파워 소스는 디바이스의 현재 파워 소스를 나타내는 디스크립션으로서, 그 값은 스트링일 수 있다. 상기 커런트 파워 소스의 값(Value)은, 예컨대, 디바이스가 AC 파워를 공급받음을 의미하는 ‘AC Power’, 디바이스가 배터리로부터 파워를 공급받음을 의미하는 ‘battery’ 등으로 설정될 수 있다. 디바이스가 AC 소스로부터 AC 파워를 공급받는다고 가정하면, 상기 커런트 파워 소스의 값은 ‘AC Power’로 설정될 수 있다. 디바이스가 배터리로부터 파워를 공급받는다면, 상기 커런트 파워 소스의 값은 ‘battery’로 설정될 수 있다.
상기 차징 스테이터스는 배터리의 현재 충전 상태를 나타내는 커패빌리티 아이템으로서, 그 값은 스트링 형태의 정보일 수 있다. 상기 차징 스테이터스의 값은 디바이스에 배터리가 설치되었으며(Installed) 설치된 배터리가 현재 동작하고 있음(Working)을 의미하는 ‘Available’, 디바이스에 배터리가 설치되었으며 현재 충전 중임을 의미하는 ‘Charging’, 디바이스에 배터리가 설치되지 않았음을 의미하는 ‘Unavailable’, 디바이스에 배터리가 설치되었으나 기능을 바르게(Correctly) 수행하지 못함을 나타내는 ‘Error’ 등으로 설정될 수 있다.
상기 파워 레벨은 배터리의 현재 파워 레벨을 나타낼 수 있다. 예컨대 상기 파워 레벨의 값은 퍼센티지 값일 수 있다. 예를 들어, ‘0’은 배터리가 완전히 방전되어 있거나 배터리가 설치되지 않음을 의미할 수 있다. ‘100’은 배터리가 풀 차징되었음을 의미할 수 있다.
상기 서포팅 미디어 프로파일은 지원 가능한 미디어 프로파일 타입을 나타낼 수 있다. 서포팅 미디어 프로파일의 값은 스트링 형태의 정보로서 예컨대 고화질(HD : High Definition)을 의미하는’HD’, 일반 화질(SD : Standard Definition)을 의미하는 ‘SD’, 포터블 화질(PD : Portable Definition)을 의미하는 ‘PD’등으로 설정될 수 있다.
상기 서포팅 코덱 타입은 지원되는 코덱 타입들의 리스트로서, 그 값은 스트링 타입의 정보일 수 있다. 상기 스토리지 커패시티는 스토리지의 이용할 수 있는 총량(Available Amount)를 나타낼 수 있다.
상기 스토리지 기능 그룹은 디바이스의 스토리지, 예컨대 가상 스토리지 디바이스와 관련하는 기능 그룹(Function Group)을 나타내며, 그 값은 스트링 타입의 정보일 수 있다. 상기 기능 그룹의 값은 ‘액세스 컨트롤(Access Control)’, ‘커패시티 운영(Capacity Management)’, ‘만료(Expiration)’, ‘변환(Transformation)’, ‘플레이리스트(Playlist)’ 등일 수 있다.
상기 ‘액세스 컨트롤’은 가상 스토리지 디바이스를 사용하는 서로 다른 어플리케이션 간을 중재하는 액세스 컨트롤 기능 그룹을 나타낸다. 상기 액세스 컨트롤 기능 그룹은, 예컨대, 특정 어플리케이션이 다른 어플리케이션에 연계되어 있는 콘텐트에 접속하는 것을 차단할 수 있다.
상기 ‘커패시티 운영’은 가상 스토리지 디바이스가 우선 순위에 근거하여 그 스토리지 스페이스를 운영(Manage)하도록 하는 커패시티 운영 기능 그룹을 나타낼 수 있다. 상기 커패시티 운영 그룹은, 예컨대 우선 순위가 더 높은 애셋이 다운로드되면, 우선 순위가 더 높은 애셋을 위한 공간(room)을 만들기 위하여 우선 순위가 더 낮은 애셋을 폐기할 수 있다.
상기 ‘만료(Expiration)’는 가상 스토리지 디바이스가 특정한 데이트 레인지(Specific Date Range)를 기반으로 콘텐트를 저장하도록 하는 만료 기능 그룹을 나타낼 수 있다. 상기 ‘변환(Transformation)’은 가상 스토리지 디바이스로부터 콘텐트를 읽거나 쓰는 동안 변형 오퍼레이션(Transformative Operation)을 허용하는 변환 기능 그룹을 나타낼 수 있다.
상기 ‘플레이리스트(Playlist)’는 가상 스토리지 디바이스가 플레이리스트를 프로세스하는 것을 가능하게 하는 플레이리스트 기능 그룹을 나타낼 수 있다. 만약에 플레이리스트 기능 그룹이 있다면, 플레이리스트는 그룹 객체들에게 사용될 수 있다.
한편, 상기 스토리지 유시지(Storage Usage)는 현재 이용 가능한 스토리지의 총량(amount)를 나타낼 수 있다. 상기 스토리지 유시지의 값은 퍼센티지 값일 수 있다. 예를 들어, 상기 스토리지 유시지의 값이 ‘0’이면 스토리지가 완전히 비어있음(Completely Unoccupied)을 의미하고, ‘100’이면 스토리지가 완전히 사용중임(Fully Occupied)을 의미할 수 있다.
상기 큐 요청의 맥시멈 사이즈(Maximum Size of Queue Request), 큐 요청의 맥시멈 넘버(Maximum Number of Queue Request), 큐 요청의 현재 넘버(Current Number of Queue Request) 및 엔트리의 네트워크 인터페이스 넘버(Network Interface Number of Entries)는 각각 큐 요청의 맥시멈 사이즈, 주어진 시간 동안 제출될 수 있는 큐 요청의 토탈 개수, 컴플리트 상태 이외의 현재 큐 요청 개수, 네트워크 인터페이스의 개수를 나타낼 수 있다.
상기 네트워크 액세스 타입은 이용 가능한 네트워크 액세스 인터페이스 타입을 나타낼 수 있다. 상기 네트워크 액세스 타입의 값은 스트링 형태의 정보일 수 있다. 상기 네트워크 액세스 타입의 값은, 예컨대 ‘Ethernet’, ‘801.11’, ‘Bluetooth’, ‘3G’, ‘WiMAX’등일 수 있다.
상기 미디어 트랜스포트는 D3, D4, D1 인터페이스들을 위하여 지원되는 트랜스포트 프로토콜 타입을 나타낼 수 있다. 상기 미디어 트랜스포트의 값은 예컨대, ‘HTTP’, ‘RTP’ 등일 수 있다. 상기 대역폭 제한은 네트워크 인터페이스의 이용 가능한 대역폭을 나타낼 수 있다.
이상 본 발명에 대하여 그 바람직한 실시예를 예시하여 설명하였지만 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구 범위에 기재된 본 발명의 기술적 사항 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시켜 실시할 수 있음을 이해할 수 있을 것이다. 따라서, 본 발명의 앞으로의 실시예들의 변경은 본 발명의 기술을 벗어날 수 없을 것이다.
CD : 클라이언트 디바이스
CD1 : 제 1 클라이언트 디바이스
CD2 : 제 2 클라이언트 디바이스
CD3 : 제 3 클라이언트 디바이스
110 : 로컬 어플리케이션/사용자 에이전트
112 : 로컬 어플리케이션
114 : 사용자 에이전트
120 : 큐/정책 엔진
122 : 큐 매니저
124 : 매개 디바이스 매니저
126 : 정책 클라이언트
130 : 플레이어
140 : 네트워크 정책 클라이언트
150 : 가상 스토리지 디바이스
160 : 통신부
260 : 통신부
300 : 다른 디바이스
400 : 클라우드 서비스 서버
CS : 콘텐트 서버
CPS : 콘텐트 정책 서버
NPS : 네트워크 정책 서버
IMD : 매게 디바이스

Claims (20)

  1. 제 1 디바이스에 의해 수행되며,
    제 2 디바이스를 사용하여 콘텐트를 다운로드할 것을 요청하는 콘텐트 다운로드 요청을 전송하는 단계;
    상기 콘텐트 다운로드 요청을 수신한 디바이스로부터 상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 수신하는 단계;
    상기 제 2 디바이스로부터 웨이크 업(wake-up) 요청을 수신하는 단계; 및
    상기 콘텐트 다운로드 요청에 응답하여 상기 제 2 디바이스에 다운로드된 콘텐트를 상기 제 2 디바이스로부터 수신하는 단계를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  2. 제 1 항에 있어서,
    상기 컨펌에 대응하여 슬립 모드(sleep-mode)로 진입하는 단계를 더 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  3. 제 1 항에 있어서,
    상기 콘텐트 다운로드 요청, 상기 컨펌 및 상기 웨이크 업 요청 중 적어도 어느 하나는 NFC(Near Field Communication)를 이용하여 송수신되는 것을 특징으로 하는 콘텐트 다운로드 방법.
  4. 제 1 항에 있어서, 상기 웨이크 업 요청 수신 단계는
    상기 웨이크 업 요청을 NFC를 통해 수신하는 단계; 및
    WLAN(Wireless Local Area Network) 또는 3G/4G 무선 통신을 통해 수신하는 단계 중 적어도 어느 하나를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  5. 제 1 항에 있어서, 상기 콘텐트 다운로드 요청은
    다운로드 콘텐트에 대한 소스 URI 정보, 다운로드 가능한 시간을 나타내는 다운로드 타임 및 다운로드 시작 시간을 지칭하는 웨이크 업 타임 정보를 포함하는 다운로드 관련 정보를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  6. 제 1 항에 있어서, 상기 콘텐트 다운로드 요청은
    상기 제 1 디바이스가 상기 다운로드된 콘텐트의 수신 조건과 관련된 정보로서, 전원 연결 상태 정보, 배터리 상태 정보, 네트워크 상태 정보 및 저장 가용 공간 정보 중 적어도 어느 하나를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  7. 제 1 항에 있어서, 상기 콘텐트 다운로드 요청 전송 단계는
    상기 제 2 디바이스로 직접 상기 콘텐트 다운로드 요청을 전송하는 단계; 및
    제 3 디바이스로 상기 콘텐트 다운로드 요청을 전송하는 단계 중 적어도 어느 하나를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  8. 제 7 항에 있어서,
    상기 제 3 디바이스는 클라우드 서비스(cloud service)와 관련된 서버 또는 상기 제 1 디바이스와 상기 제 2 디바이스를 중계하기 위한 디바이스인 것을 특징으로 하는 콘텐트 다운로드 방법.
  9. 제 1 항에 있어서,
    다운로드 받을 콘텐트를 선택하는 사용자 인터페이스를 표시하는 단계; 및
    콘텐트 선택 신호에 응답하여 콘텐트를 선택하는 단계를 더 포함하되, 상기 콘텐트 다운로드 요청 전송 단계는
    상기 콘텐트 선택을 기반으로 상기 제 2 디바이스와 접촉시(connected) 상기 제 2 디바이스로 상기 콘텐트 다운로드 요청을 자동으로 전송하는 단계를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  10. 제 1 항에 있어서,
    최근 접속한 기기 리스트를 활용하여 접속 가능한 주변 기기를 발견하는 단계; 및
    콘텐트 서버로부터, 다운로드 받을 콘텐트의 소스 URI를 획득하는 단계를 더 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  11. 제 1 항에 있어서, 상기 다운로드된 콘텐트 수신 단계는
    다운로드된 콘텐트를 수신할 수 있는 조건을 만족하는지 판단하는 단계;
    상기 판단을 기반으로 하여 다운로드된 콘텐트를 수신하는 단계를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  12. 제 2 디바이스를 사용하여 콘텐트를 다운로드할 것을 요청하는 콘텐트 다운로드 요청을 전송하는 전송부; 및
    상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 수신하고, 웨이크 업(wake-up) 요청을 상기 제 2 디바이스로부터 수신하며, 상기 콘텐트 다운로드 요청에 의해 상기 제 2 디바이스에 다운로드된 콘텐트를 상기 제 2 디바이스로부터 수신하는 수신부를 포함하는 것을 특징으로 하는 콘텐트 다운로드 장치.
  13. 제 2 디바이스에 의해 수행되며,
    제 1 다바이스 및 제 3 디바이스 중 적어도 어느 하나로부터 콘텐트 다운로드 요청을 수신하는 단계;
    상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 전송하는 단계;
    상기 콘텐트 다운로드 요청을 기반으로, 다운로드 받을 콘텐트를 다운로드하는 단계;
    상기 제 1 디바이스로 웨이크 업(wake-up) 요청을 전송하는 단계; 및
    상기 다운로드된 콘텐트를 상기 제 1 디바이스로 전송하는 단계를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  14. 제 13 항에 있어서,
    상기 콘텐트 다운로드 요청, 상기 컨펌 및 상기 웨이크 업 요청 중 적어도 어느 하나는 NFC(Near Field Communication)를 이용하여 송수신되는 것을 특징으로 하는 콘텐트 다운로드 방법.
  15. 제 13 항에 있어서,
    상기 콘텐트 다운로드 요청을 상기 제 1 디바이스와 다른 제 3 디바이스로부터 수신하고, 상기 다운로드 받을 콘텐트를 상기 제 3 디바이스로부터 다운로드하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  16. 제 13 항에 있어서, 상기 웨이크 업 요청 전송 단계는
    상기 웨이크 업 요청을 NFC를 통해 전송하는 단계; 및
    상기 제 1 디바이스로부터 NFC를 통해 전송된 상기 웨이크 업 요청에 대한 응답이 기준 시간 동안 없는 경우, WLAN(Wireless Local Area Network) 또는 3G/4G 무선 통신을 통해 상기 웨이크 업 요청을 전송하는 단계를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  17. 제 13 항에 있어서, 상기 다운로드 완료된 콘텐트 전송 단계는
    상기 콘텐트 다운로드 요청에 포함된, 상기 제 1 디바이스의 상기 다운로드된 콘텐트 수신 조건과 관련된 정보를 기반으로 상기 다운로드된 콘텐트의 전송 여부를 판단하는 단계; 및
    상기 판단 결과를 기반으로 상기 다운로드된 콘텐트를 상기 제 1 디바이스로 전송하는 단계를 포함하는 것을 특징으로 하는 콘텐트 다운로드 방법.
  18. 콘텐트 다운로드 요청을 제 1 다바이스 및 제 3 디바이스 중 적어도 어느 하나로부터 수신하고, 상기 콘텐트 다운로드 요청을 기반으로 하여, 상기 제 1 서버로부터 다운로드 받을 콘텐트를 다운로드하는 수신부; 및
    상기 콘텐트 다운로드 요청에 응답하는 컨펌(confirm)을 전송하고, 웨이크 업(wake-up) 요청을 상기 제 1 디바이스로 전송하며, 상기 다운로드된 콘텐트를 상기 제 1 디바이스로 전송하는 전송부를 포함하는 것을 특징으로 하는 콘텐트 다운로드 장치.
  19. 제 2 디바이스를 사용하여 콘텐트를 다운로드할 것을 요청하는 콘텐트 다운로드 요청을 전송하고, 상기 콘텐트 다운로드 요청에 응답하는 컨펌을 수신하며, 상기 제 2 디바이스로부터 웨이크 업 요청을 수신하고, 상기 콘텐트 다운로드 요청에 따라 상기 제 2 디바이스에 다운로드된 콘텐트를 수신하는 제 1 디바이스; 및
    상기 콘텐트 다운로드 요청을 수신하고, 상기 컨펌을 전송하며, 상기 콘텐트 다운로드 요청을 기반으로, 다운로드 받을 콘텐트를 다운로드하고, 상기 제 1 디바이스로 웨이크 업 요청을 전송하며, 상기 다운로드된 콘텐트를 제 1 디바이스로 전송하는 제 2 디바이스를 포함하는 것을 특징으로 하는 콘텐트 다운로드 시스템.
  20. 제 19 항에 있어서,
    상기 제 1 디바이스로부터 상기 콘텐트 다운로드 요청을 수신하고, 상기 콘텐트 다운로드 요청에 응답하는 컨펌을 상기 제 1 디바이스로 전송하며, 상기 콘텐트 다운로드 요청을 상기 제 2 디바이스로 전송하는 제 3 디바이스를 더 포함하는 것을 특징으로 하는 콘텐트 다운로드 시스템.
PCT/KR2013/004102 2012-05-10 2013-05-09 Nfc를 이용한 콘텐트 다운로드 방법 및 장치 WO2013169043A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/399,877 US9467202B2 (en) 2012-05-10 2013-05-09 Method and apparatus for downloading content using NFC

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261645070P 2012-05-10 2012-05-10
US61/645,070 2012-05-10

Publications (1)

Publication Number Publication Date
WO2013169043A1 true WO2013169043A1 (ko) 2013-11-14

Family

ID=49550997

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2013/004102 WO2013169043A1 (ko) 2012-05-10 2013-05-09 Nfc를 이용한 콘텐트 다운로드 방법 및 장치

Country Status (2)

Country Link
US (1) US9467202B2 (ko)
WO (1) WO2013169043A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015099366A1 (en) * 2013-12-27 2015-07-02 Samsung Electronics Co., Ltd. Method and apparatus for sharing data quota
CN105827694A (zh) * 2016-03-11 2016-08-03 腾讯科技（深圳）有限公司 网络资源的获取方法和装置
CN107835251A (zh) * 2017-11-21 2018-03-23 武汉虹旭信息技术有限责任公司 基于无线网络中资源分布式存储与下载方法
US10284494B2 (en) 2014-03-28 2019-05-07 Baidu Online Network Technology (Beijing) Co., Ltd. Device controlling method, client, server and intermediate device

Families Citing this family (77)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9318108B2 (en) 2010-01-18 2016-04-19 Apple Inc. Intelligent automated assistant
US8977255B2 (en) 2007-04-03 2015-03-10 Apple Inc. Method and system for operating a multi-function portable electronic device using voice-activation
US8676904B2 (en) 2008-10-02 2014-03-18 Apple Inc. Electronic devices with voice command and contextual data processing capabilities
US10255566B2 (en) 2011-06-03 2019-04-09 Apple Inc. Generating and processing task items that represent tasks to perform
US10417037B2 (en) 2012-05-15 2019-09-17 Apple Inc. Systems and methods for integrating third party services with a digital assistant
BR112015018905B1 (pt) 2013-02-07 2022-02-22 Apple Inc Método de operação de recurso de ativação por voz, mídia de armazenamento legível por computador e dispositivo eletrônico
US10652394B2 (en) 2013-03-14 2020-05-12 Apple Inc. System and method for processing voicemail
US10748529B1 (en) 2013-03-15 2020-08-18 Apple Inc. Voice activated device for use with a voice-based digital assistant
US20140304381A1 (en) * 2013-04-05 2014-10-09 Nokia Corporation Method and apparatus for communicating with smart objects
CN110248338B (zh) 2013-05-10 2021-12-14 华为技术有限公司 用于控制网络外设备到设备通信的系统和方法
US10176167B2 (en) 2013-06-09 2019-01-08 Apple Inc. System and method for inferring user intent from speech inputs
WO2015004859A1 (ja) * 2013-07-09 2015-01-15 日本電気株式会社 通信端末
CN103648014A (zh) * 2013-11-15 2014-03-19 乐视致新电子科技（天津）有限公司 智能电视向移动通信终端推送资源的方法和装置
US9467222B1 (en) * 2014-04-23 2016-10-11 Fortify Technologies, LLC Systems and methods for parallel communication with multiple bluetooth devices
CN106471570B (zh) 2014-05-30 2019-10-01 苹果公司 多命令单一话语输入方法
US10170123B2 (en) 2014-05-30 2019-01-01 Apple Inc. Intelligent assistant for home automation
US9715875B2 (en) 2014-05-30 2017-07-25 Apple Inc. Reducing the need for manual start/end-pointing and trigger phrases
US9338493B2 (en) 2014-06-30 2016-05-10 Apple Inc. Intelligent automated assistant for TV user interactions
EP2996307B1 (de) * 2014-09-10 2019-11-27 Siemens Aktiengesellschaft Verfahren zur energieoptimierten datenübertragung mittels opc ua protokoll
US9843912B2 (en) * 2014-10-30 2017-12-12 At&T Intellectual Property I, L.P. Machine-to-machine (M2M) autonomous media delivery
US9886953B2 (en) 2015-03-08 2018-02-06 Apple Inc. Virtual assistant activation
US10460227B2 (en) 2015-05-15 2019-10-29 Apple Inc. Virtual assistant in a communication session
US10200824B2 (en) 2015-05-27 2019-02-05 Apple Inc. Systems and methods for proactively identifying and surfacing relevant content on a touch-sensitive device
US20160378747A1 (en) 2015-06-29 2016-12-29 Apple Inc. Virtual assistant for media playback
WO2017020270A1 (en) 2015-08-05 2017-02-09 Qualcomm Incorporated Deep packet inspection indication for a mobile cdn
KR102344822B1 (ko) * 2015-08-11 2021-12-28 퀄컴 인코포레이티드 Http-인식 콘텐츠 캐싱
US10331312B2 (en) 2015-09-08 2019-06-25 Apple Inc. Intelligent automated assistant in a media environment
US10740384B2 (en) 2015-09-08 2020-08-11 Apple Inc. Intelligent automated assistant for media search and playback
US10747498B2 (en) 2015-09-08 2020-08-18 Apple Inc. Zero latency digital assistant
US10671428B2 (en) 2015-09-08 2020-06-02 Apple Inc. Distributed personal assistant
US10348808B2 (en) 2015-10-30 2019-07-09 International Business Machines Corporation Hybrid cloud applications
US10691473B2 (en) 2015-11-06 2020-06-23 Apple Inc. Intelligent automated assistant in a messaging environment
US10956666B2 (en) 2015-11-09 2021-03-23 Apple Inc. Unconventional virtual assistant interactions
US10223066B2 (en) 2015-12-23 2019-03-05 Apple Inc. Proactive assistance based on dialog communication between devices
KR20170083905A (ko) * 2016-01-11 2017-07-19 엘지전자 주식회사 이동 단말기 및 그 제어방법
US10586535B2 (en) 2016-06-10 2020-03-10 Apple Inc. Intelligent digital assistant in a multi-tasking environment
DK201670540A1 (en) 2016-06-11 2018-01-08 Apple Inc Application integration with a digital assistant
DK179415B1 (en) 2016-06-11 2018-06-14 Apple Inc Intelligent device arbitration and control
KR102599479B1 (ko) * 2016-11-02 2023-11-08 삼성전자주식회사 근거리통신 연결을 위한 전자장치, 시스템 및 방법
US11204787B2 (en) 2017-01-09 2021-12-21 Apple Inc. Application integration with a digital assistant
DK180048B1 (en) 2017-05-11 2020-02-04 Apple Inc. MAINTAINING THE DATA PROTECTION OF PERSONAL INFORMATION
US10726832B2 (en) 2017-05-11 2020-07-28 Apple Inc. Maintaining privacy of personal information
US11301477B2 (en) * 2017-05-12 2022-04-12 Apple Inc. Feedback analysis of a digital assistant
DK179745B1 (en) 2017-05-12 2019-05-01 Apple Inc. SYNCHRONIZATION AND TASK DELEGATION OF A DIGITAL ASSISTANT
DK179496B1 (en) 2017-05-12 2019-01-15 Apple Inc. USER-SPECIFIC Acoustic Models
DK201770427A1 (en) 2017-05-12 2018-12-20 Apple Inc. LOW-LATENCY INTELLIGENT AUTOMATED ASSISTANT
US20180336275A1 (en) 2017-05-16 2018-11-22 Apple Inc. Intelligent automated assistant for media exploration
US20180336892A1 (en) 2017-05-16 2018-11-22 Apple Inc. Detecting a trigger of a digital assistant
US10448067B2 (en) * 2017-10-31 2019-10-15 Disney Enterprises, Inc. Media content cross-referencing
US10818288B2 (en) 2018-03-26 2020-10-27 Apple Inc. Natural assistant interaction
US10928918B2 (en) 2018-05-07 2021-02-23 Apple Inc. Raise to speak
US11145294B2 (en) 2018-05-07 2021-10-12 Apple Inc. Intelligent automated assistant for delivering content from user experiences
DK180639B1 (en) 2018-06-01 2021-11-04 Apple Inc DISABILITY OF ATTENTION-ATTENTIVE VIRTUAL ASSISTANT
US10892996B2 (en) 2018-06-01 2021-01-12 Apple Inc. Variable latency device coordination
DK179822B1 (da) 2018-06-01 2019-07-12 Apple Inc. Voice interaction at a primary device to access call functionality of a companion device
US10555119B2 (en) 2018-07-06 2020-02-04 Apple Inc. Ranging priority indication
CN110876117A (zh) * 2018-08-31 2020-03-10 中兴通讯股份有限公司 终端失联的恢复方法及装置
US11462215B2 (en) 2018-09-28 2022-10-04 Apple Inc. Multi-modal inputs for voice commands
US11475898B2 (en) 2018-10-26 2022-10-18 Apple Inc. Low-latency multi-speaker speech recognition
US11348573B2 (en) 2019-03-18 2022-05-31 Apple Inc. Multimodality in digital assistant systems
DK201970509A1 (en) 2019-05-06 2021-01-15 Apple Inc Spoken notifications
US11475884B2 (en) 2019-05-06 2022-10-18 Apple Inc. Reducing digital assistant latency when a language is incorrectly determined
US11423908B2 (en) 2019-05-06 2022-08-23 Apple Inc. Interpreting spoken requests
US11307752B2 (en) 2019-05-06 2022-04-19 Apple Inc. User configurable task triggers
US11140099B2 (en) 2019-05-21 2021-10-05 Apple Inc. Providing message response suggestions
US11289073B2 (en) 2019-05-31 2022-03-29 Apple Inc. Device text to speech
US11496600B2 (en) 2019-05-31 2022-11-08 Apple Inc. Remote execution of machine-learned models
DK201970511A1 (en) 2019-05-31 2021-02-15 Apple Inc Voice identification in digital assistant systems
DK180129B1 (en) 2019-05-31 2020-06-02 Apple Inc. USER ACTIVITY SHORTCUT SUGGESTIONS
US11360641B2 (en) 2019-06-01 2022-06-14 Apple Inc. Increasing the relevance of new available information
US11227599B2 (en) 2019-06-01 2022-01-18 Apple Inc. Methods and user interfaces for voice-based control of electronic devices
US11488406B2 (en) 2019-09-25 2022-11-01 Apple Inc. Text detection using global geometry estimators
US11061543B1 (en) 2020-05-11 2021-07-13 Apple Inc. Providing relevant data items based on context
US11038934B1 (en) 2020-05-11 2021-06-15 Apple Inc. Digital assistant hardware abstraction
US11755276B2 (en) 2020-05-12 2023-09-12 Apple Inc. Reducing description length based on confidence
US11490204B2 (en) 2020-07-20 2022-11-01 Apple Inc. Multi-device audio adjustment coordination
US11438683B2 (en) 2020-07-21 2022-09-06 Apple Inc. User identification using headphones

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050015285A1 (en) * 2003-07-17 2005-01-20 Hitachi, Ltd. Method and system for intelligent delivery of contents in a network
KR100775272B1 (ko) * 2006-05-12 2007-11-08 (주) 엘지텔레콤 Ｐｃ 에이전트를 이용한 모바일 원격다운로드 서비스장치및 방법
US20080160970A1 (en) * 2006-10-19 2008-07-03 July Systems, Inc. Method and computer program product for premium mobile service for discovery, payment, personalization and access of mobile content
KR20090039017A (ko) * 2007-10-17 2009-04-22 에스케이텔레콤 주식회사 이동단말을 이용한 콘텐츠 예약 다운로드 방법, 시스템 및이를 위한 이동단말
KR20110067722A (ko) * 2009-12-15 2011-06-22 엘지이노텍 주식회사 컨텐츠 제공장치 및 방법

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5024610B2 (ja) * 2007-05-31 2012-09-12 ソニー株式会社 情報処理システム、情報処理装置、情報処理方法、及びプログラム
JP4596044B2 (ja) * 2008-06-03 2010-12-08 ソニー株式会社 情報処理システム、情報処理方法
US8126985B1 (en) * 2008-12-31 2012-02-28 Qurio Holdings, Inc. Prioritizing virtual object downloads in a distributed virtual environment
JP5368147B2 (ja) * 2009-04-02 2013-12-18 フェリカネットワークス株式会社 通信装置、情報処理装置、プログラム、およびリーダライタ提供システム
CA2780067C (en) * 2009-11-06 2014-09-09 Research In Motion Limited Device, system and method for selecting, sharing and displaying electronic content
CN103003821B (zh) * 2010-07-19 2016-05-18 三星电子株式会社 用于提供drm服务的方法和装置
US8798580B2 (en) * 2010-09-21 2014-08-05 Cellco Partnership Method and system for activating services on a wireless terminal
US9344483B2 (en) * 2010-10-13 2016-05-17 Fujitsu Limited System and method for facilitating remote downloading
US8885498B2 (en) * 2010-12-23 2014-11-11 Deutsche Telekom Ag Network traffic aggregation method and device for in-vehicle telematics systems using tethering and peer-to-peer networking of mobile devices
US9214988B2 (en) * 2012-02-06 2015-12-15 Qualcomm Incorporated Methods and apparatus for improving peer communications using an active communication mode
US20130282564A1 (en) * 2012-04-21 2013-10-24 Research In Motion Limited System and method for transmitting application data between two communication devices
US9100362B2 (en) * 2012-07-06 2015-08-04 Yahoo! Inc. Peer-to-peer architecture for web traffic management

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050015285A1 (en) * 2003-07-17 2005-01-20 Hitachi, Ltd. Method and system for intelligent delivery of contents in a network
KR100775272B1 (ko) * 2006-05-12 2007-11-08 (주) 엘지텔레콤 Ｐｃ 에이전트를 이용한 모바일 원격다운로드 서비스장치및 방법
US20080160970A1 (en) * 2006-10-19 2008-07-03 July Systems, Inc. Method and computer program product for premium mobile service for discovery, payment, personalization and access of mobile content
KR20090039017A (ko) * 2007-10-17 2009-04-22 에스케이텔레콤 주식회사 이동단말을 이용한 콘텐츠 예약 다운로드 방법, 시스템 및이를 위한 이동단말
KR20110067722A (ko) * 2009-12-15 2011-06-22 엘지이노텍 주식회사 컨텐츠 제공장치 및 방법

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015099366A1 (en) * 2013-12-27 2015-07-02 Samsung Electronics Co., Ltd. Method and apparatus for sharing data quota
US10567545B2 (en) 2013-12-27 2020-02-18 Samsung Electronics Co., Ltd. Method and apparatus for sharing data quota
US10284494B2 (en) 2014-03-28 2019-05-07 Baidu Online Network Technology (Beijing) Co., Ltd. Device controlling method, client, server and intermediate device
EP2924954B1 (en) * 2014-03-28 2020-08-19 Baidu Online Network Technology (Beijing) Co., Ltd Device controlling methods, client and server
CN105827694A (zh) * 2016-03-11 2016-08-03 腾讯科技（深圳）有限公司 网络资源的获取方法和装置
CN107835251A (zh) * 2017-11-21 2018-03-23 武汉虹旭信息技术有限责任公司 基于无线网络中资源分布式存储与下载方法

Also Published As

Publication number Publication date
US9467202B2 (en) 2016-10-11
US20150133049A1 (en) 2015-05-14

Similar Documents

Publication Publication Date Title
WO2013169043A1 (ko) Nfc를 이용한 콘텐트 다운로드 방법 및 장치
WO2018074892A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2018222024A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2015069093A1 (ko) 블루투스 연결 방법 및 장치
WO2018038459A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018048268A1 (ko) 블루투스 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
EP3738351A1 (en) Method and device using network slicing in mobile communication system
WO2016017908A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016017907A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2015182896A1 (ko) 블루투스 연결 방법 및 장치
WO2011105695A2 (ko) 전자기기 및 전자기기의 동작 방법
WO2015069031A1 (ko) 블루투스를 이용한 커뮤니케이션 링크 형성 방법 및 장치
WO2014204272A1 (ko) 무선 통신시스템에서 블루투스를 이용하여 멀티미디어 콘텐츠를 재생하기 위한 방법 및 장치
WO2018021877A1 (ko) 디바이스의 연결을 형성하기 위한 방법 및 장치
WO2013058423A1 (ko) 전자기기 및 전자기기의 동작 방법
WO2015002385A1 (ko) 무선 통신시스템에서 디바이스들 간에 커뮤니케이션을 위한 방법 및 장치
WO2013015571A2 (ko) 전자기기 및 전자기기의 동작 방법
WO2015163680A1 (ko) 무선 통신 시스템에서 블루투스 저전력 에너지 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2018135926A1 (ko) 블루투스 통신 방법 및 장치
WO2017043869A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2017018604A1 (ko) 블루투스 le(low energy) 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2014189323A1 (en) Apparatus and method for performing wireless docking operation in communication system supporting universal plug and play protocol
WO2015163547A1 (ko) 무선 통신시스템에서 블루투스를 이용하여 http 데이터를 전송하기 위한 방법 및 장치
WO2018009040A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2011090287A4 (en) Electronic device and operating method of the same

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: 13787099

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14399877

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13787099

Country of ref document: EP

Kind code of ref document: A1