DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Introduction
This is a final office action in response to remarks filed on 16 January 2026. Claims 1, 5-8, 10, 13-15, and 17 are amended. No claims are canceled or added. Claims 1-20 are pending.
Claim Interpretation
The claims have been considered according to the latest Patent Eligibility Guidelines and are considered eligible.
Response to Arguments
Applicant’s arguments, see pages 10-11, filed 16 January 2026, with respect to the rejections of claims 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, new grounds of rejection are made incorporating newly discovered Krig et al. (U.S. Patent Publication 2015/0319137) in the rejections below.
Examiner notes that applicant’s arguments are directed to the applicability of the cited prior art with respect to the amended claim language, however examiner relies upon newly discovered Krig et al. (U.S. Patent Publication 2015/0319137) as the new primary prior art to teach these amendments and other aspects of the changed claim scope.
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 (i.e., changing from AIA to pre-AIA ) 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, 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.
Claims 1-2, 5-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Krig et al. (U.S. Patent Publication 2015/0319137) in view of Gokhale et al. (U.S. Patent Publication 2014/0188804) and further in view of Reineke et al. (U.S. Patent Publication 2023/0121250).
Regarding claim 1, Krig disclosed a computer-implemented method (see Krig Fig. 2, [0036]: method | Fig. 1, [0017]: communications system comprising a variety of components to implement connection management) comprising:
obtaining information associated with a device (Krig disclosed determining device characteristics, e.g., location, of a source device or intermediate device through which a connection is routed - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110…In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0020]: “The connection management applications 110 may comprise a traffic analysis component 124. The traffic analysis component 124 may be generally arranged to determine one or more characteristics of the routing of the connection. These characteristics may comprise information about the connection source 140 or any of the one or more entities through which the connection 130 is routed. These characteristics may comprise a name, country, street address, Internet Protocol (IP) address, service provider, domain name, physical location, GPS coordinates, a type of traffic (e.g. text, binary, encrypted, video, images), a quantity of traffic, and a duration of the connection. In various embodiments, the traffic analysis component 124 may be operative to perform a unified analysis of a plurality of connections wherein each of the plurality of connections is associated with a particular client network application or network task, such as a web browser or the loading of a web page. Specifically, the traffic analysis component 124 may be operative to determine a plurality of characteristics corresponding to a plurality of entities associated with the hosting of a web page, such as characteristics corresponding to the plurality of entities hosting the elements of the web page and the plurality of entities responsible for the routing of the connection 130.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.”);
obtaining information associated with policies for a plurality of jurisdictions (Krig disclosed obtaining rules, blacklists, whitelists, and preference lists that are used when determining whether or not to block a connection based on determined characteristics, e.g., determining whether or not traffic is permitted to pass through a device’s location - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110. The connection management application 110 may be generally arranged to manage network communications for a client device and/or user. In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”),
the policies including data sovereignty policies (see Gokhale combination below) and
environmental policies for each jurisdiction of the plurality of jurisdictions (see Reineke combination below),
wherein at least one jurisdiction of the plurality of jurisdictions is associated with a route for network traffic associated with the device (Krig disclosed determining whether or not network traffic is permitted to pass through an intermediate device’s location - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”);
determining a set of constraints for regulating use of the device based on the information associated with the device and the policies for the plurality of jurisdictions (Examiner interprets “a set of constraints” as being functionally equivalent to the variables/settings within a rule/policy and that “determining a set of constraints…” is inherently performed when applying the rule. Krig disclosed obtaining rules, blacklists, whitelists, and preference lists indicating the locations through which network traffic is permitted or not permitted to pass and determining whether or not a device’s location corresponds to the location specified within the rule in order to determine whether or not the device’s location is a permitted location through which network traffic is permitted to pass – see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0024]: “In various embodiments, the network control component 128 may be operative to present a user of the connection management application 110 with a user interface view containing a query that an incoming connection 130 has been received and that the user may decide to either allow or block the connection 130. In some embodiments, this query may be avoided if the determined characteristics of an incoming connection 130 match one or more whitelist rules which specify that connections matching those rules should be automatically allowed. In this manner, a user may be able to specify that certain characteristics (such as physical locations) result in a connection 130 being blocked, that certain characteristics result in a connection 130 being automatically allowed, and that any other connection 130 results in the user being queried to determine whether the connection 130 should be allowed or blocked. As such, whether or not a user is presented with one or more of the determined characteristics and whether or not a user is queried as to whether a connection 130 should be blocked may itself be determined by the determined characteristics. It will be appreciated that this same technique may be applied to outgoing connections, particularly as computer devices may initiate a large number of connections in response to a user action—such as opening a web page—that would not be immediately apparent to the user.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”);
regulating the use of the device based on the set of constraints (Krig disclosed determining whether or not a device’s location corresponds to the location specified within the rule in order to determine whether or not the device’s location is a permitted location through which network traffic is permitted to pass - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0024]: “In various embodiments, the network control component 128 may be operative to present a user of the connection management application 110 with a user interface view containing a query that an incoming connection 130 has been received and that the user may decide to either allow or block the connection 130. In some embodiments, this query may be avoided if the determined characteristics of an incoming connection 130 match one or more whitelist rules which specify that connections matching those rules should be automatically allowed. In this manner, a user may be able to specify that certain characteristics (such as physical locations) result in a connection 130 being blocked, that certain characteristics result in a connection 130 being automatically allowed, and that any other connection 130 results in the user being queried to determine whether the connection 130 should be allowed or blocked. As such, whether or not a user is presented with one or more of the determined characteristics and whether or not a user is queried as to whether a connection 130 should be blocked may itself be determined by the determined characteristics. It will be appreciated that this same technique may be applied to outgoing connections, particularly as computer devices may initiate a large number of connections in response to a user action—such as opening a web page—that would not be immediately apparent to the user.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods… For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”);
determining, based on the information associated with the device and the policies for plurality of jurisdictions, network traffic routing information associated with the device (Krig disclosed presenting a network traffic routing map and also determining whether or not the intermediate nodes of the route comply with the jurisdiction-based routing rules - see Krig [0023]: “…For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.” | [0026]: “In some embodiments, the network control component 128 may be specifically operative to individually determine whether to block or allow each of a plurality of connections 130 that are associated with the performance of a single user request, such as a user request to a web browser to visit a web page. In some embodiments, connections to the server or servers corresponding to a uniform resource locator (URL) of the web page may be automatically allowed as being the direct result of a user action, while any connections 130 to other servers are considered according to the rules of the network control component 128. In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.”; [0030]: “…In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”), wherein the network traffic routing information includes information indicating whether any jurisdiction of the plurality of jurisdictions is a restricted jurisdiction through which network traffic associated with the device is not allowed to flow (Krig disclosed referring to a blacklist when determining whether or not the location of an intermediate node of the route complies with the jurisdiction-based routing rules and that the blacklist may be specified within a field of a request to establish a network connection - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0026]: “In some embodiments, the network control component 128 may be specifically operative to individually determine whether to block or allow each of a plurality of connections 130 that are associated with the performance of a single user request, such as a user request to a web browser to visit a web page. In some embodiments, connections to the server or servers corresponding to a uniform resource locator (URL) of the web page may be automatically allowed as being the direct result of a user action, while any connections 130 to other servers are considered according to the rules of the network control component 128. In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”); and
routing the network traffic associated with the device based on the network traffic routing information (Krig disclosed allowing or blocking traffic through a particular device depending on whether or not the device’s location complies with rules and the device’s presence on a blacklist, whitelist, or other list - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.” | [0032]: “In some embodiments, the SPDNS protocol may be used to negotiate with a network to determine a routing for a connection. For example, either the initiating endpoint or the destination endpoint of a connection may authenticate a SPDNS (such as by using public/private key cryptography) and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the initiating endpoint and the destination endpoint or a routing path proposed by the SPDNS server) until the endpoint accepts a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server). In some embodiments, the SPDNS protocol may comprise a common middleground for negotiating a connection between two endpoints. For example, the two endpoints of a connection may mutually authenticate each other (such as by using public/private key cryptography), and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the endpoints or a routing path proposed by the SPDNS server) until both endpoints accept a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server).”; [0033]: “In some embodiments, a standardized icon may be used to communicate that a verified connection path (VCP) has been established for a connection. This may comprise a particular image or may comprise a standardized piece of text, such as “HTTP-VCP://” as a counterpart to the traditional “HTTPS://” indicating a secure connection, where HTTP refers to a “hypertext transfer protocol” and HTTPS refers to a “HTTP secure protocol.” A user client may be operative to display the VCP icon when a connection with verified routing has been established according to the embodiments contained herein, and to not display the VCP icon when no such verified connection has been established…”).
With respect to the limitation “the policies including data sovereignty policies and environmental policies for each jurisdiction of the plurality of jurisdictions”:
Krig disclosed applying jurisdiction-based policies when determining the route for network traffic (see Krig [0023]: “…The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block...For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.”) and that the type of data is one example of a characteristic used when applying rules to determine whether or not a connection is permitted (see Krig [0023]: “…Any of the determined characteristics may be used as the basis of a decision to block or not to block...” | [0021]: “The one or more characteristic can be determined in a variety of ways according to a variety of techniques. In some embodiments, these techniques may comprise one or more of…examining the data payloads of the connection 130 to determine the type of data carried by the connection 130…” | [0026]: “…In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.”).
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that Krig’s analysis of data type when applying jurisdiction-based policies would include applying data sovereignty policies, however Krig did not explicitly disclose that the jurisdiction-based policies include “data sovereignty policies”.
However in a related art, Gokhale disclosed applying an information management policy to production data of the computing device based on regulations of the geographic entity (see Gokhale Fig. 6 #615). The information management policies are stored in a database (see Gokhale [0045]) that is connected to computing systems of regulatory bodies of countries throughout the world (see Gokhale [0097]). The location of a device is compared to a set of rules, such as the access control list of Table 4 indicating a list of prohibited information in different countries (see Gokhale [0117]), and a security operation is performed depending on if the type of data is permitted in the device’s location (see Gokhale Fig. 9, [0119]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding consideration of data sovereignty polices would provide a system to track routing compliance according to a variety of policies. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Although Krig disclosed “…Any of the determined characteristics may be used as the basis of a decision to block or not to block...” (see Krig [0023]), Krig-Gokhale did not explicitly disclose that the jurisdiction-based policies include “environmental policies”.
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the particular types of policies used when analyzing and determining permitted communication routes are matters of implementation choice, however in a related art, Reineke disclosed a variety of sustainability factors, e.g. energy and power consumption (see Reineke [0009]+Table), and minimum standards/thresholds for resources that are set by governments, etc. (see Reineke [0024]). Fig. 3 illustrates a process for identifying resources that comply with the sustainability values and governance control, as well as topology control (e.g., [0037]: data may be located in a zone with a max power level and it is determined that performing computation will exceed the threshold). The diagnostic system evaluates resource usage and capabilities (see [0038]) and a tradeoff analysis is performed to determine appropriate resources (see [0039]). This determination filters resources according to elements that are most aligned with sustainability considerations (see [0041]) and the top choice is automatically selected and deployed (see [0043]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale and Reineke to further clarify additional types of policies and limits on network resources. Expanding upon Krig’s desire to adhere to geographic-based policies (see Krig [0010]) and Gokhale’s selection of less-resource intensive computing operations (see Gokhale 0074) to include Reineke’s analysis of computing resources would ensure that computing resources are selected based on considerations for sustainability requirements and relevant government mandates for the applicable locale(s) (see Reineke [0002]), thereby ensuring that sustainability requirements are met (see Reineke [0008]).
Regarding claim 2, Krig-Gokhale-Reineke disclosed the computer-implemented method of claim 1, wherein the information associated with the device includes a location of the device (Krig disclosed determining device characteristics, e.g., location, of a source device or intermediate device through which a connection is routed - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110…In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0020]: “The connection management applications 110 may comprise a traffic analysis component 124. The traffic analysis component 124 may be generally arranged to determine one or more characteristics of the routing of the connection. These characteristics may comprise information about the connection source 140 or any of the one or more entities through which the connection 130 is routed. These characteristics may comprise a name, country, street address, Internet Protocol (IP) address, service provider, domain name, physical location, GPS coordinates, a type of traffic (e.g. text, binary, encrypted, video, images), a quantity of traffic, and a duration of the connection. In various embodiments, the traffic analysis component 124 may be operative to perform a unified analysis of a plurality of connections wherein each of the plurality of connections is associated with a particular client network application or network task, such as a web browser or the loading of a web page. Specifically, the traffic analysis component 124 may be operative to determine a plurality of characteristics corresponding to a plurality of entities associated with the hosting of a web page, such as characteristics corresponding to the plurality of entities hosting the elements of the web page and the plurality of entities responsible for the routing of the connection 130.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.”).
Regarding claim 5, Krig-Gokhale-Reineke disclosed the computer-implemented method of claim 1, wherein regulating the use of the device and routing the network traffic associated with the device includes:
identifying that particular network traffic associated with the device has been transmitted through a restricted jurisdiction (Krig disclosed determining whether or not traffic was routed through a country included on a blacklist - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics…For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist…”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist…In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”); and
performing packet inspection on the particular network traffic to identify threats or drop packets associated with the particular network traffic (Krig disclosed examining packets to identify data type within the pack and whether or not the packet’s route includes a blacklisted location, i.e. identifying threats associated with the network traffic - see Krig [0021]: “The one or more characteristic can be determined in a variety of ways according to a variety of techniques…examining the data payloads of the connection 130 to determine the type of data carried by the connection 130. In some embodiments, this may comprise examining a hypertext markup language (HTML) or multipurpose internet mail extension (MIME) encoding of data, which may contain one or more data fields indicating a data type. It will be appreciated that these techniques can be combined to determine information that would not be determined by any one being used alone…” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”).
Regarding claim 6, Krig-Gokhale-Reineke disclosed the invention, substantially as claimed, as described in the computer-implemented method of claim 1 above, wherein regulating the use of the device and routing the network traffic associated with the device includes:
determining that hardware associated with the device is above a threshold limit on power consumption or infringes sustainability principles for a jurisdiction (see Reineke [0009]+Table: “Embodiments illustrated herein are directed to receiving a request for infrastructure resources from a user of an infrastructure computing system. Hierarchical sustainability values are accessed for entities. For example, the infrastructure computing system itself may have sustainability values that are required. …”; table in [0009] includes a variety of sustainability factors, e.g. energy and power consumption | [0024]: “The trade-off analysis rules 116 are a set of minimum standards. Such standards may be set by governments, organization, or other entities…” | Fig. 3 illustrates a process for identifying resources that comply with the sustainability values and governance control, as well as topology control (e.g., [0037]: data may be located in a zone with a max power level and it is determined that performing computation will exceed the threshold); [0038]: The diagnostic system evaluates resource usage and capabilities; [0039]: a tradeoff analysis is performed to determine appropriate resources; [0041]: the determination of appropriate resources filters resources according to elements that are most aligned with sustainability considerations; [0043]: the top choice is automatically selected and deployed); and
routing the network traffic associated with the device to maintain adherence (Krig disclosed allowing or blocking traffic through a particular device depending on whether or not the device’s location complies with rules, thereby maintaining adherence to the applicable policies - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.” | [0032]: “In some embodiments, the SPDNS protocol may be used to negotiate with a network to determine a routing for a connection. For example, either the initiating endpoint or the destination endpoint of a connection may authenticate a SPDNS (such as by using public/private key cryptography) and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the initiating endpoint and the destination endpoint or a routing path proposed by the SPDNS server) until the endpoint accepts a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server). In some embodiments, the SPDNS protocol may comprise a common middleground for negotiating a connection between two endpoints. For example, the two endpoints of a connection may mutually authenticate each other (such as by using public/private key cryptography), and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the endpoints or a routing path proposed by the SPDNS server) until both endpoints accept a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server).”; [0033]: “In some embodiments, a standardized icon may be used to communicate that a verified connection path (VCP) has been established for a connection. This may comprise a particular image or may comprise a standardized piece of text, such as “HTTP-VCP://” as a counterpart to the traditional “HTTPS://” indicating a secure connection, where HTTP refers to a “hypertext transfer protocol” and HTTPS refers to a “HTTP secure protocol.” A user client may be operative to display the VCP icon when a connection with verified routing has been established according to the embodiments contained herein, and to not display the VCP icon when no such verified connection has been established…”) to the sustainability principles (see Reineke [0009]+Table: “Embodiments illustrated herein are directed to receiving a request for infrastructure resources from a user of an infrastructure computing system. Hierarchical sustainability values are accessed for entities. For example, the infrastructure computing system itself may have sustainability values that are required. …”; table in [0009] includes a variety of sustainability factors, e.g. energy and power consumption | Fig. 3 illustrates a process for identifying resources that comply with the sustainability values and governance control, as well as topology control (e.g., [0037]: data may be located in a zone with a max power level and it is determined that performing computation will exceed the threshold); [0038]: The diagnostic system evaluates resource usage and capabilities; [0039]: a tradeoff analysis is performed to determine appropriate resources; [0041]: the determination of appropriate resources filters resources according to elements that are most aligned with sustainability considerations; [0043]: the top choice is automatically selected and deployed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale and Reineke to further clarify additional types of policies and limits on network resources. Expanding upon Krig’s desire to adhere to geographic-based policies (see Krig [0010]) and Gokhale’s selection of less-resource intensive computing operations (see Gokhale 0074) to include Reineke’s analysis of computing resources would ensure that computing resources are selected based on considerations for sustainability requirements and relevant government mandates for the applicable locale(s) (see Reineke [0002]), thereby ensuring that sustainability requirements are met (see Reineke [0008]).
Regarding claim 7, Krig-Gokhale-Reineke disclosed the computer-implemented method of claim 1, wherein routing the network traffic associated with the device includes:
identifying a path for transmitting the network traffic associated with the device based on the policies for the plurality of jurisdictions (Krig disclosed determining a route and allowing or blocking traffic through a particular device depending on whether or not the device’s location complies with rules and the device’s presence on a blacklist, whitelist, or other list - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.” | [0032]: “In some embodiments, the SPDNS protocol may be used to negotiate with a network to determine a routing for a connection. For example, either the initiating endpoint or the destination endpoint of a connection may authenticate a SPDNS (such as by using public/private key cryptography) and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the initiating endpoint and the destination endpoint or a routing path proposed by the SPDNS server) until the endpoint accepts a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server). In some embodiments, the SPDNS protocol may comprise a common middleground for negotiating a connection between two endpoints. For example, the two endpoints of a connection may mutually authenticate each other (such as by using public/private key cryptography), and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the endpoints or a routing path proposed by the SPDNS server) until both endpoints accept a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server).”; [0033]: “In some embodiments, a standardized icon may be used to communicate that a verified connection path (VCP) has been established for a connection. This may comprise a particular image or may comprise a standardized piece of text, such as “HTTP-VCP://” as a counterpart to the traditional “HTTPS://” indicating a secure connection, where HTTP refers to a “hypertext transfer protocol” and HTTPS refers to a “HTTP secure protocol.” A user client may be operative to display the VCP icon when a connection with verified routing has been established according to the embodiments contained herein, and to not display the VCP icon when no such verified connection has been established…”).
Regarding claim 8, Krig-Gokhale-Reineke disclosed the computer-implemented method of claim 1, wherein regulating the use of the device and the network traffic associated with the device includes:
determining that the device has been booted up in a restricted jurisdiction (see Gokhale [0025] “The disclosed systems and methods also enable automated application of geographic-based security features. In one aspect, the system determines a location of a computing device, determines a geographic-based rule for operating the computing device, and selectively erases or wipes the primary copy of data on the computing device if the computing device is operating within a prohibited geographic entity or region…”); and
wiping data associated with the device based on determining that the device has been booted up in the restricted jurisdiction (see Gokhale [0025] “The disclosed systems and methods also enable automated application of geographic-based security features. In one aspect, the system determines a location of a computing device, determines a geographic-based rule for operating the computing device, and selectively erases or wipes the primary copy of data on the computing device if the computing device is operating within a prohibited geographic entity or region. In other aspects, the system may enable a user to view a webpage that displays the logged locations of the computing device, and indicate via the webpage that the computing device was lost or stolen, e.g., if the user does not recognize the last logged location of the computing device. Through the webpage, the user may execute a remote erasure or wipe of the production copy of data on the computing device.” | [0119] “At block 910, the information management server compares the location of the computing device in the table to a set of rules, such as the access control list of Table 4. The set of rules may include a list of geographic entities, e.g., countries, and a corresponding list of prohibited types or classifications of information for the geographic entities. As shown in Table 4, a computing device having only general business information or general business information and confidential information being operated in a geographic entity such as Libya is not prohibited, so the information management server takes no further action. However, the same computing device having general business information and confidential information would be prohibited in a geographic entity such as North Korea, according to the access list of Table 4. If the information management server to determines that the computing device is in a geographic entity where information is prohibited, the process proceeds to block 915 to perform security operations on the computing device.” | [0125] “At block 930, the information management server may delete some or all of the information on the computing device i.e. the local copies, if necessitated by the regulations, the above-noted table or other rules. After creating a secondary copy of the information, the surest prophylactic measure to ensure that the prohibited information is not transferred may be to completely remove the information from the computing device and perform multiple overwrites of data to ensure no recovery of the previously existing data may be performed.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied and how to enforce them. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding consideration of data sovereignty policies and how to enforce them would provide a system to track compliance according to a variety of policies. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Regarding claim 9, Krig-Gokhale-Reineke disclosed the computer-implemented method of claim 1, wherein the set of constraints is updated dynamically based on changes to the information associated with the device or the policies for the plurality of jurisdictions (see Gokhale [0067]: “A brief overview of certain aspects of the techniques described in greater detail below is now provided. Regulations for managing information, e.g., data retention, may change from one geographic entity or region to another. Manually updating information management policies manual may be a challenge for IT groups because of the frequency and ease with which employees travel with mobile or portable computing devices. Some of the techniques disclosed herein relate to determining and/or adjusting information management policies based on which geographic entity a computing device operates within. The disclosed techniques advantageously provide information management services more responsively than management by a person and provide information management services requiring support from significantly less personnel-resources.” | [0097] “An IT administrator or other person may populate and maintain the data structure that includes the regulations. The data structure may be sortable by geographic entity, e.g., by a geographic entity field in the data structure, so that when regulations for, as an example, Italy change, a person may easily update various aspects of the information management policy for Italy. In some implementations, the system may be connected to computing systems of regulatory bodies of geographic entities, e.g., countries, throughout the world and may be configured to parse regulatory information and automatically populate and/or update the data structure.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied and how to update them. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding dynamically updating geographic-based policies would provide a system to track compliance according to a variety of policies that are dynamically updated. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Regarding claim 10, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Krig disclosed, as recited in claim 10: An apparatus comprising:
an interface configured to enable network communications (see Krig Fig. 2, [0036]: method | Fig. 1, [0017]: communications system comprising a variety of components to implement connection management | Fig. 5 #542 input device interface connected to network, [0051]: components include processor(s), storage medium, program, interfaces for sending messages, etc.);
a memory (see Krig Fig. 5 #506 memory, [0051]: components include processor(s), storage medium, program, interfaces for sending messages, etc.); and
one or more processors coupled to the interface and the memory (see Krig Fig. 5 #504 processing unit, #506 memory, #542 input device interface, [0051]: components include processor(s), storage medium, program, interfaces for sending messages, etc.), and configured to:
obtain information associated with a device (Krig disclosed determining device characteristics, e.g., location, of a source device or intermediate device through which a connection is routed - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110…In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0020]: “The connection management applications 110 may comprise a traffic analysis component 124. The traffic analysis component 124 may be generally arranged to determine one or more characteristics of the routing of the connection. These characteristics may comprise information about the connection source 140 or any of the one or more entities through which the connection 130 is routed. These characteristics may comprise a name, country, street address, Internet Protocol (IP) address, service provider, domain name, physical location, GPS coordinates, a type of traffic (e.g. text, binary, encrypted, video, images), a quantity of traffic, and a duration of the connection. In various embodiments, the traffic analysis component 124 may be operative to perform a unified analysis of a plurality of connections wherein each of the plurality of connections is associated with a particular client network application or network task, such as a web browser or the loading of a web page. Specifically, the traffic analysis component 124 may be operative to determine a plurality of characteristics corresponding to a plurality of entities associated with the hosting of a web page, such as characteristics corresponding to the plurality of entities hosting the elements of the web page and the plurality of entities responsible for the routing of the connection 130.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.”);
obtain information associated with policies for a plurality of jurisdictions (Krig disclosed obtaining rules, blacklists, whitelists, and preference lists that are used when determining whether or not to block a connection based on determined characteristics, e.g., determining whether or not traffic is permitted to pass through a device’s location - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110. The connection management application 110 may be generally arranged to manage network communications for a client device and/or user. In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”),
the policies including data sovereignty policies (see Gokhale combination below) and
environmental policies for each jurisdiction of the plurality of jurisdictions (see Reineke combination below),
wherein at least one jurisdiction of the plurality of jurisdictions is associated with a route for network for network traffic associated with the device (Krig disclosed determining whether or not network traffic is permitted to pass through an intermediate device’s location - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”);
determine a set of constraints for regulating use of the device based on the information associated with the device and the policies for the plurality of jurisdictions (Examiner interprets “a set of constraints” as being functionally equivalent to the variables/settings within a rule/policy and that “determining a set of constraints…” is inherently performed when applying the rule. Krig disclosed obtaining rules, blacklists, whitelists, and preference lists indicating the locations through which network traffic is permitted or not permitted to pass and determining whether or not a device’s location corresponds to the location specified within the rule in order to determine whether or not the device’s location is a permitted location through which network traffic is permitted to pass – see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0024]: “In various embodiments, the network control component 128 may be operative to present a user of the connection management application 110 with a user interface view containing a query that an incoming connection 130 has been received and that the user may decide to either allow or block the connection 130. In some embodiments, this query may be avoided if the determined characteristics of an incoming connection 130 match one or more whitelist rules which specify that connections matching those rules should be automatically allowed. In this manner, a user may be able to specify that certain characteristics (such as physical locations) result in a connection 130 being blocked, that certain characteristics result in a connection 130 being automatically allowed, and that any other connection 130 results in the user being queried to determine whether the connection 130 should be allowed or blocked. As such, whether or not a user is presented with one or more of the determined characteristics and whether or not a user is queried as to whether a connection 130 should be blocked may itself be determined by the determined characteristics. It will be appreciated that this same technique may be applied to outgoing connections, particularly as computer devices may initiate a large number of connections in response to a user action—such as opening a web page—that would not be immediately apparent to the user.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”); and
regulate the use of the device based on the set of constraints (Krig disclosed determining whether or not a device’s location corresponds to the location specified within the rule in order to determine whether or not the device’s location is a permitted location through which network traffic is permitted to pass - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0024]: “In various embodiments, the network control component 128 may be operative to present a user of the connection management application 110 with a user interface view containing a query that an incoming connection 130 has been received and that the user may decide to either allow or block the connection 130. In some embodiments, this query may be avoided if the determined characteristics of an incoming connection 130 match one or more whitelist rules which specify that connections matching those rules should be automatically allowed. In this manner, a user may be able to specify that certain characteristics (such as physical locations) result in a connection 130 being blocked, that certain characteristics result in a connection 130 being automatically allowed, and that any other connection 130 results in the user being queried to determine whether the connection 130 should be allowed or blocked. As such, whether or not a user is presented with one or more of the determined characteristics and whether or not a user is queried as to whether a connection 130 should be blocked may itself be determined by the determined characteristics. It will be appreciated that this same technique may be applied to outgoing connections, particularly as computer devices may initiate a large number of connections in response to a user action—such as opening a web page—that would not be immediately apparent to the user.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods… For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”);
determine, based on the information associated with the device and the policies for the plurality of jurisdictions, network traffic routing information associated with the device (Krig disclosed presenting a network traffic routing map and also determining whether or not the intermediate nodes of the route comply with the jurisdiction-based routing rules - see Krig [0023]: “…For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.” | [0026]: “In some embodiments, the network control component 128 may be specifically operative to individually determine whether to block or allow each of a plurality of connections 130 that are associated with the performance of a single user request, such as a user request to a web browser to visit a web page. In some embodiments, connections to the server or servers corresponding to a uniform resource locator (URL) of the web page may be automatically allowed as being the direct result of a user action, while any connections 130 to other servers are considered according to the rules of the network control component 128. In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.”; [0030]: “…In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”), wherein the network traffic routing information includes information indicating whether any jurisdiction of the plurality of jurisdictions is a restricted jurisdiction through which network traffic associated with the device is not allowed to flow (Krig disclosed referring to a blacklist when determining whether or not the location of an intermediate node of the route complies with the jurisdiction-based routing rules and that the blacklist may be specified within a field of a request to establish a network connection - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0026]: “In some embodiments, the network control component 128 may be specifically operative to individually determine whether to block or allow each of a plurality of connections 130 that are associated with the performance of a single user request, such as a user request to a web browser to visit a web page. In some embodiments, connections to the server or servers corresponding to a uniform resource locator (URL) of the web page may be automatically allowed as being the direct result of a user action, while any connections 130 to other servers are considered according to the rules of the network control component 128. In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”); and
route the network traffic associated with the device based on the network traffic routing information (Krig disclosed allowing or blocking traffic through a particular device depending on whether or not the device’s location complies with rules and the device’s presence on a blacklist, whitelist, or other list - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.” | [0032]: “In some embodiments, the SPDNS protocol may be used to negotiate with a network to determine a routing for a connection. For example, either the initiating endpoint or the destination endpoint of a connection may authenticate a SPDNS (such as by using public/private key cryptography) and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the initiating endpoint and the destination endpoint or a routing path proposed by the SPDNS server) until the endpoint accepts a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server). In some embodiments, the SPDNS protocol may comprise a common middleground for negotiating a connection between two endpoints. For example, the two endpoints of a connection may mutually authenticate each other (such as by using public/private key cryptography), and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the endpoints or a routing path proposed by the SPDNS server) until both endpoints accept a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server).”; [0033]: “In some embodiments, a standardized icon may be used to communicate that a verified connection path (VCP) has been established for a connection. This may comprise a particular image or may comprise a standardized piece of text, such as “HTTP-VCP://” as a counterpart to the traditional “HTTPS://” indicating a secure connection, where HTTP refers to a “hypertext transfer protocol” and HTTPS refers to a “HTTP secure protocol.” A user client may be operative to display the VCP icon when a connection with verified routing has been established according to the embodiments contained herein, and to not display the VCP icon when no such verified connection has been established…”).
With respect to the limitation “the policies including data sovereignty policies and environmental policies for each jurisdiction of the plurality of jurisdictions”:
Krig disclosed applying jurisdiction-based policies when determining the route for network traffic (see Krig [0023]: “…The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block...For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.”) and that the type of data is one example of a characteristic used when applying rules to determine whether or not a connection is permitted (see Krig [0023]: “…Any of the determined characteristics may be used as the basis of a decision to block or not to block...” | [0021]: “The one or more characteristic can be determined in a variety of ways according to a variety of techniques. In some embodiments, these techniques may comprise one or more of…examining the data payloads of the connection 130 to determine the type of data carried by the connection 130…” | [0026]: “…In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.”).
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that Krig’s analysis of data type when applying jurisdiction-based policies would include applying data sovereignty policies, however Krig did not explicitly disclose that the jurisdiction-based policies include “data sovereignty policies”.
However in a related art, Gokhale disclosed applying an information management policy to production data of the computing device based on regulations of the geographic entity (see Gokhale Fig. 6 #615). The information management policies are stored in a database (see Gokhale [0045]) that is connected to computing systems of regulatory bodies of countries throughout the world (see Gokhale [0097]). The location of a device is compared to a set of rules, such as the access control list of Table 4 indicating a list of prohibited information in different countries (see Gokhale [0117]), and a security operation is performed depending on if the type of data is permitted in the device’s location (see Gokhale Fig. 9, [0119]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding consideration of data sovereignty polices would provide a system to track routing compliance according to a variety of policies. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Although Krig disclosed “…Any of the determined characteristics may be used as the basis of a decision to block or not to block...” (see Krig [0023]), Krig-Gokhale did not explicitly disclose that the jurisdiction-based policies include “environmental policies”.
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the particular types of policies used when analyzing and determining permitted communication routes are matters of implementation choice, however in a related art, Reineke disclosed a variety of sustainability factors, e.g. energy and power consumption (see Reineke [0009]+Table), and minimum standards/thresholds for resources that are set by governments, etc. (see Reineke [0024]). Fig. 3 illustrates a process for identifying resources that comply with the sustainability values and governance control, as well as topology control (e.g., [0037]: data may be located in a zone with a max power level and it is determined that performing computation will exceed the threshold). The diagnostic system evaluates resource usage and capabilities (see [0038]) and a tradeoff analysis is performed to determine appropriate resources (see [0039]). This determination filters resources according to elements that are most aligned with sustainability considerations (see [0041]) and the top choice is automatically selected and deployed (see [0043]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale and Reineke to further clarify additional types of policies and limits on network resources. Expanding upon Krig’s desire to adhere to geographic-based policies (see Krig [0010]) and Gokhale’s selection of less-resource intensive computing operations (see Gokhale 0074) to include Reineke’s analysis of computing resources would ensure that computing resources are selected based on considerations for sustainability requirements and relevant government mandates for the applicable locale(s) (see Reineke [0002]), thereby ensuring that sustainability requirements are met (see Reineke [0008]).
Regarding claim 11, the claim contains the limitations, substantially as claimed, as described in claim 2 above. Krig-Gokhale-Reineke disclosed, as recited in claim 11: The apparatus of claim 10, wherein the information associated with the device includes a location of the device (Krig disclosed determining device characteristics, e.g., location, of a source device or intermediate device through which a connection is routed - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110…In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0020]: “The connection management applications 110 may comprise a traffic analysis component 124. The traffic analysis component 124 may be generally arranged to determine one or more characteristics of the routing of the connection. These characteristics may comprise information about the connection source 140 or any of the one or more entities through which the connection 130 is routed. These characteristics may comprise a name, country, street address, Internet Protocol (IP) address, service provider, domain name, physical location, GPS coordinates, a type of traffic (e.g. text, binary, encrypted, video, images), a quantity of traffic, and a duration of the connection. In various embodiments, the traffic analysis component 124 may be operative to perform a unified analysis of a plurality of connections wherein each of the plurality of connections is associated with a particular client network application or network task, such as a web browser or the loading of a web page. Specifically, the traffic analysis component 124 may be operative to determine a plurality of characteristics corresponding to a plurality of entities associated with the hosting of a web page, such as characteristics corresponding to the plurality of entities hosting the elements of the web page and the plurality of entities responsible for the routing of the connection 130.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.”).
Regarding claim 13, the claim contains the limitations, substantially as claimed, as described in claim 5 above. Krig-Gokhale-Reineke disclosed, as recited in claim 13: The apparatus of claim 10, wherein, when routing the network traffic associated with the device, the one or more processors are configured to:
identify that particular network traffic associated with the device has been transmitted through a restricted jurisdiction (Krig disclosed determining whether or not traffic was routed through a country included on a blacklist - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics…For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist…”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist…In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”); and
perform packet inspection on the particular network traffic to identify threats or drop packets associated with the particular network traffic (Krig disclosed examining packets to identify data type within the pack and whether or not the packet’s route includes a blacklisted location, i.e. identifying threats associated with the network traffic - see Krig [0021]: “The one or more characteristic can be determined in a variety of ways according to a variety of techniques…examining the data payloads of the connection 130 to determine the type of data carried by the connection 130. In some embodiments, this may comprise examining a hypertext markup language (HTML) or multipurpose internet mail extension (MIME) encoding of data, which may contain one or more data fields indicating a data type. It will be appreciated that these techniques can be combined to determine information that would not be determined by any one being used alone…” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”).
Regarding claim 14, the claim contains the limitations, substantially as claimed, as described in claim 7 above. Krig-Gokhale-Reineke disclosed, as recited in claim 14: The apparatus of claim 10, wherein, when routing the network traffic associated with the device, the one or more processors are configured to:
identify a path for transmitting the network traffic associated with the device based on the policies for the plurality of jurisdictions (Krig disclosed determining a route and allowing or blocking traffic through a particular device depending on whether or not the device’s location complies with rules and the device’s presence on a blacklist, whitelist, or other list - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.” | [0032]: “In some embodiments, the SPDNS protocol may be used to negotiate with a network to determine a routing for a connection. For example, either the initiating endpoint or the destination endpoint of a connection may authenticate a SPDNS (such as by using public/private key cryptography) and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the initiating endpoint and the destination endpoint or a routing path proposed by the SPDNS server) until the endpoint accepts a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server). In some embodiments, the SPDNS protocol may comprise a common middleground for negotiating a connection between two endpoints. For example, the two endpoints of a connection may mutually authenticate each other (such as by using public/private key cryptography), and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the endpoints or a routing path proposed by the SPDNS server) until both endpoints accept a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server).”; [0033]: “In some embodiments, a standardized icon may be used to communicate that a verified connection path (VCP) has been established for a connection. This may comprise a particular image or may comprise a standardized piece of text, such as “HTTP-VCP://” as a counterpart to the traditional “HTTPS://” indicating a secure connection, where HTTP refers to a “hypertext transfer protocol” and HTTPS refers to a “HTTP secure protocol.” A user client may be operative to display the VCP icon when a connection with verified routing has been established according to the embodiments contained herein, and to not display the VCP icon when no such verified connection has been established…”).
Regarding claim 15, the claim contains the limitations, substantially as claimed, as described in claim 8 above. Krig-Gokhale-Reineke disclosed, as recited in claim 15: The apparatus of claim 10, wherein, when regulating the use of the device, the one or more processors are configured to:
determine that the device has been booted up in a restricted jurisdiction (see Gokhale [0025] “The disclosed systems and methods also enable automated application of geographic-based security features. In one aspect, the system determines a location of a computing device, determines a geographic-based rule for operating the computing device, and selectively erases or wipes the primary copy of data on the computing device if the computing device is operating within a prohibited geographic entity or region…”); and
wipe data associated with the device based on determining that the device has been booted up in the restricted jurisdiction (see Gokhale [0025] “The disclosed systems and methods also enable automated application of geographic-based security features. In one aspect, the system determines a location of a computing device, determines a geographic-based rule for operating the computing device, and selectively erases or wipes the primary copy of data on the computing device if the computing device is operating within a prohibited geographic entity or region. In other aspects, the system may enable a user to view a webpage that displays the logged locations of the computing device, and indicate via the webpage that the computing device was lost or stolen, e.g., if the user does not recognize the last logged location of the computing device. Through the webpage, the user may execute a remote erasure or wipe of the production copy of data on the computing device.” | [0119] “At block 910, the information management server compares the location of the computing device in the table to a set of rules, such as the access control list of Table 4. The set of rules may include a list of geographic entities, e.g., countries, and a corresponding list of prohibited types or classifications of information for the geographic entities. As shown in Table 4, a computing device having only general business information or general business information and confidential information being operated in a geographic entity such as Libya is not prohibited, so the information management server takes no further action. However, the same computing device having general business information and confidential information would be prohibited in a geographic entity such as North Korea, according to the access list of Table 4. If the information management server to determines that the computing device is in a geographic entity where information is prohibited, the process proceeds to block 915 to perform security operations on the computing device.” | [0125] “At block 930, the information management server may delete some or all of the information on the computing device i.e. the local copies, if necessitated by the regulations, the above-noted table or other rules. After creating a secondary copy of the information, the surest prophylactic measure to ensure that the prohibited information is not transferred may be to completely remove the information from the computing device and perform multiple overwrites of data to ensure no recovery of the previously existing data may be performed.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied and how to enforce them. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding consideration of data sovereignty policies and how to enforce them would provide a system to track compliance according to a variety of policies. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Regarding claim 16, the claim contains the limitations, substantially as claimed, as described in claim 9 above. Krig-Gokhale-Reineke disclosed, as recited in claim 16: The apparatus of claim 10, wherein the set of constraints is updated dynamically based on changes to the information associated with the device or the policies for the plurality of jurisdictions (see Gokhale [0067]: “A brief overview of certain aspects of the techniques described in greater detail below is now provided. Regulations for managing information, e.g., data retention, may change from one geographic entity or region to another. Manually updating information management policies manual may be a challenge for IT groups because of the frequency and ease with which employees travel with mobile or portable computing devices. Some of the techniques disclosed herein relate to determining and/or adjusting information management policies based on which geographic entity a computing device operates within. The disclosed techniques advantageously provide information management services more responsively than management by a person and provide information management services requiring support from significantly less personnel-resources.” | [0097] “An IT administrator or other person may populate and maintain the data structure that includes the regulations. The data structure may be sortable by geographic entity, e.g., by a geographic entity field in the data structure, so that when regulations for, as an example, Italy change, a person may easily update various aspects of the information management policy for Italy. In some implementations, the system may be connected to computing systems of regulatory bodies or geographic entities, e.g., countries, throughout the world and may be configured to parse regulatory information and automatically populate and/or update the data structure.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied and how to update them. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding dynamically updating geographic-based policies would provide a system to track compliance according to a variety of policies that are dynamically updated. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Regarding claim 17, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Krig disclosed, as recited in claim 17: One or more non-transitory computer readable storage media encoded with instructions that, when executed by one or more processors, cause the one or more processors (see Krig Fig. 2, [0036]: method | Fig. 1, [0017]: communications system comprising a variety of components to implement connection management | Fig. 5 #504 processing unit, #506 memory, #532 applications, #542 input device interface connected to network, [0051]: components include processor(s), storage medium, program, interfaces for sending messages, etc.) to:
obtain information associated with a device (Krig disclosed determining device characteristics, e.g., location, of a source device or intermediate device through which a connection is routed - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110…In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0020]: “The connection management applications 110 may comprise a traffic analysis component 124. The traffic analysis component 124 may be generally arranged to determine one or more characteristics of the routing of the connection. These characteristics may comprise information about the connection source 140 or any of the one or more entities through which the connection 130 is routed. These characteristics may comprise a name, country, street address, Internet Protocol (IP) address, service provider, domain name, physical location, GPS coordinates, a type of traffic (e.g. text, binary, encrypted, video, images), a quantity of traffic, and a duration of the connection. In various embodiments, the traffic analysis component 124 may be operative to perform a unified analysis of a plurality of connections wherein each of the plurality of connections is associated with a particular client network application or network task, such as a web browser or the loading of a web page. Specifically, the traffic analysis component 124 may be operative to determine a plurality of characteristics corresponding to a plurality of entities associated with the hosting of a web page, such as characteristics corresponding to the plurality of entities hosting the elements of the web page and the plurality of entities responsible for the routing of the connection 130.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.”);
obtain information associated with policies for a plurality of jurisdictions (Krig disclosed obtaining rules, blacklists, whitelists, and preference lists that are used when determining whether or not to block a connection based on determined characteristics, e.g., determining whether or not traffic is permitted to pass through a device’s location - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110. The connection management application 110 may be generally arranged to manage network communications for a client device and/or user. In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”),
the policies including data sovereignty policies (see Gokhale combination below) and
environmental policies for each jurisdiction of the plurality of jurisdictions (see Reineke combination below),
wherein at least one jurisdiction of the plurality of jurisdictions is associated with a route for network for network traffic associated with the device (Krig disclosed determining whether or not network traffic is permitted to pass through an intermediate device’s location - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”);
determine a set of constraints for regulating use of the device based on the information associated with the device and the policies for the plurality of jurisdictions (Examiner interprets “a set of constraints” as being functionally equivalent to the variables/settings within a rule/policy and that “determining a set of constraints…” is inherently performed when applying the rule. Krig disclosed obtaining rules, blacklists, whitelists, and preference lists indicating the locations through which network traffic is permitted or not permitted to pass and determining whether or not a device’s location corresponds to the location specified within the rule in order to determine whether or not the device’s location is a permitted location through which network traffic is permitted to pass – see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0024]: “In various embodiments, the network control component 128 may be operative to present a user of the connection management application 110 with a user interface view containing a query that an incoming connection 130 has been received and that the user may decide to either allow or block the connection 130. In some embodiments, this query may be avoided if the determined characteristics of an incoming connection 130 match one or more whitelist rules which specify that connections matching those rules should be automatically allowed. In this manner, a user may be able to specify that certain characteristics (such as physical locations) result in a connection 130 being blocked, that certain characteristics result in a connection 130 being automatically allowed, and that any other connection 130 results in the user being queried to determine whether the connection 130 should be allowed or blocked. As such, whether or not a user is presented with one or more of the determined characteristics and whether or not a user is queried as to whether a connection 130 should be blocked may itself be determined by the determined characteristics. It will be appreciated that this same technique may be applied to outgoing connections, particularly as computer devices may initiate a large number of connections in response to a user action—such as opening a web page—that would not be immediately apparent to the user.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0029]: “A preference list may comprise a listing of desired countries, regions, servers, networks, server operators, or network operators through which routing is preferred but not required. Members of the preference list may also be automatically allowed for use during routing, but are also specifically desired for routing. These may represent particularly trusted routes. For example, a user in the United States may set a preference for routes which remain in the United States; a user in Western Europe may prefer routes which remain in Europe; a copyright holder may prefer routes which are entirely contained within countries that are signatories to one or more intellectual property treaties.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods…For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”);
regulate the use of the device based on the set of constraints (Krig disclosed determining whether or not a device’s location corresponds to the location specified within the rule in order to determine whether or not the device’s location is a permitted location through which network traffic is permitted to pass - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0024]: “In various embodiments, the network control component 128 may be operative to present a user of the connection management application 110 with a user interface view containing a query that an incoming connection 130 has been received and that the user may decide to either allow or block the connection 130. In some embodiments, this query may be avoided if the determined characteristics of an incoming connection 130 match one or more whitelist rules which specify that connections matching those rules should be automatically allowed. In this manner, a user may be able to specify that certain characteristics (such as physical locations) result in a connection 130 being blocked, that certain characteristics result in a connection 130 being automatically allowed, and that any other connection 130 results in the user being queried to determine whether the connection 130 should be allowed or blocked. As such, whether or not a user is presented with one or more of the determined characteristics and whether or not a user is queried as to whether a connection 130 should be blocked may itself be determined by the determined characteristics. It will be appreciated that this same technique may be applied to outgoing connections, particularly as computer devices may initiate a large number of connections in response to a user action—such as opening a web page—that would not be immediately apparent to the user.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods… For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”);
determine, based on the information associated with the device and the policies for the plurality of jurisdictions, network traffic routing information associated with the device (Krig disclosed presenting a network traffic routing map and also determining whether or not the intermediate nodes of the route comply with the jurisdiction-based routing rules - see Krig [0023]: “…For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.” | [0026]: “In some embodiments, the network control component 128 may be specifically operative to individually determine whether to block or allow each of a plurality of connections 130 that are associated with the performance of a single user request, such as a user request to a web browser to visit a web page. In some embodiments, connections to the server or servers corresponding to a uniform resource locator (URL) of the web page may be automatically allowed as being the direct result of a user action, while any connections 130 to other servers are considered according to the rules of the network control component 128. In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.”; [0030]: “…In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed…”), wherein the network traffic routing information includes information indicating whether any jurisdiction of the plurality of jurisdictions is a restricted jurisdiction through which network traffic associated with the device is not allowed to flow (Krig disclosed referring to a blacklist when determining whether or not the location of an intermediate node of the route complies with the jurisdiction-based routing rules and that the blacklist may be specified within a field of a request to establish a network connection - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0026]: “In some embodiments, the network control component 128 may be specifically operative to individually determine whether to block or allow each of a plurality of connections 130 that are associated with the performance of a single user request, such as a user request to a web browser to visit a web page. In some embodiments, connections to the server or servers corresponding to a uniform resource locator (URL) of the web page may be automatically allowed as being the direct result of a user action, while any connections 130 to other servers are considered according to the rules of the network control component 128. In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.” | [0027]: “In various embodiments, one or more of a blacklist, whitelist, preference list, or other defined list may be used in analyzing and controlling the routing of a connection 130. A blacklist may comprise a listing of countries, regions, servers, networks, server operators, or network operators through which a connection 130 should not be routed and to which a connection 130 should not be routed. It will be appreciated that a blacklist may comprise any one of countries, regions, servers, networks, server operators, or network operators or may comprise a mix of blacklist entry types, and that one or more entries of each type may exist. In some embodiments, a blacklist may comprise a listing of regions through which a connection 130 should not be routed and to which a connection 130 should not be routed, where a region can comprise a defined physical area which may include countries, states, cities, or any other mechanism of defining a physical area. In some embodiments, a region may comprise a bounded geographical area comprising a cohesive political unit which may be one or more of a country, state, county, city, municipality, or any other form of political unit covering a defined geographical area.”; [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.”); and
route the network traffic associated with the device based on the network traffic routing information (Krig disclosed allowing or blocking traffic through a particular device depending on whether or not the device’s location complies with rules and the device’s presence on a blacklist, whitelist, or other list - see Krig [0023]: “The connection management application 100 may comprise a network control component 128. The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block. The user of the connection management application 110 may be operative to specify one or more rules which indicate that a connection 130 should be blocked if the one or more determined characteristics conform to the settings of the rule. For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.” | [0030]: “In some embodiments, the whitelist, blacklist, and preference list may be used with traditional network protocol methods, such as by having their control implemented using the tracrouting and domain name server (DNS) lookups as described above. In some embodiments, the whitelist, blacklist, and preference list may be implemented using an extended protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list when attempting to initiate a connection 130 or send a packet, datagram, packet data unit (PDU), frame, subframe, or other unit of network transmission. For example, a request to open a network socket to a remote server may include within it a field specifying one or more of a whitelist, blacklist, and preference list for the routing of the connection 130, such that each intermediate step in the routing of the connection 130 is expected to adhere to the whitelist, blacklist, and/or preference list. In various embodiments, the user client may be operative to verify the obedience of the intermediate routing entities to the lists, such as through a query, or an encrypted query, to the intermediate routing entities to confirm their identity, existence on the whitelist, or lack of existence on the blacklist. In some embodiments, intermediate routing entities may be operative to query the user client to determine whether an entity (such as a country, region, server, network, server operator, or network operator) which is not on any of the whitelist, blacklist, or preference list is allowed. In some embodiments, the extended protocol may comprise an extension of the Internal Protocol (IP) protocol allowing for the specification of one or more of a blacklist, whitelist, and preference list in a IP datagram header. In other embodiments, the extended protocol may comprise an extension of a protocol at a different level of the network stack, such as one above or below the IP protocol. In some embodiments, the extended protocol may be used to re-check a connection path at intervals, such as at set intervals, or on demand, such as at a user request. It will be appreciated that any of the enclosed embodiments may be used at the instantiation of a connection, at the reception of an incoming connection, at the creation of an outgoing connection, or an existing connection.” | [0032]: “In some embodiments, the SPDNS protocol may be used to negotiate with a network to determine a routing for a connection. For example, either the initiating endpoint or the destination endpoint of a connection may authenticate a SPDNS (such as by using public/private key cryptography) and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the initiating endpoint and the destination endpoint or a routing path proposed by the SPDNS server) until the endpoint accepts a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server). In some embodiments, the SPDNS protocol may comprise a common middleground for negotiating a connection between two endpoints. For example, the two endpoints of a connection may mutually authenticate each other (such as by using public/private key cryptography), and accept or refuse proposed or attempted routing paths (such as actual attempts to route datagrams between the endpoints or a routing path proposed by the SPDNS server) until both endpoints accept a proposed or attempted routing path (such as by verifying its acceptability according to one or more of a whitelist, blacklist, or preference list using the SPDNS server).”; [0033]: “In some embodiments, a standardized icon may be used to communicate that a verified connection path (VCP) has been established for a connection. This may comprise a particular image or may comprise a standardized piece of text, such as “HTTP-VCP://” as a counterpart to the traditional “HTTPS://” indicating a secure connection, where HTTP refers to a “hypertext transfer protocol” and HTTPS refers to a “HTTP secure protocol.” A user client may be operative to display the VCP icon when a connection with verified routing has been established according to the embodiments contained herein, and to not display the VCP icon when no such verified connection has been established…”).
With respect to the limitation “the policies including data sovereignty policies and environmental policies for each jurisdiction of the plurality of jurisdictions”:
Krig disclosed applying jurisdiction-based policies when determining the route for network traffic (see Krig [0023]: “…The network control component 128 may be arranged to determine whether to block the connection 130 based on the one or more determined characteristics. Any of the determined characteristics may be used as the basis of a decision to block or not to block...For example, one or more rules may specify that a connection 130 is to be blocked if any of the physical locations that may comprise the one or more determined characteristics corresponds to a set of blacklisted physical locations. In various embodiments, physical locations may comprise a list of countries. As such, in some embodiments, the connection may be blocked if the determined characteristics indicate that the connection 130 was routed through a country included in a set of blacklisted countries.”) and that the type of data is one example of a characteristic used when applying rules to determine whether or not a connection is permitted (see Krig [0023]: “…Any of the determined characteristics may be used as the basis of a decision to block or not to block...” | [0021]: “The one or more characteristic can be determined in a variety of ways according to a variety of techniques. In some embodiments, these techniques may comprise one or more of…examining the data payloads of the connection 130 to determine the type of data carried by the connection 130…” | [0026]: “…In some embodiments, these rules may be conditional on the type of data being transmitted over the connections 130 or the purpose of the connections 130. For example, a connection 130 to a server hosting textual, image, video, or other media or multimedia content may be allowed unless the connection 130 has determined characteristics corresponding to a specific rule to block (such as a connection to or through a blacklisted country) while a connection 130 to a server acting as a tracking server—which attempts to track the behavior of individual computer users across multiple web pages or web sites—may be blocked, or the user may be asked whether to block, unless the tracking server or tracking servers appear on a whitelist of allowed tracking servers.”).
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that Krig’s analysis of data type when applying jurisdiction-based policies would include applying data sovereignty policies, however Krig did not explicitly disclose that the jurisdiction-based policies include “data sovereignty policies”.
However in a related art, Gokhale disclosed applying an information management policy to production data of the computing device based on regulations of the geographic entity (see Gokhale Fig. 6 #615). The information management policies are stored in a database (see Gokhale [0045]) that is connected to computing systems of regulatory bodies of countries throughout the world (see Gokhale [0097]). The location of a device is compared to a set of rules, such as the access control list of Table 4 indicating a list of prohibited information in different countries (see Gokhale [0117]), and a security operation is performed depending on if the type of data is permitted in the device’s location (see Gokhale Fig. 9, [0119]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding consideration of data sovereignty polices would provide a system to track routing compliance according to a variety of policies. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Although Krig disclosed “…Any of the determined characteristics may be used as the basis of a decision to block or not to block...” (see Krig [0023]), Krig-Gokhale did not explicitly disclose that the jurisdiction-based policies include “environmental policies”.
While it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the particular types of policies used when analyzing and determining permitted communication routes are matters of implementation choice, however in a related art, Reineke disclosed a variety of sustainability factors, e.g. energy and power consumption (see Reineke [0009]+Table), and minimum standards/thresholds for resources that are set by governments, etc. (see Reineke [0024]). Fig. 3 illustrates a process for identifying resources that comply with the sustainability values and governance control, as well as topology control (e.g., [0037]: data may be located in a zone with a max power level and it is determined that performing computation will exceed the threshold). The diagnostic system evaluates resource usage and capabilities (see [0038]) and a tradeoff analysis is performed to determine appropriate resources (see [0039]). This determination filters resources according to elements that are most aligned with sustainability considerations (see [0041]) and the top choice is automatically selected and deployed (see [0043]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale and Reineke to further clarify additional types of policies and limits on network resources. Expanding upon Krig’s desire to adhere to geographic-based policies (see Krig [0010]) and Gokhale’s selection of less-resource intensive computing operations (see Gokhale 0074) to include Reineke’s analysis of computing resources would ensure that computing resources are selected based on considerations for sustainability requirements and relevant government mandates for the applicable locale(s) (see Reineke [0002]), thereby ensuring that sustainability requirements are met (see Reineke [0008]).
Regarding claim 18, the claim contains the limitations, substantially as claimed, as described in claim 2 above. Krig-Gokhale-Reineke disclosed, as recited in claim 18: The one or more non-transitory computer readable storage media of claim 17, wherein the information associated with the device includes a location of the device (Krig disclosed determining device characteristics, e.g., location, of a source device or intermediate device through which a connection is routed - see Krig [0118]: “The communication systems 100 may comprise the connection management application 110…In particular, the connection management application 110 may be arranged to analyze incoming and outgoing network connections, to determine characteristics of the connections, to communicate these characteristics to a user in a manner designed to empower the user to make informed decisions about their network connections, and to provide users with the ability to control incoming and outgoing network connections using real-time controls, pre-established rules, or a combination of the two…” | [0020]: “The connection management applications 110 may comprise a traffic analysis component 124. The traffic analysis component 124 may be generally arranged to determine one or more characteristics of the routing of the connection. These characteristics may comprise information about the connection source 140 or any of the one or more entities through which the connection 130 is routed. These characteristics may comprise a name, country, street address, Internet Protocol (IP) address, service provider, domain name, physical location, GPS coordinates, a type of traffic (e.g. text, binary, encrypted, video, images), a quantity of traffic, and a duration of the connection. In various embodiments, the traffic analysis component 124 may be operative to perform a unified analysis of a plurality of connections wherein each of the plurality of connections is associated with a particular client network application or network task, such as a web browser or the loading of a web page. Specifically, the traffic analysis component 124 may be operative to determine a plurality of characteristics corresponding to a plurality of entities associated with the hosting of a web page, such as characteristics corresponding to the plurality of entities hosting the elements of the web page and the plurality of entities responsible for the routing of the connection 130.” | [0025]: “In various embodiments, querying the user may comprise presenting the user—such as through a textual or graphical display—one or more of the determined one or more characteristics. For example, a user may be presented with an entity name, device name and physical location associated with the connection source 140. Alternatively or additionally, a user may be presented with a graphical rendering of a multi-hop map of the physical locations through which a connection 130 is routed. In some embodiments, the user may be able to specify which characteristics of the one or more characteristics they wish to be presented with when queried as to whether a connection 130 should be blocked.”).
Regarding claim 20, the claim contains the limitations, substantially as claimed, as described in claim 9 above. Krig-Gokhale-Reineke disclosed, as recited in claim 20: The one or more non-transitory computer readable storage media of claim 17, wherein the set of constraints is updated dynamically based on changes to the information associated with the device or the policies for the plurality of jurisdictions (see Gokhale [0067]: “A brief overview of certain aspects of the techniques described in greater detail below is now provided. Regulations for managing information, e.g., data retention, may change from one geographic entity or region to another. Manually updating information management policies manual may be a challenge for IT groups because of the frequency and ease with which employees travel with mobile or portable computing devices. Some of the techniques disclosed herein relate to determining and/or adjusting information management policies based on which geographic entity a computing device operates within. The disclosed techniques advantageously provide information management services more responsively than management by a person and provide information management services requiring support from significantly less personnel-resources.” | [0097] “An IT administrator or other person may populate and maintain the data structure that includes the regulations. The data structure may be sortable by geographic entity, e.g., by a geographic entity field in the data structure, so that when regulations for, as an example, Italy change, a person may easily update various aspects of the information management policy for Italy. In some implementations, the system may be connected to computing systems of regulatory bodies of geographic entities, e.g., countries, throughout the world and may be configured to parse regulatory information and automatically populate and/or update the data structure.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig and Gokhale to further describe the types of policies that may be applied and how to update them. Modifying Krig’s determination about compliance with geographic routing policies to include Gokhale’s teachings regarding dynamically updating geographic-based policies would provide a system to track compliance according to a variety of policies that are dynamically updated. Incorporating Gokhale’s teachings would reduce overhead costs (see Gokhale [0007]), ensure compliance with appropriate policies and regulations in a geographically-diverse environment (see Gokhale [0023]), reduce personnel costs by automating updates to policies (see Gokhale [0114]), and increase customizability of policies by including policies related to data class (see Gokhale [0096]).
Claims 3-4, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Krig-Gokhale-Reineke as applied to claims 1, 10, and 17 above, and further in view of Løken (WO 2023/214887 A1).
Regarding claim 3, Krig-Gokhale-Reineke disclosed the invention, substantially as claimed, as described in the computer-implemented method of claim 1 above, but did not explicitly disclose “associating a digital visa with the device, wherein the digital visa comprises data that describes the set of constraints, and wherein a link to the digital visa is on the device”.
However in a related art of geographic-based regulatory compliance, Løken disclosed a track-and-trace system to ensure compliance with a country’s legislation (see Løken p.4 line 24 – page 5 line 3: “For instance a track and trace system that is enabled to track and trace every single product uniquely with a unique id, can be used to comply with the upcoming European Digital Products Passports. Access and use of this kind of track & trace data may be made available to the end consumer in relation to the requirements of the legislation in question [i.e. “data that describes the set of constraints”]…As an example, a user may have properly returned a depleted battery which carries a unique code [i.e. “associating a digital visa with the device…wherein a link to the digital visa is on the device”], to an approved return point without revealing the user's identity to the return point operator. Then the proper return can be documented without revealing the identity of the user itself. Further, the brand owner may document before environmental authorities that the product carrying a unique code has been properly returned as per legislation, for recycling or finally depositing the product…”). Examiner notes that the details about the content of the set of constraints used to maintain adherence to policies is taught by Krig above.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale-Reineke and Løken to further describe the types of policies that may be applied and how to track compliance with the policies. Modifying Krig-Gokhale-Reineke’s determination about compliance with geographic policies to include Løken’s teachings regarding a track-and-trace digital passport would provide a system to track compliance with a variety of policies. Incorporating Løken’s teachings would ensure that there is positive proof of regulatory compliance while also improving security of identity-based data (see Løken page 5 lines 3-13).
Regarding claim 4, Krig-Gokhale-Reineke-Løken disclosed the computer-implemented method of claim 3, wherein the digital visa uses information provided by a Digital Product Passport to enforce the policies (see Løken p.4 line 24 – page 5 line 3: “For instance a track and trace system that is enabled to track and trace every single product uniquely with a unique id, can be used to comply with the upcoming European Digital Products Passports. Access and use of this kind of track & trace data may be made available to the end consumer in relation to the requirements of the legislation in question. The acts of the consumer engaging with the products will also create and contribute data to such systems. As an example, a user may have properly returned a depleted battery which carries a unique code, to an approved return point without revealing the user's identity to the return point operator. Then the proper return can be documented without revealing the identity of the user itself. Further, the brand owner may document before environmental authorities that the product carrying a unique code has been properly returned as per legislation, for recycling or finally depositing the product…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale-Reineke and Løken to further describe the types of policies that may be applied and how to track compliance with the policies. Modifying Krig-Gokhale-Reineke’s determination about compliance with geographic policies to include Løken’s teachings regarding a track-and-trace digital passport would provide a system to track compliance with a variety of policies. Incorporating Løken’s teachings would ensure that there is positive proof of regulatory compliance while also improving security of identity-based data (see Løken page 5 lines 3-13).
Regarding claim 12, the claim contains the limitations, substantially as claimed, as described in claim 3 above. Krig-Gokhale-Reineke disclosed, as recited in claim 12:
Regarding claim 12, Krig-Gokhale-Reineke disclosed the invention, substantially as claimed, as described in the apparatus of claim 10 above, but did not explicitly disclose “wherein the one or more processors are further configured to associate a digital visa with the device, wherein the digital visa comprises data that describes the set of constraints, and wherein a link to the digital visa is on the device”.
However in a related art of geographic-based regulatory compliance, Løken disclosed a track-and-trace system to ensure compliance with a country’s legislation (see Løken p.4 line 24 – page 5 line 3: “For instance a track and trace system that is enabled to track and trace every single product uniquely with a unique id, can be used to comply with the upcoming European Digital Products Passports. Access and use of this kind of track & trace data may be made available to the end consumer in relation to the requirements of the legislation in question [i.e. “data that describes the set of constraints”]…As an example, a user may have properly returned a depleted battery which carries a unique code [i.e. “associating a digital visa with the device…wherein a link to the digital visa is on the device”], to an approved return point without revealing the user's identity to the return point operator. Then the proper return can be documented without revealing the identity of the user itself. Further, the brand owner may document before environmental authorities that the product carrying a unique code has been properly returned as per legislation, for recycling or finally depositing the product…”). Examiner notes that the details about the content of the set of constraints used to maintain adherence to policies is taught by Krig above.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale-Reineke and Løken to further describe the types of policies that may be applied and how to track compliance with the policies. Modifying Krig-Gokhale-Reineke’s determination about compliance with geographic policies to include Løken’s teachings regarding a track-and-trace digital passport would provide a system to track compliance with a variety of policies. Incorporating Løken’s teachings would ensure that there is positive proof of regulatory compliance while also improving security of identity-based data (see Løken page 5 lines 3-13).
Regarding claim 19, the claim contains the limitations, substantially as claimed, as described in claim 3 above. Krig-Gokhale-Reineke disclosed, as recited in claim 19:
Regarding claim 19, Krig-Gokhale-Reineke disclosed the invention, substantially as claimed, as described in the one or more non-transitory computer readable storage media of claim 17 above, but did not explicitly disclose “wherein the one or more processors are further configured to associate a digital visa with the device, wherein the digital visa comprises data that describes the set of constraints, and wherein a link to the digital visa is on the device”.
However in a related art of geographic-based regulatory compliance, Løken disclosed a track-and-trace system to ensure compliance with a country’s legislation (see Løken p.4 line 24 – page 5 line 3: “For instance a track and trace system that is enabled to track and trace every single product uniquely with a unique id, can be used to comply with the upcoming European Digital Products Passports. Access and use of this kind of track & trace data may be made available to the end consumer in relation to the requirements of the legislation in question [i.e. “data that describes the set of constraints”]…As an example, a user may have properly returned a depleted battery which carries a unique code [i.e. “associating a digital visa with the device…wherein a link to the digital visa is on the device”], to an approved return point without revealing the user's identity to the return point operator. Then the proper return can be documented without revealing the identity of the user itself. Further, the brand owner may document before environmental authorities that the product carrying a unique code has been properly returned as per legislation, for recycling or finally depositing the product…”). Examiner notes that the details about the content of the set of constraints used to maintain adherence to policies is taught by Krig above.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krig-Gokhale-Reineke and Løken to further describe the types of policies that may be applied and how to track compliance with the policies. Modifying Krig-Gokhale-Reineke’s determination about compliance with geographic policies to include Løken’s teachings regarding a track-and-trace digital passport would provide a system to track compliance with a variety of policies. Incorporating Løken’s teachings would ensure that there is positive proof of regulatory compliance while also improving security of identity-based data (see Løken page 5 lines 3-13).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Angela Widhalm de Rodriguez whose telephone number is (571)272-1035. The examiner can normally be reached M-F: 6am-2:30pm EST.
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, Nicholas Taylor can be reached at (571)272-3889. 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.
/ANGELA WIDHALM DE RODRIGUEZ/Examiner, Art Unit 2443