Title of Invention	A METHOD AND SYSTEM FOR PROVIDING ACCESS CONTROL & AUTOMATION FOR A REMOTE CLIENT DEVICE ACCESSING A VIRTUALIZED UNIVERSAL PLUG AND PLAY HOME NETWORK
Abstract	ABSTRACT The proposed invention explains a method and system for access control & automation for a Remote Client accessing a Virtualized UPNP Home Network. Users can control and access the Devices from anywhere outside the Home Network through the Internet. A Remote Access Administrator may give access permissions to the users with whom he wants to share the Devices. The system includes an AccessControl model to provide access to the users trying to access the Home Network incorporating Virtualizers. The Virtualizers enhance the features provided by the Devices in the Home Network. The AccessControl model advertises itself as a Service in the Home Network. A Device Description Document (DDD) for each Device is present in the Home Network. The Remote Access Administrator configures the DDD for each Remote User. Further, the system allows the automatic routing and conversion of data according to the capabilities of the Remote User's device. A Remote Access Discovery Agent (RADA) authenticates a Remote User before allowing the Remote User to access the devices in the Home Network.

Title of Invention

A METHOD AND SYSTEM FOR PROVIDING ACCESS CONTROL & AUTOMATION FOR A REMOTE CLIENT DEVICE ACCESSING A VIRTUALIZED UNIVERSAL PLUG AND PLAY HOME NETWORK

Abstract

ABSTRACT The proposed invention explains a method and system for access control & automation for a Remote Client accessing a Virtualized UPNP Home Network. Users can control and access the Devices from anywhere outside the Home Network through the Internet. A Remote Access Administrator may give access permissions to the users with whom he wants to share the Devices. The system includes an AccessControl model to provide access to the users trying to access the Home Network incorporating Virtualizers. The Virtualizers enhance the features provided by the Devices in the Home Network. The AccessControl model advertises itself as a Service in the Home Network. A Device Description Document (DDD) for each Device is present in the Home Network. The Remote Access Administrator configures the DDD for each Remote User. Further, the system allows the automatic routing and conversion of data according to the capabilities of the Remote User's device. A Remote Access Discovery Agent (RADA) authenticates a Remote User before allowing the Remote User to access the devices in the Home Network.

Full Text	lELD OF INVENTION This invention relates to the field of Home Networking technology, and particularly to those utilizing the Universal Plug and Play (UPnP) as their preferred approach. Nonetheless, it applies equally to approaches similar to the UPnP. More specifically, it relates to a method and system that enhances the Services provided by UPnP Devices in a Home Network, when accessed across from a remote location, with respect to the access control model. DESCRIPTION OF RELATED ART A typical UPnP-Remote Access Device model featuring the Remote Clients (which includes both Remote Access Clients & Remote-CPs) accessing the Devices in a Home Network (providing their respective Services) over the Residential Gateway (RG) could be as illustrated in Figure 1. The application WO2006088592A1 describes a method and a system for data routing, management and associated applications. The system includes a host server that facilitates delivery of content between a Home Network node (for e.g., PC, web camera) and a remote network access appliance (for e.g., a mobile phone). The application describes an authentication mechanism to verify the authenticity of the remote access appliance. The authentication mechanism is used to identify if the remote access appliance has appropriate rights to access the data at the Home Network node. Also, the mechanism may be used to limit access to specific portions of the data. Further, characteristics of the remote access appliance are also considered for granting access to the appliance. For example, music data requested by the remote access appliance may be formatted in a particular audio format for which the appliance is adapted to play the audio data. But the application fails to describe the following concepts: • An approach specific to prevalent Home Networking standards, like the UPnP - which have a means to discover Devices & their respective Services • Access rights to content are based on an XML approach that UPnP follows & it is not limited to just media content • A distributed access control model with multiple instances of the AccessControl Servers within a Home Network, with different options to base this model on • Validating the Remote User accessing the Devices in the Home Network based on a set of preset filters by the Remote Access Administrator • Intelligent routing and automatic conversion of data format based on the capabilities of the Remote device, through the use of Virtualizers (distributed across in a Home Network) SUMMARY OF THE INVENTION Specific to the Home Networks, and applies appropriately for the UPnP technology. Here we mainly are concerned with the mechanism of remotely accessing Devices (i.e. from outside the home) & their respective Services that are found within a Home Network. UPnP has increased importance in becoming the standard for Home Networking. UPnP however was designed to be used within a private Home Network area, with no consideration for accessing home devices remotely, say over the public Internet or from another home. Internet enables devices to connect remotely, using various technologies to do it securely too (like the VPN, IPSec, etc.). Utilizing the Internet and the UPnP, users could access content available within a home, control devices and utilize other Services in a home from anywhere, and at anytime. Such combination provides great convenience for homeowners, extending the boundaries of their Home Network. For example, parents can now access their home surveillance camera, and perhaps monitor their little ones at home, while away from home. This invention describes methods and apparatus that enhance Services provided by UPnP devices in a Home Network when accessed across from a remote location, over the Internet. Accordingly, this invention explains a method for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network comprising the following steps: • Remote Access Administrator gives access permissions to the Remote Users who could access Devices in the Home Network • the Device providing AccessControl Service shall advertise itself within the Home Network, in the usual UPnP way • Remote Access Administrator configures the aggregated Device Description Documents (DDD) for each of the Remote User who could access the Home Network • includes an access control model to provide access for the Remote Users accessing the Home Network, after going through a process of verification • incorporates Virtualizers, that is a resource which enhances the features provided by a given Device in a Home Network to suit the capabilities of the Remote Client device • performing an automated routing based on the capabilities of the Remote User's device capabilities, over the Virtualizer devices These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 shows the UPnP's Remote Access Device Model & the AccessControl Service Figure 2 shows the UPnP-RA Device Model & the AccessControl Service with Virtualization DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However, in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. Atypical UPnP-Remote Access Device model featuring the Remote Clients (which includes both Remote Access Clients & Remote-CPs) accessing the Devices in a Home Network (providing their respective Services) over the Residential Gateway (RG) could be as illustrated in Figure 1. Figure 2 illustrates the utilization of the AccessControl model in the context of remotely accessing clients into a Home Network that incorporate Virtualizers in their path. A Virtualizer is a Device responsible for enhancing or converting the features exposed by the original Devices in a Home Network. The AccessControl Service could also provide necessary intelligence with respect to the Remote Client device's capabilities, which could be taken care by the Devices present within a Home Network. Do note the routings based on the Remote Client device's capabilities in the figure, and as given below: Devicel > Vendor Virtl > R-User1 > RAS > RG > RAC > Remote-CP1 Devicel > Generic Virt2 > R-User2 > RAS > RG > RAC > Remote-CP2 Device2 > Generic Virt2 > R-User3 > RAS > RG > RAC > Remote-CP3 Device2 > R-User4 > RAS > RG > RAC > Remote-CP4 i) Devices in the UPnP normally offer Services ii) Virtualizers are also UPnP-Devices, whose Services are primarily consumed during the process of Remote Access iii) AccessControl Device is a UPnP-Device that provides a Service for controlling the privileges of all Remote Clients accessing the Devices/Services within a Home Network iv) Remote Access Server (RAS) is a UPnP-Device providing many Services, one of them being the Remote Access Discovery Agent (RADA) Service for passing the UPnP's Discovery information in the Home Network to the Remote Access Client (RAC) Device v) The RAC device also has a similar RADA Service component for synchronizing the Device Discovery information with the RAS Device vi) Residential Gateway (RG) is a Device, that provides the UPnP's Internet Gateway Device (IGD) Service for the Devices in the Home Network's LAN for accessing over into the WAN vii) Remote-CP is a UPnP-Control Point that is remotely located behind the RAC device. The RAC device is a logical Device, and could be present within the same physical device as the Remote-CP itself too. In this invention, we primarily concentrate on two aspects within a UPnP-like Home Network that is being remotely accessed by certain UPnP Clients, perhaps over the Internet. The first is related to the access control capabilities for all the devices remotely accessing a Home Network, its Devices & utilizing their respective Services. The access control mechanism is responsible for both (i) firstly, exposing only what needs to be accessible for the Remote Client with respect to the Devices, Services, Actions, Content, etc. (ii) secondly, its also responsible for doing a double-check during the actual process of access itself, just to avoid Remote User from hacking into Devices which he isn't supposed to access as he wasn't given the necessary permissions by the Remote Access Administrator. The other feature is concentrated around the process of Virtualizing the features provided by a Device in a UPnP-like Home Network to a Remote Client accessing it. The Remote Client is merely interested in utilizing a Service rather than understanding the intricacies about which Device is specifically offering this Service. Virtualization could be with respect to any aspect/feature in a Home Networking environment. The process followed here is to cloud the original Device's capabilities and expose a Virtualizer instead to the Remote Client, to bring in enhanced features comparatively that suit the Remote Client's capabilities. For exact definition of some of the terms used in the explanation below, please refer to the glossary. The access control process is as follows: As a Remote Access Administrator, one is usually interested to provide an access control mechanism for his/her Devices, Services, Actions, etc. within a Home Network, thus providing the necessary restricted access to the Remote Users entering the Home Network. As part of provisioning these above requirements, the AccessControl Device need not necessarily have knowledge about each of the Devices/Services specifically, i.e. with respect to its Device Control Protocol (DCP) as defined in the UPnP specification. It could perform a simple XML-based filtering, on the SSDP information that it would receive from each of the Devices in a Home Network [the AccessControl Device here is acting as a "UPnP-ControlPoint" in this context, gathering all the SSDP info that is being advertised by various UPnP Devices in a Home Network]. AccessControl Device shall advertise about its Service within the Home Network just as any other UPnP-Device [while at this point, it is taking the role of an "UPnP-Device"], using the traditional SSDP means. The RAS Device shall respond to the AccessControl's SSDP, and shall utilize its Services. Other Control Point devices within the Home Network although receiving this SSDP, would not be interested in this particular Service from AccessControl Device, and shall ignore it. AccessControl Service only needs to understand that there is a DDD for each of the UPnP-Devices within the Home Network, upon which it needs to apply certain filters, transformations, etc., which is configured specifically for each of the Remote Users, by the Remote Access Administrator. The Remote-CPs shall access Devices in the Home Network. As part of the access methodology, the Remote-CPs shall also provide a description about their respective device capabilities. This kind of information is not part of the conventional UPnP messaging, but could be easily incorporated in order to provide the extra benefits during Remote Access, dynamically. Or, the other option could also be that the Remote Access Administrator could include these Remote Client's capabilities during the setup process, i.e. when it is configuring the access control privileges on the AccessControl Device for that particular Remote Client device (this is a static way of doing the above, and perhaps wouldn't take care of any upgrades possible on the remote side). Since AccessControl plays an important role in the whole process of remote access, having a backup helps. We could have more than one device acting as the AccessControl Device in the Home Network, maintaining replica of the configuration info of the remote RACs. In this scenario, the AccessControl Device from which the RAS receives the SSDP first shall be considered as the reference (or we could have any other overriding mechanisms also that could be incorporated in some cases). The other option is that of distributed AccessControl information scattered across certain set of Devices. In which case the RAS needs to be configured to consider them all appropriately. A simple application for configuring the access privileges on an AccessControl Device should be present. The configuration could mainly consist a matrix of elements - the list of Devices, the Services that each of them provide, and their list of Actions respectively. All this may be defined for each of the Remote Users, by means of a simple checklist perhaps that could specify if they have access or not against each of them. We could include Content-based-filters in certain situations, wherein we have media/data being accessed across. This shall work in coordination with certain Services, like the Content Directory Service (CDS) for example, which is involved in listing media content available in a UPnP-Device. The Remote User could be restricted on certain type of audio or video, based on the Type, Title, etc. which shall be one of the configurables for a particular Remote Client accessing this Home Network. When the RAS is exposing the list of Devices, Services, Actions, Content to a Remote Client, it shall appropriately modify the SSDP based on the access privileges configured by the Remote Access Administrator for it specifically. The SSDP in this case is unique to each of the Remote Clients, and the RAS shall be responsible for this modification and reconstruction of SSDP structure appropriately, taking necessary inputs from the AccessControl Device. [2] When a Remote Client tries to access over the Residential Gateway & the RAS, the RAS Device needs to understand that there is a Device in its Home Network providing the AccessControl Service (based on the SSDP adverts it received previously). The RAS shall consult with the AccessControl Service and re-check for the Remote Client's privileges before providing the necessary access to the specific Device in the Home Network. Based on the Remote Client's capabilities (refer to points 6 and 7), the AccessControl Device shall route the request through the appropriate Virtualizer. Virtualizers provide extra features atop the original UPnP-Devices, those that were not originally present with these Devices. In Figure 2, for instance if there were Generic-Virtualizers like the transcoders for instance, this shall certainly benefit a Remote User. The Generic-Virtualizer features shall be termed "Virtual Feature" and its Services as "Virtual Service" here on in this document. For example, a Virtual Feature could be an MPEG2-to-H.264 transcoding, which shall provide this Virtual Service to all Devices hosting MPEG2 content within the Home Network, and which are accessed by all Remote-CPs supporting H.264 rendering capabilities. Another Virtualizer Service could be for providing a Virtual Feature like MPEG2-to-DivX transcoding, this also applies on to the same set of Devices, but applies when a Remote-CP is capable of supporting DivX rendering instead. The requirement here is the routing necessary for making it all happen, based on the specific requirement of the Remote-CP's capabilities, although applied for the same set of Devices in the Home Network - which is being applied by the AccessControl Device as it has a prior understanding of the Remote Client's capabilities. The other type of Virtualizers are those specific to a particular Device, termed here as the Vendor-specific-Virtualizers. These are coupled with their respective Devices only (also illustrated in Figure 2). The only difference in this case being that they are very specific, and ideally provided by the manufacturer of the Device itself Unlike the Generic-Virtualizers which can be provided by any third-party vendor too, as they are based on open standards. This should not restrict these Devices to get routed over the Generic-Virtualizers whenever necessary (as illustrated in Figure 2 for Remote-User-2; the Device-1 had a Vendor-specific-Virtualizer). Building the Device-to-Virtualizer relationship is the responsibility of the AccessControl Device, which decides this routing based on the Remote Client's capabilities. Finally, we could always have the normal scenario wherein a Remote-CP accesses a UPnP Device directly, if they find the desired compatibility perhaps. For example, a Remote-CP that has MPEG-2 rendering capabilities accessing an MPEG-2 Device, without using any of the Virtual Services (illustrated in Figure 2, with Remote-User-4). We can apply multiple Virtualizers too in the path, including a combination of vendor-specific & the generic ones. A simple example here could be a UPnP-Device that is serving MPEG2 content, while the Remote Client is capable of rendering DivX format. And we have two Virtualizers in the Home Network - a MPEG2-to-H.264 transcoder & a H.264-to-DivX transcoder. In this scenario, the AccessControl Device shall appropriately route the content through both these transcoders, giving content in the DivX format, which is compatible for the Remote Client's capabilities. Keeping the common aspect of access control on the particular Device as an independent entity gives us the flexibility in designing, wherein we give the various Services packaged into the Home Network. How they get connected dynamically is based on the capabilities of the Remote Client. The AccessControl Service holds the modified URLs for the UPnP-Devices and/or Virtualizer-UPnP-Devices, based on SSDP/DDD it receives and maintains. The RADA exposes a unique DevicelnfoList for each of the Remote Clients specifically. But it is the responsibility of the AccessControl to manage these lists specifically for each of the Remote Clients, based on the Remote-CP's capabilities, received either during login phase or as was pre-configured. Understanding the Remote-CP's capabilities is the crux, which can be addressed in the following ways: 1. For a simple scenario - this kind of information is not coming part of the standard UPnP messaging, hence it is best addressed by the user during the process of logging into the Home Network. In our example above, if the Remote-CP is consuming a particular content, it should mention the media format that is compatible for it. This information about the Remote-CP shall be maintained until the end of the session by the RAS. And when he re-logs into the Home Network next time he could always come in with a Remote-CP having different capabilities too (as we consider the RAC as an independent entity to the Remote-CP for giving such a flexibility to the Remote Users). 2. For a more complete scenario - we could rather expose the same Device as multiple Devices, based on the number of Virtualizers attached to it. And Remote-CP chooses the one its compatible to it, based on its own rendering capabilities. All this becomes part of the DevicelnfoList exposed over the RADA to the Remote-CP. The other important aspect is that the AccessControl scans all requests from Remote-CP each time they hit the RAS, before they can go any further accessing the DeviceA/irtualizer in a Home Network. As a consequence, even if the Remote-CP tries to give an "invalid URL" this shall be declined as an invalid link by the AccessControl (i.e. its only allowing the URLs specified in the DevicelnfoList, and barring the rest). A simple security measure, which could be perhaps mandatory in any Remote Access scenario. If we take this simple scenario in our earlier Virtualization model, perhaps we could be replicating multiple resources for this very generic functionality itself. Some of the salient features in the above model are as follows: • AccessControl model of implementing a security when a user remotely accesses a Home Network • Although we have tried to describe a single AccessControl Service in the description above, this shouldn't prove to be a hurdle if someone wants to have a distributed model wherein we have multiple instances of AccessControl Servers in a Home Network as well • These filters could be defining ACLs of multiple types - such as the Devices, Services, Actions, Content, etc. • The implementation of the Virtualization is for enhancing the Services provided by Devices in a Home Network for those accessing remotely, which could be further enhanced by understanding the Remote-CP's capabilities, like the rendering for instance. All this requires the desired routing intelligence to be presented from this Service. • A security model built into the system when a Remote Client requests access based on a particular URL - this shall be "authenticated by the AccessControl Service" before it tries accessing any Device in a Home Network (else its easy for the Remote Client to hoodwink the RAS Device, specifying URLs which weren't authorized by the Remote Access Administrator)[0] • All of the above features have been achieved without any modification in the current UPnP-Devices, hence supporting all legacy Devices should be easy ADVANTAGES The advantages of this invention are as follows: 1. RAS has a single entry point for performing stuff related to access control - being provided by the AccessControl Service 2. A single point for the Remote Access Administrator for configuring ACLs of various Remote Users - on the Device providing AccessControl Service 3. AccessControl Service has the flexibility to reside on any Device in the Home Network (including RAS Device itself) - it needs to maintain a simple database regarding the access control policy for all the devices accessing the Home Network from a remote location . RAS shall automatically detect an AccessControl Service within the Home Network, just like any other Service in a UPnP Home Network . If there are more than one AccessControl Devices in the Home Network, RAS could base it on the first SSDP it receives. Or any other policy if an implementer so desires, or also the Remote Access Administrator could decide which ACL shall be the valid one for the Home Network. We could also consider distributed AccessControl Services in the Home Network, if someone desires to have it that way The simplification provided for a Remote Client for using Virtualizers in the Home Network to help serve them better in a way compatible to it shall be taken care by the AccessControl Service. So all that the Remote Client needs to know is access a piece of content for instance, rather than worrying about its format, etc. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart therefrom. GLOSSARY OF TERMS AND DEFINITIONS THEREOF ACL AccessControl List CP Control Point DCP Device Control Protocol DDD Device Description Document (of UPnP) HN Home Network IP Internet Protocol IPSec IP security - a suite of protocols for securing IP communications by authenticating and/or encrypting each IP packet in a data stream LAN Local Area Network Remote Client A device remotely accessing a Home Network (equivalent to a Remote-CP, or Remote-CP+RAC in some situations) RG Residential Gateway SSDP Simple Service Discovery Protocol UPnP Universal Plug & Play VPN Virtual Private Network - is a private communications network often used by organizations to communicate confidentially over a public network In the context of Figure 2 : AxsCtrl AccessControl Service Vendor Virt a vendor-specific Virtualizer (usually provided by the Device vendor) Generic Virt a generic Virtualizer (Device vendor or any third-party vendor) RAC Remote Access Client RAS Remote Access Server RADA Remote Access Discovery Agent Remote Access Administrator- owner of the Home Network, takes care of everything related to RA R-User a Remote User's (a person who accesses a given Home Network from outside, over the Internet) access control list, maintained by the AccessControl Service Remote-CP remotely accessing control point, a UPnP client device located Sfctside of the UPnP Network that utilizes the Services provided by the Devices in a Home Network Device a device in the context of UPnP that provides some kind of Service within its Network device a device in the normal sense Device!nfoList A list shared by the RAS to the RACs about the Devices in a Home Network, their Services, etc. (ideally an XML-based representation) Reference: [1] UPnP Device Architecture [2] Shrikant K. "A method of optimizing UPnP's discovery process for remote access", 2006 CLAIM 1. A method for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network comprising the steps of: i) Remote Access Administrator giving access permissions to the Remote Users who could access Devices in the Home Network; ii) the Device providing AccessControl Service shall advertise itself within the Home Network; iii) Remote Access Administrator configuring the aggregated Device Description Documents (DDD) for each of the Remote User who could access the Home Network; iv) including an access control model to provide access for the Remote Users accessing the Home Network, after going through a process of verification; v) incorporating virtualizers, that is a resource which enhances the features provided by a given Device in a Home Network to suit the capabilities of the Remote Client device; and vi) performing an automated routing based on the capabilities of the Remote User's device capabilities, over the Virtualizer devices. 2. A method as claimed in claim 1 wherein Access Control Device gather all the SSDP info that is being advertised by various UPnP Devices in a Home Network. 3. A method as claimed in claim 1 wherein Access Control Device advertises (SSDP) about its Service within the Home Network. 4. A method as claimed in claim 1 wherein a RAS Device respond to the Residential Gateway and utilize its Services. 5* A method as claimed in claim 1 wherein the Remote-CPs access Devices in the Home Network, also providing description about their respective device capabilities to the RADA. 6. A method as claimed in claim 1 wherein the Remote Access Administrator include Remote Client's capabilities during the setup process, when configuring the access control privileges on the AccessControl Device for that particular Remote Client device. 7. A method as claimed in claim 1 wherein multiple devices are adopted to act as the AccessControl Devices in the Home Network, maintaining replica of the configuration info of the remote RACs, and where the AccessControl Device from which the RAS receives the SSDP first is considered as the reference (or other equivalent approaches). 8. A method as claimed in claim 1 wherein if the distributed AccessControl information is scattered across certain set of Devices then the RAS is configured to consider them accordingly, i.e. the RADA needs to consider them all in such a situation. 9. A method as claimed in claim 1 wherein an application module is used for configuring the access privileges on an AccessControl Device. 10. A method as claimed in claim 1 wherein service-based-filters are used in the said method. 11 A method as claimed in claim 1 wherein action-based-filters are used in the said method. r A method as claimed in claim 1 wherein content-based-filters are used when media/ data being accessed across. . A method as claimed in claim 1 wherein when the RAS exposes Devices, Services, Actions and/or Content (by means of SSDP) to a Remote Client, depending on the access privileges configured by the Remote Access Administrator. A method as claimed in claim 1 wherein when a Remote Client tries to access over the Residential Gateway and the RAS, and the RAS Device understands the presence of a Device in its Home Network that's providing the AccessControl Service based on the SSDP adverts it receives. A method as claimed in claim 1 wherein the RAS consult with the AccessControl Service and re-check for the Remote Client's privileges before providing the access to the specific Device within a Home Network. A method as claimed in claim 1 wherein based on the Remote Clients capabilities, the AccessControl Device route the request through the appropriate Virtualizer, before accessing the actual Device. A system for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network. A method for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network substantially described and explained with reference to the drawings. 19. A system for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network substantially described and explained with reference to the drawings. Dated this the 11th day of April 2007

Full Text

lELD OF INVENTION
This invention relates to the field of Home Networking technology, and particularly to those utilizing the Universal Plug and Play (UPnP) as their preferred approach. Nonetheless, it applies equally to approaches similar to the UPnP. More specifically, it relates to a method and system that enhances the Services provided by UPnP Devices in a Home Network, when accessed across from a remote location, with respect to the access control model.
DESCRIPTION OF RELATED ART
A typical UPnP-Remote Access Device model featuring the Remote Clients (which includes both Remote Access Clients & Remote-CPs) accessing the Devices in a Home Network (providing their respective Services) over the Residential Gateway (RG) could be as illustrated in Figure 1.
The application WO2006088592A1 describes a method and a system for data routing, management and associated applications. The system includes a host server that facilitates delivery of content between a Home Network node (for e.g., PC, web camera) and a remote network access appliance (for e.g., a mobile phone). The application describes an authentication mechanism to verify the authenticity of the remote access appliance. The authentication mechanism is used to identify if the remote access appliance has appropriate rights to access the data at the Home Network node. Also, the mechanism may be used to limit access to specific portions of the data. Further, characteristics of the remote access appliance are also considered for granting access to the appliance. For example, music data requested by the remote access appliance may be formatted in a particular audio format for which the appliance is adapted to play the audio data.
But the application fails to describe the following concepts:
• An approach specific to prevalent Home Networking standards, like the UPnP - which have a means to discover Devices & their respective

Services
• Access rights to content are based on an XML approach that UPnP follows & it is not limited to just media content
• A distributed access control model with multiple instances of the AccessControl Servers within a Home Network, with different options to base this model on
• Validating the Remote User accessing the Devices in the Home Network based on a set of preset filters by the Remote Access Administrator
• Intelligent routing and automatic conversion of data format based on the capabilities of the Remote device, through the use of Virtualizers (distributed across in a Home Network)
SUMMARY OF THE INVENTION
Specific to the Home Networks, and applies appropriately for the UPnP technology. Here we mainly are concerned with the mechanism of remotely accessing Devices (i.e. from outside the home) & their respective Services that are found within a Home Network.
UPnP has increased importance in becoming the standard for Home Networking. UPnP however was designed to be used within a private Home Network area, with no consideration for accessing home devices remotely, say over the public Internet or from another home.
Internet enables devices to connect remotely, using various technologies to do it securely too (like the VPN, IPSec, etc.). Utilizing the Internet and the UPnP, users could access content available within a home, control devices and utilize other Services in a home from anywhere, and at anytime. Such combination provides great convenience for homeowners, extending the boundaries of their Home Network. For example, parents can now access their home surveillance camera, and perhaps monitor their little ones at home, while away from home. This invention describes methods and apparatus that enhance Services provided by UPnP

devices in a Home Network when accessed across from a remote location, over the Internet.
Accordingly, this invention explains a method for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network comprising the following steps:
• Remote Access Administrator gives access permissions to the Remote Users who could access Devices in the Home Network
• the Device providing AccessControl Service shall advertise itself within the Home Network, in the usual UPnP way
• Remote Access Administrator configures the aggregated Device Description Documents (DDD) for each of the Remote User who could access the Home Network
• includes an access control model to provide access for the Remote Users accessing the Home Network, after going through a process of verification
• incorporates Virtualizers, that is a resource which enhances the features provided by a given Device in a Home Network to suit the capabilities of the Remote Client device
• performing an automated routing based on the capabilities of the Remote User's device capabilities, over the Virtualizer devices
These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 shows the UPnP's Remote Access Device Model & the AccessControl
Service
Figure 2 shows the UPnP-RA Device Model & the AccessControl Service with
Virtualization
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However, in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
Atypical UPnP-Remote Access Device model featuring the Remote Clients (which includes both Remote Access Clients & Remote-CPs) accessing the Devices in a Home Network (providing their respective Services) over the Residential Gateway (RG) could be as illustrated in Figure 1.
Figure 2 illustrates the utilization of the AccessControl model in the context of remotely accessing clients into a Home Network that incorporate Virtualizers in their path. A Virtualizer is a Device responsible for enhancing or converting the features exposed by the original Devices in a Home Network. The AccessControl Service could also provide necessary intelligence with respect to the Remote Client device's capabilities, which could be taken care by the Devices present within a Home Network. Do note the routings based on the Remote Client device's

capabilities in the figure, and as given below:
Devicel > Vendor Virtl > R-User1 > RAS > RG > RAC > Remote-CP1
Devicel > Generic Virt2 > R-User2 > RAS > RG > RAC > Remote-CP2
Device2 > Generic Virt2 > R-User3 > RAS > RG > RAC > Remote-CP3
Device2 > R-User4 > RAS > RG > RAC > Remote-CP4
i) Devices in the UPnP normally offer Services
ii) Virtualizers are also UPnP-Devices, whose Services are primarily
consumed during the process of Remote Access iii) AccessControl Device is a UPnP-Device that provides a Service
for controlling the privileges of all Remote Clients accessing the
Devices/Services within a Home Network iv) Remote Access Server (RAS) is a UPnP-Device providing many
Services, one of them being the Remote Access Discovery Agent
(RADA) Service for passing the UPnP's Discovery information in
the Home Network to the Remote Access Client (RAC) Device v) The RAC device also has a similar RADA Service component for
synchronizing the Device Discovery information with the RAS
Device vi) Residential Gateway (RG) is a Device, that provides the UPnP's
Internet Gateway Device (IGD) Service for the Devices in the
Home Network's LAN for accessing over into the WAN vii) Remote-CP is a UPnP-Control Point that is remotely located
behind the RAC device. The RAC device is a logical Device, and
could be present within the same physical device as the
Remote-CP itself too.
In this invention, we primarily concentrate on two aspects within a UPnP-like Home Network that is being remotely accessed by certain UPnP Clients,

perhaps over the Internet.
The first is related to the access control capabilities for all the devices remotely accessing a Home Network, its Devices & utilizing their respective Services. The access control mechanism is responsible for both (i) firstly, exposing only what needs to be accessible for the Remote Client with respect to the Devices, Services, Actions, Content, etc. (ii) secondly, its also responsible for doing a double-check during the actual process of access itself, just to avoid Remote User from hacking into Devices which he isn't supposed to access as he wasn't given the necessary permissions by the Remote Access Administrator.
The other feature is concentrated around the process of Virtualizing the features provided by a Device in a UPnP-like Home Network to a Remote Client accessing it. The Remote Client is merely interested in utilizing a Service rather than understanding the intricacies about which Device is specifically offering this Service. Virtualization could be with respect to any aspect/feature in a Home Networking environment. The process followed here is to cloud the original Device's capabilities and expose a Virtualizer instead to the Remote Client, to bring in enhanced features comparatively that suit the Remote Client's capabilities.
For exact definition of some of the terms used in the explanation below, please refer to the glossary.
The access control process is as follows:
As a Remote Access Administrator, one is usually interested to provide an access control mechanism for his/her Devices, Services, Actions, etc. within a Home Network, thus providing the necessary restricted access to the Remote Users entering the Home Network.
As part of provisioning these above requirements, the AccessControl Device need not necessarily have knowledge about each of the

Devices/Services specifically, i.e. with respect to its Device Control
Protocol (DCP) as defined in the UPnP specification. It could perform a
simple XML-based filtering, on the SSDP information that it would receive
from each of the Devices in a Home Network [the AccessControl Device
here is acting as a "UPnP-ControlPoint" in this context, gathering all the
SSDP info that is being advertised by various UPnP Devices in a Home
Network].
AccessControl Device shall advertise about its Service within the Home
Network just as any other UPnP-Device [while at this point, it is taking the
role of an "UPnP-Device"], using the traditional SSDP means.
The RAS Device shall respond to the AccessControl's SSDP, and shall
utilize its Services. Other Control Point devices within the Home Network
although receiving this SSDP, would not be interested in this particular
Service from AccessControl Device, and shall ignore it.
AccessControl Service only needs to understand that there is a DDD for
each of the UPnP-Devices within the Home Network, upon which it
needs to apply certain filters, transformations, etc., which is configured
specifically for each of the Remote Users, by the Remote Access
Administrator.
The Remote-CPs shall access Devices in the Home Network. As part of
the access methodology, the Remote-CPs shall also provide a
description about their respective device capabilities. This kind of
information is not part of the conventional UPnP messaging, but could be
easily incorporated in order to provide the extra benefits during Remote
Access, dynamically.
Or, the other option could also be that the Remote Access Administrator
could include these Remote Client's capabilities during the setup process,
i.e. when it is configuring the access control privileges on the
AccessControl Device for that particular Remote Client device (this is a
static way of doing the above, and perhaps wouldn't take care of any
upgrades possible on the remote side).
Since AccessControl plays an important role in the whole process of

remote access, having a backup helps. We could have more than one device acting as the AccessControl Device in the Home Network, maintaining replica of the configuration info of the remote RACs. In this scenario, the AccessControl Device from which the RAS receives the SSDP first shall be considered as the reference (or we could have any other overriding mechanisms also that could be incorporated in some cases).
The other option is that of distributed AccessControl information scattered across certain set of Devices. In which case the RAS needs to be configured to consider them all appropriately. A simple application for configuring the access privileges on an AccessControl Device should be present. The configuration could mainly consist a matrix of elements - the list of Devices, the Services that each of them provide, and their list of Actions respectively. All this may be defined for each of the Remote Users, by means of a simple checklist perhaps that could specify if they have access or not against each of them.
We could include Content-based-filters in certain situations, wherein we have media/data being accessed across. This shall work in coordination with certain Services, like the Content Directory Service (CDS) for example, which is involved in listing media content available in a UPnP-Device. The Remote User could be restricted on certain type of audio or video, based on the Type, Title, etc. which shall be one of the configurables for a particular Remote Client accessing this Home Network.
When the RAS is exposing the list of Devices, Services, Actions, Content to a Remote Client, it shall appropriately modify the SSDP based on the access privileges configured by the Remote Access Administrator for it specifically. The SSDP in this case is unique to each of the Remote Clients, and the RAS shall be responsible for this modification and reconstruction of SSDP structure appropriately, taking necessary inputs from the AccessControl Device. [2]

When a Remote Client tries to access over the Residential Gateway & the RAS, the RAS Device needs to understand that there is a Device in its Home Network providing the AccessControl Service (based on the SSDP adverts it received previously). The RAS shall consult with the AccessControl Service and re-check for the Remote Client's privileges before providing the necessary access to the specific Device in the Home Network.
Based on the Remote Client's capabilities (refer to points 6 and 7), the AccessControl Device shall route the request through the appropriate Virtualizer.
Virtualizers provide extra features atop the original UPnP-Devices, those that were not originally present with these Devices. In Figure 2, for instance if there were Generic-Virtualizers like the transcoders for instance, this shall certainly benefit a Remote User. The Generic-Virtualizer features shall be termed "Virtual Feature" and its Services as "Virtual Service" here on in this document.
For example, a Virtual Feature could be an MPEG2-to-H.264 transcoding, which shall provide this Virtual Service to all Devices hosting MPEG2 content within the Home Network, and which are accessed by all Remote-CPs supporting H.264 rendering capabilities. Another Virtualizer Service could be for providing a Virtual Feature like MPEG2-to-DivX transcoding, this also applies on to the same set of Devices, but applies when a Remote-CP is capable of supporting DivX rendering instead. The requirement here is the routing necessary for making it all happen, based on the specific requirement of the Remote-CP's capabilities, although applied for the same set of Devices in the Home Network - which is being applied by the AccessControl Device as it has a prior understanding of the Remote Client's capabilities.
The other type of Virtualizers are those specific to a particular Device, termed here as the Vendor-specific-Virtualizers. These are coupled with their respective Devices only (also illustrated in Figure 2). The only difference in this case being

