DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
2. The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
3. Claims 6, 13 and 20 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 103
4. 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.
5. 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.
6. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
7. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
8. Claims 1-3, 6-10, 13-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Moisand et al. (US 2017/0366452 A1, hereinafter “Moisand”) in view of Mas Ivars et al. (US 2016/0344611 A1, hereinafter “Mas Ivars”).
Regarding claims 1, 8 and 15, Moisand teaches a method for ordering services in a service chain comprising: receiving, at an edge router (e.g., Gateway 8 of fig. 1, fig. 5, ¶ [0049], although described with respect to gateway 8 as an example, the techniques described herein with respect to directly packet flows to service complex 9 for subscriber-specific services may be implemented by other network devices, such as any router, switch or other component or device. ¶ [0073]), one or more data packets; determining, at the edge router, a sequence order of service chain elements for the one or more data packets based upon an established sequence that includes a plurality of service chain elements (figs. 1-3, ¶ [0028], ¶ [0031], gateway 8 steers individual subscriber packet flows 26 through defined sets of services provided by service nodes 10. That is, each subscriber packet flow may be forwarded through a particular ordered combination of services provided by service nodes 10, each ordered set being referred to herein as a “service chain.” ¶ [0032] ); transmitting and receiving, by the edge router in the sequence order, the one or more data packets to and from the service chain elements (fig. 1, ¶ [0031], ¶ [0032], ¶ [0033], Once processed at a terminal node of the service chain, i.e., the last node 10 to apply services to packets flowing along a particular service path, the terminal node may direct the traffic back to gateway 8 for further processing and/or forwarding to public network 12. For example, traffic engineered service paths may start and terminate with gateway 8); transmitting, by the edge router, the one or more data packets to a destination after a last of the service chain elements has been performed (fig. 1, ¶ [0028], ¶ [0033]).
Moisand does not explicitly teach dynamically determining, at the edge router, a sequence order of service chain elements for the one or more data packets based upon an established sequence, wherein upon automatically detecting a packet characteristic or network condition from one or more data packets indicating that the established sequence should be modified, the edge router modifies the established sequence by reordering at least two service chain elements of the plurality of service chain elements while retaining the at least two service chain elements in the sequence order, thereby changing an order in which a payload of the one or more data packets is processed by the at least two service chain elements.
Mas Ivars teaches dynamically determining, at a node, a sequence order of service chain elements for the one or more data packets based upon an established sequence, wherein upon automatically detecting a packet/flow characteristic or network condition from one or more data packets indicating that the established sequence should be modified (figs. 2 and 5, ¶ [0058], the control node firstly checks whether the previously identified flow characteristics have changed in a manner that would warrant or motivate a different succession of network functions that would be more suitable for the data flow than the one currently applied. For example, one or more specific parameters of the flow characteristics may be monitored and checked if they have changed so that they satisfy some predefined criteria), the node modifies the established sequence by reordering at least two service chain elements of the plurality of service chain elements while retaining the at least two service chain elements in the sequence order (fig. 5, ¶ [0043], ¶ [0059], the control node 300, 400 may change the succession of network functions by performing at least one of the following three operations: ¶ [0060], ¶ [0061], ¶ [0062] Changing placement of one or more network functions in the determined succession of network functions 304. For example, instead of routing the packets to network functions A, B and C in that order, it may be decided that they should better be routed according to the order of B, C and A), thereby changing an order in which a payload of the one or more data packets is processed by the at least two service chain elements (¶ [0032], the control node may select the network functions in the succession of network functions to accomplish at least one of: ¶ [0033] Transcoding of media from one format to another format, e.g. in order to accomplish format conversion, data compression or data upsampling. ¶ [0037] Modification of payload content in the data packets, e.g. if anything should be removed from or added to the content. ¶ [0038] Modification of data packet size, e.g. to become suitable for another transport protocol).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify, at the edge router upon automatically detecting a packet characteristic or network condition from one or more data packets indicating that the established sequence should be modified, the established sequence by reordering at least two service chain elements of the plurality of service chain elements while retaining the at least two service chain elements in the sequence order, thereby changing an order in which a payload of the one or more data packets is processed by the at least two service chain elements in the system of Moisand to achieve efficient customized service chaining which is adapted for a particular data flow characteristics (¶ [0008], ¶ [0044] of Mas Ivars).
Regarding claims 2, 9 and 16, Moisand in view of Mas Ivars teaches the method of claim 1, wherein the established sequence is at least partially operator defined (Moisand: ¶ [0062]. Claims 12, 14).
Regarding claims 3, 10 and 17, Moisand in view of Mas Ivars teaches the method of claim 1, wherein the established sequence has a first direction order that is used for sending packets and a second direction order that is used for receiving packets (Moisand: ¶ [0028], Flows 26 illustrated in FIG. 1 represent one or more upstream packet flows from any one or more subscriber devices 16 and directed to public network 12. The term “packet flow,” “traffic flow,” or simply “flow” refers to a set of packets originating from a particular source device and sent to a particular destination device. A single flow of packets, in either the upstream (sourced by one of subscriber devices 16) or downstream (destined for one of subscriber devices 16) direction, may be identified by the 5-tuple: ¶ [0036], SDN controller 19 may interact with gateway 8 to specify service chain 28A, 28B information. ¶ [0082], the gateway or other device may similarly steer inbound packets through service chains (e.g., to apply reverse NAT, firewall services and the like) prior to delivery of the inbound packets to the subscriber devices).
Regarding claims 6, 13 and 20, Moisand in view of Mas Ivars teaches the method of claim 1.
Moisand does not explicitly teach wherein the sequence order is performed through an automatic detection operation.
Mas Ivars teaches wherein the sequence order is performed through an automatic detection operation (fig. 5, ¶ [0032], ¶ [0043], ¶ [0059).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention to perform the sequence order through an automatic detection operation in the system of Moisand in view of Mas Ivars to achieve efficient customized service chaining which is adapted for a particular data flow characteristics (¶ [0008], ¶ [0043] of Mas Ivars).
Regarding claims 7 and 14, Moisand in view of Mas Ivars teaches the method of claim 1, further comprising: performing, by the service chain element, each of one or more services on the one or more data packets (Moisand: figs. 1-3, ¶ [0032], ¶ [0051], ¶ 0054]. Mas Ivars: figs. 2-5, ¶ [0032]-¶ [0039]).
9. Claims 4, 5, 11, 12, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Moisand in view of Mas Ivars as applied to claim 3 above, and further in view of Schultz et al. (US 2017/0019335 A1, hereinafter “Schultz”).
Regarding claims 4, 11 and 18, Moisand in view of Mas Ivars teaches the method of claim 3.
Moisand does not explicitly teach, wherein the established sequence for the first direction order is different from the sequence order in the second direction order.
Schultz teaches the well-known method of establishing a sequence for the first direction order is different from the sequence order in the second direction order (¶ [0030]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention to establish sequence for the first direction order different from the sequence order in the second direction order in the system of Moisand in view of Mas Ivars. The motivation for doing this is a matter of design choice (¶ [0030] of Schultz).
Regarding claims 5, 12 and 19, Moisand in view of Shah teaches the method of claim 4.
Moisand does not explicitly teach wherein the sequence order in a first direction order is opposite of the sequence order in a second direction order, except for the at least two service chain elements that are reordered based on the automatically detected packet characteristic or network condition.
Schultz teaches wherein the sequence order in a first direction order is opposite of the sequence order in a second direction order (¶ [0030]). Schultz further teaches it is possible for the second direction data to flow through the service chain in an order that is different than the opposite order of first direction. It is also possible for the second direction data to pass through more, fewer, or different service nodes than first direction data. In one example, a service node that performs firewall functions may process traffic in both directions, while a DDoS service node only monitors first direction. Other example service chain policies are possible without departing from the scope of embodiments (¶ [0030]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to establish the sequence order in a first direction order that is opposite of the sequence order in a second direction order, except for the at least two service chain elements that are reordered based on the automatically detected packet characteristic or network condition in the system of Moisand in view of Mas Ivars and Schultz. The motivation for doing this is a matter of design choice (¶ [0030] of Schultz).
Response to Arguments
10. Applicant's arguments filed on June 16, 2026 have been fully considered but are moot in view of new ground(s) of rejection.
Conclusion
11. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 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, Chirag Shah can be reached at 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477
Prosecution Insights