Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
DETAILED ACTION
This action is in response to communication filed on 12/19/2025.
Claims 2-5, 7-14, 16-19, and 21-22 are pending.
Claims 2 and 11 has been amended.
Response to Arguments
Applicant's argument(s) filed on 12/19/2025 with respect to claim(s) 2-5, 7-14, 16-19, and 21-22 have been fully considered but they are not persuasive.
In the communication field, applicant argues in substance that:
a. Regarding claim(s) 2 and 11, Applicant argues (Remark page(s) 8-10)
“As per claim 2, Blinn, Anderson, and Hollenbeck fail to disclose or suggest "determining
that a trigger event based on the data change has occurred, wherein the trigger event triggers
validation of the data change." In rejecting claim 2, the Office Action on page 4 admits that Blinn
does not disclose or suggest the previously recited "determining that a trigger event has occurred,
the trigger event indicative of a validation for the data change." Office Action, page 4. To
overcome the failings of Blinn, the Office Action cites paragraphs [0005] and [0032] of Anderson
as allegedly disclosing these features. Office Action, page 4. It is respectfully submitted that the
cited portions of Anderson, when taken in combination with Blinn and Hollenbeck, do not disclose
or suggest "determining that a trigger event based on the data change has occurred, wherein the
trigger event triggers validation of the data change" for at least the following two reasons.
First, paragraph [0005] of Anderson fails to disclose a trigger event that triggers validation
of a data change. In particular, paragraph [0005] of Anderson states, in part, "[a]s source data is fed
into a data warehouse, rejection logic is applied to the source data to determine if the source data is
valid." As such, data (e.g., source data) of Anderson is validated as it is received (e.g., fed into data
warehouse). Data validation in Anderson is neither being triggered nor being performed when a
data change has occurred. Anderson fails to disclose in paragraph [0005], or elsewhere, a trigger
event that triggers validation of a data change.
Second, paragraph [0032] of Anderson fails to disclose a trigger event that triggers
validation of a data change. In particular, paragraph [0032] of Anderson states, in part:
The system loads data into a data warehouse from a relational database (stage 312). The
system runs the validation queries based on query templates to perform validation tests
against dimensions and fact tables (stage 314). The system also runs validation queries based
on query templates to handle rejected rows appropriately (stage 316). These validation
queries help ensure that the data integrity and data completeness of the data warehouse has
been achieved after the data was transformed from the source data in the original database
structure.
The Office Action appears to align the determining of whether source data was transformed
by a validity indicator of Anderson as a triggering event. However, the data validation module
described by Anderson merely checks data integrity and data completeness in a data warehouse. The
data validation module is not triggered by any type of trigger event based on any certain data
change. Anderson fails to disclose in paragraph [0032], or elsewhere, a trigger event that triggers
validation of a data change.”
In response to argument [a], Examiners respectfully disagrees.
The examiner interprets the claim limitation as "determining/detecting data updated/transformed/converted/changed/modified, then validate the updated/transformed/converted/changed/modified data ". Therefore, Anderson teaches this interpretation because "[0032], FIG. 6 is a process flow diagram 310 that illustrates one implementation of the stages involved in using a data validation module to check data integrity and data completeness in a data warehouse. The system loads data into a data warehouse from a relational database (stage 312). The system runs the validation queries based on query templates to perform validation tests against dimensions and fact tables (stage 314). The system also runs validation queries based on query templates to handle rejected rows appropriately (stage 316). These validation queries help ensure that the data integrity and data completeness of the data warehouse has been achieved after the data was transformed from the source data in the original database structure. [examiner notes: the transformed source data interprets to be the data change. The system runs the validation after the data was loaded and transformed from the source data (a relational database) in the original database structure into a data warehouse.]”.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/19/2025 has been entered.
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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
1. Claim 2, 7, 8, 11, 16 and 17 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable by Blinn (US 20070067465 A1) in view of Anderson (US 20090150447 A1) in view of Hollenbeck (US 20050102354 A1).
With respect to independent claims:
Regarding claim 2, a computer-implemented method of updating domain name system (DNS) registry data stored in a DNS resolution services system, comprising:
Blinn teaches receiving, by a DNS resolution device of the DNS resolution services system, a data change of a DNS registry provisioning database of a DNS registry, wherein the data change includes provisioning data; (Blinn, [0024], [0042]- [0043], Fig.1, FIG. 3A and FIG. 3B; Fig.1 shows remote severs such as Registrar server 130, an independent server 150, a hosting server 140, and a server 160. The remote servers are DNS server. Receives an indication of control 310, which indicates that a particular user has the authority to control the use of a domain name. The user types in the domain name into the field, and the data is received by an application running on a remote server. The method then provides authorization code 325. This providing step is performed as part of a transmission of a human-readable content such as a web page that displays the authorization code together with instructions for a user to manually modify his DNS record 240 to include the authorization code. [examiner notes: remote server interprets to be DNS resolution device. Domain name system record 240 interprets to be DNS registry provisioning database.])
extracting, by the DNS resolution device, the provisioning data from the data change; and (Blinn, [0029], [0045], Fig.2 and Fig.3; the user provides the authorization code and modified DNS record to the system 205. The system 20z\ 5 comparison verifies the publication of the authorization code in the DNS record, then validation of the control of the domain name is established. The comparison may be performed by comparing only a certain location within the DNS records, it may be performed by looking for a unique sequence of starting characters, or it may follow a parsing step which identifies the location to be compared, as appreciated by those skilled in the art. [examiner notes: the DNS records interprets to be the transformed data change. The authorization code and modified the DNS record interpret to be the data change.])
updating, based on the data change, the DNS registry data in one or more DNS resolution service resources of the DNS resolution services system, (Blinn, [0029], Fig.2; the user 200 then follows the instructions to electronically publish the authorization code, that is, to modify the DNS record 240 to include, at least, the authorization code.)
Blinn does not teach determining that a trigger event based on the data change has occurred, wherein the trigger event triggers validation of the data change; validating the data change, wherein the validating comprises comparing a transformed version of the data change with the data change; wherein the updating comprises propagating the provisioning data to the one or more DNS resolution service resources.
Anderson however in the same field of computer networking teaches determining that a trigger event based on the data change has occurred, wherein the trigger event triggers validation of the data change;(Anderson, [0005], the validity indicator is used with one or more validation query templates to determine whether the source data was transformed into destination data as expected. [0035], FIG. 8 is a diagrammatic view of one implementation of a data validation/data integrity query template 380. The data validation/data integrity query template 380 has a first validation check 382 that is responsible for ensuring that the value in each data field is correctly represented. This first validation check 382 ensures that there will be no truncations of data and that a column value (or group of column values) will be correctly mapped and transformed into the warehouse. The data validation/data integrity query template 380 also has a second validation check 384 that is responsible for data integrity verification. The second validation check 384 ensures that relationships between fact data are maintained within the dimensions. In other words, the second validation check 384 is used to ensure that all non-rejected rows in the source data were extracted and loaded as expected. After an extract-transform-load (ETL) process completes, the second validation check 384 validates that there is not any source data that was missed and that there are not any “extra” rows.)
responsive to determining that the trigger event has occurred, validating the data change, wherein the validating comprises comparing a transformed version of the data change with the data change; (Anderson, [0005], the validity indicator is used with one or more validation query templates to determine whether the source data was transformed into destination data as expected. [0032], FIG. 6 is a process flow diagram 310 that illustrates one implementation of the stages involved in using a data validation module to check data integrity and data completeness in a data warehouse. The system loads data into a data warehouse from a relational database (stage 312). The system runs the validation queries based on query templates to perform validation tests against dimensions and fact tables (stage 314). The system also runs validation queries based on query templates to handle rejected rows appropriately (stage 316). These validation queries help ensure that the data integrity and data completeness of the data warehouse has been achieved after the data was transformed from the source data in the original database structure. [examiner notes: the transformed source data interprets to be the data change. The validation is performed after the data was loaded and transformed from the source data (a relational database) in the original database structure into a data warehouse.]”.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Blinn by incorporating the teachings of Anderson. The motivation/suggestion would have been because there is a need to provide a framework for validating data completeness and data integrity of a data warehouse (Anderson, [0004]).
Blinn does not teach wherein the updating comprises propagating the provisioning data to the one or more DNS resolution service resources.
Hollenbeck however in the same field of computer networking teaches wherein the updating comprises propagating the provisioning data to the one or more DNS resolution service resources. (Hollenbeck, [0043], [0053], Fig.1, Fig.3; Registry 114 may be an entity that receives DNS information from registrars 108, 110, or 112, inserts that information into a centralized database resident at registry 114, and propagates the information in Internet zone files on the Internet so that domain names can be found by users around the world via applications such as the world wide web and e-mail. Upon receiving an indication that the zone file data is valid, zone generation/whois dumper 340 stores the file(s) on a database resident at root server 328 or another DNS server (not shown), where the file(s) are it available for propagation across Internet 301. [examiner notes: an internet zone file is a text file that stores information about a domain's records and zone in a Domain Name System (DNS) server.])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Blinn by incorporating the teachings of Hollenbeck. The motivation/suggestion would have been because there is a need to providing a shared registration system for registering domain names (Hollenbeck, [0002]).
Claim(s) 11 is/are substantially similar to claim 2, and is thus rejected under substantially the same rationale.
With respect to dependent claims:
Regarding claim 7, the method of claim 2,
Blinn do not teach further comprising propagating the data change to a plurality of DNS resolution service resources.
Hollenbeck however in the same field of computer networking teaches further comprising propagating the data change to a plurality of DNS resolution service resources. (Hollenbeck [0042] Registrars 108, 110, and 112 function to process domain name registrations for registrants and then send the necessary DNS information to registry 114 for entry into a centralized registry database and ultimate propagation over the Internet. DNS information may include, for example, domain name, name server names, and name server Internet Protocol (IP) numbers.)
The same motivation to combine as the dependent claim 2 applies here.
Regarding claim 8, Blinn-Hollenbeck teach the method of claim 2, wherein the at least one DNS resolution device comprises at least one of: a DNS server or a registration directory service server. (Blinn; Fig.1 shows DNS servers.)
Claim(s) 16 is/are substantially similar to claim 7, and is thus rejected under substantially the same rationale.
Claim(s) 17 is/are substantially similar to claim 8, and is thus rejected under substantially the same rationale.
2. Claims 3, 9, 10, 12, 18 and 19 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable by Blinn in view of Anderson in view of Hollenbeck further in view of Assad (US 20060218289 A1).
Regarding claim 3, the method of claim 2,
Blinn-Anderson-Hollenbeck do not teach wherein the trigger event comprises at least one of: a population of data in the DNS registry provisioning database exceeding a threshold, a top level domain (TLD) being added in the DNS registry provisioning database, a TLD being updated in the DNS registry provisioning database, or a TLD being deleted in the DNS registry provisioning database.
Assad however in the same field of computer networking teaches wherein the trigger event comprises at least one of: a population of data in the DNS registry provisioning database exceeding a threshold, a top level domain (TLD) being added in the DNS registry provisioning database, a TLD being updated in the DNS registry provisioning database, or a TLD being deleted in the DNS registry provisioning database. (Assad; [0024], FIG. 2 illustrates an example process for creating a non-ICANN TLD name and an SLD name in greater detail using sample data; [0044], registrar server 104 send a query request to TLD zone database to create a domain name. Steps 214, 216, 218, 220 and 222 shows create a TLD domain name and update TLD zone database.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Blinn by incorporating the teachings of Assad. The motivation/suggestion would have been because there is a need to benefit from a DNS system that is scalable to support millions of TLD names, and is unlimited by the limitations of the current system (Assad, [0015]).
Regarding claim 9, teach the method of claim 1,
Blinn-Anderson-Hollenbeck do not teach further comprising provisioning at least one new DNS resolution service resource based on the data change.
Assad however in the same field of computer networking teaches further comprising provisioning at least one new DNS resolution service resource based on the data change. (Assad; [0040], otherwise (i.e., new TLD), it passes the registration data to the TLD Farm Server 108 with a request to create the TLD zone file and add the SLD data to it. [0041] In the latter two cases, the TLD Farm Server uses the TLDIP function to compute an IP address from the TLD name. If the request from the Registry Server is to create a new TLD name, the TLD Farm Server 108 selects a server from the group of TLD name servers 110 (e.g., based on historical load or geographical location criteria) and binds the computed TLDIP address to an interface on the selected server, acting in a manner similar to a DHCP server—where a process on the selected server, in communication with the TLD Farm Server, receives the TLDIP address and does the binding. In one embodiment, the TLDIP function is designed to produce a second IP address corresponding to the character string of the TLD name, allowing the TLD Farm Server to bind the second IP address to an interface on a second server possibly belonging to another subnet.)
The same motivation to combine as the dependent claim 3 applies here.
Regarding claim 10, the method of claim 9,
Blinn-Anderson-Hollenbeck do not teach wherein provisioning the at least one new resolution service resource comprises setting up, initializing, or updating at least one DNS server or at least one registration directory service server.
Assad however in the same field of computer networking teaches wherein provisioning the at least one new resolution service resource comprises setting up, initializing, or updating at least one DNS server or at least one registration directory service server. (Assad; [0042], If the writing of the SLD data to the TLD Zone file is successful, the TLD Farm Server 108 updates the TLD Zone Database 116 accordingly, and returns a success response code to the Registry Server 106, which gets relayed eventually to the Registrant 102.)
The same motivation to combine as the dependent claim 3 applies here.
Claim(s) 12 is/are substantially similar to claim 3, and is thus rejected under substantially the same rationale.
Claim(s) 18 is/are substantially similar to claim 9, and is thus rejected under substantially the same rationale.
Claim(s) 19 is/are substantially similar to claim 10, and is thus rejected under substantially the same rationale.
3. Claim 4, 13 and 20-21 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable by Blinn in view of Anderson in view of Hollenbeck further in view of Rechterman (US 20100205302 A1).
Regarding claim 4, the method of claim 2,
Blinn-Anderson-Hollenbeck do not teach wherein the data change comprises a stream of data changes, wherein the transformed version of the data change comprises a transformed stream of data changes, the method further comprising transforming the stream of data changes into the transformed stream of data changes in a format useful for at least one DNS resolution service resource.
Rechterman however in the same field of computer networking teaches wherein the data change comprises a stream of data changes, the method further comprising transforming the stream of data changes into a transformed stream of data changes that is a different format useful for the at least one DNS resolution device. (Rechterman; [0007], once all of the required domain order information was obtained from the customer, the registrar would convert this information to a format that was acceptable to the relevant registry. This process was tedious and was often performed manually or via emails. Thereafter, the registrar would forward the customer's order to the relevant registry for approval. If the person who entered the customer's registration data made any errors (e.g., typographical errors), further delays in the domain registration process would result.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Blinn by incorporating the teachings of Rechterman et al. The motivation/suggestion would have been because there is a need to generating domain name orders from domain registrants in a standardized format, as required by a particular domain name registry. Additionally, the cited references are in the field of communication, as is the current application, and thus, are in analogous arts.
Regarding claim 21, Assad-Hollenbeck the method of claim 2,
Blinn-Anderson-Hollenbeck do no teach wherein the transformed version of the data change is in a format useful for at least one DNS resolution service resource.
Rechterman however in the same field of computer networking teaches wherein the transformed version of the data change is in a format useful for at least one DNS resolution service resource. (Rechterman; [0007], once all of the required domain order information was obtained from the customer, the registrar would convert this information to a format that was acceptable to the relevant registry. This process was tedious and was often performed manually or via emails. Thereafter, the registrar would forward the customer's order to the relevant registry for approval. If the person who entered the customer's registration data made any errors (e.g., typographical errors), further delays in the domain registration process would result.)
The same motivation to combine as the dependent claim 4 applies here.
Regarding claim 22, the method of claim 4,
Blinn-Anderson-Hollenbeck do no teach wherein validating the stream of data changes comprises comparing the transformed stream of data changes with the stream of data changes.
Rechterman however in the same field of computer networking teaches wherein validating the stream of data changes comprises comparing the transformed stream of data changes with the stream of data changes. (Rechterman; [0007], once all of the required domain order information was obtained from the customer, the registrar would convert this information to a format that was acceptable to the relevant registry. This process was tedious and was often performed manually or via emails. Thereafter, the registrar would forward the customer's order to the relevant registry for approval. If the person who entered the customer's registration data made any errors (e.g., typographical errors), further delays in the domain registration process would result.)
The same motivation to combine as the dependent claim 4 applies here.
Claim(s) 13 is/are substantially similar to claim 4, and is thus rejected under substantially the same rationale.
4. Claim 5 and 14 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable by Blinn in view of Anderson in view of Hollenbeck in view of Rechterman further in view of Assad (US 20060218289 A1).
Regarding claim 5, the method of claim 4,
Blinn-Anderson-Hollenbeck-Rechterman do not teach further comprising extracting changes to the DNS registry data stored in the at least one DNS resolution service resource from the stream of data changes.
Assad however in the same field of computer networking teaches further comprising extracting changes to the DNS registry data stored in the at least one DNS resolution service resource from the stream of data changes. (Assad; [0044], registrar server 104 send a query request to TLD zone database to create a domain name. Steps 214, 216, 218, 220 and 222 shows create a TLD domain name and update/store the changed data TLD zone database.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Blinn by incorporating the teachings of Assad. The motivation/suggestion would have been because there is a need to benefit from a DNS system that is scalable to support millions of TLD names, and is unlimited by the limitations of the current system (Assad, [0015]).
Claim(s) 14 is/are substantially similar to claim 5, and is thus rejected under substantially the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571) 272-7304. 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.
/WUJI CHEN/
Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449