Prosecution Insights
Last updated: October 02, 2026
Application No. 17/328,296

BULK MANAGEMENT OF REGISTRY OBJECTS

Non-Final OA §103§DOUBLEPATENT
Filed
May 24, 2021
Priority
Apr 27, 2012 — provisional 61/639,751 +3 more
Examiner
HOANG, KEN
Art Unit
2168
Tech Center
2100 — Computer Architecture & Software
Assignee
Verisign Inc.
OA Round
5 (Non-Final)
72%
Grant Probability
Favorable
5-6
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 72% — above average
72%
Career Allowance Rate
287 granted / 396 resolved
+17.5% vs TC avg
Strong +31% interview lift
Without
With
+31.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
15 currently pending
Career history
424
Total Applications
across all art units

Statute-Specific Performance

§101
12.3%
-27.7% vs TC avg
§103
68.1%
+28.1% vs TC avg
§102
6.7%
-33.3% vs TC avg
§112
7.0%
-33.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 396 resolved cases

Office Action

§103 §DOUBLEPATENT
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application is being examined under the pre-AIA first to invent provisions. 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 05/05/2026 has been entered Response to Arguments Applicant’s amendments to the Abstract, Specification and claims have overcome each and every objection and 101 rejections previously set forth in the Non-Final Office Action mailed 11/01/2013. Applicant’s arguments with respect to claims 2, 12 and 22 have been considered but are moot in view of the new ground(s) of rejection (See new reference MacCarthaigh). Examiner Notes (1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121 (b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131 (b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as "Applicants believe no new matter has been introduced" may be deemed insufficient. (2) Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. 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 claims at issue 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 Langi, 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); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR l.321(c) or l.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this 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 §§ 706.02(1)(1) - 706.02(1)(3) 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 l.321(b). The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTDi nfo-1.jsp. At least claims 2, 12 and 22 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 16/106,624, claims 1-20 of U.S. Patent No. 15/657,973 and claims 1-8, 10-18 and 20-22 of U.S Patent No. 13871440. Although the conflicting claims are not identical, they are not patentably distinct from each other because the claimed features of the claims 1-20 of U.S. Patent No. U.S. Patent No. 16/106,624 can also be interpreted as claimed features as claimed in the claims 2, 12 and 22 of the present application. Further, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims U.S. Patent No. U.S. Patent No. 16/106,624 to arrive at the claim 1 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals. Specifically, the claim 2 recites " a computer-implemented method of managing a plurality of jobs stored in a registry database of a registry, the method comprising: accessing, by a bulk processing engine, a job of the plurality of jobs stored in the registry database; identifying, by the bulk processing engine, a use case associated with the job, wherein the use case indicates a bulk operation to be performed on information stored in the registry database, wherein the information is associated with a set of domain names for the job, wherein a priority level is determined based on the use case; and identifying, by the bulk processing engine, one or more policies associated with the bulk operation and determining that one or more domain names of the set of domain names is subject to the one or more policies on domain names of the set of domain names for the job, wherein the bulk operation is performed by the registry based on the use case and the one or more policies on domain names of the set of domain names for the job". The claimed features are anticipated by claim 1 of the U.S. Patent No. 16/106,624 as follow "" A method of managing a domain name system, comprising: receiving a request for bulk modification of a set of records, wherein the set of records corresponds to registry objects managed by at least one registrar; designating, by a registry for the registry objects, a use case for the request for bulk modification, wherein the use case indicates that each modification of a plurality of modifications in the request for bulk modification is associated with a same type of action; accessing an electronically stored set of registry policies; and executing, using a processor, the bulk modification for at least a subset of records of the set of records according to at least the use case and the set of registry policies". It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims 1-20 of U.S. Patent No. 16/106,624 to arrive at the claim 2 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals. Similar analysis is applied in regards claims 1-20 of U.S. Patent No. 15/657,973 and claims 1-8, 10-18 and 20-22 of U.S Patent No. 13871440. 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 2, 5, 7, 9-10, 12, 15, 17, 19-20, 22, 25, 27, 29-30 and 36 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1). Regarding claim 2, Hollenbeck disclose a computer-implemented method of managing a plurality of jobs stored in registry database of a registry, the method comprising: accessing, by a bulk processing engine, a job of the plurality of jobs stored in the registry database (col. 7, line 59-64, col. 8, line 28-47, running number of batch processes that may be run on prescheduled basis using a cron-like scheduler; registration database may store the various information in the form of one or more relational tables, when execution of RRP command or batch process results in a change in registry database, these tables may be altered, noted running batch process based on schedule, which is interpreted as accessing, by a bulk processing engine, a job of the plurality of jobs stored in the registry database); Hollenbeck does not explicitly disclose: identifying, by the bulk processing engine, a use case associated with the job, wherein the use case indicates a bulk operation to be performed on information stored in the registry database, wherein the information is associated with a set of domain names for the job; identifying, by the bulk processing engine, one or more policies associated with the bulk operation and determining that one or more domain names of the set of domain names is subject to the one or more policies on domain names of the set of domain names for the job, wherein the bulk operation is performed by the registry based on the use case and the one or more policies on domain names of the set of domain names for the job. MacCarthaigh teaches: identifying, by the bulk processing engine, a use case associated with the job, wherein the use case indicates a bulk operation to be performed on information stored in the registry database, wherein the information is associated with a set of domain names for the job (paragraph [0021], indicating an update to DNS record or set of records; such as an update may comprises for example, creating one or more new records, deleting one or more existing records, or modifying the content of one or more existing records; as one non-limiting example, the domain owner may change the IP address range associated with a particular domain name; also see paragraph [0023], a request to update may describe the record as “all mail server records” and the change to be made as “delete”; all update requests pertain to records associated with the authenticated domain owner; therefore, the update request “delete all mail server records” implicitly applies only to those mail server records associated with the domain owner; also see paragraph [0025], update validation service determine whether the request change to an identifier field (e.g., IP address field, domain name field) of the DNS record would violate the condition in an update policy); identifying, by the bulk processing engine, one or more policies associated with the bulk operation and determining that one or more domain names of the set of domain names is subject to the one or more policies on domain names of the set of domain names for the job, wherein the bulk operation is performed by the registry based on the use case and the one or more policies on domain names of the set of domain names for the job (paragraph [0021], indicating an update to DNS record or set of records; such as an update may comprises for example, creating one or more new records, deleting one or more existing records, or modifying the content of one or more existing records; as one non-limiting example, the domain owner may change the IP address range associated with a particular domain name; also see paragraph [0023], a request to update may describe the record as “all mail server records” and the change to be made as “delete”; all update requests pertain to records associated with the authenticated domain owner; therefore, the update request “delete all mail server records” implicitly applies only to those mail server records associated with the domain owner; paragraph [0025], The DNS update validation validates the DNS update request by applying one or more appropriate update policies stored in the update policy data store; update validation service determine whether the request change to an identifier field (e.g., IP address field, domain name field) of the DNS record would violate the condition in an update policy). It would have been obvious to one of ordinary skill in art at the time of the invention was made to include identifying, by the bulk processing engine, a use case associated with the job, wherein the use case indicates a bulk operation to be performed on information stored in the registry database, wherein the information is associated with a set of domain names for the job; identifying, by the bulk processing engine, one or more policies associated with the bulk operation and determining that one or more domain names of the set of domain names is subject to the one or more policies on domain names of the set of domain names for the job, wherein the bulk operation is performed by the registry based on the use case and the one or more policies on domain names of the set of domain names for the job into domain management of Hollenbeck. Motivation to do so would be to include identifying, by the bulk processing engine, a use case associated with the job, wherein the use case indicates a bulk operation to be performed on information stored in the registry database, wherein the information is associated with a set of domain names for the job; identifying, by the bulk processing engine, one or more policies associated with the bulk operation and determining that one or more domain names of the set of domain names is subject to the one or more policies on domain names of the set of domain names for the job, wherein the bulk operation is performed by the registry based on the use case and the one or more policies on domain names of the set of domain names for the job to reduce the threat of domain jacking by preventing updates to DNS records when an update does not conform to a policy (MacCarthaigh, paragraph [0007], line 3-5). Hollenbeck as modified by MacCarthaigh does not explicitly disclose: Hegde teaches: wherein a priority level is determined based on the use case (paragraph, [0039], assigning a high priority to certain requests, and a low priority to others; for example, if a client data processing system need an immediate domain name translation to process a business transaction, the client data processing include data in the tag to indicate that the process has a high priority; on the other hand, if the client data system is processing a command to gather a vast number of IP address, and time to complete the command is less of a problem, then each request for translation may contain a tag that places the request at a lower priority; noted, “an immediate domain name translation to process a business transaction” is tagged with data indication of high priority while “processing a command to gather a vast number of IP address” is tagged with data indication of low priority, which reads on wherein a priority level is determined based on the use case as claimed). It would have been obvious to one of ordinary skill in art at the time of the invention was made to include wherein a priority level is determined based on the use case into domain management of Hollenbeck. Motivation to do so would be to include wherein a priority level is determined based on the use case to have a method, data processing system, and computer-implemented instructions for managing requests for domain name translations (Hegde, paragraph [0007], line 14-16). Hollenbeck as modified by MacCarthaigh and Hegde further teach: wherein the bulk operation is performed by the registry based on the use case and the one or more policies on domain names of the set of domain names for the job (MacCarthaigh, paragraph [0021], teaches indicating an update to DNS record or set of records; such as an update may comprises for example, creating one or more new records, deleting one or more existing records, or modifying the content of one or more existing records; as one non-limiting example, the domain owner may change the IP address range associated with a particular domain name; also see paragraph [0023], a request to update may describe the record as “all mail server records” and the change to be made as “delete”; all update requests pertain to records associated with the authenticated domain owner; therefore, the update request “delete all mail server records” implicitly applies only to those mail server records associated with the domain owner; paragraph [0025], The DNS update validation validates the DNS update request by applying one or more appropriate update policies stored in the update policy data store; update validation service determine whether the request change to an identifier field (e.g., IP address field, domain name field) of the DNS record would violate the condition in an update policy; also see paragraph [0034]-[0035], the DNS update validation determines that the condition in the matching update policy would not be violated, the DNS update validation service move to box 212; in box 212, the DNS update validation service updates the DNS record in accordance with the update request; while Hegde, paragraph [0035], [0039], [0047], assigned to a source group according to many other types of selection factors,…whether the request is a part of batch of similar requests, and other factor…assigning a high priority to certain requests, and a low priority to others; for example, if a client data processing system need an immediate domain name translation to process a business transaction, the client data processing include data in the tag to indicate that the process has a high priority; on the other hand, if the client data system is processing a command to gather a vast number of IP address, and time to complete the command is less of a problem, then each request for translation may contain a tag that places the request at a lower priority; processes the request according to a determined priority; and Hollenbeck, col. 7, line 59-64 and col. 18, line 29-35, col. 19, line 5-10, teaches scheduling the execution of record modification in domain registry, which satisfy the set of registry policies; executing the transaction according to priority level, it reads on wherein the bulk operation is performed by the registry based on the use case and the one or more policies as claimed). Regarding claim 5, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, further teach wherein the bulk operation performed by the registry comprises: determining, by the bulk processing engine, that the priority level associated with the use case indicates a high priority (Hegde, [0039], assigning a high priority to certain requests, and a low priority to others; for example, if a client data processing system need an immediate domain name translation to process a business transaction, the client data processing include data in the tag to indicate that the process has a high priority; on the other hand, if the client data system is processing a command to gather a vast number of IP address, and time to complete the command is less of a problem, then each request for translation may contain a tag that places the request at a lower priority); and performing, by the bulk processing engine, the bulk operation indicated by the use case (Hegde, paragraph [0035], [0039], [0047], assigned to a source group according to many other types of selection factors,…whether the request is a part of batch of similar requests, and other factor…assigning a high priority to certain requests, and a low priority to others; for example, if a client data processing system need an immediate domain name translation to process a business transaction, the client data processing include data in the tag to indicate that the process has a high priority; on the other hand, if the client data system is processing a command to gather a vast number of IP address, and time to complete the command is less of a problem, then each request for translation may contain a tag that places the request at a lower priority; processes the request according to a determined priority; in combination of the teaching of Hollenbeck, col. 7, line 59-64 and col. 18, line 29-31, col. 19, line 5-10, scheduling the execution of record modification in domain registry, which satisfy the set of registry policies; executing the transaction according to priority level, it teaches as claimed). Regarding claim 7, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, further teach wherein at least one policy of the one or more policies is a security policy (Hollenbeck, col. 18, line 15-35 and line 51-57, col. 24, line 51-60, sending a RRP command for updating existing domain; application server next makes a determination whether or not the registrar that send the RRP command is authorized to perform the action that results from the RRP command, for example, a registrar may not be authorized to perform a particular action if the registrar do not own the domain referred in the RRP command, if the registrar is determined not to be authorized, then a response may be sent back to the registrar providing an indication to that effect), wherein, based on the use case and the one or more policies, the bulk operation is performed on information associated with at least a subset of domain names of the set of domain names stored in the registry database (Hollenbeck, col. 18, line 15-35 and line 51-57, col. 24, line 51-60, sending a RRP command for updating existing domain; application server next makes a determination whether or not the registrar that send the RRP command is authorized to perform the action that results from the RRP command, for example, a registrar may not be authorized to perform a particular action if the registrar do not own the domain referred in the RRP command, if the registrar is determined not to be authorized, then a response may be sent back to the registrar providing an indication to that effect; if the registrar is determined to be authorized, then the RRP application applied business rules to the RRP command; business rules may exist to check and set a variety of attributes to ensure that all RRP commands are executed according to registry policy; executing any changes necessary by the RRP command; updating a registered domain name must contain following data, the entity name attribute set to the value ‘domain,’ and a fully qualified domain name in the domain name attribute; the registrar may perform the following update operations on the domain name: update the name server of the domain name, update the status of the domain name; in combination with baches of request for domain translation operation based on user cases and priorities as taught by Hegde, paragraph [0035], [0039], [0047], assigned to a source group according to many other types of selection factors,…whether the request is a part of batch of similar requests, and other factor…assigning a high priority to certain requests, and a low priority to others; for example, if a client data processing system need an immediate domain name translation to process a business transaction, the client data processing include data in the tag to indicate that the process has a high priority; on the other hand, if the client data system is processing a command to gather a vast number of IP address, and time to complete the command is less of a problem, then each request for translation may contain a tag that places the request at a lower priority; processes the request according to a determined priority, and MacCarthaigh, paragraph [0025], teaches The DNS update validation validates the DNS update request by applying one or more appropriate update policies stored in the update policy data store; update validation service determine whether the request change to an identifier field (e.g., IP address field, domain name field) of the DNS record would violate the condition in an update policy; also see paragraph [0034]-[0035], the DNS update validation determines that the condition in the matching update policy would not be violated, the DNS update validation service move to box 212; in box 212, the DNS update validation service updates the DNS record in accordance with the update request, it teaches as claimed). Regarding claim 9, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, further teach: tracking, by a report handler of the bulk processing engine, the operation to identify one or more modifications to the information associated with the set of domain names; generating, by the report handler, a report indicating the one or more modifications; and sending, by the report handler, the report via a bulk management interface (Hollenbeck, col. 10, line 4-19, producing reports, registrar reporting unit periodically extracts data relevant to various type of reports from registry databases; generating set of reports using the extracted data; sending the reports to the relevant registrar). Regarding claim 10, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, further teach wherein causing the operation to be performed comprises at least one of: modifying, by the bulk processing engine, an expiration date of the set of domain names; or transferring, by the bulk processing engine, a registration of the set of domain names from a first registrant to a second registrant (Hollenbeck, col. 26, line 45-67, col. 27, line 1-21, transferring domain between registrant). As per claims 12 and 22, these claims are rejected on grounds corresponding to the rationales given above for rejected claim 2 and are similarly rejected. As per claims 15 and 25, these claims are rejected on grounds corresponding to the rationales given above for rejected claim 5 and are similarly rejected. As per claims 17 and 27, these claims are rejected on grounds corresponding to the rationales given above for rejected claim 7 and are similarly rejected. As per claims 19-20, these claims are rejected on grounds corresponding to the rationales given above for rejected claims 9-10 respectively and are similarly rejected. As per claims 29-30, these claims are rejected on grounds corresponding to the rationales given above for rejected claims 9-10 respectively and are similarly rejected. Regarding claim 36, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, further teach wherein operations of a plurality of operations in the bulk operation are associated with a same type of action (MacCarthaigh, paragraph [0021], indicating an update to DNS record or set of records; such as an update may comprises for example, creating one or more new records, deleting one or more existing records, or modifying the content of one or more existing records; as one non-limiting example, the domain owner may change the IP address range associated with a particular domain name; also see paragraph [0023], a request to update may describe the record as “all mail server records” and the change to be made as “delete”; all update requests pertain to records associated with the authenticated domain owner; therefore, the update request “delete all mail server records” implicitly applies only to those mail server records associated with the domain owner). Claims 3-4, 13-14 and 23-24 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1), further in view of Kindel et al. (U.S. Pub. No. 2009/0183162 A1). Regarding claim 3, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, do not explicitly disclose: wherein the bulk operation performed by the registry comprises: identifying, by the bulk processing engine, a time interval at which the bulk operation is not be performed on the priority level; determining by the bulk processing engine, that a current is within the time interval, and in response to determine that the current time is within the time interval, refraining, by the bulk processing engine, from performing the bulk operation while the current time is within the time interval; and performing, by the bulk processing engine, the bulk operation indicated by the additional use case when the current time is no longer within the time interval. Kindel teaches: identifying, by the bulk processing engine, a time interval at which the bulk operation is not be performed on the priority level (paragraph [0062], [0068], a server may have several tasks of a high priority to execute at night time window; time window is regulated when tasks may be performed); determining by the bulk processing engine, that a current is within the time interval, and in response to determine that the current time is within the time interval, refraining, by the bulk processing engine, from performing the bulk operation while the current time is within the time interval; and performing, by the bulk processing engine, the bulk operation indicated by the use case when the current time is no longer within the time interval (paragraph [0044], [0062], [0068], operating in conjunction with a predetermined time to permit or curtain tasks; the server may have several task of a high priority to execute at night time window; pausing the task based on priority; the incomplete may be reevaluated, and resumed at a later time; if a high level of disk activity is going on, the defragmentation task may be started at later time). Hollenbeck and Kindel are analogous art since they are in the same field of endeavor: data modification based on priorities, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include identifying, by the bulk processing engine, a time interval at which the bulk operation is not be performed on the priority level; determining by the bulk processing engine, that a current is within the time interval, and in response to determine that the current time is within the time interval, refraining, by the bulk processing engine, from performing the bulk operation while the current time is within the time interval; and performing, by the bulk processing engine, the bulk operation indicated by the additional use case when the current time is no longer within the time interval into data modification of Hollenbeck. The motivation/suggestion for scheduling and execute tasks during a rigid and flexible periodic window; many tasks may be pausable and resumable based on priorities (Kindel, paragraph [0002], [0068]). Regarding claim 4, Hollenbeck as modified by MacCarthaigh, Hegde and Kindel teach all claimed limitations as set forth in rejection of claim 3, further teach selecting, by the bulk processing engine, an additional job of the plurality of jobs while the current time is within the time interval, the additional job associated with an additional use case, the additional use case indicating an additional operation to be performed; identifying, by the bulk processing engine, an additional priority level associated with the additional use case; and performing, by the bulk processing engine, the additional operation indicated by the additional use case (Kindel, paragraph [0028], [0044], [0062], [0068], operating in conjunction with a predetermined time to permit or curtain tasks; the server may have several task of a high priority to execute at night time window; analyzing each task and determine a priority for a task as well as organize the tasks to be executed pausing the task based on priority; the incomplete may be reevaluated, and resumed at a later time; if a high level of disk activity is going on, the defragmentation task may be started at later time). As per claims 13-14, these claims are rejected on grounds corresponding to the rationales given above for rejected claims 3-4 respectively and are similarly rejected. As per claims 23-24, these claims are rejected on grounds corresponding to the rationales given above for rejected claims 3-4 respectively and are similarly rejected. Claims 6, 16 and 26 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1), further in view of Malik et al. (U.S. Pub. No. 2003/0033461 A1). Regarding claim 6, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, but do not explicitly disclose: wherein receiving, by the bulk processing engine, a plurality of updates indicating at least one of: a new use case associated with a new priority level, wherein the new use case and the new priority level are stored in the registry database; a deleted use case removed from the registry database; and/or a modified use case associated with a modified priority level, wherein the modified use case and the modified priority level are stored in the registry database. Malik teaches: wherein receiving, by the bulk processing engine, a plurality of updates indicating at least one of: a new use case associated with a new priority level, wherein the new use case and the new priority level are stored in the registry database; a deleted use case removed from the registry database; and/or a modified use case associated with a modified priority level, wherein the modified use case and the modified priority level are stored in the registry database (paragraph [0017], “where control registered 70 are again used to determine priority. If the user has programmed control registers to select read request as having priority over the write buffer request, then the flow continue from decision diamond 220 to step 215 where a memory access for the read request is performed”, noted, “write buffer request” is interpreted as modified use case; and priority of write request [in comparison to priority of read request] is interpreted as the modified priority level). It would have been obvious to one of ordinary skill in art at the time of the invention was made to include wherein receiving, by the bulk processing engine, a plurality of updates indicating at least one of: a new use case associated with a new priority level, wherein the new use case and the new priority level are stored in the registry database; a deleted use case removed from the registry database; and/or a modified use case associated with a modified priority level, wherein the modified use case and the modified priority level are stored in the registry database into domain management of Hollenbeck. Motivation to do so would be to include wherein receiving, by the bulk processing engine, a plurality of updates indicating at least one of: a new use case associated with a new priority level, wherein the new use case and the new priority level are stored in the registry database; a deleted use case removed from the registry database; and/or a modified use case associated with a modified priority level, wherein the modified use case and the modified priority level are stored in the registry database such that it thus desirable to more efficiently prioritize multiple requests to the main memory (Malik, paragraph [0002], line 17-18). As per claims 16 and 26, these claims are rejected on grounds corresponding to the rationales given above for rejected claim 6 and are similarly rejected. Claims 8, 18 and 28 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1), further in view of Goldstein et al. (U.S. Patent No. 7,174,363 B1). Regarding claim 8, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, but do not explicitly disclose wherein causing the operation to be performed comprises: performing, by a job processor of the bulk processing engine, the bulk operation indicated by the use case, wherein the job processor is configured to operate asynchronously from other operations of the registry. Goldstein teaches wherein causing the operation to be performed comprises: performing, by a job processor of the bulk processing engine, the bulk operation indicated by the use case, wherein the job processor is configured to operate asynchronously from other operations of the registry (stream comprise a sequence of data flows, with no header information, a stream differs from a message in that a message typically encapsulates a single piece of information, a stream encapsulates many such pieces, which need not necessarily be homogenous, col. 6, line 50-54; streams are used for processing data in bulk, rather than generating a set of independent messages, the stream allows a bulk transfer of data, col. 7, line 4-5 and 13-15; in conjunction with batch processing of registry record modification taught by Hollenbeck, which is read on wherein causing the operation to be performed comprises: wherein causing the operation to be performed comprises: performing, by a job processor of the bulk processing engine, the bulk operation indicated by the use case, wherein the job processor is configured to operate asynchronously from other operations of the registry as claimed). It would have been obvious to one of ordinary skill in art at the time of the invention was made to include wherein causing the operation to be performed comprises: performing, by a job processor of the bulk processing engine, the bulk operation indicated by the use case, wherein the job processor is configured to operate asynchronously from other operations of the registry into domain management of Hollenbeck. Motivation to do so would be to include wherein causing the operation to be performed comprises: performing, by a job processor of the bulk processing engine, the bulk operation indicated by the use case, wherein the job processor is configured to operate asynchronously from other operations of the registry which significantly reduce overhead (Goldstein. Col. 7, line 15). As per claims 18 and 28, these claims are rejected on grounds corresponding to the rationales given above for rejected claim 8 and are similarly rejected. Claims 11, 21 and 31 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1), further in view of Nair et al. (U.S. Pub. No. 2007/0214167 A1). Regarding claim 11, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, but do not explicitly disclose wherein accessing the job of the plurality of jobs stored in the registry database comprises: polling, by the bulk processing engine, a queue of the registry database, wherein the queue is configured to store the plurality of jobs. Nair teaches: wherein accessing the job of the plurality of jobs stored in the registry database comprises: polling, by the bulk processing engine, a queue of the registry database, wherein the queue is configured to store the plurality of jobs (paragraph [0041], [0053], request is scheduled in the Work Queue, this request then picked up by one of the available worker which is managed by worker thread manager, and the worker thread that pick up the requests acts on that request; the execution on a first in/first out basis). Hollenbeck and Nair are analogous art since they are in the same field of endeavor: data modification, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include responsive to receiving the confirmation input, sending the content to the first device into data modification of Hollenbeck. The motivation/suggestion allowing accessing the requests organized in the queue structure, which is first in/ first out basis. As per claims 21 and 31, these claims are rejected on grounds corresponding to the rationales given above for rejected claim 11 and are similarly rejected. Claim 32 is rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1), further in view of Pujol et al. (U.S. Pub. No. 2005/0204048 A1). Regarding claim 32, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, do not explicitly disclose: wherein the use case comprises a unique set of parameters and built-in validation for the bulk operation. Pujol teaches: wherein the use case comprises a unique set of parameters and built-in validation for the bulk operation (table 11-12 illustrates Use case parameters, a table mapping App calls to validate, ancillary and Submit; Bulk transfer…; also see paragraph [0159], In: a self-describing data schema contain a list of input parameter names, parameter data type, and parameter values; also see paragraph [0174]). Hollenbeck and Pujol are analogous art since they are in the same field of endeavor: bulk data operation, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include wherein the use case comprises a unique set of parameters and built-in validation for the bulk operation to overcome issue with various technologies often have tight coupling to individual channels and systems, making adaptation to change progressively difficult (Pujol, paragraph [0007]). Claim 33 is rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1), further in view of King et al. (U.S. Patent No. 8,015,244 B2). Regarding claim 33, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, do not explicitly disclose: wherein one or more changes to the registry database are pushed to a resolution service. King teaches: wherein one or more changes to the registry database are pushed to a resolution service (col. 14, line 31-40, real time events that is communicated through push, pull, or other communication strategies with domain registrars and registries; both RRP events and domain names updated in Registrars WHOIS servers can be processed). Hollenbeck and King are analogous art since they are in the same field of endeavor: Domain registration service, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include wherein one or more changes to the registry database are pushed to a resolution service to provide an efficient, organized and reliable method for tracking, acquiring, and protecting internet identification resources (King, col. 1, line 54-56). Claims 34-35 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hollenbeck et al. (U.S. Patent No. 7,299,299 B2) in view of MacCarthaigh (U.S. Pub. No. 2012/0017259 A1) and Hegde et al. (U.S. Pub. No. 2006/0242321 A1), further in view of Majumdar et al. (U.S. Pub. No. 2007/0204038 A1). Regarding claim 34, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, but do not explicitly disclose determining, by the bulk processing engine, not to execute the bulk operation on the one or more domain names that are subject to the one or more policies. Majumdar teaches: determining, by the bulk processing engine, not to execute the bulk operation on the one or more domain names that are subject to the one or more policies (paragraph [0030], if the global name zone does already have a record for the host name, then the record type of the domain name registration or update is determined; at 630, the record type of the domain name registration or update is compared with the record type of the record for the host name stored in the global names zone; if the record types match, then at 640, the registration or update is rejected; in combination with the mass processes regarding domain update/transferring taught by Hollenbeck (Hollenbeck, col. 7, line 59-64 and col. 18, line 29-31, running number of batch processes that may be run on prescheduled basis using a cron-like scheduler ; scheduling the execution of record modification in domain registry, which satisfy the set of registry policies), it teaches as claimed). Hollenbeck and Majumdar are analogous art since they are in the same field of endeavor: domain registration/update, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include determining, by the bulk processing engine, not to execute the bulk operation on the one or more domain names that are subject to the one or more policies into data modification of Hollenbeck. The motivation/suggestion to address issue with host name to be resolved globally across multiple domain and zone boundaries, a machine has to register in all the domains, which greatly increases administration complexity (Majumdar, paragraph [0003]). Regarding claim 35, Hollenbeck as modified by MacCarthaigh and Hegde teach all claimed limitations as set forth in rejection of claim 2, further teach: modifying or updating, by the bulk processing engine, the one or more domain names of the set of domain names that are subject to the one or more policies (Hollenbeck, col. 7, line 59-64 and col. 18, line 29-31, running number of batch processes that may be run on prescheduled basis using a cron-like scheduler ; scheduling the execution of record modification in domain registry, which satisfy the set of registry policies; also see “receiving information that corresponds to a domain name in the case that a registrar sends a RRP command for updating an existing domain” (col. 18, line 12-16). Hollenbeck also indicate “a registrar may not be authorized to perform a particular action if the registrar does not own the domain referred to in the RRP command” (col. 18, line 23-25). Also, Hollenbeck teaches that “business rules may exist to check and set a variety of attributes to ensure that all the RRP command are executed according to the registry policy; there may be rules for checking the credit of the registrar,…, a rule for checking the domain status,…. Each RRP command may have a different set of business rules that are applied when the RRP command is executed (e.g., a RRP command adding a domain name has a different set of rules than an RRP command transferring a domain name)” (Hollenbeck, col. 18, line 33-58)) but do not explicitly disclose: declining to modify or update, by the bulk processing engine, remaining domain names of the set of domain names that are not subject to the one or more policies. Majumdar teaches: declining to modify or update, by the bulk processing engine, remaining domain names of the set of domain names that are not subject to the one or more policies (paragraph [0030], if the global name zone does already have a record for the host name, then the record type of the domain name registration or update is determined; at 630, the record type of the domain name registration or update is compared with the record type of the record for the host name stored in the global names zone; if the record types match, then at 640, the registration or update is rejected; in combination with the mass processes regarding domain update/transferring taught by Hollenbeck (Hollenbeck, col. 7, line 59-64 and col. 18, line 29-31, running number of batch processes that may be run on prescheduled basis using a cron-like scheduler ; scheduling the execution of record modification in domain registry, which satisfy the set of registry policies), it teaches as claimed). Hollenbeck and Majumdar are analogous art since they are in the same field of endeavor: domain registration/update, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include declining to modify or update, by the bulk processing engine, remaining domain names of the set of domain names that are not subject to the one or more policies into data modification of Hollenbeck. The motivation/suggestion to address issue with host name to be resolved globally across multiple domain and zone boundaries, a machine has to register in all the domains, which greatly increases administration complexity (Majumdar, paragraph [0003]). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEN HOANG whose telephone number is (571)272-8401. The examiner can normally be reached M-F 7:30am-5:00pm. 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, Charles Rones can be reached at (571)272-4085. 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. /KEN HOANG/ Examiner, Art Unit 2168
Read full office action

Prosecution Timeline

Show 14 earlier events
May 08, 2025
Final Rejection mailed — §103, §DOUBLEPATENT
Sep 05, 2025
Response after Non-Final Action
Nov 06, 2025
Notice of Allowance
Nov 06, 2025
Response after Non-Final Action
Dec 04, 2025
Response after Non-Final Action
May 05, 2026
Request for Continued Examination
May 06, 2026
Response after Non-Final Action
Sep 01, 2026
Non-Final Rejection mailed — §103, §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12650681
CLOUD-BASED DATA RECORDER AND EVENT PROCESSOR
4y 6m to grant Granted Jun 09, 2026
Patent 12625848
MESH NETWORK SYSTEM OF ENVIRONMENTAL MONITORING DEVICES
3y 6m to grant Granted May 12, 2026
Patent 12596751
IMAGE SYNTHESIS BASED ON PREDICTIVE ANALYTICS
4y 3m to grant Granted Apr 07, 2026
Patent 12579118
SYSTEM AND METHODS FOR AUTOMATED STANDARDIZATION OF HETEROGENEOUS DATA USING MACHINE LEARNING
1y 3m to grant Granted Mar 17, 2026
Patent 12531138
PARAMETERIZED TEMPLATE FOR CLINICAL RESEARCH STUDY SYSTEMS
4y 6m to grant Granted Jan 20, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

5-6
Expected OA Rounds
72%
Grant Probability
99%
With Interview (+31.1%)
3y 1m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 396 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month