CROSS-REFERENCE TO RELATED APPLICATION

[0001 ] The present application claims priority from U.S. Provisional Appli cation Serial No. 62/837,524 for "Localized Data Storage and Processing" (At torney Docket No. INCOOl-PROV), filed April 23, 2019, which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

[0002] The present document relates to techniques for handling data stor age and processing in compliance with regulations that can vary from one ju risdiction to another.

DESCRIPTION OF THE RELATED ART

[0003] Governments are increasingly regulating how companies process and store their citizens' data. Ensuring global data compliance across jurisdic tions is increasingly difficult in this quickly changing regulatory environment.

SUMMARY

[0004] In various embodiments, the described system solves the problem of ensuring global data compliance across jurisdictions by enabling businesses to handle regulated data appropriately for each jurisdiction. According to vari ous embodiments, a system enables storing, securing, processing, and deliver ing data within geographic bounds of sovereign nations, in compliance with regulatory obligations, while still maintaining a centralized application stack. A network of data storage is maintained in each country, with a distributed application layer. Data storage in each country is securely managed, and data can be stored and delivered in compliance with jurisdictional regulations, without crossing borders, while still allowing a centralized application stack. As described in more detail below, in at least one embodiment, this is accom plished by using domain mapping so that a node in a specific country can serve data to a centrally managed web application.

[0005] In at least one embodiment, storing, processing, and serving data across multiple jurisdictions are accomplished by the use of an inverse dis tributed database that stores relevant slices within each country. In at least one embodiment, the system hosts and manages a network of secure data bases using a combination of top cloud providers and Tier 3 and 4 data cen ters.

[0006] The described techniques thus avoid the need for companies to set up their own networks of storage and processing across countries and to fully replicate an application stack in order to serve user interfaces in each country.

[0007] In some embodiments, a method of storing data may include, at a data store, receiving the data to be stored. Further, the method may include, at a processor, determining whether the data is regulated in a jurisdiction, and, responsive to the determination, selecting either:

• a regulated storage scheme, possibly from a plurality of regulated storage schemes, wherein the regulated storage scheme requires that the data be stored and/ or processed in the jurisdiction in ac cordance with one or more laws pertaining to the jurisdiction; or

• an unregulated storage scheme, in which the data is not required to be stored in the jurisdiction and/ or is not required to be stored in accordance with the one or more laws.

[0008] Further, if a regulated storage scheme is selected, the method may include, at the processor, following the regulated storage scheme by initiating storage of the data in the jurisdiction in accordance with the one or more laws. [0009] Selecting the storage scheme may include executing a software de veloper kit (SDK) method call of an API stored at least partially on the data store.

[0010] Selecting the storage scheme may include executing a REST API call to an API stored at least partially on the data store.

[0011 ] The method may further include, prior to initiating storage of the data, encrypting the data without storing a key for decrypting the data on the data store.

[0012] The method may further include, responsive to initiating storage of the data in the jurisdiction in accordance with the one or more laws, routing data at a router to a local data store in the jurisdiction, and storing the data at the local data store.

[0013] The method may further include, prior to routing the data to the lo cal data store, encrypting the data.

[0014] The data may include a plurality of indexed fields. Encrypting the data may include using a SHA-256 hash to encrypt the indexed fields, and us ing AES-256 symmetric encryption to encrypt the data.

[0015] The method may further include, at an input device, after storing the data, receiving user input from a user, and, responsive to receipt of the user input, retrieving the data using a hashed key of the SHA-256 hash at the router, and decrypting the data using an encryption key of the AES-256 sym metric encryption. The method may further include, at an output device, outputting the data for the user.

[0016] The data may be owned by a first owner. Encrypting the data may include using a first encryption scheme. The method may further include en crypting second data, owned by a second owner different from the first owner, using a second encryption scheme different from the first encryption scheme. The method may further include, at the router, routing second data.

[0017] The method may further include, responsive to initiating storage of the data in the jurisdiction in accordance with the one or more laws, further routing the data, at the router, to a second local data store in the jurisdiction, and, at the second local data store, storing the data.

[0018] The one or more laws may restrict transmission of the data out of the jurisdiction. The method may further include, at an input device located in the jurisdiction, after storing the data, receiving user input from a user via a web browser. Responsive to receipt of the user input, the data may be re trieved from the local data store. At an output device, a domain overlay may be used to output the data for the user via the web browser.

