Computer-implemented system and methods for providing encrypted protected data

A computer implemented method to provide encrypted protected data in response to an unauthorized access request and unencrypted protected data in response to an authorized access request may include the following steps: receiving a first access request for accessing protected data; determining if the first access request identifies the protected data through a specified namespace; and returning an encrypted version of the protected data in response to the first access request if the first access request did not identify the protected data through the specified namespace. Optionally, the method may include the steps of: receiving a second access request to access the protected data; determining if the second access request identifies the protected data through the specified namespace; and returning an unencrypted version of the protected data in response to the second access request only if the second access request identifies the protected data through the specified namespace.

FIELD OF THE INVENTION

This patent specification relates to the field of cyber security and computer data protection. More specifically, this patent specification relates to systems and methods for preventing exfiltration of computer data.

BACKGROUND

Hackers, unauthorized users, ransomware, or malicious software are increasingly gaining unauthorized access to sensitive and private data. Once they have access to this data, they commonly will transfer or exfiltrate the data to a remote location and use the data for personal gain or to blackmail the victim, for example by asking for a ransom. Data exfiltration can damage the reputation of a company, be costly to remediate, result in the theft or misappropriation of sensitive business information, and have detrimental consequences for individuals whose personal information may have been affected.

Therefore, a need exists for novel computer-implemented systems and methods for cyber security and computer data protection. A further need exists for novel computer-implemented systems and methods that are configured to prevent unauthorized access and exfiltration of sensitive and private data.

BRIEF SUMMARY OF THE INVENTION

According to one embodiment consistent with the principles of the invention, a computer implemented method to provide encrypted protected data in response to an unauthorized access request and unencrypted protected data in response to an authorized access request is provided. In some embodiments, the method may include the following steps: receiving a first access request for accessing protected data; determining if the first access request identifies the protected data through a specified namespace; and returning an encrypted version of the protected data in response to the first access request if the first access request did not identify the protected data through the specified namespace.

In further embodiments, the protected data may be stored in an unencrypted state and encrypted after receiving the first data access request.

In further embodiments, the protected data may be encrypted prior to receiving the first access request.

In still further embodiments, the method may include the steps of: receiving a second access request to access the protected data; determining if the second access request identifies the protected data through the specified namespace; and returning an unencrypted version of the protected data in response to the second access request only if the second access request identifies the protected data through the specified namespace.

DETAILED DESCRIPTION OF THE INVENTION

Although the terms “first”, “second”, etc. are used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, the first element may be designated as the second element, and the second element may be likewise designated as the first element without departing from the scope of the invention.

As used in this application, the term “about” or “approximately” refers to a range of values within plus or minus 10% of the specified number. Additionally, as used in this application, the term “substantially” means that the actual value is within about 10% of the actual desired value, particularly within about 5% of the actual desired value and especially within about 1% of the actual desired value of any variable, element or limit set forth herein.

Definitions

As used herein, the terms “computer” and “computing device” refer to a machine, apparatus, or device that is capable of accepting and performing logic operations from software code. The term “application”, “software”, “software code”, “source code”, “script”, or “computer software” refers to any set of instructions operable to cause a computer to perform an operation. Software code may be operated on by a “rules engine” or processor. Thus, the methods and systems of the present invention may be performed by a computer or computing device having a processor based on instructions received by computer applications and software.

The term “electronic device” as used herein is a type of computer comprising circuitry and configured to generally perform functions such as recording audio, photos, and videos; displaying or reproducing audio, photos, and videos; storing, retrieving, or manipulation of electronic data; providing electrical communications and network connectivity; or any other similar function. Non-limiting examples of electronic devices include: personal computers (PCs), workstations, servers, laptops, tablet PCs including the iPad, cell phones including iOS phones made by Apple Inc., Android OS phones, Microsoft OS phones, Blackberry phones, digital music players, or any electronic device capable of running computer software and displaying information to a user, memory cards, other memory storage devices, digital cameras, external battery packs, external charging devices, and the like. Certain types of electronic devices which are portable and easily carried by a person from one location to another may sometimes be referred to as a “portable electronic device” or “portable device”. Some non-limiting examples of portable devices include: cell phones, smartphones, tablet computers, laptop computers, wearable computers such as Apple Watch, other smartwatches, Fitbit, other wearable fitness trackers, Google Glasses, and the like.

The term “client device” as used herein is a type of computer or computing device comprising circuitry and configured to generally perform functions such as recording audio, photos, and videos; displaying or reproducing audio, photos, and videos; storing, retrieving, or manipulation of electronic data; providing electrical communications and network connectivity; or any other similar function. Non-limiting examples of client devices include: personal computers (PCs), workstations, servers, laptops, tablet PCs including the iPad, cell phones including iOS phones made by Apple Inc., Android OS phones, Microsoft OS phones, Blackberry phones, Apple iPads, Anota digital pens, digital music players, or any electronic device capable of running computer software and displaying information to a user, memory cards, other memory storage devices, digital cameras, external battery packs, external charging devices, and the like. Certain types of electronic devices which are portable and easily carried by a person from one location to another may sometimes be referred to as a “portable electronic device” or “portable device”. Some non-limiting examples of portable devices include: cell phones, smartphones, tablet computers, laptop computers, tablets, digital pens, wearable computers such as Apple Watch, other smartwatches, Fitbit, other wearable fitness trackers, Google Glasses, and the like.

The term “computer readable medium” as used herein refers to any medium that participates in providing instructions to the processor for execution. A computer readable medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks, such as the hard disk or the removable media drive. Volatile media includes dynamic memory, such as the main memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that make up the bus. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

As used herein the term “data network” or “network” shall mean an infrastructure capable of connecting two or more computers such as client devices either using wires or wirelessly allowing them to transmit and receive data. Non-limiting examples of data networks may include the internet or wireless networks or (i.e. a “wireless network”) which may include Wifi and cellular networks. For example, a network may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), a mobile relay network, a metropolitan area network (MAN), an ad hoc network, a telephone network (e.g., a Public Switched Telephone Network (PSTN)), a cellular network, a Zigbee network, or a voice-over-IP (VoIP) network.

As used herein, the term “database” shall generally mean a digital collection of data or information. The present invention uses novel methods and processes to store, link, and modify information such digital images and videos and user profile information. For the purposes of the present disclosure, a database may be stored on a remote server and accessed by a client device through the internet (i.e., the database is in the cloud) or alternatively in some embodiments the database may be stored on the client device or remote computer itself (i.e., local storage). A “data store” as used herein may contain or comprise a database (i.e. information and data from a database may be recorded into a medium on a data store).

New computer-implemented systems and methods to provide encrypted protected data such as which ay be used for preventing data exfiltration are discussed herein. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.

The present invention will now be described by example and through referencing the appended figures representing preferred and alternative embodiments. As perhaps best shown byFIG.1, an illustrative example of some of the physical components which may comprise a system to provide encrypted protected data127(“the system”)100according to some embodiments is presented. The system100is configured to facilitate the transfer of data and information between one or more access points103, client devices400, and servers300over a data network105, while preventing data that is protected by the system100from being exfiltrated, such as by hackers, data thieves, and other unauthorized users101B, ransomware and other malicious software102, etc. Each client device400may send data to and receive data from the data network105through a network connection104with an access point103. Optionally, the system100may comprise one or more data stores308accessible by a server300that may contain one or more databases.

In this example, the system100comprises at least one client device400(but preferably more than two client devices400) configured to be operated by one or more users101. Client devices400can be mobile devices, such as laptops, tablet computers, personal digital assistants, smart phones, and the like, that are equipped with a wireless network interface capable of sending data to one or more servers300with access to one or more data stores308over a network105such as a wireless local area network (WLAN). Additionally, client devices400can be fixed devices, such as desktops, workstations, and the like, that are equipped with a wireless or wired network interface capable of sending data to one or more servers300with access to one or more data stores308over a wireless or wired local area network105. The present invention may be implemented on at least one client device400and/or server300programmed to perform one or more of the steps described herein. In some embodiments, more than one client device400and/or server300may be used, with each being programmed to carry out one or more steps of a method or process described herein.

Generally, the system100may be configured to return data in response to receiving an access request121for data. The system100may characterize access requests121as authorized access requests122and unauthorized access requests123. In preferred embodiments, the system100may be configured to provide encrypted protected data127in response to an unauthorized access request123and unencrypted protected data126in response to an authorized access request122. Typically, an authorized access request122may comprise an access request121from an authorized user101A, the authorized user101A comprising an individual or entity that is authorized to view, manipulate, or otherwise access the data identified in an access request121they have generated. An unauthorized access request123may comprise an access request121from an unauthorized user101B or malicious software102, the unauthorized user101B comprising an individual or entity that is not authorized to view, manipulate, or otherwise access the data identified in an access request121they have generated (e.g., hackers, data thieves), and the malicious software102comprising data exfiltration software (e.g., ransomware). By identifying if an access request121is authorized or unauthorized, the system100may prevent data exfiltration by providing encrypted protected data127to a client device400in response to an unauthorized access request123, such as which may be generated by an unauthorized user101B or malicious software102, while providing unencrypted protected data126to a client device400in response to an authorized access request122, such as which may be generated by an authorized user101A that generated an authorized access request122.

Referring now toFIG.2, in an exemplary embodiment, a block diagram illustrates a server300of which one or more may be used in the system100or standalone and which may be a type of computing platform. The server300may be a digital computer that, in terms of hardware architecture, generally includes a processor302, input/output (I/O) interfaces304, a network interface306, a data store308, and memory310. It should be appreciated by those of ordinary skill in the art thatFIG.2depicts the server300in an oversimplified manner, and a practical embodiment may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (302,304,306,308, and310) are communicatively coupled via a local interface312. The local interface312may be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface312may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface312may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor302is a hardware device for executing software instructions. The processor302may be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the server300, a semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the server300is in operation, the processor302is configured to execute software stored within the memory310, to communicate data to and from the memory310, and to generally control operations of the server300pursuant to the software instructions. The I/O interfaces304may be used to receive user input from and/or for providing system output to one or more devices or components. User input may be provided via, for example, a keyboard, touch pad, and/or a mouse. System output may be provided via a display device and a printer (not shown). I/O interfaces304may include, for example, a serial port, a parallel port, a small computer system interface (SCSI), a serial ATA (SATA), a fibre channel, Infiniband, iSCSI, a PCI Express interface (PCI-x), an infrared (IR) interface, a radio frequency (RF) interface, and/or a universal serial bus (USB) interface.

The network interface306may be used to enable the server300to communicate on a network, such as the Internet, the data network105, the enterprise, and the like, etc. The network interface306may include, for example, an Ethernet card or adapter (e.g., 10BaseT, Fast Ethernet, Gigabit Ethernet, 10 GbE) or a wireless local area network (WLAN) card or adapter (e.g., 802.11a/b/g/n). The network interface306may include address, control, and/or data connections to enable appropriate communications on the network. A data store308may be used to store data.

The data store308is a type of memory and may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store308may incorporate electronic, magnetic, optical, and/or other types of storage media. In one example, the data store308may be located internal to the server300such as, for example, an internal hard drive connected to the local interface312in the server300. Additionally, in another embodiment, the data store308may be located external to the server300such as, for example, an external hard drive connected to the I/O interfaces304(e.g., SCSI or USB connection). In a further embodiment, the data store308may be connected to the server300through a network, such as, for example, a network attached file server.

The memory310may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.), and combinations thereof. Moreover, the memory310may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory310may have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor302. The software in memory310may include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. The software in the memory310may include a suitable operating system (O/S)314and one or more programs320.

The operating system314essentially controls the execution of other computer programs, such as the one or more programs320, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The operating system314may be, for example Windows NT, Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2003/2008/2012/2016 (all available from Microsoft, Corp. of Redmond, WA), Solaris (available from Sun Microsystems, Inc. of Palo Alto, CA), LINUX (or another UNIX variant) (available from Red Hat of Raleigh, NC and various other vendors), Android and variants thereof (available from Google, Inc. of Mountain View, CA), Apple OS X and variants thereof (available from Apple, Inc. of Cupertino, CA), or the like. The one or more programs320may be configured to implement the various processes, algorithms, methods, techniques, etc. described herein.

Referring toFIG.3, in an exemplary embodiment, a block diagram illustrates a client device400of which one or more may be used in the system100or the like and which may be a type of computing platform. The client device400can be a digital device that, in terms of hardware architecture, generally includes a processor402, input/output (I/O) interfaces404, a radio406, a data store408, and memory410. It should be appreciated by those of ordinary skill in the art thatFIG.3depicts the client device400in an oversimplified manner, and a practical embodiment may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (402,404,406,408, and410) are communicatively coupled via a local interface412. The local interface412can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface412can have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface412may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor402is a hardware device for executing software instructions. The processor402can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the client device400, a semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the client device400is in operation, the processor402is configured to execute software stored within the memory410, to communicate data to and from the memory410, and to generally control operations of the client device400pursuant to the software instructions. In an exemplary embodiment, the processor402may include a mobile optimized processor such as optimized for power consumption and mobile applications.

