DETAILED ACTION
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 .
Response to Arguments
Regarding the rejection of claim(s) 1-20 on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim(s) 1-20, of US application 17/375,748 now US Patent 11,888,736 B2 and US application 18/545,931 now US Patent 12,170,614 B2, applicant did not present arguments but asked for the rejection to be held in abeyance. Therefore, the rejection is maintained.
Applicant’s arguments, see pages 10-14, filed 06/22/2026, with respect to the prior art rejection of claim(s) 1-20 under 35 U.S.C. 103 have been fully considered and are persuasive. The prior art rejection of 1-20 has been withdrawn.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In 15re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claim(s) 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim(s) 1-20, of US application 17/375,748 now US Patent 11,888,736 B2 and US application 18/545,931 now US Patent 12,170,614 B2.
Regarding independent claim(s) 1,8 and 15 of the instant application ‘015, the claims recite “storing a first configuration associated with a first virtual network (VN) instance of a border node that is disposed between an enterprise network domain and an external network domain, the first VN instance facilitating communications with a first service in the external network domain, the first configuration indicating a second service where traffic is to be sent after the traffic is received from the first service, the first service and the second service being part of a service chain; storing a second configuration associated with a second VN instance of the border node, the second VN instance facilitating communications with the second service of the service chain in the external network domain; receiving, by the border node via the first virtual network (VN) instance disposed between an enterprise network domain and an external network domain and from the first service, a packet that is decapsulated such that a header associated with the enterprise network domain is missing from the packet; based at least in part on the header missing from the packet, sending, by the border node and to a control plane device associated with the enterprise network domain, a request associated with determining a next hop for the packet; based at least in part on receiving, at the border node and from the control plane device, an indication that a second VN instance is to be used as the next hop to send the packet to the second service, forwarding the packet from the first VN instance to the second VN instance; and based at least in part on the second configuration indicating the second service being a last service of the service chain, forwarding, by the border node, the packet to a destination device subsequent to receiving the packet back from the second service”, this limitations are disclosed by the limitation of independent claim(s) 1,8 and 15 of US application 17/375,748 now US Patent 11,888,736 B2 and claim(s) 1,8 and 15 of US application 18/545,931 now US Patent 12,170,614 B2 which recites “storing a first configuration associated with a first virtual routing and forwarding (VRF) instance of a border node that is disposed between an enterprise network domain and an external network domain, the first VRF instance facilitating communications with a first service that is disposed in the external network domain, the first configuration indicating at least an identifier and a type associated with a second service where traffic is to be sent after the traffic is received from the first service, the first service and the second service being part of a service chain; storing a second configuration associated with a second VRF instance of the border node, the second VRF instance facilitating communications with the second service of the service chain disposed in the external network domain, the second configuration indicating at least that the second service is a last service of the service chain; receiving, by the border node via the first VRF instance and from the first service, a packet previously sent to the first service by the border node using the first VRF instance, wherein the packet received from the first service is decapsulated such that a header associated with the enterprise network domain is missing from the packet, the header indicative of a next hop for the packet; based at least in part on the header missing from the packet, sending, by the border node and to a control plane device associated with the enterprise network domain, a request associated with determining the next hop, the request including the identifier and the type associated with the second service of the service chain; based at least in part on receiving, at the border node and from the control plane device, an indication that the second VRF instance is to be used as the next hop to send the packet to the second service, forwarding the packet from the first VRF instance to the second VRF instance; determining, by the border node and based at least in part on the second configuration, that the second service is the last service of the service chain; and based at least in part on the second service being the last service of the service chain, forwarding, by the border node, the packet to a destination device subsequent to receiving the packet back from the second service”.
Although the conflicting claims are not identical, they are not patentably distinct from each other because the functions of the patent non-transitory claims anticipate the device (media player) claims in the instant application. They correspond as follows:
Instant App. 18/938.015
App. 17/375,748 now US 11,888,736 B2
App. 18/545,931 now US 12,170,614 B2 (Parent App.)
A method comprising: (1,8 & 15)
storing a first configuration associated with a first virtual network (VN) instance of a border node that is disposed between an enterprise network domain and an external network domain, the first VN instance facilitating communications with a first service in the external network domain, the first configuration indicating a second service where traffic is to be sent after the traffic is received from the first service, the first service and the second service being part of a service chain; storing a second configuration associated with a second VN instance of the border node, the second VN instance facilitating communications with the second service of the service chain in the external network domain; receiving, by the border node via the first virtual network (VN) instance disposed between an enterprise network domain and an external network domain and from the first service, a packet that is decapsulated such that a header associated with the enterprise network domain is missing from the packet; based at least in part on the header missing from the packet, sending, by the border node and to a control plane device associated with the enterprise network domain, a request associated with determining a next hop for the packet; based at least in part on receiving, at the border node and from the control plane device, an indication that a second VN instance is to be used as the next hop to send the packet to the second service, forwarding the packet from the first VN instance to the second VN instance; and based at least in part on the second configuration indicating the second service being a last service of the service chain, forwarding, by the border node, the packet to a destination device subsequent to receiving the packet back from the second service
Claim(s) (1,8,15)
A method comprising: storing a first configuration associated with a first virtual routing and forwarding (VRF) instance of a border node that is disposed between an enterprise network domain and an external network domain,
the first VRF instance facilitating communications with a first service of a service chain sequence disposed in the external network domain,
the first configuration indicating at least an identifier and a type associated with a second service of the service chain sequence
where traffic is to be sent after the traffic is received from the first service;
storing a second configuration associated with a second VRF instance of the border node or another border node disposed between the enterprise network domain and another external network domain, the second VRF instance facilitating communications with the second service of the service chain sequence disposed in the other external network domain, the second configuration indicating at least that the second service is a last service of the service chain sequence;
receiving, by the border node via the first VRF instance and from the first service, a packet previously sent to the first service by the border node using the first VRF instance, wherein the packet received from the first service is decapsulated such that a header associated with the enterprise network domain is missing from the packet, the header indicative of a next hop for the packet;
based at least in part on the header indicative of the next hop missing from the packet,
sending, by the border node, a map request to a control plane associated with the enterprise network domain, the map request including the identifier and the type associated with the second service of the service chain sequence;
receiving, at the border node and from the control plane, a map reply indicating that the second VRF instance is to be used to send the packet to the second service;
sending, by the border node, the packet to the second VRF instance based at least in part on the map reply;
receiving the packet at the second VRF instance; sending, by the border node or the other border node and using the second VRF instance, the packet to the second service; receiving, at the border node or the other border node and via the second VRF instance, the packet from the second service;
determining, by the border node or the other border node and based at least in part on the second configuration, that the second service was the last service of the service chain sequence; and
based at least in part on the second service being the last service of the service chain sequence, forwarding, by the border node or the other border node, the packet to a destination device.
Claim(s) (1,8,15)
A method comprising: storing a first configuration associated with a first virtual routing and forwarding (VRF) instance of a border node that is disposed between an enterprise network domain and
an external network domain,
the first VRF instance facilitating communications with a first service that is disposed in the external network domain,
the first configuration indicating at least an identifier and a type associated with a second service
where traffic is to be sent after the traffic is received from the first service,
the first service and the second service being part of a service chain;
storing a second configuration associated with a second VRF instance of the border node, the second VRF instance facilitating communications with the second service of the service chain disposed in the external network domain, the second configuration indicating at least that the second service is a last service of the service chain; receiving, by the border node via the first VRF instance and from the first service, a packet previously sent to the first service by the border node using the first VRF instance, wherein the packet received from the first service is decapsulated such that a header associated with the enterprise network domain is missing from the packet, the header indicative of a next hop for the packet; based at least in part on the header missing from the packet, sending, by the border node and to a control plane device associated with the enterprise network domain, a request associated with determining the next hop, the request including the identifier and the type associated with the second service of the service chain; based at least in part on receiving, at the border node and from the control plane device, an indication that the second VRF instance is to be used as the next hop to send the packet to the second service, forwarding the packet from the first VRF instance to the second VRF instance; determining, by the border node and based at least in part on the second configuration, that the second service is the last service of the service chain; and based at least in part on the second service being the last service of the service chain, forwarding, by the border node, the packet to a destination device subsequent to receiving the packet back from the second service.
(2,9 & 16) The method of claim 1, further
comprising: sending, by the border node using the second VN instance, the packet to the second service; and
receiving, at the border node and via the second VN instance, the packet from the second service
sending, by the border node or the other border node and using the second VRF instance, the packet to the second service; receiving, at the border node or the other border node and via the second VRF instance, the packet from the second service;
2. The method of claim 1, further comprising: sending, by the border node using the second VRF instance, the packet to the second service; and receiving, at the border node and via the second VRF instance, the packet from the second service.
(3, 10 &17) The method of claim 1, further comprising encapsulating the packet according to an extranet encapsulation protocol associated with the enterprise network domain prior to sending the packet to the second VN instance.
2. The method of claim 1, further comprising: determining, by the border node, that the second service is connected to the second VRF instance; and encapsulating the packet according to an extranet encapsulation protocol associated with the enterprise network domain prior to sending the packet to the second VRF instance.
3. The method of claim 1, further comprising encapsulating the packet according to an extranet encapsulation protocol associated with the enterprise network domain prior to sending the packet to the second VRF instance.
(4, 11& 18). The method of claim 1, wherein the packet is forwarded from the first VN instance
to the second VN instance using a forwarding plane capability of the border node.
3. The method of claim 1, wherein sending the packet to the second VRF instance comprises forwarding the packet to the second VRF instance using a forwarding plane capability of the border node.
4. The method of claim 1, wherein the packet is forwarded from the first VRF instance to the second VRF instance using a forwarding plane capability of the border node.
(5, 12 & 19). The method of claim 1, further comprising sending, by the border node based at least in part on receiving the packet from the second service, a request to the control plane of the enterprise network domain, the request associated with determining at least one of an address or a port associated with the destination device where the packet is to be sent
5. The method of claim 1, further comprising sending, by the border node based at least in part on receiving the packet from the second service, a request to the control plane of the enterprise network domain, the request associated with determining at least one of an address or a port associated with the destination device where the packet is to be sent.
(6, 13 & 20) The method of claim 1, further comprising sending, by the border node and to the control plane associated with the enterprise network domain, a request to register, with the control plane, one or more services that the border node is connected to, the one or more
services including the first service and the second service.
5. The method of claim 1, further comprising sending, by the border node and to a control plane of the enterprise network domain, a request to register, with the control plane, one or more services that the border node is connected to, the one or more services including the first service and the second service.
6. The method of claim 1, further comprising sending, by the border node and to a control plane associated with the enterprise network domain, a request to register, with the control plane, one or more services that the border node is connected to, the one or more services including the first service and the second service.
(7 & 14) The method of claim 1, wherein the first VN instance decapsulates the packet to remove the header associated with the enterprise network domain prior to sending the packet to the first service.
6. The method of claim 1, wherein the first VRF instance decapsulates the packet to remove the header associated with the enterprise network domain prior to the packet being sent to the first service.
7. The method of claim 1, wherein the first VRF instance decapsulates the packet to remove the header associated with the enterprise network domain prior to sending the packet to the first service.
Conclusion
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 DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher L Parry, can be reached at telephone number 571-272-8328. 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 to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/D.F.D/ Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights