WO2017147819A1

WO2017147819A1 - Restricting access to portions of sensitive metadata in media content

Info

Publication number: WO2017147819A1
Application number: PCT/CN2016/075328
Authority: WO
Inventors: Liang Zhang
Original assignee: Motorola Mobility Llc
Priority date: 2016-03-02
Filing date: 2016-03-02
Publication date: 2017-09-08
Also published as: CN108605201A

Abstract

A method, a system, and a computer program product for restricting access to sensitive metadata of media on a device. The method includes identifying a request from a requesting application to access media content that contains sensitive metadata. In response to receiving the request, an application control rule is accessed to determine whether at least one sensitive metadata restriction exists that restricts access to at least one portion of the sensitive metadata for the requesting application. In response to determining the application control rule contains the at least one sensitive metadata restriction, a temporary copy of the media content is generated that excludes the at least one portion of the metadata. The method further includes providing the requesting application with a file handle that enables the requesting application to access the temporary copy. In response to the requesting application closing the file handle, the temporary copy may then be deleted.

Description

RESTRICTING ACCESS TO PORTIONS OF SENSITIVE METADATA IN MEDIA CONTENT

BACKGROUND

1. Technical Field

The present disclosure generally relates to electronic devices and in particular to an improved method for restricting access to sensitive metadata of media on an electronic device.

2. Description of the Related Art

In mobile devices, such as cellular phones, metadata may be created in conjunction with the capture of media. This metadata may include privacy-sensitive identifying information, such as a geolocation of the mobile device, the date and time of capture of the media, and device make/model information. When related to the captured media, this information may place the privacy of a user of the mobile device at risk. Current solutions only provide controls for disabling location tagging for all captured media. While this may protect the privacy of a user of the mobile device, it also eliminates the ability for trusted applications to use metadata contents for desirable purposes.

BRIEF DESCRIPTION OF THE DRAWINGS

The description of the illustrative embodiments is to be read in conjunction with the accompanying drawings, wherein:

FIG. 1 provides a block diagram representation of an example data processing system within which certain aspects of the disclosure can be practiced, in accordance with one or more embodiments；

FIG. 2 illustrates a mobile device within which certain aspects of the disclosure can be practiced, in accordance with one or more embodiments；

FIG. 3 illustrates an example mobile device configured for restricting access to sensitive metadata of media on the mobile device, in accordance with one or more embodiments；

FIG. 4 is a flow chart illustrating a method for restricting access to sensitive metadata of media on a device, in accordance with one or more embodiments；

FIG. 5 is a block diagram illustrating a first embodiment of a metadata selection interface that enables viewing and/or modification of applications control rules based on a currently selected metadata portion, in accordance with one or more embodiments； and

FIG. 6 is a block diagram illustrating an alternate embodiment of a metadata selection interface that enables viewing and/or modification of applications control rules based on a currently selected application, in accordance with one or more embodiments.

DETAILED DESCRIPTION

The illustrative embodiments provide a method, a system, and a computer program product for restricting access to sensitive metadata of media on a device. The method includes identifying a request from a requesting application to access media content that contains sensitive metadata. In response to receiving the request, an application control rule is accessed to determine whether at least one sensitive metadata restriction exists that restricts access to at least one portion of the sensitive metadata for the requesting application. In response to determining the application control rule contains the at least one sensitive metadata restriction, a temporary copy of the media content that excludes the at least one portion is generated. The method further includes providing the requesting application with a file handle that enables the requesting application to access the temporary copy. In response to the requesting application closing the file handle, the temporary copy may then be deleted.

The above contains simplifications, generalizations and omissions of detail and is not intended as a comprehensive description of the claimed subject matter but, rather, is intended to provide a brief overview of some of the functionality associated therewith. Other systems, methods, functionality, features, and advantages of the claimed subject matter will be or will become apparent to one with skill in the art upon examination of the following figures and the remaining detailed written description. The above as well as additional objectives, features, and advantages of the present disclosure will become apparent in the following description.

In the following detailed description, specific example embodiments in which the disclosure may be practiced are described in sufficient detail to enable those skilled in the art to practice the disclosed embodiments. For example, specific details such as specific method orders, structures, elements, and connections have been presented herein. However, it is to be understood that the specific details presented need not be utilized to practice embodiments of the present disclosure. It is also to be understood that other embodiments may be utilized and that logical, architectural, programmatic, mechanical, electrical and other changes may be made without departing from general scope of the disclosure. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and equivalents thereof.

References within the specification to “one embodiment, ” “an embodiment, ” “embodiments” , or “one or more embodiments” are intended to indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of such phrases in various places within the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Further, various features are described which may be exhibited by some embodiments and not by others. Similarly, various aspects are described which may be aspects for some embodiments but not other embodiments.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a” , “an” , and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising, ” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Moreover, the use of the terms first, second, etc. do not denote any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another.

It is understood that the use of specific component, device and/or parameter names and/or corresponding acronyms thereof, such as those of the executing utility, logic, and/or firmware described herein, are for example only and not meant to imply any limitations on the described embodiments. The embodiments may thus be described with different nomenclature and/or terminology utilized to describe the components, devices, parameters, methods and/or functions herein, without limitation. References to any specific protocol or proprietary name in describing one or more elements, features or concepts of the embodiments are provided solely as examples of one implementation, and such references do not limit the extension of the claimed embodiments to embodiments in which different element, feature, protocol, or concept names are utilized. Thus, each term utilized herein is to be provided its broadest interpretation given the context in which that term is utilized.

As utilized herein, media refers to media content having an associated metadata. In one embodiment, media may include at least one of a still image (including multiple-frame and/or burst images) , audio recording, video recording (including high frame rate video) , or any suitable combination of the foregoing. The media can be captured by a single image sensor and/or multiple image sensors working independently and/or in tandem. The media can further include audio captured by a microphone. In another embodiment, media may refer to any stored file.

As utilized herein, a requesting application refers to an application that is requesting read access to a particular media. In one embodiment, the requesting application may request the media at a same device where the media is stored. In another embodiment, the requesting application may issue a request to remotely-access media that is stored on another device and/or in another physical location.

Those of ordinary skill in the art will appreciate that the hardware components and basic configuration depicted in the following figures may vary. For example, the illustrative components within data processing system 100 are not intended to be exhaustive, but rather are representative to highlight components that can be utilized to implement the present disclosure. For example, other devices/components may be used in addition to, or in place of, the hardware depicted. The depicted example is not meant to imply architectural or other limitations with respect to the presently described embodiments and/or the general disclosure.

Within the descriptions of the different views of the figures, the use of the same reference numerals and/or symbols in different drawings indicates similar or identical items, and similar elements can be provided similar names and reference numerals throughout the figure (s) . The specific identifiers/names and reference numerals assigned to the elements are provided solely to aid in the description and are not meant to imply any limitations (structural or functional or otherwise) on the described embodiments.

With reference now to the figures, and beginning with FIG. 1, there is depicted a block diagram representation of an example data processing system (DPS) 100, within which one or more of the described features of the various embodiments of the disclosure can be implemented. In one embodiment, DPS 100 can be any electronic device such as a desktop computer, notebook computer, mobile phone, smart watch, camera, video recorder, or tablet.

DPS 100 includes at least one central processing unit (CPU) or processor 104 coupled to system memory 110 and non-volatile storage 120 via system interconnect 102. System interconnect 102 can be interchangeably referred to as a system bus, in one or more embodiments. One or more software and/or firmware modules can be loaded into system memory 110 during operation of DPS 100. Specifically, in one embodiment, system memory 110 can include therein a plurality of such modules, including one or more of firmware (F/W) 112, basic input/output system (BIOS) 114, operating system (OS) 116, media access utility (MAU) 117, and application (s) 118. These software and/or firmware modules have varying functionality when their corresponding program code is executed by CPU 104 or by secondary processing devices within DPS 100. In one embodiment, non-volatile storage 120 can include therein an application control database (ACD) 122 and media library 124. ACD 122 includes access control rules that categorize permissions that restrict and/or authorize applications 118 to read portions of metadata within media stored in media library 124. While ACD 122 and media library 124 are illustrated as being stored within non-volatile storage 120 of DPS 100, in other embodiments, ACD 122 and media library 124 may be partially or entirely stored on another device (e.g., a network storage or server 165) that is accessible by DPS 100.

MAU 117 is a utility that executes within DPS 100 to perform the various methods and functions described herein. In one embodiment, MAU 117 may generate a modified temporary copy of media stored in media library 124 and provide, to a requesting application (s) (e.g., applications 118) , a unique file handle that identifies the temporary copy and enables the requesting application (s) to access the temporary copy. For simplicity, MAU 117 is illustrated and described as a stand-alone or separate software/firmware/logic component, which provides the specific functions and methods described below. However, in at least one embodiment, MAU 117 may be a component of, may be combined with, or may be incorporated within firmware of DPS 100, or within the OS 116, and/or one or more of applications 118.

DPS 100 further includes one or more input/output (I/O) controllers 130, which support connection by and processing of signals from camera sensor 142 and one or more connected input device (s) 132, such as a keyboard, mouse, hardware button (s) , touch screen, infrared (IR) sensor, fingerprint scanner, or microphone. I/O controllers 130 also support connection with and forwarding of output signals to one or more connected output devices 134, such as monitors and audio speaker (s) . Additionally, in one or more embodiments, one or more device interfaces 136, such as an optical reader, a universal serial bus (USB) , a card reader, Personal Computer Memory Card International Association (PCMIA) slot, and/or a high-definition multimedia interface (HDMI) , can be associated with DPS 100. Device interface (s) 136 can be utilized to enable data to be read from or stored to corresponding removable storage device (s) 138, such as a compact disk (CD) , digital video disk (DVD) , flash drive, or flash memory card. In one or more embodiments, device interfaces 136 can further include General Purpose I/O interfaces, such as I2C, SMBus, and peripheral component interconnect (PCI) buses.