[0019] Receiving the user input may include receiving the user input from within a point of presence within the jurisdiction. Retrieving the data may include retrieving the data from within the point of presence.

[0020] Receiving the user input from within the point of presence may in clude receiving the user input from within a secure container. Retrieving the data from within the point of presence may include retrieving the data from within the secure container.

[0021 ] The method may further include detecting intrusion of a host of the local data store in the secure container, and, responsive to detection of the in trusion, transmitting notification of the intrusion to the user.

[0022] The method may further include processing the data directly within the container.

[0023] Other features and benefits of the technology described herein will be set forth in greater detail subsequently.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings, together with the description, illus trate several embodiments. One skilled in the art will recognize that the par ticular embodiments illustrated in the drawings are merely exemplary, and are not intended to limit scope.

[0025] Fig. 1A is a block diagram depicting a hardware architecture accord ing to one embodiment. [0026] Fig. IB is a block diagram depicting a hardware architecture in a cli ent/ server environment, according to one embodiment.

[0027] Fig. 2 is a block diagram depicting data that may be stored in con nection with localized data storage and processing, according to one em bodiment.

[0028] Fig. 3 is a block diagram depicting a system for handling of regu lated and unregulated data, according to one embodiment.

[0029] Fig. 4 is a block diagram depicting high-level architecture for im plementing a system according to the present disclosure, according to one embodiment.

[0030] Fig. 5 is a block diagram depicting encryption and secure transmis sion of data in the architecture of Fig. 4, according to one embodiment.

[0031 ] Fig. 6 is a block diagram depicting data storage in two or more sepa rate points of presence within a jurisdiction, according to one embodiment.

[0032] Fig. 7 is a block diagram depicting differential encryption of indexed fields and entire records, according to one embodiment.

[0033] Fig. 8 is a block diagram depicting retrieval of data encrypted via the differential encryption of Fig. 7, according to one embodiment.

[0034] Fig. 9 is a block diagram depicting retrieval of data encrypted via the differential encryption of Fig. 7, according to another embodiment.

[0035] Fig. 10 is a block diagram depicting tokenized data and data that has been encrypted with a searchable hash code, according to one embodiment.

[0036] Fig. 11 is a block diagram depicting retrieval of regulated data in which the regulated data is maintained in the applicable jurisdiction, accord ing to one embodiment.

[0037] Fig. 12 is a block diagram depicting retrieval of regulated data in which the regulated data is maintained in the applicable jurisdiction, accord ing to another embodiment. DET AILED DESCRIPTION OF THE EMBODIMENTS

[0038] The present document describes systems and methods for storing data in accordance with jurisdiction-specific requirements. Regulated data may be routed, stored, and retrieved in accordance with laws and regulations of the applicable jurisdiction. The applicable jurisdiction may be the region, country, state, and/ or city in which the data is generated, stored, transmitted, retrieved, and/ or used. Additionally or alternatively, the applicable jurisdic tion may otherwise have regulatory authority over the owner and/ or user of the data.

[0039] Data that is determined to be regulated may be automatically stored by the system in accordance with the applicable laws and regulations. Where mandated by the applicable laws and regulations, the data may be stored in the applicable jurisdiction, encrypted, maintained separate from other data, backed up, stored redundantly, and/ or kept within the jurisdiction as it is re trieved by a user within the jurisdiction.

System Architecture

[0040] According to various embodiments, the system can be implemented on any one or more electronic devices equipped to receive, store, process, and present information. Such an electronic device may be, for example, a desk top computer, laptop computer, smartphone, tablet computer, smart phone/ tablet ("phablet"), wearable computing device, and/ or the like. Any of a wide variety of device types, operating systems, and the like may be used. Accordingly, the following description is intended to illustrate various embodiments by way of example, rather than to limit scope.

[0041 ] Referring now to Fig. 1 A, there is shown a block diagram depicting a hardware architecture for practicing the described system, according to one embodiment. Such an architecture can be used, for example, for implement ing the techniques of the system in a computer or other device 101. Device 101 may be any electronic device. [0042] In at least one embodiment, device 101 has a number of hardware components well-known to those skilled in the art. Input device 102 can be any element that receives input from user 100, including, for example, a key board, mouse, stylus, touch-sensitive screen (touchscreen), touchpad, track ball, accelerometer, five-way switch, microphone, or the like. Input can be provided via any suitable mode, including for example, one or more of: point ing, tapping, typing, dragging, and/ or speech. In at least one embodiment, input device 102 can be omitted or functionally combined with one or more other components.

