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
Applicant’s arguments filed March 31, 2026 have been considered but are not persuasive. All rejections are maintained and this action is made final.
Arguments regarding rejections under 35 USC 112, first paragraph
In answering the assertions made in the rejection, which include that the specification “does not describe what the [opaque protocol] value is, how to select it or otherwise determine its value so that it can be placed in an options indicator field, or how to detect it,” Applicant argues (1) the artisan would have understood that IANA assigns IP protocol numbers and (2) the specification implies at paragraph [0063] that the value of the options indicator value is not zero in the specific case of IPv6. Applicant also points out that the specification mentions at paragraph [0040] that existing values of a next header field can sometimes be 17 or 6. This would appear to mean that at best the specification narrows down the list of candidate numbers eligible to be a “selected opaque protocol value” to those numbers which are not zero, six, or seventeen. The genus of numbers that are not zero, six, and seventeen is very large, and the discussion in paragraphs 40 and 63 does not amount to a showing that the inventor has invented species sufficient to support a claim to the genus. For example, the specification does not appear identify any values which are actually opaque protocol values, nor does it describe how to produce a selected opaque protocol value.
Applicant next argues that, upon reading the instant specification, the artisan would be been inspired to read the IPv6 specification, and from the specification conclude that the opaque values include but are not limited to values between 148 and 252. Specifically, Applicant argues:
For instance, based on the listing of assigned Internet Protocol numbers at the time the present application was filed, a network administrator implementing the claimed invention for IPv6 packets can select any value between 148 and 252 as an opaque protocol value or any other value (e.g. 312 or 455) because such values are not assigned to any protocol or option and thus making the protocol value "opaque" because network devices would not recognize the protocol value as corresponding/assigned to a defined protocol or option.
It is notable that Applicant explicitly asserts that the genus of “opaque protocol values” goes beyond even the unassigned values in the IPv6 specification, and extends to numbers like 312 and 455. The undefinable breadth of the genus—values that are not zero, six, or seventeen, and which include but are not limited to the numbers 148-252, 312, and 455—would seem to make it even more difficult for this specification to support a claim encompassing that genus.
Therefore, Applicant’s arguments cannot be held as persuasive and the rejections are maintained.
Arguments regarding rejections under 35 USC 112, second paragraph
Applicant answers the assertions in the rejection by arguing that (1) “it is easy to determine if a given protocol value is an ‘opaque protocol value’ as of the date of filing the present application by simply going to IANA list of assigned protocol numbers” and (2) “if the selected/given protocol value has not been assigned to a previously defined protocol or option as of the date of filing the present application, then it meets the definition of being an opaque protocol value.” With respect to the first point, it is not clear how the IANA specifications are helpful in narrowing down the meaning of the term, because as applicant explicitly argued earlier, the IANA specifications at best only help the artisan understand that whatever an opaque protocol value is, it is not zero, six, or seventeen, because those values have been previously defined. However, this cannot be the entire definition, because nothing limits the list of previous definitions to those which appear in particular IANA specifications. For example, neither the claim nor the specification describes selecting a value between 148 and 252, nor how to select a value that is not zero, six, or seventeen while also being “opaque”. This leaves the questions posed in the rejection unresolved, including: “Is there any limit to where the previous definition must appear?” (at least because the specification and claims place no bounds on what counts as a definition), “Must the definition have been made in any particular way?” (at least because the specification and claims do not specify whether “definitions” can be made informally, such as verbally between engineers), and “What is the instant in time to which the definition must be previous?” (because the specification and claims do not specify whether “previous” is relative to the filing date or some other date).
Arguments regarding rejections under 35 USC 112, second paragraph
Applicant argues that the combinations including Kahn and Adhikari do not render the claims obvious. The examiner respectfully disagrees.
Applicant first argues that “Kahn does not teach modifying an options indicator field in the IP header from a first options protocol value to a selected opaque protocol value”. However, Kahn was not relied upon alone to teach this feature. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant next argues that Adhikari does not remedy the alleged deficiencies of Kahn because Adhikari teaches recording the route “in an options field or record space” while “the protocol value 7 in the type field of the record route option is not modified” and because “the combination of Kahn and Adhikari simply is an IPv4 packet that includes a record route option (Adhikari) and additional proprietary information added to the inner header (Kahn).” The Examiner respectfully disagrees and submits that the broadest reasonable interpretation of “options indicator field” does not exclude, and reasonably includes, the arrangement of Kahn as modified by Adhikari in the rejection.
As explained in the rejection, Kahn does not explicitly show that the modification is from a first options protocol value. Adhikari shows, among other things, modifying an options indicator field from a first options protocol value to another (by an intermediary node, adding its outgoing interface address to the options field: see [0046]-[0047], [0050], and Fig. 4). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kahn with the teachings of Adhikari in order to allow nodes in the system to add further informational content to the packet, allowing downstream nodes to learn more about the topology of the network (see Adhikari, [0047]). Note that, following modification with Adhikari, the options indicator field would still have an “opaque protocol value” at least because the combination of Kahn’s proprietary information and Adhikari’s route information does not correspond to any previously defined protocol or option.
Remarks regarding potential “allowable subject matter”
Applicant requests confirmation that claims 7-8 would be allowable if the written description/indefiniteness rejections are overcome. While it is true that claims not subject to rejection are allowable, the natures of the deficiencies of claims 7 and 8 (which they inherit from claim 1) are such that it is difficult to reasonably speculate about what their scope would be after repair of those deficiencies.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1 and 15 recite “modifying an options indicator field…to a selected opaque protocol value.” Independent claim 9 recites “determining that an options indicator field…comprises a selected opaque protocol value.” While the instant specification mentions an “opaque protocol value” in several places, it does not describe what the value is, how to select it or otherwise determine its value so that it can be placed in an options indicator field, or how to detect it. As explained in MPEP 2161.01(I):
Specifically, the specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art in a way that shows that the inventor actually invented the claimed invention at the time of filing. Id.; Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172. […]
The written description requirement of 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, applies to all claims including original claims that are part of the disclosure as filed. Ariad, 598 F.3d at 1349, 94 USPQ2d at 1170. As stated by the Federal Circuit, "[a]lthough many original claims will satisfy the written description requirement, certain claims may not." Id. at 1349, 94 USPQ2d at 1170-71; see also LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1343-46, 76 USPQ2d 1724, 1730-33 (Fed. Cir. 2005); Regents of the Univ. of Cal. v. Eli Lilly & Co., 119 F.3d 1559, 1568, 43 USPQ2d 1398, 1405-06 (Fed. Cir. 1997)("The description requirement of the patent statute requires a description of an invention, not an indication of a result that one might achieve if one made that invention."). Problems satisfying the written description requirement for original claims often occur when claim language is generic or functional, or both. Ariad, 593 F.3d at 1349, 94 USPQ2d at 1171 ("The problem is especially acute with genus claims that use functional language to define the boundaries of a claimed genus. In such a case, the functional claim may simply claim a desired result, and may do so without describing species that achieve that result. But the specification must demonstrate that the applicant [inventor] has made a generic invention that achieves the claimed result and do so by showing that the applicant [inventor] has invented species sufficient to support a claim to the functionally-defined genus.").
Paragraph [0062] explains that “An opaque protocol value is a protocol value that does not correspond to any previously defined protocol or option” and that “intermediate routers…will not know the meaning of this opaque protocol value,” but this is not enough to describe the claimed invention in a manner understandable to a person of ordinary skill in the art in a way that shows that the inventor actually invented the claimed invention at the time of filing. Instead, each independent claim merely recites the desired result of inserting, selecting, or detecting a protocol value in the genus of “opaque protocol values” that are unknown to intermediary routers, and does so while the specification fails to describe any species that achieve that result.
Any claim not specifically addressed above is rejected for inheriting the deficiencies of a parent claim.
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.
Claims 1-20 are 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Each of independent claims 1, 9, and 20 recite the term “opaque protocol value.” Paragraph [0062] attempts to define the term, stating that “An opaque protocol value is a protocol value that does not correspond to any previously defined protocol or option.” However, this definition is ambiguous, vague, and indefinite. For example, it is impossible to tell what would count as “previously defined” in this context. Is there any limit to where the previous definition must appear? Must the definition have been made in any particular way? What is the instant in time to which the definition must be previous? There appears to be no clear answer to these questions, nor any way to reliably determine whether a given protocol value is an “opaque protocol value.” Therefore, a person of ordinary skill in the art could not interpret the metes and bounds of the claims so as to understand how to avoid infringement, and the claims are indefinite.
Any claim not specifically addressed above is rejected for inheriting the deficiencies of a parent claim.
Claim Rejections - 35 USC § 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, 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, 2, 9, and 13-15 rejected under 35 U.S.C. 103 as being unpatentable over Kahn (US Pub. No. 2010/0080123) in view of Adhikari (US Pub. No. 2004/0252694).
Regarding claim 1, Kahn teaches a method comprising:
receiving a packet comprising an Internet Protocol (IP) header (receiving an “original IP packet” at mobility anchor node 121: see Fig. 2 and [0037]);
modifying an options indicator field in the IP header to a selected opaque protocol value (inserting encoded proprietary information into one or more IPv4 Options fields, which results in an “opaque protocol value” at least because it does not correspond to any previously defined protocol or option: see [0033]-[0034], [0038], and [0044]-[0045)); and
transmitting the packet (propagating the inner packet toward mobility gateway node 122: see [0045]-[0046]).
Kahn does not explicitly show:
determining that the IP header comprises one or more options; and
that the modification is from a first options protocol value.
Adhikari shows:
determining that an IP header comprises one or more options (determining that a packet or an encapsulated packet has a record route option enabled or has an existing address recorded in an options field: see [0029] and [0046]-[0047]); and
modifying an options indicator field from a first options protocol value to another (by an intermediary node, adding its outgoing interface address to the options field: see [0046]-[0047], [0050], and Fig. 4);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kahn with the teachings of Adhikari in order to allow nodes in the system to add further informational content to the packet, allowing downstream nodes to learn more about the topology of the network (see Adhikari, [0047]). Note that, following modification with Adhikari, the options indicator field would still have an “opaque protocol value” at least because the combination of Kahn’s proprietary information and Adhikari’s route information does not correspond to any previously defined protocol or option.
Regarding claim 2, the combination shows the limitations of claim 1 as applied above and further shows wherein the method is implemented by an egress node of a sub-network, and the sub-network is a source sub-network of the packet (IP network 110: see Kahn, Fig. 2 and [0037]).
Regarding claim 9, Kahn teaches a method comprising:
receiving a packet comprising an Internet Protocol (IP) header (receiving a tunneled IP packet at mobility gateway node 122: see Fig. 2, [0033]-[0034], and [0044]-[0046]);
determining that an options indicator field in the IP header comprises a selected opaque protocol value (identifying encoded proprietary information in an IPv4 Options field: see [0033]-[0034] and [0045]-[0046]);
modifying the options indicator field from the selected opaque protocol value to another value (stripping the encoded proprietary information from the packet, returning the packet to its original form: see [0033]-[0034] and [0045]-[0046]); and
transmitting the packet (propagating the original IP packet to RAN 130 for delivery to its intended destination: see [0047]).
Kahn does not explicitly show:
that the modification is to an options value indicating that the IP header comprises one or more options.
Adhikari shows:
modifying an options indicator field from a value to an options value indicating that an IP header comprises one or more options (by an intermediary node, adding its outgoing interface address to the options field to the IP header of a packet or an encapsulated packet, indicating that it comprises at least a record route option: see [0029], [0046]-[0047], [0050], and Fig. 4).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kahn with the teachings of Adhikari in order to allow nodes in the system to add further informational content to the packet, allowing downstream nodes to learn more about the topology of the network (see Adhikari, [0047]).
Regarding claim 13, the combination shows the limitations of claim 9 as applied above and further shows removing one or more fields that were previously added to the IP header (stripping the encoded proprietary information from the packet, returning the packet to its original form: see Kahn, [0033]-[0034] and [0045]-[0046]).
Regarding claim 14, the combination shows the limitations of claim 9 as applied above and further shows wherein the method is implemented by an ingress node of a sub- network, and the sub-network is a destination sub-network of the packet (radio access network 130: see Kahn, Fig. 2 and [0047]).
Regarding claim 15, Kahn teaches a network node (e.g., mobility anchor node 121: see Fig. 2 and [0037]) comprising:
a memory storing instructions (at least implicitly disclosed as a necessary component of a computer-implemented system); and
one or more processors coupled to the memory (at least implicitly disclosed as a necessary component of a computer-implemented system), wherein the one or more processors execute the instructions to cause the network node to:
receive a packet comprising an Internet Protocol (IP) header (receiving an “original IP packet” at mobility anchor node 121: see Fig. 2 and [0037]);
modify an options indicator field in the IP header to a selected opaque protocol value (inserting encoded proprietary information into one or more IPv4 Options fields, which results in an “opaque protocol value” at least because it does not correspond to any previously defined protocol or option: see [0033]-[0034], [0038], and [0044]-[0045)); and
transmit the packet (propagating the inner packet toward mobility gateway node 122: see [0045]-[0046]).
Kahn does not explicitly show:
determining that the IP header comprises one or more options; and
that the modification is from a first options protocol value.
Adhikari shows:
determining that an IP header comprises one or more options (determining that a packet or an encapsulated packet has a record route option enabled or has an existing address recorded in an options field: see [0029] and [0046]-[0047]); and
modifying an options indicator field from a first options protocol value to another (by an intermediary node, adding its outgoing interface address to the options field: see [0046]-[0047], [0050], and Fig. 4);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kahn with the teachings of Adhikari in order to allow nodes in the system to add further informational content to the packet, allowing downstream nodes to learn more about the topology of the network (see Adhikari, [0047]). Note that, following modification with Adhikari, the options indicator field would still have an “opaque protocol value” at least because the combination of Kahn’s proprietary information and Adhikari’s route information does not correspond to any previously defined protocol or option.
Claims 3, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kahn (US Pub. No. 2010/0080123) in view of Adhikari (US Pub. No. 2004/0252694), and further in view of Perez (US Pub. No. 2019/0068498).
Regarding claim 3, the combination shows the limitations of claim 1 as applied above and further shows wherein the IP header is an IP version 6 (IPv6) header (see Adhikari, [0046], as combined above), but does not explicitly show that the one or more options comprises hop-by-hop header options, and the options indicator field is a Next Header Field.
Perez shows an IPv6 header where optional information is carried in hop-by-hop header options, and the options indicator field is a Next Header Field (see [0005] and [0024]-[0026]).
It would have been obvious to one of ordinary skill in the art at the time of the invention to further modify the system of Kahn with the teachings of Perez in order to achieve the predictable result of continuing to store the encoded information while allowing intermediate IPv6 nodes to process the packets (see Perez, [0005]).
Claims 10 and 16 correspond to claim 3 and are rejected for the reasons given above, mutatis mutandis.
Claims 4, 5, 6, 11, 12, 17, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kahn (US Pub. No. 2010/0080123) in view of Adhikari (US Pub. No. 2004/0252694), and further in view of Vincent (US Pat. No. 8,428,087).
Regarding claim 4, the combination shows the limitations of claim 1 as applied above but does not explicitly show inserting a flow identifier in the IP header to identify a packet flow.
Vincent shows inserting a flow identifier in a header to identify a packet flow (see col. 13, lines 4-29).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Kahn with the teachings of Vincent in order to support packet desegmentation (see Vincent, col. 13, lines 23-25).
Regarding claim 5, the combination shows the limitations of claim 1 as applied above and further shows wherein the IP header is an IP version 4 (IPv4) header (see Kahn, [0034]), but does not explicitly show that the options indicator field is a Protocol field.
Vincent shows where an options indicator field is a Protocol field (see col. 2, lines 55-60).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Kahn with the teachings of Vincent in order to uniquely identify the format of the packet (see Vincent, col. 2, lines 55-58).
Regarding claim 6, the combination shows the limitations of claim 1 as applied above but does not explicitly show modifying at least one of an Internet Header Length (IHL) field from a first IHL value to a second IHL value indicating a minimum THL length, a Header Checksum (HC) value from a first HC value to a second HC value, or a Total Length (TL) header field from a first TL value to a second TL value indicating an increase in a TL of the packet.
Vincent shows modifying at least one of an Internet Header Length (IHL) field from a first IHL value to a second IHL value indicating a minimum THL length, a Header Checksum (HC) value from a first HC value to a second HC value, or a Total Length (TL) header field from a first TL value to a second TL value indicating an increase in a TL of the packet (e.g., at least changing a header checksum value: see col. 15, lines 28-42).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Kahn with the teachings of Vincent in order to ensure that the checksum remains useful for validating the contents of the packet.
Claims 11, 12, 17, and 18 correspond to claims 5 and 6 and are rejected for the reasons given above, mutatis mutandis.
Claim 20 corresponds to claim 4 and is rejected for the reasons given above, mutatis mutandis.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Kahn (US Pub. No. 2010/0080123) in view of Adhikari (US Pub. No. 2004/0252694), and further in view of Thubert (US Pub. No. 2004/0179532).
Regarding claim 19, the combination does not explicitly show that the first options protocol value is 0.
Thubert shows wherein a protocol value is zero (see [0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Kahn with the teachings of Thubert in order to allow routers to identify the protocol.
Conclusion
THIS ACTION IS MADE FINAL. 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 Christopher D. Biagini whose telephone number is (571)272-9743. The examiner can normally be reached weekdays from 9 AM - 5 PM.
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, Oscar Louie can be reached at (571) 270-1684. 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.
Christopher D. Biagini
Primary Examiner
Art Unit 2445
/Christopher Biagini/Primary Examiner, Art Unit 2445
Prosecution Insights