DPS 100 comprises a network interface device (NID) 140 that enables DPS 100 and/or components within DPS 100 to communicate and/or interface with other devices, services, and components that are located external to DPS 100. In one embodiment, DPS 100 may directly connect to one or more of these external devices, such as server 165 and devices 167a-n, via NID 140. These devices, services, and components can also interface with DPS 100 via an external network, such as example network 150, using one or more communication protocols. Network 150 can be a local area network, wide area network, personal area network, and the like, and the connection to and/or between network and DPS 100 can be wired or wireless or a combination thereof. For purposes of discussion, network 150 is indicated as a single collective component for simplicity. However, it is appreciated that network 150 can comprise one or more direct connections to other devices as well as a more complex set of interconnections as can exist within a wide area network, such as the Internet.

FIG. 2 illustrates an example mobile device 200 within which one or more of the described features of the various embodiments of the disclosure can be implemented. Mobile device 200 includes at least one central processing unit (CPU) or processor 204. CPU 204 is coupled to system memory 216 and/or non-volatile storage 220, within which firmware 112 and MAU 117 can be stored for execution on CPU 204. In one embodiment, non-volatile storage 220 can include therein an application control database (ACD) 122 and media library 124. ACD 122 includes access control rules that categorize permissions that restrict and/or authorize applications 118 to read portions of metadata within media stored in media library 124. While ACD 122 and media library 124 are illustrated as being stored within non-volatile storage 220 of DPS 100, in other embodiments, ACD 122 and media library 124 may be partially or entirely stored on another device (e.g., a device 252a-n or server 254) that is accessible by mobile device 200.

According to one aspect, MAU 117 executes within mobile device 200 to perform the various methods and functions described herein. In one embodiment, MAU 117 may generate a modified temporary copy of media stored in media library 124 and provide, to a requesting application (s) (e.g., applications 118) , a unique file handle that identifies the temporary copy and enables the requesting application (s) to access the temporary copy. For simplicity, MAU 117 is illustrated and described as a stand-alone or separate software/firmware/logic component, which provides the specific functions and methods described below.

As shown, mobile device 200 comprises several input devices and output devices for enabling a user to interface with mobile device 200. In the illustrated embodiment, mobile device 200 includes a camera sensor 242, camera flash 246, hardware buttons 206a- “n” , microphone 208, and speaker 244. In one embodiment, at least one of camera sensor 242 and microphone 208 may be used independently or in conjunction to capture audio, image, and/or video media. Microphone 208 may be used to receive spoken input/commands from a user. Speaker 244 is used to output audio. Hardware buttons 206a-n are selectable buttons which are used to receive manual/tactile input from a user to control specific operations of mobile device 200 and/or of applications executing thereon. In one embodiment, hardware buttons 206a-n may also include, or be connected to, one or more sensors (e.g. a fingerprint scanner) and/or be pressure sensitive. Hardware buttons 206a-n may also be directly associated with one or more functions of the GUI and/or functions of an OS, application, or hardware of mobile device 200. In one embodiment, hardware buttons 206a-n may include a keyboard.

Mobile device 200 also includes serial port 232 (e.g., a USB (universal serial bus) port) which can be one of an input port, an output port, and an input/output port. Serial port 232 allows a direct physical connection to and communication of data with a second device. In one embodiment, serial port 232 may also connect to a power charger (not pictured) for charging a battery (not pictured) of mobile device 200.

Mobile device 200 also includes display 210, which is capable of displaying a video of media content and/or a graphical user interface (GUI) of firmware and/or one or more applications executing on mobile device 200. In one embodiment, display 210 is a touch screen that is also capable of receiving touch input from a user of mobile device 200 interfacing with a displayed GUI. The GUI can be rendered by CPU 204 for viewing on display 210.

Mobile device 200 also includes one or more wireless radios 240a-n and one or more antenna (s) 248a-n that enable mobile device 200 to wirelessly connect to, and transmit and receive voice communication and/or data with, one or more other devices, such as devices 252a-n and server 254. As a wireless device, mobile device 200 can transmit the data over a wireless network 250 (e.g., a Wi-Fi network, cellular network, Bluetooth network, or personal area network) .

FIG. 3 is a block diagram illustrating functional components of a device (mobile device 200) that is configured to restrict access to sensitive metadata of media on the mobile device, in accordance with one or more embodiments. While FIG. 3 is described with reference to mobile device 200, it is appreciated that the functionality described herein may be performed by any device that is executing MAU 117, including data processing system 100.

In FIG. 3, requesting application 302 issues request 304 to access/read at least one media 306a-n from media library 124. In one embodiment, mobile device 200 may be configured to receive request 304 from requesting application 302, and to identify a requested media 306a-n within request 304. In another embodiment, requesting application 302 is included in applications 118. While requesting application 302 is illustrated as being included within mobile device 200, in another embodiment, requesting application 302 may be an application executing on another device (e.g. server 165/254, devices 167a-n/252a-n) that remotely issues request 304 to access media 306a-n from mobile device 200.

Each media 306a-n within media library 124 includes a corresponding metadata 308a-n, which provides basic information for the corresponding media 306a-n, including, but not limited to, identification of: an author, company, a date and/or time of capture of media 306a-n, a length/duration of media 306a-n, and a file size of media 306a-n. Metadata 308a-n may also identify (i) a geolocation where a corresponding media 306a-n was captured, and/or (ii) device make and/or (ii) model information of mobile device 200. Further still, metadata 308a-n may include identification of a software version of at least one of: firmware 112, an operating system 116, and/or one or more applications 118 of mobile device 200. It should be noted that, while media library 124 is illustrated as being stored within mobile device 200, in another embodiment, media library 124 may be partially or entirely stored on another device (e.g., a network/cloud storage or server 254/165) that is accessible by MAU 117. In this embodiment, MAU 117 provides, serves, and/or facilitates delivery of requested media 306a (and/or temporary copies thereof) to requesting application 302 from the other storage location or storage device via mobile device 200.

In response to identifying requested media 306a from request 304, MAU 117 accesses ACD 122 to identify, from application control rules 310a-n, access permissions that enable and/or restrict access of requesting application 302 to read metadata 308a within requested media 306a. Application control rules 310a-n include sensitive metadata restrictions 312a-n that restrict access by particular applications to particular portions, types, and/or categories of information/metadata within metadata 308a-n. For example, application control rule 310a may restrict access by requesting application 302 to date and time information within metadata 308a-n.In this example, requesting application 302 would then receive a copy of the requested media, with the data and time information removed from the metadata. In one embodiment, each application control rule 310 establishes access permissions for a particular media 306. In at least one embodiment, application control rules 310a-n can establish access permissions for only: media 306a-n captured by mobile device 200, all media 306a-n stored on mobile device 200, all media 306a-n accessible by mobile device 200, and/or a particular subset of media 306a-n.

Additionally, in one embodiment, application control rules 310a-n may optionally include sensitive metadata authorizations 314a-n, which grant access by particular applications to particular portions, types, and/or categories of data within metadata 308a-n. For example, application control rule 310n may establish that access of requesting application 302 to phone model information within metadata 308a-n is authorized. In this example, requesting application 302 would then receive a copy of the requested media, with the phone model information included.

In one embodiment, application control rules 310a-n may be initialized at creation with a default set of permissions, including sensitive metadata restrictions 312a-n and/or sensitive metadata authorizations 314a-n, to portions of metadata 308a-n for at least one application. In at least one embodiment, application control rules 310a-n can be created, defined, and/or modified by a user of mobile device 200. For example, a user of mobile device 200 may enter data via a touchscreen of mobile device 200 to establish sensitive metadata restrictions 312a-n and/or sensitive metadata authorizations 314a-n for applications of mobile device 200. In another embodiment, application control rules 310a-n can be pre-established within a software (e.g., an operating system) of mobile device 200 and may be further modified by a user or administrator of mobile device 200. Example interfaces for interacting with application control rules 310a-n are provided in greater detail within the description of FIGs. 5-6, described below.

In one embodiment, when access to a particular portion of metadata 308a-n is not expressly restricted by sensitive metadata restrictions 312a-n for a particular application, access to that particular portion of metadata 308a-n is automatically provided and the particular portions of metadata that are not expressly restricted are included in a copy of the requested media that is provided to requesting application 302. In another embodiment, when access to a particular portion of metadata 308a-n for a particular application is not expressly authorized by sensitive metadata authorization 314a-n or restricted by sensitive metadata restrictions 312a-n, permission to access the particular portion of metadata 308a-n may be automatically restricted for the particular application by MAU 117. It should be noted that, in one embodiment, a portion of metadata 308a-n may not be simultaneously restricted by sensitive metadata restrictions 312a-n and authorized by sensitive metadata authorization 314a-n.