[0043] Data store 106 can be any magnetic, optical, or electronic storage de vice for data in digital form; examples include flash memory, magnetic hard drive, CD-ROM, DVD-ROM, or the like. In at least one embodiment, data store 106 stores information that can be utilized and/ or displayed according to the techniques described below. Data store 106 may be implemented in a database or using any other suitable arrangement. In another embodiment, data store 106 can be stored elsewhere, and data from data store 106 can be retrieved by device 101 when needed for processing and/ or presentation to user 100. Data store 106 may store one or more data sets, which may be used for a variety of purposes and may include a wide variety of files, metadata, and/ or other data.

[0044] In at least one embodiment, data store 106 may include data 111, storage schemes 112, encryption schemes 113, an SDK 114, and/ or other data (not shown), which may include any additional data that facilitates data stor age and/ or retrieval in compliance with jurisdiction-specific requirements. Data 111 may be the information that is to be stored in accordance with juris diction-specific requirements. Storage schemes 112 may be protocols for stor ing data 111 in accordance with the laws and regulations of one or more ju risdictions. Encryption schemes 113 may be methods of encrypting data 111, which may be indicated by storage schemes 112. SDK 114 may be a software developer kit that provides certain functions to facilitate storage of data 111 by software, which may be hosted on device 101.

[0045] In at least one embodiment, data 111, storage schemes 112, encryp tion schemes, 113 and/ or SDK 114 can be stored at another location, remote from device 101, and device 101 can access such data 111, storage schemes 112, encryption schemes 113, and/ or SDK 114 via any suitable communica tions protocol.

[0046] Data store 106 can be local or remote with respect to the other com ponents of device 101. In at least one embodiment, device 101 is configured to retrieve data from a remote data storage device when needed. Such commu nication between device 101 and other components can take place wirelessly, by Ethernet connection, via a computing network such as the Internet, via a cellular network, or by any other appropriate communication systems.

[0047] In at least one embodiment, data store 106 is detachable in the form of a CD-ROM, DVD, flash drive, USB hard drive, or the like. Information can be entered from a source outside of device 101 into a data store 106 that is de tachable, and later displayed after the data store 106 is connected to device 101. In another embodiment, data store 106 is fixed within device 101.

[0048] In at least one embodiment, data store 106 may be organized into one or more well-ordered data sets, with one or more data entries in each set. Data store 106, however, can have any suitable structure. Accordingly, the particular organization of data store 106 need not resemble the form in which information from data store 106 is displayed to user 100. In at least one em bodiment, an identifying label is also stored along with each data entry, to be displayed along with each data entry.

[0049] Display screen 103 can be any element that displays information such as text and/ or graphical elements. Display screen 103 may optionally display elements of data 111, storage schemes 112, encryption schemes 113, SDK 114, and/ or other data pertinent to jurisdiction-specific data storage and/ or retrieval. Display screen 103 may display any known user interface elements, including elements that modify the presentation of information on display screen 103. In at least one embodiment where only some of the de sired output is presented at a time, a dynamic control, such as a scrolling mechanism, may be available via input device 102 to change which informa tion is currently displayed, and/ or to alter the manner in which the informa tion is displayed.

[0050] Processor 104 can be a conventional microprocessor for performing operations on data under the direction of software, according to well-known techniques. Memory 105 can be random-access memory, having a structure and architecture as are known in the art, for use by processor 104 in the course of running software.

[0051 ] Communication device 107 may communicate with other computing devices through the use of any known wired and/ or wireless protocol(s). For example, communication device 107 may be a network interface card ("NIC") capable of Ethernet communications and/ or a wireless networking card ca pable of communicating wirelessly over any of the 802.11 standards. Com munication device 107 may be capable of transmitting and/ or receiving sig nals to transfer data and/ or initiate various processes within and/ or outside device 101.

