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 .
Specification
The title of the invention is not descriptive with respect to the claimed invention of translating the source address into Internet Protocol version six (IPv6) format by applying a function to translate the LDN suffix into an IPv6 suffix. A new title is required that is clearly indicative of the invention to which the claims are directed.
Drawings
New corrected drawings in compliance with 37 CFR 1.121(d) are required in this application because the drawings (Figures 1 to 13) filed 10/16/2023 do not correspond to the description of the specification filed 10/16/2023. Applicant is advised to employ the services of a competent patent draftsperson outside the Office, as the U.S. Patent and Trademark Office no longer prepares new drawings. The corrected drawings are required in reply to the Office action to avoid abandonment of the application. The requirement for corrected drawings will not be held in abeyance.
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 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 re 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 - 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 - 20 of copending Application No. 18/487,838 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the conflicting claims from Application No. 18/487,888 and Application No. 18/487,838 are directed to the same scope of inventive concept as presented in the table below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims from Application No. 18/487,888
Claims from Application No. 18/487,838
1. A method implemented by a border router, the method comprising: receiving an upstream packet over a limited domain network (LDN), the upstream packet comprising a source address in LDN format including an LDN suffix; translating the source address into Internet Protocol version six (IPv6) format by applying a function to translate the LDN suffix into an IPv6 suffix; and forwarding the upstream packet over an IPv6 network based on the source address in IPv6 format as included in the upstream packet.
2. The method of claim 1, wherein the function is a hash function.
3. The method of claim 1, wherein the function is a reversible function.
4. The method of claim 1, wherein the source address in the LDN format includes an LDN prefix, and wherein the translating the source address in the LDN format into the IPv6 format includes obtaining an IPv6 global routing prefix mapped to the LDN prefix.
5. The method of claim 4, wherein the upstream packet is received as a New IP packet with the LDN prefix and the LDN suffix contained in a shipping specification
6. The method of claim 1, wherein the LDN suffix is in a user defined format without a fixed address length.
7. The method of claim 1, wherein the LDN suffix contains a device address in one of: a Modbus format, a Building Automation and Control networks (BACNet) format, a Process Field Bus (ProfiBus) format, or combinations thereof.
8. The method of claim 4, wherein the LDN prefix is an LDN name, and wherein the LDN suffix contains an application type, a subnet type, and a device name.
9. The method of claim 8, wherein the function translates the application type into an application identifier (ID), translates the subnet type into a subnet ID, and translates the device name into a device ID.
10. The method of claim 1, wherein the upstream packet, as received, comprises a destination address in the IPv6 format and the source address in the LDN format.
11. The method of claim 4, further comprising: receiving a downstream packet over the IPv6 network, the downstream packet comprising a destination address in the IPv6 format including the IPv6 global routing prefix and the IPv6 suffix; translating the destination address into the LDN format by applying a second function to translate the IPv6 suffix into the LDN suffix; and forwarding the downstream packet over the LDN based on the destination address in the LDN format.
12. The method of claim 11, wherein the translating the destination address into the LDN format includes obtaining the LDN prefix mapped to the IPv6 global routing prefix.
13. The method of claim 11, wherein the translating the destination address into the LDN format includes discarding the IPv6 global routing prefix.
14. The method of claim 11, wherein the downstream packet, as forwarded, comprises the source address in the IPv6 format and the destination address in the LDN format.
15. The method of claim 11, wherein the downstream packet is forwarded as a New IP packet with the LDN prefix and the LDN suffix contained in a shipping specification.
16. The method of claim 11, wherein the translating is performed based on a forwarding information base (FIB), and wherein the FIB is updated based on one of: an Intermediate System to Intermediate System (ISIS) protocol, an Open Shortest Path First (OSPF) protocol, a Border Gateway Protocol (BGP), or combinations thereof.
17. A method implemented by a network device, the method comprising: obtaining data in a limited domain network (LDN); generating a packet containing the data, the packet containing a source address in an LDN format and a destination address in an Internet Protocol version six (IPv6) format; and transmitting the packet over the LDN.
18. The method of claim 17, wherein the LDN format includes an address in one of: a Modbus format, a Building Automation and Control networks (BACNet) format, a Process Field Bus (ProfiBus) format, or combinations thereof.
19. The method of claim 17, wherein the packet is a New IP packet with the source address and the destination address contained in a shipping specification.
20. The method of claim 17, wherein the LDN format is in a user defined format without a fixed address length.
1. A method implemented by a border router, the method comprising: receiving an upstream packet over a limited domain network (LDN), the upstream packet comprising a source address in LDN format including an LDN suffix, wherein the LDN employs communication packets formatted according to one or more user defined formats other than an Internet Protocol (IP) format; translating the source address into Internet Protocol version six (IPv6) format by applying a function to translate the LDN suffix into an IPv6 suffix; and forwarding the upstream packet over an IPv6 network based on the source address in IPv6 format as included in the upstream packet.
2. The method of claim 1, wherein the function is a hash function.
3. The method of claim 1, wherein the function is a reversible function.
4. The method of claim 1, wherein the source address in the LDN format includes an LDN prefix, and wherein the translating the source address in the LDN format into the IPv6 format includes obtaining an IPv6 global routing prefix mapped to the LDN prefix.
5. The method of claim 4, wherein the upstream packet is received as a New IP packet with the LDN prefix and the LDN suffix contained in a shipping specification.
6. The method of claim 1, wherein the LDN suffix is in a user defined format without a fixed address length.
7. The method of claim 1, wherein the LDN suffix contains a device address in one of: a Modbus format, a Building Automation and Control networks (BACNet) format, a Process Field Bus (ProfiBus) format, or combinations thereof.
8. The method of claim 4, wherein the LDN prefix is an LDN name, and wherein the LDN suffix contains an application type, a subnet type, and a device name.
9. A method implemented by a border router, the method comprising: receiving an upstream packet over a limited domain network (LDN), the upstream packet comprising a source address in LDN format including an LDN suffix; translating the source address into Internet Protocol version six (IPv6) format by applying a function to translate the LDN suffix into an IPv6 suffix; and forwarding the upstream packet over an IPv6 network based on the source address in IPv6 format as included in the upstream packet; wherein the source address in the LDN format includes an LDN prefix, and wherein the translating the source address in the LDN format into the IPv6 format includes obtaining an IPv6 global routing prefix mapped to the LDN prefix; wherein the LDN prefix is an LDN name, and wherein the LDN suffix contains an application type, a subnet type, and a device name; and wherein the function translates the application type into an application identifier (ID), translates the subnet type into a subnet ID, and translates the device name into a device ID.
10. The method of claim 1, wherein the upstream packet, as received, comprises a destination address in the IPv6 format and the source address in the LDN format.
11. The method of claim 4, further comprising: receiving a downstream packet over the IPv6 network, the downstream packet comprising a destination address in the IPv6 format including the IPv6 global routing prefix and the IPv6 suffix; translating the destination address into the LDN format by applying a second function to translate the IPv6 suffix into the LDN suffix; and forwarding the downstream packet over the LDN based on the destination address in the LDN format.
12. The method of claim 11, wherein the translating the destination address into the LDN format includes obtaining the LDN prefix mapped to the IPv6 global routing prefix.
13. The method of claim 11, wherein the translating the destination address into the LDN format includes discarding the IPv6 global routing prefix.
14. The method of claim 11, wherein the downstream packet, as forwarded, comprises the source address in the IPv6 format and the destination address in the LDN format.
15. The method of claim 11, wherein the downstream packet is forwarded as a New IP packet with the LDN prefix and the LDN suffix contained in a shipping specification.
16. The method of claim 11, wherein the translating is performed based on a forwarding information base (FIB), and wherein the FIB is updated based on one of: an Intermediate System to Intermediate System (ISIS) protocol, an Open Shortest Path First (OSPF) protocol, a Border Gateway Protocol (BGP), or combinations thereof.
17. A method implemented by a network device, the method comprising: obtaining data in a limited domain network (LDN), wherein the LDN employs communication packets formatted according to one or more user defined formats other than an Internet Protocol (IP) format; generating a packet containing the data, the packet containing a source address in an LDN format and a destination address in an Internet Protocol version six (IPv6) format; and transmitting the packet over the LDN.
18. The method of claim 17, wherein the LDN format includes an address in one of: a Modbus format, a Building Automation and Control networks (BACNet) format, a Process Field Bus (ProfiBus) format, or combinations thereof.
19. The method of claim 17, wherein the packet is a New IP packet with the source address and the destination address contained in a shipping specification.
20. The method of claim 17, wherein the LDN format is in a user defined format without a fixed address length.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 17 and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Laurence et al. (Patent No.: US 9,641,434; hereinafter Laurence).
Regarding claim 17, Laurence discloses a method implemented by a network device, the method comprising: obtaining data in a limited domain network (LDN) (see Fig. 1, private or local network 100 using IPv4, col. 3 lines 5 – 10, 20 – 22,…to receive outgoing packets (e.g., IPv4 packets) from sources 110 on the private network 100), the upstream packet comprising a source address in LDN format (see col. 3 lines 5 – 10, col. 4 lines 25 – 27, a source IPv4 address of an incoming packet);
generating a packet containing the data, the packet containing a source address in an LDN format and a destination address in an Internet Protocol version six (IPv6) format (see col. 5 lines 42 – 48,… may be configured to receive outgoing packets (e.g., IPv4 packets) from sources on the private network 100, convert the packets to an IP address space used on the external network 140 (e.g., an IPv6 address space, Fig. 2A, IPv4 src A and destination of IPv6 packet); and
transmitting the packet over the LDN (see col. 5 lines 48 – 50, col. 6 lines 27 – 30, the outgoing IPv6 packet may then be sent to a respective destination 170 via the external network(s) 140).
Regarding claim 19, Laurence discloses wherein the packet is a New IP packet with the source address and the destination address contained in a shipping specification (see Fig. 2A, 2B, col. 3 lines 44 – 55, IPv4 src A and IPv4 dest B are contained in a new packet).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 5, 10, and 11 – 15 are rejected under 35 U.S.C. 103 as being unpatentable over Laurence et al. (Patent No.: US 9,641,434; hereinafter Laurence) in view of Zou et al. (Pub. No.: US 2013/0301650; hereinafter Zou).
Regarding claim 1, Laurence discloses a method implemented by a border router (see Fig. 1, border device 120), the method comprising: receiving an upstream packet over a limited domain network (LDN) (see Fig. 1, private or local network 100 using IPv4, col. 3 lines 5 – 10, 20 – 22,…to receive outgoing packets (e.g., IPv4 packets) from sources 110 on the private network 100), the upstream packet comprising a source address in LDN format (see col. 3 lines 5 – 10, col. 4 lines 25 – 27, a source IPv4 address of an incoming packet);
translating the source address into Internet Protocol version six (IPv6) format by applying a function to translate the LDN suffix (ex: source port number) into an IPv6 suffix (see col. 5 lines 42 – 48,… may be configured to receive outgoing packets (e.g., IPv4 packets) from sources on the private network 100, convert the packets to an IP address space used on the external network 140 (e.g., an IPv6 address space), col. 6 lines 1 – 27, source port number may be included in the hash…The generated hash may then be concatenated with the private network 100 IPv4 source address in the lower portion (e.g., the lower 64 bits) of the IPv6 source address in the IPv6 packet header); and
forwarding the upstream packet over an IPv6 network based on the source address in IPv6 format as included in the upstream packet (see col. 5 lines 48 – 50, col. 6 lines 27 – 30, the outgoing IPv6 packet may then be sent to a respective destination 170 via the external network(s) 140).
Laurence does not explicitly disclose the following features: regarding claim 1, a source address in LDN format including an LDN suffix.
Regarding claim 1, Zou discloses a source address in LDN format including an LDN suffix (see para. 0029, 0045, source IPv4 address suffix).
It would have been obvious to one ordinary skilled in the art before the effective filing date of the claimed invention to modify the invention of Laurence, and have the features, as taught by Zou, in order to effectively increase the pool of available IPv4 addresses for legacy networks until such legacy networks can be completely upgraded to employ the newer IPv6 standards, as discussed by Zou (para. 0004).
Regarding claim 2, Laurence discloses wherein the function is a hash function (see col. 5 lines 62 – 65, a hash function).
Regarding claim 3, Laurence discloses wherein the function is a reversible function (see col. 6 lines 20 – 22, invertible function).
Regarding claim 4, Laurence discloses wherein the source address in the LDN format includes an LDN prefix, and wherein the translating the source address in the LDN format into the IPv6 format includes obtaining an IPv6 global routing prefix mapped to the LDN prefix (see Fig. 2A, col. 3 lines 42 – 55, the IPv6 subnet address of the source 110 may be determined from the IPv4 source address and put into the IPv6 source address as the IPv6 source prefix, col. 5 lines 15 – 22, … uses only an IPv6 prefix (e.g., a 64-bit prefix) in the IPv6 addresses of packet headers of outgoing packets).
Regarding claim 5, Laurence discloses wherein the upstream packet is received as a New IP packet with the LDN prefix and the LDN suffix contained in a shipping specification (see Fig. 2A, IPv4 packet is put into a new packet with IPv6 src prefix C and IPv6 dest prefix D including IPv4 src A and IPv4 dest B, col. 6 lines 1 - 14).
Regarding claim 10, Laurence discloses wherein the upstream packet, as received, comprises a destination address in the IPv6 format and the source address in the LDN format (see col. 3 lines 20 – 27, … to receive outgoing packets (e.g., IPv4 packets) from sources 110 on the private network 100, convert the packets to an IP address space used on the external network 140 (e.g., an IPv6 address space), Fig. 2A, IPv4 src A and destination of the packet in IPv6).
Regarding claim 11, Laurence discloses further comprising: receiving a downstream packet over the IPv6 network, the downstream packet comprising a destination address in the IPv6 format including the IPv6 global routing prefix and the IPv6 suffix (see Fig. 2B, IPv6 src prefix D and destination of the IPv6 packet); translating the destination address into the LDN format by applying a second function to translate the IPv6 suffix into the LDN suffix; and forwarding the downstream packet over the LDN based on the destination address in the LDN format (see Fig. 1, col. 4 lines 4 – 35, … a border device 120 of the private network 100 may also be configured to receive incoming packets (e.g., IPv6 packets) from destinations 170 via external network 140, convert the packets to an IP address space used on the private network 100 (e.g., an IPv4 address space), and send the IPv4 packets onto the private network 110 for delivery to respective destination endpoints (e.g., sources 110) on the network 100…Fig. 3 shows the process of converting IPv6 packet to IPv4 packet).
Regarding claim 12, Laurence discloses wherein the translating the destination address into the LDN format includes obtaining the LDN prefix mapped to the IPv6 global routing prefix (see Fig. 2B, IPv4 dest A is mapped to IPv6 dest prefix C as part of the destination of IPv6 packet).
Regarding claim 13, Laurence discloses wherein the translating the destination address into the LDN format includes discarding the IPv6 global routing prefix (see Fig. 2B, IPv6 prefixes are discarded when translating to IPv4 packet).
Regarding claim 14, Laurence discloses wherein the downstream packet, as forwarded, comprises the source address in the IPv6 format and the destination address in the LDN format (see Fig. 2B, source of the IPv6 packet and IPv4 dest A).
Regarding claim 15, Laurence discloses wherein the downstream packet is forwarded as a New IP packet with the LDN prefix and the LDN suffix contained in a shipping specification (see col. 4 lines 12 – 24, Fig. 2B, the new IPv4 contains IPv4 src B and IPv4 dest A).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Laurence et al. (Patent No.: US 9,641,434; hereinafter Laurence) in view of Zou et al. (Pub. No.: US 2013/0301650; hereinafter Zou) and further in view of Filsfils et al. (Pub. No.: US 2013/0089097; hereinafter Filsfils).
Laurence and Zou do not disclose the claimed features as recited in claim 16.
Regarding claim 16, Filsfils discloses wherein the translating is performed based on a forwarding information base (FIB) (see para. 0026, to convert IPv6 to IPv4 based on forwarding information bases (FIBs)), and wherein the FIB is updated based on one of: an Intermediate System to Intermediate System (ISIS) protocol, an Open Shortest Path First (OSPF) protocol, a Border Gateway Protocol (BGP), or combinations thereof (see para. 0017, ISIS, OSPF and BGP).
It would have been obvious to one ordinary skilled in the art before the effective filing date of the claimed invention to modify the invention of Laurence and Zou, and have the features, as taught by Filsfils, in order to provide communications mechanisms and methodologies that allow greater bandwidth, achieve superior performance, and/or offer minimal delay presents a significant challenge for designers of packet switching devices and network managers, as discussed by Filsfils (para. 0003).
Allowable Subject Matter
Claims 6 – 9, 18, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anh Ngoc M Nguyen whose telephone number is (571) 270-5139. The examiner can normally be reached on Monday to Friday, from 7:30 am to 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kwang Bin Yao can be reached on ((571) 272-3182. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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 .
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.
/ANH NGOC M NGUYEN/Primary Examiner, Art Unit 2473