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 .
DETAILED ACTION
Response to Amendment
This is a reply to the request for Continued Examination (RCE) filed on 11/06/2025, in which Claim(s) 1-20 are presented for examination.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/06/2025 has been entered.
Response to Arguments
Double Patenting Rejection:
Applicant’s remarks regarding the Double Patenting rejection on pg. 9 of the remarks filed on 10/20/2025 has been considered; however, The Examiner respectfully disagrees, as the claims is clearly broader and is anticipated by the parent application.
Claim Rejections - 35 U.S.C. § 102 and 35 U.S.C. § 103:
Since Applicant’s did not clarify the “processing technique”, as such the combination of Aerdts-Bennett identifying the applications identifier, the resources requirements and application group identifier (generic identifier), mapping them based on resource/policy requirement, would read on the claimed limitations.
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim(s) 1, 8 and 15 is/are rejected on the ground of nonstatutory double patenting over claim(s) 1, 7 and 13 of U.S. Patent No. 11,763,034 since the claims, if allowed, would improperly extend the “right to exclude” already granted in the patent.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent and the application are claiming common subject matter, as follows: The pending application is anticipated by the parent patents, in which the current application is broader in scopes and is fully covered by the patent.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Aerdts et al. (US 20170048314 A1; hereinafter Aerdts) in view of Bennett et al. (US 20110055926 A1; hereinafter Bennett) further in view of Diwakar (US 20140237016 A1).
Regarding claims 1, 8 and 15, Aerdts discloses a device, comprising:
one or more memories (memories 228 [Aerdts; ¶21]); and
one or more processors to (processor 226 [Aerdts; ¶21]):
map a first application resource [tag to a generic identifier] based on processing the first application resource [tag] with a processing technique, wherein the first application resource [tag] is associated with an application and is used by a first cloud domain (At block 102, first resources of a first cloud, a first dependency between the first resources, and second resources of a second cloud may be automatically discovered. At block 104, a migration map between the first cloud and the second cloud may be generated based on the discovered first and second resources. At block 303, the cloud controller 224 may register with the cloud service provider 204 to obtain access to and discover the cloud topology, i.e. resources and dependences, of the cloud 202. Discovery of resources may include discovery of attributes of the resources. The discovered resources may include any of the resources described earlier in reference to FIG. 2a, including all the examples discussed earlier with reference to the hardware 210, virtual hardware 214, software 218, data 216, and the cloud computing services implemented using the hardware 210, virtual hardware 214, software 218, and data 216. The cloud controller 224 may discover the resources automatically. The discovered resources may include discovered hardware, software, data, and cloud computing services. Turning back to FIG. 3, at block 304, the cloud controller 224 may generate a model 240 of cloud 202 based on the resources discovered at block 303 and/or based on the prior knowledge in the repository data 246 such as previously discovered models or archetype models [Aerdts; ¶11-13, 26-44]; Fig. 1, 3 and associated texts]). Aerdts discloses first resources of a first cloud, a first dependency between the first resources, and second resources of a second cloud may be automatically discovered. Second resources of a second cloud may be discovered. A migration map between the first cloud and the second cloud may be generated based on the discovered first and second resources. The migration map may be recursively modified to increase accuracy of the migration map. Aerdts does not explicitly discloses wherein the generic identifier includes a field or a tag to identify the application; however, in a related and analogous art, Bennett teaches this feature.
In particular, Bennett teaches first identifying the application (process method), mapping of application identifier (i.e., app1, app2 - tag) to application group identifier (ie., group1, group2, etc., - generic identifier), and mapping of application group to security policy. Thus, as long as the application group are mapped to the security policy, the security policy would apply to all the applications within the group. [Bennett; ¶74-93; Figs. 5-6 and associated text]. It would have been obvious before the effective filing dated of the claimed invention to modify Aerdts in view of Bennett application group mapping with the motivation to easier change security policy to multiple application at once.
map a second application resource tag to the generic identifier based on processing the second application resource tag with the processing technique to determine that the second application resource tag relates to the application, wherein the second application resource tag is used by a second cloud domain that is different than the first cloud domain (At block 104, a migration map between the first cloud and the second cloud may be generated based on the discovered first and second resources. At block 306, the cloud controller 224 may register with the cloud service provider 208 to obtain access to and discover the cloud topology, i.e. resources and dependencies, of the cloud 206. Discovery of resources may include discovery of attributes of the resources. The discovered resources may include any of the resources described earlier in reference to FIG. 2a, including all the examples discussed earlier with reference to the hardware 212, virtual hardware 215, software 220, data 217, and the cloud computing services implemented using the hardware 212, virtual hardware 215, software 220, and data 217. As with cloud 202, the cloud controller 224 may discover the flavor of the cloud 206. The cloud controller 224 may discover the resources automatically. Because the cloud 206 is to be on the receiving end of the migration, the discovered resources of the cloud 206 may include capacity attributes of the resources of cloud 206 specifying resource capacities of the cloud 206. For example, capacity attributes of hardware resources may be discovered, such as storage, network, and data center specific information, for example power constraints, processing constraints, storage constraints, and the number of available racks of computing devices and/or servers. Capacity attributes may include capacity attributes of other resources such as software. Capacity attributes may include, for example, whether the cloud 206 allows use of physical servers and/or the use of virtual IP addresses. Capacity attributes may include firewall policies. Capacity attributes may include whether the migration to cloud 206 can be accomplished with zero down time, which is a time during migration when neither the cloud 202 nor the cloud 206 is fully operational. For example, there may be down time during migration from or to clouds having certain relation database service rules provided by certain cloud service providers. In examples in which there is zero down time, there is no service interruption during migration in providing cloud computing services. To facilitate a smooth migration, the discovered capacity attributes of cloud 206 may allow determination of possible changes that need to be made to resources that may be migrated from cloud 202 to 206. In some examples, attributes of resources, such as attributes of applications, of the cloud 202 may be discovered based on the capacity attributes of cloud 206 discovered at block 306. Such attribute discovery of cloud 202 may aid in determining changes that need to be made to resources of cloud 202 that may be migrated. However, in other examples, these attributes of cloud 202 may have been discovered during the initial discovery of cloud 202 at block 303. At block 308, based on the resources discovered at block 303, based on prior knowledge in the repository data 246 such as archetype migration maps, and/or based on the model 240 of the cloud 202 generated at block 304, the cloud controller 224 may generate a migration map 242 between the resources of cloud 202 and the resources of cloud 206 as it will be configured after migration is complete. Thus, the cloud controller 224 may also generate a model 244 of the resources of cloud 206 to represent the resources of cloud 206 after the migration is complete. The model 244 of cloud 206 and the migration map 242 may be stored in a document on the cloud controller 224. The model 244 of the cloud 206 and the migration map 242 may be generated automatically, for example using machine learned models such as Semantic Web frameworks. However, in some examples, the generation of the model 244 of the cloud 206 and the migration map 242 may additionally be based at least partly on input from an a user, such as an IT professional, using a user input device 234 of the cloud controller 224. The migration map 242 may express changes that are necessary to migrate resources from the cloud 202 to the cloud 206. The migration map 242 may be represented and/or stored as data structure of any kind, for example a table such as Table 1 below, that describes attributes of the mapping. Although Table 1 shows mappings of various cloud computing services as an example, mappings of other resources, including hardware, software, applications, and data, may also be included in a migration map [Aerdts; ¶11-13, 45-56; Fig. 1, 3 and associated texts], mapping of application identifier (i.e., app1, app2 - tag) to application group identifier (ie., group1, group2, etc., - generic identifier), and mapping of application group to security policy. Thus, as long as the application group are mapped to the security policy, the security policy would apply to all the applications within the group. [Bennett; ¶74-93; Figs. 5-6 and associated text]); and
provide information indicating an action to the first cloud domain and the second cloud domain based on the generic identifier to permit the first cloud domain or the second cloud domain to perform the action (At block 104, a migration map between the first cloud and the second cloud may be generated based on the discovered first and second resources. At block 106, the migration map may be recursively modified to increase accuracy of the migration map. At block 108, the first resources may be migrated to the second cloud based on the migration map. At blocks 310 to 316, the cloud controller 224 may iteratively modify the migration map 242 and/or the model 244. The modification may be performed recursively, for example each iteration of blocks 310 to 316 may build upon the output of a respective previous iteration of blocks 310 to 316. Recursive modification may be to increase the accuracy of the migration map 242 and/or the model 244. The blocks 310 to 316 are described in more detail below. At block 310, the cloud controller 224 may, for example, determine whether the migration map 242 and/or model 244 has one or more errors. For example, the cloud controller 224 may simulate a migration from cloud 202 to cloud 206 to validate whether the migration map 242, and thus model 244, is valid and will be able to be used successfully in an actual migration. The cloud controller 224 may output simulation results of the simulated migration on an output device 236 for viewing by a user, such as an IT professional. At block 312, the cloud controller 224 may determine, based on the analysis, whether the migration map 242 and/or model 244 are to be modified. For example, the cloud controller 224 may determine, based on the simulation results, that the migration map 242 is valid or invalid. The migration map 242 may be invalid because, for example, it contains an error, e.g. it contains an inconsistency, prohibited attribute, or does not comply with a specification for the migration map 242 and/or model 244. For example, the specification may mandate that the migration map 242 and/or model 244 have specific attributes, such as satisfy certain security standards. In some examples, the specification may be user defined. At block 314, the migration map 242 and/or model 244 may be modified based on additional automated resource discovery of the clouds 202 and 206 and/or user input. [Aerdts; ¶11-13, 57-63; Fig. 1, 3 and associated texts]).
Aerdts-Bennett combination discloses resources map between the first cloud and the second cloud may be generated based on the discovered first and second resources. The migration map may be recursively modified to increase accuracy of the migration map. Aerdts-Bennett combination does not explicilty discloses provide information indicating an action to the first cloud domain and the second cloud domain based on the generic identifier to permit the first cloud domain and the second cloud domain to perform the action; however, in a related and analogous art, Diwakar teaches this feature.
In particular, Diwakar teaches cloud governance module may identify an application executing on one or more servers belonging to a respective plurality of cloud computing service providers C1-Cn and determined the complaints. The cloud governance hand-off the policies to all the necessary clouds to properly executes the application [Diwakar; ¶22-34; Figs. 2A-2B and associated text]. It would have been obvious to one with ordinary skill in the art at time of invention to modify Aerdts-Bennett combination in view of Diwakar to hand-off policies to other clouds with the motivation to make sure the complaints and properly executing the application on different clouds domain.
Regarding claim 2, Aerdts-Bennett-Diwakar Combination discloses the device of claim 1, wherein the one or more processors are further to: dynamically determine that the application is present in the second cloud domain based on the second application resource tag and a second address associated with the application (discovered application(s) in a cloud computing environment accordingly, a physical server may be mapped to a virtual server, dynamic IP address may be mapped to static IP address, or real IP addresses may be masked with virtual IP addresses in cloud 206. In further examples, mapped resources may have different versions, or resource capabilities may be different e.g. cell and block storage may be different across mapped resources [Aerdts; ¶40-41, 52-53; Fig. 3-5 and associated texts]).
Regarding claim 3, Aerdts-Bennett-Diwakar Combination discloses the device of claim 1, wherein the one or more processors are further to: provide policy information to the first cloud domain based on the generic identifier to permit the first cloud domain to perform the action (policy for the cloud to performed set actions [Aerdts; ¶55-56; Fig. 3-4 and associated texts]).
Regarding claim 4, Aerdts-Bennett-Diwakar Combination discloses the device of claim 1, wherein the first application resource tags is used for identifying the application and an Internet protocol (IP) address associated with the application (a mapping may map a resource of cloud 202 with a resource of cloud 206 having a different property than the resource of cloud 202. For example, a physical server may be mapped to a virtual server, dynamic IP address may be mapped to static IP address, or real IP addresses may be masked with virtual IP addresses in cloud 206. In further examples, mapped resources may have different versions, or resource capabilities may be different e.g. cell and block storage may be different across mapped resources [Aerdts; ¶52-53; Fig. 3-4 and associated texts]).
Regarding claim 5, Aerdts-Bennett-Diwakar Combination discloses the device of claim 1, wherein the one or more processors are further to: store the second application resource tag associated with the second cloud domain in a data structure (the information is stored at the database at the cloud domain [Aerdts; ¶27-28, 39-41; Fig. 3-5 and associated texts]).
Regarding claim 6, Aerdts-Bennett-Diwakar Combination discloses the device of claim 1, wherein the generic identifier may include a first field to identify the application and a second field to identify types associated with the application (mapping tied to resources to application, declarative languages and other representations [Aerdts; ¶27-28, 39-41; Fig. 3-5 and associated texts]).
Regarding claim 7, Aerdts-Bennett-Diwakar Combination discloses the device of claim 1, wherein the action includes one or more of: a security action to be applied to the application, a business action to be applied to the application, or a network action to be applied to the application (policy for the cloud to performed set actions [Aerdts; ¶55-56; Fig. 3-4 and associated texts]).
Regarding claim 9, Aerdts-Bennett-Diwakar Combination discloses the method of claim 8, wherein the action includes one or more of: a security action to be applied to the application, a business action to be applied to the application, or a network action to be applied to the application (policy for the cloud to performed set actions [Aerdts; ¶55-56; Fig. 3-4 and associated texts]).
Regarding claim 10, Aerdts-Bennett-Diwakar Combination discloses the method of claim 8, wherein providing the information indicating the action comprises: providing information indicating the action based on the generic identifier and an Internet protocol (IP) address (policy for the cloud to performed set actions [Aerdts; ¶55-56; Fig. 3-4 and associated texts], based on a mapping may map a resource of cloud 202 with a resource of cloud 206 having a different property than the resource of cloud 202. For example, a physical server may be mapped to a virtual server, dynamic IP address may be mapped to static IP address, or real IP addresses may be masked with virtual IP addresses in cloud 206. In further examples, mapped resources may have different versions, or resource capabilities may be different e.g. cell and block storage may be different across mapped resources [Aerdts; ¶52-53; Fig. 3-4 and associated texts]).
Regarding claim 11, Aerdts-Bennett-Diwakar Combination discloses the method of claim 8, wherein the first application resource tags is used for identifying the application and an Internet protocol (IP) address associated with the application (a mapping may map a resource of cloud 202 with a resource of cloud 206 having a different property than the resource of cloud 202. For example, a physical server may be mapped to a virtual server, dynamic IP address may be mapped to static IP address, or real IP addresses may be masked with virtual IP addresses in cloud 206. In further examples, mapped resources may have different versions, or resource capabilities may be different e.g. cell and block storage may be different across mapped resources [Aerdts; ¶52-53; Fig. 3-4 and associated texts]).
Regarding claim 12, Aerdts-Bennett-Diwakar Combination discloses the method of claim 8, wherein the first cloud domain or the second cloud domain includes: a public cloud domain, a private cloud domain, or a legacy data center domain (can be public or private entities [Aerdts; ¶12-14; Fig. 2a-2b and associated texts]).
Regarding claim 13, Aerdts-Bennett-Diwakar Combination discloses the method of claim 8, further comprising: receiving a third application resource tag and a third address associated with a second application; processing the third application resource tag with to determine which application resource tag relate to the second application and are to be mapped to a second generic identifier; and mapping the third application resource tag to the second generic identifier based on the third application resource tag being related to the second application (the process are the same through multiple cloud domains [Aerdts; ¶12-14; Fig. 2a-2b and associated texts]).
Regarding claim 14, Aerdts-Bennett-Diwakar Combination discloses the method of claim 8, wherein mapping the first application resource tag to the generic identifier comprises: mapping the first application resource tag to the generic identifier based on processing the first application resource tag with a processing technique; and wherein mapping the second application resource tag to the generic identifier based on processing the second application resource tag comprises: mapping the second application resource tag to the generic identifier based on processing the second application resource tag with the processing technique (a mapping may map a resource of cloud 202 with a resource of cloud 206 having a different property than the resource of cloud 202. For example, a physical server may be mapped to a virtual server, dynamic IP address may be mapped to static IP address, or real IP addresses may be masked with virtual IP addresses in cloud 206. In further examples, mapped resources may have different versions, or resource capabilities may be different e.g. cell and block storage may be different across mapped resources [Aerdts; ¶52-53; Fig. 3-4 and associated texts]).
Regarding claim 16, Aerdts-Bennett-Diwakar Combination discloses the non-transitory computer-readable medium of claim 15, wherein the generic identifier provides a common nomenclature for the application that maps to different nomenclatures utilized by the first cloud domain and the second cloud domain to identify the application (a mapping may map a resource of cloud 202 with a resource of cloud 206 having a different property than the resource of cloud 202. For example, a physical server may be mapped to a virtual server, dynamic IP address may be mapped to static IP address, or real IP addresses may be masked with virtual IP addresses in cloud 206. In further examples, mapped resources may have different versions, or resource capabilities may be different e.g. cell and block storage may be different across mapped resources [Aerdts; ¶52-53; Fig. 3-4 and associated texts]).
Regarding claim 17, Aerdts-Bennett-Diwakar Combination discloses the non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the one or more processors to: dynamically determine that the application is present in the second cloud domain based on the second application resource tag and a second address associated with the application (At block 104, a migration map between the first cloud and the second cloud may be generated based on the discovered first and second resources. At block 306, the cloud controller 224 may register with the cloud service provider 208 to obtain access to and discover the cloud topology, i.e. resources and dependencies, of the cloud 206. Discovery of resources may include discovery of attributes of the resources. The discovered resources may include any of the resources described earlier in reference to FIG. 2a, including all the examples discussed earlier with reference to the hardware 212, virtual hardware 215, software 220, data 217, and the cloud computing services implemented using the hardware 212, virtual hardware 215, software 220, and data 217. As with cloud 202, the cloud controller 224 may discover the flavor of the cloud 206. The cloud controller 224 may discover the resources automatically. The map 242 may be represented and/or stored as data structure of any kind, for example a table such as Table 1 below, that describes attributes of the mapping. Although Table 1 shows mappings of various cloud computing services as an example, mappings of other resources, including hardware, software, applications, and data, may also be included in a migration map [Aerdts; ¶11-13, 45-56; Fig. 1, 3 and associated texts]).
Regarding claim 18, Aerdts-Bennett-Diwakar Combination discloses the non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the one or more processors to map the second application resource tag to the generic identifier based on processing the second application resource tag with the processing technique to determine that the second application resource tag relates to the application, cause the one or more processors to: map the second application resource tag to the generic identifier based on processing the second application resource tag with one or more of: a natural language processing technique, a computational linguistics technique, or a text analysis technique (the present disclosure may provide for intelligent discovery that may be automated, iterative, and/or recursive. This may allow for determining a migration map for migrating cloud resources from an origin cloud to a destination cloud. The migration map may include mappings and complexity indicators representing complexity of migrations. Additionally, automated discovery may utilize declarative languages, e.g. semantic technologies, to model the migrations in an abstracted way such that the migrations may be made across any types of clouds and cloud service providers. Thus, an organization may more easily and flexibly migrate to different clouds as the need or desire arises, and may better track cloud resources. Additionally, the present disclosure may provide faster migration service, and may reduce errors in migration and manual labor involved in migration [Aerdts; ¶10]).
Regarding claim 19, Aerdts-Bennett-Diwakar Combination discloses the non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the one or more processors to: provide policy information to the first cloud domain based on the generic identifier to permit the first cloud domain to perform the action (policy for the cloud to performed set actions [Aerdts; ¶55-56; Fig. 3-4 and associated texts]).
Regarding claim 20, Aerdts-Bennett-Diwakar Combination discloses the non-transitory computer-readable medium of claim 15, wherein the first cloud domain is different than the second cloud domain (can be public or private entities [Aerdts; ¶12-14; Fig. 2a-2b and associated texts]).
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http:ljwww.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jain et al. (US 20160294728 A1) discloses a method for dynamic network service allocation that maps generic services into specific configurations of service resources in a network is provided. An application that is assigned to be performed by computing resources in the network is associated with a set of generic services, and the method maps the set of generic services to the service resources based on the assignment of the application to the computing resources. The mapping of generic services is further based on a level of service that is chosen for the application, where the set of generic services are mapped to different sets of network resources according to different levels of services.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAO Q HO whose telephone number is (571)270-5998. The examiner can normally be reached on 7:00am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DAO Q HO/Primary Examiner, Art Unit 2432