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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
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-6 and 10-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In adhering to the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG), Step 1 is directed to determining whether or not the claims fall within a statutory class. Herein, the claims fall within statutory class of process, machine or manufacture. Hence, the claims qualify as potentially eligible subject matter under 35 U.S.C §101. With Step 1 being directed to a statutory category, the analysis directed to Step 2A.
Step 2A is a two prong inquiry. Prong 1 considers whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). In this case independent claim 1 recites mental processes as applied to human activity (i.e. human interaction with a computer and concepts performed in the human mind). For example, but for the recitation of generic computing components, the claimed steps of (1) “scheduling and deploying, based on a domain controller node of the domain controller system, a container corresponding to the domain controller node...” and (2) “scheduling and deploying, based on a remote server of the domain controller system, the container corresponding to the domain controller node...” are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion, thus it is reasonable to identify these limitations as reciting a mental process. See, MPEP 2106.04(a)(2) III C).
Since the claims are directed toward a judicial exception, analysis flows to Prong 2. Prong 2 considers whether the judicial exception is integrated into a practical application. In this case, the judicial exception is not integrated into a practical application for the following reasons:
The additional elements of a “domain controller system of a vehicle ,” “domain controller node of the domain controller system,” and “container corresponding to the domain controller node” is recited at a high level of generality and amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f));
The recitation of a “domain controller system of a vehicle ,” “domain controller node of the domain controller system,” “container corresponding to the domain controller node; ” “current application environment of the domain controller system is a formal environment;” and “current application environment of the domain controller system is a development test environment” amounts to an attempt to link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)).
Since the claims are directed to the determined judicial exception, the analysis flows to Step 2B. Therein, the elements and combination of elements are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. In this case, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. It is noted here that the elements should be considered both individually and as an ordered combination. In this case, the claimed method, computer-readable storage medium, and electronic device each are generically recited and thus do not add significantly more to the respective limitations. Taken as an ordered combination, the limitations are directed to limitations referenced in Alice Corp. (also called the Mayo test) that are not enough to qualify as significantly more when recited in a claim with an abstract idea include, as a non-limiting or non-exclusive examples: (i) mere instructions to implement the idea on a computer, and/or (ii) recitation of generic computer structure that serves to perform generic computer functions that are well-understood, routine, and conventional activities previously known to the pertinent industry. The limitations that recite specific computer elements do not add significantly more because they are simply an attempt to limit the abstract idea to a particular technological environment. (MPEP § 2106.05 (I)(A)), “Limitations that the courts have found not to be enough to qualify as “significantly more” when recited in a claim with a judicial exception include: i. …mere instructions to implement an abstract idea on a computer.” Viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself (Note MPEP 2106.05(a)). Since there are no elements or ordered combination of elements that amount to significantly more than the judicial exception, the claims are not eligible subject matter under 35 USC §101.
For the above reasons, the claims of this application are not patentable under 35 USC 101.
Regarding claims 2, 12, and 17: the “performing” step recited in claim 2 is an additional mental process under Prong 1 since this function can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion but for the recitation of generic computing components. For example, a person can think and evaluate whether to perform capacity expansion or capacity reduction based on observing a current operation status of a domain controller system.
Claims 12 and 17 are similar to claim 2 and are ineligible for the same reasons as claim 2.
Regarding claim 3, 13, and 18: the “deleting” and “creating” limitations recited in claim 3 are additional mental processes under Prong 1 since these can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion but for the recitation of generic computing components. For example, a person can think and evaluate whether to delete/create a container based on observing a container failure.
Claims 13 and 18 are similar to claim 3 and are ineligible for the same reasons as claim 3.
Regarding claim 4, 14, and 19: the additional element of “distributing, based on a usage scenario of the domain controller system, a container application corresponding to the usage scenario to the domain controller node of the domain controller system by utilizing the remote server, so that the domain controller node completes an application deployment” recited in claim 4 amounts to a mere recitation of an insignificant extra-solution data transmission activity (see MPEP § 2106.05(g)). The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network (See MPEP § 2106.05(d)(II)).
Claims 14 and 19 are similar to claim 4 and are ineligible for the same reasons as claim 4.
Regarding claims 5, 15, and 20: the “containerd” limitation recited in claim 5 amounts to an attempt to generally link the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h).
Claims 15 and 20 are similar to claim 5 and are ineligible for the same reasons as claim 5.
Regarding claims 6, 16, and 21: the “K3s” limitation recited in claim 6 amounts to an attempt to generally link the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h).
Claims 16 and 21 are similar to claim 6 and are ineligible for the same reasons as claim 6.
Regarding claim 10, this claim is not patent eligible for the same reasons given for claim 1 for the common limitations. The recitation of the additional element of “a computer-readable storage medium, encoded with instructions, that when executed by one or more computers, cause the one or more computers to perform operations” amounts to merely applying the judicial exception under Prong 2 (MPEP § 2106.05(f)), thus not a practical application, nor amounts to significantly more than the judicial exception under Step 2B. ” The additional elements of a “computer-readable storage medium, encoded with instructions;” and “one or more computers” amounts to merely using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f)) under Prong 2, thus not a practical application, nor amounts to significantly more than the judicial exception under Step 2B.
Regarding claim 11, this claim is not patent eligible for the same reasons given for claim 1 for the common limitations. The recitation of the additional element of “wherein the processor is configured to execute operations” and “a memory for storing an instruction executable by the processor” amounts to amounts to merely using a generic computing component as a tool to apply the abstract idea under Prong 2 (MPEP § 2106.05(f)), thus not a practical application, nor amounts to significantly more than the judicial exception under Step 2B.
Claims 10 and 12-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
During examination, the claims must be interpreted as broadly as their terms reasonably allow. In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 U.S.P.Q.2d 1827, 1834 (Fed. Cir. 2004). Independent claim 10 recites a “computer-readable storage medium,” which is not comprehensively defined by the specification. The broadest reasonable interpretation of a claim drawn to a computer-readable storage medium covers forms of transitory propagating signals in view of the ordinary and customary meaning of computer readable media, particularly when the specification is silent. Transitory propagating signals are non-statutory subject matter. In re Nuijten, 500 F.3d 1346, 1356-57, 84 U.S.P.Q.2d 1495, 1502 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter). See also Subject Matter Eligibility of Computer Readable Media, 1351 Off. Gaz. Pat. Office 212 (Feb. 23, 2010). Examiner suggests adding the word “non-transitory.”
Claims 12-16 are rejected due to their dependence on independent claim 10.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 4, 10-12, 14, 17, and 19 are rejected under 35 U.S.C. 102 as being anticipated by Harel et al. (WO 2020047016 A1).
As per claim 1, Harel teaches the invention substantially as claimed including a container scheduling and deployment method, applied to a domain controller system of a vehicle ([0007], vehicle or IoT system controllers may operate in a virtualized framework, where individual controllers may be deployed as ...container instances), comprising:
scheduling and deploying ([0172], the instantiation of the virtual instance may occur on-demand or in a just-in-time manner), based on a domain controller node of the domain controller system ([0007], vehicle or IoT system controllers may operate in a virtualized framework, where individual controllers may be deployed as ...container instance; and [0142], Virtual computing instances 202, 205, and 208 may emulate or be otherwise associated with an ECU and/or vehicle function; Examiner Note: the claimed “domain controller node” is mapped to Harel’s “vehicle controller/ECU), a container corresponding to the domain controller node ([0142], a virtual computing instance may be spun up on demand to emulate or perform a particular vehicle function; and [0172], virtual computing instances, may be spun up to anticipate or react to these dynamic conditions of the vehicle. For example, in some embodiments a user’s detected approach to the vehicle (e.g., based on signals or signal strength from a keyless entry device, smartphone, etc.) may be a prompt to instantiate virtual computing instances associated with vehicle operation; Examiner Note: Harel’s “virtual computing instances” are containers: [0011], the plurality of virtual computing instances are container resources) when a current application environment of the domain controller system is a formal environment ([0142], a virtual computing instance may be spun up on demand to emulate or perform a particular vehicle function, which may or may not be live (i.e., currently operating within a vehicle)); and
scheduling and deploying ([0142], a virtual computing instance may be spun up on demand to emulate or perform a particular vehicle function; and [0172], process 1300 may instantiate a virtual computing instance. This virtual computing instance may be a ...container resource), based on a remote server of the domain controller system ([0142], virtual computing instances may be instantiated in response to a user input, either at the vehicle or remotely from it; and [0171], process 1300 may be performed ... by an external device (e.g., database 302)), the container corresponding to the domain controller node ([0142], Virtual computing instances 202, 205, and 208 may emulate or be otherwise associated with an ECU and/or vehicle function. For example, virtual computing instance 202 may be spun up to emulate or perform the braking operation of a vehicle) when the current application environment of the domain controller system is a development test environment ([0162], Virtual testing variables 1000 may be applied to virtual computing instance 202 to cause changes in the virtual testing environment. By operating ECU or controller 203 and vehicle function 204 in a virtual computing environment and applying virtual testing variables 1000 to that environment, virtual computing instance 202 may be able to monitor the behavior of ECU or controller 203 and/or vehicle function 204 to observe any changes).
As per claim 2, Harel teaches, wherein the scheduling and deploying, based on a domain controller node of the domain controller system, a container corresponding to the domain controller node comprises:
performing, based on a current operation status of the domain controller system, capacity expansion or capacity reduction on the container corresponding to the domain controller node by utilizing the domain controller node ([0142], a virtual computing instance may be spun up on demand to emulate or perform a particular vehicle function...This may be done automatically, such as in response to a strain or load on a particular device in a vehicle. In some embodiments, virtual computing instances may be instantiated in response to a user input, either at the vehicle or remotely from it. In other embodiments, virtual computing instances may be instantiated in response to a particular action of vehicle communication network 1 , such as a system boot or detection of high system load for a particular function; and [0143], when a vehicle is parked, a virtual computing instance associated with an acceleration function or anti-lock brakes function may be spun down).
As per claim 4, Harel teaches, wherein the scheduling and deploying, based on a remote server of the domain controller system, the container corresponding to the domain controller node comprises:
distributing, based on a usage scenario of the domain controller system, a container application corresponding to the usage scenario to the domain controller node of the domain controller system by utilizing the remote server ([0180], process 1300 may save data (e.g., trace information) relating to the determination of whether a virtual computing instance’s behavior is a deviation from a security rule set (e.g., at memory 102 and/or database 302). This information may be analyzed at database 302 or elsewhere to adjust the determination of rules to add to a security rule set at step 1302. The rule set may then be applied from database 302 to multiple ECUs across multiple vehicles; Examiner note: “database 302” is an external server that can distribute containers: [0144], database 302 is external to vehicle communications system 3; [0145], Database 302 may also be an instance of computer 100 in some embodiments; [0171], process 1300 may be performed by ... an external device (e.g., database 302); [0172], process 1300 may instantiate a virtual computing instance), so that the domain controller node completes an application deployment ([0180], an action deviating from a rule set of one virtual computing instance may be used to harden ECUs across multiple vehicles; and [0195], if the external application is determined to be unsafe, it may be deleted (i.e. , removed from virtualized environment memory 907 and/or all parts of vehicle communications system 7). In some embodiments, process 1400 may also report the unsafe application to another computing device (e.g., database 302). In response to a report from process 1400, security rule program 6, rule table 403, process 1300, and/or related software may be changed (e.g., by database 302) in order to respond to a threat posed by the unsafe application).
As per claim 10, this is the “computer-readable storage medium claim” corresponding to claim 1 and is rejected for the same reasons.
As per claim 11, this is the “electronic device claim” corresponding to claim 1 and is rejected for the same reasons.
As per claim 12, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 14, this claim is similar to claim 4 and is rejected for the same reasons.
As per claim 17, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 19, this claim is similar to claim 4 and is rejected for the same reasons.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 3, 13, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Harel as applied to independent claims 1, 10, and 11 and in further view of Hallur et al. (US 20210034423 A1).
As per claim 3, Harel fails to specifically teach wherein the scheduling and deploying, based on a domain controller node of the domain controller system, a container corresponding to the domain controller node comprises: when the container corresponding to the domain controller node is a failed container, deleting the failed container and creating a new container corresponding to the failed container by utilizing the domain controller node.
However, Hallur teaches, wherein the scheduling and deploying, based on a domain controller node of the domain controller system, a container corresponding to the domain controller node comprises:
when the container corresponding to the domain controller node is a failed container ([0071], container orchestration program 101 determines that a container is unhealthy based, at least in part, on identifying an anomaly between containers running on the worker nodes), deleting the failed container ([0073], stateful containers are terminated and restarted on a different worker node) and creating a new container corresponding to the failed container by utilizing the domain controller node ([0073], container orchestration program 101 generates a replica container corresponding to the unhealthy container... deploying a new container includes generating a replica of the original application container).
Harel and Hallur are analogous because they each related to container management. Harel teaches a method of container management including monitoring, scaling, and testing containers in a vehicle system. (Abstract, Techniques include instantiating a plurality of virtual computing instances in a vehicle computing network within the vehicle, each of the plurality of virtual computing instances being configured to perform at least one vehicle software function; and identifying, for the plurality of virtual computing instances; [0012], the plurality of virtual computing instances are configured to be spun up, on demand, to perform the at least one vehicle software function; [0017], the operations further comprise monitoring functionality of the plurality of virtual computing instances during live operations in the vehicle computing network; and [0160], Virtualized environment memory 907 may include a portion designated as a “sandbox,” which may be configured to store an application safely (e.g., in memory space lacking network or other connections and/or in a read-only memory space), such that it cannot perform an operation within vehicle communications system 7 or otherwise interact with vehicle communications system 7). Hallur teaches a method of managing distributed containers including recovering from container failures based on monitoring informaton. ([0071], container orchestration program 101 determines whether the container workload is healthy. In some embodiments of the invention, container orchestration program 101 determines that a container is unhealthy based, at least in part, on identifying an anomaly between containers running on the worker nodes; and [0073], stateful containers are terminated and restarted on a different worker node). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, Harel’s container monitoring mechanism would be modified to include Hallur’s recovery mechanism to remedy failed container instances. This combination would result in a container management system that can recover from container failures observed from container monitoring. Therefore, it would have been obvious to combine the teachings of Harel and Hallur.
As per claim 13, this claim is similar to claim 3 and is rejected for the same reasons. The same motivation used in the rejection of claim 3 is applicable to the instant claim.
As per claim 18, this claim is similar to claim 3 and is rejected for the same reasons. The same motivation used in the rejection of claim 3 is applicable to the instant claim.
Claims 5, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Harel as applied to independent claims 1, 10, and 11 and in further view of Rodriguez et al. (US 20220171648 A1).
As per claim 5, Harel fails to specifically teach, wherein a containerd container is adopted as the container, and the containerd container is used for decoupling functional modules in the domain controller node.
However, Rodriguez teaches, wherein a containerd container is adopted as the container ([0040], the container runtime service 112 may be implemented on top of the container runtime provided by ContainerD), and the containerd container is used for decoupling functional modules in the domain controller node ([0041], after the Linux kernel 106 boots, instead of pivoting to SystemD to perform the typical “init” process, the container-first architecture 100 pivots to the container runtime service 112 (e.g., ContainerD) as the process used to bootstrap the user space. All processes that are initialized have their own namespace and are containerized, including ntpd (Network Time Protocol daemon), crontab, dhcpd (Dynamic Host Configuration Protocol daemon), user login, terminal, and so forth).
Harel and Rodriguez are analogous because they each related to container management. Harel teaches a method of container management including monitoring, scaling, and testing containers in a vehicle system. (Abstract, Techniques include instantiating a plurality of virtual computing instances in a vehicle computing network within the vehicle, each of the plurality of virtual computing instances being configured to perform at least one vehicle software function; and identifying, for the plurality of virtual computing instances; [0012], the plurality of virtual computing instances are configured to be spun up, on demand, to perform the at least one vehicle software function; [0017], the operations further comprise monitoring functionality of the plurality of virtual computing instances during live operations in the vehicle computing network; and [0160], Virtualized environment memory 907 may include a portion designated as a “sandbox,” which may be configured to store an application safely (e.g., in memory space lacking network or other connections and/or in a read-only memory space), such that it cannot perform an operation within vehicle communications system 7 or otherwise interact with vehicle communications system 7). Rodriguez teaches a method of container management including using containerd functionality to efficiently monitor containers and manage container lifecycles. (Abstract, The processing circuitry is to: instantiate a plurality of containers on a host operating system; [0040], the container runtime service 112 may be implemented on top of the container runtime provided by ContainerD. ContainerD is a container runtime that manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond; and [0049], “container-first” architecture 100 provides complete abstraction from the Linux kernel 106 and the file system distribution, which provides numerous advantages. For example, this architecture gives an operator the flexibility to run any container from any Linux distributor on this platform. Moreover, since the operating system files are slim and simple, this architecture simplifies manageability and orchestration and minimizes the attack surface. Further, since everything running on the platform is containerized, these objects can be hashed and inventoried during runtime to verify their validity before execution, thus further improving security). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, Harel’s container management mechanism of its “external server” would be modified to include the containerd management mechanism as taught by Rodriguez to efficiently manage containers in a vehicle system. This combination would result in a container management system that can that efficiently manage distributed containers. Therefore, it would have been obvious to combine the teachings of Harel and Rodriguez.
As per claim 15, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 5 is applicable to the instant claim.
As per claim 20, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 5 is applicable to the instant claim.
Claims 6, 16, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Harel as applied to independent claims 1, 10, and 11 and in further view of Panikkar et al. (US 20230334541 A1).
As per claim 6, Harel fails to specifically teach, wherein a K3s deployment mode is applied to the container.
However, Panikkar teaches, wherein a K3s deployment mode is applied to the container ([0023], RISC-based processor 220 is configured to support execution of such functions within a container orchestration framework known as K3s from Kubernetes of San Francisco, CA).
Harel and Panikkar are analogous because they each related to container management. Harel teaches a method of container management including monitoring, scaling, and testing containers in a vehicle system. (Abstract, Techniques include instantiating a plurality of virtual computing instances in a vehicle computing network within the vehicle, each of the plurality of virtual computing instances being configured to perform at least one vehicle software function; and identifying, for the plurality of virtual computing instances; [0012], the plurality of virtual computing instances are configured to be spun up, on demand, to perform the at least one vehicle software function; [0017], the operations further comprise monitoring functionality of the plurality of virtual computing instances during live operations in the vehicle computing network; and [0160], Virtualized environment memory 907 may include a portion designated as a “sandbox,” which may be configured to store an application safely (e.g., in memory space lacking network or other connections and/or in a read-only memory space), such that it cannot perform an operation within vehicle communications system 7 or otherwise interact with vehicle communications system 7). Panikkar teaches utilizing K3s functionality in order to more effectively manage containers in remote devices. ([0022], RISC-based processors are suitable for execution of code in resource-constrained environments and can run resource-constrained operating systems such as, but not limited to, an Android operating system. In illustrative embodiments, a vendor agent is considered code executable in a resource-constrained environment and which is configured to operate as efficiently as possible within computing device 102 in terms of a physical footprint and/or an energy footprint; RISC-based processor 220 is configured to support execution of such functions within a container orchestration framework known as K3s from Kubernetes of San Francisco, CA; and [0029], K3 is a highly available, certified Kubernetes distribution designed for production workloads in unattended, resource-constrained, remote locations or inside Internet of Things (IoT) appliances. K3 is packaged as a single less than 40 MB binary that reduces the dependencies and steps needed to install, run and auto-update a production Kubernetes cluster). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, that based on the combination, Harel would be modified to include K3S deployment functionalities as taught by Panikkar in order for its “external server” to manage containers on remote vehicle systems. This combination would result in a container management system that is able to effectively deploy and manage containers in a remote vehicle based system. Therefore, it would have been obvious to combine the teachings of Harel and Panikkar.
As per claim 16, this claim is similar to claim 6 and is rejected for the same reasons. The same motivation used in the rejection of claim 6 is applicable to the instant claim.
As per claim 21, this claim is similar to claim 6 and is rejected for the same reasons. The same motivation used in the rejection of claim 6 is applicable to the instant claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/MELISSA A HEADLY/Examiner, Art Unit 2197