The I/O interfaces404can be used to receive data and user input and/or for providing system output. User input can be provided via a plurality of I/O interfaces404, such as a keypad or keyboard404B, touch screen404C, camera, microphone, mouse404D, buttons, bar code scanner, voice recognition, eye gesture, and the like. As used herein, a mouse404D includes any hand (or other body part) operated device for positioning a cursor or performing selections and interactions with data displayed via a digital display, such as a mouse, scroll ball, scroll bar, track ball, digital pen or stylus, mouth controlled mouse, foot controlled mouse, etc. System output can be provided via a display screen, such as a liquid crystal display (LCD), light emitting diode (LED) display, touch screen display, and the like. The I/O interfaces404can also include, for example, a global positioning service (GPS) radio, a serial port, a parallel port, a small computer system interface (SCSI), an infrared (IR) interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, and the like. The I/O interfaces404can include a graphical user interface (GUI)404A that enables a user to interact with the client device400. Additionally, the I/O interfaces404may be used to output notifications to a user and can include a speaker or other sound emitting device configured to emit audio notifications, a vibrational device configured to vibrate, shake, or produce any other series of rapid and repeated movements to produce haptic notifications, and/or a light emitting diode (LED) or other light emitting element which may be configured to illuminate to provide a visual notification.

The radio406enables wireless communication to an external access device or network. Any number of suitable wireless data communication protocols, techniques, or methodologies can be supported by the radio406, including, without limitation: RF; IrDA (infrared); Bluetooth; ZigBee (and other variants of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum; Long Term Evolution (LTE); cellular/wireless/cordless telecommunication protocols (e.g. 3G/4G, etc.); wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless hospital or health care facility network protocols such as those operating in the WMTS bands; GPRS; proprietary wireless data communication protocols such as variants of Wireless USB; and any other protocols for wireless communication.

The data store408may be used to store data and is therefore a type of memory. The data store408may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store408may incorporate electronic, magnetic, optical, and/or other types of storage media.

The memory410may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, etc.), and combinations thereof. Moreover, the memory410may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory410may have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor402. The software in memory410can include one or more software programs420, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example ofFIG.3, the software in the memory system410includes a suitable operating system (O/S)414and programs420.

The operating system414essentially controls the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The operating system414may be, for example, LINUX (or another UNIX variant), Android (available from Google), Symbian OS, Microsoft Windows CE, Microsoft Windows 7 Mobile, Microsoft Windows 10, iOS (available from Apple, Inc.), webOS (available from Hewlett Packard), Blackberry OS (Available from Research in Motion), and the like.

The programs420may include various applications, add-ons, etc. configured to provide end user functionality with the client device400. For example, exemplary programs420may include, but not limited to, a web browser, social networking applications, streaming media applications, games, mapping and location applications, electronic mail applications, financial applications, and the like. In a typical example, the end user typically uses one or more of the programs420along with a network105to manipulate information of the system100.

Referring now toFIG.4a block diagram showing a schematic diagram of the system100and some exemplary software rules engines and components which may optionally be configured to run on one or more servers300and/or client devices400according to various embodiments described herein are illustrated. The engines131,132, may be in electronic communication so that data may be readily exchanged between the engines131,132, and one or more engines131,132, may read, write, or otherwise access data of the system100.

In some embodiments, the system100may include a request engine131and an encryption engine132which may be run by a processor402of a client device400. In further embodiments, the system100may include a request engine131and an encryption engine132which may be run by a processor302of a server300. In further embodiments, a request engine131and/or encryption engine132may be configured to run on one or more client devices400and/or servers300with data transferred to and from a request engine131and/or encryption engine132that may be in communication with a data store308through a network105. It should be understood that the functions attributed to the engines131,132, described herein are exemplary in nature, and that in alternative embodiments, any function attributed to any engine131,132, may be performed by one or more other engines131,132, or any other suitable processor logic.