In another embodiment, each application control rule 310 may be associated with either a particular application or a particular portion of metadata 308a-n, in another embodiment. In one embodiment, each application control rule 310a-n establishes permissions for at least one application to access a particular type or category of data within metadata 308a-n. The permissions established by application control rules 310a-n may restrict and/or enable access of a plurality of applications to individual portions of metadata 308a-n. In a first example, application control rule 310a may establish permissions that identify whether each of multiple individual applications have (or do not have) access to date and time information within metadata 308a-n. In the same example, application control rule 310n may establish permissions that identify whether each of multiple individual applications have (or do not have access) to phone model information within metadata 308a-n.

In another embodiment, each individual application control rule 310a-n establishes permissions for only a particular application to access at least one particular type or category within metadata 308a-n. The permissions established by application control rules 310a-n may individually restrict and/or enable access by a particular application to each of a plurality of individual portions of metadata 308a-n. In a second example, application control rule 310a includes permissions that enable a first application to access date and time and phone model portions of metadata 308a-n, while restricting access by the first application to geotag location information of metadata 308a-n. In the same example, application control rule 310n can include permissions that restrict a second application from accessing date and time, phone model, and geotag location information portions of metadata 308a-n.

In response to requesting application 302 requesting access to a requested media 306a having metadata 308a, MAU 117 determines whether application control rules 310a-n identify unauthorized portions of metadata 308a that requesting application 302 does not have full authorized access to. The unauthorized portions of metadata 308a include any portions of metadata 308a that are restricted by sensitive metadata restrictions 312a-n. In another embodiment, the unauthorized portions of metadata 308a may include any portions of metadata 308a that are not expressly authorized by at least one sensitive metadata authorization 314a-n, if present.

In response to determining application control rules 310a-n identify unauthorized portions of metadata 308a for requesting application 302, MAU 117 generates temporary media copy 316 of requested media 306a. Temporary media copy 316 is a copy of requested media 306a that includes the original media data (e.g., image data) of requested media 306a and includes temporary metadata 318 in lieu of metadata 308a. When unauthorized portions of metadata 308a have been identified, temporary metadata 318 excludes those unauthorized portion (s) of metadata 308a. Any portions of metadata 308a that are not determined to be unauthorized portion (s) for requesting application 302 are considered to be authorized portion (s) and are included in temporary metadata 318. For example, in response to sensitive metadata restrictions 312a-n restricting access of requesting application 302 to device model and geotag location information portion of metadata 308a, MAU 117 generates temporary media copy 316, which includes a subset of metadata 308a that excludes the device model and geotag location information portions. File handle 320 is generated to provide access by requester 302 to temporary media copy 316, and file handle 320 is then provided to requesting application 302 in lieu of a file handle that provides access to media 306a.

In one embodiment, temporary media copy 316 may be stored in media library 124 while in use by requesting application 302. In another embodiment, temporary media copy 316 may be stored in a separate storage or separate portion of a same storage as media library 124 while temporary media copy 316 is in use by requesting application 302. In still another embodiment, temporary media copy 316 may be stored in a volatile memory (not pictured) . In response to subsequently receiving a close request 322 from requesting application 302 to close temporary media copy 316, MAU 117 automatically deletes temporary media copy 316, in one embodiment.

In one embodiment, MAU 117 may detect request 304 from requesting application 302 upon receipt of request 304 at an application program interface (API) . In another embodiment, MAU 117 may snoop request 304 by monitoring a system/data bus between components (e.g. system interconnect 102) . In still another embodiment, MAU 117 may intercept a transmission, that includes request 304, to a default API (e.g., a file open (fopen) API) of mobile device 200 which handles open requests for media 306a-n. MAU 117 may then generate and provide file handle 320 to the default API, which then delivers the file handle 320 to requesting application 302.

Referring now to FIG. 4, there is depicted a high-level flow-chart illustrating a method for restricting access to sensitive metadata of media on a device, in accordance with one or more embodiments of the present disclosure. Aspects of the method is described with reference to the components of FIGs. 1-3. Several of the processes of the method provided in FIG. 4 can be implemented by a processor (e.g., CPU 104 or CPU 204) executing software code of MAU 117 within a mobile device or generic data processing system. For simplicity, the method processes described below are generally described as being performed by processor execution of MAU 117 within mobile device 200.

Method 400 commences at initiator block 401 then proceeds to block 402. At block 402 MAU 117 identifies, from requesting application 302, request 304 to access requested media 306a. MAU 117 then accesses application control rule database 122 to identify application control rules 310a-n (block 404) . At block 406, MAU 117 determines whether application control rules 310a-n identify, requesting application 302, at least one unauthorized portion (s) of metadata 308a that is restricted by at least one sensitive metadata restriction 312a-n and/or not authorized by at least one sensitive metadata authorization 314a-n. In response to determining that application control rules 310a-n do not identify at least one unauthorized portion (s) of metadata 308a for requesting application 302, MAU 117 (and/or a default API of mobile device 200) provides a file handle to requesting application 302 that enables requesting application 302 to access requested media 306a (block 416) . The method then terminates at block 418.

