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 .
Information Disclosure Statement
The 10/13/2025 and 2/2/2026 IDS documents have been considered by the examiner.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 112(b):
Applicant’s amendment has overcome the applied rejection. As such, the rejection has been withdrawn.
Regarding claims rejected under 35 USC 103:
With respect to claims 1-2, 4-8, and 21:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Bathula (US 2019/0327016 A1).
With respect to claims 9-15:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Venna (US 2017/0236079 A1).
With respect to claims 16-20:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Sinha (US 2024/0283809 A1).
Regarding claims rejected under 35 USC 101:
With respect to claims 1-2, 4-8, and 21:
Applicant’s amendment has overcome the applied rejection. As such, the rejection has been withdrawn.
With respect to claims 9-20:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that “Independent claim 9 provides a technical solution to distribute data traffic across multiple access points to improve load distribution and prevent overload at an access point, as well as to provide redundancy for directing traffic to available access points, which may result in improved network latency and overall responsiveness of services for the certificate management system (see e.g., id., [0033]). Independent claim 16 provides a technical solution to efficiently manage certificate generation for root domains by introducing a new record type to ensure the root domain remains directly linked to the network address.” In response to Applicant’s argument concerning claim 9, it is noted that the identified improvements (i.e., “a technical solution to distribute data traffic across multiple access points to improve load distribution and prevent overload at an access point, as well as to provide redundancy for directing traffic to available access points, which may result in improved network latency and overall responsiveness of services for the certificate management system”) are not actually expressed in the claim. The claim is merely drawn to generating a certificate based on graph relationships and using the certificate.
In response to Applicant’s argument concerning claim 16, it is noted that the identified improvements concern a problem that transcends computing: graphing relationships and applying the graph in determining access control (“introducing a new record type” as part of generating a certificate). The claim does not express an improvement to the actual technical generation procedure of the certificate. Instead, it relates to changing out the data looked at (relationships in a graph) before generation takes place.
Where Applicant argues that “the Application notes a need for improving security for certificate generation that accounts for various domains and access points (see e.g., Application, [0022] and [0023]). Such a solution is necessarily rooted in computer technology in order to manage network connectivity and data access across distributed access points,” it is noted that the claim limitations do not concern managing network connectivity in any detail beyond merely making use of the certificate. The expressed improvements in the claims relate to modifying the type of information which is looked at before generating the certificate. This likewise applies where Applicant argues that claims 9 and 16 “improve the functioning of a computing system, including enabling geographic-based relationship modeling for network addresses… improve the functioning of a computing system, including enabling certificate generation based on multiple relationship types;” these improvements only relate to which data is chosen to be looked at rather than the actual certificate generation, or how the certificate is used in a network.
With respect to step 2B and claims 9 and 16, Applicant argues that “independent claim 9 recites specific details about generating a graph defining a relationship between a network address, an access point of a plurality of access points, and one or more records associated with at least one domain, where the relationship is based on the network address being assigned to the plurality of access points across a plurality of geographic locations. Amended independent claim 16 recites specific details about generating a graph that defines a first relationship between a network address and a record associated with a domain and a second relationship between the network address and an alias record associated with a root domain, and generating a certificate for accessing data via the domain or the root domain based on at least one of the first relationship or the second relationship.” In response, it is noted that these are the identified abstract idea elements in claims 9 and 16.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 9-10 and 12-15 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 4-5, and 14 of copending Application No. 18/230,920 in view of Torkamani (US 11,743,282 B1) and Venna (US 2017/0236079 A1). The copending claims are considered to anticipate instant claim 9 as below, but do not disclose: the relationship further comprising “an access point of a plurality of access points, and one or more records associated with at least one domain, wherein the relationship is based on the network address being assigned to the plurality of access points across a plurality of geographic locations.” However, the copending claims in view of at least Col. 4, Ll. 45-60 of Torkamani and FIG. 7 and [0175] of Venna concerning DNS data for a graph are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the copending claims to further specify additional graph relationship data for at least the purpose of implementing more granular policy for the certificates.
Instant Application
18/230,920
9. A method comprising: generating, by a computing device, a graph defining a relationship between a network address, an access point of a plurality of access points, and one or more records associated with at least one domain, wherein the relationship is based on the network address being assigned to the plurality of access points across a plurality of geographic locations;
generating, by the computing device, a certificate for the network address based on the graph; and
controlling, by the computing device, data transfer between the at least one domain and a device based on the certificate.
1. (Currently Amended) A method comprising: generating, by a computing device, a graph that defines relationships between a network address and a plurality of different domains, the graph comprising a plurality of nodes that each represent a corresponding one of the plurality of different domains or the network address;
generating, by the computing device, a first certificate for the network address based on the graph, the first certificate listing individual each of the plurality of nodes in the graph that identify corresponding ones of the plurality of different domains as separate certificate entries; controlling access to the network address using the first certificate; detecting, by the computing device, a change to at least one of the relationships between the network address and one or more of the plurality of different domains;
generating, by the computing device, a modified graph based on the change to the at least one of the relationships; generating, by the computing device, a second certificate for the network address based on the modified graph, the second certificate listing individual nodes in the modified graph as separate certificate entries; and
controlling access to the network address using the second certificate instead of the first certificate.
10. The method of claim 9, wherein the at least one domain is served by multiple providers that comprise a first provider hosted by an entity and a second provider hosted by a content delivery network that is different than the entity, wherein the first provider is represented in the graph by a first node and the second provider is represented in the graph by a second node.
4. The method of claim 1, wherein the network address is served by multiple providers that comprise a first provider hosted by an entity and a second provider hosted by a content delivery network that is different than the entity, wherein the first provider is represented in the graph by a first node and the second provider is represented in the graph by a second node.
14. The method of claim 9, wherein the graph further comprises a plurality of nodes that represent the network address, the access point, and the at least one domain, wherein respective nodes of the plurality of nodes are connected by links representative of the relationship between the network address, the access point, and the at least one domain.
5. The method of claim 4, wherein each of the plurality of nodes that represent the plurality of different domains is connected by a link to the first node or the second node in the graph.
15. The method of claim 9, wherein the network address is a virtual internet protocol address configured for access by at least one of a physical network interface or the device.
14. The system of claim 9, wherein the network address is a virtual internet protocol address configured for access by at least one of a physical network interface or a device.
Regarding instant claim 12, the copending claims do not specify: “wherein the one or more records include an indication of one or more of the at least one domain or one or more subdomains associated with the at least one domain.” However, the copending claims in view of at least Col. 4, Ll. 36-61 and Col. 12, Ll. 7-21 of Torkamani with respect to an indication of the domain or associated subdomain are considered to disclose this limitation. This claim would have been obvious for substantially the same reasons as claim 9 above.
Regarding instant claim 13, it is rejected for substantially the same reasons as claim 9 above (i.e., the citations to Torkamani and the obviousness rationale).
Claims 16-19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over at least claim 1 of copending Application No. 18/230,920 in view of Farber (US 11,204,961 B1) and Sinha (US 2024/0283809 A1). The copending claims are considered to anticipate instant claim 1 as below, but do not disclose: graph relationship further comprising “a record associated with a domain and a second relationship between the network address and an alias record associated with a root domain.” However, the copending claims in view of at least FIG. 7 and Col. 31, Ll. 1-40 of Farber and the abstract and [0049]-[0051] of Sinha concerning DNS data for a graph are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the copending claims to further specify DNS data such as addresses, records, aliases, and type for at least the purpose of implementing more granular policy for the certificates.
Instant Application
18/230,920
16. A method comprising:
generating, by a computing device, a graph that defines a first relationship between a network address and a record associated with a domain and a second relationship between the network address and an alias record associated with a root domain;
generating, by the computing device, a certificate for accessing data via the domain or the root domain based on at least one of the first relationship or the second relationship; and
Controlling, by the computing device, data transfer between the domain and a device based on the certificate.
1. A method comprising:
generating, by a computing device, a graph that defines relationships between a network address and a plurality of different domains;
generating, by the computing device, a first certificate for the network address based on the graph; controlling access to the network address using the first certificate; detecting, by the computing device, a change to at least one of the relationships between the network address and one or more of the plurality of different domains; generating, by the computing device, a modified graph based on the change to the at least one of the relationships; generating, by the computing device, a second certificate for the network address based on the modified graph; and
controlling access to the network address using the second certificate instead of the first certificate.
Regarding instant claim 17, it is rejected for substantially the same reasons as claim 16 above (e.g., the citations and obviousness rationale; FIG. 7 or Farber).
Regarding instant claim 19, the copending claims do not specify: “wherein the certificate is generated based on the second relationship based on the network address and the record being separated by one or more nodes in the graph.” However, the copending claims in view of at least FIG. 7-8 and Col. 32, Ll. 37-62 of Farber’s dependency graph are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the copending claims to further specify generating the certificate based on graph distance (e.g., representing regional distance) for substantially the same reasons as claim 16 above (i.e., more granular access control).
Regarding instant claim 18, it is rejected for substantially the same reasons as claim 19 above.
This is a provisional nonstatutory double patenting rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 9-12 and 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Note that the courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation (refer to MPEP 2106.04(a)(2)).
Independent claim 9 recites the following abstract idea limitations: A method comprising:
generating, by a computing device, a graph defining a relationship between a network address, an access point of a plurality of access points, and one or more records associated with at least one domain, wherein the relationship is based on the network address being assigned to the plurality of access points across a plurality of geographic locations (observation and evaluation as part of a mental process—e.g., an analyst obtaining a description of a network arrangement and graphing it, where network entities are vertices and edges represent relations; this may be done using pen and paper);
generating a certificate for the network address based on the graph (evaluation and judgement as part of a mental process—e.g., the analyst creating a certificate in any relation from the graph); and
controlling data transfer between the at least one domain (certain methods of organizing human activity—e.g., requiring a certificate for access to data or for completing an algorithm to access data) and [an entity] based on the certificate.
Independent claim 9 recites the following limitations which may comprise additional elements that are sufficient to amount to significantly more than the judicial exception: performing the generating, generating, and controlling steps “by a computing device;” the entity further comprising “a device.”
With respect to step 2A, the judicial exception is not integrated into a practical application because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, the method is drawn to controlling data transfer between a domain and “a device” based on the certificate. However, the device is extra-solution to the claim since it is not performing any of the claim steps and the data transfer need not take place within the claim scope (i.e., “controlling data transfer” can refer to scheduling a data transfer to take place, or to allowing an administrator to perform a data transfer). Further, the “computing device” is merely a generic computer substitution as a form of adding the words “apply it.” Otherwise, claim 9 is drawn to generating a graph, generating a certificate based on the graph, and access control using the certificate. As such, the invention is addressing a problem that transcends computing (graphing relationships and applying the graph in determining access control) rather than improving the functioning of a computer, or an improvement to other technology or a technical field.
With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, “a computing device” and “a device” used as part of a data transfer with at least one domain. However, “a computing device” and “a device” are generic and could be any base computer (processor and memory). Additionally, merely using a computer to “transfer data” is considered to be a base implementation of any generic computer.
Regarding dependent claims 10, 12, and 14-15, they merely further specify the graph, and are therefore likewise rejected under the same analysis as claim 9. Although claim 10 further specifies “multiple providers that comprise a first provider hosted by an entity and a second provider hosted by a content delivery network,” they are merely specified as far as “at least one domain is served by multiple providers;” “served” is not otherwise specified in a technical manner. Claim 15 merely specifies the graph data of the “network address” rather than describing a technical implementation using the network address.
Dependent claim 11 specifies the following abstract idea limitations: further comprising permitting data transfer between the at least one domain and the device based on verifying, by the second provider, a validity of the certificate (observation, evaluation, and judgement as part of a mental process—e.g., a provider analyst determining whether to allow a data transfer based on checking a certificate). Since claim 11 merely further specifies the abstract idea, it is likewise rejected under the same analysis as claim 9 above.
Independent claim 16 is substantially similar to elements of independent claim 9 above, and is therefore rejected under the same analysis.
Dependent claims 17 and 20 merely further specify the graph and are rejected for substantially the same reasons as well.
Dependent claim 18 recites the following abstract idea limitations: wherein the certificate is generated based on the first relationship based on the network address and the record being adjacent nodes in the graph (observation, evaluation, and judgement as part of a mental process—e.g., the analyst reviewing the graph as part of a decision on whether to generate the certificate). Since claim 18 merely further specifies the abstract idea, it is likewise rejected under the same analysis as claim 16 above.
Dependent claim 19 is rejected for substantially the same reasons as claim 18 above.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 4-7, and 21 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Independent claim 1 recites “wherein the certificate comprises the relationships between the domain and the fallback access point,” which renders it indefinite because it is not clear whether “the relationship” has antecedent; nor is it clear whether “the fallback access point” is different from the “one or more fallback access points” since it excludes the plural case. While claim 1 does recite “a graph defining relationships between a domain and a plurality of different access points… the plurality of different access points comprising a serving access point and one or more fallback access points,” this may be a different relationship from the one “between the domain and the fallback access point.” For instance, if the first relationship includes access points other the fallback access point; or if it relates to plural fallback access points. As such, the scope of the claim is unclear and one of ordinary skill in the art would not understand how to interpret the claim for the purpose of avoiding infringement.
The dependent claims do not rectify this issue and are therefore likewise rejected.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-2 and 4-7, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nagaratnam (US 2003/0233543 A1) in view of Amin (US 2020/0007666 A1) and Bathula (US 2019/0327016 A1).
Regarding claim 1, Nagaratnam discloses: A method comprising: generating, by a computing device, a graph (e.g., trust graph in Nagaratnam) defining relationships between a domain (e.g., zones and trust zones in Nagaratnam) and a plurality of different access points (e.g., FIG. 5 of Nagaratnam), wherein:
the plurality of different access points comprising a serving access point, the plurality of different access points is represented in the graph by a plurality of nodes; and
Refer to at least [0033] and [0043] of Nagaratnam with respect to the trust graph having nodes representing relationships between clients, servers, and end entities.
generating by the computing device, a certificate for accessing the data via the domain wherein the certificate comprises the relationships between the domain and the [and the access points]; and
Refer to at least [0035], [0039], [0048], and [0054]-[0055] of Nagaratnam with respect to either providing certificates for new nodes connecting to the network, or in the case where the trust relationships change. As per at least the abstract and [0057], the certificates are provided based on the trust graph.
controlling, by the computing device, access to the data using the certificate.
Refer to at least [0004]-[0005] of Nagaratnam with respect to using the certificates for SSL communication.
Nagaratnam does not specify: the plurality of different access points further comprising one or more fallback access points; the plurality of nodes are ordered in the graph based on a proximity of a first geographic location of the serving access point to respective second geographic locations of the one or more fallback access points; detecting, by the computing device, a change in connectivity of the serving access point, wherein the serving access point is unavailable to serve a request for data based on the change in connectivity; selecting, by the computing device and based on traversing the graph, a fallback access point of the one or more fallback access points to serve the request for the data. However, Nagaratnam in view of Amin discloses: the plurality of different access points further comprising one or more fallback access points; the trust graph further comprising the one or more fallback access points.
Refer to at least FIG. 4A-B, [0031], and [0039]-[0041] of Amin with respect to generating a graph of nodes, including redundant nodes used for failover.
detecting, by the computing device, a change in connectivity of the serving access point, wherein the serving access point is unavailable to serve a request for data based on the change in connectivity;
Refer to at least [0029]-[0030] of Amin stating that “failed node identifier 133 can… identify a service on a node 140A-D that may have experienced a failure or outage… the failed node identifier 133 can transmit an instruction to the node failover manager 134 to initiate failover operations for the service.”
selecting, by the computing device and based on traversing the graph, a fallback access point of the one or more fallback access points to serve the request for the data.
Refer to at least [0031] of Amin stating that “node failover manager 134 can identify a redundant node 140A-D using the service request graph. In some embodiments, the node failover manager 134 selects the redundant node 140A-D with the best KPI value”
The teachings of Nagaratnam and Amin both concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Nagaratnam to further include graphing redundant nodes for failover for at least the purpose of accounting for service outages as in [0001]-[0002] of Amin (i.e., if a server in Nagaratnam fails, then the trust graph can account for it using a different server to maintain service and uptime).
Although Nagaratnam-Amin considers node location data (e.g., [0025] of Amin), Nagaratnam-Amin does not specify: the plurality of nodes are ordered in the graph based on a proximity of a first geographic location of the serving access point to respective second geographic locations of the one or more fallback access points. However, Nagaratnam-Amin in view of Bathula discloses: the plurality of nodes are ordered in the graph based on a proximity of a first geographic location of the serving access point to respective second geographic locations of the one or more fallback access points.
Refer to at least FIG. 2B, FIG. 8, [0019], FIG. 6, and [0084] of Bathula with respect to ordering a network graph including support for router failure and restoration according to physical distance.
The teachings of Bathula likewise concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Nagaratnam-Amin to further implement node distances as part of the failover graph because it allows for evaluating Amin’s KPIs by merely traversing the graph. Additionally, the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (ordering graph nodes according to proximity).
Regarding claim 2, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations and obviousness rationale—e.g., FIG. 8 of Bathula).
Regarding claim 4, Nagaratnam-Amin-Bathula discloses: The method of claim 1, wherein the detection of the change in connectivity is based on one or more of a traffic speed (see at least [0011] and [0029] of Amin with respect to node KPIs for identifying a failure of outage, where the KPIs include a data transfer rate and uplink/downlink speeds) associated with the serving access point or a network connection status of the serving access point.
Refer to at least [0035] and [0048] of Nagaratnam with respect to a node being started and added to the network.
Regarding claim 5, Nagaratnam-Amin-Bathula discloses: The method of claim 1, further comprising traversing the graph to detect a first node of the plurality of nodes corresponding to the fallback access point, wherein the fallback access point is adjacent to a second node of the plurality of nodes corresponding to the serving access point;
Refer to at least FIG. 4B, [0041], and [0048] of Amin with respect to traversing the service graph to detect failover nodes (e.g., node 140B-2 adjacent to node 140C-1).
Regarding claim 6, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations concerning the graphs—e.g., FIG. 4A-B in Amin).
Regarding claim 7, Nagaratnam-Amin-Bathula discloses: The method of claim 1, wherein the fallback access point is selected from the one or more fallback access points based on one or more of a numerical quantity of data transmissions at the fallback access point, the geographic location, or the respective second geographic locations.
Refer to at least [0031] of Amin with respect to selecting the redundant node with the best KPIs (e.g., transfer rate).
This claim would have been obvious for substantially the same reasons as claims 1 and 2 above.
Regarding claim 21, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations and obviousness rationale—e.g., the cited portions of Amin concerning determining a node failure and choosing a different node in the request graph, which may be performed more than once).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nagaratnam- Amin-Balthua as applied to claims 1-2, 4-7, and 21 above, and further in view of Jain (US 2012/0047394 A1).
Regarding claim 8, Nagaratnam-Amin-Balthua does not specify: wherein at least one fallback access point is associated with a datacenter; and the plurality of different access points are within a third geographic location served by the datacenter. However, Nagaratnam-Amin-Balthua in view of Jain discloses: wherein at least one fallback access point is associated with a datacenter; and the plurality of different access points are within a third geographic location served by the datacenter.
Refer to at least FIG. 8 and [0031] of Jain with respect to datacenter equipment represented as graph nodes for performing failover.
The teachings of Jain likewise concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant's invention to modify the teachings of Nagaratnam-Amin-Balthua to further implement support for graphing nodes associated with a datacenter because design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Claim(s) 9-12 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Torkamani (US 11,743,282 B1) in view of Nagaratnam (US 2003/0233543 A1) and Venna (US 2017/0236079 A1).
Regarding claim 9, Torkamani discloses: A method comprising:
generating, by a computing device, a graph (e.g., k-partite graph in Torkamani) defining a relationship between a network address, an access point of a plurality of access points, and one or more records associated with at least one domain, wherein the relationship is based on the network address being [associated with] the plurality of access points across a plurality of geographic locations (“the nodes and edges may be based on data from one or multiple geographic regions of user use of the cloud-based environment” in Col. 12, Ll. 57-61 of Torkamani);
Refer to at least Col. 4, Ll. 45-60 of Torkamani, which discloses that “the system may extract a k-partite graph from the DNS data, with different types of nodes, such as elastic computing instances (e.g., a unique identifier of an instance that queried a domain), a fully qualified domain name (FQDN, referring to a tuple of the subdomain, second-level domain, and top-level domain that was queried by the instance), a second-level domain and top-level domain pair (e.g., tuple), and IP address in a DNS query response that resolves to the domain. Based on the nodes, the edges of the k-partite graph may include edges between elastic computing instances and a FQDN queried by the instance, edges between a FQDN and an IP address when the FQDN resolved to the IP address, and edges between FQDNs and their pairs of second-level and top-level domains. The k-partite graph may be spatio-temporal in that it may include data for multiple days of cloud-based environment use from multiple regions.”
controlling, by the computing device, data transfer between the at least one domain and a device.
Refer to at least Col. 13, Ll. 40-46 of Torkamani, disclosing that “[b]ased on the k-partite graph, the one or more reputation scoring services 126 may determine reputation scores/labels for any nodes of the k-partite graph (e.g., corresponding to the entities 112, 116, and/or 120), which may be used to control the flow of traffic inside and/or outside of the cloud-based environment 110.”
Torkamani does not disclose: generating, by the computing device, a certificate for the network address based on the graph; controlling data transfer further comprising being based on the certificate. However, Torkamani in view of Nagaratnam discloses: generating, by the computing device, a certificate for the network address based on the graph;
Refer to at least [0035], [0039], [0048], and [0054]-[0055] of Nagaratnam with respect to either providing certificates responsive to a network change. As per at least the abstract and [0057], the certificates are provided based on a trust graph.
controlling data transfer further comprising being based on the certificate.
Refer to at least [0004]-[0005] of Nagaratnam with respect to using the certificates for SSL communication.
The teachings of Torkamani and Nagaratnam both concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Torkamani to further use the k-partite graph as part of generating certificates for at least the reasons discussed in [0006] of Nagaratnam (i.e., an improved certificate distribution mechanism) and for the purpose of generating certificates specific to a network topology and its trust relationships (i.e., an administrator may not want generic certificates for safety reasons, such as to isolate certain network entities from most communication).
Torkamani-Nagaratnam does not specify: the relationship further comprising the network address being assigned to the plurality of access points. However, Torkamani-Nagaratnam in view of Venna discloses: the relationship further comprising the network address being assigned to the plurality of access points.
Refer to at least FIG. 7 and [0175] of Venna with respect to entity nodes and the graph capturing the relationships of domains to the entities that operate/are responsible for them. Further see at least [0174] of Venna with respect to location attributes for nodes.
The teachings of Venna likewise concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Torkamani-Nagaratnam to further implement additional node information and attributes for at least the purpose of improving reputation scoring by having more granular data.
Regarding claim 10, Torkamani-Nagaratnam does not disclose: wherein the at least one domain is served by multiple providers that comprise a first provider hosted by an entity and a second provider hosted by a content delivery network that is different than the entity, wherein the first provider is represented in the graph by a first node and the second provider is represented in the graph by a second node. However, Torkamani-Nagaratnam in view of Venna discloses: wherein the at least one domain is served by multiple providers that comprise a first provider hosted by an entity and a second provider hosted by a content delivery network that is different than the entity, wherein the first provider is represented in the graph by a first node and the second provider is represented in the graph by a second node.
Refer to at least FIG. 7, [0076], [0179]-[0183], and [0210]-[0211] of Venna with respect to a graph having edges representative of relationships such as being served by a content delivery network for a given domain. Additional types of edges include those for servers, web servers, and mail services.
The teachings of Venna likewise concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Torkamani-Nagaratnam to further support CDN relations for the graph because design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Regarding claim 11, it is rejected for substantially the same reasons as claim 9 above (i.e., exchanging and using certificates for access—e.g., [0004]-[0005] of Nagaratnam).
Regarding claim 12, Torkamani-Nagaratnam-Venna discloses: The method of claim 9, wherein the one or more records comprise an indication of one or more of the at least one domain or one or more subdomains associated with the at least one domain.
Refer to at least Col. 4, Ll. 36-61 and Col. 12, Ll. 7-21 of Torkamani with respect to an indication of the domain or associated subdomain.
Regarding claim 14, it is rejected for substantially the same reason as claim 9 above (i.e., the citations concerning the k-partite graph; “the edges between nodes may represent different meanings and types of relationships between the nodes”).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Torkamani-Nagaratnam-Venna as applied to claims 9-12 and 14 above, and further in view of Maslak (US 2020/0404050 A1).
Regarding claim 13, Torkamani-Nagaratnam-Venna does not specify: wherein controlling the data transfer further comprises: receiving a request for the data transfer from at least one geographic location of the plurality of geographic locations, wherein the network address is an anycast network address: and directing, by the computing device, the request to the access point based on the access point being a nearest access point to the at least one geographic location. However, Torkamani-Nagaratnam-Venna in view of Maslak discloses: wherein controlling the data transfer further comprises: receiving a request for the data transfer from at least one geographic location of the plurality of geographic locations, wherein the network address is an anycast network address: and directing, by the computing device, the request to the access point based on the access point being a nearest access point to the at least one geographic location.
Refer to at least the abstract, FIG. 3, and [0042] of Maslak with respect to receiving a request for content and obtaining an anycast address from a nearby geographic region.
The teachings of Maslak concern controlling traffic flow and the anycast methodology, which is considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Torkamani-Nagaratnam-Venna to further support anycast because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Torkamani-Nagaratnam-Venna as applied to claims 9-12 and 14 above, and further in view of Sethuramalingam (US 10,673,716 B1).
Regarding claim 15, Torkamani-Nagaratnam-Venna does not specify: wherein the network address is a virtual internet protocol address configured for access by at least one of a physical network interface or the device. However, Torkamani-Nagaratnam-Venna in view of Sethuramalingam discloses: wherein the network address is a virtual internet protocol address configured for access by at least one of a physical network interface or the device.
Refer to at least Col. 14, Ll. 38-43 of Sethuramalingam with respect to substituting virtual network interfaces for public or private network addresses.
The relied upon teachings of Sethuramalingam concern networking generally, and are considered to be combinable with those of Torkamani-Nagaratnam-Venna concerning network addresses.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Torkamani-Nagaratnam-Venna to further support virtual interfaces and addresses because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Claim(s) 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nagaratnam (US 2003/0233543 A1) in view of Farber (US 11,204,961 B1) and Sinha (US 2024/0283809 A1).
Regarding claim 16, Nagaratnam discloses: A method comprising:
generating, by a computing device, a graph (e.g., trust graph in Nagaratnam) that defines a first relationship and a second relationship;
Refer to at least [0033] and [0043] of Nagaratnam with respect to the trust graph having nodes representing relationships between clients, servers, and end entities.
generating, by the computing device, a certificate for accessing data via the domain based on at least one of the first relationship or the second relationship; and
Refer to at least [0035], [0039], [0048], [0054]-[0055], and [0057] of Nagaratnam with respect to either providing certificates based on the trust graph.
controlling, by the computing device, data transfer between the domain and a device based on the certificate.
Refer to at least [0004]-[0005] of Nagaratnam with respect to using the certificates for SSL communication.
Nagaratnam does not specify: the first relationship further comprising being between a network address and a record associated with a domain; the second relationship further comprising being between the network address and an alias record associated with a domain However, Nagaratnam in view of Farber discloses: the first relationship further comprising being between a network address and a record associated with a domain; the second relationship further comprising being between the network address and an alias record associated with a domain.
Refer to at least FIG. 7 and Col. 31, Ll. 1-40 of Farber with respect to a service dependency work graph including “availability data, DNS data, and API data associated therewith… represented DNS data 706A may, for example, comprise one or more of a DNS lookup, a Start of Authority (SOA) record, an IP address, a simple mail transfer protocol (SMTP) mail exchanger (MX), name servers (NS), pointers for reverse DNS (rDNS) lookups (PTR), a domain name alias (CNAME), the like, or combinations thereof.” Further refer to at least Col. 14, Ll. 18-31 of Farber with respect to a service dependency data type (e.g., DNS and domain names).
The teachings of Nagaratnam and Farber both concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Nagaratnam to further include DNS data such as addresses, records, aliases, and type for at least the purpose of more comprehensive trust graphs and further limiting certificates according to additional policy details based on the more comprehensive trust graphs (i.e., more granular security policy), and further for at least the reasons discussed in Col. 5, Ll. 3-29 of Farber (i.e., discovering service information and addressing conflicts).
Nagaratnam-Farber does not specify: the domain associated with the alias record further comprising a root domain. However, Nagaratnam-Farber in view of Sinha discloses: the domain associated with the alias record further comprising a root domain.
Refer to at least the abstract and [0049]-[0051] of Sinha with respect to grouping and classifying domains for a network graph, including root domains.
The teachings of Sinha likewise concern graphing relationships between network nodes, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Nagaratnam-Farber to further implement support for classifying root domains as part of DNS data the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., additional DNS data and combinations concerning Col. 31, Ll. 1-40 of Farber).
Regarding claim 17, it is rejected for substantially the same reasons as claim 16 above (e.g., the citations; FIG. 7).
Regarding claim 18, Nagaratnam-Farber-Sinha discloses: The method of claim 17, wherein the certificate comprises the first relationship based on the network address and the record being adjacent nodes in the graph.
Refer to at least [0043] of Nagaratnam with respect to the trust graph relationship having trust if two zones are connected by an arrow.
Regarding claim 19, Nagaratnam-Farber-Sinha discloses: The method of claim 16, wherein the certificate comprises the second relationship based on the network address and the record being separated by one or more nodes in the graph.
Refer to at least FIG. 7-8 and Col. 32, Ll. 37-62 of Farber with respect to the dependency graph showing that, e.g., service A is limited based on its residency type (e.g., only within region A).
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Nagaratnam-Farber to further implement generating the certificate based on graph distance (e.g., representing regional distance) for substantially the same reasons as claim 16 above (i.e., more granular access control).
Regarding claim 20, Nagaratnam-Farber-Sinha discloses: The method of claim 16, wherein: the alias record corresponds to the first relationship.
Refer to at least Col. 31, Ll. 1-40 and Col. 17, Ll. 55-59 of Farber with respect to DNS data combinations for the dependency graph and the disclosure that “the service dependency data type may include Domain Name System (DNS) lookup, tracing, access logs, messaging, manual, service, domain names.”
Nagaratnam-Farber does not disclose: wherein the domain is a root domain. However, Nagaratnam-Farber in view of Sinha discloses: wherein the domain is a root domain.
Refer to at least the abstract and [0049]-[0051] of Sinha with respect to grouping and classifying domains for a network graph, including root domains.
This claim would have been obvious for substantially the same reasons as claim 16 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights