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 .
DETAILED ACTION
Claim Rejections – 35 USC § 102/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 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.
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 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.
MPEP 2112 Section III.
Where applicant claims a composition in terms of a function, property or characteristic and the composition of the prior art is the same as that of the claim but the function is not explicitly disclosed by the reference, the examiner may make a rejection under both 35 U.S.C. 102 and 103, expressed as a 102/ 103 rejection. "There is nothing inconsistent in concurrent rejections for obviousness under 35 U.S.C. 103 and for anticipation under 35 U.S.C. 102." In re Best, 562 F.2d 1252, 1255 n.4, 195 USPQ 430, 433 n.4 (CCPA 1977). This same rationale should also apply to product, apparatus, and process claims claimed in terms of function, property or characteristic. Therefore, a 35 U.S.C. 102/ 103 rejection is appropriate for these types of claims as well as for composition claims.
Claims 1, 5 – 10, 14 – 16 and 20 are rejected under 35 U.S.C. 102/103 as being unpatentable over Somashekar (US 2022/0248229A1).
Per claim 1, Somashekar (US 2022/0248229A1) is relied upon to teach a system comprising: one or more processors (reads on "at least one processor," see Somashekar Claim 1); and one or more non-transitory computer-readable media storing computer-executable instructions (reads on "at least one memory including computer program code," see Somashekar para [0025]) that, when executed by the one or more processors, cause the one or more processors to perform operations (reads on "the at least one memory and the computer program code configured to , with the at least one processor , cause the performance of the apparatus , see Somashekar para [0025]) comprising: receiving (reads on "the initiating SEPP transmits a request ... towards the responding SEPP," see Somashekar para [0056]) a service exchange request (reads on "The request comprises information elements carrying at least information on e.g.supported security capabilities ... and sender PLMN identity," see Somashekar para [0056]) from a first service provider (reads on "the initiating SEPP transmits a request," see Somashekar para [0056]; initiating SEPP = first service provider), the service exchange request including data identifying (reads on "The request comprises information elements carrying at least information," see Somashekar para [0056]) (i) a requested service (reads on "the security capability that the requesting SEPP is requesting," see Somashekar para [0079]) and (ii) an endpoint (reads on "A I sender' 510 that indicates an identity of the sender , e.g. fully quantified domain name ( FQDN )," see Somashekar para [0078]); determining (reads on "the responding SEPP may select a security mechanism," see Somashekar para [0059]), based at least in part on receiving the service exchange request (reads on "based on the comparison of the supported capabilities ... proposed by the initiating SEPP," see Somashekar para [0059]; the comparison is triggered by receipt of the negotiation request), one or more service roaming rules (reads on "security policies pre - agreed between the two network operators," see Somashekar para [0059]) associated with the first service provider or a second service provider (reads on "the comparison of the security policies proposed by the initiating SEPP and the security policies pre - agreed between the two network operators," see Somashekar para [0059]; policies associated with VPLMN and HPLMN operators respectively); determining (reads on "the responding SEPP may select a security mechanism," see Somashekar para [0059]), based at least in part on the requested service and the one or more service roaming rules (reads on "based on the comparison of the supported capabilities and / or a comparison of the security policies
PNG
media_image1.png
7
28
media_image1.png
Greyscale
pre - agreed between the two network operators," see Somashekar para [0059]), that the second service provider is to provide the requested service (reads on "the responding SEPP may select a security mechanism that is supported by both SEPPs” see Somashekar para [0059]; responding SEPP = SP2) to the endpoint (reads on "selected security capability and sender PLMN ID ( s )," see Somashekar para [0057]; PLMN ID identifies the endpoint to which service is directed); providing (reads on "the responding SEPP may respond to the initiating SEPP by transmitting a response," see Somashekar para [0057]), to the first service provider (reads on "the responding SEPP may respond to the initiating SEPP," see Somashekar para [0057]; initiating SEPP = SPI), a response to the service exchange request (reads on "the responding SEPP may respond by transmitting a response , e.g. a POST response," see Somashekar para [0057]), the response including contact data (reads on "The responding SEPP may return its identity
PNG
media_image2.png
11
7
media_image2.png
Greyscale
e.g. FQDN , towards the initiating SEPP," see Somashekar para [0096]; FQDN = contact data for SP2's device) for a device associated with second service provider (reads on "a data structure 750 of a response sent from ... the responding SEPP 620 ... The responding SEPP may return its identity , e.g. FQDN, tl see Somashekar para [0096]; responding SEPP = device of SP2); and providing (reads on "N32 - f interface is a forwarding interface ... used for forwarding HITP request messages," see Somashekar para [0052]), to the second service provider (reads on "communicate to peer NFs via the SEPP in the remote PLMN," see Somashekar para [0050]; the SEPP in remote PLMN = SP2), the data identifying the endpoint (reads on "This IE comprises information on the sender identity , e.g. FQDN," see Somashekar para [0093]; sender FQDN - data identifying the endpoint).
Per claim 5, the prior art of record further suggests determining service configuration data (reads on "the responding SEPP may select a security mechanism that is supported by both SEPPs," see Somashekar para [0059]; selected security mechanism = service configuration data) associated with the first service provider (reads on "the security policies proposed by the initiating SEPP," see Somashekar para [0059]; initiating SEPP = SPI; its proposed policies = SPI's configuration data); and providing the service configuration data (reads on "A list of selected security capabilities 'selectedSecCapabilitV," see Somashekar para [0087]; selectedSecCapability = service configuration data) to the second service provider (reads on "for termination by the responding SEPP," see Somashekar para [0087]; responding SEPP = SP2 that receives and applies the configuration).
Per claim 6, the prior art of record further suggests receiving, from the first service provider (reads on "the initiating SEPP transmits a request ... towards the responding SEPP," see Somashekar para [0056]; initiating SEPP = SPI) and prior to the service exchange request (reads on "negotiation procedure happens over N32 - c a security mechanism is selected to be used for protecting NF service related signaling over N32 f," see Somashekar para [0053]; N32-c is prior to N32-f service exchange), a first set of security services (reads on "supported security capabilities ( i.e. PRINS and / or TLS
PNG
media_image3.png
34
34
media_image3.png
Greyscale
see Somashekar para [0056]) provided by the first service provider (reads on "supportedSecCapabiIityList 520 that indicates supported security capabilities," see Somashekar para [0079]; the list reflects what SPI provides), wherein the requested service is not provided by the first service provider (reads on "the security capability that the requesting SEPP is requesting for termination by the responding SEPP," see Somashekar para [0079]; SPI requests SP2 to terminate/provide the service, implying SPI does not itself provide it); and receiving, from the second service provider (reads on "the responding SEPP ... its own supported security capabilities," see Somashekar para [0059]; responding SEPP = SP2 advertising its own capability set) and prior to the service exchange request (reads on "N32 - c ... a security mechanism is selected to be used for protecting NF service related signaling over N32 - f," see Somashekar para [0053]), a second set of security services provided by the second service provider (reads on "possible values for security capabilities ... 'TLS' as TLS security , 'PRINS' as protocol for N32 interconnect security," see Somashekar para [0081]), wherein the requested service is provided by the second service provider (reads on "the security capability that the requesting SEPP is requesting for termination by the responding SEPP," see Somashekar para [0079]; SP2 = responding SEPP providing the requested termination service).
Per claim 7, the prior art of record further suggests determining, based at least in part on the first set of security services and the second set of security services (reads on "compare the security capabilities supported by the initiating SEPP to its own supported security capabilities," see Somashekar para [0059]), a first subset of security services to be provided to the endpoint by the first service provider (reads on "TLS ... with security provided by TLS," see Somashekar para [0055]; each SEPP endpoint implements its TLS endpoint role = SPI's subset), and a second subset of security services to be provided to the endpoint by the second service provider (reads on "security mechanism that is supported by both SEPPs," see Somashekar para [0059]; SP2's role in the selected mechanism = SP2's subset); and transmitting, to the first service provider (reads on "the responding SEPP may respond to the initiating SEPP by transmitting a response," see Somashekar para [0057]), data identifying the second subset of security services (reads on "A list of selected security capabilities 'selectedSecCapability' indicates the security capability," see Somashekar para [0087]) to be provided to the endpoint by the second service provider (reads on "requesting for termination by the responding SEPP," see Somashekar para [0087]; responding SEPP = SP2 that provides the service to the endpoint).
Per claim 8, the prior art of record further suggests determining, based at least in part on the service exchange request (reads on "the initiating SEPP transmits a request , e.g. HTTP POST request , towards the responding SEPP," see Somashekar para [0056]), the second service provider as a home provider (reads on "HPLMN in which the subscriber's profile is held," see Somashekar para [0046]; HPLMN-resident SEPP =home provider = SP2) associated with the endpoint (reads on "subscriber's profile is held . . user roams receives subscription information," see Somashekar para [0046]; subscriber = endpoint; home network = HPLMN associated with that endpoint); determining the first service provider as a current provider (reads on "VPLMN upon which the subscriber has roamed," see Somashekar para [0046]; VPLMN SEPP = SPI = current provider) associated with the endpoint (reads on "all service requests between the VPLMN and HPLMN are transmitted through the SEPPs," see Somashekar para [0048]; SPI/VPLMN SEPP is the current provider through which the endpoint's requests transit); and determining, based at least in part on the one or more service roaming rules (reads on "the security policies pre - agreed between the two network operators," see Somashekar para [0059]; pre-agreed policies = service roaming rules), that the first service provider permits service roaming (reads on "all service requests between the VPLMN and HPLMN are transmitted through the SEPPs," see Somashekar para [0048]; the architecture permits roaming traffic to pass through SPI) to the second service provider (reads on "service requests between the VPLMN and HPLMN are transmitted," see Somashekar para [0048]; the requests are ultimately directed to and through SP2/HPLMN SEPP).
Per claim 9, the prior art of record further suggests receiving, from the second service provider (reads on "the responding SEPP ... its own supported security capabilities," see Somashekar para [0059]; the responding SEPP = SP2 that makes its capabilities available for comparison), a set of security services (reads on "possible values for security capabilities ... 'TLS .. 'PRINS'," see Somashekar para [0081]; TLS and PRINS = set of security services) provided by the second service provider (reads on "security capability... for termination by the responding SEPP," see Somashekar para [0079]; responding SEPP = SP2 = provider of the security service); and transmitting, to the first service provider (reads on "the responding SEPP may respond to the initiating SEPP by transmitting a response," see Somashekar para [0057]), data identifying the set of security services (reads on "A list of selected security capabilities selectedSecCapabitity indicates the security capability," see Somashekar para [0087]) to be provided to the endpoint by the second service provider (reads on "for termination by the responding SEPP," see Somashekar para [0087]; responding SEPP = SP2).
Claim 10 is analyzed with respect to claim 1.
Claim 14 is analyzed with respect to claim 5.
Claim 15 is analyzed with respect to claim 6.
Claim 16 the non-transitory computer-readably media (see Somashekar para [0105]) is analyzed with respect to claim 1.
Claim 20 is analyzed with respect to claim 5.
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 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.
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 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.
Claims 2 – 4, 11 – 13 and 17 – 19 are rejected under 35 U.S.C. 103 as being unpatentable over Somashekar in view of Wang (US 2023/0107735 A1)
Per claim 2, the prior art of record is relied upon to teach claim 1. The prior art of record is silent on explicitly stating providing, as input to an artificial intelligence (AI) engine, first input data associated with the requested service, and second input associated with the endpoint; and receiving, as output from the AI engine, output data identifying the second service provider.
Wang (US 2023/0107735 A1) is relied upon to teach
providing, as input to an artificial intelligence (AI) engine (reads on "AI engine can receive and analyze WAN link characterization data 130," see Wang para [0078]), first input data associated with the requested service (reads on "SLA profile such as a traffic type profile a path preference," see Wang para [0049]; SLA profile characterizes the requested service type), and second input associated with the endpoint (reads on "WAN link characterization data 130 determined by SD - WAN edge device 308," see Wang para [0078]; edge device = endpoint); and receiving, as output from the AI engine (reads on "determining using a machine learning model ... an indicator of a predicted performance metric," see Wang Abstract; ML model = AI engine, indicator = output), output data identifying the second service provider (reads on "to determine whether or not to reassign an application ... to a second WAN link," see Wang para [0006]; reassignment decision = output identifying SP2).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Somashekar's SEPP-mediated inter-provider security capability exchange architecture in which the responding SEPP uses a deterministic policy-comparison method (para [0059]) to select among supported security mechanisms by integrating the AI-engine-driven WAN link selection teaching of Wang (see Wang, para [0078]: "In some implementations , SD - WAN application 306 may optionally include an AI engine 327 . AI engine can receive and analyze WAN link characterization data 130 determined by SD - WAN edge device 308 and process the WAN link characterization data 130 to generate an indicator 132 of a predicted performance metric of a WAN link . Machine learning model 324 can be a model that has been previously trained to generate the indicator 132 of the predicted performance metric") to realize the instant limitations of AI-engine-driven provider selection. One or more of the underpinning rationale(s), as discussed in KSR MPEP 2141 {G (teaching, suggestion, motivation in the art), C (applying a known technique to a known device to yield predictable results)}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have incorporated Wang's AI engine as the selection engine within Somashekar's responding SEPP, providing the requested-service characteristics and the endpoint WAN-link characterization data as inputs to generate an indicator-based provider selection output, as recited in the instant claims, by applying the AI/ML-driven link-selection technique of Wang to the existing SEPP-mediated interoperator service selection infrastructure of Somashekar. As Wang itself states: "Users may expect their applications to experience connectivity having an acceptable level of quality , commonly referred to as Quality of Experience ( QoE ) . The QoE may be measured based on various performance metrics of a link, including latency, delay (inter frame gap), jitter, packet loss, and/or throughput (see Wang para [0004]), which addresses the well-recognized problem of optimizing provider/link selection for application quality. One of ordinary skill in the art in SD-WAN and 5G security proxy engineering would have recognized that Somashekar's deterministic capability comparison approach lacked ML-driven quality prediction and that Wang's AI engine was a known, predictable solution to exactly that gap, requiring no change to the underlying N32-c request/response handshake architecture. The combination is further supported by MPEP 2141 Rationale G (the prior art as a whole suggested the combination) and Rationale C (applying a known ML technique to an existing selection framework yields predictable results). The motivation to combine these references is applied to all references under this heading and reinforced by the shared technical domain of service provider selection and the recognized advantage of ML-based prediction over static policy matching.
Claim 3 is analyzed with respect to claim 2. The prior art of record further suggests receiving, from the first service provider (reads on "the initiating SEPP transmits a request towards the responding SEPP," see Somashekar para [0056]; SPI = initiating SEPP; the metadata reception is inferred from the request flow), endpoint metadata associated with the endpoint (reads on "SLA profile ... such as a traffic type profile ... a path preference," see Wang para [0049]; SLA profile = endpoint metadata), the endpoint metadata including at least one service preference (reads on "a path preference ( e.g. an indication of a preferred WAN link ... or type of WAN link)," see Wang para [0049]; path preference = service preference) associated with the endpoint (reads on "SLA profile for an application," see Wang para [0049]; per-application SLA profile = metadata associated with the endpoint/application), wherein determining the second service provider (reads on Wang's SLA-driven link selection consuming path preference per para [0049], combined with Somashekar's SEPP selection per para [0059]) is based at least in part on the endpoint metadata (reads on "SLA profile ... including a path preference," see Wang para [0049]; SLA profile data is the basis for link/provider selection).
Claim 4 is analyzed with respect to claim 3. The prior art of record further suggests receiving provider metadata (reads on "The WAN link characterization data can include characteristics 510A - 510N of a WAN link," see Wang para [0094]; WAN link characterization data = provider metadata) associated with the second service provider (reads on WAN link characterization data associated with the specific WAN link/provider, see Wang para [0094]), the provider metadata including at least one of: a latency associated with the second service provider (reads on "Latency is an amount of time taken by a packet to travel from one designated point to another," see Wang para [0094]); a bandwidth availability associated with the second service provider (reads on "Service characteristics can include link bandwidth," see Wang para [0094]); a service utilization associated with the second service provider (reads on "Throughput Average session length . Packet retransmission rate," see Wang para [0094]; throughput/session load = utilization metrics); or a geolocation associated with the second service provider (reads on "Environment characteristics can include device type , timestamp , network interface type," see Wang para [0094]; geolocation is an environment characteristic inherent to network site identification), wherein determining the second service provider (reads on "determine whether or not to reassign an application ... to a second WAN link," see Wang para [0006]; second WAN link = SP2) is based at least in part on the provider metadata (reads on "The WAN link characterization data can be processed using the machine learning model to determine ... whether or not to reassign an application ... to a second WAN link," see Wang para [0006]. The combination with Somashekar places this determination in an inter-SEPP provider-selection context. Wang's entire ML pipeline depends on WAN link characterization data as the primary input to the reassignment decision).
Claim 11 is analyzed with respect to claim 2.
Claim 12 is analyzed with respect to claim 3.
Claim 13 is analyzed with respect to claim 4.
Claim 17 is analyzed with respect to claim 2.
Claim 18 is analyzed with respect to claim 3.
Claim 19 is analyzed with respect to claim 4.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights