DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication filed on 08/01/2024.
Status of claims in the instant application:
Claims 1-20 are pending.
Priority
This application is a CON of 18/307,183 filed on 04/26/2023 now PAT 12,081,679 which is a DIV of 17/537,702 filed on 11/30/2021 now PAT 11,671,266. This also claim benefit to EUROPEAN PATENT OFFICE (EPO) 20217801.8 filed on 12/30/2020 and EUROPEAN PATENT OFFICE (EPO) 20212145.5 filed on 12/07/2020.
The priority documents have been received by the office.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 08/01/2024 have been considered, and a signed copies of the IDS forms have been attached to this office action.
Drawings
Drawings filed on 08/01/2024 have been inspected, and it’s in compliance with MPEP 608.02.
Specification
The abstract of the disclosure is objected to because it contains legal phraseology often used in patent claims, and it should be avoided in the abstract.
The abstract of the instant application recites, “… the first domain name comprises the certificate identifier …”. The word “comprises” is a legal phraseology often used in patent claims.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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, 3, 4 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20170111473 A1 to AMIGA et al. (hereinafter “AMIGA”) in view of Pub. No.: US 20150281168 A1 to Holloway et al. (hereinafter “Holloway”).
Regarding Claim 1. AMIGA discloses A computer-implemented method for providing a domain name system (DNS) response (AMIGA: Abstract, FIG. 1-2: … Processing computer network requests by receiving from a requesting computer an encoded value in a domain name resolution request, where the encoded value has a valid domain name syntax, decoding the encoded value into a Uniform Resource Locator having a host portion and a non-host portion, determining that the host portion of the Uniform Resource Locator in combination with the non-host portion of the Uniform Resource Locator meets a predefined routing criterion associated with a computer network address that is associated with a proxy server, and sending the computer network address to the requesting computer in response to the domain name resolution request …), the method comprising:
receiving, from a requestor, a DNS request for resolving a [fully qualified] domain name, the [fully qualified] domain name including an encoded domain name as a label (AMIGA, Abstract, FIG. 2, Para [0036, 0042]: … Processing computer network requests by receiving from a requesting computer an encoded value in a domain name resolution request, where the encoded value has a valid domain name syntax … At server 120, a URL decoder 124 is configured to receive one or more encoded values associated with a URL, such as URL 108, in one or more domain name resolution requests as described above …);
determining a decoded domain name based on the encoded domain name (AMIGA, Abstract, FIG.2, Para [0036, 0042]: … decoding the encoded value into a Uniform Resource Locator having a host portion and a non-host portion, determining that the host portion of the Uniform Resource Locator in combination with the non-host portion of the Uniform Resource Locator meets a predefined routing criterion associated with a computer network address that is associated with a proxy server … decode the encoded values into a URL 108′ by applying decoding techniques that are complementary to the techniques used to create the encoded values, where URL 108′ includes all host and non-host portions 110′ and 112′ that URL 108′ included prior to its encoding as described above. A proxy selector 126 is configured to determine whether host portion 110′ of URL 108′ in combination with non-host portion 112′ of URL 108′ meets one or more predefined routing criteria 128 associated with a computer network address at a proxy server 130 …); and
providing, to the requestor, a DNS response including the decoded domain name (AMIGA, Abstract, FIG.2, Para [0036, 0042: … sending the computer network address to the requesting computer in response to the domain name resolution request … send the computer network address in response to the domain name resolution request(s), such as to domain name resolution requestor 118 …).
However, AMIGA does not explicitly teach, but Holloway from same or similar field of endeavor teaches:
“a DNS request for resolving a fully qualified domain name (Holloway, Abstract, Para [0041-0042], FIG. 2, 8, Claim 1: … A method and apparatus for managing CNAME records such that CNAME records at the root domain are supported while complying with the RFC specification (an IP address is returned for any Address query for the root record). The authoritative DNS infrastructure acts as a DNS resolver where if there is a CNAME at the root record, rather than returning that record directly, a recursive lookup is used to follow the CNAME chain until an A record is located. The address associated with the A record is then returned … At operation 810, a DNS query is received for a domain (a fully qualified domain name (FQDN) … Flow then moves to operation 838 where the name server transmits a response that includes an answer to the query with the generated Address record that includes the IP address …)”
Therefore 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 Holloway into the teachings of AMIGA, because it discloses that, “the DNS server module 215 generates an Address record for the domain name “example.net” using at least the address at the end of the CNAME chain 315 (e.g., 198.51.100.10). the DNS server module 215 returns the generated Address record for “example.net” to the requester. The DNS server module 215 may cache the generated address record 320 so that it may respond locally and avoid traversing the CNAME chain when responding to subsequent requests for the Address record for “example.net” (and respecting the TTL associated with the generated address record) (Holloway, Para [0032])”.
Regarding Claim 2. The combination of AMIGA-Holloway discloses the method of claim 1, Holloway further discloses, “wherein the fully qualified domain name further includes an encoded internet protocol (IP) address (Holloway, Para [0041]: … At operation 810, a DNS query is received for a domain (a fully qualified domain name (FQDN) or sometimes referred to as an absolute domain name) for which the name server is authoritative … The query may be received from a client device or from another DNS server. The DNS query may specify the query type such as an “A” query (requesting an A record) for the domain, an “MX” query (requesting an MX record) for the domain, an “ANY” query (requesting all records) for the domain, or other type of DNS query. In the example of FIG. 8, the query type is either for an Address record (e.g., an A or AAAA record) …) and the method further includes
determining, based on the fully qualified domain name, whether the DNS request is related to an A resource record, an AAAA resource record, or a CNAME resource record (Holloway, Para [0041-0042]: … In the example of FIG. 8, the query type is either for an Address record (e.g., an A or AAAA record) or an “ANY” query. Flow then moves to operation 815 where the name server determines whether the query is for a root domain. If it is not a root domain, then in one embodiment flow moves to operation 840 and the name server responds to the query in its normal fashion. If it is a root domain (e.g., “example.net”), then flow moves to operation 820 where the name server determines whether there is at least one corresponding record that is a CNAME record. If there is not at least one corresponding CNAME record for the requested domain, then flow moves to operation 840 where the name server responds to the query in its normal fashion. If there is a corresponding CNAME record for the domain, then flow moves to operation 825 where the name server follows the CNAME chain to locate an Address record …);
in response to the DNS request being related to the CNAME resource record, determining the decoded domain name based on the encoded domain name, wherein the DNS response includes the CNAME resource record and the decoded domain name (Holloway, Para [0041-0042]: … At operation 830 a determination is made whether an Address record is found at the end of the CNAME chain. If an Address record is not found, then flow moves to operation 845 where alternative actions are taken (e.g., a response is sent that indicates that there is not an address found for the domain). If there is an authoritative name server that is not responding, but there is a record for the corresponding domain that is in cache but is past its TTL, then the name server may return the stale answer. If an Address record is found, then flow moves to operation 835 where the name server generates an Address record using at least the IP address found at the end of the CNAME chain. Flow then moves to operation 838 where the name server transmits a response that includes an answer to the query with the generated Address record that includes the IP address of the Address record found at the end of the CNAME chain …); and
in response to the DNS request being related to the A resource record or the AAAA resource record, determining a decoded IP address based on the encoded IP address, wherein the DNS response includes the decoded IP address and the A resource record or the AAAA resource record (Holloway, Para [0041-0042]: … the DNS query may specify the query type such as an “A” query (requesting an A record) for the domain, an “MX” query (requesting an MX record) for the domain, an “ANY” query (requesting all records) for the domain, or other type of DNS query. In the example of FIG. 8, the query type is either for an Address record (e.g., an A or AAAA record) or an “ANY” query … ).”
The motivation to further combine Holloway remains same as in claim 1.
Regarding Claim 3. The combination of AMIGA-Holloway discloses the method of claim 2, Holloway further discloses, “wherein the determining, based on the fully qualified domain name, whether the DNS request is related to an A resource record, an AAAA resource record, or a CNAME resource record is based on an existence of a label or content of the label not being a lowest label of the fully qualified domain name (Holloway, Para [0038-0040, 0024]: … Embodiments are not limited to responding to requests for Address records. For example, a request may be made for any records for the domain “example.net” with an ANY query. The records for the domain “example.net” may include several different types such as A, MX (Mail Exchange), NS (Name Server), SOA (Start of Authority), CNAME, etc. In such a case, upon receiving a DNS ANY query for the domain “example.net” and determining that there is at least one CNAME record that points to another domain (“x1234.example.com”), the name server follows the CNAME chain to determine the records for the domain “x1234.example.com” until locating an Address record … FIG. 7 illustrates an ANY query for the domain “example.net” assuming the domain records of FIG. 6 according to one embodiment. The DNS system 150 receives the ANY query for the domain “example.net” and locates the records illustrated in FIG. 6. The DNS system 150 traverses the CNAME chain for “example.net” and determines that there are four records that correspond with “example.com” (an A record, an MX record, an NS record, and an SOA record). Since there is already an MX record, NS record, and SOA record for “example.net”, the MX record, NS record, and SOA record for “example.com” will not be included in the response to the query. The Address record 715 for “example.net” in the response includes the address as specified in the Address record for “example.com … Embodiments are not limited to applying only at the root domain level. In some embodiments, other non-root domain names may also be flattened. For example, if the subdomain “www.example.net” has a CNAME that points to another domain, a query for the subdomain “www.example.net” may be returned with a flattened response … The DNS system 150 is used to refer to the DNS system as a whole and includes multiple DNS servers to answer DNS queries. The DNS system 150 may include authoritative name servers, preferred domain servers, top-level domain name servers, or other domain servers. It should also be understood that there may be multiple authoritative web servers that may be geographically distributed …)”.
The motivation to further combine Holloway remains same as in claim 2.
Regarding Claim 4. The combination of AMIGA-Holloway discloses the method of claim 2, Holloway further discloses, “wherein the determining, based on the fully qualified domain name, whether the DNS request is related to an A resource record, an AAAA resource record, or a CNAME resource record is based on content of a lowest label of the fully qualified domain name (Holloway, Para [0038-0040, 0024]: … Embodiments are not limited to responding to requests for Address records. For example, a request may be made for any records for the domain “example.net” with an ANY query. The records for the domain “example.net” may include several different types such as A, MX (Mail Exchange), NS (Name Server), SOA (Start of Authority), CNAME, etc. In such a case, upon receiving a DNS ANY query for the domain “example.net” and determining that there is at least one CNAME record that points to another domain (“x1234.example.com”), the name server follows the CNAME chain to determine the records for the domain “x1234.example.com” until locating an Address record … FIG. 7 illustrates an ANY query for the domain “example.net” assuming the domain records of FIG. 6 according to one embodiment. The DNS system 150 receives the ANY query for the domain “example.net” and locates the records illustrated in FIG. 6. The DNS system 150 traverses the CNAME chain for “example.net” and determines that there are four records that correspond with “example.com” (an A record, an MX record, an NS record, and an SOA record). Since there is already an MX record, NS record, and SOA record for “example.net”, the MX record, NS record, and SOA record for “example.com” will not be included in the response to the query. The Address record 715 for “example.net” in the response includes the address as specified in the Address record for “example.com … Embodiments are not limited to applying only at the root domain level. In some embodiments, other non-root domain names may also be flattened. For example, if the subdomain “www.example.net” has a CNAME that points to another domain, a query for the subdomain “www.example.net” may be returned with a flattened response … The DNS system 150 is used to refer to the DNS system as a whole and includes multiple DNS servers to answer DNS queries. The DNS system 150 may include authoritative name servers, preferred domain servers, top-level domain name servers, or other domain servers. It should also be understood that there may be multiple authoritative web servers that may be geographically distributed …)”.
The motivation to further combine Holloway remains same as in claim 2.
Regarding Claim 15. The combination of AMIGA-Holloway discloses the method of claim 1, AMIGA further discloses, “further comprising:
establishing a secured connection between the requestor and a client (AMIGA, Para [0002, 0036-0037]: … Domain name resolution requestor 118 is configured, in accordance with conventional techniques, to receive computer network addresses in response to its domain name resolution requests, whereupon any computer network resource access requests whose URLs were processed as described hereinabove, such as request 100, are sent to the computer network addresses at their specified proxy servers which the process the requests by applying the predefined policies associated with the computer network addresses as described hereinabove. Where request 100 is configured to be sent using a cryptographic protocol, such as TLS or SSL, the proxy server that receives request 100 is nevertheless able to apply the predefined policy associated with the computer network address at which request 100 is received even though the proxy server is not able to peer into the encrypted contents or request 100 …).”
Regarding Claim 16. The combination of AMIGA-Holloway discloses the method of claim 15, AMIGA further discloses, “further comprising:
sending an authentication request by the requestor to a device (AMIGA, Para [0003, 0042]: … a method is provided for processing computer network requests, the method including receiving from a requesting computer an encoded value in a domain name resolution request, where the encoded value has a valid domain name syntax, decoding the encoded value into a Uniform Resource Locator having a host portion and a non-host portion … a request is made on a computer to access a resource via a computer network, where the request includes a Uniform Resource Locator (URL) that specifies the location of the resource on the computer network (step 220). The URL, including its host and non-host portions, is encoded into an encoded value having a valid domain name syntax (step 222). The encoded value is sent in a domain name resolution request to a server (step 224), such as by invoking a dnsResolve method of a proxy auto-configuration (PAC) file in which encoded value is used as a parameter of the dnsResolve method … …); and
receiving an authentication response from the device by the requestor (AMIGA, Para [0003, 0042]: … determining that the host portion of the Uniform Resource Locator in combination with the non-host portion of the Uniform Resource Locator meets a predefined routing criterion associated with a computer network address that is associated with a proxy server, and sending the computer network address to the requesting computer in response to the domain name resolution request … At the server, the encoded value is decoded into the URL, including its host and non-host portions (step 226), using a decoding technique that is complementary to the technique used to create the encoded value. If the URL, including its host and non-host portions, meets predefined routing criteria associated with an alias computer network address that is associated with a destination computer network address and port at a proxy server that is configured to apply a predefined policy to requests that are received at the destination computer network address and port (step 228), the alias computer network address is sent to the computer in response to the domain name resolution request (step 230) where the alias computer network address is replaced with its associated destination computer network address and port …).”
Regarding Claim 17. This claim contains all the same or similar limitations as claim 1, hence similarly rejected as claim 1.
**** AMIGA also discloses, “A system for providing a domain name system (DNS) response, the system comprising: at least one memory storing instructions; and at least one processor configured to execute the instructions (AMIGA: Para [0015, 0043-0046])” .
Regarding Claim 18. This claim contains all the same or similar limitations as claim 2, hence similarly rejected as claim 2.
Regarding Claim 19. This claim contains all the same or similar limitations as claim 1, hence similarly rejected as claim 1.
**** AMIGA also discloses, “A non-transitory computer-readable medium storing instructions that, when executed by at least one processor at a system, cause the system to perform a method for providing a domain name system (DNS) response (AMIGA: Para [0015, 0043-0046])” .
Regarding Claim 20. This claim contains all the same or similar limitations as claim 2, hence similarly rejected as claim 2.
Claims 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20170111473 A1 to AMIGA et al. (hereinafter “AMIGA”) in view of Pub. No.: US 20150281168 A1 to Holloway et al. (hereinafter “Holloway”), as applied to claim 1 above, and further in view of Pub. No.: US 20200287865 A1 to CHEN (hereinafter “CHEN”).
Regarding Claim 5. The combination of AMIGA-Holloway discloses the method of claim 1, however it does not explicitly teach but CHEN from same or similar field of endeavor teaches:
“wherein the encoded domain name is a domain name where one or more special characters in the DNS are replaced by one or more masking characters (CHEN, Abstract, Fig. 2, Para [0017], Claim 6, 15: … In the present disclosure, the method for acquiring the resource includes: receiving a resource request message sent by a content delivery network server based on a first Internet protocol), the resource request message including a domain name address of the resource that is requested; determining that the domain name address belongs to a preset domain name, then decoding the domain name address to obtain an original domain name address … The method for acquiring the resource according to claim 1, wherein decoding the domain name address to obtain the original domain name address comprises: replacing a special character in the domain name address with a dot separator …)”.
Therefore 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 CHEN into the combined teachings of AMIGA-Holloway, because it discloses that, “Compared with existing technologies, by introducing the rewrite server between the CDN server and the resource server, the embodiments of the present disclosure enable the domain name address of the resource requested by a client which belongs to the preset domain name to be directed to the resource server corresponding to the resource that is requested through the rewrite server, without changing a function of each of internal nodes in the CDN network or changing the way the resource server processes contents of a page file. In this case, resources that are not in the same domain may be accessed by the client, thereby improving the customer experience, reducing the cost, and upgrading the Internet communication protocol supported by the website (CHEN, Para [0010])”.
Regarding Claim 6. The combination of AMIGA-Holloway-CHEN discloses the method of claim 5, CHEN further discloses, “wherein the determining the decoded domain name based on the encoded domain name includes replacing the one or more masking characters within the encoded domain name with corresponding one or more special characters within the DNS (CHEN, Abstract, Fig. 2, Para [0017-0019], Claim 6, 15: … In this embodiment, the special character in the domain name address is replaced by the dot separator, and the domain name address in which the special character has been replaced is combined with the preset domain name to obtain the original domain name address. The resource required by the client is obtained from the resource server corresponding to the resource that is requested according to the original domain name address, so that the client in an IPv6 environment may access the resource that is not in the same domain as the client, thus bringing good customer experience to customers … in one embodiment, determining the original domain name address according to the replaced domain name address and the preset domain name includes: deleting the preset domain name contained in the replaced domain name address to obtain the original domain name address …)”.
The motivation to further combine CHEN remains same as in claim 5.
Claims 7, 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20170111473 A1 to AMIGA et al. (hereinafter “AMIGA”) in view of Pub. No.: US 20150281168 A1 to Holloway et al. (hereinafter “Holloway”), as applied to claim 1 above, and further in view of Pub. No.: US 20180097831 A1 to Uppal et al. (hereinafter “Uppal”).
Regarding Claim 7. The method of combination of AMIGA-Holloway discloses the claim 1, however it does not explicitly teach but Uppal from same or similar field of endeavor teaches, “wherein the fully qualified domain name includes a certificate identifier (Uppal, Para [0015]: … While examples are provided above enabling domain names to be encoded into network addresses, other DNS-level information may additionally or alternatively be encoded into a network address under the present disclosure. For example, a DNS service may encode within a network address “hint information,” that enables a router or other computing device (e.g., a server within a POP) to more efficiently service requests to communicate with the network address. Illustratively, the hint information may include an identifier of a security certificate (e.g., and SSL or TLS certificate) associated with a domain name to which the request is directed …; Examiner’s Note: already discloses the fully qualified domain name ).”
Therefore 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 Uppal into the combined teachings of AMIGA-Holloway, because it discloses that, “encoding of hint information within a network address may reduce or eliminate the need for a router or other computing device (e.g., of a CDN) to maintain a mapping of network addresses to associated security certificates, or to inspect data packets for information identifying a relevant security certificate (e.g., a “host header” within an HTTP packet). Because decoding of hint information within a network address may require less processing power or memory usage than would packet inspection or using lookups to external mappings, use of hint information can reduce the computing resources used by a router or other computing device (Uppal, Para [0015])”.
Regarding Claim 8. The combination of AMIGA-Holloway- Uppal discloses the method of claim 7, Uppal further discloses, “wherein the certificate identifier is related to a digital certificate owned by a device, wherein the device is different from the requestor (Uppal, Para [0015]: … While examples are provided above enabling domain names to be encoded into network addresses, other DNS-level information may additionally or alternatively be encoded into a network address under the present disclosure. For example, a DNS service may encode within a network address “hint information,” that enables a router or other computing device (e.g., a server within a POP) to more efficiently service requests to communicate with the network address. Illustratively, the hint information may include an identifier of a security certificate (e.g., and SSL or TLS certificate) associated with a domain name to which the request is directed. Accordingly, when a computing device receives a request to communicate with a network address including encoded hint information, the computing device may decode the hint information, determine the security certificate identified by the hint information, and establish a secure communication channel with a client computing device. …; Examiner’s Note: … the identifier is not for the client making the request but for the domain and is used to establish connection to other device from the client).”
The motivation to further combine Uppal remains same as in claim 7.
Regarding Claim 9. The combination of AMIGA-Holloway- Uppal discloses the method of claim 8, Uppal further discloses, “wherein the certificate identifier is a hash value or a random value (Uppal, Para [0043]: … on receiving a request to communicate with the network address, a receiving device (e.g., a content server 122) may verify the validity of the network address by confirming the digital signature (e.g., decrypting the digital signature using a corresponding cryptographic public key and comparing a resulting value to an independent hash of the same set of inputs). The bits of groups 6 and 7, representing hint information, may represent information informing a receiving device of how to handle requests to communicate with the network address, such as an identifier of a security certificate to utilize in creating a secure communication channel with an accessing computing device 102. Thus, on receiving a request to communicate with the network address, a receiving device (e.g., a content server 122) may retrieve a security certificate corresponding to the hint information and use such a certificate to establish secure communications with the accessing computing device 102. Additional examples of hint information may include, for example, an identifier or network address of a resolver from which a DNS request corresponding to the encoded network address was received, a location of that resolver, etc …).”
The motivation to further combine Uppal remains same as in claim 8.
Claims 10, 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20170111473 A1 to AMIGA et al. (hereinafter “AMIGA”) in view of Pub. No.: US 20150281168 A1 to Holloway et al. (hereinafter “Holloway”) and Pub. No.: US 20180097831 A1 to Uppal et al. (hereinafter “Uppal”), as applied to claim 7 above, and and further in view of Pub. No.: US 20130111560 A1 to Arenas et al. (hereinafter “Arenas”).
Regarding Claim 10. The combination of AMIGA-Holloway-Uppal discloses the method of claim 7, however it does not explicitly teach but Arenas from same or similar field of endeavor teaches, “wherein the fully qualified domain name specifies a domain name, the domain name being a wildcard domain name (Arenas, Abstract, Para [0033]: … Techniques for dynamic domain-based isolation are described. An apparatus may comprise a domain name component operative to receive a domain name request for a uniform resource locator, the domain name component operative to resolve the domain name request 105 on a wildcard entry in a domain name table … In various embodiments, the wildcard entry may comprise a wildcard subdomain with an identifier portion and a wildcard portion. The identifier portion may be a user-specific identifier, a user-specific identifier concatenated with a defined separator character or characters such as the dash used in the example above, or may generally comprise a user-specific identifier. The wildcard portion may comprise an asterisk character, as in the example above, or any other symbol or method of indicating a portion of a subdomain available for wildcard matching …; Examiner’s Note: already discloses the fully qualified domain name).”
Therefore 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 Arenas into the combined teachings of AMIGA-Holloway-Uppal, because it discloses that, “the domain generator component 104 is arranged to automatically generate a domain for a web application 104-a. As previously described, when installing a web application 104-a on a web portal, whether developed by a host entity for the web portal or a third party developer, the web application 104-a needs a separate domain for security purposes. This domain is typically generated by a user or the developer of the web application 104-a, thereby increasing cost and complexity for deploying the web application 104-a. To reduce or eliminate associated cost and complexity, the domain generator component 104 may automatically generate a domain for a web application 104-a as part of the set of installation operations used to install the web application 104-a on a web server. In addition to reducing cost and complexity for a user or developer, this dynamic domain generation provides some unique advantages to the web server, such as having fine control over how each domain is generated for a web application 104-a and/or a user. For instance, the domain generator component 104 may generate a domain using an algorithm that reduces a time needed to perform and resolve domain name system (DNS) searches by the domain name component 110. This may be of particular value in large-scale hosting scenarios in which the responsiveness of the domain name system is a limiting factor in performance (Arenas, Para [0024])”.
Regarding Claim 11. The combination of AMIGA-Holloway-Uppal-Arenas discloses the method of claim 10, Holloway further discloses, “wherein the certificate identifier is a label of the domain name different from a last label of the domain name. (Holloway, Para [0038-0040, 0024]: … Embodiments are not limited to responding to requests for Address records. For example, a request may be made for any records for the domain “example.net” with an ANY query. The records for the domain “example.net” may include several different types such as A, MX (Mail Exchange), NS (Name Server), SOA (Start of Authority), CNAME, etc. In such a case, upon receiving a DNS ANY query for the domain “example.net” and determining that there is at least one CNAME record that points to another domain (“x1234.example.com”), the name server follows the CNAME chain to determine the records for the domain “x1234.example.com” until locating an Address record … FIG. 7 illustrates an ANY query for the domain “example.net” assuming the domain records of FIG. 6 according to one embodiment. The DNS system 150 receives the ANY query for the domain “example.net” and locates the records illustrated in FIG. 6. The DNS system 150 traverses the CNAME chain for “example.net” and determines that there are four records that correspond with “example.com” (an A record, an MX record, an NS record, and an SOA record). Since there is already an MX record, NS record, and SOA record for “example.net”, the MX record, NS record, and SOA record for “example.com” will not be included in the response to the query. The Address record 715 for “example.net” in the response includes the address as specified in the Address record for “example.com … Embodiments are not limited to applying only at the root domain level. In some embodiments, other non-root domain names may also be flattened. For example, if the subdomain “www.example.net” has a CNAME that points to another domain, a query for the subdomain “www.example.net” may be returned with a flattened response … The DNS system 150 is used to refer to the DNS system as a whole and includes multiple DNS servers to answer DNS queries. The DNS system 150 may include authoritative name servers, preferred domain servers, top-level domain name servers, or other domain servers. It should also be understood that there may be multiple authoritative web servers that may be geographically distributed …; Examiner’s note: Uppal prior art already discloses the certificate)”.
The motivation to further combine Holloway remains same as in claim 1.
Regarding Claim 12. The combination of AMIGA-Holloway-Uppal-Arenas discloses the method of claim 11, Holloway further discloses, “wherein the certificate identifier is a second to last label of the domain name (Holloway, Para [0038-0040, 0024]: … The Address record 715 for “example.net” in the response includes the address as specified in the Address record for “example.com … Embodiments are not limited to applying only at the root domain level. In some embodiments, other non-root domain names may also be flattened. For example, if the subdomain “www.example.net” has a CNAME that points to another domain, a query for the subdomain “www.example.net” may be returned with a flattened response … The DNS system 150 is used to refer to the DNS system as a whole and includes multiple DNS servers to answer DNS queries. The DNS system 150 may include authoritative name servers, preferred domain servers, top-level domain name servers, or other domain servers. It should also be understood that there may be multiple authoritative web servers that may be geographically distributed …; Examiner’s note: Uppal prior art already discloses the certificate; also the domain label location in this claim is an obvious variation of claim 11)”.
The motivation to further combine Holloway remains same as in claim 1.
Claims 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20170111473 A1 to AMIGA et al. (hereinafter “AMIGA”) in view of Pub. No.: US 20150281168 A1 to Holloway et al. (hereinafter “Holloway”), as applied to claim 1 above, and further in view of Pub. No.: US 20130111560 A1 to Arenas et al. (hereinafter “Arenas”).
Regarding Claim 13. The combination of AMIGA-Holloway discloses the method of claim 1, however it does not explicitly teach but Arenas from same or similar field of endeavor teaches, “wherein the fully qualified domain name specifies a domain name and the domain name includes an asterisk label (Arenas, Abstract, Para [0033]: … Techniques for dynamic domain-based isolation are described. An apparatus may comprise a domain name component operative to receive a domain name request for a uniform resource locator, the domain name component operative to resolve the domain name request 105 on a wildcard entry in a domain name table … In various embodiments, the wildcard entry may comprise a wildcard subdomain with an identifier portion and a wildcard portion. The identifier portion may be a user-specific identifier, a user-specific identifier concatenated with a defined separator character or characters such as the dash used in the example above, or may generally comprise a user-specific identifier. The wildcard portion may comprise an asterisk character, as in the example above, or any other symbol or method of indicating a portion of a subdomain available for wildcard matching …; Examiner’s Note: already discloses the fully qualified domain name).”
Therefore 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 Arenas into the combined teachings of AMIGA-Holloway, because it discloses that, “the domain generator component 104 is arranged to automatically generate a domain for a web application 104-a. As previously described, when installing a web application 104-a on a web portal, whether developed by a host entity for the web portal or a third party developer, the web application 104-a needs a separate domain for security purposes. This domain is typically generated by a user or the developer of the web application 104-a, thereby increasing cost and complexity for deploying the web application 104-a. To reduce or eliminate associated cost and complexity, the domain generator component 104 may automatically generate a domain for a web application 104-a as part of the set of installation operations used to install the web application 104-a on a web server. In addition to reducing cost and complexity for a user or developer, this dynamic domain generation provides some unique advantages to the web server, such as having fine control over how each domain is generated for a web application 104-a and/or a user. For instance, the domain generator component 104 may generate a domain using an algorithm that reduces a time needed to perform and resolve domain name system (DNS) searches by the domain name component 110. This may be of particular value in large-scale hosting scenarios in which the responsiveness of the domain name system is a limiting factor in performance (Arenas, Para [0024])”.
Regarding Claim 14. The combination of AMIGA-Holloway-Arenas discloses the method of claim 13, Holloway further discloses, “wherein the asterisk label is a last label of the domain name (Holloway, Para [0023-0024, 0039-0040]: … a user may input a domain name into the address bar of their browser (e.g., http://www.example.com) to access that page, which causes the browser to make a request for the IP address mapped to that domain name … The DNS system 150 is used to refer to the DNS system as a whole and includes multiple DNS servers to answer DNS queries. The DNS system 150 may include authoritative name servers, preferred domain servers, top-level domain name servers, or other domain servers. It should also be understood that there may be multiple authoritative web servers that may be geographically distributed … Embodiments are not limited to applying only at the root domain level. In some embodiments, other non-root domain names may also be flattened …; Examiner’s Note: Any level of the domain name is contemplated by Holloway, and hence the asterisk can be the last label …).”
The motivation to further combine Holloway remains same as in claim 1.
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20060195687 A1; Klein et al.: Klein discloses A computer-based system and method of mapping an encrypted network request packet to its decrypted copy in a secure computer network web server. Method creates a plug-in module on a secure web server and saves at least one network address and port number from a captured encrypted network request packet. Plug-in module obtains a decrypted copy of the network request packet from the secure web server decryption module and returns it with the network address and port number.
This invention relates in general to the field of computer networks, and in particular to a method and system for highly efficient mapping of encrypted HTTPS network packets to a specific URL name and other encrypted data without performing the decryption outside of a secure web server.
US 20200314065 A1; ROY et al.: ROY discloses a computer-implemented system and method for efficiently configuring the security rules for application firewalls in a cloud-based infrastructure, the cloud-based infrastructure containing at least one of a virtual machine comprising an application, a Domain Name System (DNS) Agent, and a firewall. The method may comprise requesting, by the application, network address information via a DNS server for a fully qualified domain name (FQDN); intercepting, by the DNS Agent, data packets containing the DNS Server query response; decoding, by the DNS Agent, the DNS query response, and identifying the network address information; and updating a security rule of the firewall, by the DNS Agent, based on the decoded network address information. The method may be implemented to update the security rules of application firewalls across an organization's cloud-based infrastructure.
The present invention relates generally to implementing a dynamic firewall for applications in an organization's cloud-based infrastructure, and more particularly to an efficient method and system for automatically configuring the security rules of application firewalls in a cloud-based infrastructure by intercepting DNS query responses and dynamically programming application firewalls with decoded DNS address information.
US 20040260821 A1; Yamamoto et al.: Yamamoto discloses System, method and program product performed by a proxy server which forwards an access request from a client to a data server and forwards response data from the data server to the client. A first address location and an encoding format of the response data are stored. A subsequent access request from the client which includes a second address location encoded by the encoding format is received. The second address location is compared to the first address location to determine if the second address location is related to the first address location. In response to a determination that the second address location is related to the first address location, the second address location is decoded based on the encoding format. The data server can be a web server, the response data can be a web page, and the second address location can include the first address. For example, the second address location can be an extension of the first address location.
US 20220140996 A1; CEBERE et al.: CEBERE discloses systems and methods for carrying out privacy-preserving DNS exchanges. In some embodiments, a client machine engages in a private information retrieval (PIR) exchange with a nameserver. In response to receiving an encrypted query from the client, the query formulated according to a domain name, the nameserver may extract a record (e.g., an IP address) from a domain name database without decrypting the respective query. Some embodiments achieve such information retrieval by the use of homomorphic encryption.
The invention relates to systems and methods for protecting the privacy of online to communication, and in particular, to preventing a remote entity from acquiring information about the browsing habits of Internet users.
US 20210120416 A1; S Bykampadi et al.: Bykampadi discloses a method, comprising: receiving a first message from a service-consuming second network entity in a second mobile network for a service-providing first network entity in a first mobile network, the first message comprising a first callback resource identifier, generating a second callback resource identifier on the basis of the first callback resource identifier, wherein the second callback resource identifier comprises a domain name of a security edge node in the first network, and transferring a callback message from the first network entity to the security edge node, the callback message comprising the second callback resource identifier.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST M-F.
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, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434