that they are very specific, and ideally provided by the manufacturer of the Device itself Unlike the Generic-Virtualizers which can be provided by any third-party vendor too, as they are based on open standards. This should not restrict these Devices to get routed over the Generic-Virtualizers whenever necessary (as illustrated in Figure 2 for Remote-User-2; the Device-1 had a Vendor-specific-Virtualizer). Building the Device-to-Virtualizer relationship is the responsibility of the AccessControl Device, which decides this routing based on the Remote Client's capabilities.
Finally, we could always have the normal scenario wherein a Remote-CP accesses a UPnP Device directly, if they find the desired compatibility perhaps. For example, a Remote-CP that has MPEG-2 rendering capabilities accessing an MPEG-2 Device, without using any of the Virtual Services (illustrated in Figure 2, with Remote-User-4).
We can apply multiple Virtualizers too in the path, including a combination of vendor-specific & the generic ones. A simple example here could be a UPnP-Device that is serving MPEG2 content, while the Remote Client is capable of rendering DivX format. And we have two Virtualizers in the Home Network - a MPEG2-to-H.264 transcoder & a H.264-to-DivX transcoder. In this scenario, the AccessControl Device shall appropriately route the content through both these transcoders, giving content in the DivX format, which is compatible for the Remote Client's capabilities.
Keeping the common aspect of access control on the particular Device as an independent entity gives us the flexibility in designing, wherein we give the various Services packaged into the Home Network. How they get connected dynamically is based on the capabilities of the Remote Client.
The AccessControl Service holds the modified URLs for the UPnP-Devices and/or Virtualizer-UPnP-Devices, based on SSDP/DDD it receives and maintains. The RADA exposes a unique DevicelnfoList for each of the Remote

Clients specifically. But it is the responsibility of the AccessControl to manage these lists specifically for each of the Remote Clients, based on the Remote-CP's capabilities, received either during login phase or as was pre-configured.
Understanding the Remote-CP's capabilities is the crux, which can be addressed in the following ways:
1. For a simple scenario - this kind of information is not coming part of the standard UPnP messaging, hence it is best addressed by the user during the process of logging into the Home Network. In our example above, if the Remote-CP is consuming a particular content, it should mention the media format that is compatible for it. This information about the Remote-CP shall be maintained until the end of the session by the RAS. And when he re-logs into the Home Network next time he could always come in with a Remote-CP having different capabilities too (as we consider the RAC as an independent entity to the Remote-CP for giving such a flexibility to the Remote Users).
2. For a more complete scenario - we could rather expose the same Device as multiple Devices, based on the number of Virtualizers attached to it. And Remote-CP chooses the one its compatible to it, based on its own rendering capabilities. All this becomes part of the DevicelnfoList exposed over the RADA to the Remote-CP.
The other important aspect is that the AccessControl scans all requests from Remote-CP each time they hit the RAS, before they can go any further accessing the DeviceA/irtualizer in a Home Network. As a consequence, even if the Remote-CP tries to give an "invalid URL" this shall be declined as an invalid link by the AccessControl (i.e. its only allowing the URLs specified in the DevicelnfoList, and barring the rest). A simple security measure, which could be perhaps mandatory in any Remote Access scenario. If we take this simple scenario in our earlier Virtualization model, perhaps we could be replicating multiple resources for this very generic functionality itself.

Some of the salient features in the above model are as follows:
• AccessControl model of implementing a security when a user remotely accesses a Home Network
• Although we have tried to describe a single AccessControl Service in the description above, this shouldn't prove to be a hurdle if someone wants to have a distributed model wherein we have multiple instances of AccessControl Servers in a Home Network as well
• These filters could be defining ACLs of multiple types - such as the Devices, Services, Actions, Content, etc.
• The implementation of the Virtualization is for enhancing the Services provided by Devices in a Home Network for those accessing remotely, which could be further enhanced by understanding the Remote-CP's capabilities, like the rendering for instance. All this requires the desired routing intelligence to be presented from this Service.
• A security model built into the system when a Remote Client requests access based on a particular URL - this shall be "authenticated by the AccessControl Service" before it tries accessing any Device in a Home Network (else its easy for the Remote Client to hoodwink the RAS Device, specifying URLs which weren't authorized by the Remote Access Administrator)[0]
• All of the above features have been achieved without any modification in the current UPnP-Devices, hence supporting all legacy Devices should be easy
ADVANTAGES
The advantages of this invention are as follows:
1. RAS has a single entry point for performing stuff related to access control - being provided by the AccessControl Service
2. A single point for the Remote Access Administrator for configuring ACLs of various Remote Users - on the Device providing AccessControl Service
3. AccessControl Service has the flexibility to reside on any Device in the

Home Network (including RAS Device itself) - it needs to maintain a simple database regarding the access control policy for all the devices accessing the Home Network from a remote location
. RAS shall automatically detect an AccessControl Service within the Home Network, just like any other Service in a UPnP Home Network
. If there are more than one AccessControl Devices in the Home Network, RAS could base it on the first SSDP it receives. Or any other policy if an implementer so desires, or also the Remote Access Administrator could decide which ACL shall be the valid one for the Home Network. We could also consider distributed AccessControl Services in the Home Network, if someone desires to have it that way The simplification provided for a Remote Client for using Virtualizers in the Home Network to help serve them better in a way compatible to it shall be taken care by the AccessControl Service. So all that the Remote Client needs to know is access a piece of content for instance, rather than worrying about its format, etc.
It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device.
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart therefrom.

GLOSSARY OF TERMS AND DEFINITIONS THEREOF
ACL AccessControl List
CP Control Point
DCP Device Control Protocol
DDD Device Description Document (of UPnP)
HN Home Network
IP Internet Protocol
IPSec IP security - a suite of protocols for securing IP communications by
authenticating and/or encrypting each IP packet in a data stream
LAN Local Area Network
Remote Client A device remotely accessing a Home Network (equivalent
to a Remote-CP, or Remote-CP+RAC in some situations)
RG Residential Gateway
SSDP Simple Service Discovery Protocol
UPnP Universal Plug & Play
VPN Virtual Private Network - is a private communications network often used by
organizations to communicate confidentially over a public network
In the context of Figure 2 :
AxsCtrl AccessControl Service
Vendor Virt a vendor-specific Virtualizer (usually provided by the Device vendor)
Generic Virt a generic Virtualizer (Device vendor or any third-party vendor)
RAC Remote Access Client
RAS Remote Access Server
RADA Remote Access Discovery Agent
Remote Access Administrator- owner of the Home Network, takes care of
everything related to RA
R-User a Remote User's (a person who accesses a given Home Network
from outside, over the Internet) access control list, maintained by the AccessControl
Service
Remote-CP remotely accessing control point, a UPnP client device located

Sfctside of the UPnP Network that utilizes the Services provided by the Devices in a
Home Network
Device a device in the context of UPnP that provides some kind of Service
within its Network
device a device in the normal sense
Device!nfoList A list shared by the RAS to the RACs about the Devices in
a Home Network, their Services, etc. (ideally an XML-based representation)
Reference:
[1] UPnP Device Architecture
[2] Shrikant K. "A method of optimizing UPnP's discovery process for remote
access", 2006

CLAIM
1. A method for access control and automation for a Remote Client accessing a
Virtualized UPnP Home Network comprising the steps of:
i) Remote Access Administrator giving access permissions to the
Remote Users who could access Devices in the Home Network; ii) the Device providing AccessControl Service shall advertise itself
within the Home Network; iii) Remote Access Administrator configuring the aggregated Device
Description Documents (DDD) for each of the Remote User who
could access the Home Network; iv) including an access control model to provide access for the
Remote Users accessing the Home Network, after going through
a process of verification; v) incorporating virtualizers, that is a resource which enhances the
features provided by a given Device in a Home Network to suit the
capabilities of the Remote Client device; and vi) performing an automated routing based on the capabilities of the
Remote User's device capabilities, over the Virtualizer devices.
2. A method as claimed in claim 1 wherein Access Control Device gather all the SSDP info that is being advertised by various UPnP Devices in a Home Network.
3. A method as claimed in claim 1 wherein Access Control Device advertises (SSDP) about its Service within the Home Network.
4. A method as claimed in claim 1 wherein a RAS Device respond to the Residential Gateway and utilize its Services.

5* A method as claimed in claim 1 wherein the Remote-CPs access Devices in the Home Network, also providing description about their respective device capabilities to the RADA.
6. A method as claimed in claim 1 wherein the Remote Access Administrator include Remote Client's capabilities during the setup process, when configuring the access control privileges on the AccessControl Device for that particular Remote Client device.
7. A method as claimed in claim 1 wherein multiple devices are adopted to act as the AccessControl Devices in the Home Network, maintaining replica of the configuration info of the remote RACs, and where the AccessControl Device from which the RAS receives the SSDP first is considered as the reference (or other equivalent approaches).
8. A method as claimed in claim 1 wherein if the distributed AccessControl information is scattered across certain set of Devices then the RAS is configured to consider them accordingly, i.e. the RADA needs to consider them all in such a situation.
9. A method as claimed in claim 1 wherein an application module is used for configuring the access privileges on an AccessControl Device.
10. A method as claimed in claim 1 wherein service-based-filters are used in the said method.
11 A method as claimed in claim 1 wherein action-based-filters are used in the said method.

r A method as claimed in claim 1 wherein content-based-filters are used when media/ data being accessed across.
. A method as claimed in claim 1 wherein when the RAS exposes Devices, Services, Actions and/or Content (by means of SSDP) to a Remote Client, depending on the access privileges configured by the Remote Access Administrator.
A method as claimed in claim 1 wherein when a Remote Client tries to access over the Residential Gateway and the RAS, and the RAS Device understands the presence of a Device in its Home Network that's providing the AccessControl Service based on the SSDP adverts it receives.
A method as claimed in claim 1 wherein the RAS consult with the AccessControl Service and re-check for the Remote Client's privileges before providing the access to the specific Device within a Home Network.
A method as claimed in claim 1 wherein based on the Remote Clients capabilities, the AccessControl Device route the request through the appropriate Virtualizer, before accessing the actual Device.
A system for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network.
A method for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network substantially described and explained with reference to the drawings.

19. A system for access control and automation for a Remote Client accessing a Virtualized UPnP Home Network substantially described and explained with reference to the drawings.
Dated this the 11th day of April 2007

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=6Kjs/N0vFOf1nE2Fyw1KrA==&loc=egcICQiyoj82NGgGrC5ChA==

« Previous Patent

Next Patent »

Patent Number

269626

Indian Patent Application Number

762/CHE/2007

PG Journal Number

45/2015

Publication Date

06-Nov-2015

Grant Date

29-Oct-2015

Date of Filing

11-Apr-2007

Name of Patentee

SAMSUNG R&D INSTITUTE INDIA-BANGALORE PRIVATE LIMITED

Applicant Address

#2870 ORION BUILDING BAGMANE CONSTELLATION BUSINESS PARK OUTER RING ROAD DODDANEKUNDI CIRCLE MARATHAHALLI POST BANGALORE 560037

Inventors:

#	Inventor's Name	Inventor's Address
1	SHRIKANT KANAPARTI	BAGMANE LAKEVIEW BLOCK B NO 66/1 BAGMANE TECH PARK CV RAMAN NAGAR BYRASANDRA BANGALORE560093

PCT International Classification Number

G06F15/16

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA