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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/9/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claims Status
Claims 1-15 are pending
Claims 1-6, 12 and 14 are rejected.
Claims 7-11, 13 and 15 are allowed.
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.
Claims 1 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2016/0373520) in view of Laicher (US 2016/0306719).
Kumar teaches a method for providing node level redundancy for session data (Kumar para: 22-26 and 37-41 disclose session data redun
dancy and migration between servers, including backup data and failover when a server becomes unavailable. Kumar states that servers store session data, that backup data includes a backup of session data, and that a failure of a server can be addressed by transferring the session to another server.
A short message service function (SMSF) cluster including plurality of SMSF nodes on a primary site with a service communication proxy (Kumar para 18-21, 23-24, 32-36, and 56-57 disclose a cluster-like arrangement of multiple servers in a data center with a load balancer acting as a reverse proxy and selecting among plural servers to service requests.
Redirecting, by the SCP, the session data to other SMSF node from the plurality of SMSF nodes, on detecting one of the plurality of SMSF nodes fails/downs (Kumar para 29-31, 41, 49-52, 56-57 disclose redirecting requests to another server when one server becomes unavailable, including transferring the session and updating the server information so traffic is directed to the new server. Kumar fails to specifically triggering, by the SMSF, a disaster recovery (DR) site, on detecting all the SMSF nodes fail/down” but Laicher teaches a disaster recovery secondary data center/site that is used when the primary site fails and the secondary site takes over business operations including that, after disaster recovery failover, customer access is switched to the secondary site (Laicher para 25-26, 29-31, 48-49 and 77-80).
Kumar does however disclose routing, by the SCP, the session data to the DR site and further teaches when the SMSF cluster is restarted and ready to accept the session data and sending a command line interface (CLI) command from the SMSF to the SCP to shift back the session data to primary site (Kumar para 31, 41-42 and 57-58 disclose the load balancer updates the destination server for the session and directs traffic accordingly after failover.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to extend Kumar’s failover framework to a site-level DR failover when the entire primary cluster becomes unavailable, as taught by Laicher’s disaster recovery architecture.
Regarding claim 3, Kumar teaches enabling, by the SMSF, load distribution of messages by the SCP on plurality of SMSF blades (Kumar para 20 and 58 disclose load balancer 114 acts a reverse proxy, selects among the plurality of servers based on load and forwards service requests to the selected server. Further showing migrating sessions so the load balancer can redirect traffic between the servers to maintain balanced loads.)
Claims 2, 6, 12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2016/0373520) in view of Laicher (US 2016/0306719) and further in view of Assali et al (US 10,778,527).
Regarding claim 2, Kumar and Laicher fail to disclose the limitation of integrating, by the SMSF, with a plurality of network functions using HTTP/2-based interfaces both directly as well as via the SCP.
However, Assali teaches a service proxy function in a telecommunications network core using a service-based architecture, where the network functions communicate using HTTP/2 as the service-based application layer protocol. Assali further teaches service proxy workers deployed alongside network function instances, acting as a default outbound proxy, and routing telecommunications network core messages between network functions (Assali col. 4, lines 1-9 and 21-29, col. 5 line 60- col, 6, line 5 and col 6, lines 29-37).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Assali’s proxy with Kumar’s existing network to improve resiliency and scalability of SMSF communications with network functions, including direct and proxy-mediated interfaces.
Regarding claim 6, Kumar and Laicher fail to disclose the SCP being configured to distribute the session data using a round robin algorithm for redundancy.
However Assali teaches a service proxy function 102 that provides improved load balancing across available network functions, has a complete view of messages for a given type of network function, and expressly supports round robin and weighted round robin as load balancing techniques based on current load and network function availability (Assali col 5, lines 35-42).
Assali’s teaches shows that the service proxy is not merely forwarding traffic, but is actively distributing sessions among available network functions in a manner that accounts for network function availability. That is the same technical architecture used to provide resiliency in a service proxy environment, because distributing traffic across multiple available network functions allows the proxy to continue operation when one network function becomes unavailable, while balancing among the remaining instances. In this way, Assali’s load-balancing proxy supports failure handling, rerouting, and continued service availability, which are the practical benefits of using a round robin distribution scheme in a redundant network configuration.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Assali to configure Kumar’s SCP to distribute session data using a round robin algorithm in order to obtain the load balancing and resiliency benefits taught by Assali in a network environment with multiple available network functions.
Regarding claims 12 and 14, Kumar teaches a method for providing node level redundancy for session data, including servers that store session data and a failover arrangement in which session information is transferred when a server becomes unavailable. Kumar discloses a clustered server environment in which traffic is distributed among plural servers, and where session data can be migrated or redirected to maintain service continuity when one server fails. Kumar further teaches a load balancer and reverse proxy arrangement that selects among multiple servers and updates traffic routing when the active server changes (Kumar para. 0018-0021, 0023-0024, 0029-0031, 0037-0041, 0049-0052 and 0056-0058).
However, Kumar does not specifically teach the SCP configured to distribute the session data using a round robin algorithm and when the SMSF cluster is restarted and ready to accept the session data, the SMSF configured to send a command line interface (CLI) command to the SCP to shift back the session data to primary site. Kumar teaches failover and session migration generally, but does not expressly disclose round robin as the distribution algorithm for the SCP or the specific CLI-based shift-back operation.
Laicher discloses a disaster recovery (DR) site that is activated when a primary site fails, and teaches switching operations to a secondary site to maintain continuity of service. Laicher therefore teaches the SMSF is configured to trigger a disaster recovery (DR) site, on detecting all the SMSF nodes fail/down and the SCP configured to route the session data to the DR site (Laicher para 0025-0026, 0029-0031, 0048-0049 and 0077-0080).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to extend Kumar’s failover framework to a site-level DR failover when the entire primary cluster becomes unavailable, as taught by Laicher’s disaster recovery architecture.
Kumar and Laicher fail to teach the SCP configured to distribute the session data using a round robin algorithm and when the SMSF cluster is restarted and ready to accept the session data, the SMSF configured to send a command line interface (CLI) command to the SCP to shift back the session data to primary site. While Kumar teaches generic load balancing and failover, and Laicher teaches DR site failover, neither reference discloses the specific use of round robin for the SCP’s distribution of session data, nor the specific CLI command used to shift traffic back to the primary site after restart.
Assali teaches a service proxy function that provides improved load balancing across available network functions and expressly supports round robin as a load balancing technique based on current load and network function availability. Therefore, Assali teaches the SCP configured to distribute the session data using a round robin algorithm (Assali col. 5, lines 35-42).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Assali to configure Kumar’s SCP to distribute session data using a round robin algorithm in order to obtain the load balancing and resiliency benefits taught by Assali in a network environment with multiple available network functions.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2016/0373520) in view of Laicher (US 2016/0306719) and further in view of Hua et al (US 2020/0204962).
Regarding claim 4, Kumar and Laicher fail to disclose the limitation of providing, by the SMSF, a mobile application part (MAP) connectivity via a mobile application part gateway (MAPGW) component.
Hua teaches a 5G/legacy SMS interworking architecture in which SMSF 220 manages SMS over NAS, and an intermediary gateway function routes messages between the 5G core and legacy EPS SMS elements. Hua further teaches that the legacy side may use MAP signaling, including that HSS/UDM 240 may communicate with SMSC 230 via a Mobile Application Part (MAP) or DIAMETER protocol interface (Hua para 0012-0015, 0029-0030, 0042-0043, 0052 and 0053).
Hua teaches that current network standards do not adequately specify routing for MT SMS over NAS in mixed 5G and legacy environments, and that the disclosed approach minimizes new 5G-core enhancements, avoids disruptive changes, speeds up and smooths support, and improves efficiency by reducing unnecessary queries. Hua also describes the intermediary as a way to let 5G and legacy SMS systems interwork without requiring the 5G core to directly implement all legacy signaling details.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar and Laicher in view of Hua to and SMSF with MAP connectivity through a gateway-type intermediary because it preserves compatibility with existing infrastructure while reducing implementation disruption and supporting more efficient routing in a mixed-core network as suggested by Hua.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2016/0373520) in view of Laicher (US 2016/0306719) and further in view of Avetoom et al (US 2022/0038869).
Regarding claim 5, Kumar and Laicher fail to disclose offering, by the SMSF, services to an access management function (AMF) via a NSMSF service-based interface.
However, Avetoom teaches a 5G service-based architecture in which AMF 102 communicates with SMSF 132 via the Nsmsf service based interface, and where the SMSF supports services to the AMF, including authorization, activation, deactivation, and update functions for SMS service (Avetoom para 0021-0025, Avetoom also explains that traditional access to SMS-related user data can be technically burdensome, time consuming, and computationally inefficient, and that the disclosed approach improves efficiency by allowing the AMF to interact with the SMSF through a service-based interface rather than relying on more manual or cumbersome access workflows (Avetoom para 0002, 0017-0020 and 0041).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar and Laicher with Avetoom to have the SMSF provide services to the AMF through a service-based Nsmsf interface, as this would provide a more efficient and streamlined mechanism for AMF-to-SMSF interaction in a 5G SBA environment.
Allowable Subject Matter
Claims 7-11, 13 and 15 are allowed.
Claim 7 recites a very specific database redundancy for traffic routing architecture in which the SMSF cluster contains a plurality of DB nodes on a primary site with a service communication proxy (SCP), and where the plurality of DB nodes includes a plurality of pairs of master DB node and slave DB node and an additional slave DB node. The claim further requires that the SCP is configured to distribute the traffic using a round robin algorithm, that the SMSF routes traffic to the additional slave DB node when one master/slave pair fails, that the SMSF routes traffic to the other pair when the first pair fails, and that the SCP routes traffic to a disaster recovery site only when all pairs fail and the additional slave DB node is not available. The claim additionally requires that, when the cluster is restarted and ready to accept traffic, the SMSF sends a CLI command to the SCP to shift traffic back to the primary site. The applied prior art, including Kumar, Laicher, and Assali, does not appear to teach or suggest this particular multi-layer DB redundancy structure or the claimed failover sequence among multiple DB pairs, an additional slave DB node, and a DR site. Although Assali teaches round robin load balancing, it does not disclose the claimed DB-node topology or the claimed controlled failback via CLI command.
Claims 8-11 depend on allowable claim 7.
Claim 13 recites the system counterpart to claim 7 and includes the same specific technical arrangement: a SMSF cluster containing plurality of DB nodes on a primary site with an SCP, where the DB nodes include plurality of pairs of master DB node and slave DB node and an additional slave DB node, the SCP being configured to distribute traffic using a round robin algorithm, and the SMSF and SCP being configured to route traffic in the same staged failover order described in claim 7, including routing to the additional slave DB node, then to the other pair, and then to a DR site if the additional slave DB node is unavailable. The claim also requires the SMSF to send a CLI command to shift traffic back to the primary site once the cluster restarts. The prior art does not appear to disclose this particular system-level database redundancy configuration. While the references show general failover, load balancing, and disaster recovery concepts, they do not appear to teach the specific combination of multiple master/slave DB pairs, an additional slave DB node, round robin distribution across that structure, and CLI-based return to the primary site.
Claim 15 recites the computer program product version of the same DB redundancy architecture and therefore includes the same limiting features. More specifically, the claimed instructions cause execution of a method involving a SMSF cluster with plurality of DB nodes on a primary site and an SCP, where the DB nodes include plurality of pairs of master DB node and slave DB node and an additional slave DB node, the SCP is configured to distribute traffic using a round robin algorithm, traffic is routed first to the additional slave DB node upon failure of one DB pair, then to the other pair upon further failure, and finally to a DR site if all DB pairs fail and the additional slave DB node is unavailable. The claim also requires sending a CLI command to shift traffic back to the primary site when the cluster is restarted and ready to accept traffic. The applied references do not appear to teach or suggest this specific combination of DB redundancy features and failover operations. In particular, they do not appear to disclose the claimed layered DB failover arrangement or the CLI-driven failback mechanism.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDAN ORGAD whose telephone number is (571)272-7884. The examiner can normally be reached 9AM-5PM.
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. 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.
/EDAN ORGAD/Supervisory Patent Examiner, Art Unit 2414
