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 .
Claims StatusClaims 1-7 & 13 are pending and have been rejected.
Restriction: Elected group, claims 1-7 & 13. Non-elected group, claims 8-12 & 14-16.
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, 3, 4, 7 and 13 rejected on the ground of nonstatutory double patenting over claim 1, 3, 4, 7 of Application 18/486476 since the claims, if allowed, would improperly extend the “right to exclude” already granted in the patent.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent and the application are claiming common subject matter, as follows: current service of a chain of n services.
Furthermore, there is no apparent reason why applicant was prevented from presenting claims corresponding to those of the instant application during prosecution of the application which matured into a patent. See In re Schneller, 397 F.2d 350, 158 USPQ 210 (CCPA 1968). See also MPEP § 804.
Instant Application 18/486439
Application 18/486476
Claims 1 & 13 A method for implementing a current service of a chain of n services, the method comprising: receiving, from the service preceding the current service in the chain, a first routing token comprising message routing data between the services of the chain; verifying that the current service is a legitimate recipient of the first routing token; implementing a function of the current service; generating a current chaining token from a data of evidence of a passage through the current service; and transmitting, to the service following the current service in the chain, the current chaining token and a second routing token determined from the first routing token.
Claim 1 A method for implementing a current service, of a chain of n services, the method comprising: receiving, from the service preceding the current service in the chain, a first routing token comprising message routing data between the services of the chain and a first chaining token comprising data of evidence of a passage through the previous service; verifying that the current service is a legitimate recipient of the first routing token; implementing a function of the current service; generating a second chaining token based on the first chaining token and based on a second routing token determined from the first routing token; and transmitting, to the service following the current service in the chain, the second chaining token and the second routing token.
Claim 3
wherein the current service comprises an identifier of the current service, the method further comprising obtaining an recipient service identifier by applying a decryption function to the first routing token, the decryption function using a decryption key decryption associated with the current service, wherein verifying that the current service is a legitimate recipient comprises comparing the recipient service identifier with the identifier of the current service.
Claim 3
wherein the current service comprises an identifier of the current service, the method further comprising obtaining a recipient service identifier by applying a decryption function to the first routing token, the decryption function using a decryption key associated with the current service, wherein verifying that the current service is a legitimate recipient comprises comparing the recipient service identifier with the identifier of the current service.
Claim 4 wherein the second routing token is generated by applying a decryption function to the first routing token, the decryption function using a decryption key associated with the current service.
Claim 4
wherein the second routing token is generated by applying a decryption function to the first routing token, the decryption function using a decryption key associated with the current service.
Claim 7 wherein encryption, decryption, signature and identification functions at the level of the current service are based on public key cryptographic technologies, and refer to an associated electronic certificate.
Claim 7 wherein encryption, decryption, signature and identification functions at the level of the service are based on public key cryptographic technologies, and refer to an associated electronic certificate.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a module for…” in claim 13.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof (Specification of instant application, Paragraph 67 and Figure 3A).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
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.
Claims 1-4, 7 & 13 are rejected under 35 U.S.C. 103 as being unpatentable over Dunbar et al. (U.S. Publication 2015/0326473), hereinafter ‘Dunbar’ in view of Lim et al. (U.S. Publication 2014/0198791), hereinafter ‘Lim’.
As to claim 1, Dunbar discloses a method for implementing a current service of a chain of n services, the method comprising: receiving, from the service preceding the current service in the chain, a first routing token comprising message routing data between the services of the chain (Dunbar, see [0029], path message is received and forwarded, wherein the service function path information comprises instructions for network nodes to map a data packet attributes to a service chain ID for routing data packets. See [0033] and fig. 2, service chain ID comprises a list that contains the SFF network nodes along the service function path and one or more service functions); implementing a function of the current service (Dunbar, see [0023], routing and implementing service functions along service function chains and service function paths. Routing loops can be implemented in a network for routing data packets along service function chains or service function paths); generating a current chaining token from a data of evidence of a passage through the current service (Dunbar, see [0030-0031], sending confirmation message when data packets are communicated from the service function ingress node along the service function paths to the service function egress nodes); and transmitting, to the service following the current service in the chain, the current chaining token and a second routing token determined from the first routing token (Dunbar, see [0029], the service function path information comprises instructions for network nodes to associate one or more data packet attributes to a service chain ID for routing data packets. See [0033] and fig. 2, Service function chain comprises a service chain ID and one or more SFF network node entries for a service function path. See [0041], data packets are transmitted from and received at the same port to be processed by a service function). Dunbar is silent to verifying that the current service is a legitimate recipient of the first routing token; However, Lim discloses verifying that the current service is a legitimate recipient of the first routing token (Lim, see [0008], [0014] & fig. 1-3, authenticating transmission path of the packet in a corresponding node in a domain, wherein the transmission processing unit is configured to verify whether or not to authentication such that a reception packet passes through the corresponding node has been performed and whether or not an immediately previous node that should be passed through along the transmission path has been passed through and transmit the packet); Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dunbar in view of Lim in order to further modify the method for service chain path route reservations from the teachings of Dunbar with the method for processing packet for routing from the teachings of Lim. One of ordinary skill in the art would have been motivated because it would allow to transmit a packet among nodes in the network (Lim – 0003).
As to claim 2, Dunbar in view of Lim discloses everything disclosed in claim 1. Lim further discloses wherein the current chaining token is generated based on the second routing token (Lim, see [0033], with respect to the RO node (2-0), information with regard to the immediately previous transmission node through which the reception packet passed and the next reception node is contained in an attribute managed together with the routing ID value (A) of the RO node (2-0). That is, the RO node (2-0) is an ingress node, and therefore the immediately previous transmission node is NULL and the next reception node is the R1 node (2-1). Similarly, the transmission node and the reception node of the R1 node (2-1) are the RO node (2-0) and the R2 node (2-2), respectively. According to one embodiment, the transmission processing unit (22-0) of the RO node (2-0) inserts the routing ID value (A) and the path verification value to the header of the packet which is actually transmitted using the value managed at the routing table. The path verification value may be a value which is obtained by encrypting the routing ID value (A) into a private key value of the corresponding node. The public key can be used to confirm the encrypted path verification value).
As to claim 3, Dunbar in view of Lim discloses everything disclosed in claim 1. Lim further discloses wherein the current service comprises an identifier of the current service, the method further comprising obtaining an recipient service identifier by applying a decryption function to the first routing token, the decryption function using a decryption key decryption associated with the current service, wherein verifying that the current service is a legitimate recipient comprises comparing the recipient service identifier with the identifier of the current service (Lim, see [0014], determining packet authentication to determine whether or not authentication such that a reception packet passes through a corresponding node has been performed; verifying and determining a packet path such that, according to the result of the packet authentication determination, if the reception packet is not authenticated, the packet is dropped, and if the reception packet is authenticated, it is determined whether or not the packet has passed through the immediately previous node that should be passed through along a transmission path; and verifying and correcting the header path such that, according to the result of the packet path verification determination).
As to claim 4, Dunbar in view of Lim discloses everything disclosed in claim 1. Lim further discloses wherein the second routing token is generated by applying a decryption function to the first routing token, the decryption function using a decryption key associated with the current service (Lim, see [0009], the transmission processing unit may insert the routing ID value to which the transmission path is set and a path verification value thereto into a header of a transmission packet, and thereafter transmit the transmission packet to the next node. The path verification value may be a value which is obtained by encrypting the routing ID value into a private key value of the corresponding node).
As to claim 7, Dunbar in view of Lim discloses everything disclosed in claim 1, wherein encryption, decryption, signature and identification functions at the level of the current service are based on public key cryptographic technologies, and refer to an associated electronic certificate (Lim, see [0016], the determining of the packet path verification may include acquiring a public key of the immediately previous node that should be passed through along the transmission path from an encryption key table and thereafter using the acquired public key, and confirming the encrypted path verification value of the reception packet).
As to claim 13, Dunbar discloses an electronic device for implementing a service of a service chain, the electronic device comprising: a module for receiving a first routing token comprising message routing data between the services of the service chain (Dunbar, see [0029], path message is received and forwarded, wherein the service function path information comprises instructions for network nodes to map a data packet attributes to a service chain ID for routing data packets. See [0033] and fig. 2, service chain ID comprises a list that contains the SFF network nodes along the service function path and one or more service functions); a module for implementing a function of said service (Dunbar, see [0023], routing and implementing service functions along service function chains and service function paths. Routing loops can be implemented in a network for routing data packets along service function chains or service function paths); a module for generating a chaining token from a data of evidence of a passage through said service (Dunbar, see [0030-0031], sending confirmation message when data packets are communicated from the service function ingress node along the service function paths to the service function egress nodes); and, a module for transmitting, to the service following said service in the service chain, the generated chaining token and a second token routing token determined from the first routing token (Dunbar, see [0029], the service function path information comprises instructions for network nodes to associate one or more data packet attributes to a service chain ID for routing data packets. See [0033] and fig. 2, Service function chain comprises a service chain ID and one or more SFF network node entries for a service function path. See [0041], data packets are transmitted from and received at the same port to be processed by a service function). Dunbar is silent to a module for verifying that said service is a legitimate recipient of the first routing token; However, Lim discloses a module for verifying that said service is a legitimate recipient of the first routing token (Lim, see [0008], [0014] & fig. 1-3, authenticating transmission path of the packet in a corresponding node in a domain, wherein the transmission processing unit is configured to verify whether or not to authentication such that a reception packet passes through the corresponding node has been performed and whether or not an immediately previous node that should be passed through along the transmission path has been passed through and transmit the packet); Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dunbar in view of Lim in order to further modify the method for service chain path route reservations from the teachings of Dunbar with the method for processing packet for routing from the teachings of Lim. One of ordinary skill in the art would have been motivated because it would allow to transmit a packet among nodes in the network (Lim – 0003).
Claims 5 & 6 are rejected under 35 U.S.C. 103 as being unpatentable over Dunbar et al. (U.S. Publication 2015/0326473), hereinafter ‘Dunbar’ in view of Lim et al. (U.S. Publication 2014/0198791), hereinafter ‘Lim’ and Beliveau et al. (U.S. Publication 2015/0124815), hereinafter ‘Beliveau’.
As to claim 5, Dunbar in view of Lim discloses everything disclosed in claim 1, but is silent to further comprising: generating, by the current service, the data of evidence of a passage through the current service, the data being generated by applying a hash function to the second routing token; and transmitting, by the current service, the data to at least one of the next service or a monitoring service. However, Beliveau discloses generating, by the current service, the data of evidence of a passage through the current service, the data being generated by applying a hash function to the second routing token (Beliveau, see [0054], first assigned to a service instance and this information can be stored in the data path for subsequent packets, wherein the traffic is partitioned over the services by using a hash function based on the subscriber identity (source IP address in the upstream, destination IP address in the downstream)); and transmitting, by the current service, the data to at least one of the next service or a monitoring service (Beliveau, see [0069], the packet is sent to the controller for further processing. Once the controller receive the packet, analyze it, to then send an OFPT_FLOW_MOD to the forwarding element in order to program the learned flow).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dunbar in view of Lim and Beliveau in order to further modify the method for service chain path route reservations from the teachings of Dunbar with the method for processing packet for routing from the teachings of Lim and the method for steering traffic through a set of services from the teachings of Beliveau. One of ordinary skill in the art would have been motivated because it would allow to transmit to destination in accordance with instance of the next service (Beliveau – Abstract).
As to claim 6, Dunbar in view of Lim discloses everything disclosed in claim 1, is silent to further comprising: receiving, by the current service, a data of evidence of that the previous service has actually been applied; and transmitting, by the current service, the received data to the next service. However, Beliveau discloses receiving, by the current service, a data of evidence of that the previous service has actually been applied (Beliveau, see [0069], controller receives the data packet and analyzes it. See [0071], a packet that is received from a VM or a service will most likely result in a successful lookup); and transmitting, by the current service, the received data to the next service (Beliveau, see [0069], the packet is sent to the controller for further processing. Once the controller receive the packet, analyze it, to then send an OFPT_FLOW_MOD to the forwarding element in order to program the learned flow). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Dunbar in view of Lim and Beliveau in order to further modify the method for service chain path route reservations from the teachings of Dunbar with the method for processing packet for routing from the teachings of Lim and the method for steering traffic through a set of services from the teachings of Beliveau. One of ordinary skill in the art would have been motivated because it would allow to transmit to destination in accordance with instance of the next service (Beliveau – Abstract).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. This includes:
U.S. Publication 2016/0315819, which describes carrying in-band metadata for network path proof of transit.
U.S. Publication 2008/0289039, which describes protecting a message from an XML attack when being exchanged in a distributed and decentralized network system Any inquiry concerning this communication or earlier communications from the examiner should be directed to TANIA M PENA-SANTANA whose telephone number is (571)270-0627. The examiner can normally be reached Monday - Friday 8am to 4pm EST.
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, Nicholas R Taylor can be reached at 5712723889. 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.
/TANIA M PENA-SANTANA/Examiner, Art Unit 2443
/CHRISTOPHER B ROBINSON/Primary Examiner, Art Unit 2443