Title of Invention: Electronically backing up files using steganography Abstract: Steganography is leveraged to store additional data in the existing data on any given electronic storage. For example, a first request to store a first electronic file is received. Based on the first request, a determination is made as to whether one or more second electronic files meet one or more predefined criteria for being a carrier file for steganography. If the one or more second electronic files meet the one or more predefined criterion for being a carrier file, the first electronic file is electronically stored into the one or more second electronic files using steganography. Detailed Description: Part general_description_paragraphs: Part BACKGROUND: Technical Field The present disclosure generally relates to electronic storage of files, and more particularly, to leveraging steganography to store or back up electronic files. Related Art Rapid advances have been made in the past several decades in the fields of computer technology and telecommunications, and businesses and end users now engage in electronic activities more than ever. A plethora of electronic files may be created as a result of these electronic activities. For example, these electronic files may include emails, word processing documents, spreadsheets, pictures, videos, music, podcasts, e-books, etc. As more and more electronic files are created, the storage of the electronic files becomes an important concern. What is needed is an efficient, low cost, and yet secure way to electronically store or backup electronic files. Part DETAILED DESCRIPTION: It is to be understood that the following disclosure provides many different embodiments, or examples, for implementing different features of the present disclosure. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. Various features may be arbitrarily drawn in different scales for simplicity and clarity. As computing and communication technologies continue to advance, electronic file creation becomes increasingly more prevalent. For example, more and more people are turning to emails or electronic texting to communicate with one another instead of sending physical letters. As another example, rather than taking pictures with cameras that use film, users have turned to digital cameras and mobile telephones to electronically record pictures and/or videos. Similarly, digital music and e-books have mostly replaced conventional cassette tapes/CDs and paper books, respectively, as the preferred media of user consumption. As more and more electronic files are being created, the electronic storage of these files has become an increasing concern. According to the various aspects of the present disclosure, electronic files are stored using steganography to leverage existing electronic files that are already stored on an electronic storage/medium, the details of which are discussed below. FIG. 1 is a simplified high-level block diagram view of an infrastructure (or system) 50 that enables the storing or backup of electronic files using steganography. The infrastructure 50 includes a user 60, a service provider 70, one or more electronic devices 90, and a cloud storage 95. The user 60 may be a consumer or a worker for a business entity. The user 60 may generate electronic files (for example using the one or more electronic devices 90 discussed below) that can be stored or backed up electronically using steganography. The service provider 70 may be an entity that develops a steganography engine that allows the electronic storing or backing up of files using steganography. In some embodiments, the service provider 70 may be an app developer, and the steganography engine may be implemented as (or within) a mobile app, for example an app that can be downloaded and installed via the APPLE APP STORE®, or GOOGLE PLAY®, etc. In other embodiments, the service provider 70 may be a software company that develops the steganography engine as part of a mobile operating system or desktop/laptop operating system, or as a program that can be installed on a mobile device or a desktop/laptop device. In other words, the functionalities provided by the steganography engine may be built into the mobile or desktop/laptop operating system, or the steganography engine may be downloaded as a software program and installed on a mobile or desktop/laptop device of the user 60. In some embodiments, the service provider 70 may be a financial institution or a third party payment provider, for example PayPal®, Inc. of San Jose, Calif., or a similar entity. The user 60 may also have an account with the service provider 70 in some embodiments. To facilitate the ensuing discussions, the concept of steganography is briefly explained below. Generally, steganography involves the practice of concealing information within other data, but the concealment is performed in a way such that it is not immediately transparent or obvious, so as to avoid attracting attention or scrutiny. Used in the computer technology context, steganography may be used to conceal the information of one electronic file (referred to as a source file herein) into the content of another electronic file (referred to as a carrier file herein). The content of the carrier file is manipulated in a way to allow the information of the source file to be stored therein, without drawing attention to the fact that the carrier file itself has been altered. One technique for implementing steganography is the “Least Significant Bit” (LSB) method. For example, an image file may be used as a carrier file for steganography. The image file may include a plurality of pixels, each one of which may be expressed as a plurality of binary digits (e.g., 101001101). The value of the binary digits may correspond to the color or hue of the pixel. The LSB method of steganography may intentionally change the least significant bit (e.g., the last digit) of each of the pixels, so that binary data may be stored in the pixels. As a simplified example, suppose that the binary data of 1100 needs to be stored, and suppose that four image pixels are available to be used as carriers for steganography, where the pixels have original binary values of 101001100, 100011101, 111100000, and 100011001, respectively. In this example, the original least significant bit values of the four pixels are 0, 1, 0, and 1, respectively. By applying the LSB steganography method, the least significant bit values are changed into 1, 1, 0, and 0, respectively, so as to store the binary data value of 1100 into these four pixels. The altered pixels now have binary values of 101001101, 100011101, 111100000, and 100011000, respectively. Note that not all of the pixels' binary values are necessarily changed. If their original least significant bit binary value is the same as the binary value that needs to be stored, then no change needs to be made. In this example above, the modification of the four pixels allows the binary data of 1100 to be stored therein, and as a result, two of the pixels' values (i.e., the first pixel and the last pixel) are altered. However, since each pixel has a relatively large binary value, the alteration of the least significant bit of the binary value does not change the overall color appearance of the pixel ifischer@example.com. For example, if the original pixel represents a green color, then the altered pixel may contain a bit of blue, but the pixel still appears mostly green to the human eye. In other words, the relatively large binary value of the pixel, coupled with the small modification to the binary value, means that the overall change of the pixel (or of the image as a whole) is almost imperceptible to the human eye. Thus, a neutral observer may not be aware of the fact that information has been encoded or stored into the image file via steganography, but a user aware of this fact can extract the encoded information from the image file later. Another technique for implementing steganography is known as the “F5” algorithm. The F5 algorithm typically uses a common image format such as JPEG as the carrier medium. Instead of replacing the LSBs of quantized Discrete Cosine Transformation (DCT) coefficients with the message bits, the absolute value of the coefficient is decreased by one if it needs to be modified. The F5 algorithm embeds message bits into randomly-chosen DCT coefficients and employs matrix embedding that minimizes the necessary number of changes to hide a message of certain length. In the embedding process, the message length and the number of non-zero AC coefficients (e.g., the AC coefficients of a DCT transform) are used to determine the best matrix embedding that minimizes the number of modifications of the cover image. Compared to the LSB technique, the F5 algorithm has better embedding efficiency and higher embedding capacity, as well as offering resistance against both visual and statistical attacks. Of course, the LSB and F5 methods discussed above are just some examples of steganography, which may be implemented using a variety of techniques. Some of these additional steganography techniques are described in more detail in the article “A Survey of Steganography and Steganalysis Technique in Image, Text, Audio and Video as Cover Carrier” appearing in the Journal of Global Research in Computer Science, Volume 2, No. 4, April 2011, authored by Souvik Bhattacharyya, Indradip Banerjee, and Gautam Sanyal, the contents of which are hereby incorporated by reference in its entirety. For reasons of simplicity, other additional techniques of steganography are not discussed in detail herein. Referring back to FIG. 1, the steganography engine (e.g., developed by the service provider 70) may be implemented on one or more of the electronic devices 90. As examples, the electronic devices 90 may include a computer 90A, a mobile telephone 90B, a computer tablet 90C, a peripheral device 90D (e.g., a wearable device such as a smart watch), a network-capable “smart” household appliance 90E (e.g., a refrigerator or a television set), or a cloud storage device 90F. These electronic devices 90 may communicate with each other, or with one or more computers of the service provider 70, under a suitable wired or wireless telecommunications protocol. While the devices 90A-90E may be located near the user 60 (e.g., at the user 60's home or work), the cloud storage device 90F may be located remotely from the user 60. The electronic devices 90A-90E may communicate with the cloud storage 90F to send and/or retrieve data to and/or from the cloud storage 95. FIG. 2 is a simplified block diagram that illustrates how an electronic file 100 (referred to as a source file) can be stored or backed up using steganography according to various aspects of the present disclosure. In various embodiments, the electronic file 100 may include an electronic file with visual content (e.g., a JPEG picture, a AVI video, etc.), audio content (e.g., an MP3 music file, a WAV podcast, etc.), and/or textual content (e.g., a MICROSOFT WORD® document, a spreadsheet, a presentation slide, an email, a text message, a spreadsheet, an e-book, etc.). In some embodiments, the electronic file 100 may be stored or backed up electronically at a request of the user 60. In other embodiments, the electronic file 100 may be stored or backed up electronically automatically without a specific involvement from the user 60. The electronic file 100 may be stored or backed up electronically using steganography in any electronic device that has an electronic memory, for example any one of the electronic devices 90A-90F discussed above with reference to FIG. 1. As an example, electronic devices 90A, 90B, and 90C are illustrated as the suitable electronic devices for storing the electronic file 100 using steganography, though it is understood that the same concept applies to the devices 90D-90F. The electronic devices 90A-90C may each include one or more existing electronic files, which may serve as carrier files for storing the electronic file 100. As non-limiting examples, the electronic device 90A may include a plurality of electronic files such as electronic files 110-111, the electronic device 90B may include a plurality of electronic files such as electronic files 120-121, and the electronic device 90C may include a plurality of electronic files such as electronic files 130-131. The electronic files 110-111, 120-121, and 130-131 may be different types of files, such as video files, image files, audio files, etc. Using steganography, the electronic file 100 may be stored or backed up into one or more of the files 110-111, 120-121, and/or 130-131. The storing or backing up of the electronic file 100 may be implemented using any steganography technique, for example the LSB technique discussed above. The electronic storing or backing up of the electronic file 100 via steganography offers improved security and/or privacy. For example, steganography allows the electronic file 100 to be stored in a secretive manner, such that its existence may not be readily apparent to a hacker or other users that should not otherwise have access to the electronic file 100. Since the existence of the electronic file 100 is not readily known, it is more difficult for hackers or the other users to gain access to the electronic file 100. In some embodiments, the electronic storing or backing up of the electronic file 100 is implemented with redundancy. The redundancy may include a local level redundancy and/or a global level redundancy. For local level redundancy, multiple copies or instances of the electronic file 100 may be stored in the same electronic device. For example, a copy of the electronic file 100 may be stored in the electronic file 110 on the electronic device 90A, while another copy of the electronic file 100 may be stored in the electronic file 111 on the electronic device 90A. For global level redundancy, multiple copies or instances of the electronic file 100 may be stored on a plurality of different electronic devices. For example, a copy of the electronic file 100 may be stored in the electronic file 110 on the electronic device 90A, another copy of the electronic file 100 may be stored in the electronic file 120 on the electronic device 90B, and yet another copy of the electronic file 100 may be stored in the electronic file 130 on the electronic device 90C. Of course, local level redundancy and global level redundancy may be simultaneously implemented, such that multiple copies of the electronic file 100 are stored in different carrier files within the same electronic device, and similarly across multiple different electronic devices. In some embodiments, the redundancy herein may employ a Redundant Array of Inexpensive/Independent Disks (RAID) technique. RAID works by storing data on multiple disks and allowing input/output (I/O) operations to overlap in a balanced way, though the data may still appear to an operating system as a single logical hard disk. The use of multiple disks increases fault tolerance. RAID may also involve disk mirroring or disk striping. In disk mirroring, identical data are copied onto more than one disk. In disk striping, each disk's storage space is partitioned into units ranging from a sector (512 bytes) up to several megabytes. The stripes of the disks may be interleaved and addressed in order. A brief summary for each of plurality of RAID levels is provided below, such as RAID 1, RAID 5, RAID 10, etc. RAID 0: Minimum of 2 disks and has striped blocks, but no redundancy. RAID 0 offers the best performance but has no fault tolerance. RAID 1: Minimum of 2 disks to duplicate the storage of data. No striping. Either disk can be read at the same time. RAID 3: Uses striping across multiple disks and dedicates at least one disk to store parity information for the purposes of error checking and correction. Data recovery may be performed by calculating the exclusive OR of the information recorded on the other drives. RAID 5: Minimum of 3 disks but typically involves 5 or more disks, and is based on block-level striping with parity. The parity information is striped across each drive, allowing the array to function even if one drive were to fail. The read and write operations can span multiple drives. RAID 5 offers good performance and good redundancy. Is better suited for heavy read operations, but not ideal for heavy write operations. RAID 10: Minimum of 4 disks. RAID 10 is a combination of RAID 1 and 0. The data is mirrored, and the mirrors are striped (this is also referred to as a “stripe of mirrors”. RAID 10 offers excellent redundancy since blocks are mirrored, as well as excellent performance since the blocks are striped. Regardless of which RAID technique (or any other redundancy technique) is used herein, redundancy offers enhanced security and more robust protection of the electronic file 100. For example, if the electronic file 100 is only stored in a single carrier file, then if the carrier file is corrupted or inadvertently deleted, the electronic file 100 could become irretrievably lost. As local redundancy is implemented, the corruption or deletion of one carrier file will not affect the integrity of the electronic file 100, as the electronic file 100 can still be recovered from a different carrier file on the same electronic device. Global redundancy offers even more security and robustness, since even if one of the electronic devices is damaged or lost, the electronic file 100 can still be recovered from one or more of the carrier files located on the other electronic devices. Redundancy also offers protection against ransomware. Ransomware may refer to malicious software programs that infiltrate the victim's computing devices, and then threaten to delete the contents of the infiltrated devices or otherwise block the user's access to the contents, unless the user pays a ransom to the perpetrator of the ransomware. Using the redundancy discussed above (especially global level redundancy), even if one of the electronic devices on which the electronic file 100 is stored is infected with the ransomware, the user may still retrieve a copy of the electronic file 100 from an unaffected electronic device. It is also understood that an entirety of the electronic file 100 need not be stored into any single one of the carrier files. For example, the electronic file 100 may be divided or broken up into a plurality of portions or segments, and each divided portion may be stored into a respective one of the carrier files using a steganography technique. Local or global redundancy may also be used to implement the storing of the divided segments of the electronic file 100. FIG. 3 is a flowchart illustrating a method 200 of storing electronic files using steganography according to embodiments of the present disclosure. One or more steps of the method 200 may be performed at least in part by a steganography engine discussed above. The method 200 includes a step 210, in which a table of contents is created. The table of contents maps out how (e.g., what steganography technique is used) and/or where (e.g., on which device and/or which carrier file) each source file (e.g., the electronic file 100 of FIG. 2) is stored. As an example, the table of contents created in step 210 may specify that multiple copies of the electronic file 100 (discussed above with reference to FIG. 2) are stored in the carrier files 110-111 on the electronic device 90A using the LSB steganography technique, as well as in the carrier files 120-121 on the electronic device 90B using a steganography technique other than LSB. An entry may exist in the table of contents for each of a plurality of stored source files. In some embodiments, the table of contents is accessible by the user 60, for example upon being authenticated after entering the correct user credentials (e.g., username and password). In this manner, the user may know how and/or where each of the source files is stored. In other embodiments, the table of contents may be hidden from the user 60 and is only accessible by the software modules of the steganography engine. The method 200 includes a step 220, in which a request to store one or more source files (e.g., the electronic file 100 discussed above) is received. This request may be generated by a software program or by a user such as the user 60. In some embodiments, the steganography engine provides a user interface, through which the user 60 may upload or otherwise specify the electronic files to be stored. For example, the user 60 may select the electronic source files from a source folder and “drag-and-drop” the selected electronic file into a destination folder that is reserved for files to be stored using steganography. In some embodiments, the user 60 may be allowed to specify the steganography technique that should be applied to store each of the electronic files. Furthermore, the user 60 may also be allowed to specify the exact electronic device(s) and/or the redundancy level for each of the electronic source files to be stored. The method 200 includes a step 230, in which the source files of step 220 are stored electronically in one or more carrier files using steganography. Again, the storing of the electronic files is performed by the steganography engine, which may occur automatically “in the background” without additional involvement from the user 60. The method 200 includes a step 240, in which the table of contents created in step 210 is updated. For example, the table of contents is updated to reflect how and/or where the electronic files discussed in steps 220 and 230 have been stored. It is understood that in some embodiments, the step 240 need not necessarily be performed after the step 230 but may instead be performed before the step 230, or concurrently with the step 230. The method 200 includes a step 250, in which a request to retrieve the one or more stored source files is received. This request may be generated by a software program or by a user such as the user 60. For example, the one or more electronic files may be needed to execute another program, and thus the program may automatically make a call to the steganography engine when the one or more source files are needed. Alternatively, the user 60 may specifically send a request to the steganography engine to retrieve the one or more source files. For example, the one or more source files may include digital pictures, and the request in step 250 is issued when the user 60 wishes to view the pictures. The method 200 includes a step 260, in which the one or more source files are reconstructed based on the information retrieved from the carrier files. In embodiments where local or global redundancy are used, the steganography engine may access any one of the carrier files (or a plurality of the carrier files, if each carrier file only stores a portion of the one or more source files) to retrieve the information that is stored in the accessed carrier files. Based on the retrieved information, and knowing which type of steganography technique has been used to encode the information into the carrier file(s), the steganography engine may then reconstruct the source file accordingly. In theory, most, if not all, existing files in any given electronic storage medium can serve as carrier files for steganography. However, some of these files may be better candidates for serving as carrier files than others. Some aspects of the present disclosure involve determining which of these files qualify as more suitable candidates for serving as the carrier files. An example of this is discussed below with reference to FIG. 4, which illustrates an example method 300 of identifying suitable files for serving as carrier files in steganography. The method 300 includes a step 310, in which an electronic device is designated as the storage medium to search for carrier files. For example, the user 60 may designate the electronic device 90A (e.g., a laptop computer) as the electronic device to search for carrier files. This means that the electronic files residing on the electronic device 90A will be searched subsequently to see if they qualify as a suitable carrier file for steganography. In some embodiments, the user 60 may be able to designate not only the electronic device, but also one or more specific directories or folders on the electronic device in which the search should be conducted. For example, the user 60 may designate “photos” folder in the C:\ drive of the electronic device 90A as the directory/folder in which the search for carrier files should be conducted. The method 300 includes a step 320, in which the designated electronic device is searched for suitable carrier files. The searching in step 320 may include electronically scanning the files in the designated electronic device (or in one or more of the designated folders thereof) for one or more attributes. If the searched file has one of these attributes, it may be deemed suitable for being used as a carrier file. According to the various aspects of the present disclosure, there may be a variety of attributes that could indicate whether the scanned file is suitable to serve as a carrier file. One example attribute is the frequency of modification to the scanned file. The steganography engine may determine how often the scanned file is modified, whether by the user or by another program running on the electronic device. The more frequently the scanned file is modified, the less suitable it is to be used as a carrier file. The rationale is that, information from the source file will need to be written or encoded into the existing data of the carrier file via steganography. However, if the carrier file is frequently modified (whether by the user or by another entity), that modification may corrupt the information of the source file written into the carrier file, which is undesirable. Alternatively, additional measures would have to be taken to prevent the inadvertent overwriting of the information encoded into the carrier file. Thus, it would be better if the carrier file is hardly ever modified, in which case the corruption of the source file information encoded therein via steganography is less of a concern. In some embodiments, the steganography engine may assign a carrier file suitability score to the scanned file, where a higher score means that the scanned file is more suitable to be used as a carrier file, and a lower score means that the scanned file is less suitable to be used as a carrier file. In these embodiments, the more frequently the scanned file is modified, the lower the score it may receive, and vice versa. For example, the steganography may set a predefined threshold for the modification rate as once per year. If the scanned file is modified less than once per year, it may receive a carrier file suitability score greater than the predefined threshold, and thus may be used hereinafter as a carrier file. If the scanned file is modified more than once per year, it may receive a carrier file suitability score lower than the predefined threshold, and thus may not be used hereinafter as a carrier file. It is also understood that different attributes may be evaluated for different types of files. For example, if the scanned file is a type of file that includes visual content—for example if the file is an image file (e.g., JPEG, GIF, BITMAP, etc.) or a video file (e.g., MP4, AVI, WMV, MOV, FLV, etc.)—the attribute may include whether the visual content contains one or more humans. In some embodiments, the determination of whether or not the visual content contains humans may be performed by scanning the visual content to look for human faces using image recognition techniques. For example, the scanning may look for a set of objects resembling human eyes, etc. If the visual content contains one or more humans, then the scanned file may be deemed not suitable (or less suitable) for being used as a carrier file. On the other hand, if the visual content contains no humans, then the scanned file may be deemed suitable (or more suitable) for being used as a carrier file. The rationale may be that most users value pictures/videos with humans in them, rather than pictures/videos that contain just inanimate objects. Since a carrier file being used for steganography will undergo some degree of alteration, it is more desirable to use files that are not highly valued by the user as the carrier files. Accordingly, the files where the visual content contains no humans may be better candidates for being used as carrier files. In another embodiment, determining whether a scanned file should or should not be used as a carrier file is based on user specific preferences or data. For example, if a user is known to value pictures or videos of their children over ones of adults, files with the user's children, as determined by facial recognition techniques, may be deemed inappropriate as a carrier file. If the user is known to value adult relatives in the file over adult friends in the file, the latter may be chosen as a carrier file over the former. In embodiments where the steganography engine uses a scoring system to grade the candidates for carrier files, the files with no humans may receive a higher score (indicating more suitability for being used as a carrier file), and the files with human faces may receive a lower score. In some embodiments, the value of the score may be correlated with the number of humans in the file as well. For example, if an image has multiple human faces, it may receive a lower score than if it had just one human face. If the score is below a predefined threshold (e.g., less than 5 on a scale of 1-10), then the steganography engine may deem the image file not suitable for being used as a carrier file. The steganography engine may also keep track of the locations of the human faces appearing in the image files, so that if the image file ends up being used as a carrier file, the steganography technique will be applied to portions (e.g., different locations) of the image where humans are not shown. In this manner, even if steganography alters the visual appearance in certain locations of the image, the visual appearance alteration is more likely to be done to inanimate objects (or other animals) instead of humans, and thus it is less likely to annoy the user. For video files, a plurality of sample points may be taken across the length of the video (e.g., 10 samples per minute, or 1 sample per second) to determine the number of humans in the video file. Again, the more humans appear in the video file, the lower the score (indicating that the file has a low suitability for being a carrier file) the video file may receive. If the score is below a predefined threshold (e.g., less than 5 on a scale of 1-10), then the steganography engine may deem the video file not suitable for being used as a carrier file. The steganography engine may also keep track of the human faces appearing at each of the samples taken, so that if the video file ends up being used as a carrier file, the steganography technique will be applied to portions (e.g., different time periods) of the video where humans are not shown. In this manner, even if steganography alters the visual appearance in certain segments of the video, the visual appearance alteration is more likely to be done to inanimate objects (or animals) instead of humans, and thus it is less likely to annoy the user. It is also understood that in some embodiments, the steganography engine may receive an input from the user 60, where the input designates one or more persons as persons of interest. For example, the user 60 may designate himself/herself, and members of the user 60's friends or family as humans of interest. The user 60 may be more interested in keeping the visual appearance of the humans of interest intact. In these embodiments, the steganography will apply the human detection discussed above for image files and video files only for the humans of interest, rather than just all people in general. In embodiments where the scanned file is an audio file, such as MP3 files, WAV files, etc., the attribute may include an amount (e.g., a percentage of total audio recording time) of the audio file that is either silence or noise. If the audio content contains not much silence or noise, then the audio file may be deemed not suitable (or less suitable) for being used as a carrier file. On the other hand, if the audio content contains a great deal of silence and/or noise, then the audio file may be deemed suitable (or more suitable) for being used as a carrier file. The rationale may be that most users value meaningful sounds (e.g., speech or music) in audio recordings, rather than silence or noise. Since a carrier file being used for steganography will undergo some degree of alteration, it is more desirable to use files that are not highly valued by the user as the carrier files. Accordingly, the files where the audio content contains a lot of silence or noise may be better candidates for being used as carrier files. In embodiments where the steganography engine uses a scoring system to grade the candidates for carrier files, the files with a higher percentage of the audio recording as silence or noise may receive a higher score (indicating more suitability for being used as a carrier file), and the files with a lower percentage of the audio recording as silence or noise may receive a lower score. If the score is below a predefined threshold (e.g., less than 5 on a scale of 1-10), then the steganography engine may deem the audio file not suitable for being used as a carrier file. The steganography engine may take a plurality of sample points across the length of the audio recording (e.g., 10 samples per minute, or 1 sample per second) to determine the degree of silence or noise in the audio recording. This information may be kept by the steganography engine, so that if the audio file ends up being used as a carrier file, the steganography technique will be applied to segments of the audio recording corresponding to silence or noise. In this manner, even if steganography alters the audible appearance in certain segments of the audio recording, the alteration is more likely to be done to segments that the user does not care much about, and thus it is less likely to annoy the user. Thus, files are selected as carrier files based on the value a user may place on a file or how much a file may be changed with steganography. While the above provides some examples, other ways of making such determinations are also suitable, including user designations, location where file was generated (e.g., honeymoon, vacation, anniversary), time of year (e.g., Christmas), number files of similar captured content, or other indications that altering a first file using steganography may be more acceptable to a user than altering a second file. Still referring to FIG. 4, the method 300 further includes a decision step 330 to determine whether a sufficient number of files in the electronic device been searched. In some embodiments, the sufficient number means every file in the electronic device (or in the specified directory/folder). In other embodiments, the sufficient number may be an absolute number in terms of quantity (e.g., 1000 files), or in terms of percentage (e.g., 75% of the total number of files). If the answer from the decision step 330 is no, then the method 300 loops back to step 320 again to continue the search for suitable carrier files. If the answer from the decision step 330 is yes, then the method 300 proceeds to another decision step 340 to determine whether a different electronic device (or a different directory/folder on the same electronic device) should be searched. If the answer from the decision step 340 is no, then the method 300 loops back to step 310 to look for a different electronic device (or different directory/folder) to do the searching discussed above. If the answer from the decision step 340 is yes, then the method 300 proceeds to a step 350 to finish the process for searching for suitable carrier files. The table of contents discussed above may also be updated accordingly. In other words, the updated table of contents will know which files (and their corresponding locations) will be suitable carrier files for steganography. In some embodiments, the present disclosure may also perform a “calibration” for each user 60 to gauge the user's tolerance for the amount of alteration caused by steganography. This will then allow the steganography engine to fine tune its “aggressiveness” in performing the steganography. In more detail, referring now to FIG. 5, a flowchart of a method 400 of performing a calibration according to the present disclosure is illustrated. The method 400 includes a step 410, in which a demonstration is shown to the user 60 with respect to the alteration of an example carrier file as a result of electronically storing data in the example carrier file based on a first steganography technique. For example, the first steganography technique may be the LSB technique discussed above, and the carrier file may be an image file. As a part of the demonstration, an original version of the image file and an altered version (e.g., altered after the LSB technique is applied to store information therein) of the image file are both presented to the user. In some embodiments, the “before” and “after” images may be presented side-by-side, so that the user can more clearly see what is the extent of the change in the visual appearance of the image file as a result of the application of the LSB steganography technique. The method 400 then proceeds to step 415, in which feedback from the user is received in response to the demonstrated alteration of the example carrier file in step 410. The feedback may include the user clicking an “acceptable” button or an “unacceptable” button through a user interface, or it may include the user assigning a satisfaction score through the user interface. The received feedback indicates whether (or to what extent) the user is okay with the degree of alteration to the example carrier file caused by the first steganography technique (e.g., the LSB technique in this example) herein. The method 400 then proceeds to a decision step 420 to determine whether the alteration is acceptable to the user, based on the input received from the step 415. If the answer from the decision step 420 is yes, then the method 400 proceeds to a step 425, where the first steganography technique may be used to implement the electronic storing of the source files. However, if the answer from the decision step 420 is no, then the method 400 proceeds to a step 430, where a second steganography technique may be used to implement the electronic storing of the source files. The second steganography technique is different from the first steganography technique and causes less alteration to the example carrier file than the first steganography technique. For example, the second steganography technique may not utilize the least significant bit of every single pixel of the example carrier file to store the information of the source file, but rather a subset of the pixels (e.g., every other pixel, or every third pixel). Since fewer pixels are altered, the overall alteration to the image may be less significant and thus more acceptable to the user. In other words, the second steganography technique is less aggressive than the first steganography technique. It is understood that additional steps may be performed as a part of the method 400. For example, if the user is okay or agreeable with the alteration to the image file due to the first steganography technique, the method 400 may now turn to a third steganography technique that is more aggressive than the first steganography technique. For example, the third steganography technique may involve using the least two significant bits (e.g., the last two bits of a binary digit), rather than just one bit, in order to store the information of the source file. The “before” and “after” versions of the example carrier file image are then shown to the user again, and user feedback is received, similar to steps 410-415. If the user is agreeable with the amount of alteration caused by the third steganography technique, then either the third steganography technique will be used to implement the electronic storing discussed above, or a fourth steganography technique that is even more aggressive than the third steganography technique will be used to repeat the steps 410 and 415 again. Similarly, if the user indicated that the amount of alteration caused by the second steganography technique is still not acceptable, then progressively less aggressive steganography techniques may be performed to the example carrier file to determine at what level the user is comfortable with the amount of alteration. In this manner, a suitably aggressive steganography technique will be determined in a customized manner for each individual user. This will optimize the performance of the electronic storing of files while not causing user dissatisfaction. Of course, the “calibration” process discussed herein is not limited to using carrier files with visual content, since carrier files with audio content or textual content may also be used to run the calibration discussed above. Referring now to FIG. 6, a flowchart of a method 450 is illustrated. The method 450 describes an example process flow to prevent the accidental deletion or corruption of the information of the source file that is stored in carrier files. The method 450 includes a step 455, in which a request is received to modify a carrier file. The request may come from the user 60, or it may come from one of the programs running on the electronic device on which the carrier file resides. In some embodiments, the request to modify the carrier file involves a request to write additional data to the carrier file, or to change the existing data of the carrier file. In other embodiments, the request to modify the carrier file may include a request to delete the carrier file altogether. The method 450 then proceeds to a decision step 460 to determine whether the modification of step 455 will affect the information of the source file that is stored in the carrier file via steganography according to the aspects of the present disclosure discussed above. If the modification will not affect the stored information of the source file, then the method 450 proceeds to a step 465, in which the carrier file is allowed to be modified. However, if the decision step 460 determines that the modification will affect the information of the source file stored in the carrier file (e.g., if the modification is a deletion request or will overwrite the information of the source file), the method 450 proceeds to another decision step 470 to determine whether the information has been sufficiently backed up elsewhere. For example, the information stored in the carrier file may have been backed up according to the local and/or global redundancy methods discussed above. In other words, multiple copies of the information of the source file may already be stored in other carrier files on the same electronic device, or on other electronic devices. In some embodiments, the decision step 470 involves comparing the number of redundant copies of the information stored elsewhere against a predefined threshold, and the information of the source file will be deemed to have been sufficiently backed up if the number of redundant copies meets or exceeds the predefined threshold. As an example, suppose that the predefined threshold is 5, and 10 copies of the source file have been determined to be stored in carrier files other than the carrier file that is to be modified. In that case, the decision step 470 will determine that the source file has been sufficiently backed up, and the method 450 will proceed to the step 465 to allow the carrier file to be modified. On the other hand, suppose the number of copies of the information is less than 5 (e.g., 3, or even 0), then the decision step 470 will determine that the source file has not been sufficiently backed up, and the method 450 will proceed to a step 475 to automatically store the source file in another carrier file, using the steganography techniques discussed herein. The method 450 will also perform a step 480 to update the table of contents, so that the steganography engine can accurately keep track of the most recent location(s) of the source file that is stored in one or more carrier files. In this manner, the method 450 will prevent inadvertent modification or deletion of source file information that should be stored. It is understood that in some embodiments, the steps 455-480 may be executed without the user's specific involvement or awareness that they are being performed. FIG. 7 is a flowchart illustrating a method 500 for leveraging steganography to back up electronic files. The method 500 includes a step 510, in which a first request to store a first electronic file is received. The method 500 includes a step 520 of determining that one or more second electronic files meet one or more predefined criteria for being a carrier file for steganography. In some embodiments, the determining comprises determining whether a rate at which the one or more second electronic files are electronically modified is below a predefined rate. In some embodiments, the one or more second electronic files include visual content, and the determining comprises determining whether a human presence in the visual content is below a predefined threshold. In some embodiments, a designation is received from the user of one or more humans as humans of interest, wherein the determining step comprises determining a presence of the designated humans of interest in the visual content. In some embodiments, in response to determining that the one or more second electronic files are suitable for being used as carrier files, steganography is performed only to portions of the one or more second electronic files that do not correspond to the human presence in the visual content. In some embodiments, the one or more second electronic files include audio content, and the determining step comprises determining whether an amount of silence or background noise in the audio content is above a predefined threshold. In some embodiments, in response to determining that the one or more second electronic files are suitable for being used as carrier files, steganography is performed only to portions of the one or more second electronic files that correspond to the silence or the noise in the audio content. The method 500 includes a step 530 of electronically storing the first electronic file into the one or more second electronic files using steganography. In some embodiments, the one or more second electronic files are located in a plurality of different electronic media, and the electronically storing step comprises dividing the first electronic files into a plurality of portions and electronically storing the plurality of portions into the different electronic media. The method 500 includes a step 540 of receiving a second request to modify one of the second electronic files in which the first electronic file is stored. The method 500 includes a step 550 of automatically storing, in response to the received second request, the first electronic file in another one of the second electronic files before the second electronic file is modified. It is understood that additional method steps may be performed before, during, or after the steps 510-550 discussed above. For example, in some embodiments, the method 500 may include a step of demonstrating, to a user, an alteration of an example carrier file as a result of electronically storing data in the example carrier file based on a first steganography technique. The method 500 may further include a step of receiving feedback from the user in response to the demonstrating, the feedback indicating whether the alteration of the example carrier file is acceptable to the user. In some embodiments, the method 500 may include a step of using the first steganography technique to implement the electronically storing in response to the feedback indicating that the alteration of the example carrier file is acceptable to the user, or using a second steganography technique to implement the electronically storing in response to the feedback indicating that the alteration of the example carrier file is unacceptable to the user, wherein the second steganography technique causes less alteration to the example carrier file than the first steganography technique. Based on the above discussions, it can be seen that the present disclosure offers several significant advantages over conventional electronic data storing. It is understood, however, that not all advantages are necessarily discussed in detail herein, different embodiments
{'bibliographic_information': "{'country': 'US', 'doc-number': '15797890', 'kind': 'B2', 'date': '20171030', 'extension': '292', 'invention_title': 'Electronically backing up files using steganography'}", 'source_file': './grant/2020/ipg200310.xml', 'source_data': 'USPTO-Grant'}