Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101.
Claims 10 and 20 is/are rejected under 35 U.S.C. 101 as claiming the same invention as that of claims 6 and 18 of prior U.S. Patent No. 12,273,245. This is a statutory double patenting rejection.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 10,715,403. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are substantially within the scope of claims 1-20 of ‘403, and thus are deemed to be an obvious variation.
Double Patenting
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-14 of U.S. Patent No. 11,252,050. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are substantially within the scope of claims 1-20 of ‘050, and thus are deemed to be an obvious variation.
Double Patenting
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-14 of U.S. Patent No. 11,722,385. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are substantially within the scope of claims 1-20 of ‘050, and thus are deemed to be an obvious variation.
Double Patenting
Claims 1-9 and 11-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 8-12, 13-15, and 18-20 of U.S. Patent No. 12,273,245. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are fully within the scope of the claims of ‘245.
Claims 1 and 11 are fully within the scope of claims 7 and 18 of ‘245.
Claims 2 and 12 introduce subject matter provided by claims 2 and 14 of ‘245.
Claims 3-4 and 13-14 introduce subject matter provided by claims 3 and 15 of ‘245.
Claims 5 and 15 introduce subject matter provided by claims 8 and 19 of ‘245.
Claims 6 and 16 introduce subject matter provided by claim 9 of ‘245.
Claims 7 and 17 introduce subject matter provided by claim 10 of ‘245.
Claims 8 and 18 introduce subject matter provided by claims 11 and 20 of ‘245.
Claims 9 and 19 introduce subject matter provided by claim 12 of ‘245.
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.
Claims 6-7 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2015/0295792 (Cropper) in view of US 2010/0128598 (Gandhewar), US 2011/0154320 (Verma), US 2014/0026122 (Markande), and US 9,971,621 (Berg).
With regard to claim 1, Cropper discloses a system that automatically scales a size of a virtual machine in a cloud-based IT environment that is hosting one or more active user sessions, the system comprising:
a virtual machine having a plurality of incrementally scalable sizes (Cropper: Figure 6 and Paragraph [0081]. The size of the virtual machine can be adjusted from an initial level to a new requested level. It is noted that having a plurality of incrementally scalable sizes only provides that the virtual machine can be resized, not that the sizes are preconfigured with different levels of resources.), wherein each size is defined by a number of virtual CPU cores (Cropper: Paragraphs [0096], [0099], and [0072]. The resources can include CPU and memory. Lacking a claim requirement of the specific sizes, allowing for different amounts of resources would meet this claim language.);
a controller controlling the size of the virtual machine (cropper: Figure 6 and Figure 1. The cloud controller is considered to be the first server.);
a memory in communication with the controller, wherein the memory is configured to store program instructions executable by the controller (Cropper: Figure 6 and Figure 1);
wherein, in response to executing the program instructions, the controller is configured to:
receive a baseline implemented size of the virtual machine supporting a first number of user sessions (Cropper: Figure 6. The VM is set up with an initial configuration that is to be changed. It is noted that a virtual machine will support at least one user session, where the instant claim does not provide detail as to what specifies the number of user sessions or how the number of user sessions impacts any other functionality. Further, it is noted that the number of user sessions does not need to be known or specified by any component of the system as currently claimed.);
receive a request to resize the virtual machine to a new implemented size supporting a new number of user sessions (Cropper: Figure 6. Adding or removing resources would support different numbers of users.);
in response to the request to resize the virtual machine, calculate a minimum number of virtual CPU cores needed to support the new implemented size (Cropper: Figure 6 and Column 24, lines 16-18. Resources needed to add virtual machines is determined.);
in response to the calculation of virtual CPU cores, and without user intervention, identify one of the plurality of incrementally scalable sizes for the virtual machine that comprises at least the minimum number of virtual CPU cores needed to support the new number of user sessions (Cropper: Figure 6 and Column 24, lines 16-18).
Cropper fails to disclose expressly, but Gandhewar teaches that the calculating uses a user session to core ration, wherein the user session to core ratio is defined as the number of user sessions that can be supported per virtual CPU core (Gandhewar: Paragraph [0223]. Virtual servers are presented, where such virtual servers have CPU cores to support multiple user sessions. One of ordinary skill in the art would have recognized that a server is limited in the number of concurrent sessions by its available resources, where adding resources (such as CPU and RAM resources) would add to the number of supported sessions.). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to have the number of cores determined based on the number of cores required for a number of users (user to core ratio) to ensure that as users are added, additional cores are added as needed to prevent the system performance from degrading as users are added, while allowing cores to be removed as users are removed to ensure that unnecessary resources are not reserved for the virtual machine.
Cropper fails to teach, but Verma teaches shut down each of the active user sessions and resize the virtual machine to the identified one of the plurality of incrementally scalable sizes for the virtual machines (Verma: Paragraph [0107] and [0018]. Verma provides for the scheduling of maintenance and the notification of such to users. In combination with Cropper and Gandhewar, the user would be notified of the operations to change the virtual machines, including the need to power down or otherwise reboot the virtual machines.).
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to notify users (including active users) of the operations to be performed and to perform the operations, including shutting down the machines to ensure that the virtual machine’s operating system properly adjusts for the difference in resources.
Cropper fails to teach, but Markande teaches that the request to resize the virtual machines to a new size supporting the new number of users is triggered by the output of a testing server (Markande: Paragraphs [0024], [0029], and [0046]. A server, including a virtual server, hosting an application can be tested using a script (scheduled routine), where response time thresholds can be used to determine the performance. If the performance, such as response times) falls below a threshold, the resources can be scaled up.). Accordingly, it would have been obvious to perform response time tests and scale the resources, in accordance with Cropper, in the system of Cropper to ensure that the current configuration can support expected traffic, and if not, proactively adjust the system, thus providing a more stable user experience with interacting with the system.
With regard to claim 6, Cropper fails to teach, but Berg teaches that the output of the testing server automatically adjusts an action plan comprising a schedule of a plurality of users scheduled to access the virtual machine at any given time, and that the request to resize the virtual machine to a new size supporting the new number of user sessions is derived from the action plan (Berg: Column 13, lines 14-37. Schedules can be used to predict future demand to launch more VM instances. When combined with Markande, the schedule would be used first, according to Berg, then if performance is an issue, in accordance with Markande, the performance would be further adjusted, where the final level would be derived from both the tests and the schedule.). Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to utilize an action plan comprising a schedule to ensure that the pool of resources can meet demand for different times of day while allowing the resources to be decommissioned when they are no longer needed, thus improving the efficiency of the pool of resources (less power and resource consumption off peak while ensuring that during peak hours the resources are available), where making the adjustment according to the schedule first would reduce the likelihood of having a performance degradation that would trigger the resizing of Markande.
With regard to claim 2, Cropper in view of Gandhewar, Verma, Markande, and Berg teaches wherein the action plan includes at least one work hours profile comprising a user adjustable schedule of when an associated user is expected to use the virtual machine (Berg: Column 13, lines 14-37. Berg provides for user-specified schedules.).
With regard to claim 3, wherein the automatic modification of the action plan includes adjusting at least one work hours profile comprising a user adjustable schedule of when an associated user is expected to use the virtual machine (Berg: Column 13, lines 14-37. Schedules can be used to predict future demand to launch more VM instances.).
With regard to claim 4, Cropper in view of Gandhewar, Verma, Markande, and Berg teaches wherein the at least one work hours profile further comprises a schedule of a plurality of users scheduled to access the virtual machine at any given time (Berg: Column 13, lines 14-37. Schedules can be used to predict future demand to launch more VM instances.).
With regard to claim 5, Cropper fails to teach, but Markande teaches wherein the testing server is configured to: spin up a test user session in the testing server; on a scheduled routine, through the test user session, identify a plurality of response times for a plurality of tasks in the virtual machine; compare the identified plurality of response times against defined response time thresholds; when one or more of the identified plurality of response times exceed the defined response time thresholds, provide the request to resize the virtual machine to a new implemented size supporting the new number of user sessions (Markande: Paragraphs [0024], [0029], and [0046]. A server, including a virtual server, hosting an application can be tested using a script (scheduled routine), where response time thresholds can be used to determine the performance. If the performance, such as response times) falls below a threshold, the resources can be scaled up.). Accordingly, it would have been obvious to perform response time tests and scale the resources, in accordance with Cropper, in the system of Cropper to ensure that the current configuration can support expected traffic, and if not, proactively adjust the system, thus providing a more stable user experience with interacting with the system.
With regard to claim 6, Cropper in view of Gandhewar, Verma, Markande, and Berg teaches wherein the testing server is configured to test the user session to identify the plurality of response times for the plurality of tasks in the virtual machine according to a scheduled routine (Markande: Paragraphs [0024], [0029], and [0046]. A server, including a virtual server, hosting an application can be tested using a script (scheduled routine).).
With regard to claim 7, Cropper in view of Gandhewar, Verma, Markande, and Berg teaches wherein the testing server is configured to test the user session to identify the plurality of response times for the plurality of tasks in the virtual machine each time the virtual machine is resized (Markande: Paragraphs [0024], [0029], and [0046]. The tests can be performed for any size of the resource, where defined response times would be applicable to each resized virtual machine.).
With regard to claim 8, Cropper in view of Markande teaches wherein the defined response time thresholds are user adjustable (Markande: Paragraph [0043]).
With regard to claim 9, Cropper fails to teach, but knowledge possessed by one of ordinary skill in the art at the time of filing teaches wherein the plurality of tasks in the virtual machine includes one or more of: logging in to a desktop; visiting a website using a web browser; sending an email via an email client; opening a word-processing document; opening a spreadsheet document; opening a presentation software document; and opening a PDF document (more specifically, Official Notice is taken that the use of test scripts for testing common user actions, where each action listed was known to be a common user action, was well-known in the art). Accordingly, it would have been obvious to one of ordinary skill in the art to have the plurality of tasks include at least one of the listed common user tasks to appropriately test the response times of common user interactions, thus ensuring that the system is appropriately responding to such requests in a timely fashion.
With regard to claims 11-19, the instant claims are similar to claims 1-9, and are rejected for similar reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT B CHRISTENSEN whose telephone number is (571)270-1144. The examiner can normally be reached Monday through Friday, 6AM to 2PM.
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, John Follansbee can be reached at (571) 272-3964. 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.
SCOTT B. CHRISTENSEN
Examiner
Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights