DETAILED ACTION
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on March 6, 2025 is being considered by the examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-21 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Crandall et al. (U.S. Publication No. 2008/0155224 A1, hereinafter referred to as “Crandall”).
Regarding claim 1, Crandall discloses a computer-implemented method comprising: (“computer-implemented method)(e.g., paragraph [0035])
interpreting data in a first environment structure of a first format used in a first environment to a second structure of a second format used in a second environment, the data as interpreted stored in an intermediate storage; (“According to the illustrated system, a legacy OS 200 of the type that is generally associated with mainframe systems is loaded into main memory 100. This legacy OS, which may be the 2200 OS commercially available from Unisys Corporation, is adapted to execute directly on a "legacy platform", which may be a mainframe system such as a 2200 or an A-series data processing system commercially available from the Unisys Corporation. Alternatively, this legacy platform may be some other enterprise-type environment that provides the security, data protection, and recovery mechanisms generally associated with mainframe systems. Such mechanisms are provided to prevent unintentional deletions or updates to data stored on mass storage devices 109. These mechanisms also ensure that the data is maintained in a coherent state.”)(e.g., paragraph [0057])
activating a program in the second environment, wherein the program is executed by a broker configured to use data from the intermediate storage, to produce output to be stored in a second intermediate storage; and (“In one embodiment, legacy OS 200 may be implemented using a different machine instruction set (hereinafter, "legacy instruction set", or "legacy instructions") than that which is native to IP(s) 104. This legacy instruction set is the instruction set which is executed by the IPs of a legacy platform on which the legacy OS is intended to operate. In this embodiment, the legacy instruction set used to implement legacy OS is emulated by an emulation environment 202. The details associated with the operation of emulation environment 202 are largely beyond the scope of this disclosure. More information regarding the operation of this environment may be found in the commonly-assigned U.S. patent application entitled "System and Method for Synchronizing Memory Management Functions of Two Disparate Operating Systems", attorney docket number RA-5827, filed on even date herewith.”)(e.g., paragraph [0058])
upon the program termination, interpreting the output in the second intermediate storage from the second structure to the first structure, wherein interpreting the data and the output is performed using a mapper which maps between the first format and the second format, and wherein the first format is different from the second format at least in that at least one data field in the first format is absent in the second format, or at least one data field in the second format is absent in the first format, or in that at least one data field in the first format is formatted differently in the second format, or data fields in the second format have different order from data fields in the first format. ("If legacy OS 200 were operating on a legacy platform, legacy IOP 204 would be monitoring the designator in the initiation queue to determine when request packet 302 is ready for processing. Legacy IOP 204 would then process this packet directly without use of any intermediate translating step. However, two characteristics of the current system make some translation necessary before legacy IOP may process the packet. First, the request packet 302 resides in virtual address space. In other words, the address contained in entry 305 is a virtual address. Moreover, all addresses stored within the BD buffer that point to data buffers are virtual addresses, as will be described further below. These addresses cannot be used directly by the legacy IOP 204, which expects all addresses to be physical addresses to physical memory devices. Thus, translation is required to translate all virtual addresses to physical addresses." "In view of the foregoing, when the designator bit of entry 305 is set, IOP driver 206 nails all of the memory used for the BD buffer so that it is not paged out of memory while that buffer is being used during the 1/0 operation. The IOP driver also translates each virtual address that is stored within the request packet into one or more physical addresses that map to the virtual address. To accomplish this address translation, IOP driver 206 calls various standard memory management utilities of commodity OS _113. These utilities convert virtual addresses into physical addresses. The physical addresses that are returned by the commodity OS 113 in response to these calls are used by IOP driver 206 to create a translated request packet 304. In one embodiment, each BD of the original request packet will be translated into multiple BDs of the translated request packet 304. This is discussed in detail below.")(e.g., paragraphs [0090]-[0092]).
Regarding claim 2, Crandall discloses the method of Claim 1. Crandall further discloses wherein the first environment is an open environment and the second environment is a legacy environment. (“First, commodity OSes generally do not include the type of security and protection mechanisms needed to ensure that legacy data is adequately protected. For instance, a commodity OS such as Linux utilizes an in-memory cache 120 to boost performance. This in-memory cache may store data that has been retrieved from mass storage devices 109. Based on the types of requests made by application programs to this data, some updates to this cached data may be retained within the in-memory cache 120 and not written back to mass storage devices 109 for some period of time. Other updates may be initiated directly to the mass storage devices 109. This may lead to a "data coherency" problem wherein an older update that had been retained within in-memory cache 120 may eventually overwrite newer data that was stored directly to cache. A commodity OS will generally not guard against this undesired result. Instead, the application programmer must ensure that this type of operation does not occur. This becomes increasingly difficult in a multi-processing environment wherein many different applications are making I/O requests concurrently.”)(e.g., paragraph [0053]).
Regarding claim 3, Crandall discloses the method of Claim 1. Crandall further discloses wherein the first environment is a legacy environment and the second environment is an open environment. (“The above description focuses on a commodity-type OS that communicates directly with peripheral devices (e.g., the HBAs) via corresponding device drivers. Another approach for performing I/O operations within a commodity-type system is to utilize an Input/Output Processor (IOP) emulator 126 to communicate with the peripheral devices. An IOP emulator is a software system that is loaded into main memory 100 to emulate the functions that would be provided by corresponding IOP hardware of the type that is typically present in mainframe-type systems. An IOP emulator 126 may be useful, for instance, when a data processing system is being made to appear as though it is coupled to an IOP that is of a type that is generally not supported by that system.”)(e.g., paragraph [0055]).
Regarding claim 4, Crandall discloses the method of Claim 1. Crandall further discloses further comprising activating the program in the second environment, and providing the program with access to the intermediate storage. (“Legacy OS may initiate an I/O operation to transfer legacy data on behalf of application programs (APs) 205A. For instance, APs 205A may make a request to legacy OS 200 to read data from, or write data to, mass storage devices 109. When this occurs, the requesting one of APs 205A provides one or more addresses to data buffers in main memory to which, or from which, the data will be transferred.”)(e.g., paragraph [0066]).
Regarding claim 5, Crandall discloses the method of Claim 1. Crandall further discloses wherein the program is configured to use an Application Program Interface (API) to get values from the intermediate storage and put values into a second intermediate storage. (“In the illustrated adaptation, legacy OS 200 communicates with commodity OS 113 via an application program interface (API) 207. As is known in the art, an API is an interface that a computer system, library, or application provides to allow requests for services to be made of it by other computer programs and/or to allow data to be exchanged between the two entities. In one embodiment, the legacy OS 200 uses the same API 207 to obtain services from the commodity OS as any other software application program, such as one of APs 205B, would employ. Thus, the legacy OS appears to the commodity OS as just another software application that is requesting the commodity OS' services.”)(e.g., paragraph [0059]).
Regarding claim 6, Crandall discloses the method of Claim 5. Crandall further discloses wherein the program in the second environment can access dynamically allocated memory locations for reading and writing, in accordance with business logic of the program in the second environment. (“Legacy OS 200 is adapted to communicate directly with various legacy I/O Processors (IOPs) such as legacy IOP 204, which includes I/O hardware of a type typically found on a legacy platform. Legacy IOP 204 provides an interface between main memory 100 and the HBAs such as fibre channel HBA 106 and SCSI HBA 108. Legacy OS 200 includes data protection and other security features that ensures that I/O operations initiated by the legacy OS will maintain the data stored within mass storage devices 109 in a coherent state. The legacy OS also has sophisticated protection mechanisms in place to guard against unintentional or unauthorized data deletions or updates.”)(e.g., paragraph [0063]).
Regarding claim 7, Crandall discloses the method of Claim 5. Crandall further discloses wherein the second format is a format accessible to the API. (“Legacy IOP 204 provides an interface between main memory 100 and the HBAs such as fibre channel HBA 106 and SCSI HBA 108.”)(e.g., paragraph [0063]).
Regarding claim 8, Crandall discloses the method of Claim 1. Crandall further discloses wherein the program in the second environment is adapted to: receive an address of the intermediate storage; (“Commodity OS 113 is not adapted to initiate I/O operations using legacy IOP 204. During system initialization, commodity OS 113 will determine that some unidentified type of hardware device (i.e., legacy IOP 204) is coupled to the system and will cause the appropriate driver to be loaded, which in this example is shown as IOP driver 206. This IOP driver 206 provides an interface that allows the commodity OS to communicate in a limited fashion with the legacy IOP 204. However, IOP driver 206 does not allow the commodity OS 113 to communicate directly with the HBAs. In fact, the legacy IOP 204 hides the existence of the HBAs from the commodity OS. As a result, the commodity OS 113 will not attempt to perform I/O operations to/from mass storage devices 109. This protects the data from any unauthorized inadvertent and/or malicious update activities that may be initiated via commodity OS 113.” “The request packet includes the address(es) of the data buffer(s) in main memory to which, or from which, the data will be transferred.”)(e.g., paragraphs [0064] and [0069])
read data from the intermediate storage; and write data to a second intermediate storage. (“Commodity OS 113 is not adapted to initiate I/O operations using legacy IOP 204. During system initialization, commodity OS 113 will determine that some unidentified type of hardware device (i.e., legacy IOP 204) is coupled to the system and will cause the appropriate driver to be loaded, which in this example is shown as IOP driver 206. This IOP driver 206 provides an interface that allows the commodity OS to communicate in a limited fashion with the legacy IOP 204. “ “Legacy OS may initiate an I/O operation to transfer legacy data on behalf of application programs (APs) 205A. For instance, APs 205A may make a request to legacy OS 200 to read data from, or write data to, mass storage devices 109. When this occurs, the requesting one of APs 205A provides one or more addresses to data buffers in main memory to which, or from which, the data will be transferred.”)(e.g., paragraph [0064], [0066], [0069], [0075] and [0085]).
Regarding claim 9, Crandall discloses the method of Claim 8. Crandall further discloses wherein the second format is a format accessible to the program in the second environment. (“Legacy OS 200 is adapted to communicate directly with various legacy I/O Processors (IOPs) such as legacy IOP 204, which includes I/O hardware of a type typically found on a legacy platform. Legacy IOP 204 provides an interface between main memory 100 and the HBAs such as fibre channel HBA 106 and SCSI HBA 108. Legacy OS 200 includes data protection and other security features that ensures that I/O operations initiated by the legacy OS will maintain the data stored within mass storage devices 109 in a coherent state. The legacy OS also has sophisticated protection mechanisms in place to guard against unintentional or unauthorized data deletions or updates.”)(e.g., paragraph [0063] and [0157]).
Regarding claim 10, Crandall discloses the method of Claim 1. Crandall further discloses wherein the data comprises a tree structure. (“Mass storage devices 109 may store highly sensitive data such as banking records, data used to support transportation and utility infrastructures, government information, and so on. Because loss of such data could have catastrophic effects, it is generally advantageous to update this data using data protection and security mechanisms of the type typically found on legacy data processing systems (e.g., mainframes). In today's world, however, smaller commodity data processing systems such as PCs are increasingly being used to update this type of sensitive data. As discussed above, this presents several challenges.”)(e.g., paragraph [0052]).
Regarding claim 11, Crandall discloses the method of Claim 1. Crandall further discloses wherein the data comprises an array. (“If the call is successful, commodity OS returns an array of page descriptors that provides the starting physical addresses of the pages in physical memory that have been allocated to the buffer in virtual address space.”)(e.g., paragraphs [0052] and [0110]).
Regarding claim 12, Crandall discloses the method of Claim 11. Crandall further discloses wherein the array is a multi-dimensional array. (“If the call is successful, commodity OS returns an array of page descriptors that provides the starting physical addresses of the pages in physical memory that have been allocated to the buffer in virtual address space.”)(e.g., figures 4-5 and paragraphs [0052] and [0110]).
Regarding claim 13, Crandall discloses a system having a processor, the processor being adapted to perform the steps of: (“FIG. 1 is a block diagram of an exemplary commodity-type data processing system such as a personal computer, workstation, or other "off-the-shelf" hardware (hereinafter "commodity platform") that may be adapted for use with the current invention. A main memory 100 is coupled to a shared cache 102. The shared cache is, in turn, coupled to one or more instruction processors (IPs) 104 which may be an instruction processor commercially available from Unisys Corporation, Intel Corporation, Advanced Micro Devices, Inc., or some other vendor.”)(e.g., paragraph [0049])
interpreting data in a first environment structure of a first format used in a first environment to a second structure of a second format used in a second environment, the data as interpreted stored in an intermediate storage; (“According to the illustrated system, a legacy OS 200 of the type that is generally associated with mainframe systems is loaded into main memory 100. This legacy OS, which may be the 2200 OS commercially available from Unisys Corporation, is adapted to execute directly on a "legacy platform", which may be a mainframe system such as a 2200 or an A-series data processing system commercially available from the Unisys Corporation. Alternatively, this legacy platform may be some other enterprise-type environment that provides the security, data protection, and recovery mechanisms generally associated with mainframe systems. Such mechanisms are provided to prevent unintentional deletions or updates to data stored on mass storage devices 109. These mechanisms also ensure that the data is maintained in a coherent state.”)(e.g., paragraph [0057])
activating a program in the second environment, wherein the program is configured to use data from the intermediate storage, to produce output to be stored in a second intermediate storage; and (“In one embodiment, legacy OS 200 may be implemented using a different machine instruction set (hereinafter, "legacy instruction set", or "legacy instructions") than that which is native to IP(s) 104. This legacy instruction set is the instruction set which is executed by the IPs of a legacy platform on which the legacy OS is intended to operate. In this embodiment, the legacy instruction set used to implement legacy OS is emulated by an emulation environment 202. The details associated with the operation of emulation environment 202 are largely beyond the scope of this disclosure. More information regarding the operation of this environment may be found in the commonly-assigned U.S. patent application entitled "System and Method for Synchronizing Memory Management Functions of Two Disparate Operating Systems", attorney docket number RA-5827, filed on even date herewith.”)(e.g., paragraph [0058])
upon the program termination, interpreting the output in the second intermediate storage from the second structure to the first structure, wherein interpreting the data and the output is performed using a mapper which maps between the first format and the second format, and wherein the first format is different from the second format at least in that at least one data field in the first format is absent in the second format, or at least one data field in the second format is absent in the first format, or in that at least one data field in the first format is formatted differently in the second format, or data fields in the second format have different order from data fields in the first format. ("If legacy OS 200 were operating on a legacy platform, legacy IOP 204 would be monitoring the designator in the initiation queue to determine when request packet 302 is ready for processing. Legacy IOP 204 would then process this packet directly without use of any intermediate translating step. However, two characteristics of the current system make some translation necessary before legacy IOP may process the packet. First, the request packet 302 resides in virtual address space. In other words, the address contained in entry 305 is a virtual address. Moreover, all addresses stored within the BD buffer that point to data buffers are virtual addresses, as will be described further below. These addresses cannot be used directly by the legacy IOP 204, which expects all addresses to be physical addresses to physical memory devices. Thus, translation is required to translate all virtual addresses to physical addresses." "In view of the foregoing, when the designator bit of entry 305 is set, IOP driver 206 nails all of the memory used for the BD buffer so that it is not paged out of memory while that buffer is being used during the 1/0 operation. The IOP driver also translates each virtual address that is stored within the request packet into one or more physical addresses that map to the virtual address. To accomplish this address translation, IOP driver 206 calls various standard memory management utilities of commodity OS _113. These utilities convert virtual addresses into physical addresses. The physical addresses that are returned by the commodity OS 113 in response to these calls are used by IOP driver 206 to create a translated request packet 304. In one embodiment, each BD of the original request packet will be translated into multiple BDs of the translated request packet 304. This is discussed in detail below.")(e.g., paragraphs [0090]-[0092]).
Regarding claim 14, Crandall discloses the system of Claim 13. Crandall further discloses wherein the first environment is an open environment and the second environment is a legacy environment or (“First, commodity OSes generally do not include the type of security and protection mechanisms needed to ensure that legacy data is adequately protected. For instance, a commodity OS such as Linux utilizes an in-memory cache 120 to boost performance. This in-memory cache may store data that has been retrieved from mass storage devices 109. Based on the types of requests made by application programs to this data, some updates to this cached data may be retained within the in-memory cache 120 and not written back to mass storage devices 109 for some period of time. Other updates may be initiated directly to the mass storage devices 109. This may lead to a "data coherency" problem wherein an older update that had been retained within in-memory cache 120 may eventually overwrite newer data that was stored directly to cache. A commodity OS will generally not guard against this undesired result. Instead, the application programmer must ensure that this type of operation does not occur. This becomes increasingly difficult in a multi-processing environment wherein many different applications are making I/O requests concurrently.”)(e.g., paragraph [0053]) the first environment is a legacy environment and the second environment is an open environment. (“The above description focuses on a commodity-type OS that communicates directly with peripheral devices (e.g., the HBAs) via corresponding device drivers. Another approach for performing I/O operations within a commodity-type system is to utilize an Input/Output Processor (IOP) emulator 126 to communicate with the peripheral devices. An IOP emulator is a software system that is loaded into main memory 100 to emulate the functions that would be provided by corresponding IOP hardware of the type that is typically present in mainframe-type systems. An IOP emulator 126 may be useful, for instance, when a data processing system is being made to appear as though it is coupled to an IOP that is of a type that is generally not supported by that system.”)(e.g., paragraph [0055]).
Claims 15-18 have substantially similar limitations as stated in claims 4-7, respectively; therefore, they are rejected under the same subject matter.
Regarding claim 19, Crandall discloses the system of Claim 13. Crandall further discloses wherein the program in the second environment is adapted to: receive an address of the intermediate storage; read data from the intermediate storage; and write data to a second intermediate storage, and (“Commodity OS 113 is not adapted to initiate I/O operations using legacy IOP 204. During system initialization, commodity OS 113 will determine that some unidentified type of hardware device (i.e., legacy IOP 204) is coupled to the system and will cause the appropriate driver to be loaded, which in this example is shown as IOP driver 206. This IOP driver 206 provides an interface that allows the commodity OS to communicate in a limited fashion with the legacy IOP 204. “ “The request packet includes the address(es) of the data buffer(s) in main memory to which, or from which, the data will be transferred.” “Legacy OS may initiate an I/O operation to transfer legacy data on behalf of application programs (APs) 205A. For instance, APs 205A may make a request to legacy OS 200 to read data from, or write data to, mass storage devices 109. When this occurs, the requesting one of APs 205A provides one or more addresses to data buffers in main memory to which, or from which, the data will be transferred.”)(e.g., paragraph [0064], [0066], [0069], [0075] and [0085]) wherein the second format is a format accessible to the program in the second environment. (“Legacy OS 200 is adapted to communicate directly with various legacy I/O Processors (IOPs) such as legacy IOP 204, which includes I/O hardware of a type typically found on a legacy platform. Legacy IOP 204 provides an interface between main memory 100 and the HBAs such as fibre channel HBA 106 and SCSI HBA 108. Legacy OS 200 includes data protection and other security features that ensures that I/O operations initiated by the legacy OS will maintain the data stored within mass storage devices 109 in a coherent state. The legacy OS also has sophisticated protection mechanisms in place to guard against unintentional or unauthorized data deletions or updates.”)(e.g., paragraph [0063] and [0157]).
Regarding claim 20, Crandall discloses a computer program product comprising a non-transitory computer readable medium retaining program instructions, which instructions when read by a processor, cause the processor to perform: (e.g., paragraphs [0037] and [0049])
interpreting data in a first environment structure of a first format used in a first environment to a second structure of a second format used in a second environment, the data as interpreted stored in an intermediate storage; (“According to the illustrated system, a legacy OS 200 of the type that is generally associated with mainframe systems is loaded into main memory 100. This legacy OS, which may be the 2200 OS commercially available from Unisys Corporation, is adapted to execute directly on a "legacy platform", which may be a mainframe system such as a 2200 or an A-series data processing system commercially available from the Unisys Corporation. Alternatively, this legacy platform may be some other enterprise-type environment that provides the security, data protection, and recovery mechanisms generally associated with mainframe systems. Such mechanisms are provided to prevent unintentional deletions or updates to data stored on mass storage devices 109. These mechanisms also ensure that the data is maintained in a coherent state.”)(e.g., paragraph [0057])
activating a program in the second environment, wherein the program is configured to use data from the intermediate storage, to produce output to be stored in a second intermediate storage; and (“In one embodiment, legacy OS 200 may be implemented using a different machine instruction set (hereinafter, "legacy instruction set", or "legacy instructions") than that which is native to IP(s) 104. This legacy instruction set is the instruction set which is executed by the IPs of a legacy platform on which the legacy OS is intended to operate. In this embodiment, the legacy instruction set used to implement legacy OS is emulated by an emulation environment 202. The details associated with the operation of emulation environment 202 are largely beyond the scope of this disclosure. More information regarding the operation of this environment may be found in the commonly-assigned U.S. patent application entitled "System and Method for Synchronizing Memory Management Functions of Two Disparate Operating Systems", attorney docket number RA-5827, filed on even date herewith.”)(e.g., paragraph [0058])
upon the program termination, interpreting the output in the second intermediate storage from the second structure to the first structure, wherein interpreting the data and the output is performed using a mapper which maps between the first format and the second format, and wherein the first format is different from the second format at least in that at least one data field in the first format is absent in the second format, or at least one data field in the second format is absent in the first format, or in that at least one data field in the first format is formatted differently in the second format, or data fields in the second format have different order from data fields in the first format. ("If legacy OS 200 were operating on a legacy platform, legacy IOP 204 would be monitoring the designator in the initiation queue to determine when request packet 302 is ready for processing. Legacy IOP 204 would then process this packet directly without use of any intermediate translating step. However, two characteristics of the current system make some translation necessary before legacy IOP may process the packet. First, the request packet 302 resides in virtual address space. In other words, the address contained in entry 305 is a virtual address. Moreover, all addresses stored within the BD buffer that point to data buffers are virtual addresses, as will be described further below. These addresses cannot be used directly by the legacy IOP 204, which expects all addresses to be physical addresses to physical memory devices. Thus, translation is required to translate all virtual addresses to physical addresses." "In view of the foregoing, when the designator bit of entry 305 is set, IOP driver 206 nails all of the memory used for the BD buffer so that it is not paged out of memory while that buffer is being used during the 1/0 operation. The IOP driver also translates each virtual address that is stored within the request packet into one or more physical addresses that map to the virtual address. To accomplish this address translation, IOP driver 206 calls various standard memory management utilities of commodity OS _113. These utilities convert virtual addresses into physical addresses. The physical addresses that are returned by the commodity OS 113 in response to these calls are used by IOP driver 206 to create a translated request packet 304. In one embodiment, each BD of the original request packet will be translated into multiple BDs of the translated request packet 304. This is discussed in detail below.")(e.g., paragraphs [0090]-[0092]).
Claim 21 has substantially similar limitations as stated in claim 2; therefore, it is rejected under the same subject matter.
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD L BOWEN whose telephone number is (571)270-5982. The examiner can normally be reached Monday through Friday 7:30AM - 4:00PM EST.
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, Aleksandr Kerzhner can be reached at (571)270-1760. 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.
/RICHARD L BOWEN/Primary Examiner, Art Unit 2165