DETAILED ACTION
Response to Amendment
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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7-12, and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kissell (U.S. Patent Application Publication Number 2006/0195683) and Koryakin et al. (U.S. Patent Number 10,452,420).
Regarding Claim 1, Kissell discloses a method comprising:
storing a first context in a first set of registers (Figure 2, items 222, 224, and 226, paragraph 0054; i.e., the thread context 104 comprises a collection of registers) in the CPU core (paragraph 0016), the first context corresponding to an operating system kernel (paragraph 0058; i.e., the thread identification information located within registers 226 identifies whether the particular thread is operating at a kernel privilege level; the operating system may be Linux - see paragraph 0126), wherein the operating system kernel runs on a first privilege domain that allows full access to CPU operations (paragraph 0137; i.e., the kernel privilege level allows for full CPU access versus a user privilege level, which does not); and
storing a second context in a second set of registers in the CPU core while the first context is stored in the first set of registers in the CPU core (paragraph 0058; i.e., there are a plurality of registers 222/224/226 to store the contexts of the various threads running on the CPU), the second context corresponding to the first application (e.g., a thread/application operating at the user level), wherein the CPU executes instructions using one of the first and second contexts at a time while both contexts persist in the first and second sets of registers (Figure 2, item 212, paragraphs 0058-0059; i.e., the scheduler 216 causes execution units 212 to execute instructions corresponding to the selected context stored in one of the registers 222/224/226, while other contexts persist in others of the registers 222/224/226).
Kissell does not expressly disclose executing, by a computer system comprising a central processing unit (“CPU”) having one or more cores, a hypervisor that provides a platform for one or more virtual machines to operate, the one or more virtual machines comprising a first virtual machine;
wherein the operating system kernel is a guest kernel for a guest operating system running on the first virtual machine; and
receiving a first request from a first application to perform a first operation, the first operation requiring access to the first privilege domain.
In the same field of endeavor (e.g., context switching techniques), Koryakin teaches executing, by a computer system (Figure 1, item 100) comprising a central processing unit (“CPU”) (Figure 1, item 110) having one or more cores (Column 2, lines 57-67), a hypervisor (Figure 1, item 160) that provides a platform for one or more virtual machines (Figure 1, item 130) to operate, the one or more virtual machines comprising a first virtual machine (Column 3, lines 19-35);
wherein the operating system kernel is a guest kernel for a guest operating system (Figure 1, item 135, Column 4, lines 56-64; i.e., operating systems are known in the art to comprise a kernel; therefore the guest operating system 135 would necessarily comprise a guest kernel) running on the first virtual machine; and
receiving a first request (Column 5, lines 24-29 and Column 6, line 53 - Column 7, line 5; i.e., a triggering event such as an attempt to execute a certain privileged instruction may come from an application operating in the guest execution mode resulting in a VM Exit [Column 3, lines 42-49]; the VM controller application 155 may detect the operation type from “the request” or analyze the cause of the VM Exit; further, the VM controller application 155 may initiate the “requested operation”) from a first application (Figure 1, item 140) to perform a first operation, the first operation requiring access to the first privilege domain (Figure 1, item 145, Column 3, lines 19-24 and 42-49, Column 4, lines 18-21; i.e., a guest application 140 may request to execute a certain privileged instruction [the “first operation”] at the VMM level [the “first privilege domain”], which results in a VM Exit).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Koryakin’s teachings of context switching techniques with the teachings of Kissell, for the purpose of allowing multiple fully separated instances of operating systems to run simultaneously (i.e., this is the purpose of virtual machines). Further, the use of a guest operating system allows a user to execute functions that cannot alter or harm the host system since it runs at a lower privilege level.
Regarding Claim 2, Kissell teaches wherein the first and second contexts include at least one of a stack pointer, a page table, and a program counter (Figure 2, item 222, paragraph 0058).
Regarding Claim 3, Koryakin discloses wherein the first application uses a second privilege domain that allows limited access to CPU operations (Figure 1, item 140, Column 3, lines 50-63; i.e., the guest application 140 [the “first application”] has pre-configured restrictions for CPU operations).
Regarding Claim 4, Kissell teaches wherein the first context persists in the first set of registers in the CPU core while the operating system is running (Figure 2, item 212, paragraphs 0058-0059).
Kissell does not expressly teach the operating system is a guest operating system running on a virtual machine.
In the same field of endeavor, Koryakin discloses the operating system is a guest operating system (Figure 1, item 135) running on a virtual machine (Figure 1, item 130).
The motivation discussed above with regards to Claim 1 applies equally as well to Claim 4.
Regarding Claim 5, Koryakin discloses storing a third context in the CPU core, the third context corresponding the hypervisor (Figure 1, items 145 and 160, Column 4, lines 56-64; i.e., the VMM 145 and hypervisor 160 work together [Column 4, lines 45-46] in the “separate privileged execution mode context”).
Regarding Claim 7, Kissell teaches after executing the first operation, storing the first context in the first set of registers in the CPU core again; and loading the second context from the CPU core (paragraphs 0012 and 0076; i.e., the context of an executed thread/application can be restored to the registers after which another thread’s context can be loaded into the CPU core).
Regarding Claim 8, Kissell discloses a non-transitory, computer-readable medium containing instructions that, when executed by one or more hardware-based processors (paragraph 0210), performs operations comprising:
storing a first context in a first set of registers (Figure 2, items 222, 224, and 226, paragraph 0054; i.e., the thread context 104 comprises a collection of registers) in the CPU core (paragraph 0016), the first context corresponding to an operating system kernel (paragraph 0058; i.e., the thread identification information located within registers 226 identifies whether the particular thread is operating at a kernel privilege level; the operating system may be Linux - see paragraph 0126), wherein the operating system kernel runs on a first privilege domain that allows full access to CPU operations (paragraph 0137; i.e., the kernel privilege level allows for full CPU access versus a user privilege level, which does not); and
storing a second context in a second set of registers in the CPU core while the first context is stored in the first set of registers in the CPU core (paragraph 0058; i.e., there are a plurality of registers 222/224/226 to store the contexts of the various threads running on the CPU), the second context corresponding to the first application (e.g., a thread/application operating at the user level), wherein the CPU executes instructions using one of the first and second contexts at a time while both contexts persist in the first and second sets of registers (Figure 2, item 212, paragraphs 0058-0059; i.e., the scheduler 216 causes execution units 212 to execute instructions corresponding to the selected context stored in one of the registers 222/224/226, while other contexts persist in others of the registers 222/224/226).
Kissell does not expressly disclose executing, by a computer system comprising a CPU having one or more cores, a hypervisor that provides a platform for one or more virtual machines to operate, the one or more virtual machines comprising a first virtual machine;
wherein the operating system kernel is a guest kernel for a guest operating system running on the first virtual machine; and
receiving a first request from a first application to perform a first operation, the first operation requiring access to the first privilege domain.
In the same field of endeavor, Koryakin teaches executing, by a computer system (Figure 1, item 100) comprising a CPU (Figure 1, item 110) having one or more cores (Column 2, lines 57-67), a hypervisor (Figure 1, item 160) that provides a platform for one or more virtual machines (Figure 1, item 130) to operate, the one or more virtual machines comprising a first virtual machine (Column 3, lines 19-35);
wherein the operating system kernel is a guest kernel for a guest operating system (Figure 1, item 135, Column 4, lines 56-64; i.e., operating systems are known in the art to comprise a kernel; therefore the guest operating system 135 would necessarily comprise a guest kernel) running on the first virtual machine; and
receiving a first request (Column 5, lines 24-29 and Column 6, line 53 - Column 7, line 5; i.e., a triggering event such as an attempt to execute a certain privileged instruction may come from an application operating in the guest execution mode resulting in a VM Exit [Column 3, lines 42-49]; the VM controller application 155 may detect the operation type from “the request” or analyze the cause of the VM Exit; further, the VM controller application 155 may initiate the “requested operation”) from a first application (Figure 1, item 140) to perform a first operation, the first operation requiring access to the first privilege domain (Figure 1, item 145, Column 3, lines 19-24 and 42-49, Column 4, lines 18-21; i.e., a guest application 140 may request to execute a certain privileged instruction [the “first operation”] at the VMM level [the “first privilege domain”], which results in a VM Exit).
The motivation discussed above with regards to Claim 1 applies equally as well to Claim 8.
Regarding Claim 9, Kissell teaches wherein the first and second contexts include at least one of a stack pointer, a page table, and a program counter (Figure 2, item 222, paragraph 0058).
Regarding Claim 10, Koryakin discloses wherein the first application uses a second privilege domain that allows limited access to CPU operations (Figure 1, item 140, Column 3, lines 50-63; i.e., the guest application 140 [the “first application”] has pre-configured restrictions for CPU operations).
Regarding Claim 11, Kissell teaches wherein the first context persists in the first set of registers in the CPU core while the operating system is running (Figure 2, item 212, paragraphs 0058-0059).
Kissell does not expressly teach the operating system is a guest operating system running on a virtual machine.
In the same field of endeavor, Koryakin discloses the operating system is a guest operating system (Figure 1, item 135) running on a virtual machine (Figure 1, item 130).
The motivation discussed above with regards to Claim 1 applies equally as well to Claim 11.
Regarding Claim 12, Koryakin discloses storing a third context in the CPU core, the third context corresponding to the hypervisor (Figure 1, items 145 and 160, Column 4, lines 56-64; i.e., the VMM 145 and hypervisor 160 work together [Column 4, lines 45-46] in the “separate privileged execution mode context”).
Regarding Claim 14, Kissell teaches after executing the first operation, storing the first context in the first set of registers in the CPU core again; and loading the second context from the CPU core (paragraphs 0012 and 0076; i.e., the context of an executed thread/application can be restored to the registers after which another thread’s context can be loaded into the CPU core).
Regarding Claim 15, Kissell discloses a computer system comprising:
one or more processors, including a central processing unit (“CPU”) having one or more cores (paragraph 0210); and
a non-transitory, computer-readable medium (paragraph 0210) containing instructions that, when executed by one or more hardware-based processors, causes the computer system to perform operations comprising:
storing a first context in a first set of registers (Figure 2, items 222, 224, and 226, paragraph 0054; i.e., the thread context 104 comprises a collection of registers) in the CPU core (paragraph 0016), the first context corresponding to an operating system kernel (paragraph 0058; i.e., the thread identification information located within registers 226 identifies whether the particular thread is operating at a kernel privilege level; the operating system may be Linux - see paragraph 0126), wherein the operating system kernel runs on a first privilege domain that allows full access to CPU operations (paragraph 0137; i.e., the kernel privilege level allows for full CPU access versus a user privilege level, which does not); and
storing a second context in a second set of registers in the CPU core while the first context is stored in the first set of registers in the CPU core (paragraph 0058; i.e., there are a plurality of registers 222/224/226 to store the contexts of the various threads running on the CPU), the second context corresponding to the first application (e.g., a thread/application operating at the user level), wherein the CPU executes instructions using one of the first and second contexts at a time while both contexts persist in the first and second sets of registers (Figure 2, item 212, paragraphs 0058-0059; i.e., the scheduler 216 causes execution units 212 to execute instructions corresponding to the selected context stored in one of the registers 222/224/226, while other contexts persist in others of the registers 222/224/226).
Kissell does not expressly disclose executing, by a computer system comprising a CPU having one or more cores, a hypervisor that provides a platform for one or more virtual machines to operate, the one or more virtual machines comprising a first virtual machine;
wherein the operating system kernel is a guest kernel for a guest operating system running on the first virtual machine; and
receiving a first request from a first application to perform a first operation, the first operation requiring access to the first privilege domain.
In the same field of endeavor, Koryakin teaches executing, by a computer system comprising a CPU (Figure 1, item 110) having one or more cores (Column 2, lines 57-67), a hypervisor (Figure 1, item 160) that provides a platform for one or more virtual machines (Figure 1, item 130) to operate, the one or more virtual machines comprising a first virtual machine (Column 3, lines 19-35);
wherein the operating system kernel is a guest kernel for a guest operating system (Figure 1, item 135, Column 4, lines 56-64; i.e., operating systems are known in the art to comprise a kernel; therefore the guest operating system 135 would necessarily comprise a guest kernel) running on the first virtual machine; and
receiving a first request (Column 5, lines 24-29 and Column 6, line 53 - Column 7, line 5; i.e., a triggering event such as an attempt to execute a certain privileged instruction may come from an application operating in the guest execution mode resulting in a VM Exit [Column 3, lines 42-49]; the VM controller application 155 may detect the operation type from “the request” or analyze the cause of the VM Exit; further, the VM controller application 155 may initiate the “requested operation”) from a first application (Figure 1, item 140) to perform a first operation, the first operation requiring access to the first privilege domain (Figure 1, item 145, Column 3, lines 19-24 and 42-49, Column 4, lines 18-21; i.e., a guest application 140 may request to execute a certain privileged instruction [the “first operation”] at the VMM level [the “first privilege domain”], which results in a VM Exit).
The motivation discussed above with regards to Claim 1 applies equally as well to Claim 15.
Regarding Claim 16, Kissell teaches wherein the first and second contexts include at least one of a stack pointer, a page table, and a program counter (Figure 2, item 222, paragraph 0058).
Regarding Claim 17, Koryakin discloses wherein the first application uses a second privilege domain that allows limited access to CPU operations (Figure 1, item 140, Column 3, lines 50-63; i.e., the guest application 140 [the “first application”] has pre-configured restrictions for CPU operations).
Regarding Claim 18, Kissell discloses wherein the first context persists in the first set of registers in the CPU core while the operating system is running (Figure 2, item 212, paragraphs 0058-0059).
Kissell does not expressly teach the operating system is a guest operating system running on a virtual machine.
In the same field of endeavor, Koryakin discloses the operating system is a guest operating system (Figure 1, item 135) running on a virtual machine (Figure 1, item 130).
The motivation discussed above with regards to Claim 1 applies equally as well to Claim 18.
Regarding Claim 19, Koryakin discloses storing a third context in the CPU core, the third context corresponding to the hypervisor (Figure 1, items 145 and 160, Column 4, lines 56-64; i.e., the VMM 145 and hypervisor 160 work together [Column 4, lines 45-46] in the “separate privileged execution mode context”).
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kissell and Koryakin and as applied to claims 1, 8, and 15 above, and further in view of Dutu et al. (U.S. Patent Application Publication Number 2020/0004586).
Regarding Claim 6, Kissell and Koryakin teach receiving a second request from a second application to perform a second operation (Koryakin, Column 3, lines 30-35; i.e., there may be plural virtual machines 130, each running a guest application 140; each of these guest applications 140 may transmit requests to access the VMM [Column 5, lines 24-29 and Column 6, line 53 - Column 7, line 5]);
saving the second context in a memory (Kissell, Figure 2, items 222, 224, and 226, paragraph 0054; i.e., the second context continues to be stored within registers 222/224/226 along with contexts of other threads/applications);
storing the third context in the CPU core while the first context remains in the first set of registers in the CPU core (Kissell, Figure 2, items 222, 224, and 226, paragraph 0054; i.e., a third context may be stored within registers 222/224/226 while the first context remains in the first set of registers); and
executing the second operation using the third context (Kissell, Figure 2, item 212, paragraphs 0058-0059; i.e., the scheduler 216 causes execution units 212 to execute instructions corresponding to the selected context stored in one of the registers 222/224/226, while other contexts persist in others of the registers 222/224/226).
Kissell and Koryakin do not expressly disclose prefetching a third context, the third context corresponding to the second application.
In the same field of endeavor (e.g., context switching techniques), Dutu teaches prefetching a third context, the third context corresponding to the second application (paragraph 0015).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Dutu’s teachings of context switching techniques with the teachings of Kissell and Koryakin, for the purpose of avoiding the need for the CPU to have to wait for the context to be retrieved from memory before executing the application, thereby resulting in faster execution times.
Regarding Claim 13, Kissell and Koryakin teach receiving a second request from a second application to perform a second operation (Koryakin, Column 3, lines 30-35; i.e., there may be plural virtual machines 130, each running a guest application 140; each of these guest applications 140 may transmit requests to access the VMM [Column 5, lines 24-29 and Column 6, line 53 - Column 7, line 5]);
saving the second context in a memory (Kissell, Figure 2, items 222, 224, and 226, paragraph 0054; i.e., the second context continues to be stored within registers 222/224/226 along with contexts of other threads/applications);
storing the third context in the CPU core while the first context remains in the first set of registers in the CPU core (Kissel, Figure 2, items 222, 224, and 226, paragraph 0054; i.e., a third context may be stored within registers 222/224/226 while the first context remains in the first set of registers); and
executing the second operation using the third context (Kissel, Figure 2, item 212, paragraphs 0058-0059; i.e., the scheduler 216 causes execution units 212 to execute instructions corresponding to the selected context stored in one of the registers 222/224/226, while other contexts persist in others of the registers 222/224/226).
Kissell and Koryakin do not expressly disclose prefetching a third context, the third context corresponding to the second application.
In the same field of endeavor, Dutu teaches prefetching a third context, the third context corresponding to the second application (paragraph 0015).
The motivation discussed above with regards to Claim 6 applies equally as well to Claim 13.
Regarding Claim 20, Kissell and Koryakin teach receiving a request from a second application to perform an operation (Koryakin, Column 3, lines 30-35; i.e., there may be plural virtual machines 130, each running a guest application 140; each of these guest applications 140 may transmit requests to access the VMM [Column 5, lines 24-29 and Column 6, line 53 - Column 7, line 5]);
saving the second context in a memory (Kissell, Figure 2, items 222, 224, and 226, paragraph 0054; i.e., the second context continues to be stored within registers 222/224/226 along with contexts of other threads/applications);
storing the third context in the CPU core while the first context remains in the first set of registers in the CPU core (Kissel, Figure 2, items 222, 224, and 226, paragraph 0054; i.e., a third context may be stored within registers 222/224/226 while the first context remains in the first set of registers); and
executing the requested operation using the third context (Kissel, Figure 2, item 212, paragraphs 0058-0059; i.e., the scheduler 216 causes execution units 212 to execute instructions corresponding to the selected context stored in one of the registers 222/224/226, while other contexts persist in others of the registers 222/224/226).
Kissell and Koryakin do not expressly disclose prefetching a third context, the third context corresponding to the second application.
In the same field of endeavor, Dutu teaches prefetching a third context, the third context corresponding to the second application (paragraph 0015).
The motivation discussed above with regards to Claim 6 applies equally as well to Claim 20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure because each reference discloses a method for context switching among applications executing on a CPU.
Response to Arguments
Applicant's arguments filed 3/31/26 have been fully considered but they are not persuasive.
Regarding Claim 1, Applicant argues “neither Koryakin nor Kissell teaches storing a guest kernel's context in registers in a CPU core within a virtual machine environment.” Response, page 10. The examiner disagrees. The combination of Kissell with Koryakin teaches the argued feature. More specifically, Kissell teaches storing an operating system kernel context in a register of a CPU. See Kissell, paragraph 0058. The operating system may be Linux. See id. at paragraph 0126. Kissell does not expressly state that this operating system is a guest operating system running on a virtual machine. However, Koryakin teaches a guest operating system 135 (which, as is well known in the art, necessarily comprises a kernel) that runs on a virtual machine 130. See Koryakin, Figure 1. Accordingly, the combination of references teaches the argued feature (i.e., the combination of references teaches storing a guest kernel’s context in registers in a CPU core within a virtual machine environment). It would have been obvious to one of ordinary skill in the art to have combined the references for the reasons given in the § 103 rejection above. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Regarding dependent Claim 4, Applicant argues “neither Koryakin nor Kissell teaches or suggests that a guest kernel context remains persistently stored in CPU registers throughout the operation of the guest operating system”. Response, pages 13-14. The examiner disagrees. Similar to the above discussion, Kissell teaches storing multiple contexts, including an operating system kernel context in CPU registers. Kissell does not expressly disclose that the operating system is a guest operating system running on a virtual machine. However, Koryakin teaches this. As stated above, the combination of references teaches the argued feature and it would have been obvious to one of ordinary skill in the art to have combined the references for the reasons provided above.
Regarding dependent Claim 5, Applicant argues “this requires three privilege domain contexts (guest kernel, application, and hypervisor) to be simultaneously present in the CPU core. Neither Koryakin, which does not teach register-level context storage, nor Kissell, which doesn't even disclose a hypervisor, teaches this three-context configuration.” Response, page 14. The examiner disagrees. Koryakin teaches storing and running multiple contexts in the CPU. See Koryakin, Column 4, lines 56-64. The hypervisor 160 may be merged with the VMM 145. See id. at Column 4, lines 45-46. Therefore, the hypervisor context may be included with the other contexts that are stored and operating on the CPU. This would result in three contexts being stored and run on the CPU. Accordingly, it can be seen that Koryakin does in fact teach the argued limitation.
Regarding dependent Claim 6, Applicant argues “Dutu does not teach or suggest anything about storing a guest kernel context in a set of registers in a CPU core, virtual machines, hypervisors, or privilege domain context management within a virtualized environment.” Response, page 14. However, Dutu was not alleged to teach these features. Rather, Dutu was only used in the § 103 rejection to teach the feature of “prefetching a third context, the third context corresponding to the second application”. Accordingly, Applicant’s argument is not persuasive.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAISAL M ZAMAN whose telephone number is (571)272-6495. The examiner can normally be reached Monday - Friday, 8 am - 5 pm, alternate Fridays.
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, Andrew J. Jung can be reached at 571-270-3779. 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.
/FAISAL M ZAMAN/ Primary Examiner, Art Unit 2175