[0052] Referring now to Fig. IB, there is shown a block diagram depicting a hardware architecture in a client/ server environment, according to one em bodiment. Such an implementation may use a "black box" approach, whereby data storage and processing are done completely independently from user input/ output. An example of such a client/ server environment is a web-based implementation, wherein client device 108 runs a browser that provides a user interface for interacting with web pages and/ or other web- based resources from server 110. Items from data store 106 can be presented as part of such web pages and/ or other web-based resources, using known protocols and languages such as Hypertext Markup Language (HTML), Java, JavaScript, and the like. [0053] Client device 108 can be any electronic device incorporating input device 102 and/ or display screen 103, such as a desktop computer, laptop computer, personal digital assistant (PDA), cellular telephone, smartphone, music player, handheld computer, tablet computer, kiosk, game system, wearable device, or the like. Any suitable type of communications network 109, such as the Internet, can be used as the mechanism for transmitting data between client device 108 and server 110, according to any suitable protocols and techniques. In addition to the Internet, other examples include cellular telephone networks, EDGE, 3G, 4G, long term evolution (LTE), Session Initia tion Protocol (SIP), Short Message Peer-to-Peer protocol (SMPP), SS7, Wi-Fi, Bluetooth, ZigBee, Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (SHTTP), Transmission Control Protocol / Internet Protocol (TCP/IP), and/ or the like, and/ or any combination thereof. In at least one embodiment, client device 108 transmits requests for data via communica tions network 109, and receives responses from server 110 containing the re quested data. Such requests may be sent via HTTP as remote procedure calls or the like.

[0054] Information may be routed between one or more servers 110 and/ or client devices 108 by one or more routers 115. In some embodiments, the one or more routers 115 may be specially designed in order to implement storage schemes 112 by which data 111 is routed to and from the jurisdiction in which it is to be stored. In alternative embodiments, the one or more routers 115 may be incorporated into servers 110 and/ or client devices 108.

[0055] In one implementation, server 110 is responsible for data storage and processing, and incorporates data store 106. Server 110 may include ad ditional components as needed for retrieving data from data store 106 in re sponse to requests from client device 108. In some embodiments, server 110 may reside in a jurisdiction in which data 111 is to be stored, per laws and regulations pertinent to the jurisdiction. Accordingly, server 110 may have a local data store 116 in which data 111 is to be stored within the jurisdiction. Server 110 from which data 111 is transmitted may route data 111 to server 110 having local data store 116 via one or more routers 115.

[0056] As in Fig. 1A, data store 106 may be organized into one or more well-ordered data sets, with one or more data entries in each set. Data store 106, however, can have any suitable structure, and may store data according to any organization system known in the information storage arts, such as da tabases and other suitable data storage structures. As in Fig. 1A, data store 106 may include data 111, storage schemes 112, encryption schemes 113, SDK 114, and/ or other data (not shown); alternatively, such data 111, storage schemes 112, encryption schemes 113, SDK 114, and/ or other data can be stored elsewhere (such as at another server) and retrieved as needed.

[0057] In addition to or in the alternative to the foregoing, data 111, storage schemes 112, encryption schemes 113, SDK 114, and/ or other data may also be stored in a data store 106 present in client device 108. In some embodi ments, data 111, storage schemes 112, encryption schemes 113, SDK 114, and/ or other data may have elements distributed between server 110 and cli ent device 108 and/ or other computing devices in order to facilitate secure and/ or effective communication between these computing devices.

[0058] As in Fig. 1A, display screen 103 can be any element that displays information such as text and/ or graphical elements. Various user interface elements, dynamic controls, and/ or the like may be used in connection with display screen 103.

[0059] As also set forth in Fig. 1A, processor 104 can be a conventional mi croprocessor for use in an electronic device to perform operations on data un der the direction of software, according to well-known techniques. Memory 105 can be random-access memory, having a structure and architecture as are known in the art, for use by processor 104 in the course of running software. Communication device 107 may communicate with other computing devices through the use of any known wired and/ or wireless protocol(s), as also set forth in the description of Fig. 1A. [0060] In one embodiment, some or all of the system can be implemented as software written in any suitable computer programming language, whether in a standalone or client/ server architecture. Alternatively, it may be implemented and/ or embedded in hardware.

[0061 ] Notably, multiple servers 110 and/ or multiple client devices 108 may be networked together, and each may have a structure similar to those of client device 108 and server 110 that are illustrated in Fig. IB. The data struc tures and/ or computing instructions used in the performance of methods de scribed herein may be distributed among any number of client devices 108 and/ or servers 110. As used herein, "system" may refer to any of the compo nents, or any collection of components, from Figs. 1A and IB, and may in clude additional components not specifically described in connection with Figs. 1A and IB.

Data Structures

[0062] Fig. 2 is a block diagram depicting data that may be stored in con nection with localized data storage and processing, according to one em bodiment. Specifically, data 111, storage schemes 112, and encryption schemes 113 of Figs. 1A and IB are depicted in greater detail.

[0063] More specifically, data 111 may include, in some implementations, records for a plurality of owners that own or otherwise control portions of the data 111. Thus, data 111 may be divided into n records, pertaining to owner 1 200 through owner n 202.

[0064] Each record may include, for example, regulated data 210 and/ or unregulated data 212. Regulated data 210 may be subject to one or more laws and/ or regulations of a jurisdiction. By contrast, unregulated data 212 may not be subject to any such laws and/ or regulations.

[0065] In some embodiments, unregulated data 212 may be data 111 that is unregulated in all jurisdictions in which data 111 is to be stored. In other em bodiments, unregulated data 212 may be data that is simply unregulated in one or more particular jurisdictions of interest. As depicted in Fig. 2, all data 111 that is not regulated data 210 may be unregulated data 212. In some em bodiments, regulated data 210 may be further broken down by jurisdiction (for example, with a class of regulated data 210 for each jurisdiction with ap plicable laws and regulations).

[0066] Regulated data 210 may have indexed fields 214, and unregulated data 212 may have indexed fields 216. Indexed fields 214 and indexed fields 216 may beneficially be stored in a manner that permits a user to query and/ or search indexed fields 214 and/ or indexed fields for particular por tions of regulated data 210 and/ or unregulated data 212, respectively.

Searching regulated data 210 may pose a unique challenge due to the encryp tion and/ or other jurisdiction-mandated data storage parameters applied to it. In some embodiments, indexed fields 214 of regulated data 210 may be stored in a manner that facilitates search and retrieval of the desired por tion^) .

[0067] Storage schemes 112 may include, in some implementations, records for a plurality of storage schemes, each of which pertains to a particular juris diction. For example, storage schemes 112 may be divided into p records, pertaining to country 1 230 through country p 240.

[0068] Each record may include, for example, data storage laws 232 and encryption protocols 234. Data storage laws 232 may list the laws and/ or regulations applicable to the country (or state, city, region, or other jurisdic tion) to which the record applies. For example, data storage laws 232 may in dicate where data 111 regulated by the jurisdiction can legally be stored, whether backups and/ or redundant storage must be used, whether encryp tion must be used and if so what type, who is allowed to retrieve data 111, and/ or whether data 111 is allowed to pass out of the jurisdiction during the retrieval process. Encryption protocols 234 may specify one or more particu lar encryption schemes (for example, of encryption schemes 113) that are to be used in connection with data 111 governed by the jurisdiction. [0069] Encryption schemes 113 may include, in some implementations, re cords for a plurality of encryption schemes. For example, encryption schemes 113 may be divided into q records, pertaining to scheme 1 250 through scheme q 260.

[0070] Each record may include, for example, encryption steps 252 and/ or one or more encryption keys 254. The encryption steps 252 may specify the particular algorithm(s) to be used for each scheme. Any encryption method may be used; some examples will be shown and described subsequently. The encryption key 254 for a given record may specify the key, or keys, needed to decrypt files encrypted with the corresponding encryption steps 252 of the record. In some implementations, it may be desirable for the encryption keys 254 to be stored separately from the remaining portions of the encryption schemes 113 (such as, for example, the encryption steps 252), and/ or sepa rately from the data 111 that is to be encrypted therewith. For example, in some embodiments, the server 110 that encrypts and initiates transmittal of data 111 to a particular jurisdiction may not store the encryption keys 254 needed to decrypt that data 111; rather, the encryption keys 254 may be stored in the local data store 116 in the jurisdiction, and/ or in the data store 106 of a client device 108 at which the data 111 is to be received and decrypted.

