GB2550971A - Method and system for managing access to a media sample captured at a first site by a movable camera - Google Patents

Abstract

A media sample (e.g. a photograph or video surveillance footage), is captured 301 at a first site by a movable camera and stored within the camera. The media sample is associated 304 with a first site indication (e.g. the geographical location of the camera). When the camera is moved to a second location, the media sample remains tagged with the first site indication. An access request is received 305 for accessing media samples captured at the first site, the access request comprising user identification data 306. Based on access rights 308 associated with the identification data, the user is authorised 310 to access the media sample stored in the mobile camera now at the second site. The camera may be part of a network of cameras comprising a master camera which is responsible for generating the site indication.

Description

METHOD AND SYSTEM FOR MANAGING ACCESS TO A MEDIA SAMPLE CAPTURED AT A FIRST SITE BY A MOVABLE CAMERA

FIELD OF THE INVENTION

The present invention relates in general to the management of access to media content in network cameras of multi-camera networking systems. In particular, the present invention is directed to a method and a system for managing access to a media sample captured at a first site by a movable camera.

BACKGROUND OF THE INVENTION

In some contexts, it is profitable to share media contents (e g. photographs, videos) recorded by a camera with other devices or between several users of these devices.

In a first exemplary context, live events such as concerts, public speeches or family events are considered. In such events, several photographs of the same object may be taken by several photographers, for instance from a similar perspective. However, the quality of the photographs may vary depending on the cameras and also depending on the conditions of the capture. In such a context, it may be advantageous to allow other photographers to easily retrieve the best photograph (e.g. with the best quality or taken from the best point of view) taken for the object of shared interest.

In a second exemplary context, distributed and decentralized video surveillance systems of transportable network cameras are considered. For instance, network cameras may be set up inside a building during the day while they may be set up outside during the night, in order to monitor a construction work area (worksite) located just in front of the building. The network cameras belong to the same video surveillance system but monitor different sites at different time. In this case, the proprietor of the building may want to provide the worksite manager with access to videos recorded in the video surveillance system. Hence, the worksite manager will have access to video samples recorded at the worksite but also to video samples recorded earlier by the same cameras located inside the building, which may cause confidentiality issues.

In general terms, the video surveillance system may be managed by different users of different sites. In order to allow a posteriori forensic analysis (or other post-processing of recorded images), access to video samples recorded at a first site must be granted to users of this first site. On the other hand, in order to preserve confidentiality of image data captured at the first site, users of a second site must not have access to these recorded videos.

In such video surveillance or photo sharing contexts, access rights of media content are provided to users on a device-by-device basis: if the users obtain access rights to a particular device, they can access all the contents recorded in this device.

Document US 9,077,863 is directed to a system comprising cameras located at fixed positions. This system is based on access rights granted to a mobile device for accessing videos recorded by the cameras located in the neighborhood of this mobile device. The access is thus granted based on the position of the mobile device compared to the position of the cameras.

However, due to security and privacy issues, this solution is not adapted to systems comprising cameras whose position changes over time. For instance, when a same camera is used for taking photographs during a family event occurring in a house and then during a professional event occurring in a business center, it is not desirable that the participants in the professional event have access to the photographs of the family event thanks to their proximity to the camera that recorded both events.

Consequently, there is a need for improving the security and privacy of media content recorded by a camera whose position may change over time when other devices are provided with access to it.

SUMMARY OF THE INVENTION

The present invention has been devised to address one or more of the foregoing concerns.

According to a first aspect of the invention, there is provided a method for managing access to a media sample, the media sample being captured at a first site by a movable camera and stored within the movable camera, the method comprising: - associating the media sample with a first site indication, thereby when the movable camera is moved to a second site different from the first site, the media sample remains associated with the first site indication; obtaining an access request for accessing media samples captured at the first site, the access request comprising identification data identifying a user; authorizing or not authorizing, based on access rights associated with the identification data, the user to access the media sample stored in the movable camera now at the second site.

Therefore, the method of the invention makes it possible to improve the security and privacy of recorded media samples, in particular when a camera is moved from a first location to a second location, while these captured media samples are still accessible to authorized users (a user is a person which is interacting with the camera or any client device with or without media capture means) and devices (camera or any other networking device capable of connecting to the system). The solution provided is thus adapted to systems comprising cameras whose position changes over time.

The media samples are associated with the first site at which they were captured. Even if the camera storing these media samples moves from this first site to a second site, the media samples are still associated with the first site. Hence, a user which has access rights to access the media samples captured at the second site but not the media samples captured at the first site is not authorized to access the media samples associated with the first site even if they are stored in the camera currently at the second site. Also, a user having access to media samples captured at a first site is still capable of playing them after the camera is moved to a second site, even if the user does not have access to the media samples that will be captured at the second site.

Optional features of the invention are further defined in the dependent appended claims.

The first site indication indicates conditions in which the media sample was recorded in the first site.

According to embodiments, the first site indication is based on a geographical position of the movable camera at the first site.

Hence, access rights to the media sample may be set according to the geographical position of the capture.

According to embodiments, the first site indication comprises information about networks accessible to the movable camera.

For example, it is possible to set access rights to the media sample based on the position of the capture, even if there was no GPS coverage at the time of the capture. Indeed, the knowledge of accessible networks provides position information.

According to embodiments, the first site indication is based on identifiers of cameras forming a multi-camera networking system with the movable camera.

According to embodiments, the first site indication is based on a capture timestamp associated with the media sample, and access to the media sample is authorized depending on the timestamp.

Advantageously, different access rights may be set for different moments of the day (e.g. morning, evening).

According to embodiments, the first site indication results from the following steps: computing a table of local context indications comprising an identifier of each camera of a multi-camera networking system to which the movable camera belongs and a local context indication associated with each identifier; selecting a subset of cameras of the multi-camera networking system based on the table of local context indications and a selection criterion, the selected subset defining a site; generating a site indication for the site, based on the local context indications associated with the cameras of the subset.

An advantage of an automatic generation of the site indication is that the site indication is always adapted to the current context and does not depend on the vigilance of the installer and thus the management of user access rights is more efficient.

Alternatively, the site indication could be manually set by the camera owner or installer. In this case, when the installer modifies the capture conditions of the camera system, the site indication is also modified by hand. The advantage of this solution is that the setup is very simple and may be entirely controlled by the installer.

According to embodiments, access rights for accessing media samples are based on the site indication generated for the site where the media samples were captured.

The present invention is compliant with several types of system configuration: centralized, semi-centralized or distributed systems.

According to embodiments, the method further comprises a step of electing a master camera from among the cameras of the multi-camera networking system, for generating the site indication.

According to embodiments, the media sample captured at a given site is encrypted with an encryption key based on the associated site indication or an encryption key common to all the media samples captured in any site by the movable camera.

Thus, even if a non-authorized user may obtain the encrypted media sample, the user cannot have access to an unencrypted version of the media sample. Hence, the security of media sample is improved.

According to embodiments, the method further comprises: capturing another media sample at the second site by the movable camera and storing it in the movable camera; associating the other media sample with a second site indication; obtaining an access request for accessing media samples captured by the movable camera, the access request comprising identification data identifying a user; authorizing or not authorizing, based on access rights associated with the identification data, the user to access the media sample captured at the first site and/or the other media sample captured at the second site by the movable camera.

For instance, the second site indication results from the following steps: computing a table of local context indications comprising an identifier of each camera of a multi-camera networking system to which the movable camera belongs and a local context indication associated with each identifier; selecting a subset of cameras of the multi-camera networking system based on the table of local context indications and a selection criterion, the selected subset defining a site; generating a site indication for the site, based on the local context indications associated with the cameras of the subset.

The second site indication indicates conditions in which the media sample was recorded in the second site.

According to a second aspect of the invention, there is provided a system for managing access to a media sample, the media sample being captured at a first site by a movable camera and stored within the movable camera, the system being configured for: associating the media sample with a first site indication, thereby when the movable camera is moved to a second site different from the first site, the media sample remains associated with the first site indication; obtaining an access request for accessing media samples captured at the first site, the access request comprising identification data identifying a user; authorizing or not authorizing, based on access rights associated with the identification data, the user to access the media sample stored in the movable camera now at the second site.

The second aspect of the present invention has optional features and advantages similar to the first aspect above-mentioned.

There is also provided a device or system for managing access to a media sample, the media sample being captured at a first site by a movable camera of a multi-camera networking system and stored within the movable camera, the device or system being configured for: - associating the media sample and the movable camera with a first site indication; - when the movable camera is moved to a second site different from the first site, replacing the first site indication associated with the camera by a second site indication, the media sample being still associated with the first site indication; - obtaining an access request for accessing media samples captured at the first site, the access request comprising identification data identifying a user; - authorizing or not authorizing, based on access rights associated with the identification data, the user to access the media sample stored in the movable camera now associated with the second site indication.

The present invention is also directed to a system substantially as hereinbefore described with reference to, and as shown in Figure 1, a method substantially as hereinbefore described with reference to, and as shown in Figures 3 to 5, and a device substantially as hereinbefore described with reference to, and as shown in Figures 1, 2 and 6.

Since the present invention may be implemented in software, the present invention may be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium, and in particular a suitable tangible carrier medium or suitable transient carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device or the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1 illustrates a multi-device networking system in which embodiments of the invention may be implemented;

Figure 2 is a block diagram illustrating modules of a movable camera of the multi-device networking system shown in Figure 1, in which steps of one or more embodiments may be implemented ;

Figure 3 is a flowchart illustrating general steps of a method for managing access to a media sample according to embodiments;

Figure 4 is a flowchart illustrating steps for computing a new site indication according to embodiments;

Figure 5 is a flowchart illustrating steps for creating a new site according to embodiments;

Figure 6 is a block diagram representing an exemplary architecture of a processing device in which steps of one or more embodiments may be implemented.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

In the following description, a system comprising a plurality of interconnected network cameras is considered. Other network devices may join this networking system, for instance mobile phones.

