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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
The following NON-FINAL Office action is in response to application 18376852 filed 10/05/2023.
Status of Claims
Claims 1-20 are currently pending and have been rejected as follows.
Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 14 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 14 recites “The non-transitory computer readable medium of claim 7” etc. rendering said Claim 14 vague and indefinite because its parent Claim 7 is a method claim, and thus it is unclear for Claim 14 upon which antecedental subject matter it depends.
Claim 14 is recommended to be amended, to depend upon medium claim 8.
Clarification and/or corrections is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 14 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 14 is a non-transitory medium claim depending upon parent method claim 7. Thus,
Claim 14 fails to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim 14 is recommended to be amended, to depend upon medium claim 8.
Clarification and correction are required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract “container orchestration (CO)”, tested per MPEP 2106.04(A)(2) III C #2, and found to represent a computer environment upon which a mental process of “orchestration” [interpreted as management] is being implemented associated with decision-making of whether events are “non-skippable”, [interpreted as mandatory] or “skippable” [interpreted as non-mandatory] in the “stream” [or workflow] of “events”, based on a “determining” [or benchmarking] of whether or not “a rate” “exceeds” “threshold limit over the time period” (Claims 1,4,5,8,11 ,12,15,18,19). Then the “user” is being informed of the determination (i.e “non-skippable”) (Claims 1,8,15). These are not meaningfully different than the combination of collecting information, analyzing it, and displaying certain results of the collection and analysis, which according to MPEP 2106.04(a)(2) III A, 5th bullet point1, recite, describe or set forth the abstract mental processes.
Examiner again resubmits that MPEP 2106.04(A)(2) III C #2 is clear that performing a mental process [here “container orchestration”] in a computer environment does not preclude the claims from reciting abstract mental process. Additional evidence of such computer environment upon which to perform the abstract idea is evidenced by the narrowing of the “clusters” and “nodes” (Claims 6,7,12,14,20). Thus here the claims set forth the abstract idea. Step 2A prong 1.
This judicial exception is not integrated into a practical application because per Step 2A prong two, because the individual or combination of the additional, computer-based elements such as: “event processor” (Claims 1-12, 15-20), “software for presentation to a user” (Claims 1,8,15), “software executing in a data center” (dependent Claims 2,9, 16), “management software executing in a datacenter receives events generated by the plurality of clusters and provides the stream of events to the event processor” (dependent Claims 6,13,20), “software, executing on” “hardware platform” (dependent Claims 15,18,19), “client device in communication with management software executing in a data center” (dependent Claims 2,9,16), “client device in communication with a control plane node of the CO system” (dependent Claims 3,10,17) etc., are/is found to merely apply the already recited abstract exception, as tested per MPEP 2106.05(f), and/or narrow it to a technological environment or field of use, as tested per MPEP 2106.05(h), neither of which integrates said abstract exception into a practical application. For example, when tested, per MPEP 2106.05(f)(2) ¶1, they represent mere invocation of machinery to perform tasks to receive, store, or transmit data. Here such data corresponds to the associated “events” recited throughout Claims 1-20. Also, as tested per MPEP 2106.05(f)(2)(iii) such additional elements merely monitor of audit log data [here “events”] executed on a general-purpose computer. Such level of automation recited throughout Claims 1-20, when equally tested per MPEP 2106.05(h) vi., can also be argued as an example of narrowing the abstract exception to a field of use or technological environment such as narrowing the combination of collecting information, analyzing it, and displaying certain results of collection and analysis, to data related to a technological environment characterized by “control plane nodes of the CO system comprise at least one of controllers, schedulers, and application programming interface (API) servers, wherein the CO system comprises a data center and a plurality of sites, the event processor disposed in the data center, the worker nodes disposed in the plurality of sites, the worker nodes executing containerized network functions (CNFs)” at Claim 7 and similarly at Claim 14.
Thus, Examiner provided a preponderance of legal evidence showing that the automation / computerization above does not integrate the abstract exception into a practical application.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because Examiner follows MPEP 2106.05(d) II guidelines and carries over the above findings at MPEP 2106.05 (f) and/or (h) to submit that as shown above, the additional elements, merely apply the already recited abstract idea [MPEP 2106.05(f)] and/or narrow it to a field of use or technological environment [MPEP 2106.05(h)]. For these same reasons, said computer-based additional elements also do not provide significantly more than the abstract idea itself, in light of MPEP 2106.05(f) and/or (h) as sufficient option(s) for evidence without having to rely on the well understood routine and conventional test of MPEP 2106.05(d). Based on such legal evidence conferred by the MPEP 2106.05(f),(h) tests above, the Examiner submits that the additional computer-based elements do not provide significantly more without having to rely on the well understood routine and conventional test of MPEP 2106.05(d).
Yet, assuming arguendo that further evidence would be required to demonstrate conventionality of the additional, computer-based elements, the Examiner would further point to MPEP 2106.05(d) to demonstrate that said additional elements remain well-understood, routine, conventional. In such case, Examiner would rely on the Original Specification as follows:
- Original Specification ¶ [0051] 2nd-3rd sentences: “The apparatus may be specially constructed for required purposes, or the apparatus may be a general-purpose computer selectively activated or configured by a computer program stored in the computer. Various general-purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations”.
- Original Specification mid-¶ [0053] “In general, each virtual machine includes a guest operating system in which at least one application runs. It should be noted that, unless otherwise stated, one or more of these embodiments may also apply to other examples of contexts, such as containers”.
- Original Specification ¶ [0054] reciting at high level of generality: “Although one or more embodiments of the present invention have been described in some detail for clarity of understanding, certain changes may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein but may be modified within the scope and equivalents of the claims. In the claims, elements and/or steps do not imply any particular order of operation unless explicitly stated in the claims”.
- Original Specification ¶ [0055] reciting at high level of generality: “Boundaries between components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific configurations. Other allocations of functionality are envisioned and may fall within the scope of the appended claims. In general, structures and functionalities presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionalities presented as a single component may be implemented as separate components. These and other variations, additions, and improvements may fall within the scope of the appended claims”.
All of this preponderance of factual and/or legal evidence demonstrate that the additional computer-based elements fail to provide anything significantly more. Thus Claims 1-20, although directed to statutory categories (here “method” or process at Claims 1-7, “non-transitory medium” or computer product at Claim 8-13, 14[?], “system” or machine at Claims 15-20) they still recite, or at least set forth the abstract idea (Step 2A prong one), with their additional, computer-based elements not integrating the abstract idea into a practical application (Step 2A prong two) or providing significantly more than abstract idea (Step 2B). Thus, Claims 1-20 are ineligible.
Rejections under 35 § U.S.C. 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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 1-3,5,6,8-10,12,13,15-17,19,20 are rejected under 35 U.S.C. 103 as being unpatentable over:
Ovesea et al, US 20190235895 A1, Salesforce Inc, hereinafter Ovesea, in view of
Viggósson et al, US 20240412841 A1 hereinafter Viggósson. As per,
Claims 1,8,15 Ovesea teaches “A method of managing events in a container orchestration (CO) system, comprising”: / “A non-transitory computer readable medium comprising instructions to be executed in a computing device to cause the computing device to carry out a method of managing events in a container orchestration (CO) system, comprising”: (Ovesea ¶ [0168], [0175]-[0176]) / “A computer system, comprising: a hardware platform; software, executing on the hardware platform, configured to”: (Ovesea Fig.1A, ¶ [0041] 3rd sentence: various system constituents may be implemented through a combination of software and hardware. Also ¶ [0175] 1st-2nd sentences: system 500 may implement the techniques herein using device-specific hard-wired logic, one ASICs, FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 500 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 500 in response to processor 504 executing sequences of instructions contained in main memory 506)
- “receiving, at an event processor, a stream of events generated by the CO system”
(Ovesea ¶ [0052] 1st sentence: a system configuration for organization migrations comprises migration scheduler (102), migration orchestration engine (152), objects (e.g. processes, threads, objects, classes, interfaces, instantiations, implementers, methods, etc.) operating in conjunction with migration scheduler (102) and migration orchestration engine (152).
Ovesea ¶ [0156] 2nd sentence migration orchestration engine (e.g 152) receives migration configuration data for an organization migration to move application data and application services of a to-be-migrated organization hosted at a source system instance in a multi-tenant computing system to a target system instance in multi-tenant computing system. First, ¶ [0054] 5th sentence: collect (e.g. realtime) progresses of migration specific actions or steps in any given organization migration and present an up-to-date consistent view and/or history of the state of the organization migration. For example, per ¶ [0071] migration orchestration engine (152)…implement/create a finite state machine (FSM) based at least in part on migration stages in Figs.2A-B, including transitions between these migration stages. A transition refers to an action triggered by an event to leave the current state and to enter the next state following the current state.
Ovesea ¶ [0117] last sentence: migration scheduler (102) can collect or track progresses of the migration steps that have been initiated for execution at any given time point.
Ovesea ¶ [0141] 2nd sentence: For each migration step that has been launched, the migration step engine (160) can collect progress of each such migration step. Also, ¶ [0158])
“the events generated by worker nodes, control plane nodes, or both of the CO system”;
(Ovesea ¶ [0054] last sentence: the infrastructure used to migrate application data from an underlying database of 1st type (e.g. Oracle database, etc.) in a source system instance (or place of deployment (POD)) into a replacement database of different type (e.g. Sayonara-based database, etc.) in a target system instance. ¶ [0146] in Fig.1E a step engine (denoted StepEngine) on the source system instance (denoted POD A) may enqueue 1st XI message on the message queue of the target system instance (denoted POD B) to control executing migration step ( query, table insertion, to obtain HBase trust etc). A step controller (denoted as StepControllerHandler) may enqueue a second XI message on the message queue of the source system instance to return the result of controlling executing the migration step. In some embodiments, 2nd XI message may be specifically composed to allow successful dequeuing of the 2nd XI message from the message queue of the source system instance, by a step controller result handler (denoted as “StepControllerResultHandler”) 188 of Fig.3D. The result may be delivered to a step manager (denoted as “StepManager”) on the source system instance that is interested in such a result
Ovesea ¶ [0126] 1st sentence: controller 170 represents interface comprising a launch(…) method, which an engineer responsible for a to-be-migrated component can implement with specific program logic for a migration steps in the component to be invoked (directly or indirectly) for execution by migration scheduler (102) and/or migration orchestration engine (152). ¶ [0127] Both launch(…) and cancel(…) methods in controller (170) can be passed a connection and a step to launch or cancel. The connection is used to determine where the migration step is to run. If the step is to be run on the target system instance, a cross-instance (denoted as X) connection (e.g. to a remote database) is passed as the connection. Otherwise, a normal connection (e.g. an intra-instance connection, local connection, to a local database) is passed as the connection. ¶ [0143] In some embodiments, step controller handler 182 represents a class/object that may be used to send a message for controlling executing a migration step. In some embodiments, if the step controller handler (182) fails to control executing the migration step, retries may be performed for a specific number of times. If step controller handler (182) still fails, the step execution control action corresponding to the message can be reported as a failure. ¶ [0144] Since the migration step can be executed on the target system instance (whereas step controller handler (182) may be running on the source system instance), the step control handler (182) may perform checking out connections to free up resources (e.g. using Committed Dequeue Transaction Behavior etc.)
- “tracking, by the event processor, a rate of a plurality of the events in the stream received over a time period” (Ovesea ¶ [0056] 2nd-4th sentences: implement or specify a pre-migration step to be executed at a (time) offset before a selected time window (e.g. shutdown window, etc.), a migration step to be executed during selected time window, or post-migration step to be executed at a (time) offset after the selected time window. In some embodiments, the pre and post-migration steps share almost everything with the (e.g. normal) step, other than specifying the (time) offsets before or after the selected time window. A time offset may be any of: an absolute time value (e.g. system time, wall clock time), a relative time value (e.g from selected time window, from shutdown window, from another step or action etc.), a logical time value (e.g a sufficiently large incrementing integer, etc.), a time-dependent sequence number representing a logical time value, and so forth.
Ovesea ¶ [0057] 1st-3rd sentences: A migration step in migration steps (158) for each migration component in the migration components (156) can specify (e.g. using a static enum, etc.) whether this step is to be run on the source system instance, the target (or destination) system instance, or both. The migration step also specify a (time) offset (e.g., positive or negative, from the selected time window or the migration time window, a (signed) long value, etc.) at which the step is to be invoked/executed. The migration step engine (160) can be implemented to optimize executing the migration step, for example try to execute the migration step as close to (Window Start Time +Offset) as possible, where Window Start Time denotes the start time of the selected time window and Offset denotes the (time) offset as specified in the migration step
Ovesea ¶ [0062] 1st sentence: … migration step instance (164) implement program logic responsible for detecting [or tracking] whether the migration step has stalled in execution and deal with such situation appropriately (e.g setting timer in advance to be fired later for checking [or track] any subsequent stalling condition etc). ¶ [0089] 2nd-3rd sentences: Under techniques herein, migration components (156) process migration steps for transitions in parallel or any order that respects underlying dependency relationships among the migration steps and/or among the migration components. Different migration components take varying amounts of time to complete it respective migration steps. ¶ [0143] 2nd sentence: … if step controller handler (182) fails to control executing the migration step, retries may be performed for a specific number of times);
- “indicating, by the event processor, that each of the plurality of events is non-skippable”;
(Ovesea ¶ [0036] 5th sentence: … migration steps in the selected time window is prevented from being performed if some or all of pre-migration steps have not been completed successfully and have not been skipped by operators ¶ [0075] 4th-6th sentences: migration orchestration engine (152) can (only) transition from 1st to 2nd state immediately following: 1st state when the following conditions are met: #1. All to-be-migrated components are finished their respective processing (or their respective execution of migration steps with no non-skippable migration steps in failure) for the 1st state. #2. migration scheduler (102) allows transitioning from 1st to 2nd state to happen).
- “determining, by the event processor for a first event in the stream of events after the plurality of events, that the rate exceeds a threshold limit over the time period”;
(Ovesea ¶ [0057] 3rd sentence: …try to execute the migration step as close to (Window Start Time +Offset) as possible. ¶ [0060] 2nd sentence: to determine whether a migration step is due for execution, migration step finder (160) may take into account… any time delays [interpreted as over threshold limit], time related to generating progress reports including but not limited to completion, any previous failures of the migration step, and so forth. For example, at ¶ [0063] 3rd sentence: … querying, through migration step manager (166), the progresses of the migration steps to determine whether any depended migration steps have completed successfully or failed…. ¶ [0060] 2nd sentence noting such failure refers to the time delays. Also see ¶ [0081] 3rd sentence: noting an example where the selected time window (or scheduled downtime) occur before migration orchestration engine (152) complete its work (not able to execute all non-skippable migration steps of all to-be-migrated components, etc.) for the current state before the next state (e.g., Read Only state, On Target state, etc. ¶ [0137]-¶ [0138] start time< current time)
- “indicating, by the event processor, that the first event is skippable”
(Ovesea ¶ [0063] 3rd-5th sentences: Depending migration steps and/or migration step finder (162) may also be interested in querying, through migration step manager (166), the progresses of the migration steps in order to determine… whether any migration steps have been skipped.
¶ [0036] 7th sentence: If failed pre-migration steps are skipped, the subsequent or other migration steps continue to be enqueued/performed in the organization migration. ¶ [0054] 4th sentence non fatal errors in migration specific actions or steps and/or stalled operations/steps can be recovered or resolved by skipping or retrying these actions, operations or steps for a limited number of times)
* However *
Ovesea does not explicitly recite to clearly anticipate:
- “providing, by the event processor, each event in the stream of events indicated as being non-skippable to software for presentation to a user” as claimed.
* Nevertheless *
Viggósson in analogous art of container orchestration associated with event transition or progression teaches or suggests the missing indicat[ion] as required by:
- “providing, by the event processor, each event in the stream of events indicated as being non-skippable to software for presentation to a user”
(Viggósson ¶ [0065] 1st-3rd sentences: application system 101 can by implemented as a collection of containerized services. The containerized services can expose endpoints for responding to client requests (e.g., representational state transfer endpoints implemented in Java, or the like). Deployment and management of these services can be achieved using a container orchestration system (e.g. Kubernetes, Docker, Nomad, or the like). ¶ [0096] 3rd sentence: In the example depicted in Fig.3B, module 3 is associated with mandatory mission 325a. Completion of mandatory mission 325a may be necessary for progression from module 3 to module 4
¶ [0097] 4th sentence: selects available mandatory opportunities for display)
PNG
media_image1.png
624
636
media_image1.png
Greyscale
Viggósson Fig.3B in support of rejection arguments above
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modify modified Ovesea’s teachings, to have included Viggósson’s teachings, in order to have better containerized the services of Ovesea in a more effective manner that would have exposed endpoints for responding to client requests, e.g through representational state transfer endpoints implemented in Java, or the like (Viggósson ¶ [0065] 2nd sentence in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Ovesea ¶ [0040] in view of Viggósson ¶ [0040].
Alternatively, the claimed invention could have also been viewed as a mere combination of old elements in a similar container orchestration field of endeavor. In such combination each element would have merely performed same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Ovesea in view of Viggósson, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, and/or technologically feasible manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
Claims 2,9,16 Ovesea/Viggósson teaches all limitations in Claims 1,8,15 above. Furthermore,
Ovesea teaches or suggests:
- “wherein the event processor executes in a client device in communication with management software executing in a data center”
(Ovesea ¶ [0063] 1st-3rd sentences: migration step manager (166) implemented as program class /object to support or allow consumptions / manipulations of progresses of migration steps by interested program classes/objects (e.g processes, threads, objects, classes, interfaces, instantiations, implementers, methods) interested in such progresses. For example, migration user interface 136 interested in querying, through migration step manager (166), the progresses of the migration steps to present the progresses to operator then obtain user input from operator to any failures or issues in relation to these migration steps. Depending migration steps and/or migration step finder (162) may also be interested in querying, through migration step manager (166), the progresses of the migration steps to determine whether any depended migration steps have completed successfully or failed, or have been skipped by operators, and so forth.
Ovesea ¶ [0103] at startup of migration application servers (as a part of system services of system instance or datacenter) in organization migration framework (100), migration components (156) register themselves with migration orchestration engine (152) in a migration component registry with their respective well-defined names that can be used by the migration orchestration engine (152) to reference (e.g. uniquely, unambiguously, distinctly, etc.) the migration components (156).
Ovesea ¶ [0048] 2nd sentence: migration user device (118) may be operatively linked to, and communicate with, the migration scheduler (102) through one or more networks (e.g., 120, etc.) or via a local data connection. ¶ [0049] 2nd,4th sentences: For the requested organization migration, migration scheduler (102) identify a specific organization (e.g., 1st organization (114-1), etc.) to be migrated, a source target instance (e.g., system instance (110-1-1) in 1st datacenter (112-1), etc.), a target system instance (e.g., system instance (110-2-1) in the second datacenter (112-2), etc.), preparation time window (e.g., a start time, an end time, etc.), downtime window (e.g., a start time, an end time, etc.), migration configuration data, any commands and/or operational parameters set forth for the requested organization migration, etc…. Some or all of the foregoing may be obtained from the source and target system instances for the organization migration. ¶ [0101] 1st sentence: When a new organization migration is initiated, new migration configuration data is generated or supplied. Migration configuration data portion(s) for each migration component can be retrieved by the migration orchestration engine (102) from the new migration configuration data and passed along to each such migration component either one time through a (e.g. special, etc.) command/call or one but not all of the migration configuration data portion(s) each time when a command or call is made to each such migration component is made. Sending the migration configuration data portion(s) one time through a special command allows the migration component to handle and manage its respective migration configuration data portion(s) once passed along from the migration orchestration engine (102) ) “and”
- “wherein the management software receives the events and provides the stream of events to the client device” (Ovesea ¶ [0043] Each data center implement a set of system instances to host respective organizations that contract with the owner of the computing system such as a multi-tenant computing system to host their respective (e.g. organization-specific, organization-common) application data, to provide their (e.g. organization-specific, organization-common) application services to their respective users and/or customers. Examples of application data include, organization-specific application data, organization-common application data, application configuration data, application data, application metadata, application code, etc., specifically generated or configured for (e.g. organization-specific, organization-common, etc.) application services of an individual organization. For example, ¶ [0054] 2nd,5th sentences: the infrastructure provides a migration component for registering to-be-migrated components and/or migration steps for the components. The infrastructure can be used to collect (e.g. realtime, near-realtime, etc.) progresses of migration specific actions or steps in any given organization migration and present an up-to-date consistent view and/or a history of the state of organization migration. Ovesea ¶ [0048] migration user such as operator, administrator, authorized or designated user, can use a migration user device 118 to enter or send a request for an organization migration to a migration scheduler 102 through a migration user interface. The migration user device (118) may be operatively linked to, and communicate with, the migration scheduler (102) through one or more networks (e.g., 120, etc.) or via a local data connection. For example,
Ovesea ¶ [0049] 2nd ,4th sentences: For the requested organization migration, migration scheduler (102) identify a specific organization (e.g. 1st organization (114-1), etc.) to be migrated, a source target instance (e.g. system instance (110-1-1) in 1st datacenter (112-1), etc.), a target system instance (e.g. system instance (110-2-1) in the 2nd datacenter (112-2), etc.))
Claims 3,10,17 Ovesea/Viggósson teaches all limitations in claims 1,8,15 above. Furthermore,
Ovesea teaches or suggests: “wherein the event processor executes in a client device in communication with a control plane node of the CO system, and wherein the control plane node of the CO system provides the stream of events to the client device”.
(Ovesea Fig.1A, ¶ [0075] 1st-3rd sentences: a single point of scheduling control with respect to transitions between different states in the state machine may be implemented. In a non-limiting implementation example, the migration scheduler (102) can focus on when to move the application data and/or application services of the organization in the organization migration, while the migration orchestration engine (152) can focus on how to move application data and/or application services of an organization in an organization migration. All decisions on state transitions can be driven through the single point of scheduling control).
Claims 5,12,19 Ovesea/Viggósson teaches all limitations in claims 1,8,15 above.
Ovesea teaches or suggests:
- “determining, by the event processor for a second event in the stream of events after the first event, that the rate does not exceed the threshold limit over the time period” (Ovesea ¶ [0057] 3rd sentence: migration step engine (160) can be implemented to optimize executing the migration step, for example try to execute the migration step as close to (Window Start Time +Offset) as possible, where Window Start Time denotes the start time of the selected time window and Offset denotes the (time) offset as specified in the migration step. ¶ [0071] 2nd sentence: A transition as described herein refer to an action triggered by an event to leave the current state and to enter the next state following current state. ¶ [0073] 2nd sentence: state machine as implemented in migration orchestration engine (152) waits in the new state for all to-be-migrated components to finish their respective migration steps (or actions) for the new state before transitioning to the next state (immediately following the new state). ¶ [0081] 1st-2nd sentences: migration orchestration engine (152) can complete its work (e.g., by way of executing pre-migration steps of all to-be-migrated components, etc.) before the selected time window (or scheduled downtime). Once within the selected time window, the migration scheduler (102) can drive a transition to the next state (e.g., the Read Only state, the On Target state, etc.). ¶ [0082] 2nd sentence: migration orchestration engine (152) can poll migration scheduler (102) periodically until the current time of such polling is within the selected time window (or scheduled downtime). ¶ [0089] 3rd-5th sentences: Different migration components may take varying amounts of time to complete it respective migration steps. The migration orchestration engine (152) may remain in the current state and may not move into next state until all migration components are finished with migration steps for the current state. The migration orchestration engine (152) can query the migration components (156), or can be notified by each migration component in the migration components (156) (e.g., in real time, in near real time, at the next cron job, etc.) when each such migration component completes its respective transition work (or migration steps for the current state)
Ovesea does not explicitly recite:
- “indicating, by the event processor, that the second event is non-skippable” as claimed.
Viggósson however in analogous container orchestration associated with event transition or progression teaches or suggests:
- “indicating, by the event processor, that the second event is non-skippable”
(Viggósson Fig.3B above and ¶ [0065] 1st-3rd sentences: application system 101 can by implemented as a collection of containerized services. The containerized services can expose endpoints for responding to client requests (e.g., representational state transfer endpoints implemented in Java, or the like). Deployment and management of these services can be achieved using a container orchestration system (e.g. Kubernetes, Docker, Nomad, or the like). Viggósson ¶ [0096] 3rd sentence: In the example depicted in Fig.3B, module 3 is associated with mandatory mission 325a. Completion of mandatory [interpreted as non-skippable mission 325a may be necessary for progression from module 3 to module 4. ¶ [0097] 4th sentence: selects available mandatory opportunities for display).
Rationales to have modified/combined Ovesea / Viggósson are above and reincorporated.
Claims 6,13,20 Ovesea/Viggósson teaches all limitations in claims 1,8,15 above.
Ovesea teaches or suggests: “wherein the CO system comprises a plurality of clusters disposed over a plurality of sites” (Ovesea ¶ [0030] 1st sentence an organization migration moves (e.g, entire hosted, etc.) application data and application services of an organization from 1st point of deployment (POD) such as a source system instance in a datacenter to another POD such as target system instance in same or a different datacenter in the selected time window in which the application data and application services based at least in part on the application data may be temporarily unavailable (but may still provide read-only access in some embodiments) to users and/or customers of the organization. ¶ [0042] the computing system that hosts the organizations may comprise a plurality of datacenters such as 112-1,112-2,112-3, etc., which may be located at the same or different geographic locations such as the same or different continents, the same or different countries, the same or different states, the same or different regions, and so forth. ¶ [0045] in Fig.1A, each datacenter (112-1,112-2,112-3, etc.) may comprise a set of one or more system instances. A first datacenter 112-1 comprises first system instances 110-1-1, 110-1-2, etc.; a second datacenter 112-2 comprises second system instances 110-2-1,110-2-2, etc.; a third datacenter 112-3 comprises third system instances 110-3-1, 110-3-2, etc. ¶ [0046] Each system instance (110-1-1,110-1-2,110-2-1,110-2-2,110-3-1,110-3-2 etc.) in hosting computing system can host up to a maximum number of organizations such as 5,000 organizations, 10,000 organizations, 15,000+ organizations, etc. in Fig.1A, the system instance (110-1-1) in the datacenter (112-1) may host 1st organization 114-1 and 2nd organization 114-2, among others; the system instance (110-1-1) in datacenter (112-1) may host 3rd organization 114-3, among others),
“each of the clusters comprising some of the worker nodes” (Ovesea ¶ [0054] last sentence: the infrastructure used to migrate application data from an underlying database of 1st type (e.g. Oracle database, etc.) in a source system instance (or place of deployment (POD)) into a replacement database of different type (e.g. Sayonara-based database, etc.) in a target system instance. ¶ [0146] in Fig.1E, a step engine (denoted StepEngine) on the source system instance (denoted as POD A) may enqueue a 1st XI message on the message queue of the target system instance (denoted as POD B) to control executing a migration step (e.g query, table insertion, to obtain HBase trust etc.). A step controller (denoted as StepControllerHandler) may enqueue a second XI message on the message queue of the source system instance to return the result of controlling executing the migration step. In some embodiments, the second XI message may be specifically composed to allow successful dequeuing of the second XI message from the message queue of the source system instance, for example by a step controller result handler (denoted as “StepControllerResultHandler”) 188 of FIG. 3D. The result may be delivered to a step manager (denoted as “StepManager”) on the source system instance that is interested in such a result), “some of the control plane nodes” (Ovesea ¶ [0126] 1st sentence: controller 170 represents interface comprising a launch(…) method, which an engineer responsible for a to-be-migrated component can implement with specific program logic for a migration steps in the component to be invoked (directly or indirectly) for execution by migration scheduler (102) and/or migration orchestration engine (152). ¶ [0127] Both the launch(…) and cancel(…) methods in the controller (170) can be passed a connection and a step to launch or cancel. The connection is used to determine where the migration step is to run. If the step is to be run on the target system instance, a cross-instance (denoted as X) connection (e.g., to a remote database, etc.) is passed as the connection. Otherwise, a normal connection (e.g., an intra-instance connection, a local connection, to a local database, etc.) is passed as the connection. ¶ [0143] In some embodiments, a step controller handler 182 represents a class/object that may be used to send a message for controlling executing a migration step. In some embodiments, if the step controller handler (182) fails to control executing the migration step, retries may be performed for a specific number of times. If the step controller handler (182) still fails, the step execution control action corresponding to the message can be reported as a failure. ¶ [0144] Since the migration step can be executed on the target system instance (whereas the step controller handler (182) may be running on the source system instance), the step control handler (182) may perform checking out connections to free up resources (e.g. using Committed Dequeue Transaction Behavior etc.), or some of both”,
“ and wherein management software executing in a datacenter receives events generated by the plurality of clusters and provides the stream of events to the event processor”. (Ovesea ¶ [0060] 1st-3rd sentences: migration step finder (160) implemented (as program object, class object, etc.) with migration step engine to query migration data store (108) for migration steps due for execution. To determine whether a migration step is due for execution, migration step finder (160) take into account, or make provision for, any time delays, time related to generating progress reports including but not limited to completion, any previous failures of the migration step, and so forth. For a migration step with previous failures, the migration step finder (162) may allocate additional time for possible retries in case of encountering failures again.).
Ovesea ¶ [0061] migration step engine (160), or migration step finder (162), can create or instantiate a migration step instance 164 (or step executor) to execute a (e.g., single, each, etc.) migration step due for execution. Each migration step can be executed independently (in parallel, in any order, in a step execution order that respects or complies with dependency relationships between or among the migration steps) by a corresponding migration step executor (e.g. 164). The migration step instance (164) implements program logic responsible for logging (e.g., system logs, traces, etc.), alerting (e.g., a migration step, a component, etc.) on completion of a migration step's completion of execution, indicating whether the migration step is executed successfully or failed, logging of successes/errors in running or executing pre-/post-migrations steps, etc.
Ovesea ¶ [0063] 3rd sentence: Depending migration steps and/or migration step finder (162) may also be interested in querying, through migration step manager (166), the progresses of migration steps to determine whether any depended migration steps completed successfully or failed, or whether any migration steps have been skipped by operators, and so forth)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 4,11,18 are rejected under 35 U.S.C. 103 as being unpatentable over:
Ovesea/Viggósson as applied to claims 1,8,15 above, in further view of
Venkataraman et al, US 7911857 B1 hereinafter Venkataraman. As per,
Claims 4,11,18 Ovesea/Viggósson teaches all limitations in claims 1,8,15. Furthermore,
Ovesea teaches or suggests:
- “selecting, by the event processor, a second event in the stream of events after the first event”; (Ovesea ¶ [0071] 2nd sentence: A transition as described herein refer to an action triggered by an event to leave the current state and to enter the next state following current state. ¶ [0073] 2nd sentence: state machine as implemented in migration orchestration engine (152) waits in the new state for all to-be-migrated components to finish their respective migration steps (or actions) for the new state before transitioning to the next state (immediately following the new state)
- “determining, by the event processor, that a parameter of the second event matches criteria for a non-skippable event”; (Ovesea ¶ [0075] last sentence: The migration orchestration engine (152) can (e.g., only, etc.) transition from 1st to 2nd state immediately following the 1st state when the following conditions are met: # 1. All to-be-migrated components are finished their respective processing (or their respective execution of migration steps with no non-skippable migration steps in failure) for the first state. # 2. The migration scheduler (102) allows transitioning from the first state to the second state to happen) “and”
-[determining] “” (Ovesea ¶ [0081] 3rd sentence: selected time window (or scheduled downtime) can occur before migration orchestration engine (152) complete its work (e.g., not able to execute all non-skippable migration steps of all to-be-migrated components, etc.) for the current state before the next state (e.g., the Read Only state, the On Target state, etc.. ¶ [0036] 4th sentence migration steps in the selected time window is prevented from being performed if some or all of pre-migration steps have not been completed successfully and have not been skipped by the operators. Also ¶ [0037] 5th sentence: Even if a component or migration step may take a long time to execute, every other migration step that does not depend on the component or the migration step is not held from being executed.).
* However *
Ovesea/Viggósson does not explicitly recite “indicating” as in “indicating, by the event processor, that the second event is non-skippable despite the rate exceeding the threshold limit over the time period” as claimed.
* Nevertheless *
Venkataraman in analogous art of events’ management teaches or suggests:
- “indicating, by the event processor, that the second event is non-skippable despite the rate exceeding the threshold limit over the time period”
(Venkataraman column 8 lines 45-48: As shown [or indicated] in Fig.9, however, of the 16 samples for one iteration of groups 910 and 920, the sampling technique tends to cover the complete cycle of clk1x despite the delay illustrated by rectangles 915 and 925).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have further modified Ovesea/Viggósson to have further included Venkataraman’s teachings to have further employed a sampling range in the processing of Ovesea/Viggósson that would have maximized sampling coverage and avoid sampling overlap (Venkataraman column 8 lines 49-51 in view of MPEP 2143 C, D and/or G)
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar events’ management field of endeavor. In such combination each element would have merely performed same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Ovesea/Viggósson in view of Venkataraman, the to be combined elements would have fitted together like pieces of a puzzle in a logical complementary technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 7,14 are rejected under 35 U.S.C. 103 as being unpatentable over:
Ovesea/Viggósson as applied to claims 6 above, in further view of
Kumar et al, US 20240202017 A1 hereinafter Kumar. As per,
Claim 7. Ovesea/Viggósson teaches all the limitations in claim 6 above. Furthermore,
Ovesea teaches, “wherein the control plane nodes of the CO system comprise at least one of controllers” (Ovesea ¶ [0126]: controller 170), “schedulers” (Ovesea ¶ [0048] 1st sentence: scheduler 102), “and application programming interface (API) servers, wherein the CO system comprises a data center and a plurality of sites” (Ovesea ¶ [0030] 1st sentence: An organization migration moves (e.g, entire hosted, etc.) application data and application services of an organization from 1st point of deployment (POD) such as a source system instance in a datacenter to another POD such as target system instance in the same or a different datacenter in the selected time window in which the application data and application services based at least in part on the application data may be temporarily unavailable (but may still provide read-only access in some embodiments) to users and/or customers of the organization. ¶ [0042] In some embodiments, the computing system that hosts the organizations may comprise a plurality of datacenters such as 112-1, 112-2, 112-3, etc., which may be located at the same or different geographic locations such as the same or different continents, the same or different countries, the same or different states, the same or different regions, and so forth. ¶ [0045] in Fig.1A, each datacenter (112-1,112-2,112-3, etc.) may comprise a set of one or more system instances. A first datacenter 112-1 comprises first system instances 110-1-1, 110-1-2, etc.; a second datacenter 112-2 comprises second system instances 110-2-1, 110-2-2, etc.; a third datacenter 112-3 comprises third system instances 110-3-1, 110-3-2, etc. ¶ [0046] Each system instance (e.g., 110-1-1,110-1-2,110-2-1,110-2-2,110-3-1,110-3-2, etc.) in the hosting computing system can host up to a maximum number of organizations such as 5,000 organizations, 10,000 organizations, 15,000+ organizations, etc. As illustrated in Fig.1A, the system instance (110-1-1) in the datacenter (112-1) may host a first organization 114-1 and a second organization 114-2, among others; the system instance (110-1-1) in the datacenter (112-1) may host a third organization 114-3, among others), “the event processor disposed in the data center” (Ovesea ¶ [0103… the startup of migration application servers [or processor] (e.g., …as a part of system services of a system instance or a datacenter, etc.) in the organization migration framework (100), the migration components (156) register themselves with the migration orchestration engine (152) in a migration component registry with their respective well-defined names that can be used by the migration orchestration engine (152) to reference (e.g., uniquely, unambiguously, distinctly, etc.) the migration components (156) ),
* However *
Ovesea/Viggósson does not explicitly teach “the worker nodes disposed in the plurality of sites, the worker nodes executing containerized network functions (CNFs)” as claimed.
* Nevertheless *
Kumar in analogous art of container management teaches or suggests: “the worker nodes disposed in the plurality of sites, the worker nodes executing containerized network functions (CNFs)” (Kumar ¶ [0007] 1st sentence: containerized network function (CNF) may be deployed on a computing node (or worker node) of a cloud platform. ¶ [0027] Computing nodes 130 include devices configured to run containerized applications. Computing nodes 130 may include physical machines and/or virtual machines. In some situations, computing nodes 130 may be part of one or more clusters of computing nodes of a cloud infrastructure associated with container management system 120. ¶ [0014] Based on receiving the recommendation request, the orchestration system may obtain topology information regarding computing nodes that may be used to deploy the CNF and regarding available custom schedulers that may be used to deploy the CNF on the computing nodes. For example, the orchestration system may determine computing capabilities, memory capabilities, and/or network connectivity capabilities of the computing nodes. The orchestration system may analyze the cluster information and the topology information to identify one or more schedulers that are configured to deploy the CNF on one or more computing nodes with capabilities to support the requirements of the CNF).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have further modified Ovesea/Viggósson teachings to have included Kumar’s teachings in order to have provided the benefit of context witness to the scheduler of Ovesea/Viggósson (Kumar ¶ [0007]-¶ [0008] in view of MPEP 2143 C, D and/or G) while having avoided imbalances on the cluster of computing nodes due to recurring creation and/or deletion of CNFs as well as re-configuring of computing nodes in the cloud platform. (Kumar ¶ [0009] in view of MPEP 2143 C, D, and/or G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar container management field of endeavor. In such combination each element would have merely performed the same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Ovesea/Viggósson in further view of Kumar, the to be combined elements would have fitted together like pieces of a puzzle in a logical complementary, technologically feasible and/or economically desirable. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
Claim 14. Ovesea / Viggósson / Kumar teaches all the limitations of claim 7 above. Further,
Ovesea teaches or suggests: “wherein the control plane nodes of the CO system comprise at least one of controllers (Ovesea ¶ [0126]: controller 170), “schedulers” (Ovesea ¶ [0048] 1st sentence: scheduler 102), “and application programming interface (API) servers”
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
Following art is made of record and considered pertinent to Applicant’s disclosure:
- Sagkriotis S, Accelerating orchestration with in-network offloading, Doctoral dissertation, University of Glasgow, May 2023
- WO 2023047189 A1
¶ [0065] In some embodiments, application system 101 can by implemented as a collection of containerized services. The containerized services can expose endpoints for responding to client requests (e.g., representational state transfer endpoints implemented in Java, or the like). Deployment and management of these services can be achieved using a container orchestration system (e.g., Kubernetes, Docker, Nomad, or the like). In some embodiments, the containers can include, or be configured to connect to volumes that include, the data and instructions that specify the patient support platform (e.g., platform components 210).
¶ [0095] Each module in treatment path 301 can be associated with interactive opportunities. In some embodiments, the associated interactive opportunities can include one or more mandatory interactive opportunities. In some instances, satisfaction of a progression criterion for the module can require completion of the mandatory interactive opportunities associated with that module. In the example depicted in FIG. 3B, module 3 is associated with mandatory mission 325a. Completion of mandatory mission 325a may be necessary for progression from module 3 to module 4. In some instances, completion of such mandatory interactive opportunities can be sufficient for progression, while in other instances addition conditions may need to be satisfied. For example, a mandatory interactive opportunity may be a test designed to evaluate a patient’s knowledge of their condition. Progression to the next module may require completion of the test and a sufficiently high score on the test. As an additional example, progression to the next module may require completion of any mandatory interactive opportunities, and completion of a set number of other interactive opportunities. In some instances, progression may not require completion of specific mandatory missions. Instead, progression can require completion of a number of missions, expiration of a time period (e.g., each week the patient can progress to the next module), or satisfaction of another suitable condition.
- US 20230315522 A1 ¶ [0078] In a conventional orchestration environment, such as Kubernetes, a scheduler (e.g., kube-scheduler 128) is an important service running on the master control plane node 102 and is configured for distributing the workload or containers across multiple worker nodes 104, as well as tracking the utilization of the workload (e.g., one or more tasks) on nodes in a cluster 180, and putting the workload on resources that are available and which can accept the workload. However, the conventional kube-scheduler 128 can become a bottleneck and also, in some environments (e.g., Kubernetes) is limited as to how many worker nodes 104 to which it can distribute workload. Because of these limitations, the potential for a given environment (e.g., a master or control plane node 102 and plurality of worker nodes 104) to be able to provide features such as supercomputing and/or HPC functionality, can be limited
¶ [0109] 2nd-3rd sentences: If time expires when the node is ready to perform the task (answer at block 343 is YES), then processing similarly flows to block 325 to remove the task from the queue. If time to complete the task expires during task execution, but before task is complete (e.g. answer at block 353 is YES), then processing similarly flows to block 335 to remove the task from the queue).¶ [0110] Similarly, as will be appreciated, at any time while the receiving node is waiting to be ready to perform the task, or even while performing the task, independent of whether or not the time for completing the task has expired, the receiving node may receive notice that another node has completed the task first, as described above (e.g., as checked in block 330, before performing the task and block 354, while performing the task). If the receiving node is notified that another node has completed the task first (e.g., answer at block 330 is YES or answer at block 354 yes YES), then processing proceeds to block 335 to remove the task from the queue or stop instances of the task from running, as applicable
- US 20240419439 A1 ¶ [0047] More particularly, Figs.6A-E are examples of validation with respect to authentication and connectivity to target environment/platform. Fig.6A is sample code executable by automated software validation engine 510 to retrieve Kubernetes cluster credentials, together with a list of namespaces, for successful authentication. ¶ [0066] … result behavior of automated software validation engine 510 with respect to verifying the declaration of mandatory variables is shown in Figs.7K-L. More particularly, if all mandatory variables are declared, automated software validation engine 510 generates a success report such… in Fig.7K. However, if one or more mandatory variables are not declared, automated software validation engine 510 reports the failure with the details as shown in Fig.7L
- US 20170187838 A1 ¶ [0010] last sentence: The function module data store includes nonvolatile memory. In other features, performance of the transmitting and receiving is skipped in response to a time elapsed, since a prior function module request with the first function module identifier was transmitted, being less than a predetermined period of time
- US 20200293354 A1 ¶ [0014] last sentence: Forced migration needs a lot of tests for the dependency of this application on other system libraries, etc., consequently to greatly increase the difficulty in application of containerization. ¶ [0026] 1.4) Judging whether the target application ends operation or the operation time exceeds the preset time threshold, if the target application ends operation or the operation time exceeds the preset time threshold, jumping to the next step; ¶ [0016] 2nd sentence: The method includes skipping performance of the transmitting and receiving in response to a time elapsed, since a prior function module request with the first function module identifier was transmitted, being less than a predetermined period of time.
- US 20250190250 A1 Figs.4B, 5B and Mid-¶ [0071] The second duration may be, for example, a ratio of a data volume of the target data to a transmission bandwidth. It may be understood that, for a cluster that stores the target data, second duration corresponding to the cluster is 0, in other words, a data transmission process may be skipped
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OCTAVIAN ROTARU whose telephone number is (571)270-7950. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number (571)270-5396. 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.
/OCTAVIAN ROTARU/
Primary Examiner, Art Unit 3624 A
January 15th, 2026
1 Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);