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 .
2. This office action is a response to an application filed on 04/03/2024, where claims 1-20 are pending.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on 04/03/2024 has been considered by the examiner. The submission is in compliance with the provisions of 37CFR 1.97.
Drawings
4. The drawings were received on 04/03/2024. These drawing are acceptable.
Claim Rejections - 35 USC § 103
5. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 2,5, 6, 8 9, 12, 13, 15, 16 19, is/are rejected under 35 U.S.C. 103 as being unpatentable over Naidu et al. (US 20210152694 A1) hereinafter Naidu and further in view of Ogawa (JP 2017005466 A)hereinafter Ogawa
As to claim 1. Naidu teaches A system for securing internet-based transfer of voice call data, comprising: ([0013] Fig. 1, and internet-based transfer of voice call system)
a session border controller (SBC), configured to use communications encoded with a primary protocol; ([0033] Fig. 2A, SBC Mapping 232 can correlate parameters and/or configurations of services, functions, and/or protocols required for various types of call sessions to one or more DNS Resource records. the SBC Mapping 232 can be in form of a SBC Mapping Table that correlates SBC functional CODEC parameters/encodes, to Universal Resource Identifiers (URI) and/or Fully Qualified Domain Names (FQDN) associated with one or more SBC servers 240A-D )
a connectivity component, configured to communicate with a voice call data source; ([0026] Fig2A, a first mobile communication device 216A can be wirelessly connected to a first carrier network 250 via a first mobility network 217A/connectivity component, and a second mobile communication device 216B can be wirelessly connected to a second carrier network 255 via a second mobility network 217B )
a forwarding unit (FU) communicatively coupled to the SBC and to the connectivity component; ([0029][0030]Fig. 2A, the first carrier network 250/forwarding unit, can include a SBC server 240C that implements a web client service, such as in SBC-WEB 240C, web client service can enable a client application 230 at the first communication device 216A to connect to a web server via the IP Network 245; first carrier network connected to first mobility network 217A/connectivity component)
wherein, when a communication is received at the connectivity component, from the voice call data source, to propose transferring voice call data to the SBC, ([0033][0034] Fig. 2A, the application 230 can detect a request for a call session at the first communication device 216A, cause the first communication device 216A to send an SIP INVITE message to the SBC-TLS server 240B/security service through first mobility network 217A, in order to request an origination of the call session. )
the connectivity component is to transmit an indication to the FU and the FU is to send a primary-protocol-encoded communication to the SBC ([0033][0034] Fig. 2A, the Application 230 can cause the first communication device 216A to send an SIP INVITE /primary protocol, message to the SBC-TLS server 240A in order to request an origination of the call session through first mobility network 217A/connectivity component to first carrier network 250/forwarding unit and SBC Mapping Table that correlates SBC functional CODEC parameters/encodes)
requesting to establish a source-agnostic connection to the SBC;([0034] Fig. 2A, the Application 230 can cause the first communication device 216A to send an SIP INVITE message to the SBC-TLS server 240A in order to request an origination of the call session. )
wherein the SBC is to, in response to the primary-protocol-encoded communication to the SBC, ; ([0033] Fig. 2A, SBC Mapping 232 can correlate parameters and/or configurations of services, functions, and/or protocols required for various types of call sessions to one or more DNS Resource records, SBC Mapping 232 can be in form of a SBC Mapping Table that correlates SBC functional CODEC parameters/encodes, to Universal Resource Identifiers (URI) and/or Fully Qualified Domain Names (FQDN) associated with one or more SBC servers 240A-D )
output an IP address encoded with the primary protocol, the IP address indicative of a location configured to receive the voice call data; ([0036] Fig. 2B, requirements can be used to determine a Codec parameter corresponding to the requirements. The communication device/application can access a SBC Mapping; SBC Mapping can be searched, using the Codec parameter, to obtain a URI/FQDN for a SBC server corresponding to the Codec parameter in step 263. Once the URI/FQDN is obtained, the communication device/application can access a DNS resource to obtain an IP address/location, for the SBC server corresponding to the URI/FQDN in step 264; communication device/application can direct a SIP INVITE message to the SBC server, such as SBCRTT 265, SBC-TLS 266, or SBC-WEB (HTTP) 267)
IP address encoded ([0046] Fig. 2c, communication device can determine a codec parameter for the call session according the service/function requirement, in step 278, and, in turn, search a SBC table for a resource identifier based on the Codec parameter, in step 280. The communication device requests and receives an IP address for the SBC server from a DNS resource based on the resource identifier, in step 282, and, in turn, sends a transport protocol message to the SBC server at the IP address to facilitate the call session, in step 284)
Naidu does not teach a gateway component, configured to communicate with a voice call data source using a secondary protocol; wherein the gateway component is to:
convert the IP address encoded with the primary protocol into an IP address encoded with the secondary protocol, and send the IP address encoded with the secondary protocol to the voice call data source that is proposing to transfer the voice call data
Ogawa teaches a gateway component, configured to communicate with a voice call data source using a secondary protocol; ([0019] gateway device installed between a first communication network and a second communication network , communicates calls between network,, converts IP version to a different IP version)
wherein the gateway component is to:
convert the IP address encoded with the primary protocol into an IP address encoded with the secondary protocol, and ([0030][0035]Fig. 3,an SBC (Session Border Controller) 31 (gateway device) between the originating network 21 and the receiving network 22.; The version conversion unit 313 converts the IP version of the IP address to a lower version; specifically, the version conversion unit 313 converts IPv6 addresses to IPv4 addresses according to the instructions of the control unit 314).
send the IP address encoded with the secondary protocol to the voice call data source that is proposing to transfer the voice call data. ([0056]Fig. 1, Fig. 6, Upon receiving a 488 response, the offering terminal 11 returns an ACK to the receiving terminal 12 (step S106 in Figure 6), and then re-offers to the receiving terminal 12 with an IPv4 IP address set in the C/U-Plane (step S108; Fig 6: INVITE(SDP_O2:IPv4)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine teaching of Ogawa with the teaching of Naidu because Ogawa teaches that , optimizing the call conversion procedure can reduce the occurrence of unnecessary IP version conversions, thereby improving processing efficiency by reducing fallback procedures, connection delays associated with message requests and responses can be minimized, thereby improving the user's perceived quality. (Ogawa [0021])
As to claim 2. The combination of Naidu and Ogawa specifically Naidu teaches wherein the SBC is to: receive voice call data at the IP address from the voice call data source. ([0031][0034] Fig. 2A, an IP-based Voice/Video call session (VoLTE/ViLTE) is initiate; SIP INVITE message that is received at the second Carrier Network 255 from the first Carrier Network 250 can include an IP Address for a corresponding SBC server 242A that is appropriate for this type of call session. )
Claim 9 s/are interpreted and rejected for the same reasons as set forth in claim 2.
As to claim 5 The combination of Naidu and Ogawa specifically Naidu teaches wherein the primary protocol is a Session Initiation Protocol (SIP). ([0034] Fig. 2A, the Application 230 can cause the first communication device 216A to send an SIP INVITE message to the SBC-RTT server 240A)
Claims 12 and 19 s/are interpreted and rejected for the same reasons as set forth in claim 5.
As to claim 6. The combination of Naidu and Ogawa specifically Naidu teaches wherein the forwarding unit (FU) is a selective forwarding unit (SFU). ([0034] Fig. 2A, a call session that requires a RTT service/function and uses a SBC-RTT server 240A at the first Carrier Network 250 can automatically select a SBC-RTT server 240B at the second Carrier Network 255. )
Claim 13 s/are interpreted and rejected for the same reasons as set forth in claim 6.
As to claim 8. A method for securing internet-based transfer of voice call data, comprising: ([0025] Fig. 2A, a method of full IP-capable calling, such as VoLTE, ViLTE, or a video streaming service. IP-capable calling devices 216A-B, can be wired devices or wireless devices 216A.)
sending a primary-protocol-encoded communication, by a forwarding unit (FU), to a session border controller (SBC), ([0029][0033]Fig. 2A, first carrier network 250 can include a SBC server 240B that implements a TLS service as part its set of security functions, such as in SBC-TLS 240B; he TLS service can contain VoIP communications; forward call to SBC TLS; SBC Mapping 232 can be in form of a SBC Mapping Table that correlates SBC functional CODEC parameters/encodes, to Universal Resource Identifiers (URI) and/or Fully Qualified Domain Names (FQDN) associated with one or more SBC servers 240A-D)
when an indication is received at the FU that a communication has been received at a connectivity component, from a voice call data source, ([0033][0034] Fig. 2A, the Application 230 can cause the first communication device 216A/source to send an SIP INVITE /primary protocol, message to the SBC-TLS server 240B in order to request an origination of the call session through first mobility network 217A/connectivity component to first carrier network 250/forwarding unit and SBC Mapping Table that correlates SBC functional CODEC parameters/encodes)
to propose transferring voice call data to the SBC, ([0033][0034] Fig. 2A, the application 230 can detect a request for a call session at the first communication device 216A, cause the first communication device 216A to send an SIP INVITE message to the SBCTLS server 240B through first mobility network 217A, in order to request an origination of the call session. )
wherein the FU is communicatively coupled to the SBC and to the connectivity component, ([0029][0030]Fig. 2A, the first carrier network 250/forwarding unit, can include a SBC server 240C that implements a web client service, such as in SBC-WEB 240C, web client service can enable a client application 230 at the first communication device 216A to connect to a web server via the IP Network 245; first carrier network connected to first mobility network 217A/connectivity component)
wherein the primary-protocol-encoded communication comprises a request to establish a source-agnostic connection to the SBC, ([0033][0034] Fig. 2A SBC Mapping 232 can be in form of a SBC Mapping Table that correlates SBC functional CODEC parameters/encodes, to Universal Resource Identifiers (URI) and/or Fully Qualified Domain Names (FQDN) associated with one or more SBC servers 240A;
Application 230 can cause the first communication device 216A to send an SIP INVITE /primary protocol, to the SBC-TLS server 240B in order to request an origination of the call session)
wherein the SBC is configured to use communications encoded with the primary protocol ([0033] Fig. 2A, SBC Mapping 232 can correlate parameters and/or configurations of services, functions, and/or protocols required for various types of call sessions to one or more DNS Resource records. the SBC Mapping 232 can be in form of a SBC Mapping Table that correlates SBC functional CODEC parameters/encodes, to Universal Resource Identifiers (URI) and/or Fully Qualified Domain Names (FQDN) associated with one or more SBC servers 240A-D )
and
the connectivity component is configured to communicate with the voice call data source; ([0026] Fig2A, a first mobile communication device 216A can be wirelessly connected to a first carrier network 250 via a first mobility network 217A/connectivity component, and a second mobile communication device 216B can be wirelessly connected to a second carrier network 255 via a second mobility network 217B )
outputting by the SBC, in response to the primary-protocol-encoded communication an IP address encoded with the primary protocol, ([0036] Fig. 2B, requirements can be used to determine a Codec parameter corresponding to the requirements. The communication device/application can access a SBC Mapping; SBC Mapping can be searched, using the Codec parameter, to obtain a URI/FQDN for a SBC server corresponding to the Codec parameter in step 263. Once the URI/FQDN is obtained, the communication device/application can access a DNS resource to obtain an IP address/location for the SBC server corresponding to the URI/FQDN in step 264; communication device/application can direct a SIP INVITE message to the SBC server, such as SBC-RTT 265, SBC-TLS 266, or SBC-WEB (HTTP) 267)
wherein the IP address indicative of a location configured to receive the voice call data; ([0036] Fig. 2B, call session can be initiated for a VoLTE,, the communication device/application can access a DNS resource to obtain an IP address/location for the SBC server corresponding to the URI/FQDN in step 264; communication device/application can direct a SIP INVITE message to the SBC server, such as SBC-RTT 265, SBC-TLS 266, or SBC-WEB (HTTP) 267)
Naidu does not teach converting, by a gateway component, the IP address encoded with the primary protocol into an IP address encoded with the secondary protocol,
wherein the gateway component is configured to communicate with the voice call data source using a secondary protocol; and
sending, by the gateway component, the IP address encoded with the secondary protocol to the voice call data source that is proposing to transfer the voice call data.
Ogawa teaches converting, by a gateway component, the IP address encoded with the primary protocol into an IP address encoded with the secondary protocol, ([0030][0035]Fig. 3,an SBC (Session Border Controller) 31 (gateway device) between the originating network 21 and the receiving network 22.; The version conversion unit 313 converts the IP version of the IP address to a lower version; specifically, the version conversion unit 313 converts IPv6 addresses to IPv4 addresses according to the instructions of the control unit 314).
wherein the gateway component is configured to communicate with the voice call data source using a secondary protocol; ([0019] gateway device installed between a first communication network and a second communication network , communicates calls between network,, converts IP version to a different IP version)
and
sending, by the gateway component, the IP address encoded with the secondary protocol to the voice call data source that is proposing to transfer the voice call data. ([0056]Fig. 1, Fig. 6, Upon receiving a 488 response, the offering terminal 11 returns an ACK to the receiving terminal 12 (step S106 in Figure 6), and then re-offers to the receiving terminal 12 with an IPv4 IP address set in the C/U-Plane (step S108; Fig 6: INVITE(SDP_O2:IPv4)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine teaching of Ogawa with the teaching of Naidu because Ogawa teaches that , optimizing the call conversion procedure can reduce the occurrence of unnecessary IP version conversions, thereby improving processing efficiency by reducing fallback procedures, connection delays associated with message requests and responses can be minimized, thereby improving the user's perceived quality. (Ogawa [0021])
As to claim 15. Naidu teaches A method for internet-based transfer of telephony data, comprising: ([0025] Fig. 2A, a method of full IP-capable calling, such as VoLTE, ViLTE, or a video streaming service. IP-capable calling devices 216A-B, can be wired devices or wireless devices 216A.)
transmitting a communication encoded by a first protocol, by a forwarding unit (FU), to a server security component, 0029][0033]Fig. 2A, first carrier network 250 can include a SBC server 240B that implements a TLS service as part its set of security functions, such as in SBC-TLS 240B/SBC security service; he TLS service can contain VoIP communications; forward call to SBC TLS; SBC Mapping 232 can be in form of a SBC Mapping Table that correlates SBC functional CODEC parameters/encodes, to Universal Resource Identifiers (URI) and/or Fully Qualified Domain Names (FQDN) associated with one or more SBC servers 240A-D)
upon an indication being received at the FU that a communication has been received at a server connection, from a telephony data source, to transfer telephony data to the server security component, ([0033][0034] Fig. 2A, the Application 230 can cause the first communication device 216A/source to send an SIP INVITE /primary protocol, message to the SBC-TLS server 240B in order to request an origination of the call session through first mobility network 217A/connectivity component to first carrier network 250/forwarding unit and SBC Mapping Table that correlates SBC functional CODEC parameters/encodes)
wherein the FU is in communication with the server security component and a server connection, ([0029][0033]Fig. 2A, first carrier network 250 can include a SBC server 240B that implements a TLS service as part its set of security functions, such as in SBC-TLS 240B
wherein the communication encoded by a first protocol comprises a request to establish a source-agnostic connection to the server security component, , ([0033][0034] Fig. 2A, the Application 230 can cause the first communication device 216A/source to send an SIP INVITE /primary protocol, to the SBC-TLS server 240B/server security in order to request an origination of the call session)
wherein the server security component is configured to use communications encoded with the first protocol , ([0033][0034] Fig. 2A SBC Mapping 232 can be in form of a SBC Mapping Table that correlates SBC functional CODEC parameters/encodes, to Universal Resource Identifiers (URI) and/or Fully Qualified Domain Names (FQDN) associated with one or more SBC servers 240A;
Application 230 can cause the first communication device 216A to send an SIP INVITE /primary protocol, to the SBC-TLS server 240B in order to request an origination of the call session)
and the server connection is configured to communicate with the telephony data source; ([0026] Fig2A, a first mobile communication device 216A can be wirelessly connected to a first carrier network 250 via a first mobility network 217A/connectivity component, and a second mobile communication device 216B can be wirelessly connected to a second carrier network 255 via a second mobility network 217B )
outputting by the server security component an IP address encoded with the first protocol, wherein the IP address is of a location to receive the telephony data; ([0036] Fig. 2B, requirements can be used to determine a Codec parameter corresponding to the requirements. The communication device/application can access a SBC Mapping; SBC Mapping can be searched, using the Codec parameter, to obtain a URI/FQDN for a SBC server corresponding to the Codec parameter in step 263. Once the URI/FQDN is obtained, the communication device/application can access a DNS resource to obtain an IP address/location for the SBC server corresponding to the URI/FQDN in step 264; communication device/application can direct a SIP INVITE message to the SBC server, such as SBC-RTT 265, SBC-TLS 266, or SBC-WEB (HTTP) 267)
Naidu does not teach converting, by a gateway component, the IP address encoded with the first protocol into an IP address encoded with a secondary protocol; and sending, by the gateway component, the IP address encoded with the secondary protocol to the telephony data source.
Ogawa teaches converting, by a gateway component, the IP address encoded with the first protocol into an IP address encoded with a secondary protocol; ([0030][0035]Fig. 3,an SBC (Session Border Controller) 31 (gateway device) between the originating network 21 and the receiving network 22.; The version conversion unit 313 converts the IP version of the IP address to a lower version; specifically, the version conversion unit 313 converts IPv6 addresses to IPv4 addresses according to the instructions of the control unit 314).
and sending, by the gateway component, the IP address encoded with the secondary protocol to the telephony data source. ([0056]Fig. 1, Fig. 6, Upon receiving a 488 response, the offering terminal 11 returns an ACK to the receiving terminal 12 (step S106 in Figure 6), and then re-offers to the receiving terminal 12 with an IPv4 IP address set in the C/U-Plane (step S108; Fig 6: INVITE(SDP_O2:IPv4)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine teaching of Ogawa with the teaching of Naidu because Ogawa teaches that , optimizing the call conversion procedure can reduce the occurrence of unnecessary IP version conversions, thereby improving processing efficiency by reducing fallback procedures, connection delays associated with message requests and responses can be minimized, thereby improving the user's perceived quality. (Ogawa [0021])
As to claim 16. The combination of Naidu and Ogawa specifically Naidu teaches , comprising: receiving, by the server security component, telephony data at the IP address from the telephony data source. ([0034] Fig. 2A, the DNS Resource 234 can return the IP Address for the SBC-TLS server 240B. The Application 230 can use this IP Address to connect to the SBC-TLS server 240B. For example, the Application 230 can cause the first communication device 216A to send an SIP INVITE message to the SBC-RTT server 240V in order to request an origination of the call session)
Claim(s) 3, 4, 10, 11, 17 ,18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Naidu, Ogawa and further in view of Bharrat et al. (US 20190174000 A1)hereinafter Bharrat
As to claim 3. The combination of Naidu and Ogawa does not teach wherein the SBC is to: direct the voice call data to a recorder service.
Bharrat teaches wherein the SBC is to: direct the voice call data to a recorder service. ([0133] [0161]Fig. 10, he call detail records are typically for incoming calls to the customer over a period of time such as 15 minutes or an hour and in the exemplary embodiment are generated by the SBC 308;; the SBC 308 still generates and stores call detail records for calls routed through the SBC to the CDR database 316).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine teaching of Bharrat with the teaching of Naidu and Ogawa because Bharrat teaches that allowing subscribers of a service to flag suspect robocalls for improved subscriber experience and thereby to take action which mitigate disruptions due to robocalls imposed upon subscribers as businesses.( Bharrat [0005])
Claim 10 s/are interpreted and rejected for the same reasons as set forth in claim 3.
As to claim 4. The combination of Naidu and Ogawa specifically Ogawa teaches, wherein the primary protocol and the secondary protocol are different protocols. ([0006] there are ipv6 and ipv4 protocols)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine teaching of Ogawa with the teaching of Naidu because Ogawa teaches that , optimizing the call conversion procedure can reduce the occurrence of unnecessary IP version conversions, thereby improving processing efficiency by reducing fallback procedures, connection delays associated with message requests and responses can be minimized, thereby improving the user's perceived quality. (Ogawa [0021])
Claims 11 and 18 s/are interpreted and rejected for the same reasons as set forth in claim 4.
As to claim 17. The combination of Naidu and Ogawa does not teach , comprising: directing, , the telephony data to a recorder service.
Naidu teaches by the server security component ([0028] Fig. 2A, each SBC server 240A can include including security functions, Security functions that may be included in a SBC server 240A)
The combination of Naidu and Ogawa does not teach comprising: directing, , the telephony data to a recorder service.
Ogawa teaches comprising: directing, , the telephony data to a recorder service.
([0133] [0161]Fig. 10, call detail records are typically for incoming calls to the customer over a period of time such as 15 minutes or an hour and in the exemplary embodiment are generated by the SBC 308; the SBC 308 still generates and stores call detail records for calls routed through the SBC to the CDR database 316).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine teaching of Bharrat with the teaching of Naidu and Ogawa because Bharrat teaches that allowing subscribers of a service to flag suspect robocalls for improved subscriber experience and thereby to take action which mitigate disruptions due to robocalls imposed upon subscribers as businesses.( Bharrat [0005])
As to claim 7 The combination of Naidu and Ogawa specifically Naidu teaches, wherein, when the connectivity component is to transmit an indication of the communication to the FU, ([0034] Fig. 2A, the Application 230 can cause the first communication device 216A to send an SIP INVITE message to the SBC-RTT server 240A in order to request an origination of the call session through first mobility network 217A/connectivity component to first carrier network 250/forwarding unit)
instructs the FU to send the primary-protocol-encoded communication to the SBC([0033][0034] Fig. 2A, the Application 230 can cause the first communication device 216A to send an SIP INVITE /primary protocol, message to the SBC-TLS server 240B/security service in order to request an origination of the call session through first mobility network 217A/connectivity component to first carrier network 250/forwarding unit and SBC Mapping Table that correlates SBC functional CODEC parameters/encodes) requesting to establish the source-agnostic connection to the SBC. ;([0034] Fig. 2A, the Application 230 can cause the first communication device 216A to send an SIP INVITE message to the SBCTLS server 240B in order to request an origination of the call session. )
The combination of Naidu and Ogawa does not teach the indication is transmitted via a voice call data recording controller, wherein the voice call data recording controller
Bharrat teaches the indication is transmitted via a voice call data recording controller, ([0133] [0161]Fig. 10, he call detail records are typically for incoming calls to the customer over a period of time such as 15 minutes or an hour and in the exemplary embodiment are generated by the SBC 308; the SBC 308 still generates and stores call detail records for calls routed through the SBC to the CDR database 316).
wherein the voice call data recording controller ([0191] Fig. 1, As calls 201 arrive into the network at session border controller 220, session border controller 220 generates call detail records and stores them in storage device 202, e.g., CDR database 202. The raw CDRs 204 include calling party source identification information)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine teaching of Bharrat with the teaching of Naidu and Ogawa because Bharrat teaches that allowing subscribers of a service to flag suspect robocalls for improved subscriber experience and thereby to take action which mitigate disruptions due to robocalls imposed upon subscribers as businesses.( Bharrat [0005])
Claims 14 and 20 s/are interpreted and rejected for the same reasons as set forth in claim 7.
Conclusion
6. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ansari; Amir et al. [US 20150347683 A1] MULTI-SERVICES APPLICATION GATEWAY AND SYSTEM EMPLOYING THE SAME
Mirsky; Gregory et al. [US 10841207 B2] Method and apparatus for supporting bidirectional forwarding (BFD) over multi-chassis link aggregation group (MC-LAG) in internet protocol (IP) networks
Pitchai; Sridhar et al. [US 20150172189 A1] METHOD, APPARATUS, AND SYSTEM FOR SUPPORTING FLEXIBLE LOOKUP KEYS IN SOFTWARE-DEFINED NETWORKS
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ATIQUE AHMED whose telephone number is (571)272-6244. The examiner can normally be reached 9:30 - 7:30 PM M-F Eastern.
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, Un Cho can be reached at 5712727919. 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.
/ATIQUE AHMED/Primary Examiner, Art Unit 2413
Prosecution Insights