In response to determining that application control rules 310a-n identify at least one unauthorized portion (s) of metadata 308a for requesting application 302, MAU 117 creates temporary media copy 316 of requested media 306a having temporary metadata 318 which excludes only those unauthorized portions of metadata 308a (block 408) . At block 410, MAU 117 generates file handle 320, which provides access to temporary media copy 316, and MAU 117 and/or mobile device 200 transmits file handle 320 to requesting application 302 (block 410) . At block 412, a determination is made whether requesting application 302 has closed file handle 320. In response to MAU 117 determining that requesting application 302 has closed file handle 320, temporary media copy 316 is deleted (block 414) . The method then terminates at block 420.

In the above-described flow charts, one or more of the method processes may be embodied in a computer readable device containing computer readable code such that a series of steps are performed when the computer readable code is executed on a computing device. In some implementations, certain steps of the methods are combined, performed simultaneously or in a different order, or perhaps omitted, without deviating from the scope of the disclosure. Thus, while the method steps are described and illustrated in a particular sequence, use of a specific sequence of steps is not meant to imply any limitations on the disclosure. Changes may be made with regards to the sequence of steps without departing from the spirit or scope of the present disclosure. Use of a particular sequence is therefore, not to be taken in a limiting sense, and the scope of the present disclosure is defined only by the appended claims.

Aspects of the present disclosure are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language, without limitation. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine that performs the method for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. The methods are implemented when the instructions are executed via the processor of the computer or other programmable data processing apparatus.

FIG. 5 is a block diagram illustrating a first embodiment of an example metadata selection interface 500 that facilitates viewing and/or modification of application control rules 310a-n by a user of a device (mobile device 200) based on a selected active metadata portion, in accordance with one or more embodiments. While FIG. 5 is described with reference to mobile device 200, it is appreciated that the functionality described herein may be performed by any device that is executing MAU 117, including data processing system 100.

As illustrated, mobile device 200 displays metadata selection interface 500 within display 210. Within metadata selection interface is metadata selection field 502, which provides metadata portions 504a-n, each of which corresponds to a particular portion of metadata. In the illustrative embodiment, metadata portions 504a-n are scrolled horizontally. However, in another embodiment metadata portions 504a-n may be scrolled vertically and/or both vertically and horizontally. As illustrated, metadata portions 504a-n include location metadata 504a, date and time metadata 504b, and phone model metadata 504n. In one or more embodiments, other types of metadata portions may also be included within metadata portions 504a-n. One of the visible metadata portions 504a-n may be selected as an active metadata portion (signified by the underlining and bolding of a metadata portion selection) . In response to receiving a selection of an active metadata portion (date and time metadata 504b) , a listing of authorization selection fields 506a-n and corresponding applications 508a-n are presented, based on application control rules 310a-n, with permission data that identifies at least one application that has access to and/or that is restricted access to date and time metadata 504b. Applications 508a-n correspond to applications stored on mobile device 200. In another embodiment, applications 508a-n may also include applications executing on another device and which are configured to access media 306a-n on mobile device 200. In still another embodiment, other applications 508a-n are applications that are registered to a user of mobile device 200 that are not currently stored on mobile device 200 (e.g., applications purchased by a user and/or registered to an account associated with the user that have not yet been downloaded to mobile device 200) . In at least one embodiment, the listing of applications 508a-n may be scrolled vertically and/or horizontally.

Once authorization selection fields 506a-n and application fields 508a-n have been populated for date and time metadata 504b, a user of mobile device 200 may view the access permissions of applications 508a-n to access a portion of metadata corresponding to date and time metadata 504b within metadata 308a-n. In one embodiment, the selection of a particular authorization selection field 506 indicates that access to date and time metadata 504b is authorized for a corresponding application 508. Similarly, a blank authorization selection field 506 indicates that access to date and time metadata 504b is restricted for a corresponding application 508. In an alternate embodiment, the selection of a particular authorization selection fields 506 indicates that access to date and time metadata 504b is restricted for a corresponding application 508 and a blank authorization selection field 506 indicates that access to date and time metadata 504b is authorized for a corresponding application 508.

In one embodiment, authorization selection fields 506a-n may be individually toggled on/off by a user of mobile device 200. Thus, a user of mobile device 200 can modify the access permissions of applications 508a-n to date and time metadata 504b within metadata 308a-n by toggling on/off authorization selection fields 506a-n. The access permissions established by authorization selection fields 506a-n and/or any modifications thereto are stored within sensitive metadata restrictions 312a-n and/or sensitive metadata authorizations 314a-n. For example, as illustrated by FIG. 5, date and time metadata 504b is selected as an active metadata portion (which is signified by the underlining and bolding of date and time metadata 504b) .

Authorization selection fields

