Prosecution Insights
Last updated: July 17, 2026
Application No. 18/331,050

UNIFIED DATA STREAMING FRAMEWORK IN VIRTUALIZATION MANAGEMENT SOFTWARE

Final Rejection §103
Filed
Jun 07, 2023
Examiner
NGUYEN, BRANDON A
Art Unit
2195
Tech Center
2100 — Computer Architecture & Software
Assignee
Vmware LLC
OA Round
2 (Final)
Grant Probability
Favorable
3-4
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-55.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
11 currently pending
Career history
18
Total Applications
across all art units

Statute-Specific Performance

§103
97.4%
+57.4% vs TC avg
§102
2.6%
-37.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 0 resolved cases

Office Action

§103
Notice of Pre-AIA or AIA Status 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Arguments 2. Applicant’s arguments with respect to claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. 3. Applicant's request for reconsideration of the non-finality of the 101 rejection of the last Office action is persuasive and, therefore, the non-finality of that action is withdrawn. Claim Rejections - 35 USC § 103 4. 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. 5. Claims 1, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Baturin Pub. No. US 2022/0326886 A1 (hereafter Baturin) in view of Bartfai-Walcott et al. Pub No. US 2020/0050494 A1 (hereafter Bartfai-Walcott), MERTES et al. Pub. No. US 2022/0334725 A1 (hereafter MERTES), and Ding Pub. No. US 2023/0035929 A1. 6. With regard to claim 1, Baturin teaches A method of accessing object data ([0005] a method for processing a request for virtual resources) managed by virtual infrastructure (VI) services … a cluster of hosts in a data center and a virtualization layer executing in the cluster of hosts ([0005] a distributing computing cluster comprising a plurality of edge devices.{Cluster of hosts} [0046] The edge device 500 can be thought of as a cloud-integrated service that extends some or all of conventional cloud capabilities to locations that may not be accessible by or have access to cloud data centers.{Data center}[0034] In some examples, the edge device 100 may include containerization engine 102 (e.g., Docker, Kubernetes, etc.) configured to implement one or more containers (e.g., corresponding to container(s) 104A, 104B, 104C, to 104N, collectively referred to as “container(s) 104”). A containerization engine (e.g., the containerization engine 102) may be container-orchestration system for automating computer application deployment, scaling, and management. In some embodiments, the containerization engine {Virtualization layer} may be configured to provide OS-level virtualization to deliver software in packages called containers. These containers can be isolated from one another and utilize respective software, libraries, and configuration files, and can communicate with each other through well-defined channels. In some embodiments, service(s) 104 may include any suitable number of services (e.g., one or more). These services may implement at least some portion of centralized cloud capabilities. Each service may be stand-alone or operate as a distributed cluster. The edge device 100 may further include a hypervisor 106 configured to implement one or more virtual machines (e.g., virtual machines 108A, 108B, 108C, to 108N, collectively referred to as “virtual machine(s) 108” or “VMs 108”); the method comprising: receiving, from a client at a unified data service … one or more requests for accessing the object data, the one or more requests comprising a first request for reading the object data; planning, in response to the one or more requests, one or more operations to access the object data that targets a first VI service of the VI services, the one or more operations comprising a fetch operation in response to the first request; ([0109] At 1204, a request for virtual resources of the distributed computing cluster may be received (e.g., by the storage control plane 802 of FIG. 8). The request may be received from a user device (e.g., user device 810 of FIG. 8) and directed to the first edge device.{Unified Data Service} [0110] At 1206, the first edge device may determine that the first edge device is operating as a computing node different from the head node of the distributed computing cluster. By way of example, the first edge device may be node 2 of FIG. 2, which initially may be a different computing node than the one currently acting as the head node (e.g., node 1 of FIG. 9, for example). [0111] At 1208, the first edge device may determine that a second edge device {First VI Service} (e.g., node 1 of FIG. 900) of the distributed computing cluster has been elected as the head node of the distributed computing cluster. In some embodiments, monitor 910 of the first edge device may be configured to contact a state data store (e.g., state storage 816) which may be configured to store and provide by request a current head node of the computing cluster. [0112] At 1210, with the current head node identified, the first edge node may forward the request to the second edge device. In some embodiments, forwarding the request to the second edge device causes the request to be processed by the distributed computing cluster.); and forwarding, from the unified data service to the client, a result of accessing the object data …” ([0114] In response to identifying that the majority of the distributed computing cluster have responded, the first edge device may transmit an indication that the read request was successful. Examiner notes that edge devices contain services (via containers) and can be considered the service as a whole (e.g. each edge device being the service that it contains), therefore the first edge device of Baturin above could be configured to be the unified data service, (a leader device that may connect to the other edge devices) and the second edge device is configured to be the first VI service, and subsequent edge devices are the rest of the VI services. Baturin may not explicitly teach the first edge device {Unified data service} executing within a virtualization management software. Baturin does teach a cluster manager to manage any suitable number of computing clusters [0065]. Bartfai-Walcott teaches as evidence, an edge device executing within a management system such that it teaches a virtualization management software that manages a cluster of hosts ([0236] The software management system 2300 may incorporate the elements described herein to provide a distributed service framework system using a common services interface. The software management system may include edge devices 2302, such as IoT resources 2304 and local cloud services 2306, among others. The software management system 2300 may also include cloud-based devices 2308, such as a service provider cloud 2310 that may include other possible services, such as software as a service (SaaS) 2312, platform as a service (PaaS) 2314, and infrastructure as a service (IaaS) 2316. Other services that may be offered by the cloud provider include direct cloud services 2318, which may be run in virtual machines in the cloud, and brokered cloud services 2320, which may be run in clouds owned by other providers 2322. [0237] In addition to the distributed services framework 2000, the software management system 2300 may include tools for the implementation of management functions. These may include analytics and micro-services 2324, and management, manageability, and control functions (MMC) 2326. The MMC functions 2326 may include asset services 2328, for example, as described with respect to the common services interface 1900 of FIG. 19. The MMC 2326 may also include telemetry services 2330 for tracking the health, reputation, and metadata for devices. Also see Fig. 23). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to show the edge device of Baturin executes within a virtualization management software as evidence of Bartfai-Walcott. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of scalability in the unified data framework, and the efficiency of managing and executing data requests of a client. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied said teachings to achieve expected results. The combination of Baturin and Bartfai-Walcott does not explicitly teach invoking, in response to the one or more operations, an application programming interface (API) of the first VI service to access the object data, the API being exposed by a unified data library integrated with the first VI service. Baturin does teach an API proxy integrated in an edge device [0039]. MERTES teaches as evidence that the second edge device of Baturin executes a plurality of APIs to retrieve data from storage such that invoking, in response to the one or more operations, an application programming interface (API) of the first VI service to access the object data, the API being exposed by a unified data library integrated with the first VI service (Fig. 23 Edge Device 2302, [0513] In some implementations, the storage service agents 2322, 2324, 2326 are configured to invoke storage system APIs exposed by the storage operating environment 2310, a storage system API server, or some other storage system component. For example, a storage controller may include a device API server 2316 that exposes a library of device APIs 2318 for the storage system. When a control message encapsulating a storage agent API request is routed by the EMS client 2320 to one of the storage service agents 2322, 2324, 2326, that storage service agent fulfills the request by invoking one or more device APIs 2318 exposed by the device API server 2316. As previously discussed, each storage service agent 2322, 2324, 2326 is tailored to perform a specific set of functions offered by a corresponding component of the cloud-based storage service 2304. For example, the update agent 2322 is tailored to performing software updates (e.g., updates to the storage operating environment) driven by the software update microservice 2340, the storage orchestration agent 2324 is tailored to performing storage provisioning operations driven by the storage orchestration microservice 2342, the DPaaS agent 2326 is tailored to performing data protection operations driven by the DPaaS microservice 2344. Accordingly, each storage service agent 2322, 2324, 2326 is provided with a set of permissions to access only the subset of device APIs 2318 necessary for carrying out its tailored operations. For example, the storage orchestration agent 2324 may have API permissions to provision a volume but not define replication targets, whereas the DPaaS agent 2326 may have API permissions to configure replication but not provision a volume. Similarly, the update agent 2322 may have permissions to update the storage operating environment 2310 but not to provision a volume. [0526] The storage service agents 2405, 2407 interact with storage system APIs 2421, 2423, 2425, 2427 {Unified Data Library} to carry out operations on the storage system that are directed by the control plane of the cloud-based storage service 2403. Examples of storage system APIs can include APIs to create a new volume, migrate a volume, configure a host connection, set a snapshotting frequency, define a replication target, and so on. Readers will appreciate that a variety of APIs are provided by a storage system. The set of APIs exposed by a storage system may be referred to here as a library of APIs. As discussed above, in some implementations the edge device 2401 may be a component of enterprise storage system. In such implementations, as depicted in FIG. 24, the library of storage system APIs is provided on the edge device 2401 itself. In other implementations, the edge device 2401 may be a collocated server coupled to the enterprise storage system via a network connection. In additional implementations, the edge device 2401 may be a virtual device. In some examples, the storage system APIs 2421, 2423, 2425, 2427 are accessed by the storage service agents 2405, 2407 through an API server. Also see [0530-0543] and figures 23-29 for more details). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply the teachings of MERTES with the combination of Baturin and Bartfai-Walcott to teach as evidence, that the second edge device of Baturin utilizes an API library via API proxy to access storage data and expand API functionality to accommodate for a plurality of services. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of scalability and flexibility. The combination does not explicitly teach comparing snapshots to determine data drift. Ding teaches comparing changed block tracking (CBT) data associated with data changes after a snapshot such that it teaches the limitation “the result comprising a snapshot of the object data associated with a first checkpoint obtained through the fetch operation; and causing the client to determine drift of a data object state from a desired state based on comparison of the snapshot of the object data associated with the first checkpoint with one or more other snapshot of the object data associated with one or more other checkpoints different from the first checkpoint. ([0074-0080] teaches a processor identifying a first snapshot associated with a first point in time version, the snapshot being fetched by an API as taught in [0028], and then the processor accesses changed block tracking (CBT) data associated with data changes in the VM by a second point in time such that they are snapshots associated with a point in time different from the first, and then determine data changes associated with the VM along with subsequent actions such that it may be computing “drift data”).” It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply the teachings of Ding with the combination of Baturin, Bartfai-Walcott, and MERTES to teach as evidence, that a requested snapshot may be used to compare to other snapshots at different points in time to determine data change. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing inbound data ingestion and outbound network traffic improving system performance (Ding [0078]). Together, Ding, in combination with Baturin, Bartfai-Walcott, and MERTES teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied said teachings to achieve expected results. 7. Claim 8 has similar limitations to claim 1 and is rejected for similar reasons. Claim 8 is directed towards “A non-transitory computer readable medium (Baturin [0004] non-transitory computer-readable medium)”. 8. Claim 15 has similar limitations to claim 1 and is rejected for similar reasons. Claim 15 is directed towards “A computing system (Baturin [0004] systems), a client in communication with the virtualization management software (Baturin [0038] example architecture 200 for connecting the edge device described herein (e.g., edge device 100 from FIG. 1) to a computing device 202 (e.g., a user computing device). The computing device 202 can be any type of computing device including, but not limited to, a laptop computer, a desktop computer, or the like)”. 9. Regarding claims 2-7, 9-14, and 16-20, they depend on claims 1, 8, and 15 respectively and are rejected for the same reasons previously brought forth in the non-final rejection. Conclusion 10. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON A NGUYEN whose telephone number is (571)272-6074. The examiner can normally be reached Mon-Fri (10am-6pm). Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /BRANDON NGUYEN/Examiner, Art Unit 2195 /Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Read full office action

Prosecution Timeline

Jun 07, 2023
Application Filed
Nov 21, 2025
Non-Final Rejection (signed) — §103
Jan 08, 2026
Non-Final Rejection mailed — §103
Apr 08, 2026
Response Filed
Jun 11, 2026
Final Rejection mailed — §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
Grant Probability
Moderate
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month