DETAILED ACTION
This action is in response to the application filed on 25 July 2024.
Claims 1-20 are under examination.
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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception without reciting additional elements sufficient to amount to significantly more than the exception.
Claim 1 recites operations including receiving information regarding a distributed resource, determining a geographic location and resource type, inputting the information into a recommendation model utilizing a linear programming algorithm, optimizing an objective function subject to constraints, determining a recommended network allocation site, and generating a recommendation for display. These limitations recite mathematical concepts, including mathematical calculations and optimization using linear programming, as well as mental processes involving evaluation of information and recommending a result.
The additional elements, including one or more processors, non-transitory computer-readable media, cloud computing resources, a user interface, and network allocation sites, merely implement the abstract idea on generic computer components performing their ordinary functions of receiving, processing, storing, and displaying information.
The claims do not integrate the abstract idea into a practical application. In particular, the claims do not recite automatically provisioning computing resources, modifying network routing, controlling operation of cloud infrastructure, or improving the functioning of a computer or network. Rather, the claims merely determine a recommended allocation site and generate a recommendation for display.
The additional elements, individually and in combination, amount to no more than well-understood, routine, and conventional computer functions and therefore do not amount to significantly more than the judicial exception itself.
Accordingly, claims 1, 2, and 17-20 are ineligible under 35 U.S.C. §101.
Claims 3–16 depend from claim 2 and therefore incorporate all of claim 2’s limitations. The additional limitations of claims 3–16 merely further specify the information collected or analyzed, the mathematical variables and constraints used in the optimization, the manner in which data is organized or displayed, or generic model-training operations. These additional limitations do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea.
In particular, claims 3 and 4 add obtaining location and resource-type information from a user request; claims 5–9 add mathematical decision variables and constraints; claims 10 and 11 add determining location and resource type from user or resource information; claim 12 adds applying the same recommendation process to another resource; claim 13 adds retrieving historical data and generically training the recommendation model; claims 14 and 15 add organizing efficiency or distance information in a matrix; and claim 16 adds applying a Boolean mask to matrix values. These limitations constitute additional data gathering, mathematical processing, data organization, and generic computer implementation and do not provide a technological improvement.
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Ziafat et al., “A hierarchical structure for optimal resource allocation in geographically distributed clouds,” in view of Kodialam et al., US 2013/0290539 A1.
With respect to claim 1:
As to “A system for dynamically selecting geographic locations for network allocation sites of distributed resources in a cloud computing network, the system comprising: one or more processors; and one or more non-transitory, computer-readable mediums, comprising instructions that, when executed by one or more processors, cause operations comprising:”, Ziafat teaches a computerized system for selecting datacenters and allocating virtual machines in a geographically distributed cloud. Ziafat’s system includes geographical-region brokers, middle brokers, and cloud/datacenter brokers having monitoring, database, management, and decision-making components that execute algorithms for datacenter and VM selection. See Ziafat, §§ 3, 3.1, 3.1.1–3.1.4; Figs. 2–5.
As to “receiving a first distributed resource, of a plurality of distributed resources, for allocation, wherein the first distributed resource comprises a first cloud computing resource used by a first user;”, Ziafat teaches receiving a user request specifying cloud resources, including the number and hardware properties of requested VMs, and allocating qualified VMs from geographically distributed datacenters to the user request. See Ziafat, § 3.1, subsection “User request”; Table 2; § 3.1.4, steps 1–6; procedure “DETERMINER,” steps 1–5.
As to “determining a first geographic location for the first distributed resource;”, Ziafat teaches determining and maintaining geographic-location information for resources and resource-allocation entities. In particular, Ziafat stores geographic distances between geographical brokers, middle brokers, and datacenters; calculates distances using longitude and latitude; sorts middle brokers based on their distance from the user; and selects geographically appropriate brokers and datacenters. See Ziafat, § 3.1.1; Fig. 3; Eq. (1); procedure “DETERMINER,” steps 3–4; § 3.1.2; Fig. 4.
As to “determining a first type for the first distributed resource;”, Ziafat teaches that each user request contains a “type of requested resource” and requested hardware characteristics, including MIPS, RAM, storage, and bandwidth. Ziafat also distinguishes among different VM types having different hardware characteristics. See Ziafat, § 3.1.1, discussion following Fig. 3; Table 2; § 4.2.2; Table 5.
As to “inputting the first geographic location and the first type into a network allocation site recommendation model to generate a first output,”, Ziafat teaches inputting a user request containing user location, requested resource type, and requested hardware characteristics into its hierarchical allocation model. The geographical broker and middle broker use that information, together with stored geographic and resource information, to select a suitable datacenter and return the selected datacenter specification or identifier. See Ziafat, § 3.1.1; Table 2; procedure “DETERMINER,” steps 2–5; § 3.1.2, procedure “MANAGE,” steps 3–4; § 3.1.4, steps 1–6.
As to “wherein the network allocation site recommendation model uses a linear programming algorithm,”, Ziafat expressly teaches using a Simplex Linear Programming method to select an optimal datacenter from geographically distributed datacenters. The middle broker invokes the LP algorithm in response to a “Select DC” command and returns the selected datacenter to the geographical broker. See Ziafat, § 3; § 3.1.2, procedure “MANAGE,” steps 3–4; § 3.1.4, steps 2–4; § 3.2.3.
As to “wherein an objective function of the linear programming algorithm comprises a maximum aggregated allocation efficiency for a subset of the plurality of distributed resources at a proposed geographic location for a proposed network allocation site,”, Ziafat teaches generating candidate permutations or compositions of datacenters and evaluating each candidate composition using an LP fitness function. The fitness function aggregates weighted objective values for availability, reliability, cost, response time, and geographic distance to select an optimal datacenter or datacenter composition. See Ziafat, § 3.2.3, steps 1–3; Eqs. (13)–(16). In particular, Eq. (16) represents the sum of weighted objectives for the datacenters in a candidate composition. Under the broadest reasonable interpretation, this aggregate fitness value constitutes an aggregated allocation-efficiency measure for a proposed datacenter allocation.
As to “wherein a first decision variable for the objective function comprises a predicted net efficiency for each distributed resource in the subset of the plurality of distributed resources,”, Ziafat teaches determining, normalizing, weighting, and combining the QoS values associated with each candidate datacenter, including availability, reliability, cost, response time, and geographic distance. The resulting fitness contribution for each candidate reflects the overall suitability of placing resources at that candidate datacenter. See Ziafat, §§ 3.2.1–3.2.3; Eqs. (4)–(12), (15a), (15b), and (16). Under the broadest reasonable interpretation, the resulting composite fitness contribution corresponds to a predicted net efficiency because it represents the net allocation suitability obtained by combining positive and negative efficiency factors.
As to “wherein a second decision variable for the objective function comprises a distance for each distributed resource in the subset of the plurality of distributed resources from a respective current location to the proposed geographic location,”, Ziafat teaches calculating geographic distances among users, geographical brokers, middle brokers, and datacenters and expressly includes geographic distance as a weighted objective in the LP fitness function. See Ziafat, § 3.1.1; Eq. (1); procedure “DETERMINER,” steps 3–4; § 3.2.3, step 3; Eqs. (15b) and (16). Ziafat states that the negative objectives normalized for the LP include “the geographic distance between the datacenter and the middle broker.”
As to “wherein a first constraint for the objective function comprises a minimum net efficiency for each distributed resource in the subset of the plurality of distributed resources,”, Ziafat teaches applying SLA threshold constraints to candidate datacenter compositions. Specifically, the average availability and reliability of a candidate composition must be greater than or equal to the minimum availability and reliability requested by the user, while average cost and response time must be less than or equal to the user’s maximum acceptable values. See Ziafat, § 3.1, Table 2; § 3.2.3, step 2; Eqs. (14a)–(14d). Under the broadest reasonable interpretation, the minimum availability and reliability requirements constitute minimum efficiency requirements for the candidate resources.
Ziafat does not expressly teach “wherein a second constraint for the objective function comprises a maximum distance for each distributed resource in the subset of the plurality of distributed resources from a respective current location to the proposed geographic location.”
Kodialam teaches that a cloud-resource request may include a distance constraint requiring the selected device to be within a maximum geographic distance, such as a number of miles, or a maximum network distance, such as a number of network hops, from the client, another allocated resource, or another point of reference. Kodialam further teaches identifying devices satisfying the constraint and selecting the highest-weight device among those constrained candidates. See Kodialam ¶¶ 29, 38–41, 46, 48, 53, 55–56, 62; claims 3–5 and 11–13.
It would have been obvious to incorporate Kodialam’s maximum geographic or network distance constraint into Ziafat’s LP-based datacenter-selection model. Both references concern allocating cloud resources among geographically distributed datacenters, and Kodialam teaches that selecting resources subject to geographic or network distance constraints reduces propagation delay and satisfies user geographic preferences. The modification would have predictably constrained Ziafat’s optimized candidate datacenters to those located within an acceptable distance while retaining Ziafat’s optimization of availability, reliability, cost, response time, and geographic distance.
As to “determining, based on the first output, a first geographic reference point for a first network allocation site of a plurality of network allocation sites, wherein each of the plurality of network allocation sites comprises a respective geographic reference point for allocating one or more of a plurality of distributed resources;”, Ziafat teaches determining a selected datacenter based on the LP output and associating geographically distributed datacenters and brokers with geographic regions, longitude, latitude, and geographic-distance information. See Ziafat, § 3.1.1; Figs. 2–4; Eq. (1); § 3.1.2, procedure “MANAGE,” steps 3–4; § 3.1.4, steps 2–4. Ziafat does not, however, expressly characterize the location used for the selected site as the claimed “geographic reference point.”
Kodialam teaches measuring a distance constraint relative to a client, another allocated resource, or “some other point of reference.” Kodialam further teaches a request that resources be allocated near the city of Chicago, whereby Chicago constitutes a geographic reference location used to identify a qualifying allocation site. See Kodialam ¶¶ 35, 38–41.
It would have been obvious to apply Kodialam’s geographic-reference-point technique to Ziafat’s geographically distributed datacenter-selection system so that candidate and selected datacenters could be evaluated relative to a user location, specified city, previously allocated resource, or other geographic point. Doing so would predictably enable Ziafat’s system to enforce geographic-placement preferences and maximum-distance requirements.
As to “generating for display, on a user interface, a first recommendation for using the first network allocation site for the first distributed resource based on the first geographic reference point,”, Ziafat teaches returning the identifier of the selected datacenter to the geographical broker, returning the identifiers of selected VMs to the user, informing the user of the assignment, and allowing the user to accept the selected assignment. See Ziafat, procedure “DETERMINER,” step 5; § 3.1.4, steps 4–12; Fig. 5. Ziafat does not expressly state that the selected allocation is generated for display on a user interface.
Kodialam teaches that, after selecting a cloud device, the resource manager transmits a response to the requesting client indicating the location of the allocated resource. Kodialam further teaches that the client may be a desktop computer, laptop, tablet, mobile device, server, or blade and that a user may interact with an application through the client device. See Kodialam ¶¶ 32, 45.
It would have been obvious to generate Ziafat’s selected datacenter and VM assignment for display through the requesting user’s conventional client interface. Both references communicate the selected cloud-resource location or assignment to the requesting user or client, and displaying that communicated selection would have been a predictable use of a conventional user interface to permit the user to review and accept the proposed allocation.
Accordingly, claim 1 would have been obvious over Ziafat in view of Kodialam. Ziafat’s cited disclosure is contained principally in §§ 3.1–3.2.3, Figs. 2–5, Tables 1–2 and 5, and Eqs. (1), (13)–(16).
With respect to claim 2:
As to “A method for dynamically selecting geographic locations for network allocation sites of distributed resources, the method comprising:”, Ziafat teaches a method for selecting datacenters and allocating cloud resources among geographically distributed cloud datacenters. Ziafat’s method uses a hierarchical structure of geographical-region brokers, middle brokers, and datacenter brokers to select an appropriate datacenter and allocate virtual machines based on geographic and resource requirements. See Ziafat, §§ 3, 3.1, 3.1.1–3.1.4; Figs. 2–5.
As to “receiving a first distributed resource, of a plurality of distributed resources, for allocation, wherein the first distributed resource comprises a first cloud computing resource used by a first user;”, Ziafat teaches receiving a user request for one or more cloud computing resources, including virtual machines, and allocating qualified VMs from geographically distributed datacenters to satisfy the request. The user request identifies the number and hardware properties of the requested resources. See Ziafat, § 3.1, “User request”; Table 2; § 3.1.4, steps 1–6; procedure “DETERMINER,” steps 1–5.
As to “determining a first geographic location for the first distributed resource;”, Ziafat teaches determining geographic-location information using longitude and latitude and calculating geographic distances among the user, geographical brokers, middle brokers, and datacenters. Ziafat stores geographic-distance information in the broker databases and uses the information when selecting resources and datacenters. See Ziafat, § 3.1.1; Fig. 3; Eq. (1); procedure “DETERMINER,” steps 3–4; § 3.1.2; Fig. 4.
As to “determining a first type for the first distributed resource;”, Ziafat teaches that each user request includes a “type of requested resource” and hardware characteristics such as MIPS, RAM, storage, and bandwidth. Ziafat also discloses multiple VM types having different resource characteristics. See Ziafat, § 3.1.1, discussion following Fig. 3; Table 2; § 4.2.2; Table 5.
As to “inputting the first geographic location and the first type into a network allocation site recommendation model to generate a first output,”, Ziafat teaches inputting a user request containing user-location information and requested-resource type and characteristics into its hierarchical allocation model. The geographical and middle brokers use the request information, together with stored geographic and resource information, to identify a suitable datacenter and return the selected datacenter identifier or specification as an output. See Ziafat, § 3.1.1; Table 2; procedure “DETERMINER,” steps 2–5; § 3.1.2, procedure “MANAGE,” steps 3–4; § 3.1.4, steps 1–6.
As to “wherein the network allocation site recommendation model uses a linear programming algorithm,”, Ziafat expressly teaches applying a Simplex Linear Programming method to select an optimal datacenter from geographically distributed datacenters. The middle broker uses the LP algorithm to select a datacenter satisfying the user request and returns the selected datacenter to the geographical broker. See Ziafat, § 3; § 3.1.2, procedure “MANAGE,” steps 3–4; § 3.1.4, steps 2–4; § 3.2.3.
As to “wherein an objective function of the linear programming algorithm comprises a maximum aggregated allocation efficiency for a subset of the plurality of distributed resources at a proposed geographic location for a proposed network allocation site,”, Ziafat teaches generating candidate permutations or compositions of datacenters and evaluating each candidate using an LP fitness function that aggregates weighted objective values, including availability, reliability, cost, response time, and geographic distance. Ziafat normalizes and weights the objectives and combines them to identify an optimal datacenter or datacenter composition. See Ziafat, § 3.2.3, steps 1–3; Eqs. (13)–(16). Under the broadest reasonable interpretation, Ziafat’s aggregate fitness value constitutes an aggregated allocation-efficiency measure for resources at a proposed datacenter location.
As to “wherein a first constraint for the objective function comprises a minimum net efficiency for each distributed resource in the subset of the plurality of distributed resources;”, Ziafat teaches applying SLA threshold constraints to candidate datacenter compositions. Specifically, the availability and reliability of the candidate datacenters must be greater than or equal to minimum values required by the user, while cost and response time must be less than or equal to maximum acceptable values. See Ziafat, § 3.1, Table 2; § 3.2.3, step 2; Eqs. (14a)–(14d). Under the broadest reasonable interpretation, the required minimum availability and reliability values constitute minimum net-efficiency requirements for each candidate distributed resource.
As to “determining, based on the first output, a first geographic reference point for a first network allocation site of a plurality of network allocation sites, wherein each of the plurality of network allocation sites comprises a respective geographic reference point for allocating one or more of a plurality of distributed resources;”, Ziafat teaches determining a selected datacenter based on the LP output and associating geographically distributed datacenters and brokers with geographic regions, longitude, latitude, and geographic-distance information. See Ziafat, § 3.1.1; Figs. 2–4; Eq. (1); § 3.1.2, procedure “MANAGE,” steps 3–4; § 3.1.4, steps 2–4. Ziafat does not expressly characterize the location associated with the selected datacenter as a “geographic reference point.”
Kodialam teaches selecting cloud resources relative to a client location, another allocated resource, or another point of reference. Kodialam further teaches a request specifying that a group of VMs be allocated near the city of Chicago, such that Chicago serves as a geographic reference location for identifying a qualifying allocation site. See Kodialam ¶¶ 35, 38–41.
It would have been obvious to incorporate Kodialam’s use of a geographic reference location into Ziafat’s datacenter-selection method so that candidate and selected datacenters could be identified and evaluated relative to a user location, specified city, another allocated resource, or another geographic point. Such a modification would have predictably enabled Ziafat’s system to satisfy geographic-placement preferences and reduce network propagation delay.
As to “generating for display, on a user interface, a first recommendation for using the first network allocation site for the first distributed resource based on the first geographic reference point,”, Ziafat teaches returning the selected datacenter identifier to the geographical broker, returning the identifiers of selected VMs to the user, informing the user of the assignment, and permitting the user to accept the selected assignment. See Ziafat, procedure “DETERMINER,” step 5; § 3.1.4, steps 4–12; Fig. 5. Ziafat does not expressly state that the selected allocation is generated for display on a user interface.
Kodialam teaches transmitting a response to the requesting client that indicates the location of the allocated cloud resources. Kodialam further teaches that the client may be a desktop computer, laptop, tablet, or mobile device through which the user interacts with the cloud resources. See Kodialam ¶¶ 32, 45.
It would have been obvious to generate Ziafat’s selected datacenter and resource assignment for display on the requesting user’s conventional client interface. Displaying the selected allocation would have been a predictable implementation of the references’ express communication of the selected cloud-resource location to the requesting user and would permit the user to review and accept the allocation.
Regarding claim 3, Ziafat teaches “receiving a first request from a first user for the first distributed resource” because the system receives a user request specifying the requested cloud resources and associated resource characteristics. See Ziafat § 3.1, Table 2; § 3.1.4; procedure "DETERMINER."
Ziafat does not expressly disclose “in response to receiving the first request, querying the first user for the first geographic location.”
Kodialam teaches that a cloud resource request may specify geographic preferences or constraints, including a client location, a city (e.g., Chicago), another allocated resource, or another point of reference that is used by the cloud controller to determine an appropriate allocation site. See Kodialam ¶¶ 29, 38–41.
It would have been obvious to prompt or query the user for the geographic location when such information is absent from the initial request so that Ziafat's LP-based allocation algorithm could utilize the user's geographic preferences while satisfying Kodialam's geographic placement constraints.
Regarding claim 4, Ziafat teaches “receiving a first request for allocating the first distributed resource” because the user submits a request for cloud resources. Ziafat further teaches “in response to receiving the first request, using the first request to determine the first geographic location and the first type” because the request includes the requested resource type and resource characteristics, while the user's location information is used by the geographical broker and middle broker to determine the geographic location utilized during datacenter selection. See Ziafat § 3.1.1; Table 2; Fig. 3; Eq. (1); § 3.1.4.
Regarding claim 5, Ziafat teaches “wherein a first decision variable for the objective function comprises a predicted net efficiency for each distributed resource in the subset of the plurality of distributed resources” because Ziafat's LP optimization evaluates each candidate datacenter using normalized and weighted QoS metrics, including availability, reliability, cost, response time, and geographic distance, and combines those values into a composite fitness value used by the objective function to select the optimal datacenter. See Ziafat §§ 3.2.1–3.2.3; Eqs. (4)–(16). Under the broadest reasonable interpretation, the composite fitness value represents a predicted net efficiency for each candidate resource allocation.
Regarding claim 6, Ziafat teaches “wherein a second decision variable for the objective function comprises a distance for each distributed resource in the subset of the plurality of distributed resources from a respective current location to the proposed geographic location” because the LP objective function includes geographic distance as one of the weighted optimization parameters. Ziafat calculates geographic distances using longitude and latitude and incorporates normalized geographic distance into the optimization objective. See Ziafat § 3.1.1; Eq. (1); § 3.2.3; Eqs. (15b) and (16).
Regarding claim 7, Ziafat teaches the LP optimization framework, while Kodialam teaches constraining cloud-resource selection by a maximum geographic or network distance from a client or other reference point. See Kodialam ¶¶ 29, 38–41, 46, 48, 53, 55–56, 62. It would have been obvious to incorporate Kodialam's maximum-distance constraint into Ziafat's optimization to satisfy geographic-placement requirements while reducing propagation delay.
Regarding claim 8, Ziafat teaches “wherein a third constraint for the objective function comprises a maximum capacity for the proposed network allocation site, wherein the maximum capacity comprises a maximum size of the subset” because each datacenter has finite resource capacity, including available processors, memory, storage, and bandwidth, and only candidate datacenters capable of satisfying the requested workload are considered during allocation. See Ziafat § 3.1; Table 1; Table 2; § 3.1.4.
Regarding claim 9, Ziafat teaches “wherein a fourth constraint for the objective function comprises a minimum aggregated net efficiency [for] the subset of the plurality of distributed resources” because the LP optimization requires candidate datacenter compositions to satisfy minimum availability and reliability thresholds while optimizing the aggregate weighted objective function. See Ziafat § 3.2.3; Eqs. (14a)–(16). Under the broadest reasonable interpretation, these minimum QoS thresholds constitute a minimum aggregated net efficiency.
Regarding claim 10, Ziafat teaches determining a geographic address (longitude and latitude) corresponding to the user and determining the geographic location based thereon. See Ziafat § 3.1.1; Eq. (1); Fig. 3.
Regarding claim 11, Ziafat teaches retrieving available resource types, determining the requested resource characteristics (e.g., MIPS, RAM, storage, bandwidth), and selecting an appropriate resource type based on those characteristics. See Ziafat Table 2; § 3.1.1; § 4.2.2; Table 5.
Regarding claim 12, Ziafat teaches allocating multiple requested resources and returning the selected assignments, while Kodialam teaches allocating multiple cloud resources relative to a common geographic reference point. It would have been obvious to generate recommendations for additional distributed resources using the same selected network allocation site.
Regarding claim 14, Ziafat teaches generating and evaluating candidate datacenter-resource combinations using matrices of QoS values (availability, reliability, cost, response time, and distance) that are normalized and aggregated during LP optimization. See Ziafat §§ 3.2.1–3.2.3; Eqs. (4)–(16). Under the broadest reasonable interpretation, these data structures correspond to the claimed matrix populated with allocation-efficiency values.
Regarding claim 15, Ziafat teaches calculating the geographic distance between users, brokers, and datacenters using longitude and latitude and utilizing those distance values during optimization. See Ziafat § 3.1.1; Eq. (1); § 3.2.3. Under the broadest reasonable interpretation, the calculated distances populate the claimed matrix.
Claim 17 is rejected under 35 U.S.C. § 103 as being unpatentable over Ziafat et al. in view of Kodialam et al. for substantially the same reasons set forth above with respect to claim 1. Claim 17 recites substantially the same subject matter as claim 1, except in computer-readable medium form and without the additional objective-function decision-variable and constraint limitations. Ziafat teaches the recited computer-readable medium storing instructions that, when executed, perform the claimed resource-allocation operations, and Kodialam teaches determining a geographic reference point and recommending a geographically constrained network allocation site as discussed above with respect to claim 1. Therefore, claim 17 is similarly unpatentable over the combination of Ziafat and Kodialam.
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the prior art as proposed because the claimed invention merely involves the predictable use and/or rearrangement of known elements according to their established functions. As set forth in KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007), when a work is composed of familiar elements arranged according to known methods, it is likely to be obvious if it yields no more than predictable results. The prior art teaches each of the claimed elements, and it would have been within the ordinary skill in the art to combine or modify these teachings using common sense and routine design choices, such as optimizing performance, improving efficiency, or adapting known techniques to similar devices or systems. The combination does not require undue experimentation or change in principle of operation, and there is no teaching away in the prior art. Absent a showing of unexpected results or criticality, the claimed arrangement represents no more than an obvious variation of known technology.
Claims 18-20 recite substantially identical subject matter as claims 3-5, respectively, and are thus similarly rejected.
Allowable Subject Matter
Claims 13 and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure (see form 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUAT T PHUNG whose telephone number is (571)270-3126. The examiner can normally be reached on M-F 9 AM - 6 PM.
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, Marcus Smith can be reached on (571) 272-3988. 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.
/Luat Phung/
Primary Examiner, Art Unit 2468
Prosecution Insights