DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Allowable Subject Matter
Claims 36-40 are allowable over the prior art. However, the claims remain rejected under 35 USC §101.
Reasons For Allowance
The cited references do not disclose accessing a reference to a data resource, wherein the reference is stored in a first storage location that is restricted from storing the data resource, retrieving the data resource from a second storage location storing the data resource, wherein the second storage location is identified by the reference and wherein the data resource has a region-restriction that restricts the geographical region in which the data resource can be stored.
Specification
The disclosure is objected to because of the following: Paragraph [008] of the Specification states that …
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Nor is the claimed subject matter limited to implementations that solve any or all of the disadvantages noted herein.
This contradicts 37 CFR §1.73 which states that the summary should “be commensurate with the invention as claimed”. MPEP §608.01(d) further adds that “the summary should be directed to the specific invention being claimed”. And, anything in the disclosure can/will be used to help determine the scope of the claimed subject matter (e.g., for interpreting a claim’s meaning). And, the claims are required to be supported by the disclosure, especially concerning enablement and clarity. 35 USC §§112 (a) and 112(b). The Office recommends deleting the last two sentences of paragraph [008]. Applicant is respectfully reminded to review the specification/abstract/claims/drawings for all informalities.
Claim Rejections – 35 U.S.C. § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 21-40 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
These claims are rejected under 35 USC §101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites at a very level, deciding whether or not to store data based upon restriction/constraint metadata. Thus, the claims encompass the performance of the limitations in the mind, or alternatively the solving of a math problem (i.e., a series of mathematical steps) that are not tied to a practical application.
Regarding independent claims 21, 33 and 36:
Step 1: Yes, claim 21 recites a system (therefore a product/machine), claim 33 is directed to a method (therefore a process), and claim 36 is directed to device (therefore a product/machine). Thus, each of these claims is directed to a statutory category.
Step 2A, Prong 1 (Judicial Exception Recited?): Yes. Claims 21 and 33 each recite limitations directed to an abstract idea: “routing the retrieval request to a storage location storing the data resource in accordance with the region-restriction”. This claim perforce requires an abstract [region-restriction] determination in order to effectuate routing. As drafted, each of these limitations recites a mentally performable process as one can make a routing decision based upon a restriction/constraint via a mental process or using paper and pencil.
Additionally, claim 36 recites limitations directed to an abstract idea: “…, the data resource having a region-restriction that restricts a geographical region in which the data resource can be stored; accessing a reference to the data resource, wherein the reference is stored in a first storage location that is restricted from storing the data resource”. This claim perforce requires an abstract [region-restriction] determinations in order to effectuate routing. As drafted, the limitation recites a mentally performable process as one can make a decision as to whether or not to access data based upon a restriction/constraint via a mental process or using paper and pencil.
Step 2A, Prong 2 (Integrated into a Practical Application?): No. Claim 21 recites the following additional elements: “a processor”, “a memory” and “a storage location”. Claim 33 recites the following additional elements: “a storage location”. And, claim 36 recites the following additional elements: “a processor”, “a memory”, and “a first storage location” and “a second storage location”. Each of these are merely high-level recitations of generic computer components and represent mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Additionally, claims 21 and 33 each recite the receiving, routing, retrieving and providing of data (request or data “resource”). Claim 36 recites the receiving, accessing, retrieving and providing of data (request, reference or data “resource”). These actions represent insignificant extra-solution activity as receiving, routing, retrieving and providing of data (i.e., mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Viewing the additional limitations together and the claims as a whole, nothing provides integration into a practical application. Therefore, each claim is directed to an abstract idea.
Step 2B (Inventive Concept Provided?): No. As discussed with respect to Step 2A, the elements (i.e., receiving, routing, retrieving and providing of data or receiving, accessing, retrieving and providing of data) in each claim amount to no more than mere instructions to apply the exception. Mere instructions to apply an exception using generic computer components (e.g., processors, memory/storage) cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
With respect to the receiving, routing, retrieving and providing of data limitations or the receiving, accessing, retrieving and providing of data limitations discussed above, and when re-evaluated these elements are well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remain insignificant extra-solution activity that does not provide significantly more.
Therefore, each of the claims, taken as a whole, does not change this conclusion and the claims are ineligible.
Claims 22-32 depend upon claim 21, and do not correct the issues set forth above. These claims essentially further claim generic computing elements or insignificant extra-solution activities. Therefore, these claims are likewise rejected.
Claims 34-35 depend upon claim 33, and do not correct the issues set forth above. These claims essentially claim a further abstract activity (i.e., a determination) and the use of generic computing elements. Therefore, these claims are likewise rejected.
Claims 37-40 depend upon claim 36, and do not correct the issues set forth above. These claims essentially further claim generic computing elements or insignificant extra-solution activities. Therefore, these claims are likewise rejected.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 21-26, 28-29 and 33 are rejected under 35 U.S.C. §103 as being unpatentable over Nicolae Paladi et al. (“Trusted Geolocation-Aware Data Placement in Infrastructure Clouds”, TrustCom 2014, Beijing, China, September 24-26, 2014, IEEE Computer Society, pp. 352-360, hereafter referred to as “Paladi”) in view of Gokhale et al (US Patent Application Publication No. 2014/0188804, hereafter referred to as “Gokhale”).
Regarding independent claim 21: Paladi teaches A system comprising: … receiving, from a requestor, a retrieval request to retrieve a data resource associated with a party, the data resource having a region-restriction that restricts a geographical region in which the data resource can be stored; (See Paladi page 357, section “B. Storage Protection Protocol”, bullet “7)” discussing that a user sends a storage request to storage hosts, in the context of the last paragraph on page 357 and Fig. 6 on page 358 teaching that the user can specify a location policy comprising geolocation cell parameters reflecting geographic regions and the page 352 Abstract indicating that this mechanism allows users to control the geographical location of their data.) routing the retrieval request to a storage location storing the data resource in accordance with the region-restriction; (See Paladi page 357, section “B. Storage Protection Protocol”, bullets “2)” and “6)” discussing the storage and processing [e.g., accessing and retrieving] of data.) retrieving the data resource from the storage location; See Paladi page 357, section “B. Storage Protection Protocol”, bullets “2)” and “6)” discussing the storage and processing [e.g., accessing and retrieving] of data.) and providing the data resource to the requestor in response to the retrieval request. (See Paladi page 357, section “B. Storage Protection Protocol”, bullet “7)” discussing the sending of the requested/encrypted file to the requesting user.)
However, Paladi does not explicitly teach the remaining limitations as claimed. Gokhale, though, teaches … a processor; and a memory storing instructions that, when executed, perform operations comprising: … (See Gokhale paragraph 0151 discussing the use of processors, and paragraphs 0152-0153 discussing the use of memory/storage.)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains to apply the teachings of Gokhale for the benefit of Paladi, because to do so provided a designer with options for implementing a system that facilitated data access and retention based on regulations / geographic characteristics, as taught by Gokhale in the Abstract. These references were all applicable to the same field of endeavor, i.e., storage management.
Regarding claim 22: Paladi teaches wherein the storage location is a data center physically located in the geographical region. (See Paladi page 357, 1st paragraph of section “B. Storage Protection Protocol” discussing that data is stored on storage hosts deployed in a user-approved jurisdiction.)
Regarding claim 23: Paladi teaches wherein the storage location further stores a list of geographical regions in which the party consents to storing the data resource. (See Paladi page 357, section “B. Storage Protection Protocol”, bullet “1)” discussing the use of a list of geolocation cells, and the last paragraph on page 357 stating that a user could specify one or more geolocation cells, in the context of Fig. 6 on page 358 showing an exemplary location policy XML structure for creating a geocell list.)
Regarding claim 24: Paladi does not explicitly teach the remaining limitations as claimed. Gokhale, though, teaches wherein the storage location further stores a list comprising a pointer to the data resource, wherein the pointer identifies the storage location. (See Gokhale paragraph 0038 teaching the use of pointers to access data, and that pointers may be used to reflect the storage location of the object.)
Regarding claim 25: Paladi does not explicitly teach the remaining limitations as claimed. Gokhale, though, teaches wherein routing the retrieval request to the storage location comprises: accessing the pointer to the data resource based on the retrieval request; and identifying the storage location based on the pointer. (See Gokhale paragraph 0038 teaching the use of pointers to access data, and that pointers may be used to reflect the storage location of the object.)
Regarding claim 26: Paladi teaches wherein the storage location serves a plurality of geographical regions. (See Paladi in the last paragraph of page 357 discussing in regards to a storage location policy that a user may “specify either a single of more geolocation cells”, in the context of Fig. 6 on page 358 depicting an XML-based storage location policy for a data object that includes exemplary code for creating a geocell list.)
Regarding claim 28: Paladi teaches wherein the data resource has been stored in the storage location based on a geographical dependency property of the party. (See Paladi in the last paragraph of page 357 discussing in regards to a storage location policy that a user may “specify either a single of more geolocation cells”, in the context of Fig. 6 on page 358 depicting an XML-based storage location policy for a data object that includes exemplary code for creating a geocell list. Also see Paladi page 357, 1st paragraph of section “B. Storage Protection Protocol” indicating that storage depends upon the “user-approved jurisdiction”. Such jurisdiction is specified in the location policy data structure of Fig. 6 on page 358.)
Regarding claim 29: Paladi does not explicitly teach the remaining limitations as claimed. Gokhale, though, teaches wherein the geographical dependency property of the party is based on an Internet Protocol (IP) address associated with the party. (See Gokhale discussing the use of IP addresses to aid in location services.)
Claim 33 is substantially similar to claim 21, and therefore likewise rejected.
Claim 27 is rejected under 35 U.S.C. §103 as being unpatentable over Nicolae Paladi et al. (“Trusted Geolocation-Aware Data Placement in Infrastructure Clouds”, TrustCom 2014, Beijing, China, September 24-26, 2014, IEEE Computer Society, pp. 352-360, hereafter referred to as “Paladi”) in view of Gokhale et al (US Patent Application Publication No. 2014/0188804, hereafter referred to as “Gokhale”) and Sommerfelt et al (US Patent Application Publication No. 2018/0205739, hereafter referred to as “Sommerfelt”).
Regarding claim 27: Paladi in view of Gokhale does not explicitly teach the remaining limitations as claimed. Sommerfelt, though, teaches wherein the data resource is stored in an electronic mailbox of the storage location. (See Sommerfelt paragraphs 0036 and 0040-0042 teaching the use of mailboxes associated with a server unit that may or may not be located in a different geographic region.)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains to apply the teachings of Sommerfelt for the benefit of Paladi in view of Gokhale, because to do so provided a designer with options for implementing a system that facilitated secure access by one or multiple users, as taught by Sommerfelt in paragraphs 0042-0044. These references were all applicable to the same field of endeavor, i.e., storage management.
Claim 30 is rejected under 35 U.S.C. §103 as being unpatentable over Nicolae Paladi et al. (“Trusted Geolocation-Aware Data Placement in Infrastructure Clouds”, TrustCom 2014, Beijing, China, September 24-26, 2014, IEEE Computer Society, pp. 352-360, hereafter referred to as “Paladi”) in view of Gokhale et al (US Patent Application Publication No. 2014/0188804, hereafter referred to as “Gokhale”) and McCarthy et al (US Patent Application Publication No. 2015/0163206, hereafter referred to as “McCarthy”).
Regarding claim 30: Paladi in view of Gokhale does not explicitly teach the remaining limitations as claimed. McCarthy, though, teaches wherein the geographical dependency property of the party indicates a region in which the data resource was created. (See McCarthy paragraph 0203 discussing geo-tagging a document with information such as where a document was created.)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains to apply the teachings of McCarthy for the benefit of Paladi in view of Gokhale, because to do so provided a designer with options for implementing a system that provides a historical/geographical audit trail regarding user/data interaction for legal or e-discovery purposes, for example, as taught by McCarthy in paragraph 0203. These references were all applicable to the same field of endeavor, i.e., storage management.
Claims 31-32 and 34-35 are rejected under 35 U.S.C. §103 as being unpatentable over Nicolae Paladi et al. (“Trusted Geolocation-Aware Data Placement in Infrastructure Clouds”, TrustCom 2014, Beijing, China, September 24-26, 2014, IEEE Computer Society, pp. 352-360, hereafter referred to as “Paladi”) in view of Gokhale et al (US Patent Application Publication No. 2014/0188804, hereafter referred to as “Gokhale”) and Gordon (US Patent Application Publication No. 2017/0353516, hereafter referred to as “Gordon ”).
Regarding claim 31: Paladi in view of Gokhale does not explicitly teach the remaining limitations as claimed. Gordon, though, teaches wherein routing the retrieval request to the storage location comprises: determining the data resource is stored in a plurality of storage locations, the plurality of storage locations including the storage location; determining the storage location is physically closest of the plurality of storage locations to the requestor; and selecting the storage location from the plurality of storage locations based on determining the storage location is physically closest to the requestor. (See Gordon paragraphs 0144 and 0158 teaching the determination of a location that is closer than any other location.)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains to apply the teachings of Gordon for the benefit of Paladi in view of Gokhale, because to do so provided a designer with options for implementing a system that facilitates the locating of a networked devices, as taught by Gordon in paragraphs 0143-0144. These references were all applicable to the same field of endeavor, i.e., storage management.
Regarding claim 32: Paladi in view of Gokhale does not explicitly teach the remaining limitations as claimed. Gordon, though, teaches wherein routing the retrieval request to the storage location comprises: determining the data resource is stored in a plurality of storage locations, the plurality of storage locations including the storage location; determining the storage location has a lowest latency of the plurality of storage locations to the requestor; and selecting the storage location from the plurality of storage locations based on determining the storage location has the lowest latency. (See Gordon paragraphs 0144 and 0158 teaching the use of performance measurements such as latency in choosing the closest location.)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains to apply the teachings of Gordon for the benefit of Paladi in view of Gokhale, because to do so provided a designer with options for implementing a system that facilitates the locating of a networked devices, as taught by Gordon in paragraphs 0143-0144. These references were all applicable to the same field of endeavor, i.e., storage management.
Regarding claim 34: Paladi in view of Gokhale does not explicitly teach the remaining limitations as claimed. Gordon, though, teaches wherein routing the retrieval request to the storage location comprises: determining the storage location is logically closest of a plurality of storage locations to the requestor; and selecting the storage location from the plurality of storage locations based on determining the storage location is logically closest to the requestor. (See Gordon paragraphs 0144 and 0158 teaching the use of performance measurements such as latency in choosing the closest location.)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains to apply the teachings of Gordon for the benefit of Paladi in view of Gokhale, because to do so provided a designer with options for implementing a system that facilitates the locating of a networked devices, as taught by Gordon in paragraphs 0143-0144. These references were all applicable to the same field of endeavor, i.e., storage management.
Regarding claim 35: Paladi in view of Gokhale does not explicitly teach the remaining limitations as claimed. Gordon, though, teaches wherein logical closeness is based on at least one of: network link structure; a load on a network used to access the data resource; or a load on computation resources in the storage location. (See Gordon paragraphs 0144 and 0158 teaching the use of performance measurements such as speed, throughput and latency in choosing the closest location.)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains to apply the teachings of Gordon for the benefit of Paladi in view of Gokhale, because to do so provided a designer with options for implementing a system that facilitates the locating of a networked devices, as taught by Gordon in paragraphs 0143-0144. These references were all applicable to the same field of endeavor, i.e., storage management.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Relevance is provided in at least the Abstract of each cited document.
Non-Patent Literature
Padmanabhan, Venkata N., et al., “An Investigation of Geographic Mapping Techniques for Internet Hosts”, SIGCOMM ‘01, San Diego, CA, August 27-31, 2001, pp. 173-185.
In this paper, we ask whether it is possible to build an IP address to geographic location mapping service for Internet hosts. Such a service would enable a large and interesting class of location-aware applications. This is a challenging problem because an IP address does not inherently contain an indication of location. We present and evaluate three distinct techniques, collectively referred to as IP2Geo, for determining the geographic location of Internet hosts. The first technique, GeoTrack, infers location based on the DNS names of the target host or other nearby network nodes. The second technique, GeoPing, uses network delay measurements from geographically distributed locations to deduce the coordinates of the target host. The third technique, GeoCluster, combines partial (and possibly inaccurate) host-to-location mapping information and BGP pre x information to infer the location of the target host. (page 173, Abstract). The rst technique, GeoTrack, tries to infer location based on the DNS names of the target host or other nearbynet work nodes. The DNS name of an Internet host sometimes contains clues about the host’s location. Such a clue, when present, could indicate location at di erent levels of granularity suchascity(e.g.,corerouter1.SanFrancisco.cw.net indicates the city of San Francisco), state (e.g., www.state.ca.us indicates the state of California), or country (e.g., www.un.cm indicates the country of Cameroon). (page 173, 4th paragraph of section entitled “1. Introduction”). The third technique, GeoCluster, combines partial (and possibly inaccurate) IP-to-location mapping information with BGP prefix information to infer the location of the host of interest. For our research, we obtained the host-to-location mapping information from a variety of sources, including a popular Web-based email site, a business Web hosting site, and an online TV guide site. The data thus obtained is partial in the sense that it only includes a relatively small number of IP addresses. We use BGP prefix information to expand the coverage of this data by identifying clusters of IP addresses that are likely to be located in the same geographic area. This technique is self-calibrating in that it can offer an indication of how accurate a specific location estimate is likely to be. (pages 173-174, 6th paragraph of section entitled “1. Introduction”). We also describe GeoCluster, a powerful new technique that combines partial IP-to-location mapping information obtained from a variety of sources and topological clustering data [12] to do location mapping. Our results indicate that GeoCluster performs the best among the IP2Geo techniques. (page 175, 3rd paragraph of section entitled “3.1 Design Rationale”). GeoCluster operates as follows. First, the IP address space is broken up into clusters such that all hosts with IP addresses within a cluster are likely to be co-located2, i.e., the addresses form a geographic cluster. Then, knowing the location corresponding to a few hosts in a cluster (and assuming the locations are largely in agreement), GeoCluster deduces the location of the entire cluster. The key to the operation of GeoCluster is IP-to-location mapping information obtained from sources such as the ones mentioned in Section 3.5. (We discuss the general problem of obtaining such data in Section 6.5.) However, this mapping information tends to be partial in coverage (since it includes location information only for a relatively small subset of the IP address space) and possibly inaccurate. These problems limit the utility of the IP-to-location mapping data. GeoCluster addresses both of these problems by clustering IP addresses according to their (likely) location. Clustering helps expand the coverage of the partial IP-to-location map ping information. The aggregation of location information also enables us to identify and eliminate outliers caused by inaccuracies in the individual location data points. (page 180, 2nd – 4th paragraphs of section “6. The GeoCluster Technique”).
Albeshri, Aiiad, et al., “GeoProof: Proofs of Geographic Location for Cloud Computing Environment”, ICDCSW 2012, Macau, China, June 18-21, 2012, pp. 506-514.
Cloud computing has emerged as a major ICT trend and has been acknowledged as a key theme of industry by prominent ICT organisations. However, one of the major challenges that face the cloud computing concept and its global acceptance is how to secure and protect the data that is the property of the user. The geographic location of cloud data storage centres is an important issue for many organisations and individuals due to the regulations and laws that require data and operations to reside in specific geographic locations. Thus, data owners may need to ensure that their cloud providers do not compromise the SLA contract and move their data into another geographic location. This paper introduces an architecture for a new approach for geographic location assurance, which combines the proof of storage protocol (POS) and the distance-bounding protocol. This allows the client to check where their stored data is located, without relying on the word of the cloud provider. This architecture aims to achieve better security and more flexible geographic assurance within the environment of cloud computing. (page 506, Abstract).
Watson, Gaven J., et al., “LoSt: Location Based Storage”, CCSW ‘12, Raleigh, NC, October 19, 2012, pp. 59-69.
For certain types of sensitive data (such as health records) it is important to know the geographic location of the file, e.g. that it is stored on servers within the USA. This is particularly important for determining applicable laws and regulations. In this paper we discuss the problem of verifying the location of files within distributed file storage systems such as the cloud. We consider a general setup for a distributed storage system and show that verifying location when such a system is fully malicious, is impossible. We then make plausible assumptions about the behavior of the system and provide a formal definition for Proofs of Location (PoL) in our setting. We show secure and efficient PoL schemes can be constructed by using a geolocation scheme and a Proof of Retrievability (PoR) scheme with a new added property that we call re-coding, which is of independent interest. (page 59, Abstract). Internet Geolocation systems [20, 15] are aimed at determining the geographic location of a server (IP ad dress). In such systems a trusted set of landmarks are used to query the server and measure the round trip time of the query, upper-bounding the distance of the server from the landmark. Using queries from multiple landmarks and trilateration, one can locate the server with reasonable accuracy. To verify the location of a file however, one needs to determine the location of the claiming server and in addition show that the server actually holds the file. (page 60, 3rd paragraph of section “1.1 Setting Considered”). We consider a distributed storage service provider that uses a set of geographically dispersed storage servers S = {S1,S2, ..., Sn}, where Si denotes the label (IP address) of server i. The service provider receives a user’s request to store an encoded file in a particular region R, which is a contiguous geographic area that houses one or more servers in S. To store a file, a user encodes the file F obtaining F∗, and sends it together with a region R to the service provider. The service provider will select a set of servers T ⊆ S which it believes to be contained in the region R. (page 64, section “3. Storage Model”, 1st paragraph).
Massonet, Philippe, et al., “A Monitoring and Audit Logging Architecture for Data Location Compliance in Federated Clous Infrastructures”, IPDPS 2011, Anchorage, AK, 16-20 May 2011, pp. 1510-1517.
—Current cloud infrastructures have opaque service offerings where customers cannot monitor the underlying physical infrastructure. This situation raises concerns for meeting compliance obligations by critical business applications with data location constraints that are deployed in a Cloud. When federated cloud infrastructures span across different countries where data can migrate from one country to another, it should be possible for data owners to monitor the location of their data. This paper shows how an existing federated Cloud monitoring infrastructure can be used for data location monitoring without compromising Cloud isolation. In the proposed approach collaboration is required between the cloud infrastructure provider (IP) and the user of the cloud, the service provider (SP): the IP monitors the virtual machines (VM) on the SP’s behalf and makes the infrastructure level monitoring information available to him. With the monitoring information the SP can create the audit logs required for compliance auditing. The proposed logging architecture is validated by an e-Government case study with legal data location constraints. (page 1510, Abstract). This section describes a RESERVOIR based cloud monitoring and logging architecture that is designed to meet the compliance requirements. The SP is responsible for defining the data export control constraints and the associated monitoring requirements in the service definition. Creating the audit log data requires collaboration between the SP and the IP. The IP manages the infrastructure level monitoring and makes the monitored data available to the SP. The SP is responsible for subscribing to the relevant monitoring data and creating the audit logs in the format that is required for the audit. This distribution of responsibilities is necessary because the SP cannot be allowed to monitor the physical and virtual infrastructure directly. The architecture enforces a strict distinction between SP space and infrastructure space to meet isolation and confidentiality objectives of the federated cloud infrastructure. The IP is responsible for deploying the Application according to the service definition. The VEEM layer is responsible for translating the data export constraints into placement and migration constraints to be enforced by the Policy Engine (PE) when placing and migrating VEE in the federation. (pages 1512-1513, 1st – 2nd paras of section “B. Monitoring and Logging Architecture”). XML descriptor tags related to geolocation labeling. (page 1513, Fig. 2).
Paladi, Nicolae, et al., “’One of Our Hosts in Another Country’: Challenges of Data Geolocation in Cloud Storage”, VITAE 2014, Aalborg, Denmark, May 11-14, 2014, pp. 1-6.
Physical location of data in cloud storage is an increasingly urgent problem. In a short time, it has evolved from the concern of a few regulated businesses to an important consideration for many cloud storage users. One of the characteristics of cloud storage is fluid transfer of data both within and among the data centres of a cloud provider. However, this has weakened the guarantees with respect to control over data replicas, protection of data in transit and physical location of data. This paper addresses the lack of reliable solutions for data placement control in cloud storage systems. We analyse the currently available solutions and identify their shortcomings. Furthermore, we describe a high-level architecture for a trusted, geolocation-based mechanism for data placement control in distributed cloud storage systems, which are the basis of an on-going work to define the detailed protocol and a prototype of such a solution. This mechanism aims to provide granular control over the capabilities of tenants to access data placed on geographically dispersed storage units comprising the cloud storage. (page 1, Abstract).
Peterson, Zachary N. J., et al., “A Position Paper on Data Sovereignty: The Importance of Geolocating Data in the Cloud”, HotCloud ‘11, Portland, OR, June 14-15, 2011, USENIX Association, pp. 1-5.
In this position paper, we propose the need for devel oping new algorithms for establishing the integrity, au thenticity, and geographical location of data stored in the cloud. Of particular interest is establishing data location. at a granularity sufficient for placing it within the bor ders of a particular nation-state. We call this notion data sovereignty. We desire to establish some (probabilistic) guarantee that a provider is storing data at some expected physical location(s) and maintain such guarantees amid potentially dishonest providers. The problem of verify ing that data exists only at allowed locations—and copies have not moved to some location that violates a policy— is a difficult problem in general; data sovereignty pro vides a much weaker guarantee, but a step toward ac tively monitoring compliance with some SLA policies. (page 1, 2nd paragraph of section entitled “1 Introduction”). By combining the responses of a network delay-based measurement geolocation protocol with a PDP response, the objective is to provide a strong binding between net work location and data location. Of course, one must avoid introducing any variable overhead to the server’s processing of the request, so the measured latency almost entirely reflects propagation cost. MAC-PDP allows a single challenger to use the measured delay to calculate a radial distance of the responder (e.g. using only the client in Figure 1). A well placed challenger may be able to provably place data within the continental United States, efficiently satisfying many of the sovereignty issues ad dressed in Section 2. For finer location granularity, a challenger may em ploy the help of friendly, semi-trusted landmarks (e.g. us ing all landmarks in Figure 1). Each landmark may chal lenge the server to respond to some subset of the c ran domly chosen blocks, measure the response times, then authentically report the responses and measurements to the client, to aid in estimating the target’s location. (page 4, 2nd – 3rd paras).
Paladi, Nicolae, et al., “Trusted Geolocation-Aware Data Placement in Infrastructure Clouds”, TrustCom 2014, Beijing, China, September 24-26, 2014, IEEE Computer Society, pp. 352-360.
Data geolocation in the cloud is becoming an increasingly pressing problem, aggravated by incompatible legis lation in different jurisdictions and compliance requirements of data owners. In this work we present a mechanism allowing cloud users to control the geographical location of their data, stored or processed in plaintext on the premises of Infrastructure-as-a Service cloud providers. We use trusted computing principles and remote attestation to establish platform state. We enable cloud users to confine plaintext data exclusively to the jurisdictions they specify, by sealing decryption keys used to obtain plaintext data to the combination of cloud host geolocation and platform state. We provide a detailed description of the implementation as well as performance measurements on an open source cloud infrastructure platform using commodity hardware. (page 352, Abstract).
US Patent Application Publications
Gokhale 2014/0188804
A method of providing data storage services for a first computing device, comprising: determining, with a second computing device, a location of the first computing device; determining, with the second computing device, a country or geographic region corresponding to the location of the first computing device; querying a data structure using the country or geographic region to determine which data storage rules apply to the country or geographic region; and applying, with the second computing device, a data storage policy to application data generated by the first computing device, wherein the data storage policy includes creating at least one secondary copy of the application data, wherein the data storage policy is applied based on the data storage rules determined by querying the data structure, wherein applying the data storage policy includes adjusting one or more of: a frequency with which secondary copies of the application data are made, a location to which the secondary copies of the application data are stored, a type of secondary copy of the application data to be made, and security measures to be applied to at least some of the application data stored on the first computing device. The method of claim 1 wherein determining the country includes: querying a database with an IP address of the first computing device; and receiving an identification of the country from the database in response to the query. (claims 1 and 3).
Horowitz 2017/0286518
According to one embodiment, the method further comprises provisioning the cloud resources responsive to user entry of naming information, architecture information, database subsystem version, database geographic region, instance size, and database management information. According to one embodiment, the method further comprises generating user interface displays, wherein the user interface displays are configured to accept specification of: naming information (e.g., group name, cluster name, etc.); architecture information (e.g., replication factor, sharding enabled, etc.); a database subsystem version; a database geographic region; a database instance size (e.g., RAM, storage, etc.); and database management information (e.g., back up enabled). According to one embodiment, the method further comprises receiving optimization information from the central management server; automatically provisioning new cloud resources; and installing database subsystems having optimizations (e.g., new application version, updated storage engine, additional replica set nodes, etc.). (para 0014).
Gordon 2017/0353516
Techniques for serving a manifest file of an adaptive streaming video include receiving a request for the manifest file from a user device. The video is encoded at different reference bitrates and each encoded reference bitrate is divided into segments to generate video segment files. The manifest file includes an ordered list of universal resource locators (URLs) that reference a set of video segment files encoded at a particular reference bitrate. A source manifest file that indicates the set of video segment files is identified based on the request. An issued manifest file that includes a first URL and a second URL is generated based on the source manifest file. The first URL references a first domain and the second URL references a second domain that is different from the first domain. The issued manifest file is transmitted to the user device as a response to the request. (Abstract). Typically, in order to obtain the video segment files for playback the video player first requests a master manifest file, sometimes also called an index file or a playlist, by issuing an HTTP GET request for the master manifest Uniform Resource Locator (URL). The master manifest [list] is typically a text file comprising a plurality of URLs, each of which identifies a variant manifest; these URLs can be absolute or relative URLs, and are commonly relative URLs. The video player then requests some or all of the variant manifest files by issuing HTTP GET requests for the URLs of the required variant manifests. The video player may also issue HTTP header requests for the URLs of some or all of the variant manifests that are not requested in full (if any); this enables the video player to confirm that a manifest file is available for later download, and to obtain information about the file contained in the header. Each variant manifest is typically a text file comprising a plurality of URLs, each of which identifies a video segment file; these URLs can also be absolute or relative URLs, and are commonly relative URLs. Manifest files can contain other information in addition to URLs, for example metadata and other descriptive or control information. In the case of live or linear video, as the video player proceeds through playback of the segments identified in the then-current variant manifest, it will request an updated variant manifest, which should contain additional video segment URLs; in normal operation, updated variant manifest files will continue to be requested by, and available to, the video player until a manifest file is reached that contains an endlist tag or comparable indicator that the video stream has reached its end. (para 0021). In the primary embodiment and secondary embodiment there are multiple distributed instances of the manifest file handler, optionally organized into clusters wherein each cluster comprises multiple manifest file handler instances; the hostname associated with the network of manifest file handlers is resolved by the DNS Authoritative Name Servers to IP addresses of one or more manifest file handler clusters or one or more specific manifest file handlers based on any of, or any combination of: manifest file handler or manifest file handler cluster network location, e.g. relatively close in network terms (meaning a manifest file handler or manifest file handler cluster that can communicate over the network quickly, e.g. with less total latency, than can at least some other manifest file handlers or manifest file handler clusters) to any of, or any combination of, the network location of the local name server making the hostname resolution request, or to the estimated network location of the requesting user device, or to the network location from which a manifest file handler or manifest file handler cluster can receive the requested HLS manifest files, HLS manifest files associated with the digital service, or HLS manifest files generally, or to the network location of the digital service, or to the network location of an advertising service or server associated with the digital service, or to another network location associated with the digital service; manifest file handler or manifest file handler cluster geographic location; (paras 0130-0132). Determining a location that is close, in network terms, to a second location, or that is closer than other locations, in network terms, to a second location, or determining the distance in network terms between a first network location and a second network location (e.g., a requesting device and one or more infrastructure components) can be implemented by using any of, or any combination of, all or part of: the IP addresses of one or both of the two network locations; other Internet address information related to one or both of the two network locations, such as IP address blocks, IP address ranges, or Autonomous System Numbers; Internet routing information related to one or both of the two network locations, such as inter-AS or intra-AS routing tables; connectivity or utilization information related to one or both of the two network locations (for example, the capacity of one or more router ports, or the utilization of one or more router ports, related to one or both of the two network locations); performance measurements, including speed, throughput, latency, jitter, or other network performance characteristics, between two network locations, wherein each of the two locations comprising the measured pair of locations is either one of the locations between which the distance or determination of closeness is being determined or is a location related to one of the locations between which the distance or determination of closeness is being determined; a network map; a network database, comprising network addresses, address ranges, or other network information along with location information, distance information, performance information, or other information that can be used to determine the distance between two locations or closeness of one location to another. (para 0144). the manifest file handler, the network location or geographic location of the manifest file handler, or an attribute or characteristic associated with the manifest file handler; (para 0487).
Nagpal 2013/0036100
Deduplication in a network storage environment includes, for files stored in a network, determining a location constraint status specified by a compliance agreement for each of the files. Location constraint statuses include a location of persistent residency and no residency restriction. Deduplication also includes selecting a file from the files in the network and identifying corresponding redundant files, the selected file and the corresponding redundant files representing a set. Deduplication further includes determining the location constraint status for each of the files in the set. For the files in the set having a location constraint status specifying a location of persistent residency, the deduplication includes retaining a master copy at the respective location of persistent residency, and removing the corresponding redundant files from the network. (Abstract). Exemplary embodiments of the invention provide for deduplication in a network storage environment (e.g., a cloud storage architecture). The exemplary deduplication processes consider residency requirements of file storage when considering which redundant files to remove during deduplication. Residency requirements refer to restrictions or constraints with respect to one or more geographic locations in which copies of a file are permitted to reside in storage. For example, where copies of a file are located across multiple dispersed data centers in a network cloud, the exemplary deduplication processes identify the redundant files, ensure that a single master copy is stored in a location that complies with the residency requirements, and then eliminate all other copies of the file from their storage locations. (para 0016).
McCarthy 2015/0163206
In embodiments, a geo-tagging facility 278 may be provided, where a document may be geo-tagged such as to indicate where a document has been created, sent from, received, edited, viewed, and the like. Geo-tagging a document may include information that is appended to and travels with the document through distribution, sharing, modification, and archiving. Geo-tagging information may include geographical location information (e.g. city, state, territory, country, region, zip code, latitude and longitude), a business location (e.g. company name, company address, business unit), a network location (e.g. secure network, an enterprise network, a public network, a wireless network), a storage location (e.g. archive location, thumb-dive storage, DVD), and the like. In an example, a document may be created by a user at Company `A` in San Francisco, where the location information may include the company name and the city, as well as other information such as time and date and user's name. The document may then be distributed to two other users in two different counties working with two different companies, where this information may be appended to a geo-history of the document (e.g. as stored as metadata along with the document). Additional information may be appended to the document as it is edited, redistributed, and finally archived. The geo-location information may be searched on, such as during its life as an active document or while stored in archive. Geo-tagging of data may better enable the discovery of the document's history (and content therein), such as for legal or e-discovery searches. (para 0203).
Iyer 2017/0060918
Metadata generally includes information about data objects and/or characteristics associated with the data objects. For simplicity herein, it is to be understood that, unless expressly stated otherwise, any reference to primary data 112 generally also includes its associated metadata, but references to metadata generally do not include the primary data. Metadata can include, without limitation, one or more of the following: the data owner (e.g., the client or user that generates the data), the last modified time (e.g., the time of the most recent modification of the data object), a data object name (e.g., a file name), a data object size (e.g., a number of bytes of data), information about the content (e.g., an indication as to the existence of a particular search term), user-supplied tags, to/from information for email (e.g., an email sender, recipient, etc.), creation date, file type (e.g., format or application type), last accessed time, application type (e.g., type of application that generated the data object), location/network (e.g., a current, past or future location of the data object and network pathways to/from the data object), geographic location (e.g., GPS coordinates), frequency of change (e.g., a period in which the data object is modified), business unit (e.g., a group or department that generates, manages or is otherwise associated with the data object), aging information (e.g., a schedule, such as a time period, in which the data object is migrated to secondary or long term storage), boot sectors, partition layouts, file location within a file folder directory structure, user permissions, owners, groups, access control lists (ACLs), system metadata (e.g., registry information), combinations of the same or other similar information related to the data object. In addition to metadata generated by or related to file systems and operating systems, some applications 110 and/or other components of system 100 maintain indices of metadata for data objects, e.g., metadata associated with individual email messages. The use of metadata to perform classification and other functions is described in greater detail below. (para 0059).
US Patents
Gokhale 9,633,216
A method of providing data storage services for a first computing device, comprising: determining, with a second computing device, a current location of the first computing device, wherein the first computing device generates application data, and wherein the second computing device is associated with providing the data storage services for the first computing device; and wherein the first computing device is a mobile device; determining, with the second computing device, a country or geographic region corresponding to the current location of the first computing device; querying a data structure using the country or geographic region to determine which data storage rules apply to the determined country or geographic region corresponding to the current location of the first computing device, wherein the data storage rules are based on data retention regulations for the determined country or geographic region; and applying, with the second computing device, a data storage policy to the application data generated by the first computing device, wherein the application data includes production copies of data created at the first computing device, wherein the data storage policy includes creating at least one secondary copy of the application data, wherein the data storage policy is applied based on the data storage rules determined by querying the data structure to apply to the determined country or geographic region corresponding to the current location of the first computing device, wherein the applied data storage policy includes: a frequency with which secondary copies of the production copies of the application data are made, a location to which the secondary copies of the production copies of the application data are stored, a type of secondary copy of the production copies of the application data to be made, and security measures to be applied to at least some of the application data stored on the first computing device. The method of claim 1 wherein determining the country includes: querying a database with an IP address of the first computing device; and receiving an identification of the country from the database in response to the query. (claims 1 and 3).
Maier 9,800,557
In an example, it is assumed that only one privacy regime is applicable to the example data processing system 100. In another example, the privacy regime may be the German data privacy act. Then, handling and processing of restricted-access data is limited to a geographic region restricted-access data must neither be stored, neither processed nor transmitted by hardware and/or media outside that geographical region and the privileged section 132 of the data processing system 100 may be determined according to the geographic place of its underlying hardware components and signal transmission media. (col. 5 lines 39-49).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner ROBERT STEVENS whose telephone number is (571) 272-4102. The examiner can normally be reached Mon - Fri 6:00 - 2:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amy Ng can be reached on (571) 270-1698. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ROBERT STEVENS/Primary Examiner, Art Unit 2164
June 27, 2026
Prosecution Insights