[0071 ] Notably, Fig. 2 only depicts examples of data that may be recorded and used by a system according to the present disclosure. Data 111, storage schemes 112, and/ or encryption schemes 113 may exclude any of the fields shown in Fig. 2, and/ or may include additional fields of data not specifically shown in Fig. 2. Further, as mentioned previously, the system may capture and maintain other data in addition to or in the alternative to data 111, stor age schemes 112, and encryption schemes 113.

Localized Data Storage and Processing

[0072] In at least one embodiment, the system described herein provides mechanisms for handling regulated data differently from other data. Fig. 3 is a block diagram depicting a system 300 for handling of regulated data 210 and unregulated data 212, according to one embodiment.

[0073] As depicted in Fig. 3, regulated data 210 can include more sensitive data 111 such as, for example, personally identifiable information, health re cords, payment information, and transaction history. Unregulated data 212 may include other, less sensitive data 111, which can be handled by conven tional database storage, and can include, for example, anonymized data, pref erences, history, and scoring data.

[0074] An application 310 may, in some instances, generate and/ or store both types of data. System 300 may handle regulated data 210 with jurisdic tion-specific routing (for example, via router 115), and may store unregulated data 212 in a more conventional database 330.

[0075] According to known methods, secure handling of regulated data 210 within a jurisdiction (referred to as a "country" hereafter, which should be broadly read to include a country, city, county, state, region, or other law making body) can be a complex and multi-step endeavor. In general, the process of integrating a new country into a data storage scheme (referred to as "onboarding") can involve a team of experts across many disciplines, includ ing legal, compliance, hosting operations, engineering, database administra tors, network operations, information security, technical writing, risk, and technical operations.

[0076] The following table illustrates, by example, the teams that may be involved in the various steps for onboarding a country.

[0077] Fig. 4 is a block diagram depicting high-level architecture 400 for implementing a system 300 according to the present disclosure, according to one embodiment. In at least one embodiment, the system 300 is implemented in the context of a software developer kit (SDK 114) integrated within an ap plication running on an electronic device such as a device 101, client device 108, or server 110. SDK 114 may provide support for various programming languages, such as Java, PHP, Python, Scala, Ruby, and the like. SDK method calls may be directed to each country using router 115, which may be a spe cialized router, either by communicating through the router 115 or retrieving the location of a particular point of presence. Local data stores 116, or points of presence, can be established in each country according to local regulations. At every step, system 300 may implement a high level of security to ensure that data 111 is safe and is never compromised.

[0078] Fig. 5 is a block diagram depicting encryption and secure transmis sion 500 of data 111 within architecture 400 of Fig. 4, according to one em bodiment. The first step may be to encrypt data 111 within application 310. This can be done, for example, using a private key and key management sys tem provided and implemented by the operator of application 310. This way, only that application 310 (or authorized other parties) can decrypt data 111. The native encryption built into any desired language can be used, so that the encryption is implemented natively using known and proven libraries. The encryption can be performed at a level similar to typical encryption on disk. Encrypted data 11 may then be sent to router 115, which may be a specialized router at the same encryption level.

[0079] In at least one embodiment, all network communication is per formed securely, using for example, Transport Layer Security (TLS) 1.2 and a revocable application programming interface (API) key. In at least one em bodiment, tenants (for example, owners of data 111) are fully isolated from one another, such that only a given tenant's data 111 can be accessed using the corresponding API. All data 111 may be stored on fully isolated servers 110 (for example, on local data stores 116) with encryption at rest.

[0080] Fig. 6 is a block diagram depicting data storage 600 in two or more separate points of presence within a jurisdiction, according to one embodi ment. This redundancy may allow for secure, reliable access of data 111 in case one location (for example, one local data store 116) goes offline or is shut off due to governmental intervention or other factors. In at least one em bodiment, a mix of global cloud providers and reputable Tier 4 data centers is used to provide two Tier 4 facilities in each country.

[0081 ] Examples of cloud providers that can be used in connection with system 300 include:

• Amazon Web Services;

• Microsoft Azure;

• Google Cloud; and

• Alibaba Cloud.

[0082] Tier 4 data centers used in connection with system 300 can include any or all of the following features and characteristics:

• Redundant interconnects;

• Redundant power; • Redundant cooling; and

• Secure facilities.

[0083] Fig. 7 is a block diagram depicting differential encryption 700 of in dexed fields 214 and entire records, according to one embodiment. In at least one embodiment, system 300 offers a searchable encrypted database by im plementing two different types of encryption. Data 111 may be encrypted di rectly within application 310 using a custom SDK (for example, the SDK 114) that uses a SHA-256 hash 710 to encrypt indexed fields 214 to provide hashed fields 720, and AES-256 symmetric encryption 730 to encrypt the entire record to provide a symmetrically encrypted record 740. The symmetrically en crypted record 740 can be, for example, a JSON payload that can include JSON encoded images if desired. For example, in an e-commerce use case, the customer ID, name, and city are hashed, and then the customer transaction history is encrypted symmetrically.

[0084] Fig. 8 is a block diagram depicting retrieval 800 of data 111 en crypted via the differential encryption of Fig. 7, according to one embodi ment. Data 111 can be retrieved using one or more of the hashed keys and then decrypted using encryption key 254, which may be provided by the op erator of application 310.

[0085] The top half of Fig. 8 depicts a flow in which data 111 is called by web service 810, which may function on device 101 and/ or client device 108, to query data store 106 for data 111. Data 111 may be decrypted and pro vided to user 100. Data store 106 may reside on server 110, which may not be in the applicable jurisdiction. The bottom half of Fig. 8 depicts retrieval of data 111 in which web service 810 (for example, data store 106) handles only data 111 in encrypted and/ or redacted form. Web service 810 may receive actual data 111 from local data store 116 located in the applicable jurisdiction. Thus, actual data 111 may only be transmitted within the applicable jurisdic tion. [0086] In at least one embodiment, system 300 fully encrypts data 111 but does not have access to encryption key 254. Any suitable encryption method ology can be used, allowing system 300 to be very flexible and allowing for arbitrary data 111 to be secured and stored. This is in contrast to tokenization (a use case that is popular for payment information), where a provider will generate a fake credit number for example, that can then be swapped with the real credit card number which can then be stored in place of the real credit card number by the customer.

[0087] Fig. 9 is a block diagram depicting retrieval 900 of regulated data 210, in which data 111, such as regulated data 210, is maintained in the appli cable jurisdiction during the retrieval process, according to another embodi ment. An application, such as application 310 referenced previously, may be used to call for data 111 in place of web service 810.

[0088] Fig. 10 is a block diagram depicting data 1000, including tokenized data 1010 and data 1020 that has been encrypted with a searchable hash code, according to one embodiment.

[0089] Fig. 11 is a block diagram depicting retrieval 1100 of regulated data 210, in which data 111, such as regulated data 210, is maintained in the appli cable jurisdiction during the retrieval process, according to one embodiment. In circumstances where, because of regulatory or other issues, data 111 cannot be permitted to leave a jurisdiction, a domain overlay can be used to serve data 111 from a point of presence (for example, local data store 116) in the ju risdiction (country) directly to a web browser. For example, ACME Company can assign india.acme.com to point to the point of presence in India. A user 100 in India can interact directly with www.acme.com to retrieve a web page. When the web application (for example, application 310) needs to access regu lated data 210, it can have the user's browser directly query india.acme.com, which resolves to the point of presence, or local data store 116, in India.

[0090] The point of presence can then read federated authentication 1110, such as authentication cookies, to verify the user's identity with the main ACME web application 310, and can then serve data 111 directly to the browser. The data 111 may then be rendered by logic in the web browser for presentation to the user 100. This way, ACME still maintains a single web application 310, but can have regulated data 210 stored in a particular juris diction and served from that jurisdiction without the data 111 leaving the ju risdiction.

[0091 ] When processing batches of data, it can be more convenient to serve data from and/ or process data directly within a point of presence, or local data store 116. In at least one embodiment, a function as a service can be de ployed into the point of presence using a secure container. If the host peers within the container, the requester may be notified of the intrusion. This way, a secure container can even include encryption keys 254 to decrypt data with relative certainty that the encryption key 254 is not compromised. Using a domain overlay model, where a customer of the system can have their own domain mapped to the point of presence, data 111 can be served directly to a web browser application 310 run by a user 100. For example, india.acme.com can serve data directly from a point of presence in India to a browser running in India, even if the main web application is served from a centralized www.acme.com.

