Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to amendment filed on 02/06/2026. Claims 1, 8 and 15 have been amended. Claims 1-20 are pending, of which claims, of which claim 1, claim 8 and 15 are in independent form.
Response to Argument
3. Claims 1, 8 and 15 have amended to overcome 112(b). Therefore, 112(b) rejection for claims 1, 8 and 15 have been withdrawn.
4. Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
Status of Claims
5. Claims 1-20 are pending, of which claims, of which claim 1, 8 and 15 are in independent form.
The Office's Note:
6. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon 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 conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
7. Claims 1-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of copending Application No. 18524017. Although the claims at issue are not identical, they are not patentably distinct from each other because both applications teach zero downtime during code deployment and production.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
8. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wagner (US 20180039506– hereinafter Wagner), in view of Siddiqui (US 9,268,663– hereinafter Siddiqui) and further in view of Radermacher(US 20180285097– hereinafter Radermacher).
Claim 1 is rejected, Wagner teaches a computer-implemented method, comprising:
downloading, by a first computing device, code associated with processing requests directed toward a datastore, wherein the code is a new version of code to replace a prior version of code associated with processing requests directed toward the datastore (Wagner, US 20180039506, para [0069], At block 706, the versioning and deployment manager 150 initiates a download of the updated version of the code onto the virtual compute system 110. For example, the versioning and deployment manager 150 cause the updated version of the code to be downloaded onto an internal data store of the virtual compute system 110 (e.g., internal data store 160 of FIG. 1), a code cache on one of the instances (e.g., code cache 158C of FIG. 1), or one or more containers created on the virtual compute system 110. Para [0054-0062], the versioning and deployment manager 150 maintains the internal data store 160 that is used to store data accessed by one or more instances.);
receiving, by the first computing device, a first request directed toward the datastore, wherein the first request is received while downloading the new version of code (Wagner, para [0067], At block 702 of the illustrative routine 700, the versioning and deployment manager 150 receives a code execution request associated a user code. For example, the versioning and deployment manager 150 may receive the request from the frontend 120 after the frontend has performed any initial processing on the request. As discussed above, the request may specify the code to be executed on the virtual compute system 110, and any operating conditions such as the amount of compute power to be used for processing the request, the type of the request (e.g., HTTP vs. a triggered event), the timeout for the request (e.g., threshold time after which the request may be terminated), security policies (e.g., may control which instances in the warming pool 130A are usable by which user), etc. Para [0050-0051], the versioning and deployment manager 150 allows the older version of the code to be used while the new version is being downloaded onto an internal data store, a code cache of a particular instance, and/or a container. Para [0054-0062], the versioning and deployment manager 150 maintains the internal data store 160 that is used to store data accessed by one or more instances);
processing, by the first computing device, the first request directed toward the datastore using the prior version of code while downloading the new version of code (Wagner, para [0070], At block 708, the versioning and deployment manager 150 causes the code execution request associated with the updated version of the code to be processed with an older version of the code that was previously loaded on one of the containers before the code execution request was received at block 702. Para [0050-0051], the versioning and deployment manager 150 allows the older version of the code to be used while the new version is being downloaded onto an internal data store, a code cache of a particular instance, and/or a container.);
switching, by the first computing device, from the prior version of code to the new version of code (Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed.); and
Wagner does not explicitly teach
directing a second request to be processed by a second computing device, wherein the second request is directed toward the datastore to be processed by the second computing device while the first computing device is switching from the prior version of code to the new version of code
However, Siddiqui teaches
directing a second request to be processed by a second computing device, wherein the second request is directed toward the datastore to be processed by the second computing device while the first computing device is switching from the prior version of code to the new version of code (Siddiqui, US 9,268,663, fig. 6 and column 10, line 15 to line 59, At 604, the allocation module 112 may receive a request from a user, such as the user 102. At 606, the allocation module 112 may determine whether the user is a previous user that has been allocated to one of the plurality of versions of software available via the framework 202 (e.g., the version A, the version B, the version N, etc.). Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software. ).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Siddiqui into Wagner to analyze and control software testing. The minimal disruption, delay, or latency are enabled when allocating the users to the versions of software. The controller can easily update the allocation rules dynamically based on data received directly from the metrics analyze as suggested by Siddiqui (See abstract and summary).
Wagner and Siddiqui do not explicitly teach
wherein the new version of code designates one or more data columns of the datastore introduced by the new version of code as optional for requests processed using the prior version of code, such that the prior version of code processes the first request without accessing the one or more data columns, and wherein the one or more data columns are mandatory for requests processed using the new version of code
However, Radermacher teaches
wherein the new version of code designates one or more data columns of the datastore introduced by the new version of code as optional for requests processed using the prior version of code, such that the prior version of code processes the first request without accessing the one or more data columns, and wherein the one or more data columns are mandatory for requests processed using the new version of code(Radermacher, US 20180285097, fig. 1 and para [0026-0028], In the present description, described zero downtime software updates refer generally to any software maintenance, upgrade, or other change to operations of the application 104, including changes to the database system 108, which have a goal of completely avoiding any interruption, or at least any noticeable interruption, to the operations of the application 104. For example, when making structural or content changes to the database tables 110 during an update process, the update engine 104 ensures that such changes are not visible to the application 104, until the changes are confirmed as being complete and correct, at which point the update engine 102 is able to seamlessly switch operations of the application 104 to the resulting, updated database table(s) 110. Fig. 1 and para [0035], A shadow table generator 120 may be configured to generate a shadow table 121 for the (original) table 110. The shadow table may share characteristics of the table 110, while also including additional or alternative structural elements. For example, as described below, the shadow table 121 may include a new column, which may be referred to as a shadow column. The shadow table 121 is invisible to the application 104, and the application 104 may continue to function using the original table 110, while changes to the original table 110 that result from these operations of the application 104 may be reflected in the shadow table 121. Fig. 7 and para [0085], FIG. 7 is a block diagram illustrating example operations associated with deployment of specific update changes being imported. Specifically, a file 702 containing the desired changes is received. As shown, the update engine 402 may be configured to read the contents of the file 702 (704), and may proceed to deploy the read content (706). Fig. 8 and para [0090-0091], FIG. 8 is a block diagram illustrating further example operations of the import operations of FIG. 7. As shown, the update engine 402 may be configured to compute one or more tables requiring modification (802). In the following examples, it is assumed that the table Y414 will require a modified column C, as described in more detail below with respect to FIG. 10, while remaining tables, table X412 and Z416 will remain structurally the same as before the deployment in question. Fig. 10 and para [0095], As shown, the update engine 402 may be configured to modify the table Y 414 to add a shadow column C_SHD 1004 (1001). The update engine 402 may be further configured to create a trigger 1006 to replicate data from a corresponding column C to the newly-created shadow column C_SHD 1004, while modifying content (1002). In this way, content may be copied from the original column C to the shadow column C_SHD 1004 while modifying content (1003). As may be understood from the above description, the target column 1004 will be invisible to the executing application of the server 404, until after the import and deployment processes are complete.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Radermacher into Wagner and Siddiqui to enable allowing an update engine to be installed and designed for permanent or semi-permanent setup within the system, thus allowing faster deployment times during imports of updates and shorter runtimes of the updates. The product enables improving robust performance, as any errors are corrected and/or revoked in an automated fashion with high degree of success, so that the software can continue executing regardless of outcome of update procedures. The product enables generating the shadow table partially during preparation phase that occurs prior to actual generations of the bridge schema and the bridge view depending on the type of update change and/or type of database table so as to minimize time needed for deploying the update change as suggested by Radermacher (See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Wagner, Siddiqui and Radermacher teach the computer-implemented method of claim 1, further comprising processing, by the first computing device, a third request directed toward the datastore using the new version of code after switching from the prior version of code to the new version of code has completed (Siddiqui, fig. 6 and column 10, line 15 to line 59, At 604, the allocation module 112 may receive a request from a user, such as the user 102. At 606, the allocation module 112 may determine whether the user is a previous user that has been allocated to one of the plurality of versions of software available via the framework 202 (e.g., the version A, the version B, the version N, etc.).) .
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Wagner, Siddiqui and Radermacher teach the computer-implemented method of claim 1 further comprising validating the new version of code for a first plurality of nodes serviced by the first computing device, wherein the second computing device services a second plurality of nodes(Siddiqui, column 8, line 61 to column 9 line 6, At 412, the metrics analyzer 118 may measure system performance and/or results of user interaction. For example, the metrics analyzer 118 may extract an output of the version of software assigned at the operation 408, including a measurement of system resources for the execution of the version (or approximation based on batch processes of many uses of the version). At 414, the metrics analyzer 118 may aggregate the measure data from the user and other users. The measured data may include use results and/or system performance data. The aggregation may be performed on a one by one basis or via batch processing at intervals (e.g., predetermined, periodic, random, etc.). Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software. ).
Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Wagner, Siddiqui and Radermacher teach the computer-implemented method of claim 3, wherein validating the new version of code for the first plurality of nodes serviced by the first computing device includes monitoring at least one of a log, an application status, and live traffic (Siddiqui, column 8, line 61 to column 9 line 6, At 412, the metrics analyzer 118 may measure system performance and/or results of user interaction. For example, the metrics analyzer 118 may extract an output of the version of software assigned at the operation 408, including a measurement of system resources for the execution of the version (or approximation based on batch processes of many uses of the version). At 414, the metrics analyzer 118 may aggregate the measure data from the user and other users. The measured data may include use results and/or system performance data. The aggregation may be performed on a one by one basis or via batch processing at intervals (e.g., predetermined, periodic, random, etc.).).
Claim 5 is rejected for the reasons set forth hereinabove for claim 3, Wagner, Siddiqui and Radermacher teach the computer-implemented method of claim 3, further comprising shutting down the second computing device based upon, at least in part, a successful validation of the new version of code for the first plurality of nodes serviced by the first computing device(Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed. Siddiqui, Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software. ).
Claim 6 is rejected for the reasons set forth hereinabove for claim 5, Wagner, Siddiqui and Radermacher teach the computer-implemented method of claim 5, wherein shutting down the second computing device includes servicing the second plurality of nodes to process a fourth request directed toward the datastore using the new version of code(Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed. Siddiqui, Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software.).
Claim 7 is rejected for the reasons set forth hereinabove for claim 6, Wagner, Siddiqui and Radermacher teach the computer-implemented method of claim 6, further comprising deploying the new version of code to the second computing device(Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed. Siddiqui, column 9, line 25 to line 40, the version B may be an updated version of the software used in the version A or both the version A and the version B may be new software subjected to a comparison test. Siddiqui, Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software.).
As per claim 8, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 9, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 10, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 11, this is the medium claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the medium claim to method claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the medium claim to method claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the medium claim to method claim 7. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the medium claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the medium claim to method claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the medium claim to method claim 6. Therefore, it is rejected for the same reasons as above.
Conclustion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached on 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199