The system100may comprise one or more request engines131. A request engine131may comprise or function as request logic stored in a memory310,410, which may be executable by the processor302,402, of a server300and/or client device400. Generally, a request engine131may comprise a driver or program or module which may run in Kernel Mode and may preferably handle all the file access requests121in a Windows, Linux, macOS, or other operating system. In some embodiments, a request engine131may comprise a file system filter driver or kernel driver. For example, a request engine131may comprise a Microsoft Windows driver that extends or modifies the function of peripheral devices or supports a specialized device in the personal computer that is inserted into the existing Driver Stack to perform the function of handling all the file access requests121. A request engine131may comprise a filter driver that can filter I/O operations for one or more file systems or file system volumes. Depending on the nature of the driver, filter can mean log, observe, modify, or even prevent. Typical applications for file system filter drivers include antivirus utilities, encryption programs, and hierarchical storage management systems.

In some embodiments, a request engine131may receive access requests121and may return data in response to each access request121. An access request121may comprise a request to access data, such as which may be stored in a data store308,408, of a server300and/or client device400. A request engine131may characterize or determine each access request121to be an authorized access request122or an unauthorized access request123. In preferred embodiments, a request engine131may return data requested in an authorized access request122as unencrypted data and may return data requested in an unauthorized access request123as encrypted data. In further embodiments, a request engine131may perform one or more other functions described herein.

The system100may comprise one or more encryption engines132. An encryption engine132may comprise or function as encryption logic stored in a memory310,410, which may be executable by the processor302,402, of a server300and/or client device400. Generally, an encryption engine132may be configured to encrypt the data of one or more protected files124of the system100. A protected file124may comprise a file that one or more users101have identified or chosen as being a file that is to be protected by the system100. The data of a protected file124may be referred to as protected data. In preferred embodiments, an encryption engine132may generate an encrypted version of the one or more protected files124that are identified in an unauthorized access request123. In some embodiments, an encryption engine132may dynamically generate an encrypted version of the one or more protected files124in an unauthorized access request123after the system100receives the unauthorized access request123, such as by using a streaming encryption protocol or any other suitable encryption protocol. In further embodiments, an encryption engine132may generate an encrypted version of one or more protected files124before the system100receives an unauthorized access request123for the one or more protected files. In some embodiments, encrypted versions of one or more protected files124that are generated before receiving an access request121for those protected files124may be stored in a cached format on a client device400and/or server300. In some embodiments, encrypted versions of one or more protected files124that are generated before receiving an access request121for those protected files124may be stored in a cache repository on a client device400and/or server300. An encryption engine132may generate an encrypted version of a protected file124(generating an encrypted version of the protected data of the protected file) using any suitable encryption method or protocol, such as AES, RSA, DES, 3DES, RC5, RC6, etc. In further embodiments, an encryption engine132may perform one or more other functions described herein.

FIG.5shows a block diagram of an example of a computer-implemented method to identify a file that should be protected (“the method”)500according to various embodiments described herein. In some embodiments, the method500may be used to identify one or more files of a data store308,408, of a server300and/or client device400which the system100is to treat as protected files. One or more steps of the method500may be performed by a request engine131and/or encryption engine132which may be executed by a computing device processor, such as a processor302(FIG.2) and/or a processor402(FIG.3).

In some embodiments, the method500may start501and a namespace for protected files124may be identified in step502. Preferably, a namespace identified in step502may be visible to the user101of the client device400on the graphical user interface (GUI)404A of their client device400as a storage location. In computing, a namespace is a set of signs (names) that are used to identify and refer to objects of various kinds. A namespace ensures that all of a given set of objects have unique names so that they can be easily identified. Namespaces are commonly structured as hierarchies to allow reuse of names in different contexts. Namespaces are assigned a universally unique identifier (UUID), also referred to as a globally unique identifier (GUID), which is a 128-bit label used for information in computer systems. Generally, a GUID for a namespace may be hidden, such that the GUID for the namespace is only available to the graphical user interface (GUI)404A displaying the namespace, and therefore is only associated with an access request121generated by a user101of the client device400having the graphical user interface (GUI)404A displaying the namespace. In this manner, the GUID of a specified namespace125displayed on a graphical user interface (GUI)404A may be hidden from unauthorized users101B and malicious software102.

In some embodiments, a namespace for protected files124may be identified by a request engine131creating the namespace on a client device400or server300and informing the user101of the client device400that the namespace is to be used to access files displayed in the namespace (protected files). In further embodiments, a namespace for protected files124may be identified by a request engine131by receiving user101input that identifies an existing namespace as a namespace that is to be used to access protected files124(files displayed in the namespace). Once a namespace is identified as a namespace for protected files, the request engine131and the system100may treat or identify that namespace as a specified namespace125.

In step503, input describing one or more files that are to be protected may be received by the request engine131. Input describing one or more files that are to be protected may be generated by a user101via an I/O interface404of their client device400, such as by the user101saving one or more files to the specified namespace125, by the user101copying one or more files to the specified namespace125, by the user101selecting or identifying an existing namespace in step502that already has files in it as a specified namespace125, etc.

In step504, the one or more files of step503may be associated with the specified namespace125by the request engine131. Once a file is associated with the specified namespace125, thereby becoming a protected file124of the system100, the request engine131will return the data of the file in an encrypted format unless the access request121for that file identifies the file via the specified namespace125. In some embodiments, the one or more files may be associated with the specified namespace125by changing the identifier of the files to include the globally unique identifier (GUID) of the specified namespace125.

FIG.6depicts a block diagram of an example of a computer-implemented method to identify the intention of accessing the content of a protected file124and to present a separate view of the file's content transparently based on the identified intention (“the method”)600according to various embodiments described herein. In some embodiments, the method600may be used to identify or characterize an access request121as being authorized or unauthorized by identifying the intention of the access request121. One or more steps of the method600may be performed by a request engine131and/or encryption engine132which may be executed by a computing device processor, such as a processor302(FIG.2) and/or a processor402(FIG.3).

In some embodiments, the method600may start601and an access request121for accessing a protected file124may be received by a request engine131in step602. Generally, an access request121may comprise a digital request to open or view, copy, move, share, upload, or otherwise access the data of a file. As an example, a user101may generate an access request121for a file by providing input, via their client device400, selecting to attach a file to an email. As another example, a user101may generate an access request121for a file by providing input, via their client device400, selecting to move a file from one data store308,408, to another data store308,408.

In decision block603, the request engine131may determine if the access request121identifies the protected file124via a specified namespace125by determining if the access request121includes the globally unique identifier (GUID) of a specified namespace125. In some embodiments, an access request121may be provided via user input that is received from a keyboard404B. In further embodiments, an access request121may be provided via user input that is received from a touch screen404C. In further embodiments, an access request121may be provided via user input that is received from a mouse404D. Generally, by using a keyboard404B, touch screen404C, mouse404D, or other I/O interface404A of a client device400that displays a specified namespace125on a graphical user interface404A to provide user input that generates an access request121for a protected file124by selecting the protected file124through the displayed specified namespace125, the generated access request121may include the globally unique identifier (GUID) of the specified namespace125which may be read by the request engine131so that the request engine131may determine that the access request121identifies the protected file124via a specified namespace125. If the access request121identifies the protected file124via a specified namespace125, the method600may proceed to step604. If the access request121does not identify the protected file124via a specified namespace125, the method600may proceed to step605.

In step604, the request engine131may identify the intention of the access request121as authorized. By identifying the intention of the access request121as authorized, the request engine131may process and identify the access request121as an authorized access request122. The intention of an access request121may be identified by the request engine131in order to determine if the access request121is an authorized access request122or an unauthorized access request123. Generally, an access request121generated by an authorized user101A may have authorized intentions for accessing the protected file124identified in an access request121(authorized access request122) as the authorized user101A comprises an individual or entity that is authorized to view, manipulate, or otherwise access the data identified in an access request121they have generated. After step604, the method600may finish606.

In step605, the request engine131may identify the intention of the access request121as unauthorized. By identifying the intention of the access request121as unauthorized, the request engine131may process and identify the access request121as an unauthorized access request123. The intention of an access request121may be identified by the request engine131in order to determine if the access request121is an authorized access request122or an unauthorized access request123. Generally, an access request121generated by an unauthorized user101B or malicious software102may have unauthorized intentions for accessing the protected file124identified in an access request121(unauthorized access request123) as an unauthorized user101B or malicious software102comprises an individual or entity that is not authorized to view, manipulate, or otherwise access the data identified in an access request121they have generated. After step605, the method600may finish606.

FIG.7depicts a block diagram of an example of a computer-implemented method to provide encrypted protected data127in response to an unauthorized access request123and unencrypted protected data126in response to an authorized access request122(“the method”)700according to various embodiments described herein. In some embodiments, the method700may be used to facilitate the transfer of data and information between one or more access points103, client devices400, and servers300over a data network105, while preventing data that is protected by the system100from being exfiltrated, such as by hackers, data thieves, and other unauthorized users101B, ransomware and other malicious software102, etc. By providing encrypted protected data127in response to an unauthorized access request123, the method700may prevent data that is protected by the system100from being exfiltrated and/or otherwise accessed by an unauthorized individual (unauthorized user101B) or unauthorized software (malicious software102). One or more steps of the method700may be performed by a request engine131and/or encryption engine132which may be executed by a computing device processor, such as a processor302(FIG.2) and/or a processor402(FIG.3).