[0092] Fig. 12 is a block diagram depicting retrieval 1200 of regulated data 210, in which regulated data 210 is maintained in the applicable jurisdiction during the retrieval process, according to one alternative embodiment. Re trieval 1200 may be similar to retrieval 1100 of Fig. 11, except that in Fig. 12, application 310 may send the browser a signed token. The signed token may be submitted to local data store 116 to retrieve the regulated data 210 from lo cal data store 116. Application pages with the signed token may be presented on existing web application 1210.

[0093] One skilled in the art will recognize that the examples depicted and described herein are merely illustrative, and that other arrangements of user interface elements can be used. In addition, some of the depicted elements can be omitted or changed, and additional elements depicted, without depart ing from the essential characteristics.

[0094] The present system and method have been described in particular detail with respect to possible embodiments. Those of skill in the art will ap preciate that the system and method may be practiced in other embodiments. First, the particular naming of the components, capitalization of terms, the at tributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms and/ or features may have dif ferent names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, or entirely in hardware ele ments, or entirely in software elements. Also, the particular division of func tionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system com ponent may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.

[0095] Reference in the specification to "one embodiment" or to "an em bodiment" means that a particular feature, structure, or characteristic de scribed in connection with the embodiments is included in at least one em bodiment. The appearances of the phrases "in one embodiment" or "in at least one embodiment" in various places in the specification are not necessar ily all referring to the same embodiment.

[0096] Various embodiments may include any number of systems and/ or methods for performing the above-described techniques, either singly or in any combination. Another embodiment includes a computer program prod uct comprising a non-transitory computer-readable storage medium and computer program code, encoded on the medium, for causing a processor in a computing device or other electronic device to perform the above-described techniques. [0097] Some portions of the above are presented in terms of algorithms and symbolic representations of operations on data bits within a memory of a computing device. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps (in structions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated.

It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain ar rangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality.

[0098] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "process ing" or "computing" or "calculating" or "displaying" or "determining" or the like, refer to the action and processes of a computer system, or similar elec tronic computing module and/ or device, that manipulates and transforms data represented as physical (electronic) quantities within the computer sys tem memories or registers or other such information storage, transmission or display devices.

[0099] Certain aspects include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions can be embodied in software, firmware and/ or hardware, and when embodied in software, can be downloaded to reside on and be op erated from different platforms used by a variety of operating systems.

[0100] The present document also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computing device. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk in cluding floppy disks, optical disks, CD-ROMs, DVD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, flash memory, solid state drives, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Further, the computing devices referred to herein may include a single processor or may be architectures employing multiple processor de signs for increased computing capability.

[0101 ] The algorithms and displays presented herein are not inherently related to any particular computing device, virtualized system, or other appa ratus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The re quired structure for a variety of these systems will be apparent from the de scription provided herein. In addition, the system and method are not de scribed with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to imple ment the teachings described herein, and any references above to specific lan guages are provided for disclosure of enablement and best mode.

[0102] Accordingly, various embodiments include software, hardware, and/ or other elements for controlling a computer system, computing device, or other electronic device, or any combination or plurality thereof. Such an electronic device can include, for example, a processor, an input device (such as a keyboard, mouse, touchpad, track pad, joystick, trackball, microphone, and/ or any combination thereof), an output device (such as a screen, speaker, and/ or the like), memory, long-term storage (such as magnetic storage, opti cal storage, and/ or the like), and/ or network connectivity, according to tech niques that are well known in the art. Such an electronic device may be port able or non-portable. Examples of electronic devices that may be used for implementing the described system and method include: a mobile phone, personal digital assistant, smartphone, kiosk, server computer, enterprise computing device, desktop computer, laptop computer, tablet computer, con sumer electronic device, or the like. An electronic device may use any operat ing system such as, for example and without limitation: Linux; Microsoft Windows, available from Microsoft Corporation of Redmond, Washington; Mac OS X, available from Apple Inc. of Cupertino, California; iOS, available from Apple Inc. of Cupertino, California; Android, available from Google, Inc. of Mountain View, California; and/ or any other operating system that is adapted for use on the device.

[0103] While a limited number of embodiments have been described herein, those skilled in the art, having benefit of the above description, will appreciate that other embodiments may be devised. In addition, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the subject matter. Accordingly, the disclosure is intended to be illustrative, but not limiting, of scope.