DETAILED ACTION
This office action is in response to claims filed 12 June 2026.
Claims 1, 3-8, 10-15, and 17-23 are pending.
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 .
Allowable Subject Matter
Claims 21-23 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.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3-8, 10-15, and 17-20 have been considered but are moot because the matter specifically challenged in the argument does not address the new reference used in the current rejection (RAZ, cited below).
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 conflicting claims 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) 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 www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 8, and 15 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, and 15 of Patent No.: US 12,348,374 B2 (hereafter Reference Patent) in view of MITKAR et al. Pub. No.: US 2018/0285199 A1 (hereafter MITKAR).
MITKAR was cited previously.
Regarding claim 1 of instant application, the following table emphasizes the similarities between it and claim 1 of the Reference Patent:
Instant Application
Reference Patent
1. A method for managing operation of endpoint devices of edge infrastructure, the method comprising:
obtaining, from a requestor, an access request for a service to be provided by an endpoint device of the endpoint devices;
obtaining, based on the requestor, a requestor activity profile that specifies a first set of limits on use of the endpoint device by the requestor and that is based on at least two measured activity profiles of users classified as having a same persona;
obtaining, based on the service, a service activity profile;
obtaining, based on the requestor activity profile and the service activity profile, a container definition; and
instantiating, using the container definition and to service the access request, a containerized service on the endpoint device to obtain an updated endpoint device that provides the service to the requestor.
1. A method for managing operation of endpoint devices of edge infrastructure, the method comprising:
obtaining a container definition for a containerized service requested by a requestor;
instantiating a first container based on a first portion of the container definition, the first portion of the container definition being based on a requestor activity profile for the requestor, the requestor activity profile being based on at least two measured activity profiles of users classified as having a same persona, the requestor being one of the users, and the at least two measured activity profiles specify characteristics of the users of corresponding endpoint devices of the endpoint devices used to provide other instances of the containerized service to the users;
instantiating a second container hosted by the first container to obtain an instance of the containerized service, the second container being based on a second portion of the container definition; and
providing computer implemented services using the containerized service hosted by an endpoint device of the endpoint devices.
7. The method of claim 1, wherein the second portion of the container definition is based on a service activity profile that specifies a second set of limits on use of the endpoint device by at least one application that provides, at least in part, the containerized service.
While Claim 1 of the reference patent discusses obtaining both a requestor activity profile and a service activity profile, Claim 1 of the reference patent does not explicitly teach:
obtaining, based on the requestor activity profile and the service activity profile, a container definition;
However, in analogous art that similarly discusses instantiation of containerized services, MITKAR teaches:
obtaining, based on the requestor activity profile and the service activity profile, a container definition ([0310] At block 616, the image generator 304 generates a container image (i.e., “container definition”) based at least in part on the retrieved application binaries, configuration data (i.e., as discussed below in the rejection of claim 1 under 35 U.S.C 102(a)(1), application binaries and configuration data represent application “service activity profile” data), and the user data (i.e., “requestor activity profile” data));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined MITKAR’s teaching of building a container image definition based on application activity data and user activity data, with claim 1 of the reference application’s teaching of instantiating a container image based on either application activity data or user activity data, to realize, with a reasonable expectation of success, a system that obtains both requestor activity and service activity profiles, as in claim 1 of the reference patent, and generates a container image for instantiation based on both, as in MITKAR. A person having ordinary skill would have been motivated to make this combination to instantiate more optimal containerized services that better suit the needs of users based on their activity as well as the activity of the services themselves.
Regarding claims 8, and 15, they comprise limitations similar to claim 1, and are therefore rejected for similar rationale.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 8, 11, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR (cited above), in further view of RAZ et al. Patent No.: US 7,984,151 B1 (hereafter RAZ).
Regarding claim 1, MITKAR teaches the invention substantially as claimed, including:
A method for managing operation of endpoint devices of edge infrastructure, the method comprising:
obtaining, from a requestor, an access request for a service ([0303] The process 600 begins at block 602 where, for example, the image generator 304 receives a selection of an application to include in a container image (i.e., a request for an application requests the “services” provided by that application (see [0065] for a list of various “services” provided by applications including email, file system, database, etc.))) to be provided by an endpoint device of the endpoint devices ([0005] A container may be instantiated or formed on a computing system from a container image);
obtaining, based on the requestor, a requestor activity profile ([0308] At block 612, the image generator 304 identifies the storage location at the secondary storage system 118 of user data generated by the application selected at the block 602 at the client computing device 102. [0309] At block 614, the media agent 144 retrieves the data from the secondary storage devices 108 corresponding to the storage locations identified at the block 612 (i.e., retrieving user data indicative of activities performed for the user represents obtaining a “requestor activity profile”)) that specifies a first set of limits on use of the endpoint device by the requestor ([0274] Classifying the data may include identifying one or more applications 110, configuration data or information for one or more of the applications 110, data created in response to interaction with the applications 110 (e.g., files, application state information, or other user data that may be created or modified in response to a user's interaction with the applications 110), or any other types of data that may be associated with the one or more applications 110. The user data created in response to interaction with the applications 110 may refer to any type of data that may be created or modified in response to a user's interaction with one or more of the applications 110. Typically, this user data is separate from the files required to install or execute the applications 110. However, in some cases, the user data may include a modified form of a file used to facilitate execution of an application, such as a configuration file or a state saving file. In one example, the user data may include files created by the user or application state information generated or modified in response to a user's interaction with the application 110. For instance, for a word processing application, the configuration data may include a default folder for storing user data, and the user data may refer to one or more documents created by a user using the word processing application. As another example, for a webserver management application, the configuration data may include access control information for users, and the user data may refer to one or more webpages to be served by the webserver managed by the Web server management application (i.e., user data imposes limits on execution of a container based on user interaction with the application; those limits include what files or documents to use, what webpages to serve by a webserver, etc.));
obtaining, based on the service, a service activity profile ([0305] At block 606, the media agent 144 retrieves the application binaries from the secondary storage devices 108 corresponding to the storage locations identified at the block 604. [0306] At block 608, the image generator 304 identifies the storage location at the secondary storage system 118 of configuration data associated with the application selected at the block 602. [0307] At block 610, the media agent 144 retrieves the configuration data from the secondary storage devices 108 corresponding to the storage locations identified at the block 608 (i.e., retrieving either application binaries representing execution activity of the application, or configuration data of the application representing data associated with the activity of the application, represents obtaining a “service activity profile”));
obtaining, based on the requestor activity profile and the service activity profile, a container definition ([0310] At block 616, the image generator 304 generates a container image (i.e., “container definition”) based at least in part on the retrieved application binaries, configuration data, and the user data); and
instantiating, using the container definition and to service the access request, a containerized service on the endpoint device to obtain an updated endpoint device that provides the service to the requestor ([0005] A container may be instantiated or formed on a computing system from a container image (i.e., instantiating the container on the computing system “updates” the computing system to provide the application to the user requesting the application)).
While MITKAR discusses obtaining a requestor activity profile, MITKAR does not explicitly teach that the requestor activity profile is further:
based on at least two measured activity profiles of users classified as having a same persona.
However, in analogous art that similarly discusses obtaining user profiles of application activity, RAZ teaches that a requestor activity profile is:
based on at least two measured activity profiles of users classified as having a same persona ([Column 5, Lines 23-34] The aggregated user profile information may include information describing at least one system resource usage attribute having a similar value for each user of the group. For example, a first group of users (i.e., representing a first “persona”) may be associated with respective individualized user data substantially occupying 5 megabytes of storage (i.e., multiple users are classified as being in the first group based on their storage usage, or “activity”), while a second group of users may be associated with respective individualized user data substantially occupying only 500 kilobytes of storage or less. Thus, the aggregated user profile information for the first group would indicate that the members of the group use more storage space for their data than users of the second group).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined RAZ’s teaching of aggregating user profiles by classifying users into different groups or personas, with MITKAR’s teaching of using a requestor activity profile to obtain a container definition, to realize, with a reasonable expectation of success, a system that obtains a container definition based on requestor activity profile, as in MITKAR, where the activity profile is based on classifying activity of multiple users into a single persona, as in RAZ. A person having ordinary skill would have been motivated to make this combination to improve system performance, in terms of latency, efficiency and redundancy (RAZ Column 1, Lines 36-40).
Regarding claim 4, RAZ further teaches:
the at least two measured activity profiles specifying characteristics of users of corresponding endpoint devices of the endpoint devices used to provide other instances of the service to the users ([Column 5, Lines 23-34] The aggregated user profile information may include information describing at least one system resource usage attribute having a similar value for each user of the group. For example, a first group of users (i.e., representing a first “persona”) may be associated with respective individualized user data substantially occupying 5 megabytes of storage (i.e., multiple users are classified as being in the first group based on their storage usage, or “activity”), while a second group of users may be associated with respective individualized user data substantially occupying only 500 kilobytes of storage or less. Thus, the aggregated user profile information for the first group would indicate that the members of the group use more storage space for their data than users of the second group (i.e., each aggregated user profile specifies a resource usage characteristic of a user)).
Regarding claims 8, 11, 15, and 18, they comprise limitations similar to those of claims 1, and 4, and are therefore rejected for similar rationale.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, in view of RAZ, as applied to claims 1, 8, and 15 above, and in further view of CHAWLA et al. Patent No.: US 8,555,274 B1 (hereafter CHAWLA).
CHAWLA was cited previously.
Regarding claim 3, MITKAR further teaches:
the first set of limits comprising…
a second limit on use of applications hostable by the endpoint device ([0274] However, in some cases, the user data may include a modified form of a file used to facilitate execution of an application, such as a configuration file or a state saving file. In one example, the user data may include files created by the user or application state information generated or modified in response to a user's interaction with the application 110. For instance, for a word processing application, the configuration data may include a default folder for storing user data, and the user data may refer to one or more documents created by a user using the word processing application. As another example, for a webserver management application, the configuration data may include access control information for users, and the user data may refer to one or more webpages to be served by the webserver managed by the Web server management application (i.e., user data specifies, or “limits” aspects of execution of at least a word processing application or a webserver application in the examples by specifying documents for the word processing application to use, or webpages for the webserver to serve));
a third limit on use of portions of data hostable by the endpoint device ([0274] In some cases, the user data may include a modified form of a file used to facilitate execution of an application, such as a configuration file or a state saving file. In one example, the user data may include files created by the user or application state information generated or modified in response to a user's interaction with the application 110. For instance, for a word processing application, the configuration data may include a default folder for storing user data (i.e., user data specifies, or “limits” where files created by the user are stored and used)); and
a fourth limit on distribution, by the requestor, of data hosted by the endpoint device ([0274] As another example, for a webserver management application, the configuration data may include access control information for users, and the user data may refer to one or more webpages to be served by the webserver managed by the Web server management application (i.e., user data specifies, or “limits” at least the web pages served, or “distributed” to the user)).
While MITKAR and RAZ discusses provisioning, they do not explicitly teach:
the first set of limits comprising: a first limit on use of hardware resources of the endpoint device
However, in analogous art that similarly provisions containers on endpoint devices, CHAWLA teaches:
the first set of limits comprising: a first limit on use of hardware resources of the endpoint device ([Column 7, Lines 39] A method of providing a remote virtualized desktop to a user includes describing resource parameters for a user, the resource parameters specifying a maximum resource allocation for all virtual machines provided to a particular user, the resource parameters including at least one of a central processing unit (CPU) usage and a memory usage (i.e., resource parameters represent a “first limit” on use of CPU or memory resources for a particular user)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined CHAWLA’s teaching of provisioning a container on an endpoint device based on user parameters related to use of hardware resource, with MITKAR and RAZ’s teaching of provisioning a container on an endpoint device based on user parameters, to realize, with a reason able expectation of success, a system that provisions a container on an endpoint based on user parameters, as in MITKAR and RAZ, which include parameters related to limits of hardware resource use, as in CHAWLA. A person having ordinary skill would have been motivated to make this combination to ensure that load balancing is achieved, QoS parameters are met, and that resource quotas allocated to each user are not exceeded (CHAWLA Abstract).
Regarding claims 10, and 17, they comprise limitations similar to claim 3, and are therefore rejected for similar rationale.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, and RAZ, as applied to claims 1, 8, and 15 above, and in further view of SAEKI Pub. No.: US 2023/0236818 A1 (hereafter SAEKI).
SAEKI was cited previously.
Regarding claim 5, while MITKAR and RAZ discusses provisioning of containers on endpoint devices, MITKAR and RAZ does not explicitly teach:
the service activity profile specifies a second set of limits on use of the endpoint device by at least one application that provides, at least in part, the service.
However, in analogous art that similarly provisions containers on endpoint devices, SAEKI teaches:
the service activity profile specifies a second set of limits on use of the endpoint device by at least one application that provides, at least in part, the service ([0103] A certain margin of resource usage can be added to the resource usage to calculate a container resource usage limit value (i.e., “second set of limits on use of an endpoint device”). The container resource usage limit value can be obtained by statistically processing the resource usage data in the time periods of the feature vectors belonging to the cluster. For example, extreme outliers are excluded, and an arithmetic average is calculated for each of (the CPU, the virtual memory capacity, the storage capacity, and the network bandwidth) of the resource usage data for each feature vector v (i.e., CPU, memory, and network bandwidth limits represent limits on use of resources of the endpoint device by a container providing a service)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined SAEKI’s teaching of setting usage limit values related to application utilization of container resources including CPU, memory and network bandwidth, with MITKAR and RAZ’s teaching of provisioning containerized applications on endpoint devices, to realize, with a reasonable expectation of success, a system that provisions containerized applications on endpoint devices, as in MITKAR and RAZ, according to usage limit values set for application utilization of container resources, as in SAEKI. A person of ordinary skill would have been motivated to make this combination to improve efficiency of cloud resource usage and optimally deploy an application on a container of the cloud (SAEKI [0014]).
Regarding claims 12 and 19, they comprise limitations similar to claim 5, and are therefore rejected for similar rationale.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, in view of RAZ, in view of SAEKI, as applied to claims 5, 12, and 19 above, and in further view of BANKA et al. Pub. No.: US 2024/0403139 A1 (hereafter BANKA).
BANKA was cited previously.
Regarding claim 6, SAEKI further teaches:
the second set of limits comprising: a maximum quantity of computing resources of the endpoint device usable to provide the service; a network connectivity limit for the service…and a storage area access limit for the service ([0103] A certain margin of resource usage can be added to the resource usage to calculate a container resource usage limit value (i.e., “second set of limits on use of an endpoint device”). The container resource usage limit value can be obtained by statistically processing the resource usage data in the time periods of the feature vectors belonging to the cluster. For example, extreme outliers are excluded, and an arithmetic average is calculated for each of (the CPU (i.e., “computing resources”), the virtual memory capacity, the storage capacity (i.e., virtual and physical “storage area access”), and the network bandwidth (i.e., network “connectivity limit”)) of the resource usage data for each feature vector v (i.e., CPU, memory, and network bandwidth limits represent limits on use of resources of the endpoint device by a container providing a service)).
While MITKAR, RAZ, and SAEKI teaches setting limits for resource consumption by containerized applications, MITKAR, RAZ, and SAEKI does not explicitly teach:
the second set of limits comprising…a network reachability limit for the service;
However, in analogous art that similarly discusses provisioning resources to containerized applications based on resource limits, BANKA teaches:
the second set of limits comprising…a network reachability limit for the service ([0010] based on such a directive from the analytics system, the scheduler for the container orchestration system may process the network telemetry data, node telemetry data, and/or the application performance data to reprovision a workload to a different worker node. In some examples, the scheduler may determine that current network telemetry data indicates that a minimum bandwidth or minimum latency requirement for a workload can be met by scheduling the workload to a particular node having sufficient network resource availability (i.e., minimum latency requirement represents a “reachability” limit of a network that is used to provision network resources to a containerized application));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined BANKA’s teaching of a minimum latency requirement used to provision network resources to a containerized application, with the combination of MITKAR, RAZ, and SAEKI’s teaching of resource limits used to provision resources to containerized applications, to realize, with a reasonable expectation of success, a system that provisions resources to containerized applications based on resource limits, as in MITKAR, RAZ, and SAEKI, which include minimum latency requirement limits, as in BANKA. A person having ordinary skill would have been motivated to make this combination to ensure provisioned containerized applications meet minimum latency requirements.
Regarding claims 13, and 20, they comprise limitations similar to claim 6, and are therefore rejected for similar rationale.
Claims 7, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, in view of RAZ, in view of SAEKI, in view of BANKA, as applied to claims 6 and 13 above, and in further view of MEHTA et al. Pub. No.: US 2011/0320307 A1 (hereafter MEHTA).
MEHTA was cited previously.
Regarding claim 7, while MITKAR, SAEKI, and BANKA discuss execution of applications providing services, they do not explicitly teach:
the at least two measured activity profiles specifying characteristics of applications used to provide other instances of the service.
However, in analogous art that similarly teaches execution of applications providing services, MEHTA teaches:
the at least two measured activity profiles specifying characteristics of applications used to provide other instances of the service ([0027] Device usage data may be used in generating user profile data. For example, data related to the time and frequency of use applications (e.g., media players, installed applications, and the like) may be used (i.e., applications used by the users are specified as device usage data which is used to generate a user profile). [0068] Application recommendations are provided to the device user at 418. In some implementations, a subset of the ranked list of recommendations may be initially provided. For example, several (e.g., 5, 10, 50, etc.) recommendations may be initially provided, and a mechanism (e.g., a link) may be provided to the user such that the user may request additional recommendations (i.e., subsequent instances of application services are provided based on recommendations for applications which are themselves based on measured activity profiles specifying characteristics of application patterns)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined MEHTA’s teaching of user activity profiles representing patterns of application usage for use in recommending subsequent applications, with MITKAR, RAZ, SAEKI, and BANKA’s teaching of provisioning containerized applications on endpoint resources, to realize, with a reasonable expectation of success, a system that provisions containerized applications on endpoint resources, as in MITKAR, RAZ, SAEKI, and BANKA, based on application recommendations which are themselves based on user activity profiles representing patterns of application usage for user personas, as in MEHTA. A person having ordinary skill would have been motivated to make this combination to make better recommendations for applications to improve user experience.
Regarding claim 14, it comprises limitations similar to claim 7, and is therefore rejected for similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 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, Aimee Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195
Prosecution Insights