DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to claim amendments and remarks filed by Applicant’s representative on July 30, 2026. Claims 1-4, 6-17 and 21 are pending, claims 5, 18, 19 and 20 have been canceled, and no new claims have been added.
Response to Amendments and Remarks
Applicant’s latest filed claim amendments and corresponding remarks dated July 30, 2026 have been received and fully considered. Applicant’s remarks and/or comments are generally directed to the current claim amendment(s) and accordingly deemed moot in light of the new grounds of rejection provided with this action.
With regards to Applicant’s latest amendments and remarks, Applicant firstly notes and remarks that the independent claim(s), and particularly independent claim 1, has been further amended to now expressly recite
“A method, comprising:
generating, by a computing system, a first user interface ("UI");
presenting, by the computing system, the first UI to a first entity over a first network, the first UI displaying first data regarding an identified first set of network resources that is assigned to the first entity and displaying second data regarding an amount of the identified first set of network resources that is unused;
presenting, by the computing system, first options in the first UI for the first entity to select and allocate a second set of network resources for use by other entities, the second set of network resources comprising at least a portion of the unused network resources among the identified first set of network resources;
receiving, by the computing system, user input indicating selection and allocation of the second set of network resources, based on selection from the first options in the first UI;
receiving, by the computing system and from the second entity, a request for network resources to be provisioned for a specified period;
based on a determination that at least a portion of the second set of network resource satisfies at least a portion of the requested network resources, re-assigning, by the computing system, the at least a portion of the second set of network resources as a third set of network resources to the second entity for the specified period;
re-provisioning a portion of the first set of network resources corresponding to the third set of network resources to the second entity for the specified period;
identifying, by the computing system, the first set of network resources that is assigned to the first entity; and
monitoring, by the computing system, usage of the first set of network resources;
wherein generating the first UI comprises generating, by the computing system, the first UI based on the identified first set of network resources and the monitored usage of the first set of network resources”.
With respect to the above, Applicant notes and remarks that none of the prior art reference(s) applied in rejecting independent claim 1 [Middleton et al, Brandwine et al, Guim-Bernat et al], either individually or in combination with other prior art disclosures, expressly and properly discloses or suggests the above recited and/or amended claim feature(s) or limitation(s) of
identifying, by the computing system, the first set of network resources that is assigned to the first entity; and
monitoring, by the computing system, usage of the first set of network resources;
wherein generating the first UI comprises generating, by the computing system, the first UI based on the identified first set of network resources and the monitored usage of the first set of network resources -- as currently recited by amended independent claim 1 above.
In this regard, Applicant notes or remarks that none of the applied prior art properly teaches or discloses the features of generating, by a computing system, a first user interface, and presenting, by the computing system, the first UI to a first entity over a first network, the first UI displaying first data regarding an identified first set of network resources that is assigned to the first entity, where generating the first UI comprises generating by the computing system, the first UI is ‘based on’ the ‘identified first network resources’ and the ‘monitored usage of the first set of network resources’, and amended independent claim 1 is thus distinguishable from the prior art [Applicant Remarks: par 3, pg. 11 – par 2, pg. 12]. Accordingly, Applicant remarks that the amended independent claim 1 is distinguishable from the applied prior art and/or prior art combination(s) used to reject the claims, and that the respective dependent claims are also distinguishable by virtue of their dependency on their respective parent independent claims.
Applicant’s remarks / arguments with respect to the amended feature / limitations are considered persuasive. However, in response, the Office asserts and notes that the newly amended feature(s) and noted elements are now expressly taught or disclosed in further view of teachings and disclosures to Alabsi et in a new ground of rejection, as discussed / cited with this action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) 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.
Claim(s) 1-10, 12 is/are rejected under 35 U.S.C. 103 as being disclosed by Middleton et al (hereinafter Middleton), US Patent Publication 20140359092 A1 (publication date December 2014) in view of Obviousness and in further view of Alabsi et al (hereinafter Middleton), US Patent 10237135 B1 (publication date March 2019).
As per claim{s} 1, Middleton discloses substantial features of the claimed invention, such as a method, comprising:
generating, by a computing system, a first user interface ("UI") (Middleton: e.g., ‘web interface’ provided by an ‘Interface Portal’ of the Open Content Delivery Network [OCDN] platform ) [0029, 0057; Fig. 4];
presenting, by the computing system, the first UI to a first entity over a first network, the first UI displaying first data regarding an identified first set of network resources that is assigned to the first entity (Middleton: e.g., the ‘web interface’ of the OCDN interface portal displays / presents ‘service instances’ { having ‘available / unused capacity’} defined by and/or belonging to a OCDN ‘participant’ [OCDNP], such as entity / participant ‘OCDNP_A’ {i.e., first view_410}, each ‘service instance’ having an assigned ‘Service Identifier’ [SI ID], a ‘name’ for identifying the service instance, OCDNP ‘Stated capacity’, OCDN ‘Measured Capacity’ {verified capacity measured by the Open CDN platform}, and ‘status’ information as to whether the service instance has been ‘published’ to the ‘Capacity Exchange’ {i.e., via the web interface provided by the interface portal of the Open CDN platform}…’Service attributes’ for a currently selected service instance are shown in the Second view_420. In this figure, the second view 420 illustrates the ‘service attributes’ that have been specified for the first defined service instance. As shown, the ‘service attributes’ include the OCDN_Region (see Geography), OCDN_ServiceType, OCDN_StatedCapacity, and OCDN_MeasuredCapacity. OCDNP specified service attributes can be ‘modified’ by selecting the corresponding service attribute value and entering a new value. The set of {interface} ‘Tools’_430 control (1) the creation of a new service instance, (2) the ‘publishing’ of a defined service instance, (3) the removal of a published service instance from the capacity exchange, and (4) the deletion of a defined service instance ) [0046-0047 & 0057; Fig. 4] (e.g., OCDN_StatedCapacity to specify the allocated or ‘assigned capacity’ for the service instance as estimated by the OCDNP ‘offering’ the service instance ) [0054; Fig. 3] and (Middleton: e.g., expressly discloses permitting OCDN participants to sell ‘unused capacity’ to other participants in need of additional capacity) [Abstract, 0014] (e.g., To participate in the capacity exchange as a ‘Seller’ of capacity, an OCDN Participant ‘defines a service instance’. The ‘service instance’ specifies an ‘amount of available capacity’ that the CDN is willing to make available to the Capacity exchange along with service attributes that categorize the capacity. In some embodiments, the Open CDN platform activates one or more verification probes to ‘verify’ the ‘capacity of the service instance’ defined by the CDN, before publishing that service instance to the Capacity Exchange. The {capacity} ‘measurements’ performed by the verification probes are then ‘published’ to the Exchange in conjunction with the defined service instance) [0015; Figs. 3 & 4] (e.g., the Capacity Exchange uses the verification probes to ensure a predefined and universally consistent ‘measurement’ of the ‘capacity’, ‘load’ {usage}, and headroom associated with all elements of capacity that contribute to the service instance's ‘overall capacity’ and to provide a trended verification that the OCDN_StatedCapacity is actually observed to be accurate over time. In so doing, capacity ‘Purchasers’ are better able to assess the validity of the ‘estimated remaining & future capacity’ of a service instance) [0058];
presenting, by the computing system, first options in the first UI for the first entity to select and allocate a second set of network resources for use by other entities, the second set of network resources comprising at least a portion of the unused network resources among the identified first set of network resources (Middleton: e.g., FIG. 5 conceptually illustrates a ‘Capacity Allocation table’ for a ‘service instance’ {amount of unused capacity} that is ‘published’ to the Capacity Exchange { via the web interface of the OCDN platform interface} in accordance with some embodiments. The Capacity Allocation table identifies a ‘Service instance’_510 with a stated ‘amount of capacity’ (20,000 Mbps) that the Seller provisions {allocates / offers} ‘for Others to purchase’) [0065; Fig. 5];
receiving, by the computing system, user input indicating selection and allocation of the second set of network resources, based on selection from the first options in the first UI (Middleton: e.g., FIG. 5 conceptually illustrates a ‘capacity allocation table’ for a service instance that is ‘published’ to the Capacity Exchange { via the web interface of the OCDN platform interface} in accordance with some embodiments. The capacity allocation table identifies a ‘Service instance’_510 with a stated ‘amount of capacity’ (20,000 Mbps) that the seller provisions ‘for others to purchase’) [0065; Fig. 5] (e.g., OCDNPs 620, 630, and 640 publish ‘service instances’ for their ‘unused capacity’ in the geographic region 660 to the Capacity exchange 610 along with geographic and cost service attributes related to the capacity being ‘offered’ ) [0071; Fig. 6];
receiving, by the computing system and from the second entity, a request for network resources to be provisioned for a specified period (Middleton: e.g., The box 560 may be representative of a ‘query’ (or ‘capacity request’ described below) that is submitted by a ‘Buyer’ {second entity}, whereby the query specifies a ‘duration’ and/or an ‘amount’ of desired capacity) [0067; Fig. 5];
based on a determination that at least a portion of the second set of network resources satisfies at least a portion of the requested network resources, re-assigning, by the computing system, the at least a portion of the second set of network resources as a third set of network resources to the second entity for the specified period; and re-provisioning a portion of the first set of network resources corresponding to the third set of network resources to the second entity for the specified period (Middleton: e.g., In some embodiments, the Open CDN platform manages the allocation and configuration of a service instance that was ‘successfully sold or auctioned’ through the Capacity exchange. The Open CDN platform ‘assigns’ unique identifiers to each OCDNP participant, each service instance, and each customer of each OCDNP who has a configuration exposed to a foreign CDN (i.e., foreign OCDNP), wherein an exposed configuration includes a ‘customer configuration’ that has been ‘deployed’ {provisioned} to capacity that was ‘acquired’ through the capacity exchange. The unique identifiers provide a mechanism with which to deploy and monitor customer configurations across the Open CDN platform and the participating OCDNPs) [0018] (e.g., Specifically, the Capacity exchange 610 ‘aligns’ the available service instance of whichever Seller ‘best matches’ the desired service attributes of the Buyer. As shown, OCDNP 650 acquires all of OCDNP's 620 available capacity in the geographic region 680 while acquiring a fraction of OCDNP's 630 available capacity in the geographic region 660…After ‘acquiring the capacity’, OCDNP 650 can ‘configure’ the corresponding POPs of OCDNP 620 in the geographic region 680 and OCDNP 630 in the geographic region 660 to deliver content on behalf OCDNP 650 or more specifically, on behalf of customers 690 and 695 of OCDNP 650. As shown, the ‘configuration’ for Customer 690 of OCDNP 650 is ‘deployed’ to the POP of OCDNP 630 in the geographic region 660 and the ‘configuration’ for Customer 695 of OCDNP 650 is ‘deployed’ across the POPs of OCDNP 620 and OCDNP 650 in the geographic region 680….As a result of the ‘exchanged capacity’ in FIG. 6, OCDNP 620 fully avoids the sunk cost that is associated with having ‘unused capacity’ in the geographic region 680, OCDNP 630 partially avoids the sunk cost that is associated with having ‘unused capacity’ in the geographic region 660, OCDNP 650 is able to expand its capacity within the geographic region 680, and OCDNP 650 is able to establish an entirely new POP in the geographic region 660 ) [0072-0074; Fig. 6]..
But while Middleton discloses substantial features of the invention as above, he does not explicitly disclose the additional feature(s) of the method further comprising ‘displaying’ {in the user interface} second data regarding an amount of the identified first set of network resources that is unused,
However, the Office asserts that the additional recited feature / element is disclosed in view of ‘Obviousness’ in the technical field. The recited claim element of ‘displaying’ {presenting} specific / additional ‘capacity information’ in the UI in addition to the disclosed service instance ‘capacity information’ {i.e., OCDN ‘Participant’ / Entity assigned ‘service instance{s}’ and/or OCDNP ‘unused capacity’ [0050] } already displayed / presented by the service instance {user} interface of Middleton’s disclosed invention {i.e., ‘web interface’ provided by an ‘Interface Portal’ of the Open Content Delivery Network [OCDN] platform ) [0029, 0057; Fig. 4] (e.g., To participate in the capacity exchange as a ‘Seller’ of capacity, an OCDNP ‘defines a service instance’. The ‘service instance’ specifies an ‘amount of available capacity’ {or ‘unused capacity’} that the CDN {‘participant’ / entity} is willing to ‘make available’ {sell} to the Capacity Exchange along with ‘service attributes’…) [0015; Figs. 3, 4 & 5] --- is considered ‘obvious’ in the technical field, as the feature of ‘‘displaying’ additional / specific UI information merely relates to User Interface information presentation ‘details’ or specifics to the user, and does not constitute / amount to a technical feature or contribute to a technical functionality. In this regard, the Office also notes that the said recited feature of ‘displaying’ network resources in the UI, specifically ‘second data’ such as unused resources or available capacity, at best, amounts to a user interface ‘design preference’, and is merely an ‘enhancement’ to the existing functionality of the UI in Middleton’s disclosed ‘web interface / portal’ of the Capacity Exchange.
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify Middleton’s invention with the above said additional feature, in view of Obviousness, for the motivation of providing Users { Seller / Buyer} of the Capacity Exchange system with as much ‘capacity information’ details in the user Interface {i.e., Middleton’s ‘web interface / portal’} as a convenience and enhancement, and to aid the user in making ‘informed’ assessments or decision-making in the sale / exchange / purchase of Capacity Exchange ‘service instances’ having unused / available capacity.
Middleton in view Obviousness discloses the above recited features of the claim, but does not expressly disclose the additional recited feature(s) of identifying, by the computing system, the first set of network resources that is assigned to the first entity; and monitoring, by the computing system, usage of the first set of network resources; wherein generating the first UI comprises generating, by the computing system, the first UI based on the identified first set of network resources and the monitored usage of the first set of network resources.
However, Alabsi, in a related endeavor, expressly teaches the additional recited feature(s) of identifying, by the computing system, the first set of network resources that is assigned to the first entity; and monitoring, by the computing system, usage of the first set of network resources; wherein generating the first UI comprises generating, by the computing system, the first UI based on the identified first set of network resources and the monitored usage of the first set of network resources (Middleton: e.g., expressly discloses and illustrates as part of his computing resources optimization / purchasing invention and in one aspect ‘Customer’s Instances’ {network resources assigned to a Customer} as well as the customer’s ‘usage’ of the network instance ‘resources’ {i.e., ‘Light Use’, ‘Medium Use’, ‘Heavy Use’ reservations ) [Figs. 1 & 3] (e.g., Auto Scaling Component 212 of Server 204 ‘monitors’ available computing resources over an internal management network and modify resources available based on need) [col 6, L2-7; Fig. 2] (e.g., Optimizing virtualized computing usage may also include using a list of ‘current capacity reservations associated with a customer’ in a virtualized computing environment. For instance, a customer may already have a ‘light use reservation’ that may be able to service the virtualized computing instance. A capacity reservation within current capacity reservation may be identified that matches the capacity level being sought and repurposed or ‘reassigned’ for use by the virtualized computing instance.) [cl 11, L2-10; Fig. 6] (e.g., FIG. 4 illustrates an example of ‘gathered {monitored} Usage Information 400’ {user network resource usage interface} for a virtualized computing instance. Various statistics may be gathered at regular intervals for a plurality of virtualized computing instances…As an illustrative example, in FIG. 4, the ‘identifier’ for represented ‘virtualized computing instance’ is ‘i-3340e5b0’. One statistic that may be collected is ‘usage’_402 of the virtualized computing instance. In an example, ‘usage’ of the plurality of virtualized computing instances may be identified in part by calculating a ‘usage ratio’ for each of the plurality of virtualized computing instances for a ‘time period’, wherein the usage ratio for a virtualized computing instance is based in part on how often the virtualized computing instance is executing during the time period. In another example, ‘usage’ of the plurality of virtualized computing instances may be identified in part by identifying ‘processor (CPU) utilization’ 404 for each of the plurality of virtualized computing instances for a period of time. Other exemplary ‘statistics’ depicted in FIG. 4 that may be collected and used for optimization include, as non-limiting examples, ‘network input/output 406 (I/O)’, ‘memory utilization’_408, ‘storage utilization’ or other virtualized computing resources.) [col 9, L27-50; Fig. 4 & 5].
As per claim{s} 2, Middleton discloses the method wherein the identified first set of network resources, the second set of network resources, and the third set of network resources comprise at least one of compute resources, network component resources, or data storage resources (Middleton: e.g., each ‘Edge server’ of the set of Edge servers 110 may represent a single physical machine or a ‘cluster’ of machines. The cluster of machines may include a server farm for a geographically proximate set of physically separate machines or a set of virtual machines that execute over partitioned ‘sets of resources’ of one or more physically separate machines. The set of edge servers 110 are distributed across different edge regions of the Internet to facilitate the "last mile" delivery of content. The edge servers run various processes that include, among others, … (4) monitoring ‘server capacity’ (i.e., available processor cycles, available memory, available storage, etc.), (5) monitor ‘network performance’ (e.g., latency, downed links, etc.), and (6) report statistics on the delivered content ) [0005] (e.g., ‘Capacity Exchange’ [Wingdings font/0xE0] some embodiments provide a CDN Capacity Exchange whereby ‘capacity’ from different OCDNPs can be ‘bought’, ‘sold’, and ‘traded’. As used herein, ‘capacity’ refers to the ability of a particular OCDNP to deliver content on behalf of a content originator or content publisher. ‘Capacity’ is determined from the availability of disparate ‘resources’ and disparate service attributes related to those resources. ‘Resources’ that comprise a construct or measure of ‘capacity’ include ‘processor’ cycles, ‘memory’, ‘bandwidth’, ‘throughput’, and ‘services’ (e.g., caching of static content, caching of dynamic content, application services, media streaming, secure content delivery, etc.) [0046-0047];
As per claim{s} 3, Middleton discloses the method wherein the identified first set of network resources, the second set of network resources, and the third set of network resources comprise at least one of network edge resources, bare metal resources, optical transport resources, network-to-network interconnect ("NNI") resources, quality of service ("QoS") monitoring resources, Ethernet access resources, Internet access resources, data storage resources, or composable disaggregated infrastructure resources, wherein the composable disaggregated infrastructure resources comprise at least one of graphics processing units ("GPUs"), non-volatile memory express ("NVMe") -based memory devices, field programmable gate arrays ("FPGAs"), or network interface controller ("NIC") cards (Middleton: e.g., each ‘Edge server’ of the set of Edge servers 110 may represent a single physical machine or a ‘cluster’ of machines. The cluster of machines may include a server farm for a geographically proximate set of physically separate machines or a set of virtual machines that execute over partitioned ‘sets of resources’ of one or more physically separate machines. The set of edge servers 110 are distributed across different edge regions of the Internet to facilitate the "last mile" delivery of content. The Edge servers run various processes that include, among others, … (4) monitoring ‘server capacity’ (i.e., available processor cycles, available memory, available storage, etc.), (5) monitor ‘network performance’ (e.g., latency, downed links, etc.), and (6) report statistics on the delivered content ) [0005] (e.g., ‘‘Capacity’ is determined from the availability of disparate ‘resources’ and disparate service attributes related to those resources. ‘Resources’ that comprise a construct or measure of ‘capacity’ include ‘processor’ cycles, ‘memory’, ‘bandwidth’, ‘throughput’, and ‘services’ (e.g., caching of static content, caching of dynamic content, application services, media streaming, secure content delivery, etc.) [0046-0047]
As per claim{s} 4, Middleton discloses the method wherein the specified period comprises at least one of a specified date, a specified time, or a specified duration, wherein the specified duration comprises one of a number of minutes, a number of hours, a number of days, a number of weeks, a number of months, or a number of years (Middleton: e.g., he box 560 may be representative of a query (or ‘capacity request’ described below) that is submitted by a Buyer, whereby the query specifies a ‘duration’ and/or an ‘amount’ of desired capacity {specified duration}) [0067] (e.g., expressly illustrates in one aspect wherein a Buyer ‘purchases’ {i.e., performs a ‘Take’_ 520 or ‘buying action’} for a portion of the Service instance Stated capacity_510 {i.e.. unused / available capacity} made available by a OCDN Participant / Seller, and the ‘requested’ or desired duration of the ‘Take’ spans a period of time starting from Mid-January to Mid-April, for example) [0066; Fig. 5].
As per claim{s} 6, Middleton discloses the method further comprising
presenting, by the computing system, a second UI to a second entity over a second network, the second UI displaying second options for the second entity to request provisioning of network resources for specified periods (Middleton: e.g., OCDNPs participating in the Capacity Exchange as ‘Buyers’ {second entity} of capacity can ‘search’ the {Capacity} Exchange {via the ‘web interface’ provided by the {user} ‘Interface’ Portal of the OCDN Platform} based on the categorizations of the service instances in order to ‘identify’ service instances that meet their qualifications for additional capacity. OCDNPs can then purchase an identified service instance, and the Capacity exchange ‘brokers’ the purchase using one of a variety of pricing plans supported by the exchange) [0016];
wherein receiving the request for network resources comprises receiving, by the computing system and from the second entity via the second UI, the request for network resources to be provisioned for the specified period (Middleton: e.g., the box 560 may be representative of a query (or ‘capacity request’ described below) that is submitted by a Buyer, whereby the query specifies a ‘duration’ and/or an ‘amount’ of desired capacity {specified duration}) [0067] (e.g., expressly illustrates in one aspect wherein a Buyer ‘purchases’ {i.e., performs a ‘Take’_ 520 or ‘buying action’} for a portion of the Service instance Stated capacity_510 {i.e.. unused / available capacity} made available by a OCDN Participant / Seller, and the ‘requested’ or desired duration of the ‘Take’ spans a period of time starting from Mid-January to Mid-April, for example) [0066; Fig. 5].
As per claim{s} 7, Middleton discloses the method
wherein the computing system comprises an auction-based exchange system (Middleton: e.g., OCDNPs participating in the Capacity Exchange as ‘buyers’ of capacity can search the exchange based on the categorizations of the service instances in order to ‘identify service instances’ that meet their qualifications for additional capacity. OCDNPs can then purchase an identified service instance. The Capacity Exchange ‘brokers’ the purchase using one of a variety of ‘pricing plans’ supported by the exchange. Some supported ‘pricing plans’ include (1) a first-in pricing plan, (2) a highest bid pricing plan, (3) a decaying pricing plan, (4) a tiered pricing plan, and (5) an any price ‘auctioning’ plan) [0016], wherein selecting and allocating the second set of network resources for use by other entities comprises selecting the second set of network resources to be placed in a multi-user UI system for bidding by a plurality of entities who have access to the multi-user UI system for a chance to acquire access to the selected second set of network resources (Middleton: e.g., FIG. 5 conceptually illustrates a Capacity Allocation Table for a service instance that is ‘published’ to the Capacity Exchange in accordance with some embodiments. The Capacity Allocation Table identifies a ‘Service instance’_510 with a stated ‘amount of capacity’ (20,000 Mbps) that the Seller ‘provisions’ {allocates / offers} for others to purchase) [0065] (e.g., a Buyer may purchase some or all of the available capacity of the service instance. To do so, the Buyer submits an ‘offer’ to purchase of an identified service instance or engages in a ‘bidding auction’ for that identified service instance using the interface portal of the Open CDN platform ) [0063], wherein the second entity is a winner of the bidding among the plurality of entities (Middleton: e.g., OCDNPs participating in the Capacity Exchange as ‘Buyers’ of capacity can search the exchange based on the categorizations of the service instances in order to ‘identify service instances’ that meet their qualifications for additional capacity. OCDNPs can then purchase an identified service instance. The Capacity Exchange ‘brokers’ the purchase using one of a variety of ‘pricing plans’ supported by the exchange. Some supported ‘pricing plans’ include (1) a first-in pricing plan, (2) a ‘highest bid’ pricing plan { thus, the ‘winner’ of the available capacity / instance is the user / entity with the ‘highest bid’}, (3) a decaying pricing plan, (4) a tiered pricing plan, and (5) an any price ‘auctioning’ plan) [0016] and is provided with an opportunity to request, via the second UI that is presented to the second entity, the network resources to be provisioned (Middleton: e.g., the box 560 may be representative of a query (or ‘capacity request’ described below) that is submitted by a Buyer, whereby the query specifies a ‘duration’ and/or an ‘amount’ of desired capacity {specified duration})…The Buyer then has the option to submit a ‘purchase offer’ for some or all of the available capacity of the service instance 510 {provision request}) [0067; Fig. 5].
As per claim{s} 8, Middleton discloses the method wherein the computing system comprises a network resource reservation system (Middleton: e.g., a Buyer may be charged a fluctuating fee that includes a first fee for total capacity of a service instance that was ‘reserved’ during the settlement cycle and a second fee for the actual usage of that ‘reserved capacity’ ) [0064], wherein selecting and allocating the second set of network resources for use by other entities comprises selecting the second set of network resources to be marked in a multi-user UI system as being available for reservation by one or more of a plurality of entities who have access to the multi-user UI system (Middleton: e.g., FIG. 5 conceptually illustrates a Capacity Allocation Table for a service instance that is ‘published’ to the Capacity Exchange in accordance with some embodiments. The Capacity Allocation Table identifies a ‘Service instance’_510 with a stated ‘amount of capacity’ (20,000 Mbps) that the Seller ‘provisions’ for others to purchase) [0065], wherein the second entity is an entity among the plurality of entities who has been given a right to reserve the selected second set of network resources, and is provided with options to reserve, via the second UI that is presented to the second entity, the at least a portion of the second set of network resources (Middleton: e.g., Additionally, the ‘Buyer’ may be charged a fluctuating fee that includes a first fee for total capacity of a service instance that was ‘reserved’ during the settlement cycle and a second fee for the actual usage of that ‘reserved capacity’ ) [0064].
As per claim{s} 9, Middleton discloses the method
wherein the computing system comprises a network resource trading system (Middleton: e.g., Some embodiments provide a Capacity Exchange whereby ‘capacity’ from different content delivery networks (CDNs) can be ‘bought’, ‘sold’, and ‘traded’) [Abstract],
wherein selecting and allocating the second set of network resources for use by other entities comprises selecting the second set of network resources to be marked in a multi-user UI system as being available for trading with one or more of a plurality of entities who have access to the multi-user UI system (Middleton: e.g., FIG. 5 conceptually illustrates a Capacity Allocation Table for a service instance that is ‘published’ to the Capacity Exchange in accordance with some embodiments. The Capacity Allocation Table identifies a ‘Service instance’_510 with a stated ‘amount of capacity’ (20,000 Mbps) that the Seller ‘provisions’ for others to purchase {or ‘traded’}) [0065, Abstract],
wherein the second entity is an entity among the plurality of entities who has been selected by the first entity to trade other network resources for the selected second set of network resources, wherein the first and second UIs display network resources to be traded (Middleton: e.g., The Capacity exchange 610 then brokers the ‘exchange of capacity’ {trade} by ‘aligning the Buyer (i.e., OCDNP 650) with the appropriate Seller’. Specifically, the Capacity Exchange 610 ‘aligns’ the available service instance of whichever Seller best matches the desired service attributes of the Buyer. As shown, OCDNP 650 acquires all of OCDNP's 620 available capacity in the geographic region 680 while acquiring a fraction of OCDNP's 630 available capacity in the geographic region 660) [0072; Fig. 6].
As per claim{s} 10, Middleton discloses the method
wherein the first UI further provides management options for the first entity to manage scheduling unused capacity for at least one of auction, reservation, trade, resale, or sub-lease (Middleton: e.g., FIG. 5 conceptually illustrates a Capacity Allocation Table for a service instance that is ‘published’ to the Capacity Exchange in accordance with some embodiments. The Capacity Allocation Table identifies a ‘Service instance’_510 with a stated ‘amount of capacity’ (20,000 Mbps) that the Seller ‘provisions’ {allocates / offers} for others to purchase) [0065], based on at least one of high or low watermarks within available resources among the identified first set of network resources (Middleton: e.g., Since the capacity of the service instance changes based on the puts and takes, the buyer is ‘presented’ with different values to indicate the availability of capacity for the service instance 510 during the indicated time period of box 560. As shown, the Buyer is presented with the ‘minimum’, ‘average’, and ‘maximum’ amounts of ‘available capacity’ during the indicated ‘time period’ of box 560. The ‘minimum amount’ of available capacity during the indicated time period is 14,000 Mbps (20,000-5,000-1,000), the ‘average amount’ of available capacity during the indicated time period is 15,625 Mbps, and the ‘maximum amount’ of available capacity during the indicated time period is 20,000 Mbps. The Buyer then has the option to submit a purchase offer for some or all of the available capacity of the service instance 510) [0067], wherein the management options comprise calendar-based scheduling management functionalities Middleton: e.g., expressly illustrates in one aspect wherein a Seller provisions / allocates Service Instance Stated Capacity (20000 Mbps) for Buyer{s} to purchase / trade , and the ‘duration’ or time period for the availability of the allocated capacity is ‘set’ {scheduled} by the Seller to start ‘January 1st through Mid-May’, for example) [0066; Fig. 5].
As per claim{s} 13, Middleton discloses the method further comprising updating, by the computing system, the first UI to present an amount of network resources among the identified first set of network resources available for use after re-assigning to the second entity (Middleton: e.g., The Capacity Allocation table identifies the amount of stated capacity that is available for a particular service instance ‘at different periods of time’. In some embodiments, the Capacity Allocation table tracks "puts" and "takes" to the particular service instance) [0062] (e.g., As part of the sale of capacity from a service instance, the Capacity Exchange also ‘updates’ the Capacity Allocation Table for that service instance. Specifically, each ‘portion of the service instance’ that is ‘sold’ causes a new ‘take’ to be entered in the Capacity Allocation table….The Capacity Allocation Table also identifies ‘puts’ (represented by the boxes above the service instance 510) and ‘takes’ (represented by the boxes below the service instance 510) that ‘modify’ the available amount of capacity for the service instance 510 over a period of time, where the period of time is represented by the horizontal length of the box representing the service instance 510) [0065; Fig. 5]; and presenting, by the computing system, the updated first UI to the first entity (e.g., Since the capacity of the service instance ‘changes’ based on the ‘puts’ and ‘takes’, the Buyer {or Seller} is ‘presented’ with different values to indicate the availability of capacity for the service instance 510 during the indicated time period of box 560) [0067; Fig. 5].
Claim(s) 11, 12 is/are rejected under 35 U.S.C. 103 as being disclosed by Middleton in view of Obviousness in view of Alabsi and in further view of Guim Bernat et al (hereinafter Bernat), Foreign Publication KR 20210149576 A (publication date December 2021)
As per claim{s} 11, Middleton in view of Obviousness in view of Alabsi discloses substantial features of the invention recited by claim 1 above, but does not expressly disclose the additional feature(s) of the method wherein re-assignment or re-provisioning of the portion of the first set of network resources to the second entity is recorded as a transaction on a distributed ledger system, wherein the transaction is converted into a non-fungible asset or token.
However, in a related endeavor, Bernat particularly discloses the additional feature(s) of the method wherein re-assignment or re-provisioning of the portion of the first set of network resources to the second entity is recorded as a transaction on a distributed ledger system (Bernat: e.g., The following technology is similar to Domain Name Service (DNS), but provides a registration service configured to be applied to edge architectures. For example, a set of ‘distributed ledgers’ is responsible for deploying monitoring and proof software components at each distributed edge. These monitoring elements can be used, for example, to track services as they run…EANS can provide a set of distributed ledger services to monitor and prove hardware or software computing resources accessible through an edge access network or an edge core network. The EANS provider may be responsible for tracking each service running within the edge network. Information that is tracked may include an individual or specific set of computing resources, firmware or software deployed or running on the computing resource, workloads having a specific SLA set or location therein, and a tenant (e.g., subscriber) identity (e.g., for authentication). encryption key used) or its location, intrinsic trust attributes attributed to the tracked resource, and other policy restrictions ) [pg. 147, par 4 – pg. 148, par 2; Figs.51 & 52], wherein the transaction is converted into a non-fungible asset or token (Bernat: e.g., In a tenth example (Example V10), the subject matter of Examples V1-V9 is that execution of a workload among nodes of an edge computing system coordinates and performs at least a portion of a workload of a particular node and an ‘execution token’ communicated between the nodes. based on the use of the execution token being used) [pg. 169, par 2] (e.g., Execution of the workload among the nodes of the edge computing system is based on use of an execution token passed between the nodes, the execution token being used to coordinate and perform at least a portion of the workload of a particular node.) [Claim 201; pg. 256, par 1].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify Middleton in view of Obviousness with the above said additional feature(s), as expressly disclosed by Bernat, for the motivation of providing methods and systems for ‘multi-entity’ (e.g., multi-tenants, ‘users’, stakeholders, ‘service instances’, applications, etc.)) Edge computing deployments. The various configurations and functions, among other examples, include management of ‘resources’ (e.g., control and orchestration of hardware, ‘network’, and ‘processing resource usage’), security (e.g., security enforcement and communication, isolation, conflict) and ‘service management’ (e.g., orchestration, connectivity, workload orchestration) may be implemented in an ‘Edge computing deployment’, such as by a plurality of edge nodes of the edge computing environment configured to run workloads among the multi-entities [Bernat: Abstract, pg.4, par 5 – pg. 5, par 2].
As per claim{s} 12, Middleton in view of Obviousness in view of Alabsi in further view of Bernat discloses the method wherein configuration management is tracked and recorded as transactions on the distributed ledger system (Bernat: e.g., The following technology is similar to Domain Name Service (DNS), but provides a registration service configured to be applied to edge architectures. For example, a set of distributed ledgers is responsible for deploying monitoring and proof software components at each distributed edge. These monitoring elements can be used, for example, to track services as they run….EANS can provide a set of distributed ledger services to monitor and prove hardware or software computing resources accessible through an edge access network or an edge core network. The EANS provider may be responsible for tracking each service running within the edge network. Information that is tracked may include an individual or specific set of computing resources, firmware or software deployed or running on the computing resource, workloads having a specific SLA set or location therein, and a tenant (e.g., subscriber) identity (eg, for authentication). encryption key used) or its location, intrinsic trust attributes attributed to the tracked resource, and other policy restrictions ) [pg. 147, par 4 – pg. 148, par 2; Figs.51 & 52].
The motivation to combine Bernat with Middleton is similar to that given for claim 11 above.
Claim(s) 14, 15, 16, 17, 21 is/are rejected under 35 U.S.C. 103 as being disclosed by Middleton in view of Obviousness in view of Alabsi and in further view of Brandwine et al (hereinafter Brandwine), US Patent Publication 20110173637 A1 (publication date July 2011)
As per claim{s} 14, Middleton in view of Obviousness in view of Alabsi discloses substantial features of the invention recited by claim 1 above, including the feature of ‘presenting, by the computing system, the updated first UI to the first entity’ (the feature of ‘displaying’ additional UI information or various instance capacity information in a User Interface {i.e., web interface provided by the ‘interface portal’ of the OCDN platform is considered ‘obvious’ to one of ordinary skill in the art) [see Claim 1] -- but does not expressly disclose the additional features of the method further comprising after the specified period, performing the following tasks: re-assigning, by the computing system, the portion of the first set of network resources corresponding to the third set of network resources to the first entity; as well as re-provisioning, by the computing system, the re-assigned portion of the first set of network resources; and updating, by the computing system, the first UI to present an amount of network resources among the identified first set of network resources available for use after re-assigning the portion of the first set of network resources back to the first entity.
However, in a related endeavor, Brandwine particularly discloses the additional feature(s) of the method further comprising after the specified period, performing the following tasks: re-assigning, by the computing system, the portion of the first set of network resources corresponding to the third set of network resources to the first entity; as well as re-provisioning, by the computing system, the re-assigned portion of the first set of network resources; and updating, by the computing system, the first UI to present an amount of network resources among the identified first set of network resources available for use after re-assigning the portion of the first set of network resources back to the first entity (Brandwine: e.g., In some such embodiments, after a request is received to execute one or more programs for a dedicated user 140 on one or more dedicated computing nodes, an appropriate amount of computing nodes 120 sufficient to execute the programs may be selected from the dedicated computing node group at the time of the request to execute the one or more programs. After the selected amount of computing nodes are no longer used for executing the request for the dedicated user 140 (e.g., after termination and/or ‘completion’ of the requested execution), those computing nodes may be ‘returned’ to the dedicated computing node group for use by other dedicated capacity users, and in some embodiments may further be tracked as being ‘available for use’ as part of a private pool of ‘excess computing capacity’ for that dedicated user 140) [0031].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify Middleton’s invention with the above said additional feature(s), as expressly disclosed by Brandwine, for the motivation of providing methods and systems for managing execution of programs, including using excess program execution capacity of one or more computing systems, where excess computing capacity may be made available to execute programs on a ‘temporary’ basis and/or reclaimed [Brandwine: Abstract, 0031, 0038; Figs.1a-b & 2a].
As per claim{s} 15, Middleton in view of Obviousness in view of Alabsi in view of Brandwine discloses the recited features of the claim. The claim recites substantially the same features / limitations as those recited by the combination of claims 1 and 14 (previously rejected above), except for the additional recited features of a computing system (Middleton: e.g., Computing System 1800) [0139; Fig. 5] comprising at least one first processor (Middleton: e.g., Processor 1810) [0139; Fig. 5]; and a first non-transitory computer readable medium communicatively coupled to the at least one first processor (Middleton: e.g., Computer system 1800 may include one or more of a variety of different ‘computer-readable media’ ) [0145; Fig. 5], the first non-transitory computer readable medium having stored thereon computer software comprising a first set of instructions that, when executed by the at least one first processor, causes the computing system to: (Middleton: e.g., Many of the above-described processes and components are implemented as ‘software processes’ that are specified as a set of ‘instructions’ recorded on a ‘computer readable storage medium’ (also referred to as computer readable medium). ‘Instructions’ are executed by one or more computational element(s) (such as processors or other computational elements like ASICs and FPGAs), that cause the computational element(s) to perform the actions indicated) [0138; Fig. 5]
monitor usage of the first set of network resources (Middleton: e.g., The Edge servers run various processes that (1) manage what content is cached, (2) how content is cached, (3) how content is retrieved from the origin server when the content is not present in cache, (4) monitor server capacity (e.g., available processor cycles, available memory, available storage, etc.), (5) monitor network performance (e.g., latency, downed links, etc.), and (6) report statistics on the delivered content. The set of Edge servers 110 may provide the ‘monitoring information’ to the traffic management servers 120 to facilitate the routing of content consumers to the optimal edge servers) [0005] – which are nonetheless also disclosed by Middleton (as above).
As per claim{s} 16, Middleton in view Obviousness discloses the recited features of the claim. The claim recites substantially the same features / limitations as claim 10 (previously rejected above), is distinguishable only by its statutory category (system), and accordingly rejected on the same basis.
As per claim{s} 17, Middleton in view of Obviousness in view of Alabsi in view of Brandwine discloses the recited features of the claim. The claim recites substantially the same features / limitations as claim 14 (previously rejected above), is distinguishable only by its statutory category (system), and accordingly rejected on the same basis.
As per claim{s} 21, Middleton in view of Obviousness in view of Alabsi in view of Brandwine discloses the recited features of the claim. The claim recites substantially the same features / limitations recited by the combination of claims 1, 6, 14 and 15 (previously rejected above), and accordingly rejected on the same basis.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451