According to general embodiments, a media sample is recorded at a first site by a movable camera of a multi-camera networking system. This media sample is associated with a first site indication, indicating conditions in which the media sample was recorded. When the movable camera is moved from a first site to a second site different from the first one, it may record another media sample at this second site. This new media sample is associated with a second site indication, indicating conditions in which this other media sample was recorded.

While the movable camera may change context (i.e. site), the recorded media samples are still associated with the site indication corresponding to the site at which they were recorded in the first place.

When an access request for accessing media samples is received by the camera from another device or through a client application installed in the camera, identification data identifying a user are retrieved, as well as associated access rights. The access rights take into account the site indication of media samples. Hence, depending on the access rights of the identified user, the movable camera may authorize the user to access all the media samples currently stored by the movable camera or only some of them, depending on the site indication, or none of them.

Therefore, each time a user (or a process) tries to access media samples stored in a movable camera, the site indications associated with the media samples are retrieved and the access rights of the corresponding site are determined to decide whether or not the user is authorized to access to at least some media samples.

Figure 1 illustrates a multi-device networking system in which embodiments of the invention may be implemented.

This system 100 comprises a plurality of network cameras 101, 102, 103 that may be moved over time, i.e. they are movable cameras. Each camera comprises capturing means for recording media samples (video and/or audio), communication means 111, 112, 113, for communicating with other network cameras and a storage unit (e.g. an SD card or a hard disk) for storing video data captured by the network camera or received via the communication means from another network camera.

For instance, the network cameras may be video surveillance cameras each monitoring an area of space, or they may be cameras for photography or filming (digital cameras). The cameras are configured to record media samples (video and/or audio) upon specific event detection related to a real object, e.g. a target (typically motion detection of the target), or upon manual triggering (photography cameras).

The network cameras 101, 102, 103 are interconnected through a communication network 104 that enables exchanges of messages (e.g. video data) with each other using the communication paths 105, 106, 107. The communication network 104 is for instance an IP-based local or wide area network (LAN, WAN) and the communication protocol may be an IP protocol such as HTTP over TCP or RTP over UDP. In embodiments, the exchanges over the network 104 may be secured. For these purposes, encrypted communications may be used, for example based on HTTPS or WebRTC.

In some embodiments, the network cameras are smart cameras. This kind of camera provides sufficient processing resources to perform video content analytics for instance to detect movement of targets (for restricted resources devices) and other simple image processing up to more complex algorithms such as face recognition or re-identification algorithms for high processing rate devices. A smart camera typically includes local storage memory such as an SD card or equivalent for storing recorded media samples. A network of smart cameras is able to perform distributed tasks, such as distributed management of access to media samples.

In the given example, the system of network cameras is represented as a decentralized system wherein each camera is configured to behave in an autonomous way to perform distributed tasks. However the present invention is not limited thereto and also applies to a centralized system wherein cameras interact with each other through a server (external processing device) which aggregates all data.

Figure 2 is a block diagram illustrating modules of a movable network camera 300 (e.g. cameras 101, 102, 103 of Figure 1) of the multi-device networking system shown in Figure 1, in which steps of one or more embodiments may be implemented.

These schematic modules are configured to achieve efficient control of access to data (media samples) stored in memory of the camera. In particular, there are provided: - a site indication processor module 201; - a request processor module 202; - a data controller module 203; and - a media sample exchanger 204.

The present invention is not limited to the modules shown in this figure and the movable camera may also include other processing modules, for instance a video analytics module (in video surveillance cameras) or an image enhancement module (in digital cameras).

In the distributed context considered in the following description, the access rights to the data are managed based on local context indications shared (e.g. exchanged) between the connected cameras of the system. These local context indications are used to compute a site/event indication (or site/event identifier).

This site indication is typically determined at the site indication processor module 201. The processing performed in this module is described in detail with reference to Figure 4.

Once the site indication has been determined, it may be retrieved by the other modules, for instance to be associated with recorded samples or to determine the access rights based on it.

The request processor module 202 performs access rights management. It is configured to handle several types of request.

For instance, a first type is a request for a given media sample or set of media samples. The handling of such a request is described in detail with reference to Figure 3. A second type of request handled by the request processor module 202 is a join request from a new device different from the connected network cameras of the system and aiming at connecting the existing system of cameras. This device may be a smartphone, a camera, or even an embedded process of the current camera.

The request processor module 202 is configured to decide to accept or not accept the device at the existing site. For example, if the site indication shared among the network cameras indicates that the set of cameras which form the site is “closed”, the join request of the device is automatically rejected and the device receives an error message (e.g. 403 Forbidden response for the HTTP protocol) in response to its request. On the contrary, if the site is “open” or “restricted”, the request processor module 202 checks whether the device may be authorized to access the site.

For these purposes, it is checked whether the join request includes information to identify the device in the network. Next, it is checked whether the join request should be accepted or not. This may consist for instance in forwarding the decision to one of the site administrator users who takes the appropriate decision. Another possibility is to check whether the device is on a pre-determined list of authorized devices. If the device is not authorized, an error message (e.g. 403 Forbidden response for the HTTP protocol) is sent in response to the join request. Otherwise, the new device is added to the set of cameras forming the site and a notification is sent to all the participants of the site to indicate that a new device has been added to the set of cameras. Also, the access rights are shared with the new device. A third type of request handled by the request processor module 202 is a user join request aiming at creating a new user profile comprising access rights to access the site. The request processor module 202 is thus configured to check whether the user is authorized to access to the site based on the received user join request. As for the device join request, if the site indication shared among the network cameras indicates that the set of cameras which form the site is “closed”, the user join request is automatically rejected and the user receives an error message (e.g. 403 Forbidden response for the HTTP protocol) in response to its request. On the contrary, if the site is “open” or “restricted”, the request processor module 202 checks whether the user can be authorized to access the site.

When the site is “restricted”, the system queries a user database to check whether the requesting user is known and if so, whether its access rights are sufficient to access to the site. If one of these conditions is not fulfilled, an error message (e.g. 403 Forbidden response for the HTTP protocol) is returned. Otherwise, the user is known and is granted access to the site. Hence, a successful response message is returned (typically a 200 OK response for the HTTP protocol).

When the site is “open”, user authentication parameters are retrieved (either directly from the request or through an authentication protocol) and access rights are determined for this new user. The access rights may be set to default access rights defined during the creation of the site, as described in detail with reference to Figures 4 and 5. Alternatively, the access rights are manually set by one of the known users of the site who is allowed to define new user access rights. These access rights are then associated with the user and added to an access rights database. The access rights databases of the other participants of the site are then updated thanks to network message exchanges. A success response is sent to the requester to validate the successful processing of the join request.

The data controller module 203 is in charge of controlling the storage of media samples and associated indications in the camera. Each time a media sample is captured or any indication (e.g. site indication or local context indication) is generated by the camera or received from another device, it is stored in memory of the camera. In particular, this module associates site indications with media samples that will be used later to check access rights to the media samples. This process is described in detail with reference to Figure 3.

The data controller module 203 may also be able to encrypt the media samples to avoid a malicious user directly accessing the memory of the camera and reading the media sample without having the necessary access rights.

The media sample exchanger module 204 controls the sending of data (e.g. media samples or indications) to another device and ensures that it has sufficient information to control access rights to any sent copy of media samples.

For instance, when another device or client sends a request for media samples, and is authorized to access them, the media samples may be then copied and stored in memory of the requester (i.e. requesting device). Later on, the requester may itself receive a request from a different device or client to access these media samples. In order to handle this request, the requester needs to retrieve the site indication associated with the requested samples.

For these purposes, the response to any media sample request from an authorized user (i.e. having the right to access it) comprises the requested media sample and the site indication associated with it. This avoids maintaining a table of association between requested media samples and their origin. The table would otherwise be required to find the camera that manages the site indications of the requested media samples.

When the requested media samples are encrypted (by the data controller module 203), the media sample exchanger module 204 is able to decrypt them before including them in the response message with the associated site indications. The response message may be then securely transmitted to the requester thanks to a transmission protocol using encryption such as the HTTPS protocol.

Figure 3 is a flowchart illustrating general steps of a method for managing access to a media sample according to embodiments. For instance, these steps may be performed by a movable camera such as cameras 101, 102 and 103 of Figure 1.

During a first phase composed of steps 301 to 304, the media samples recorded by the camera are associated with a site indication determined by the site indication processor module 201, as described in detail with reference to Figure 4. This first phase is managed by the data controller module 203. This first phase is performed each time a new media sample is recorded by the camera.

During a second phase composed of steps 305 to 311, an access request is handled by the request processor module 202 so as to authorize or not authorize the access to a requested media sample. This second phase is performed each time a request to access a media sample is received by the camera.

The first and the second phase are independent and may be performed in parallel. They are now described in further detail.

During the first phase, at step 301, it is checked whether a new media sample has been captured or generated by the camera to be stored in memory.

When this is the case, at step 302, it is checked whether the site has changed since the last media sample capture. If so, a new site indication is computed by the site indication processor module 201 (step 303). Otherwise, the current site indication is retrieved from the memory of the camera.

In both cases, the computed or retrieved site indication is then associated with recorded media sample at step 304. In practice, a unique identifier representing the recorded media sample is computed (for instance its memory address). A table (“junction table”) is created in memory of the camera. This table comprises the unique identifiers of the media samples and their associated site indications. When a recorded media sample is duplicated in the camera memory, thus with a new address and identifier, a new entry is added to the table with the new recorded media sample associated with the site indication of the original recorded data.

In the given example, the camera embeds storage means which may be detachable (e.g. SD cards). The recorded media samples may first be encrypted with a key generated and known by the camera to prevent direct access to the storage disk by a user who does not have the access rights to the recorded media sample. Hence, even if the user may obtain the encrypted media sample, the user cannot have access to an unencrypted version of the media sample. For instance, the encryption key may be based on the associated site indication. In such a case, the encryption key is derived from the associated site indication and thus can be different for each site handled by the camera. In one alternative, the same encryption key may be used for all the sites. The encryption key is generated based on information shared by all the cameras of the network.

During the second phase, at step 305, it is checked whether an access request for a given media sample has been received, for example using the HTTPS protocol. Upon reception of such a request, the camera has to determine whether the request from the user is authorized in order to ensure protection of media samples against unauthorized users.

For these purposes, at step 306, identification data (e.g. comprising authentication parameters of the requester) are retrieved from the received request and at step 307, the requested media sample is identified from the request and the table computed by the data controller module 203 at step 304 is used to determine the site indication associated with the requested media sample. Steps 306 and 307 can be performed in a different order or in parallel.

At step 308, access rights associated with identified user for the requested media sample are retrieved. In practice, the camera queries its access rights database with the identification data retrieved at step 306 in order to obtain a list of site indications each associated with the access rights of the requester. The site indication is then searched for in the list to extract the access rights of the requester for the requested media sample.

At step 309, it is tested whether the access rights retrieved at step 308 are sufficient and if so, the access is authorized at step 310. Otherwise, the access is forbidden and an error message (e.g. a 403 Forbidden response for the HTTP protocol) is sent in response to the access request at step 311.

For instance, if the requester asks for a read access to a media video sample recorded at a site for which it has not been authorized, the request is rejected and an error message is sent back. Otherwise, the requester has been authorized by an administrator of the system and the requested media video sample may be processed. When a media sample is requested, the media sample exchanger module 204 may be called to generate the response message.

In the given example, the request aims at retrieving data from the requested camera. However, the present invention is not limited thereto. For example, in some applications, the request may contain data that are uploaded to the requested camera (typically an HTTP POST request). In such a case, the same processing steps may be applied, except step 311 at which the camera receives the uploaded data and processes them (instead of sending them). If the uploaded data includes media data that can be stored in memory of the camera, it is expected that the site indication for the uploaded data is provided either in the request payload data or through another means (e.g. another HTTP request). Hence, the access provided may be a write access for uploading data into the camera. It may also be another kind of permission, for instance for removing a media sample from the camera.

Figure 4 is a flowchart illustrating steps for computing a new site indication according to embodiments. This algorithm is typically handled by the site indication processor module 201 of the camera shown in Figure 2.

In general terms, the site indication represents conditions in which the media samples were recorded. For instance, it may correspond to the location (e.g. geographical position) of the set of cameras, the set of network connections accessible to the cameras of the site, the set of cameras connected to the system, the time of the day, or a combination of several criteria. This site indication is thus common to the cameras of the set (i.e. of the site).

According to a first embodiment, the site indication may be manually set by the camera owner or installer. When the installer modifies the capture conditions of the camera system, the site indication is also modified by hand. The advantage of this solution is that the setup is very simple and may be entirely controlled by the installer. Only steps 406 and 407 (described below) are performed.

According to a second embodiment, the site indication is automatically determined. An advantage of this second embodiment is that the site indication is always adapted to the current context and does not depend on the vigilance of the installer and thus the management of user access rights is more efficient.

The site indication determination process starts with the determination (step 400) of the type of local context indication locally set or measured at each camera of the system. For instance, this type may be: the geographical position of the camera; the network connections accessible to the camera; a unique identifier of the camera.

The type of local context indication is the same for all the cameras of the system, thus allowing a comparative process for determining a subset of cameras defining a site.

In practice, during an initialization phase of each camera of the system, a set of types of context information may be pre-defined. The type of context information used by the system of cameras may be defined either by the installer or through a consensus agreement based on a known two-phase commit algorithm for instance. Once the system of cameras agrees on the type of the local context indication, it is supposed that it is constant until a change of the capture conditions of the system. For instance, such a change may occur when a camera is moved in the system or even when a new camera joins the system of cameras. A monitoring of the capture conditions of the system of cameras is performed during the processing loop formed by steps 401 to 405.

This processing loop starts with the determination of a local context indication at step 401 by the camera. It should be noted that the local context indication of two different cameras can be different.

For instance, the type of the local context indication chosen at step 400 is a geographical position of the camera and it is defined by latitude and longitude coordinate values. Those values may be measured by each camera using triangulation of GPS signals or in a variant they are retrieved from the manual entry performed by the installer.

At step 402, the value of the local context indication is stored in memory and shared with other cameras of the system through network messages for instance based on the HTTP protocol. In practice, the message includes a unique identifier of the camera, which enables the recipient of the message to identify from which camera the message is received.

At step 403, the current camera receives the local context indication of other cameras. In practice, each value is stored in memory in a table of local context indications comprising the unique identifier of each camera and the local context indication received for this identifier. When no local context indication is received from a camera, after a pre-determined time interval, it is considered that this camera has left the system and its local context indication is marked as missing.

Step 403 is independent from step 402 and may equally well be performed in parallel to step 402.

At step 404, a site indication is computed. In practice, the table of local context indications is processed to select a subset of cameras of the system defining a site.

For these purposes, different similarity metrics (i.e. selection criteria) may be considered depending on the type of local context indication determined at step 400.

For instance, when the type is the geographical position of the cameras, the similarity metric is based on the distance between the cameras and aims at selecting a subset of cameras located in a predetermined range. All cameras in the same predetermined range are thus considered to be at the same site.

As another example, when the considered type is the set of accessible network connections, the camera generates the list of wireless network identifiers inside its wireless range and the similarity metrics of the context information are based on the number of wireless networks in common between the lists of in range wireless networks. If two cameras have more than a predetermined percentage level (typically 90%) of networks in common, they are considered to be at the same site.

As still another example, when the considered type is a unique identifier of the camera, all the connected network cameras of the system may be selected to form the subset. This means that each time a camera is added to or removed from the system, a new site is created. For the initial determination stage, all the retrieved unique identifiers are listed and stored in memory. For subsequent determination stages, the similarity function consists in testing whether the received unique identifiers are part of the stored list of unique identifiers. Two cameras are at the same site (i.e. are selected to be in the subset) when their unique identifiers are both in the list.

Next, a site indication is computed for the site, based on the local context indications associated with the cameras of the subset. This site indication is stored in memory.

For instance, the site indication computed based on geographical positions of the cameras of the subset is the coordinates of the barycenter of coordinates of the cameras of the subset.

As another example, the site indication computed based on the lists of accessible network connections is the list of network identifiers in common.

As yet another example, the site indication computed based on the unique identifiers is the list of unique identifiers (i.e. of currently connected cameras in the system).

Steps 401 to 404 are regularly (typically every 30 seconds) performed to identify when the site configuration has changed. Each new site context indication newly estimated is compared to the one stored in memory (except for the initial determination) at step 405.

If the values are equal, the process loops back to the local context indication determination step 401 which starts after a predetermined delay (typically 30 seconds).

On the contrary, if the computed site indication is new (or it is the initial site indication), two additional steps 406 and 407 are performed before looping back to step 401. These two steps aim at reconfiguring the camera with the new site configuration.

When at step 403, no local context indication has been received from a camera which is thus marked as missing while it was in the subset of cameras at the previous loop, it may be considered that a new set of cameras is observed and that a new site needs to be created.

At step 406, a new site is created, the selected subset of cameras is associated with the new site indication and access rights associated with the new site are defined. This step is described in detail with reference to Figure 5.

In some cases, the creation of a new site is conditional upon (manual) acceptance of the installer (or admin of the site) for instance through a graphical user interface. This avoids forcing the camera to create a new site with new access rights e.g. each time a new camera is added to the system. A time interval may be taken into account when defining a new site. For instance, a timestamp may be associated with the site (e.g. indicating its creation time) and a new site may be automatically created when a predetermined time interval has passed.

At step 407, the new site indication is stored in memory and broadcasted to other processing modules 202, 203, 204 of the camera.

In the given example, the site indication is computed by each camera based on information exchanged between the cameras of the system (distributed approach). However, the present invention is not limited thereto and the person skilled in the art may adapt this example to a centralized approach with a server or a main camera handling the processing for all the other cameras.

For example, the algorithm may comprise an additional step of electing a master camera from among the cameras of the multi-camera networking system, and this elected master camera generates the site indication for all other cameras based on local context indications received from them. The resulting site indication is then broadcasted to each camera of the site. The detection of a new site may also be performed by the master camera. The master camera regularly sends messages (for instance keep alive messages) to inform other cameras of the system that it is still connected to the system. When the delay since the last reception of such a message from the master exceeds a pre-determined time interval, the remaining cameras detect that the master camera has been removed and a new election step is launched.

Figure 5 is a flowchart illustrating steps for creating a new site according to embodiments. These steps may be performed during step 406 of Figure 4.

Upon detection of a new site (i.e. a new site indication is detected at step 405), the set of concerned cameras (i.e. the selected subset) are informed to share a common feature of the site. It should be noted that since several users and/or processes may use/run on a given camera, there may be more members/participants than the number of cameras of the selected subset. However, each participant has personal access rights. Hence, upon detection of a new site, the selected subset of cameras is informed of the access rights set for the different participants of the site.

For the sake of simplicity, the given example deals with cameras only. However, the present invention is not limited to cases where only cameras may join a site. For instance, other kinds of devices having displaying tools may also want to join a site to allow a user of this device to watch or listen to content shared between the members of this site.

At step 500, the creation of the new site is advertised to all the cameras of the network through a broadcast message. The message can be sent to the cameras of the subset only (i.e. the cameras of the site) or to all the cameras of the system. The advertising of the new site creation may be sent regularly (e.g. every 10 seconds) to inform new cameras which connect to the network that a site already exists and that they may join.

In practice, the advertising message may include the site indication. Optionally, it may be associated with a value indicating whether or not the site allows a new camera to be added. For instance, the values may be defined as follows: “Open”, which indicates that the subset of cameras allows any new device to join the site; “Restricted” which indicates that the subset of cameras may allow a new device to join but it should be first accepted by an administrator of the site; “Closed” which indicates that the subset of cameras is closed and that newcomers are rejected.

In particular, the list of the cameras which are at the site may be advertised for “Open” sites. As mentioned with reference to Figure 2, join requests are handled by the request processor module 202.

At step 505, access rights for the site are defined as a set of permissions for instance associated with the access level of the user or group of users (or processes).

In practice, the system of camera provides a database of users (or processes) with authentication protocol (for instance OpenID, TLS, OAuth or any Directory Services based authentication protocol). Each time a user connects to the system (for instance through a camera) a unique identifier (e.g. a signature) is provided to represent the user.

For instance, the user database may be maintained by an access right server and in order to retrieve the permissions associated with a user, each camera of the site must query the access right server for the permission of a given user identified by its unique identifier. In response, it receives all the permissions granted to the user.

The permissions may be for instance:

Read permission of media samples; - Write permission of media samples (for media sample exchange); - Add/remove new user: allows a user to be added to or removed from the system;

Change user access level;

Configure site default access level;

Create/Start a new site.

The permissions listed above are not exhaustive. Each access level is a different set of granted permissions. The access level is defined for each site indication. For instance, the following access levels may be defined: - System administrator access level: has all granted permissions for any site and for any cameras; - Device administrator access level: has all granted permissions for any site of the current camera; - Site administrator access level: has all granted permissions for any camera but only for a specific site; - User level: has Read/Write permissions for a specific site; - Custom user: has a customized set of permissions for a specific site.

In practice, the initial set of users and their access rights are defined during an initialization phase of the access rights server.

In video surveillance applications, the first user which connects to the camera has by default the device administrator access level allowing configuration of the system. Once configured, any new user which wants to configure the camera has to have the appropriate access level (which can be attributed by an administrator). A system administrator is equivalent to a user which is device administrator on all camera of the system.

In photo sharing applications, no system administrator access level has to be defined. One user may create a new sharing event/site from its digital camera. This user has device administrator access level de facto as owner of the camera. Any new user which connects to the sharing site will have by default the User level permission. The device administrator may override the system default access right by defining new permissions which will be applied only for its camera.

According to another embodiment, the access rights server processing is handled by all the cameras in a distributed approach. An access right camera is elected through a known consensus algorithm as the access right server and user authentication server. It is in charge of controlling new user connections and of generating a consistent database of access rights that will be forwarded to other cameras at step 504. When a new user wishes to join the system, it must contact this elected camera to be attributed default access rights. This embodiment makes it possible to dispense with a central access right server which must be accessible by any camera of the system which is not feasible in all usage conditions.

According to another embodiment, each camera may provide several services such as live view, storage, indexation of recorded media samples, resilience of media data service through duplication of data (distributed copy process), erosion of old media data, graphical user interface customization. Previously access rights were defined to access only to media samples. In this alternative, different access rights for the services may be defined as a function of the site indication. For instance, a user (or a process such as distributedCopyUser) may be granted the permission to perform distributed copying of media samples regardless of the site indication but is allowed only to perform erosion i.e. removal of media samples for specific site context information value.

Below are examples of new permissions that can be defined for this last alternative: - Indexing permission: allows all media samples available from a specific site to be listed; - Distributed copy permission: allows copying of all media samples of a specific site to another camera; - User interface customization: allows modification of the theme of the user interface provided by the camera for a specific site.

Next processing steps of a new site creation process are directed to informing all participants of the site that they belong to the same set of cameras and that they can interact to manage the user access rights of the media samples they capture.

For these purposes, a processing loop composed of steps 502 to 504 is performed for each participant of the site detected at step 501.

At step 502, a new participant is added to the system. This participant is a camera or a device comprising a camera. In practice, each camera maintains a list of cameras which belong to the same site in its memory. The participant IP address is added to this list. In addition to the address of the participant, the authentication parameters of its users may be also inserted in this list.

At step 503, a notification is sent to all already processed participants that a new participant is member of the site. When receiving this notification each camera adds the new participant to its list of site members.

At step 504, the access rights of the site are sent to the participant currently being added to end the new site creation processing.

According to another embodiment, a hierarchical definition of site is provided. A set of cameras are selected by one administrator (or e.g. through automatic clustering algorithm based on the distance between the cameras) of the site to form a new sub-site of the current site. Different access rights may be defined for each sub-site of cameras. When the number of cameras in the system is increasing, it permits to cluster the set of cameras in subsets which are easier to process. In addition, it is considered that the default access rights of each sub-site are inherited from the access rights of the main site. Sub-sites may override the access rights for a more accurate access right management.

Figure 6 is a block diagram representing an exemplary architecture of a movable network camera (distributed approach), for instance one of the network cameras shown in Figure 1 or a dedicated server (centralized approach), in which steps of one or more embodiments may be implemented.

The device 600 comprises a communication bus 602 to which there are preferably connected: - a central processing unit 604, such as a microprocessor, denoted CPU; - a read only memory 606, denoted ROM, for storing computer programs for implementing the invention; - a random access memory 608, denoted RAM, for storing the executable code of methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the invention; - a network interface 612 connected to a network 614 over which a communication can be implemented between the device 600 and a network camera connected to the network; and - a data storage means 610 such as a hard disk, for storing computer programs for implementing steps of one or more embodiments of the invention and for storing data, during the implementation of one or more embodiments of the invention.

Optionally, the device 600 may also include a user interface 616 to display information to, and/or receive inputs from, a user. For instance, it may be a screen serving as a graphical interface with a user, or other means such as a keyboard or a pointing means.

The communication bus 602 provides communication and interoperability between the various elements included in the device 600 or connected to it. The representation of the bus is not limiting and in particular the CPU 604 is operable to communicate instructions to any element of the device 600 directly or by means of another element of the device 600.

The disk 610 can be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the device, possibly removable, and adapted to store one or more programs whose execution enables a method according to the invention to be implemented.

Instructions relating to the software application may be loaded into the main memory 608 from a hard disk 610 or the program ROM 606 for example. According to a variant, the executable code of the programs can be received by means of the communication network 614, via the interface 612, in order to be stored in one of the storage means of the device 600, such as the hard disk 610, before being executed. Such software application, when executed by the CPU 604, causes the steps described with reference to Figures 3 to 5 to be performed in the device 600.

The CPU 604 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 610 or in the ROM 606, are transferred into the RAM 608, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

In this embodiment, the device is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). It can consist of one or more dedicated integrated circuits that are capable of implementing the method as described with reference to Figures 3 to 5.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive, the invention being not restricted to the disclosed embodiments. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in putting into practice (i.e. performing) the claimed invention, from a study of the drawings, the disclosure and the appended claims.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. Any reference signs in the claims should not be construed as limiting the scope of the invention.

Claims (16)

1. A method for managing access to a media sample, the media sample being captured at a first site by a movable camera and stored within the movable camera, the method comprising: associating the media sample with a first site indication, thereby when the movable camera is moved to a second site different from the first site, the media sample remains associated with the first site indication; obtaining an access request for accessing media samples captured at the first site, the access request comprising identification data identifying a user; authorizing or not authorizing, based on access rights associated with the identification data, the user to access the media sample stored in the movable camera now at the second site.

2. The method of claim 1, wherein the first site indication is based on a geographical position of the movable camera at the first site.

3. The method of claim 1, wherein the first site indication comprises information about networks accessible to the movable camera.

4. The method of claim 1, wherein the first site indication is based on identifiers of cameras forming a multi-camera networking system with the movable camera.

5. The method of any one of claims 1 to 4, wherein the first site indication is based on a capture timestamp associated with the media sample, and wherein access to the media sample is authorized depending on the timestamp.

6. The method of any one of claims 1 to 5, wherein the first site indication results from the following steps: computing a table of local context indications comprising an identifier of each camera of a multi-camera networking system to which the movable camera belongs and a local context indication associated with each identifier; selecting a subset of cameras of the multi-camera networking system based on the table of local context indications and a selection criterion, the selected subset defining a site; generating a site indication for the site, based on the local context indications associated with the cameras of the subset.

7. The method of claim 6, wherein access rights for accessing media samples are based on the site indication generated for the site where the media samples were captured.

8. The method of claim 6 or 7, further comprising a step of electing a master camera from among the cameras of the multi-camera networking system, for generating the site indication.

9. The method of any one of claims 1 to 8, wherein the media sample captured at a given site is encrypted with an encryption key based on the associated site indication or an encryption key common to all the media samples captured in any site by the movable camera.

10. The method of any one of claims 1 to 9, further comprising: - capturing another media sample at the second site by the movable camera and storing it in the movable camera; - associating the other media sample with a second site indication; - obtaining an access request for accessing media samples captured by the movable camera, the access request comprising identification data identifying a user; - authorizing or not authorizing, based on access rights associated with the identification data, the user to access the media sample captured at the first site and/or the other media sample captured at the second site by the movable camera.

11. A system for managing access to a media sample, the media sample being captured at a first site by a movable camera and stored within the movable camera, the system being configured for: - associating the media sample with a first site indication, thereby when the movable camera is moved to a second site different from the first site, the media sample remains associated with the first site indication; obtaining an access request for accessing media samples captured at the first site, the access request comprising identification data identifying a user; authorizing or not authorizing, based on access rights associated with the identification data, the user to access the media sample stored in the movable camera now at the second site.

12. A computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out each step of the method according to any one of claims 1 to 10 when the program is loaded and executed by a programmable apparatus.

13. A computer-readable storage medium storing instructions of a computer program for implementing the method according to any one of claims 1 to 10.

14. A system substantially as hereinbefore described with reference to, and as shown in Figure 1.

15. A method substantially as hereinbefore described with reference to, and as shown in Figures 3 to 5.

16. A device substantially as hereinbefore described with reference to, and as shown in Figures 1, 2 and 6.