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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
1. Claims 1, 9-12, 14-15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Cafarelli et al (2014/0321278) in view Cañete Martinez et al (2022/0353336) or Blicker (2006/0195898) further in view of Mehta et al (2013/007237).
Regarding claims 1, 11 and 12. Cafarelli teaches a program, node (figure 3 – base station) and a method of data processing in a node constituting a core network, the core network including a first facility (figure 3 -SGSN) and a second facility (figure 3 – GGSN) configured to be capable of receiving data from an loT device through communication on a U-plane from the first facility and transmitting the data to an IP network (figure 3 – PDN), the method comprising:
determining, by the node, whether a program specified by a user and associated with subscriber identification information stored in the loT device is psession identifier indicating a session on the U-plane (0125 – GPT-U TEID, 0128 – the Gn interface (a network interface between the SGSN and GGSN) contains GTP-C and GTP-U protocols between the SGSN and GGSN … the SGSN and GGSN packet data are correlated and processed accordingly by the GTP correlation element … the GTP-C is used to communicate control to register user data sessions between the SGSN and GGSN. The GTP-C contains IMSI and IMEI to identify the subscriber device and identifies the GTP-U tunnel ID allocated for the data session to be used for the subscriber traffic carried to the GGSN, 0136 – the network switch may be configured to correlate GTP-c sessions to the corresponding tunnels in the user-plane, and to ensure that the tunnels associated with the subscriber (e.g., identified by IMSI, IMEI, MSISDN, APN info, etc.) are assigned to a certain port), 0147 – the serving gateway receives packets from the eNodeB devices and then sends appropriate subscriber traffic to the PDN gateway over the S5/S8 interfaces using GTP-U. The PDN gateway receives traffic from the S-GW and sends it to the internet using the SGi interface. Packets returned from the Internet devices are sent by the PDN-gateway to the appropriate SGW which forwards to the eNodeB which ultimately sends to the UE); and
(0125 – this tunnel-ID may subsequently be used for all future data communication relative to the session, 0147 – the serving gateway receives packets from the eNodeB devices and then sends appropriate subscriber traffic to the PDN gateway over the S5/S8 interfaces using GTP-U. The PDN gateway receives traffic from the S-GW and sends it to the internet using the SGi interface. Packets returned from the Internet devices are sent by the PDN-gateway to the appropriate SGW which forwards to the eNodeB which ultimately sends to the UE),
Cafarelli does not teach determining, by the node, whether a program associated with subscriber identification information stored in the loT device is present based on a session identifier included in a header of and when the program specified by the user associated with the , executing, by the node, the program to process the data
Cañete Martinez teaches embodiments related generally to a User Plane Function (UPF) (0001, 0032) wherein a node receives, from the UE, a request to establish a connection to a packet data network (figure 4, step 401, 0067, Table 16, Table 17, 0133-0134 – user selects FACEBOOK and/or Instagram and/or other social network program(s) to be activated) wherein the request includes at least one indication for profile activation … F-TEID, UE IP address and remote F-TEID. F-TEID is short for Fully-Qualified Tunnel Endpoint Identifier) (0088, Table 3, Table 4, Table 5, Table 10, see claim 44 – indication for profile activation comprises a Fully Qualified-Tunnel Endpoint Identifier (F-TEID)) wherein the F-TEID is encoded in a header (0090-0095, 0108, Table 11) and the TEID and UE ID need to be matched (0110-0111, Table 16 and Table 17 – wherein program/application ID, TEID, and UE ID are mapped) before the node activates the profile associated with the UE (figure 4, step 402, 0068-0069, 0139, Table 17) wherein the profile(s), as requested by the user (Table 12 list user selected profiles: “Facebook” matched to F-TEID 1, “Instagram” matched to F-TEID 2).
Blicker also teaches mapping TEID to SIM information (0013-0019) which enables the network to check matching TEID and SIM information (0020 – If pairs are not matching, the subscriber (e.g., User) used an incorrect IP address, if the pairs are matching the subsequent step is performed, 0021-0023 – If the pairs are not matching the subscriber used incorrect signaling information. If the pairs are matching, the session setup can be considered as authenticated).
It would have been obvious for one of ordinary skill in the art before the effective filing date of th claimed invention to modify Cafarelli to map TEID, application ID(s) and UE Identification information as taught by Cañete Martinez or to map TEID to SIM information as taught by Blicker thereby enabling the network to validate and enforce rules for the User selected profiles/programs before activation (Cañete Martinez at 0001, 0032) or to prevent falsification of source addresses (e.g., prevent IP spoofing – Blicker at 0013).
Regarding RCE 12/1/2025. Applicant amends and argues prior art does not teach when the program specified by the user and associated with the subscriber information to process a payload of the data transmitted through the session and transmitting, by the node, data including a payload obtained by causing the program specified by the user and associated with the subscriber identification information to process the payload of the data transmitted through the session.
Mehta teaches user selects a service (e.g. program specified by the user) such as VoIP, IPTV, SMS, WAP, or customer-specific application services (0016) and associated with IMSI, TMSI, IMEI (e.g., subscriber identification information) (0023) and may further include an access point name and may in some instances further identify a requested service (e.g., internet, WAP, MMS) (0035) and the payload further includes TEID (0038). For example, the user sends a request for service wherein the payload includes IMSI, APN, TEID (figure 3, figure 4) and the payload is processed (see figure 4) to determine/look up the IMSI to services mapping (see figure 4, 0045 – the payload located on the left side is processed to determine if the IMSI (e.g. subscriber identification information) is mapped to service(s) (e.g., program requested by the user), such as Internet, VoIP, SMS, WAP and/or customer-specific application service. If there is a match then process the payload to forward through the network to service the user’s request (0046-0047).
It would have been extremely obvious for one of ordinary skill in the art before the effective filing date to modify Cafarelli in view of Cañete Martinez OR Blicker to include IMSI and the service selected by the user in the payload as taught by Mehta in order to enable the system to manage multiple sessions that are mapped to an IMSI (e.g., subscriber identification information) (Mehta at 0045).
Regarding claim 9. Cafarelli teaches wherein the first facility (figure 3 – SGSN) communicates with a base station (figure 3 – wherein SGSN communicates with base stations).
Regarding claim 10. Cafarelli teaches wherein the session identifier is a TEID (0124-0125).
Cañete Martinez teaches embodiments related generally to a User Plane Function (UPF) (0001, 0032) wherein a node receives, from the UE, a request to establish a connection to a packet data network (figure 4, step 401, 0067, Table 16, Table 17, 0133-0134 – user selects FACEBOOK and/or Instagram and/or other social network program(s) to be activated) wherein the request includes at least one indication for profile activation … F-TEID, UE IP address and remote F-TEID. F-TEID is short for Fully-Qualified Tunnel Endpoint Identifier) (0088, Table 3, Table 4, Table 5, Table 10, see claim 44 – indication for profile activation comprises a Fully Qualified-Tunnel Endpoint Identifier (F-TEID)) wherein the F-TEID is encoded in a header (0090-0095, 0108, Table 11) and the TEID and UE ID need to be matched (0110-0111, Table 16 and Table 17 – wherein program/application ID, TEID, and UE ID are mapped) before the node activates the profile associated with the UE (figure 4, step 402, 0068-0069, 0139, Table 17) wherein the profile(s), as requested by the user (Table 12 list user selected profiles: “Facebook” matched to F-TEID 1, “Instagram” matched to F-TEID 2).
Blicker also teaches mapping TEID to SIM information (0013-0019) which enables the network to check matching TEID and SIM information (0020 – If pairs are not matching, the subscriber (e.g., User) used an incorrect IP address, if the pairs are matching the subsequent step is performed, 0021-0023 – If the pairs are not matching the subscriber used incorrect signaling information. If the pairs are matching, the session setup can be considered as authenticated).
Regarding claim 14. Cafarelli teaches receiving, by the node, the data from the loT device (0123-0125, figure 3 – base station receives data from subscriber devices to connect to the Internet (0096, 0123, 0147)).
Cañete Martinez teaches embodiments related generally to a User Plane Function (UPF) (0001, 0032) wherein a node receives, from the UE, a request to establish a connection to a packet data network (figure 4, step 401, 0067, Table 16, Table 17, 0133-0134 – user selects FACEBOOK and/or Instagram and/or other social network program(s) to be activated) wherein the request includes at least one indication for profile activation … F-TEID, UE IP address and remote F-TEID. F-TEID is short for Fully-Qualified Tunnel Endpoint Identifier) (0088, Table 3, Table 4, Table 5, Table 10, see claims 44 and 52 – indication for profile activation comprises a Fully Qualified-Tunnel Endpoint Identifier (F-TEID)) wherein the F-TEID is encoded in a header (0090-0095, 0108, Table 11) and the TEID and UE ID need to be matched (0110-0111, Table 16 and Table 17 – wherein program/application ID, TEID, and UE ID are mapped) before the node activates the profile associated with the UE (figure 4, step 402, 0068-0069, 0139, Table 17) wherein the profile(s), as requested by the user (Table 12 list user selected profiles: “Facebook” matched to F-TEID 1, “Instagram” matched to F-TEID 2).
Blicker teaches IP multimedia Subsystem (IMS) end device which includes the use of IMS SIM (0002, 0003 – IP multimedia end devices using SIM cards, 0007 – using standard SIM card, 0012 – devices SIM card, 0024 – subscribers are migrated to ISIM enabled devices, 0026 – ISIM enable device, 0041 – ISIM (e.g., IMS SIM), 0045 – SIM card, 0049 – UICC (e.g, UMTS IC card)).
Regarding claim 15. Cafarelli teaches wherein the subscriber identification information is stored in a physical Subscriber Identity Module (SIM) card installed in the loT device, is stored in a semiconductor chip embedded in the loT device, or is included in software stored in the loT device (0114, 0125).
Blicker teaches wherein the subscriber identification information is stored in a physical Subscriber Identity Module (SIM) card installed in the loT device, is stored in a semiconductor chip embedded in the loT device, or is included in software stored in the loT device (0002, 0003 – IP multimedia end devices using SIM cards, 0007 – using standard SIM card, 0012 – devices SIM card, 0024 – subscribers are migrated to ISIM enabled devices, 0026 – ISIM enable device, 0041 – ISIM (e.g., IMS SIM), 0045 – SIM card, 0049 – UICC (e.g, UMTS IC card)).
Regarding claim 17. Cafarelli in view of Cañete Martinez or Blicker do not explicitly teach wherein the data including the payload obtained by causing the program specified by the user and associated with the subscriber identification information to process the payload of the data transmitted through the session is transmitted from the core network to the IP network.
Mehta further teaches wherein the data including the payload obtained by causing the program specified by the user and associated with the subscriber identification information to process the payload of the data transmitted through the session is transmitted from the core network to the IP network (see figure 1 wherein user specifies a program and associated with subscriber information (see below) to process the payload of the data transmitted through the session is transmitted from the core network (e.g., figure 1 - content access network 4 and/or Mobile gateway 8) to the IP network (e.g., figure 1 – Packet Data Network 12).
Mehta teaches user selects a service (e.g. program specified by the user) such as VoIP, IPTV, SMS, WAP, or customer-specific application services (0016) and associated with IMSI, TMSI, IMEI (e.g., subscriber identification information) (0023) and may further include an access point name and may in some instances further identify a requested service (e.g., internet, WAP, MMS) (0035) and the payload further includes TEID (0038). For example, the user sends a request for service wherein the payload includes IMSI, APN, TEID (figure 3, figure 4) and the payload is processed (see figure 4) to determine/look up the IMSI to services mapping (see figure 4, 0045 – the payload located on the left side is processed to determine if the IMSI (e.g. subscriber identification information) is mapped to service(s) (e.g., program requested by the user), such as Internet, VoIP, SMS, WAP and/or customer-specific application service. If there is a match then process the payload to forward through the network to service the user’s request (0046-0047).
It would have been extremely obvious for one of ordinary skill in the art before the effective filing date to modify Cafarelli in view of Cañete Martinez OR Blicker to include IMSI and the service selected by the user in the payload as taught by Mehta in order to enable the system to manage multiple sessions that are mapped to an IMSI (e.g., subscriber identification information) (Mehta at 0045).
2. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Cafarelli et al (2014/0321278) in view Cañete Martinez et al (2022/0353336) or Blicker (2006/0195898) and Mehta further in view of Syed (2017/0366969).
Regarding claim 2. Cafarelli teaches wherein the processing which is allowed to be executed includes: arithmetic processing using a computing resource of the node (0099 – in some embodiments, the configuring of the managed packet switch may be performed by utilizing a CPU interface of the switch to modify appropriate registers in the switch to allow for the desired operation).
Cafarelli in view Cañete Martinez or Blicker and Mehta do not teach an API that is pre-authorized in association with the
Syed teaches the API located at the network side (figure 1, item 152) that is pre-authorized in association with the SIM (0028 – the IoT device uses API interface to transmit IMEI and SIM information, along with other information to the API 152 of the network node, which authorizes the subscriber and activates the IoT device to the subscriber’s plan, 0045). The API interface may also be used to determine if the IoT device is stolen (0033)
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify Cafarelli in view Cañete Martinez or Blicker and Mehta to include API interfaces as taught by Syed which enables the network to authorize the subscriber, as well as, activation of the IoT device to the subscriber’s plan.
3. Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Cafarelli in view Cañete Martinez or Blicker, Mehta and Syed further in view of Kodaypak (2017/0347283).
Regarding claim 3. Cafarelli in view of Cañete Martinez or Blicker, Mehta and Syed do not explicitly teach wherein the API that is pre-authorized includes an API that performs protocol conversion on a transport layer or an application layer of the data.
Kodaypak teaches at figure 1 and [0032] According to an embodiment, the PAW component 108 provides an intelligent wrapping function that can wrap application layer protocols associated with dedicated signaling interfaces to a standardized set of APIs that can be interfaced with the external AS(s) 106 to be able to gain easy access to the communication network. Moreover, the PAW component 108 can present any interface implemented by the network to the external AS(s) 106 as a unique and reconfigurable API. As an example, the external AS(s) 106, by employing the flexible APIs exposed via the PAW component 108, can communicate with their targeted IoT devices via specific network elements to extract critical device and/or network capabilities on an event basis. As an example, the extracted information can be utilized by the AS(s) 106 to deliver new services to such IoT devices on demand. Moreover, the PAW component 108 can perform protocol to API conversion monitoring operations that help in effective routing of the bidirectional traffic between a targeted network element (e.g., control plane entity 104) and service providers (e.g., AS 106) to gain access to the digitized information associated with desired set of IoT devices. [0036] The number of APIs that are to be generated against each of the network elements (e.g., MME/SGSN 202, HSS 204, BMSC 206, MTC-IWF 208, etc.) with unique application layer protocols for dedicated signaling interfaces along with their supported mandatory and optionally configurable information elements is substantially large, and the resulting protocol conversion per network element per interface makes the SCEF 102 a critical network element in the IoT/MTC network architecture. As each network element and its pooled configuration interfaces with a common SCEF entity, the mobility network has a huge dependency on the SCEF 102. In an embodiment, the SCEF 102 employs (e.g., by utilizing the PAW component 108) efficient protocol conversion schemes to expose these interfaces via generic and reconfigurable APIs in a protocol-independent manner to AS 1-AS M 210.sub.1-210.sub.M.
It would have been obvious for one of ordinary skill in the art before the effective filing date of th claimed invention to modify Cafarelli in view of Cañete Martinez or Blicker, Mehta and Syed to use the intelligent wrapping function as taught by Kodaypak thereby enabling service providers the ability to globally connect to their targeted IoT devices and provide new services thereto (Kodaypak – abstract).
Regarding claim 4. Cafarelli in view of Cañete Martinez or Blicker, Mehta and Syed do not teach wherein the API that is pre-authorized includes at least one of: an API that changes a payload of the data, or a transmission destination of the data that has been modified, when a predetermined condition is satisfied; an API that discards a payload of the data, or the data that has been modified, when a predetermined condition is satisfied; or an API that transmits, to the loT device, the data for which a payload has been modified, when a predetermined condition is satisfied.
Kodaypak teaches at figure 1 and [0032] According to an embodiment, the PAW component 108 provides an intelligent wrapping function that can wrap application layer protocols associated with dedicated signaling interfaces to a standardized set of APIs that can be interfaced with the external AS(s) 106 to be able to gain easy access to the communication network. Moreover, the PAW component 108 can present any interface implemented by the network to the external AS(s) 106 as a unique and reconfigurable API. As an example, the external AS(s) 106, by employing the flexible APIs exposed via the PAW component 108, can communicate with their targeted IoT devices via specific network elements to extract critical device and/or network capabilities on an event basis. As an example, the extracted information can be utilized by the AS(s) 106 to deliver new services to such IoT devices on demand. Moreover, the PAW component 108 can perform protocol to API conversion monitoring operations that help in effective routing of the bidirectional traffic between a targeted network element (e.g., control plane entity 104) and service providers (e.g., AS 106) to gain access to the digitized information associated with desired set of IoT devices. [0036] The number of APIs that are to be generated against each of the network elements (e.g., MME/SGSN 202, HSS 204, BMSC 206, MTC-IWF 208, etc.) with unique application layer protocols for dedicated signaling interfaces along with their supported mandatory and optionally configurable information elements is substantially large, and the resulting protocol conversion per network element per interface makes the SCEF 102 a critical network element in the IoT/MTC network architecture. As each network element and its pooled configuration interfaces with a common SCEF entity, the mobility network has a huge dependency on the SCEF 102. In an embodiment, the SCEF 102 employs (e.g., by utilizing the PAW component 108) efficient protocol conversion schemes to expose these interfaces via generic and reconfigurable APIs in a protocol-independent manner to AS 1-AS M 210.sub.1-210.sub.M.
Kodaypak further teaches or an API that transmits, to the loT device, the data for which a payload has been modified, when a predetermined condition is satisfied (0049 – on demand API … the application provider in turn can use these APIs to be able to perform on demand triggers for a desired set of IoT devices in a given geographic region, as well as, event based configuration, reporting, status monitoring, deletion, new services rollout with an existing device, and/or launch of new devices in specific locations, 0053 – provide event based services to external providers, supporting global IoT roaming, dynamic network reconfiguration, intelligent application layer protocol conversion and securely expose a configurable set of APIs to third party providers, dynamic routing of the APIs to minimize network failure conditions, etc.).
It would have been obvious for one of ordinary skill in the art before the effective filing date of th claimed invention to modify Cafarelli in view of Cañete Martinez or Blicker, Mehta and Syed to use on demand API(s) as taught by Kodaypak thereby enabling service providers the ability to globally connect to their targeted IoT devices and provide new services thereto (Kodaypak – abstract), provide on demand triggers, event based configuration, reporting (Kodaypak – 0049), support global roaming, dynamic network reconfiguration, intelligent application layer protocol conversion, dynamic routing of the API(s) to minimize network failure conditions (Kodaypak – 0053).
4. Claims 5, 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Cafarelli in view Cañete Martinez or Blicker, Mehta and Syed further in view of Dao et al (2018/0097657)
Regarding claim 5. Cafarelli in view Cañete Martinez or Blicker, Mehta and Syed do not teach wherein
Dao teaches wherein the data that is allowed to be input includes data received from the IoT device (0129 – 0134 wherein information included in the attach request) and verified/authenticated with user database (0132, 0135-0136 – for example, in case of IoT devices, the session request can be a request for infrequent data transmission. If the user subscription includes an appropriate service supporting infrequent data transmission, the UE will be authorized to use this server, 0151-0155 – authorized or not authorized, 0206 – error indication).
It would have been obvious for one of ordinary skill in the art before the effective filing date of th claimed invention to modify Cafarelli in view of Cañete Martinez or Blicker, Mehta and Syed to include the user database information as taught by Dao thereby enabling the network to verify the user requested session request based upon the user database information.
Regarding claim 6. Cafarelli in view Cañete Martinez or Blicker, Mehta and Syed do not teach wherein the data associated with the
Dao teaches wherein the data that is allowed to be input includes data received from the IoT device (0129 – 0134 wherein information included in the attach request) and verified/authenticated with user database (0132 – UE ID, IMSI, GUTI, UE session ID, UE device type, list of destination PDN and list of UL and DL node-level tunnel pairs associated with the PDNs, QoS information, 0135-0136 – for example, in case of IoT devices, the session request can be a request for infrequent data transmission. If the user subscription includes an appropriate service supporting infrequent data transmission, the UE will be authorized to use this server, 0151-0155 – authorized or not authorized, 0206 – error indication).
It would have been obvious for one of ordinary skill in the art before the effective filing date of th claimed invention to modify Cafarelli in view of Cañete Martinez or Blicker, Mehta and Syed to include the user database information as taught by Dao thereby enabling the network to verify the user requested session request based upon the user database information.
Regarding claim 16. Cafarelli in view Cañete Martinez or Blicker, Mehta and Syed do not teach wherein the data that is allowed to be input is restricted in the program.
Dao teaches wherein the data that is allowed to be input includes data received from the IoT device (0129 – 0134 wherein information included in the attach request) and verified/authenticated with user database (0132 – UE ID, IMSI, GUTI, UE session ID, UE device type, list of destination PDN and list of UL and DL node-level tunnel pairs associated with the PDNs, QoS information, 0135-0136 – for example, in case of IoT devices, the session request can be a request for infrequent data transmission. If the user subscription includes an appropriate service supporting infrequent data transmission, the UE will be authorized to use this server, 0151-0155 – authorized or not authorized, 0206 – error indication).
It would have been obvious for one of ordinary skill in the art before the effective filing date of th claimed invention to modify Cafarelli in view of Cañete Martinez or Blicker, Mehta and Syed to include the user database information as taught by Dao thereby enabling the network to verify the user requested session request based upon the user database information.
5. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Cafarelli in view Cañete Martinez or Blicker and Mehta further in view of Xu et al (2019/0110324).
Regarding claim 7. Cafarelli in view Cañete Martinez or Blicker and Mehta do not explicitly teach the first instance receives the data and the second instance causes the program to process the data.
However, Cafarelli teaches wherein the node has a first instance (figure 3 - SGSN) and a second instance (figure 3 – GGSN) on a public cloud, the receiving is performed by the first instance (figure 3 – GGSN receives information from the eNodeB), and the executing of the program is performed by the second instance (figure 3, GGSN – executes via program to connect to the internet, 0125 – GPT-U TEID, 0128 – the Gn interface (a network interface between the SGSN and GGSN) contains GTP-C and GTP-U protocols between the SGSN and GGSN … the SGSN and GGSN packet data are correlated and processed accordingly by the GTP correlation element … the GTP-C is used to communicate control to register user data sessions between the SGSN and GGSN. The GTP-C contains IMSI and IMEI to identify the subscriber device and identifies the GTP-U tunnel ID allocated for the data session to be used for the subscriber traffic carried to the GGSN, 0136 – the network switch may be configured to correlate GTP-c sessions to the corresponding tunnels in the user-plane, and to ensure that the tunnels associated with the subscriber (e.g., identified by IMSI, IMEI, MSISDN, APN info, etc.) are assigned to a certain port), 0147 – the serving gateway receives packets from the eNodeB devices and then sends appropriate subscriber traffic to the PDN gateway over the S5/S8 interfaces using GTP-U. The PDN gateway receives traffic from the S-GW and sends it to the internet using the SGi interface. Packets returned from the Internet devices are sent by the PDN-gateway to the appropriate SGW which forwards to the eNodeB which ultimately sends to the UE).
Xu teaches control plane and user plane and a tunneling protocol switch providing IP address manipulation to hide the topology of distributed control plane and user plane traffic. The tunneling switch also implements dynamic node selection to route the control signaling and user plane traffic to different instances, hosted on separate servers, thus enabling the higher flexibility in network routing path optimization and scalable and elastic handling of the user plane traffic (abstract, 0030, 0033-0037).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify Cafarelli in view Cañete Martinez or Blicker and Mehta to include a tunneling protocol switch as taught by Xu in order to implement dynamic node selection to route the control signaling and user plane traffic to different instances, hosted on separate servers, thus enabling the higher flexibility in network routing path optimization and scalable and elastic handling of the user plane traffic.
6. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Cafarelli in view Cañete Martinez or Blicker, Mehta and Xu et al further in view of Chang et al (2016/0119870).
Regarding claim 8. Cafarelli in view Cañete Martinez or Blicker, Mehta and Xu do not teach wherein the processing which is allowed to be executed is restricted to a predetermined range of a computing resource of the second instance that is allowed to be used.
Chang teaches using middleware to allow and/or restrict API to communicate with the kernel and to exchange data therewith. Additionally, in connection with task requests received from the application, the middleware may perform a control (e.g., scheduling or load balancing) for the task requests by, for example, assigning at least one application a priority for using system resources (e.g., the bus, the control unit, or the input) (0100).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify Cafarelli in view Cañete Martinez or Blicker, Mehta and Xu to include the middleware as taught by Chang in order to perform a control based on system resources (e.g., the bus, CPU usage, etc.).
7. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Cafarelli in view Cañete Martinez or Blicker and Mehta further in view of Chang et al (2016/0119870).
Regarding claims 13. Cafarelli in view Cañete Martinez or Blicker and Mehta do not teach wherein processing, which is allowed to be executed by the program, is restricted.
Chang teaches using middleware to allow and/or restrict API to communicate with the kernel and to exchange data therewith. Additionally, in connection with task requests received from the application, the middleware may perform a control (e.g., scheduling or load balancing) for the task requests by, for example, assigning at least one application a priority for using system resources (e.g., the bus, the control unit, or the input) (0100).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify Cafarelli in view Cañete Martinez or Blicker and Mehta to include the middleware as taught by Chang in order to perform a control based on system resources (e.g., the bus, CPU usage, etc.).
Response to Arguments
8. Applicant’s arguments with respect to claims 1-17 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
9. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
---(2019/0364492) Azizi et al teaches when the program specified by the user and associated with the subscriber information to process a payload of the data transmitted through the session and transmitting, by the node, data including a payload obtained by causing the program specified by the user and associated with the subscriber identification information to process the payload of the data transmitted through the session (figure 146, paragraph 1363).
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BARRY W TAYLOR whose telephone number is (571)272-7509. The examiner can normally be reached Monday-Thursday: 7-5.
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, Matthew Anderson can be reached at 571-272-4177. 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.
/BARRY W TAYLOR/Primary Examiner, Art Unit 2646