506a, 506b, and 506n are selected, which indicates that corresponding application 1 508a, application 2 508b, and application N 508n, are authorized to access date and time metadata 504b. Similarly, authorization selection fields 506c and 506d are not selected, which indicates that corresponding application 3 508b and application 4 508d are restricted from accessing date and time metadata 504b. A user of mobile device 200 may restrict application 1 508a from accessing date and time metadata 504b of metadata 308a-n by clearing authorization selection field 506a. Similarly, a user of mobile device 200 may authorize application 3 508c to access date and time metadata 504b of metadata 308a-n by selecting authorization selection field 506c.

FIG. 6 is a block diagram illustrating a second embodiment of an example metadata selection interface 600 that facilitates viewing and/or modification of application control rules 310a-n by a user of a device (mobile device 200) based on a selected active application, in accordance with one or more embodiments. While FIG. 6 is described with reference to mobile device 200, it is appreciated that the functionality described herein may be performed by any device that is executing MAU 117, including data processing system 100.

As illustrated, mobile device 200 displays metadata selection interface 600 within display 210. Within metadata selection interface 600 is metadata selection field 602, which provides a listing of applications 604a-n, each of which corresponds to a particular application. Applications 604a-n, correspond to applications stored on mobile device 200. In another embodiment, applications 604a-n may also include applications executing on another device and which are configured to access media 306a-n on mobile device 200. In still another embodiment, other applications 604a-n are applications that are registered to a user of mobile device 200 but are not currently stored on mobile device 200 (e.g., applications purchased by a user and/or registered to an account associated with the user that have not yet been downloaded to mobile device 200) . In the illustrative embodiment, the listing of applications 604a-n may be scrolled horizontally. However, in another embodiment, applications 604a-n may be scrolled vertically and/or both vertically and horizontally.

One of applications 604a-n may be selected as an active application (signified by the underlining and bolding of an application) . In response to receiving a selection of an active application (application 1 604a) , authorization selection fields 606a-n and metadata portions 608a-n are populated within the lower section of the user interface, based on application control rules 310a-n. Each of metadata portions 608a-n corresponds to at least one particular portion, type, and/or category within metadata 308a-n. As illustrated, metadata portions 608a-n include location date and time metadata 608a, location metadata 608b, manufacturer metadata 608c, model metadata 608d, and phone model metadata 608n. In one or more embodiments, other types of metadata portions may also be included within metadata portions 608a-n. In at least one embodiment, metadata portions 608a-n may be scrolled vertically and/or horizontally. Authorization selection fields 606a-n correspond to respective metadata portions 608a-n. Once authorization selection fields 606a-n and metadata portions 608a-n have been populated for the active application (application 1 604a) , a user of mobile device 200 may view the access permissions of application 1 604a to access metadata portions 608a-n. In one embodiment, the selection of a particular authorization selection field 606 indicates that application 1 604a is authorized to access corresponding metadata portion 608. Similarly, a blank authorization selection field 606 indicates that application 1 604a is restricted from accessing corresponding metadata portion 608. In another embodiment, the selection of a particular authorization selection field 606 indicates that application 1 604a is restricted from accessing corresponding metadata portion 608 and a blank authorization selection field 606 indicates that application 1 604a is authorized to access corresponding metadata portion 608.

In one embodiment, authorization selection fields 606a-n may be individually toggled on/off by a user of mobile device 200. Thus, a user of mobile device 200 can modify the access permissions of application 1 604a to access metadata portions 608a-n within metadata 308a-n by toggling on/off authorization selection fields 606a-n. The access permissions established by authorization selection fields 606a-n and/or any modifications thereto are stored within sensitive metadata restrictions 312a-n and/or sensitive metadata authorizations 314a-n. For example, as illustrated by FIG. 6, application 1 604a is selected as an active application (which selection is signified by the underlining and bolding of the application) .

Authorization selection fields

606a and 606n are selected, which indicates that application 1 604a is authorized to access date and time metadata 608a and resolution metadata 608n. Similarly,

authorization selection fields

606b, 606c, and 606d corresponding to location metadata 608b, manufacturer metadata 608c, and model metadata 608d are not selected, which indicates that application 1 604a is restricted from accessing those metadata portions. A user of mobile device 200 may restrict application 1 604a from accessing date and time metadata 608a of metadata 308a-n by clearing authorization selection field 606a. Similarly, a user of mobile device 200 may authorize access by application 1 604a to manufacturer metadata 608c of metadata 308a-n by selecting authorization selection field 606c.

As will be further appreciated, the processes in embodiments of the present disclosure may be implemented using any combination of software, firmware, or hardware. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment or an embodiment combining software (including firmware, resident software, micro-code, etc. ) and hardware aspects that may all generally be referred to herein as a “circuit, ” “module, ” or “system. ” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable storage device (s) having computer readable program code embodied thereon. Any combination of one or more computer readable storage device (s) may be utilized. The computer readable storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (anon-exhaustive list) of the computer readable storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage device may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

