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 .
Response to Amendment
Applicant’s submission filed on 01/20/2026 has been entered. Applicant’s submission overcomes prior objections to the drawings and claim 6. Therefore, the corresponding objections are withdrawn. Applicant’s submission overcomes prior rejections to claims 14-20 under 35 USC § 112 and prior rejections to claims 1-8 and 14-20 under 35 USC § 101. Therefore, the corresponding rejections are withdrawn. Claims 1-18 are pending. Claims 19 and 20 are cancelled.
Claim Objections
Claim 1 is objected to because of the following informalities:
in claim 1, “to enable a call session between IoT device of the user and the wireless device” should read “to enable a call session between the IoT device of the user and the wireless device” (emphasis added).
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 14-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 14 recites the limitation "the user". There is insufficient antecedent basis for this limitation in the claim. Examiner suggests that the limitation should read “a user” to establish the limitation in the claim. For the purposes of examination, the limitation is interpreted as such.
Claim 14 recites the limitation "to initiate a call on the IoT device". There is insufficient antecedent basis for this limitation in the claim. Examiner suggests that the limitation should read “to initiate a call on an IoT device” to establish the limitation in the claim. For the purposes of examination, the limitation is interpreted as such.
Claim 14 recites the limitation "the IoT platform". There is insufficient antecedent basis for this limitation in the claim. Examiner suggests that the limitation should read “an IoT platform” to establish the limitation in the claim. For the purposes of examination, the limitation is interpreted as such.
Dependent claims 15-18 are rejected due to their dependency on independent claim 14.
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.
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.
Claims 1, 2, and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Bot et al. (US 2018/0375991), hereinafter “Bot”, in view of Grubb et al. (US 2022/0337691), hereinafter “Grubb”.
Regarding claim 1, Bot teaches:
A system configured to establish call session with an Internet-of-Things (IoT) device of a user, wherein the IoT device is part of an IoT platform that includes at least the IoT device and an IoT service, the system comprising:
a call service network in a core network (see Bot, Fig. 1, par. [0102]: The communication network 130 comprises as an example an Internet Protocol (IP) Multimedia System (IMS) core network 140, having a Proxy-Call Session Control Function (P-CSCF) 140 as an interface towards the IMS network nodes, and an MGCF (Media Gateway Control Function) 150 as a gateway to terminating network, in this case as an example a Public Switched Telephone Network (PSTN) 160, which connects to a B-party 170 for terminating the call setup request), the call service network comprising:
a base station (see Bot, Fig. 1, pars. [0091-0092]: The Internet 115 comprises an Internet Service Provider (ISP) server 115A, arranged to support a connection between the mobile UEs 101, 102 and a node outside the Internet, such as communication node 120. The Internet further comprises a WLAN location database 115B, which is arranged to supply geographical coordinates when an identifier of a WLAN is provided. Communication node 120 is a node maintained by an operator of a public mobile telecommunication network and comprises a number of services, which may be implemented as separate functions, servers, or a cloud implementation, hereafter denotes as the functions; in this case, a public mobile telecommunication network node outside the Internet corresponds to a base station);
a wireless device that is in communication with the base station (see Bot, Fig. 1, par. [0091]: The Internet 115 comprises an Internet Service Provider (ISP) server 115A, arranged to support a connection between the mobile UEs 101, 102 and a node outside the Internet, such as communication node 120); and
a gateway server in communication with the IoT device and the call service network, the gateway server comprising a processor and memory storing instructions, when executed by the processor, cause the processor to facilitate an exchange of one or more call signaling messages between the IoT device and the call service network (see Bot, Fig. 1, pars. [0091-0093]: The Internet 115 comprises an Internet Service Provider (ISP) server 115A, arranged to support a connection between the mobile UEs 101, 102 and a node outside the Internet, such as communication node 120. The Internet further comprises a WLAN location database 115B, which is arranged to supply geographical coordinates when an identifier of a WLAN is provided. Communication node 120 is a node maintained by an operator of a public mobile telecommunication network and comprises a number of services, which may be implemented as separate functions, servers, or a cloud implementation, hereafter denotes as the functions. A Packet data Gateway 120A (PGw) is arranged to receive and send data packets from—and to the calling mobile UE 101, 102 and distribute these data packet to the functions, or collect data packets from the functions. Communication Gateway 120B (CGw) is arranged to send and receive data packets to—and from a terminating network 130 and distribute those data packets to the functions, or collect data packets from the functions, and see par. [0098]: The communication node 120 further comprises a function denoted as Control Function (CF) 120C, arranged to analyse a received a call setup request, from the mobile UE 101, 102, via the Packet data Gateway. The CF is further arranged to initialize a check in database 127 whether the identity of the mobile UE 101, 102 corresponds to a stored identity in a record of the database 127, and to forward the call setup via the Communication Gateway 120B in the direction of the communication network 130, and see par. [0184]: Control Function 120C comprises a memory 702 arranged for storing program instructions, settings, configuration data and variables. The processor 701 controls, under the program instructions stored in the memory); and
a communication plugin, deployed on a mobile device of the user, that is in communication with the IoT service and the call service network (see Bot, Fig. 2A, pars. [0106-0107]: As a first step the mobile UE 101, 102, residing and operating in the coverage of the WLAN, retrieves S201 its geographic location information and provides this geographical location information, with an identifier identifying the mobile UE in a call setup request to the communication node 120. The CF 120C in communication node 120 checks S202 whether the received identifier is comprised by a record of user accessible database 127. When a test S203 yields True, the CF in the communication node forwards S204 the call setup request, comprising the geographical location information and the identifier to the communication network 130 for establishing S205 the call, and see Fig. 6A, par. [0169]: Mobile UE 101, 102 comprise a memory 602 arranged for storing program instructions, settings, configuration data and variables. The processor 601 controls, under the program instructions stored in the memory, the modules; in this case, a UE may contain instructions (i.e. a plugin) for communication with WLAN and for calls (corresponding to in communication with the IoT service and the call service network)),
However, Bot does not teach:
the system configured to establish a voice-initiated call session with an IoT device of a user,
the communication plugin configured to direct a voice-initiated call session request from the user to the call service network to enable a call session between IoT device of the user and the wireless device.
Grubb, in the same field of endeavor, teaches:
the system configured to establish a voice-initiated call session with an IoT device of a user (see Grubb, Fig. 6, par. [0074]: At block 604, the accessory 601 can receive an audio input containing a wake word and a call request. For example, the audio input may be the user utterance “Computer, call Mom,” where “Computer” comprises the wake word and “call Mom” comprises the request, and see par. [0079]: At block 628, the cellular-capable device 603 can place a call to the call recipient via cellular network 630. At block 632, the cellular-capable device 603 can establish an audio channel with the accessory 601. The accessory 601 can then begin relaying audio to and from the cellular-capable device 603 to constitute the phone conversation),
the communication plugin configured to direct a voice-initiated call session request from the user to the call service network to enable a call session between IoT device of the user and the wireless device (see Grubb, Fig. 6, par. [0074]: At block 604, the accessory 601 can receive an audio input containing a wake word and a call request. For example, the audio input may be the user utterance “Computer, call Mom,” where “Computer” comprises the wake word and “call Mom” comprises the request, and see par. [0079]: At block 628, the cellular-capable device 603 can place a call to the call recipient via cellular network 630. At block 632, the cellular-capable device 603 can establish an audio channel with the accessory 601. The accessory 601 can then begin relaying audio to and from the cellular-capable device 603 to constitute the phone conversation).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Bot with the voice-initiated call of Grubb with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling making a telephone a call with an accessory device using a voice command (see Grubb, par. [0016]).
Regarding claim 2, the combination of Bot in view of Grubb teaches the system. Bot further teaches:
wherein the gateway server is configured to:
receive a call request initiated from the IoT device (see Bot, par. [0098]: The communication node 120 further comprises a function denoted as Control Function (CF) 120C, arranged to analyse a received a call setup request, from the mobile UE 101, 102, via the Packet data Gateway, and see Fig. 2B, par. [0119]: The Packet data Gateway 120A receives 203 the call setup comprising geographical location information via a preferably secure IP tunnel), and
transmit a Session Initiation Protocol (SIP) setup request to the call service network in response to the call request (see Bot, Fig. 4A, par. [0137]: The Packet data gateway 120A comprised by the communication node receives S401 a call setup request initialized by the mobile UE 101, 102, and see par. [0144]: The Communication Gateway 120B will forward S404 the SIP message towards the P-CSCF of the communication network).
Regarding claim 7, the combination of Bot in view of Grubb teaches the system. Bot further teaches:
wherein the call service network further comprises an Internet Protocol Multimedia Subsystem (IMS) (see Bot, Fig. 1, par. [0102]: The communication network 130 comprises as an example an Internet Protocol (IP) Multimedia System (IMS) core network 140).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Bot in view of Grubb, as applied to claims 1, 2, and 7 above, and further in view of Marsico et al. (US 2006/0079228), hereinafter “Marsico”.
Regarding claim 3, the combination of Bot in view of Grubb teaches the system.
However, the combination of Bot in view of Grubb does not teach:
wherein the gateway server is configured to:
receive a Session Initiation Protocol (SIP) invite request initiated from a voice call device via the call service network, and
transmit a call request to the IoT device in response to the SIP invite request.
Marsico, in the same field of endeavor, teaches:
wherein the gateway server is configured to:
receive a Session Initiation Protocol (SIP) invite request initiated from a voice call device via the call service network (see Marsico, Figs. 2, 3B, and 4A, par. [0055]: MSC 118 can route the call to the temporary routing number and MGC/MG 130 can receive the call (step 408). MGC/MG 130 can then transmit a SIP-INVITE message to SIP server 132 (step 410). Upon receipt of the SIP-INVITE message, SIP server 132 can query virtual VLR 126 for the subscriber information (step 412)), and
transmit a call request to the IoT device in response to the SIP invite request (see Marsico, Fig. 4A, par. [0055]: at step 414, virtual VLR 126 can map the routing number to the subscriber record and provide the IP address of the subscriber. At step 416, the SIP-INVITE message can then be forwarded to the subscriber over an IP network, i.e., via access point 110. Next, at step 418, a call can be established between MGC/MG 130 and communication device 108 associated with the subscriber using standard SIP and VoIP protocol).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the gateway server of the combination of Bot in view of Grubb with the gateway server receiving a SIP invite request and transmitting a call request of Marsico with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing mobility management signaling traffic (see Marsico, par. [0041]).
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Bot in view of Grubb, as applied to claims 1, 2, and 7 above, and further in view of Bernardi (US 2023/0216947), hereinafter “Bernardi”.
Regarding claim 4, the combination of Bot in view of Grubb teaches the system.
However, the combination of Bot in view of Grubb does not teach:
wherein the gateway server comprises a real-time or near real-time communication interface.
Bernardi, in the same field of endeavor, teaches:
wherein the gateway server comprises a real-time or near real-time communication interface (see Bernardi, par. [0006]: the invention provides a process and a system for using a secure real-time communications service (SRTCS) for data-capture, device programming, audio streaming, video streaming communications and content sharing that securely connects to and communicates with remote internet-of-things (IoT) wireless devices using Web Real-Time Communications (Web-RTC) Gateways and Cloud Servers to establish peer-to-peer connection between user devices and the IoT devices).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the gateway server of the combination of Bot in view of Grubb with the gateway server comprising a real-time interface of Bernardi with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of simplifying the implementation in the system (see Bernardi, par. [0009]).
Regarding claim 5, the combination of Bot in view of Grubb teaches the system.
However, the combination of Bot in view of Grubb does not teach:
wherein the gateway server further comprises a Web Real-Time Communication (RTC) gateway.
Bernardi, in the same field of endeavor, teaches:
wherein the gateway server further comprises a Web Real-Time Communication (RTC) gateway (see Bernardi, par. [0006]: the invention provides a process and a system for using a secure real-time communications service (SRTCS) for data-capture, device programming, audio streaming, video streaming communications and content sharing that securely connects to and communicates with remote internet-of-things (IoT) wireless devices using Web Real-Time Communications (Web-RTC) Gateways and Cloud Servers to establish peer-to-peer connection between user devices and the IoT devices).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the gateway server of the combination of Bot in view of Grubb with the gateway server comprising Web RTC gateway of Bernardi with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of simplifying the implementation in the system (see Bernardi, par. [0009]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bot in view of Grubb, as applied to claims 1, 2, and 7 above, and further in view of Marsico, and further in view of Jones et al. (US 7,298,702), hereinafter “Jones”.
Regarding claim 6, the combination of Bot in view of Grubb teaches the system.
However, the combination of Bot in view of Grubb does not teach:
wherein the communication plugin is configured to:
redirect the user to a login page associated with the call service network to enable the user to enter user credential information; and
transmit, upon successful authentication of the user credential information by the calls service network, at least part of the user credential information to the IoT service.
Marsico, in the same field of endeavor, teaches:
wherein the communication plugin is configured to:
redirect the user to a login page associated with the call service network to enable the user to enter user credential information (see Marsico, Fig. 3A, par. [0047]: the process can begin at step 300 when a GSM subscriber transmits an authentication request to AAA functionality 114 of Wi-Fi gateway VLR 102 to begin registration. The subscriber can be one of communication devices 108 having a subscription to the service provided by GSM network 106. According to one embodiment, Wi-Fi network 104 can utilize an authentication protocol such as RADIUS for authenticating the subscriber, and see par. [0030]: communication devices 108 register with Wi-Fi network 104 by transmitting an authentication request, including identification information, to an AAA functionality 114 associated with Wi-Fi gateway VLR 102. Communication devices 108 can register to an ISP via Wi-Fi network 104 by using Session Initiated Protocol (SIP). Communication devices 108 and AAA functionality 114 can utilize RADIUS for authentication and accounting. RADIUS specifies a mechanism for authenticating a remote user into the network through an attribute/value pair such as a login name and a password; in this case, a login name and a password corresponds to user credential information);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the communication plugin of the combination of Bot in view of Grubb with the login page of Marsico with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing mobility management signaling traffic (see Marsico, par. [0041]).
However, the combination of Bot in view of Grubb, and further in view of Marsico does not teach:
transmit, upon successful authentication of the user credential information by the calls service network, at least part of the user credential information to the IoT service.
Jones, in the same field of endeavor, teaches:
transmit, upon successful authentication of the user credential information by the calls service network, at least part of the user credential information to the IoT service (see Jones, Figs. 5 and 6, col. 13, lines 20-45: FIG. 5 next depicts functions that can be involved in wireless terminal 12 establishing a network link with remote network 24. As shown in FIG. 5, at block 64, wireless terminal 12 will first associate with VAP 16 with a predetermined SSID. At block 66, once associated, the wireless terminal 12 will send a DHCP request, seeking an IP address. In the exemplary embodiment, at block 68, the VAP 16 will allow that DHCP request to pass through the VPN tunnel to the VAP server 22. And at block 70, the DHCP server 30 on the remote network will issue an IP address to the wireless terminal 12 and, in the exemplary embodiment, provide the wireless terminal 12 with the IP address of call control device 26. At block 72, the wireless terminal 12 will then register with the call control device 26. FIG. 6 next depicts functions that can be involved in placing a voice call from wireless terminal 12 to a telephone number on the PSTN. As shown in FIG. 6, at block 74, a user of the wireless terminal 12 dials a telephone number and directs the wireless terminal 12 to send the dialed digits to the call control device. At block 76, a SIP user agent client on the wireless terminal 12 could then responsively generate and send a SIP INVITE message to the IP address of call control device 26, via a communication path comprising the WLAN air interface 14, the VAP 16, the VPN tunnel, the VAP server 22 and the remote network 24, and see col. 12, lines 33-45: after wireless terminal 12 acquires an IP address on remote network 24, the wireless terminal may register with the call control device 26 (through any agreed registration scheme), and the call control device 26 may responsively query the authentication server 32 to validate the wireless terminal 12 (or the user of the terminal). Alternatively or additionally, the call control device 26 could query the authentication server 32 each time an effort is made to place a voice call to or from wireless terminal 12. Upon successful authentication, the authentication server 32 may send a service profile to the call control device 26, which the call control device 26 can then store and use when providing service for the wireless terminal).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the communication plugin of the combination of Bot in view of Grubb, and further in view of Marsico with the transmitting credential information of Jones with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of a wireless voice terminal operating in a WLAN placing and receiving calls via a call control server on a remote network (see Jones, col. 14, lines 13-17).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Bot in view of Grubb, as applied to claims 1, 2, and 7 above, and further in view of Yerrabommanahalli et al. (US 2015/0245388), hereinafter “Yerrabommanahalli”.
Regarding claim 8, the combination of Bot in view of Grubb teaches the system.
However, the combination of Bot in view of Grubb does not teach:
wherein the call service network further comprises an emergency call session control function (E-CSCF).
Yerrabommanahalli, in the same field of endeavor, teaches:
wherein the call service network further comprises an emergency call session control function (E-CSCF) (see Yerrabommanahalli, Fig. 2, par. [0035]: The IMS 265 may provide this interface between the cellular core network 230 and the other networks 260 using a call session control function (CSCF). The CSCF provides signaling that controls the communication of the client station 205 with the IMS 265. The CSCF may control session establishment and teardown, user authentication, network security and QoS (Quality of Service). The IMS 265 may include a plurality of different CSCFs. As shown in FIG. 2, the IMS 265 may include a proxy-CSCF (P-CSCF) 270, a serving-CSCF (S-CSCF) 275, and an emergency-CSCF (E-CSCF) 280).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the call service network of the combination of Bot in view of Grubb with the E-CSCF of Yerrabommanahalli with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling calls over LTE-RAN or WLAN (see Yerrabommanahalli, par. [0022]).
Claims 9, 12, 14, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Marsico in view of Grubb, and further in view of Jones.
Regarding claims 9, 14, Marsico teaches:
A method for enabling a call service on an Internet-of-Things (IoT) device of a user, wherein the IoT device is part of an IoT platform that includes at least the IoT device and an IoT service, or one or more non-transitory computer-readable storage media comprising instructions recorded thereon, wherein the instructions, when executed by at least one data processor of a system (see Marsico, par. [0042]: each module 200, 202, and 204 may include an application processor for performing application level functions and a communications processor for communicating with other processing modules via bus 206. From a software perspective, each module 200, 202, and 204 may include telecommunications software applications for performing various telecommunications routing and processing functions), the method or the system comprising:
receiving, by a mobile application that is in communication with an IoT service and a call service core network, a request from the user to initiate a call on the IoT device (see Marsico, Fig. 3B, pars. [0051-0052]: The process can begin when a dual GSM/Wi-Fi subscriber transmits a request to access point 110 to begin registration. Referring to FIG. 3B, access point 110 forwards a RADIUS Registration Request message 314 to virtual VLR 126 for the subscriber. Message 314 includes the subscriber's GSM IMSI identifier. Based on the subscriber's GSM IMSI identifier, function 126 generates a SendAuthenticationinfo message 316 for requesting authentication information for the subscriber from the subscriber's HLR 116. Next, function 126 forwards SendAuthenticationinfo message 316 to HLR 116. Referring to FIG. 3B, in response to receiving message 316, HLR 116 can search its database for a set of authentication vectors. If HLR 116 locates the set of authentication vectors, HLR 116 generates a SendAuthenticationinfo response message 318 including the set of authentication vectors. Message 318 can be forwarded to AAA function 114 in Wi-Fi gateway VLR 102 for authenticating the subscriber in the GSM domain. If authentication is successful, Wi-Fi gateway VLR function 126 generates and forwards an Update Location message 320 including subscriber information to HLR 116. Next, HLR 116 generates a GSM InsertSubscriberData message 322 including the subscriber information, and see pars. [0007-0008]: Typically when a WLAN-enabled device attempts to connect to a WLAN, a username and password must be provided to pass to the AAA server. The AAA server can then pass the username and password to an HLR, which checks that the username and password is acceptable and then authorizes access to the WLAN. An AAA server handles user requests for access to computer resources and, for an enterprise network, provides AAA services. The AAA server typically interacts with network access and gateway servers and with databases and directories containing user information, and see par. [0028]: A user operating one of communication devices 108 can communicate with one of access points 110 to gain access to network services, such as Internet access; in this case, a user communicates a request via a communication device (i.e. an application of the user device receives the request from the user for further processing));
obtaining, by the mobile application, user credential information from the user (see Marsico, Fig. 3A, par. [0047]: the process can begin at step 300 when a GSM subscriber transmits an authentication request to AAA functionality 114 of Wi-Fi gateway VLR 102 to begin registration. The subscriber can be one of communication devices 108 having a subscription to the service provided by GSM network 106. According to one embodiment, Wi-Fi network 104 can utilize an authentication protocol such as RADIUS for authenticating the subscriber, and see par. [0030]: communication devices 108 register with Wi-Fi network 104 by transmitting an authentication request, including identification information, to an AAA functionality 114 associated with Wi-Fi gateway VLR 102. Communication devices 108 can register to an ISP via Wi-Fi network 104 by using Session Initiated Protocol (SIP). Communication devices 108 and AAA functionality 114 can utilize RADIUS for authentication and accounting. RADIUS specifies a mechanism for authenticating a remote user into the network through an attribute/value pair such as a login name and a password; in this case, a login name and a password corresponds to user credential information);
However, Marsico does not teach:
receiving, by a mobile application that is in communication with an IoT service and a call service core network, a voice-based request from the user to initiate a call on the IoT device
transmitting, by the mobile application upon authentication of the user credential information by the call service core network, at least part of the user credential information to the IoT platform to establish a call session between an IoT device of the user and an external device.
Grubb, in the same field of endeavor, teaches:
receiving, by a mobile application that is in communication with an IoT service and a call service core network, a voice-based request from the user to initiate a call on the IoT device (see Grubb, Fig. 6, par. [0074]: At block 604, the accessory 601 can receive an audio input containing a wake word and a call request. For example, the audio input may be the user utterance “Computer, call Mom,” where “Computer” comprises the wake word and “call Mom” comprises the request, and see par. [0079]: At block 628, the cellular-capable device 603 can place a call to the call recipient via cellular network 630. At block 632, the cellular-capable device 603 can establish an audio channel with the accessory 601. The accessory 601 can then begin relaying audio to and from the cellular-capable device 603 to constitute the phone conversation)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the call request of Marsico with the voice-initiated call request of Grubb with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling making a telephone a call with an accessory device using a voice command (see Grubb, par. [0016]).
However, the combination of Marsico in view of Grubb does not teach:
transmitting, by the mobile application upon authentication of the user credential information by the call service core network, at least part of the user credential information to the IoT platform to establish a call session between an IoT device of the user and an external device.
Jones, in the same field of endeavor, teaches:
transmitting, by the mobile application upon authentication of the user credential information by the call service core network, at least part of the user credential information to the IoT platform to establish a link between an IoT service account of the user and a call service account of the user (see Jones, Figs. 5 and 6, col. 13, lines 20-45: FIG. 5 next depicts functions that can be involved in wireless terminal 12 establishing a network link with remote network 24. As shown in FIG. 5, at block 64, wireless terminal 12 will first associate with VAP 16 with a predetermined SSID. At block 66, once associated, the wireless terminal 12 will send a DHCP request, seeking an IP address. In the exemplary embodiment, at block 68, the VAP 16 will allow that DHCP request to pass through the VPN tunnel to the VAP server 22. And at block 70, the DHCP server 30 on the remote network will issue an IP address to the wireless terminal 12 and, in the exemplary embodiment, provide the wireless terminal 12 with the IP address of call control device 26. At block 72, the wireless terminal 12 will then register with the call control device 26. FIG. 6 next depicts functions that can be involved in placing a voice call from wireless terminal 12 to a telephone number on the PSTN. As shown in FIG. 6, at block 74, a user of the wireless terminal 12 dials a telephone number and directs the wireless terminal 12 to send the dialed digits to the call control device. At block 76, a SIP user agent client on the wireless terminal 12 could then responsively generate and send a SIP INVITE message to the IP address of call control device 26, via a communication path comprising the WLAN air interface 14, the VAP 16, the VPN tunnel, the VAP server 22 and the remote network 24, and see col. 12, lines 33-45: after wireless terminal 12 acquires an IP address on remote network 24, the wireless terminal may register with the call control device 26 (through any agreed registration scheme), and the call control device 26 may responsively query the authentication server 32 to validate the wireless terminal 12 (or the user of the terminal). Alternatively or additionally, the call control device 26 could query the authentication server 32 each time an effort is made to place a voice call to or from wireless terminal 12. Upon successful authentication, the authentication server 32 may send a service profile to the call control device 26, which the call control device 26 can then store and use when providing service for the wireless terminal).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or one or more non-transitory computer-readable storage media of the combination of Marsico in view of Grubb with the transmitting credential information of Jones with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of a wireless voice terminal operating in a WLAN placing and receiving calls via a call control server on a remote network (see Jones, col. 14, lines 13-17).
Regarding claims 12, 17, the combination of Marsico in view of Grubb, and further in view of Jones, teaches the method or one or more non-transitory computer-readable storage media.
Marsico does not teach, but Grubb teaches:
wherein the IoT device comprises a voice-enabled device (see Grubb, Fig. 6, par. [0074]: At block 604, the accessory 601 can receive an audio input containing a wake word and a call request. For example, the audio input may be the user utterance “Computer, call Mom,” where “Computer” comprises the wake word and “call Mom” comprises the request, and see par. [0079]: At block 628, the cellular-capable device 603 can place a call to the call recipient via cellular network 630. At block 632, the cellular-capable device 603 can establish an audio channel with the accessory 601. The accessory 601 can then begin relaying audio to and from the cellular-capable device 603 to constitute the phone conversation).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the IoT device of Marsico with the voice-enabled device of Grubb with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling making a telephone a call with an accessory device using a voice command (see Grubb, par. [0016]).
Claims 10, 13, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Marsico in view of Grubb, and further in view of Jones, as applied to claims 9, 12, 14, and 17 above, and further in view of Wang et al. (US 2021/0227000), hereinafter “Wang”.
Regarding claims 10, 15, the combination of Marsico in view of Grubb, and further in view of Jones, teaches the method or one or more non-transitory computer-readable storage media.
However, the combination of Marsico in view of Grubb, and further in view of Jones, does not teach:
comprising:
presenting, by the mobile application, a login page of the call service account of the user associated with the call service core network to obtain the user credential information.
Wang, in the same field of endeavor, teaches:
comprising:
presenting, by the mobile application, a login page of the call service account of the user associated with the call service core network to obtain the user credential information (see Wang, par. [0036]: A user of the connected device may have an account in a cloud computing system and an account with a voice call carrier. A user may link their account in the cloud computing system to their account with the voice call carrier. For example, the user may use credentials, such as a username and password, for their cloud computing account to login to the system of the voice call carrier. The credentials may be sent directly to the cloud computing system, which may verify the credentials before allowing the user to login to the system of the voice call carrier by sending a token, such as OAuth token, that allows access to specific parts of the user's account on the cloud computing system to the system of the voice call carrier).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of Marsico in view of Grubb, and further in view of Jones, with the login page of Wang with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of minimizing power used and improving safety and security (see Wang, par. [0091]).
Regarding claims 13, 18, the combination of Marsico in view of Grubb, and further in view of Jones, teaches the method or one or more non-transitory computer-readable storage media.
However, the combination of Marsico in view of Grubb, and further in view of Jones, does not teach:
wherein the at least part of the user credential information is organized as a user token that is stored by the IoT service for subsequent calling.
Wang, in the same field of endeavor, teaches:
wherein the at least part of the user credential information is organized as a user token that is stored by the IoT service for subsequent calling (see Wang, par. [0036]: When the user enters the correct verification code, the system of the voice call carrier may generate a private token, such as, for example, a private OAuth2 token. The private token may be stored on the user's connected device, and may also be stored as part of the user's account in the cloud computing system, where it may be retrieved by other connected devices that the user's permits to access their cloud computing system account. The private token may be usable to verify requests to API's of the system of the voice call carrier using the user's account with the voice call carrier that includes the phone number that received the verification code).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the user credential information of the combination of Marsico in view of Grubb, and further in view of Jones, with the user token of Wang with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of minimizing power used and improving safety and security (see Wang, par. [0091]).
Claims 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Marsico in view of Grubb, and further in view Jones, as applied to claims 9, 12, 14, and 17 above, and further in view of Bot.
Regarding claims 11, 16, the combination of Marsico in view of Grubb, and further in view of Jones, teaches the method or one or more non-transitory computer-readable storage media.
However, the combination of Marsico in view of Grubb, and further in view of Jones, does not teach:
comprising:
enabling the call service on the IoT device by facilitating, using a communication interface associated with the mobile application, an exchange of one or more call signaling messages between the IoT device and the call service core network.
Bot, in the same field of endeavor, teaches:
comprising:
enabling the call service on the IoT device by facilitating, using a communication interface associated with the mobile application, an exchange of one or more call signaling messages between the IoT device and the call service core network (see Bot, Fig. 1, pars. [0091-0093]: The Internet 115 comprises an Internet Service Provider (ISP) server 115A, arranged to support a connection between the mobile UEs 101, 102 and a node outside the Internet, such as communication node 120. The Internet further comprises a WLAN location database 115B, which is arranged to supply geographical coordinates when an identifier of a WLAN is provided. Communication node 120 is a node maintained by an operator of a public mobile telecommunication network and comprises a number of services, which may be implemented as separate functions, servers, or a cloud implementation, hereafter denotes as the functions. A Packet data Gateway 120A (PGw) is arranged to receive and send data packets from—and to the calling mobile UE 101, 102 and distribute these data packet to the functions, or collect data packets from the functions. Communication Gateway 120B (CGw) is arranged to send and receive data packets to—and from a terminating network 130 and distribute those data packets to the functions, or collect data packets from the functions, and see par. [0098]: The communication node 120 further comprises a function denoted as Control Function (CF) 120C, arranged to analyse a received a call setup request, from the mobile UE 101, 102, via the Packet data Gateway. The CF is further arranged to initialize a check in database 127 whether the identity of the mobile UE 101, 102 corresponds to a stored identity in a record of the database 127, and to forward the call setup via the Communication Gateway 120B in the direction of the communication network 130).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of Marsico in view of Grubb, and further in view of Jones, with the using a communication interface of Bot with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling the use of multiple mobile UEs with or without public telecommunication capabilities (see Bot, par. [0202]).
Response to Arguments
Applicant’s arguments with respect to claims 1, 9, and 14 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Cai (US 2022/0294889) teaches network device receives a call request of a calling party, where the call request includes identification information of a called first terminal device.
Han et al. (US 2022/0255766) teaches a system for adding a smart home device includes a first mobile phone configured to set, using contact information of a second user, a second mobile phone allowed to make a call to the smart home device.
Singh et al. (US 2020/0160860) teaches techniques for dynamic contact ingestion including enabling a remote system to initiate outbound calls, announce inbound calls, and/or the like.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CALEB J BALLOWE whose telephone number is (571)270-0410. The examiner can normally be reached MON-FRI 7:30-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, Nishant B. Divecha can be reached at (571) 270-3125. 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.
/C.J.B./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419