Prosecution Insights
Last updated: July 05, 2026
Application No. 18/583,434

BIDIRECTIONAL PLATFORM FOR PROVIDING MULTI-TENANT SERVICES TO PRIVATE CUSTOMER ENDPOINTS

Non-Final OA §102§103
Filed
Feb 21, 2024
Examiner
NGUYEN, QUANG N
Art Unit
2441
Tech Center
2400 — Computer Networks
Assignee
Microsoft Technology Licensing, LLC
OA Round
1 (Non-Final)
88%
Grant Probability
Favorable
1-2
OA Rounds
2m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 88% — above average
88%
Career Allowance Rate
452 granted / 515 resolved
+29.8% vs TC avg
Strong +16% interview lift
Without
With
+16.2%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
25 currently pending
Career history
548
Total Applications
across all art units

Statute-Specific Performance

§101
3.4%
-36.6% vs TC avg
§103
65.7%
+25.7% vs TC avg
§102
18.4%
-21.6% vs TC avg
§112
1.5%
-38.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 515 resolved cases

Office Action

§102 §103
Detailed Action 1. This Office Action is responsive to the Response to Election/Restriction filed 03/19/2026. Claims 9-15 have been withdrawn (please cancel the withdrawn claims 9-15). Claims 1-8 and 16-20 have been elected and are presented for examination. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Information Disclosure Statement 2. The information disclosure statement (IDS) submitted on 03/19/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 102 3. 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. 4. Claims 1, 3 and 16-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kavanagh et al. (US 2014/0006638 A1), hereinafter “Kavanagh”. 5. As to claim 1, Kavanagh teaches a cloud compute platform comprising: platform routing components configured to: receive a data packet having a data packet header identifying a first IPv6 address as a destination for the data packet ([0085]: the hypervisor 20 of the server 12B hosting VM2 associated with tenant T2 receives the IPv6 packet), the first IPv6 address embedding a first IPv4 address and a virtual network (VNet) identifier uniquely identifying a VNet of a cloud compute platform (TABLE 1, [0073-0075] and [0077]: the IPv6 destination address is [P2 I IPv4 destination address], wherein prefix P2 is a unique prefix which identifies tenant T2 associated with different VMs); and based on extraction of the VNet identifier and the first IPv4 address from the first IPv6 address, route the data packet to a host node within the cloud compute platform that hosts a first virtual machine (VM) reachable via the first IPv4 address that is within the VNet identified by the VNet identifier ([0086]: the hypervisor 20 extracts the prefix P2 from the IPv6 destination address, looks the extracted prefix up in the mapping table to determine the tenant corresponding to the prefix, and determines the virtual machine associated with the identified tenant. The hypervisor 20 extracts the IPv4 destination address, the IPv4 source address and the payload of the IPv4 packet, then assembles the extracted payload with the header of the IPv4 packet and routes it to VM2/T2). 6. As to claim 3, Kavanagh teaches the cloud compute platform of claim 1, wherein the platform routing components include: a software-defined networking (SDN) appliance configured to: receive the data packet as part of an encapsulated data packet, the encapsulated data packet having an outer header and an encapsulated portion that includes the data packet header identifying the first IPv6 address as the destination of the data packet; extract, from the first IPv6 address, the VNet identifier and the first IPv4 address; use the VNet identifier and the first IPv4 address to retrieve, from a stored mapping, an internet protocol (IP) address of a host node of the cloud compute platform that hosts a virtual machine associated with the first IPv4 address; update the outer header of the data packet to include the IP address of the host node as a new destination for the data packet; and transmit the data packet with the new destination in the outer header to the host node (Fig. 4, [0042] and [0085-0086]: the hypervisor 20 receives the IPv6 data packet, extracts the prefix (P2) from the IPv6 destination address, looks the extracted prefix P2 up in the mapping table to determine the tenant (T2) corresponding to the prefix P2, and determines the virtual machine (VM2) associated with the identified tenant. The hypervisor 20 extracts the IPv4 source and destination addresses from the IPv6 source and destination addresses and extracts the payload of the IPv4 packet from the payload of the IPv6 packet. Then, the hypervisor 20 assembles the IPv4 packet and routes it to (host) VN2/T2). 7. As to claims 16-17, claims 16-17 are corresponding tangible computer-readable storage media claims that recite similar limitations as of cloud compute platform claims 1, 3 and do not contain any additional limitations with respect to novelty and/or inventive steps; therefore, they are rejected under the same rationale. Claim Rejections - 35 USC § 103 8. 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. 9. Claims 2, 4-8 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kavanagh, in view of WING et al. (US 2019/0319918 A1). 10. As to claim 2, Kavanagh teaches the cloud compute platform of claim 1, wherein the data packet header further identifies a second IPv6 address as a source for the data packet (FIG. 4 and [0047]: the header 122 comprises the IPv6 source address), providing for an update to packet header information that designates the first IPv6 address as a source and the second IPv6 address as a destination (FIG. 4 and [0077]: it creates the IPv6 source address by concatenating the prefix P2 with the extracted IPv4 source address and in the same manner, the IPv6 destination address is created), but does not explicitly teach “assign the data packet to a select port identifier on the first VM assigned to the first IPv4 address extracted from the first Ipv6 address; and based on assignment of the select port identifier, define an address translation rule that is conditionally applied to data packets arriving from the first IPv4 address and from the select port identifier”. In an analogous art, WING discloses “assign the data packet to a select port identifier on the first VM assigned to the first IPv4 address extracted from the first Ipv6 address; and based on assignment of the select port identifier, define an address translation rule that is conditionally applied to data packets arriving from the first IPv4 address and from the select port identifier” (FIG. 3B-3C, 4B-4C, [0050]: A NAT address translation rule may provide instructions to replace, in a header of a detected packet, a destination IP address with an IP address of a client application, and to replace, in the header, a destination port with an identifier of a redirect port implemented in the particular virtual machine. Examples of the NAT translation rules are described with references to FIG. 3B-3C and FIG. 4B-4C; FIG. 3B and [0077]: Rule 360 provides that, in a header of data packet 304A, a destination IP address 306A of “127.31.42.79” is to be replaced with “172.31.42.79”, which corresponds to the IP address of VM1 Windows client. Rule 360 also provides that, in the header of data packet 304A, a destination port identifier 308A of “80” is to be replace with “8090”, which corresponds to the identifier of the redirect port implemented in VM1). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kavanagh and WING to achieve the claimed invention to facilitate redirecting communications exchanged between the client application and server application to be encrypted when exchanged between the corresponding virtual machines (WING, [0009]). 11. As to claim 4, Kavanagh teaches the cloud compute platform of claim 3, further comprising: a decapsulator configured to generate a modified data packet by decapsulating the encapsulated data packet and; a stateful translator configured to: read the first IPv6 address and a second IPv6 address from a header of the modified data packet; extract the first IPv4 address from the first IPv6 address (Fig. 4, [0042] and [0085-0086]: the hypervisor 20 receives the IPv6 data packet, extracts the prefix (P2) from the IPv6 destination address, looks the extracted prefix P2 up in the mapping table to determine the tenant (T2) corresponding to the prefix P2, and determines the virtual machine (VM2) associated with the identified tenant. The hypervisor 20 extracts the IPv4 source and destination addresses from the IPv6 source and destination addresses), but does not explicitly teach “select a first port identifier of the first VM to assign to the modified data packet; store a translation rule mapping the first port identifier and the first IPv4 address to a pair of addresses including the first IPv6 address and the second IPv6 address; and create updated header information specifying a packet destination that identifies both the first IPv4 address and the first port identifier; and transmit the modified data packet with the updated header information to the first VM assigned to the first IPv4 address”. In an analogous art, WING discloses that Security controller 103 may be a software application configured to communicate with virtual machines hosted on hosts 106A-C, and configured to provide NAT address translation rules to the virtual machines. The NAT address translation rules may be configured on security controller 103 by a system administrator or by SDN manager 102A. A NAT address translation rule may provide instructions to replace, in a header of a detected packet, a destination IP address with an IP address of a client application, and to replace, in the header, a destination port with an identifier of a redirect port implemented in the particular virtual machine. Examples of the NAT translation rules are described with references to FIG. 3B-3C and FIG. 4B-4C (FIG. 3B-3C, 4B-4C, [0049-0050]). WING also discloses that [address translation] Rule 360 provides that, in a header of data packet 304A, a destination IP address 306A of “127.31.42.79” is to be replaced with “172.31.42.79”, which corresponds to the IP address of VM1 Windows client. Rule 360 also provides that, in the header of data packet 304A, a destination port identifier 308A of “80” is to be replace with “8090”, which corresponds to the identifier of the redirect port implemented in VM1 (FIG. 3B and [0077]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kavanagh and WING to achieve the claimed invention to facilitate redirecting communications exchanged between the client application and server application to be encrypted when exchanged between the corresponding virtual machines (WING, [0009]). 12. As to claim 5, Kavanagh-WING teaches the cloud compute platform of claim 4, wherein the stateful translator resides on the host node of the first VM assigned to the first IPv4 address (Kavanagh: Hypervisor 20 of FIG. 2; WING, [0014]: NAT agents 303A and 305B in FIG. 3A and NAT agents 304A and 303B in FIG. 4A). 13. As to claim 6, Kavanagh-WING teaches the cloud compute platform of claim 4, wherein the header of the modified data packet further identifies a second IPv6 address as a source address and the stateful translator is further configured to: replace the source address with a platform address used to communicate with components of the cloud compute platform (WING, FIG. 4A-C and [0090]: Rule 460 describes that, in a header of data packet 404B, a source IP address of “172.31.42.79” is to be replaced with a loopback IP address 415B of “127.0.0.2” and a destination IP address 406B “127.31.36.107” is to be replaced with a loopback IP address 416B of “127.0.0.1”), wherein packets received at the platform address are subject to evaluation against a set of stored translation rules including the translation rule (WING, FIG. 4A-C and [0093-0094]: Rule 470 describes that, in a header of data packet 410A, a source IP address of “127.31.36.107” is to be replaced with the source IP address of “172.31.42.79” of VM3 Windows server, and a destination IP address “127.31.36.107” is to be replaced with a destination IP address of “127.31.36.107 of VM1 Windows client.”) 14. As to claim 7, Kavanagh-WING teaches the cloud compute platform of claim 4, wherein the second IPv6 address is assigned to virtual machine associated with a multi-tenant service (Kavanagh, [0006]: data center having tenants used for cloud computing forms an IPv6 network) and the first IPv4 address is a private IP address of a customer that subscribes to the multi-tenant service (Kavanagh, [0012-0013]: generating the IPv4 packet by assembling the generated header with the generated payload and routing the generate IPv4 packet to the determined virtual machine associated with the tenant). 15. As to claim 8, Kavanagh-WING teaches the cloud compute platform of claim 5, wherein the platform routing components are further configured to: receive a return data packet transmitted by the first VM, the return data packet having a packet header identifying the first IPv4 address and the first port identifier as a source of the return data packet; identify a stored translation rule conditionally applied to traffic originating at the first IPv4 address and the first port identifier, the stored translation rule defining the second IPv6 address as the source of the return data packet and the first IPv6 address as the destination for the return data packet; creating an updated header for the return data packet, the updated header identifying the second IPv6 address as a destination and the first IPv6 address as a source; and transmit the return data packet with the updated header to the second IPv6 address (WING, FIG. 4A-C, [0086-0095]: describing Example Translation of a (Response/Return Data) Packet Sent from a Server Application to a Client Application). 16. As to claims 18-20, claims 18-20 are corresponding tangible computer-readable storage media claims that recite similar limitations as of cloud compute platform claims 4-8 and do not contain any additional limitations with respect to novelty and/or inventive steps; therefore, they are rejected under the same rationale. 17. Further references of interest are cited on Form PTO-892, which is an attachment to this Office Action. 18. A shortened statutory period for reply to this action is set to expire THREE (3) months from the mailing date of this communication. See 37 CFR 1.134. Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUANG N NGUYEN whose telephone number is (571) 272-3886. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KAMAL B. DIVECHA, can be reached at (571) 272-5863. The fax phone number for the organization is (571) 273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /QUANG N NGUYEN/ Primary Examiner, Art Unit 2441
Read full office action

Prosecution Timeline

Feb 21, 2024
Application Filed
Apr 15, 2026
Non-Final Rejection mailed — §102, §103
Jun 22, 2026
Interview Requested
Jul 01, 2026
Applicant Interview (Telephonic)
Jul 01, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598240
USER INTERACTION AND TASK MANAGEMENT USING MULTIPLE DEVICES
2y 3m to grant Granted Apr 07, 2026
Patent 12592881
IMPROVED SCALING EFFICIENCY FOR INTERNAL TRANSPORT SERVICES IN DISTRIBUTED NETWORK ELEMENTS
2y 2m to grant Granted Mar 31, 2026
Patent 12587893
METHODS AND SYSTEMS FOR OPTIMIZING SIGNALING WITH TRAFFIC DETECTION FUNCTION
1y 9m to grant Granted Mar 24, 2026
Patent 12580990
CONNECTIVITY FRAMEWORK HAVING UNIFIED STACK AND MESSAGING PROTOCOL FOR EMBEDDED SECURE CONNECTIVITY
2y 0m to grant Granted Mar 17, 2026
Patent 12574447
SYSTEM AND METHOD FOR TENANT SPECIFIC DATA MODELING FOR FIELD VERSIONING AND DOMAIN INTERCONNECTION
1y 7m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

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

1-2
Expected OA Rounds
88%
Grant Probability
99%
With Interview (+16.2%)
2y 6m (~2m remaining)
Median Time to Grant
Low
PTA Risk
Based on 515 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