In some embodiments, the method700may start701and a specified namespace125may be displayed on a graphical user interface (GUI)404A of a client device400in step702. In preferred embodiments, a specified namespace125may be displayed on a graphical user interface (GUI)404A by being displayed as a data storage location, such as by having a name, icon, etc., by a file manager, operating system, or other user interface program420running on the client device400.

In some embodiments, the method700may comprise step703and/or step704. For example, the method700may be used to process at least one access request121so that the method700includes step703or step704. As another example, the method700may be used to process at least two access requests121, with one being determined to be authorized and the other being determined to be unauthorized, so that the method700includes steps703and step704.

In optional step703, a first access request121for accessing protected data may be received by a request engine131. In optional step704, a second access request121for accessing protected data may be received by a request engine131. Generally, an access request121may comprise a digital request to open or view, copy, move, share, upload, or otherwise access the data of a file. As a first example, malicious software102may generate an access request121for a file by providing input, via their client device400, selecting to move a file from one data store308,408, to another data store308,408, such as for data exfiltration purposes. As a second example, a user101may generate an access request121for a file by providing input, via their client device400, selecting to open a file in a word processing program. After receiving an access request121in one or both of steps703and704, the method700may proceed to decision block705.

In decision block705, the request engine131may determine if each access request121received by the system100identifies a protected file124via a specified namespace125. In some embodiments, an access request121may be provided via user input that is received from a keyboard404B. In further embodiments, an access request121may be provided via user input that is received from a touch screen404C. In further embodiments, an access request121may be provided via user input that is received from a mouse404D. Generally, by using a keyboard404B, touch screen404C, mouse404D, or other I/O interface404A of a client device400that displays a specified namespace125on a graphical user interface404A to provide user input that generates an access request121for a protected file124by selecting the protected file124through the displayed specified namespace125, the generated access request121may include the globally unique identifier (GUID) of the specified namespace125which may be read by the request engine131so that the request engine131may determine that the access request121identifies the protected file124via a specified namespace125. If the access request121does not identify the protected file124via a specified namespace125, the method700may proceed to step706. If the access request121identifies the protected file124via a specified namespace125, the method700may proceed to step707.

In step706, an encrypted version of the protected data may be returned in response to the access request121by the request engine131if the access request121did not identify the protected data through the specified namespace125. Continuing the first example, a first access request121generated by the malicious software102for data exfiltration purposes in step703would not identify the protected file124via the specified namespace125since the globally unique identifier (GUID) is hidden from the unauthorized program/malicious software102, and the request engine131may return an encrypted version of the protected data to the unauthorized program/malicious software102. In some embodiments, the protected data returned in step706may be dynamically encrypted by an encryption engine132. In further embodiments, the protected data may be encrypted using a streaming encryption protocol, such as AES-128, HC-256, RC4, or any other suitable encryption protocol or method. In further embodiments, an encryption engine132may generate an encrypted version of one or more protected files124before the system100receives an unauthorized access request123for the one or more protected files. In some embodiments, encrypted versions of one or more protected files124that are generated before receiving an access request121for those protected files124may be stored in a cached format on a client device400and/or server300. In some embodiments, encrypted versions of one or more protected files124that are generated before receiving an access request121for those protected files124may be stored in a cache repository on a client device400and/or server300. After step706, the method700may finish708.

In step707, an unencrypted version of the protected data may be returned in response to the access request121if the access request121identifies the protected data through the specified namespace125. In preferred embodiments, the unencrypted version of the protected data may be returned by displaying the unencrypted version of the protected data on the graphical user interface404A of the client device400that was used to generate the access request121identifying the protected data through the specified namespace125. Continuing the second example, a second access request121generated by a user101to open a file in a word processing program on their client device400in step704would identify the protected file124via the specified namespace125since the globally unique identifier (GUID) is included in the second access request121by the user101selecting the protected file124through the specified namespace125displayed on the GUI404A of their client device400, and the request engine131may return an unencrypted version of the protected data to the user101(thereby being an authorized user101A). After step707, the method700may finish708.

It will be appreciated that some exemplary embodiments described herein may include one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches may be used. Moreover, some exemplary embodiments may be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer, server, appliance, device, etc. each of which may include a processor to perform methods as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory), a Flash memory, and the like.

Additionally, the logic flows and structure block diagrams described in this patent document, which describe particular methods and/or corresponding acts in support of steps and corresponding functions in support of disclosed structural means, may also be utilized to implement corresponding software structures and algorithms, and equivalents thereof. The processes and logic flows described in this specification can be performed by one or more programmable processors (computing device processors) executing one or more computer applications or programs to perform functions by operating on input data and generating output.

The computer system may also include a main memory, such as a random-access memory (RAM) or other dynamic storage device (e.g., dynamic RAM (DRAM), static RAM (SRAM), and synchronous DRAM (SDRAM)), coupled to the bus for storing information and instructions to be executed by processor. In addition, the main memory may be used for storing temporary variables or other intermediate information during the execution of instructions by the processor. The computer system may further include a read only memory (ROM) or other static storage device (e.g., programmable ROM (PROM), erasable PROM (EPROM), and electrically erasable PROM (EEPROM)) coupled to the bus for storing static information and instructions for the processor.

The computer system may also include a disk controller coupled to the bus to control one or more storage devices for storing information and instructions, such as a magnetic hard disk, and a removable media drive (e.g., floppy disk drive, read-only compact disc drive, read/write compact disc drive, compact disc jukebox, tape drive, and removable magneto-optical drive). The storage devices may be added to the computer system using an appropriate device interface (e.g., small computer system interface (SCSI), integrated device electronics (IDE), enhanced-IDE (E-IDE), direct memory access (DMA), or ultra-DMA).

The computer system may also include a display controller coupled to the bus to control a display, such as a cathode ray tube (CRT), liquid crystal display (LCD), light emitting diode (LED) display, or any other type of display, for displaying information to a computer user. The computer system may also include input devices, such as a keyboard and a pointing device, for interacting with a computer user and providing information to the processor. Additionally, a touch screen could be employed in conjunction with display. The pointing device, for example, may be a mouse, a trackball, or a pointing stick for communicating direction information and command selections to the processor and for controlling cursor movement on the display. In addition, a printer may provide printed listings of data stored and/or generated by the computer system.

The computer system performs a portion or all of the processing steps of the invention in response to the processor executing one or more sequences of one or more instructions contained in a memory, such as the main memory. Such instructions may be read into the main memory from another computer readable medium, such as a hard disk or a removable media drive. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

Various forms of computer readable media may be involved in carrying out one or more sequences of one or more instructions to processor for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions for implementing all or a portion of the present invention remotely into a dynamic memory and send the instructions over the air (e.g. through a wireless cellular network or WiFi network). A modem local to the computer system may receive the data over the air and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to the bus can receive the data carried in the infrared signal and place the data on the bus. The bus carries the data to the main memory, from which the processor retrieves and executes the instructions. The instructions received by the main memory may optionally be stored on storage device either before or after execution by processor.

The computer system also includes a communication interface coupled to the bus. The communication interface provides a two-way data communication coupling to a network link that is connected to, for example, a local area network (LAN), or to another communications network such as the Internet. For example, the communication interface may be a network interface card to attach to any packet switched LAN. As another example, the communication interface may be an asymmetrical digital subscriber line (ADSL) card, an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of communications line. Wireless links may also be implemented. In any such implementation, the communication interface sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

The network link typically provides data communication to the cloud through one or more networks to other data devices. For example, the network link may provide a connection to another computer or remotely located presentation device through a local network (e.g., a LAN) or through equipment operated by a service provider, which provides communication services through a communications network. In preferred embodiments, the local network and the communications network preferably use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link and through the communication interface, which carry the digital data to and from the computer system, are exemplary forms of carrier waves transporting the information. The computer system can transmit and receive data, including program code, through the network(s) and, the network link and the communication interface. Moreover, the network link may provide a connection through a LAN to a client device or client device such as a personal digital assistant (PDA), laptop computer, tablet computer, smartphone, or cellular telephone. The LAN communications network and the other communications networks such as cellular wireless and Wi-Fi networks may use electrical, electromagnetic or optical signals that carry digital data streams. The processor system can transmit notifications and receive data, including program code, through the network(s), the network link and the communication interface.