Digital photography has long overtaken film as the medium used to capture, document, and store images. In particular, the integration of digital cameras into most smartphones has resulted in a steep rise in the quantity of photographs captured by the users of these smartphones.
Privacy is one of the primary concerns of many users, particularly with respect to personal or sensitive images. Photographs stored on smartphones and digital cameras are not inherently secure or protected from tampering or hacking, either directly or through a network connection. Additionally, cloud storage of photographs, such as on social media sites, brings its own set of challenges and privacy concerns. Many social media sites share confidential images and photographs of users with third parties, and others are susceptible to hacking or data theft.
Additionally, the process for securing captured images can frequently be cumbersome and deter many users from adequately protecting captured images. Typically, the user must install or set up some hardware or software that allows the user to set up access controls on particular folders stored on the hardware or in memory. The user must then manually transfer each image file they would like to protect to the appropriate location in the hardware or memory.
Furthermore, even the process described above still has glaring security weaknesses. In particular, the time period between when an image is captured and when the image is transferred to a secured folder provides a window of opportunity to hackers or bad actors to access the image after capture but prior to transfer to the secured folder. Within this window, no security features or access controls limit access to the captured images (outside of basic security features that may be part of the general operating environment).
Accordingly, improvements are needed in systems and methods for secure image storage.
While devices, adapters, methods, apparatuses, and computer-readable media are described herein by way of examples and embodiments, those skilled in the art recognize that devices, adapters, methods, apparatuses, and computer-readable media for image capture devices and secure image storage are not limited to the embodiments or drawings described. It should be understood that the drawings and description are not intended to be limited to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims. Any headings used herein are for organizational purposes only and are not meant to limit the scope of the description or the claims. As used herein, the word “may” is used in a permissive sense (i.e., meaning having the potential to) rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.
As shown in
The image capture device also includes a controller configured to store the captured image (or captured video) in the memory. The controller is configured to store the captured image in the protected region when the switch is in the first state during image capture and store the captured image in the unprotected region when the switch is in the second state during image capture. The controller can additionally be configured to detect the state of the switch during image capture. For example, at the time of photo (or video) capture the controller detect the state or position of the switch and store a value in the memory (or in a controller sub-memory) that corresponds to the state of the switch at the capture time. This value can then be used when determining a storage destination for the captured image.
The controller can be a hardware controller or a software controller, such as an application, program, script, or process running on the image capture device. For example, the controller can be a hardware controller of the camera or other hardware components or of the entire image capture device. Controller can also be a process or script such as an operating system process or an application running on the image capture device.
The switch can be a mechanical switch that is configured to be toggled between the first state and the second state by a mechanical force. For example, the switch can be a lever or similar structure. The switch can be toggled by a user of the image capture device. The switch can also be a depressible button configured to toggle the switch between the first state and the second state. For example, if the switch is a button, then the user can push both the shutter button (a button coupled to the shutter) and the switch button at the same time to toggle protected mode and store captured images in the protected region. Otherwise, if the user pushes only the shutter button, then captured images can be stored in the unprotected region. The switch can also be a variety of other mechanical structures, such as knob, depressible button that is configured to lock in two different positions, a rotating gear, or any other mechanical structure.
As shown in
The second image capture device also includes a variable having a first state and a second state. Variable can optionally have more than two states, such as three or four states or infinite states. Variable can be, for example, a Boolean variable, an integer (able to be set to at least “0” and “1”), a character, a string, or any other type of object. For example, the variable can be a Boolean variable called “SecureMode” and having two states (true and false). The variable can be an integer variable called “SecureMode” and having at least two states (0 and 1, in addition infinite other states). When more than two states are used, each state can correspond to a level of protection. For example (state 1=no protection, state 2=authentication, state 3=authentication+encryption, state 4=authentication+encryption+masking). In this example, four different regions of memory would be designated accordingly and the captured image would be stored in one of the four regions by the controller depending on the state during image capture.
As shown in
The second image capture device also includes a controller configured to store the captured image (or captured video) in the memory. The second controller is configured to store the captured image in the protected region when the variable is in the first state during image capture and store the captured image in the unprotected region when the variable is in the second state during image capture. The controller can additionally be configured to detect the state of the variable during image capture. For example, at the time of photo (or video) capture the controller detect the state of the variable and store a value in the memory (or in a controller sub-memory) that corresponds to the state of the variable at the capture time. This value can then be used when determining a storage destination for the captured image (or video).
The controller can be a hardware controller or a software controller, such as an application, program, script, or process running on the image capture device. For example, the controller can be a hardware controller of the camera or other hardware components or of the entire image capture device. Controller can also be a process or script such as an operating system process or an application running on the image capture device.
The second image capture device can additionally include a display comprising a user interface. The user interface can be the interface of an operating system on the second image capture device or the interface of an application running on the second image capture device, such as a camera application or other mobile application. The user interface can be configured to receive an input to toggle the variable between the first state and the second state. The input can be one or more of a touch input, a swipe gesture, or a selection. A touch input can include a timed or pressure sensitive touch.
For example, the user can depress a shutter icon or other icon on a user interface for an extended period of time to (e.g., more than half a second, more than 1 second, more than 2 seconds, etc.) to set the value of the variable to a value that corresponds to a protected state. When the user releases the shutter, the captured image would then be stored in the protected region. A quick press of the shutter icon can, by contrast, not change the value of the variable to a value that corresponds to a protected state, resulting in the captured image being stored in unprotected region. In this example, the variable can by default be reset to a value that corresponds to an unprotected state after every photo or video capture. In another example, the user can depress a camera icon on the user interface that is configured to open the camera (or a specific camera application) for an extended period of time to (e.g., more than half a second, more than 1 second, more than 2 seconds, etc.) to set the value of the variable to a value that corresponds to a protected state when the camera is opened. The variable can then stay in that state for the duration of the camera session or until the user toggles it back.
In another example, the user can swipe on the user interface or on a portion of the user interface to change the variable value and toggle between secure and unsecure modes. The change in modes can be reflected on the user interface using one or more visual cues, such as icons, notifications, color changes, sounds, or visual effects. The change in modes can also communicated to the user using audio. For example, the image capture device can make a first sound for protected mode and a different sound for unprotected mode. The image capture device can also make a sound every time the mode is changed (such as a “ding” sound).
The controllers shown in
The controller can also directly communicate with hardware on the image capture device in response to detecting a change in state of a switch (as shown in
At step 301 a first region accessible only to an authenticated user and a second region accessible to a non-authenticated user is stored in a memory of an image capture device. Storing can include designating the first region and the second region and/or provisioning the two regions. For example, the controller can designate the first region as a protected region and the second region as a non-protected region. Storing can also include storing a table, mapping, or other data structure with a correspondence between regions of memory and authenticated access or non-authenticated access. For example, one or more first chunks of memory can be mapped to protected storage (authenticated access) and one or more second chunks of memory can be mapped to non-protected storage (non-authenticated access).
At step 302 a variable having a first state and a second state is stored in the memory of the image capture device. As discussed earlier, this variable can be stored in the same, or a different, memory than the protected and unprotected regions.
At step 303 an image is captured by a camera of the image capture device. This can be in response to a user input, such as a shutter press or input on a user interface.
At step 304 a state of the variable during image capture is detected by controller and can be stored for subsequent use when determining a destination of the captured image.
At step 305 the controller stores the captured image in the memory. As discussed earlier, the controller is configured to store the captured image in the first region when the variable is in the first state during image capture and store the captured image in the second region when the variable is in the second state during image capture.
The method shown in
At step 401 a first region accessible only to an authenticated user and a second region accessible to a non-authenticated user is stored in a memory of an image capture device. Storing can include designating the first region and the second region and/or provisioning the two regions. For example, the controller can designate the first region as a protected region and the second region as a non-protected region. Storing can also include storing a table, mapping, or other data structure with a correspondence between regions of memory and authenticated access or non-authenticated access. For example, one or more first chunks of memory can be mapped to protected storage (authenticated access) and one or more second chunks of memory can be mapped to non-protected storage (non-authenticated access).
At step 402 an image is captured by a camera of the image capture device. This can be in response to a user input, such as a shutter press or input on a user interface.
At step 403 a state of a switch during image capture is detected by controller and can be stored for subsequent use when determining a destination of the captured image. As discussed with respect to
At step 404 the controller stores the captured image in the memory. As discussed earlier, the controller is configured to store the captured image in the first region when the variable is in the first state during image capture and store the captured image in the second region when the variable is in the second state during image capture.
The method shown in
In addition to all of the above disclosures and embodiments, when data corresponding to captured images or videos is stored in the protected region of memory, it can be stored with specific metadata attributes that further identify the images or videos as private and further identify the type of private photo (this can be set based upon user preferences). When data corresponding to captured images or videos is stored in the unprotected region of memory, it can be stored with standard metadata attributes.
As shown above, the image capture device(s) and method(s) disclosed herein allow a user to designate a private and protected image prior to capturing the image by toggling a switch or changing the value of a variable through a user interface.
One or more of the above-described techniques can be implemented in or involve one or more specialized computer systems.
With reference to
The memory 1020 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. The memory 1020 may store software instructions 1080 for implementing the described techniques when executed by one or more processors. Memory 1020 can be one memory device or multiple memory devices. As discussed earlier, the memory will necessary include specialized features such as the protected and unprotected regions discussed with respect to
A computing environment may have additional features. For example, the computing environment 1000 includes storage 1040, one or more input devices 1050, one or more output devices 1060, and one or more communication connections 1090. An interconnection mechanism 1070, such as a bus, controller, or network interconnects the components of the computing environment 1000. Typically, operating system software or firmware (not shown) provides an operating environment for other software executing in the computing environment 1000, and coordinates activities of the components of the computing environment 1000.
The storage 1040 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing environment 1000. The storage 1040 may store instructions for the software 1080.
The input device(s) 1050 may be a touch input device such as a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scanning device, a digital camera, remote control, or another device that provides input to the computing environment 1000. The output device(s) 1060 may be a display, television, monitor, printer, speaker, or another device that provides output from the computing environment 1000.
The communication connection(s) 1090 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
Implementations can be described in the general context of computer-readable media. Computer-readable media are any available media that can be accessed within a computing environment. By way of example, and not limitation, within the computing environment 1000, computer-readable media include memory 1020, storage 1040, communication media, and combinations of any of the above.
Of course,
Having described and illustrated the principles of our invention with reference to the described embodiment, it will be recognized that the described embodiment can be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computing environment, unless indicated otherwise. Various types of general purpose or specialized computing environments may be used with or perform operations in accordance with the teachings described herein. Elements of the described embodiment shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to which the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.
This application claims priority to U.S. Provisional Application No. 62/643,520, filed Mar. 15, 2018, the disclosure of which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
62643520 | Mar 2018 | US |