While the disclosure has been described with reference to example embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the disclosure. In addition, many modifications may be made to adapt a particular system, device, or component thereof to the teachings of the disclosure without departing from the scope thereof. Therefore, it is intended that the disclosure not be limited to the particular embodiments disclosed for carrying out this disclosure, but that the disclosure will include all embodiments falling within the scope of the appended claims.

The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the disclosure. The described embodiments were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

A method comprising:

identifying a request from a requesting application to access media content that contains sensitive metadata；

in response to identifying the request, accessing an application control rule to determine whether the application control rule contains at least one sensitive metadata restriction that restricts access by the requesting application to at least one unauthorized portion of the sensitive metadata； and

in response to determining the application control rule contains at least one sensitive metadata restriction:

generating a temporary copy of the media content that excludes the unauthorized portion of the sensitive metadata； and

delivering, to the requesting application, a file handle to access the temporary copy.
The method of claim 1, further comprising:

in response to receiving a request from the requesting application to close the file handle, deleting the temporary copy.
The method of claim 1, further comprising:

intercepting the request from a transmission to a default application programming interface (API) , wherein the request is sent from the requesting application to the default API；

generating the file handle to access the temporary copy； and

providing the generated file handle to the default API, wherein the default API delivers the file handle to the requesting application.
The method of claim 1, wherein the request is a read-only request and is received at a file open application program interface (API) .
The method of claim 1, wherein the temporary copy of the media content includes at least one authorized portion of the sensitive metadata that is not restricted by the at least one sensitive metadata restriction.
The method of claim 1, wherein the application control rule identifies at least one sensitive metadata authorization that enables access to at least one authorized portion of the sensitive metadata that is different from the at least one unauthorized portion.
The method of claim 6, wherein the application control rule identifies at least one of a sensitive metadata restriction and a sensitive metadata authorization for each of a plurality of applications.
A device comprising:

an input component；

an output component；

a processor communicatively coupled to the input component and the output component and which executes a media access utility, wherein:

the processor identifies a request from a requesting application to access media content that contains sensitive metadata；

in response to identifying the request, the processor accesses an application control rule to determine whether the application control rule contains at least one sensitive metadata restriction that restricts access by the requesting application to at least one unauthorized portion of the sensitive metadata； and

in response to determining the at least one sensitive metadata restriction:

the processor generates a temporary copy of the media content that excludes the unauthorized portion of the sensitive metadata； and

the processor delivers an output containing a file handle to access the temporary copy to the requesting application.
The device of claim 8, wherein:

in response to receiving a request from the requesting application to close the file handle, the processor deletes the temporary copy.
The device of claim 8, wherein:

the processor intercepts the request from a transmission to a default application programming interface (API) , wherein the request is sent from the requesting application to the default API；

the processor generates the file handle to access the temporary copy； and

the processor provides the generated file handle to the default API, wherein processor delivers the output containing the file handle to the requesting application via the default API.
The device of claim 8, wherein the request is a read-only request and is received at a file open application program interface (API) .
The device of claim 8, wherein the temporary copy of the media content includes at least one authorized portion of the sensitive metadata that is not restricted by the at least one sensitive metadata restriction.
The device of claim 8, wherein the application control rule identifies at least one sensitive metadata authorization that enables access to at least one authorized portion of the sensitive metadata that is different from the at least one unauthorized portion.
The device of claim 13, wherein the application control rule identifies at least one of a sensitive metadata restriction and a sensitive metadata authorization for each of a plurality of applications.
A computer program product comprising:

a computer readable storage device； and

program code on the computer readable storage device that when executed by a processor associated with a device, the program code enables the device to provide the functionality of:

identifying a request from a requesting application to access media content that contains sensitive metadata；

in response to identifying the request, accessing an application control rule to determine whether the application control rule contains at least one sensitive metadata restriction that restricts access by the requesting application to at least one unauthorized portion of the sensitive metadata； and

in response to determining the application control rule contains at least one sensitive metadata restriction:

generating a temporary copy of the media content that excludes the unauthorized portion of the sensitive metadata； and

delivering, to the requesting application, a file handle to access the temporary copy.
The computer program product of claim 15, wherein the program code further comprises code that enables the device to provide the functionality of:

in response to receiving a request from the requesting application to close the file handle, deleting the temporary copy.
The computer program product of claim 15, wherein the program code further comprises code that enables the device to provide the functionality of:

intercepting the request from a transmission to a default application programming interface (API) , wherein the request is sent from the requesting application to the default API；

generating the file handle to access the temporary copy； and

providing the generated file handle to the default API, wherein the default API delivers the file handle to the requesting application.
The computer program product of claim 15, wherein the request is a read-only request and is received at a file open application program interface (API) .