DETAILED ACTION
Notice of 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/09/2026 has been entered.
Response to Arguments
Applicant's arguments filed 03/09/2026 have been fully considered.
Applicant argues that the amendments to the claims overcome the priority objection. In response to the argument, Examiner respectfully agrees. The priority objection is withdrawn.
Applicant argues that the amendments to the claims overcome the 112(a) rejection. In response to the argument, Examiner respectfully agrees. The 112(a) rejection is withdrawn.
Applicant argues, regarding the 112(b) rejections, that claims 1, 14, 21 are not missing an essential step. In response to the argument, Examiner respectfully disagrees. As the claim is currently recited, an essential step is missing. The specification is clear that “registration enables user device 102 to establish the communication session with the computing device 104” as noted in Applicant’s remarks. This shows that an essential step of creating/establishing a communication session is missing in Claims 1, 14, 21.
Applicant argues that the amendments “sending, to a presence system, the message, wherein sending the message causes the presence system to send the message to the second user device via a second communication session, wherein the message causes the second user device to register to receive the request for the first communication session” to Claims 1, 14, 21 are not taught by the prior art of record Siegel.
In response to the argument, Examiner respectfully disagrees. The acceptance of the call invitation initiates the session to cause the device that received it to register and engage in the first communication session.
Siegel teaches on sending, to a presence system, the message, wherein sending the message causes the presence system to send the message to the second user device (ie. second device 140) via a second communication session (ie. second communication connection 128), wherein the message causes the second user device (ie. second device 140) to register to receive the request for the first communication session (ie. communication between first and second user device). See Siegel, [0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both. By accepting the call invitation 142 may cause a connection (e.g., a web real-time-communications connection) to be created between the second device 140 and the second communication service provider 110.
Applicant argues that the 112b issue regarding missing step of “creating a first communication session” is not valid as the first communication session is not created until after the second device registers.
In response to the argument, Examiner respectfully disagrees. As the claims 1, 14, 21 are recited, the second device is registering with a first communication session based on a received message. Further, in Claims 4, 17, 24 where the acceptance of the invitation causes engagement in the first communication session. The missing step of creating a first communication session is necessary.
Applicant argues that the cited references do not teach or suggest "sending, to the second user device and based on the received registration request, an invitation to the first communication session, wherein acceptance of the invitation by the second user device causes the establishment of the first communication session between the first user device and the second user device" as recited in independent claim 8.
In response to the argument, Examiner respectfully disagrees. The invitation may initiate the communication session and this session may be automatically initiated based on the received application.
Siegel teaches on sending, to the second user device (ie. second device 140) and based on the received registration request, an invitation to the first communication session (ie. call invitation 142), see Siegel, [0041] The first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 136 or the request 168). [0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
wherein acceptance of the invitation by the second user device (ie. second device 140) causes the establishment of the first communication session between the first user device and the second user device (ie. communication between first and second user device). See Siegel, [0047] The session 150 may be automatically initiated when the particular application 166 is received. The particular application 166 may provide the multimedia service to the second device 140. The first device 130 may communicate with the second device 140 when the session 150 has been initiated for the multimedia service. The connection 160 may facilitate communication between the second device 140 and the first device 130 via the session 150 for the multimedia service.)
Applicant argues that the motivation to combine Siegel and Root is not supported. That Siegel would have no reason to include the teachings of Root on “receiving, from the second user device via a communication processing system and based on the request for the first communication session, a registration request”.
In response to the argument, Examiner respectfully disagrees. It would have been advantageous for Siegel to include further details on session setup. Siegel teaches on a device receiving an application in order to communicate in a session. Siegel also teaches that the second device can be determined to be registered. It is clear that Siegel can be modified to include that the second device would send a registering request. It would have been beneficial to include these details or to add this feature of Root as it would provide a complete picture of the session setup in Siegel.
Siegel teaches on determining if the second device is registered or not and on receiving an acceptance of the call invitation 142 ([0023][0024]). However, Siegel is silent on receiving, from the second user device via a communication processing system and based on the request for the first communication session, a registration request.
Root teaches receiving, from the second user device via a communication processing system and based on the request for the first communication session, a registration request. See Root, [0021] Each request for registration on the server 11A includes identification information specific to each communication device. In conjunction with the registration request, the IP address for each of the communication devices that are granted access to the server 11A is detected or passed in the registration request message and stored on server 11A and can be used during communication sessions to identify the location of the device for packet routing purposes.
It would have been obvious to modify Siegel per Root as it would allow the modified system to provide a complete session setup by allowing for registration requests to be received from devices that have been invited to a session.
Please see updated rejection below:
Claim(s) 1, 3, 7, 14, 16, 20-21, 23, 27-30 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2014/0128108 A1 (Siegel).
Claim(s) 4-6, 8-13, 17-19, 24-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0128108 A1 (Siegel) in view of US 2010/0299385 A1 (Root).
Claim(s) 28, 29, 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0128108 A1 (Siegel) in view of US 2012/0303831 A1 (Toshniwal).
Claim Rejections - 35 USC § 112
112 (b):
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.
Claim(s) 1, 3-7, 14, 16-21, 23-30 is/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 1 rejected under 35 U.S.C. 112(b) as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: creating/establishing a first communication session. Claim 1 recites “wherein the message causes the second user device to register to engage in the first communication session.”. This renders the claim unclear as the previous limitations recite “receiving, by a computing device and from a first user device, a request for a first communication session with a second user device;”. The previous limitation is a request for a first communication session. The claim is missing a step for creating/establishing the first communication session. The first communication session cannot be engaged in unless it has been created/established.
This same rejection applies to Claims 14 & 21.
All dependents are also rejected as having the same deficiencies as the claims from which they depend.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3, 7, 14, 16, 20-21, 23, 27-30 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2014/0128108 A1 (Siegel).
Regarding Claim 1:
Siegel teaches A method comprising: receiving, by a computing device (ie. first communication service provider 120) and from a first user device (ie. first device 130 or second communication service provider 110), a request for a first communication session (ie. request 136 or request 168) with a second user device (ie. second device 140); ([0041] The first communication service provider 120 may receive the request 136 from the second communication service provider 110 or the request 168 from the first device 130. In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 136 or the request 168).)
generating, based on the request for the first communication session, a message (ie. call invitation 142); ([0041] In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 13 6 or the request 168). [0047] The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
and sending, to a presence system, the message, wherein sending the message causes the presence system to send the message to the second user device (ie. second device 140) via a second communication session (ie. second communication connection 128), wherein the message causes the second user device (ie. second device 140) to register to receive the request for the first communication session (ie. communication between first and second user device). ([0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both. By accepting the call invitation 142 may cause a connection (e.g., a web real-time-communications connection) to be created between the second device 140 and the second communication service provider 110.) The acceptance of the call invitation initiates the session to cause the device that received it to register and engage in the first communication session.
Regarding Claim 14:
Siegel teaches One or more non-transitory computer-readable media storing processor-executable instructions ([0093] FIG. 5, the drive unit 516 may include a computer-readable non-transitory storage medium 522 in which one or more sets of instructions 524, e.g. software, can be embedded. The instructions 524 may reside completely, or at least partially, within the main memory 504, the static memory 506, and/or within the processor 502 during execution by the computer system 500.) that, when executed by at least one processor, cause the at least one processor to:
receive, from a first user device (ie. first device 130 or second communication service provider 110), a request for a first communication session (ie. request 136 or request 168) with a second user device (ie. second device 140); ([0041] The first communication service provider 120 may receive the request 136 from the second communication service provider 110 or the request 168 from the first device 130. In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 136 or the request 168).)
generate, based on the request for the first communication session (ie. request 136 or request 168), a message (ie. call invitation 142); ([0041] In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 13 6 or the request 168). [0047] The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
and sending, to a presence system, the message, wherein sending the message causes the presence system to send the message to the second user device (ie. second device 140) via a second communication session (ie. second communication connection 128), wherein the message (ie. call invitation 142) causes the second user device (ie. second device 140) to register to engage in the first communication session (ie. communication between first and second user device). ([0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both. By accepting the call invitation 142 may cause a connection (e.g., a web real-time-communications connection) to be created between the second device 140 and the second communication service provider 110.) The acceptance of the call invitation initiates the session to cause the device that received it to register and engage in the first communication session.
Regarding Claim 21:
Siegel teaches A system comprising: a computing device (ie. first communication service provider 120) configured to: receive, from a first user device (ie. first device 130 or second communication service provider 110), a request for a first communication session (ie. request 136 or request 168) with a second user device (ie. second device 140); ([0041] The first communication service provider 120 may receive the request 136 from the second communication service provider 110 or the request 168 from the first device 130. In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 136 or the request 168).)
generate, based on the request for the first communication session (ie. request 136 or request 168), a message (ie. call invitation 142); ([0041] In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 13 6 or the request 168). [0047] The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
and sending, to a presence system, the message, wherein sending the message causes the presence system to send the message to the second user device (ie. second device 140) via a second communication session (ie. second communication connection 128), wherein the message causes the second user device (ie. second device 140) to register to engage in the first communication session (ie. communication between first and second user device); ([0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both. By accepting the call invitation 142 may cause a connection (e.g., a web real-time-communications connection) to be created between the second device 140 and the second communication service provider 110.) The acceptance of the call invitation initiates the session to cause the device that received it to register and engage in the first communication session.
the first user device (ie. first device 130 or second communication service provider 110) configured to: send the request for the first communication session (ie. request 136 or request 168); ([0041] The first communication service provider 120 may receive the request 136 from the second communication service provider 110 or the request 168 from the first device 130. In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 136 or the request 168).)
and the second user device (ie. second device 140) configured to: receive the message (ie. call invitation 142). ([0041] In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 13 6 or the request 168). [0047] The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
Regarding Claims 3, 16, 23:
Siegel teaches the inventions of claims 1, 14, 21 as described.
Siegel teaches wherein the message (ie. call invitation 142) comprises an indication of a capability (ie. multimedia service associated with the request 168) of the first user device (ie. first device 130). ([0048] In a particular embodiment, the one or more second devices (e.g., the second device 140) may be configured receive the call invitation 142 as an incoming telephone call. The call invitation 142 may identify a calling party associated with the first device 130, a multimedia service associated with the request 136 (or the request 168), a category of the multimedia service associated with the request 136 (or the request 168), a topic of the session to be initiated for the request 132, a user of the second device 140, or a combination thereof.). Request 168 is associated with the first device and includes capability information on a multimedia service.
Regarding Claims 7, 20, 27:
Siegel teaches the inventions of claims 1, 14, 21 as described.
Siegel teaches wherein the first communication session comprises one or more of an internet telephone call, a multimedia distribution, a multimedia conference, or a presentation. ([0048] In a particular embodiment, the one or more second devices (e.g., the second device 140) may be configured receive the call invitation 142 as an incoming telephone call. The call invitation 142 may identify a calling party associated with the first device 130, a multimedia service associated with the request 136 (or the request 168), a category of the multimedia service associated with the request 136 (or the request 168), a topic of the session to be initiated for the request 132, a user of the second device 140, or a combination thereof.)
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.
Claim(s) 4-6, 8-13, 17-19, 24-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0128108 A1 (Siegel) in view of US 2010/0299385 A1 (Root).
Regarding Claim 8:
Siegel teaches A method comprising: receiving, by a computing device (ie. first communication service provider 120) and from a first user device (ie. first device 130 or second communication service provider 110), a request for a first communication session (ie. request 136 or request 168) with a second user device (ie. second device 140); ([0041] The first communication service provider 120 may receive the request 136 from the second communication service provider 110 or the request 168 from the first device 130.)
and sending, to the second user device (ie. second device 140) and based on the received registration request, an invitation to the first communication session (ie. call invitation 142), ([0041] The first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 136 or the request 168). [0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
wherein acceptance of the invitation by the second user device (ie. second device 140) causes the establishment of the first communication session between the first user device and the second user device (ie. communication between first and second user device). ([0047] The session 150 may be automatically initiated when the particular application 166 is received. The particular application 166 may provide the multimedia service to the second device 140. The first device 130 may communicate with the second device 140 when the session 150 has been initiated for the multimedia service. The connection 160 may facilitate communication between the second device 140 and the first device 130 via the session 150 for the multimedia service.)
Siegel teaches on determining if the second device is registered or not and on receiving an acceptance of the call invitation 142 ([0023][0024]). However, Siegel is silent on receiving, from the second user device via a communication processing system and based on the request for the first communication session, a registration request.
Root teaches, in the same field of endeavor, presence capable shared or non-shared client communication devices that are members of a communications group are connected to a communications network server that is capable of receiving presence information, Abstract.
Root also teaches receiving, from the second user device via a communication processing system and based on the request for the first communication session, a registration request. ([0021] Each request for registration on the server 11A includes identification information specific to each communication device. In conjunction with the registration request, the IP address for each of the communication devices that are granted access to the server 11A is detected or passed in the registration request message and stored on server 11A and can be used during communication sessions to identify the location of the device for packet routing purposes.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Siegel per Root to include receiving, from the second user device via a communication processing system and based on the request for the first communication session, a registration request. This would have been advantageous as discussed above, as it would allow the modified system to provide a complete session setup by allowing for registration requests to be received from devices that have been invited to a session.
Regarding Claim 9:
Siegel (as modified by Root) teaches the invention of claim 8 as described.
Siegel further comprising: generating, based on the request for the first communication session (ie. request 136 or request 168), a message (ie. call invitation 142); ([0041] In a particular embodiment, the first communication service provider 120 may send one or more call invitations, such as the call invitation 142, to the second device 140 based on a received request (e.g., the request 13 6 or the request 168). [0047] The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
and causing the message (ie. call invitation 142) to be sent to the second user device via a second communication session (ie. second communication connection 128), wherein the message causes the second user device (ie. second device 140) to register to receive the request for the first communication session (ie. communication between first and second user device). ([0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both. By accepting the call invitation 142 may cause a connection (e.g., a web real-time-communications connection) to be created between the second device 140 and the second communication service provider 110.) The call invitation initiates the session to cause the device to register and engage in the first communication session.
Regarding Claim 10:
Siegel (as modified by Root) teaches the invention of claim 9 as described.
Siegel teaches wherein the message (ie. call invitation 142) comprises an indication of a capability (ie. multimedia service) of the first user device. ([0048] In a particular embodiment, the one or more second devices (e.g., the second device 140) may be configured receive the call invitation 142 as an incoming telephone call. The call invitation 142 may identify a calling party associated with the first device 130, a multimedia service associated with the request 136 (or the request 168), a category of the multimedia service associated with the request 136 (or the request 168), a topic of the session to be initiated for the request 132, a user of the second device 140, or a combination thereof.). Request 168 is associated with the first device and includes capability information on a category of a multimedia service.
Regarding Claim 11:
Siegel (as modified by Root) teaches the invention of claim 8 as described.
Siegel teaches further comprising: receiving, from the second user device, an acceptance of the invitation (ie. notification of acceptance) to the first communication session; (Fig 4, Step 414 “Receive a notification that the second device has accepted the call invitation”. [0024] The first communication service provider 120 may send a call invitation, such as a call invitation 142, to the second device 140 based on the request 136. The call invitation 142 may invite the second device 140 to initiate the session 150 with the first device 130. The call invitation 142, when accepted, may enable the second device 140 to initiate the session 150 for a particular multimedia service associated with a request ( e.g., the request 136).)
and establishing the first communication session (ie. communication between first and second user device) between the first user device and the second user device. ([0047] The session 150 may be automatically initiated when the particular application 166 is received. The particular application 166 may provide the multimedia service to the second device 140. The first device 130 may communicate with the second device 140 when the session 150 has been initiated for the multimedia service. The connection 160 may facilitate communication between the second device 140 and the first device 130 via the session 150 for the multimedia service.)
Regarding Claim 12:
Siegel (as modified by Root) teaches the invention of claim 8 as described.
Siegel teaches on determining if the second device is registered or not and on receiving an acceptance of the call invitation 142 (Fig 4, [0023][0024]). However, Siegel is silent on wherein the registration request comprises location information for the second user device.
Root teaches wherein the registration request comprises location information for the second user device. ([0021] Each request for registration on the server 11A includes identification information specific to each communication device. In conjunction with the registration request, the IP address for each of the communication devices that are granted access to the server 11A is detected or passed in the registration request message and stored on server 11A and can be used during communication sessions to identify the location of the device for packet routing purposes.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Siegel per Root to include wherein the registration request comprises location information for the second user device. This would have been advantageous as discussed above, as it would allow the modified system to provide verification of the invited user device, by verifying location information provided in the registration request.
Regarding Claim 13:
Siegel (as modified by Root) teaches the invention of claim 8 as described.
Siegel teaches wherein the first communication session comprises one or more of an internet telephone call, a multimedia distribution, a multimedia conference, or a presentation. ([0048] In a particular embodiment, the one or more second devices (e.g., the second device 140) may be configured receive the call invitation 142 as an incoming telephone call. The call invitation 142 may identify a calling party associated with the first device 130, a multimedia service associated with the request 136 (or the request 168), a category of the multimedia service associated with the request 136 (or the request 168), a topic of the session to be initiated for the request 132, a user of the second device 140, or a combination thereof.)
Regarding Claims 4, 17, 24:
Siegel teaches the inventions of claims 1, 14, 21 as described.
Siegel teaches sending, to the second user device, an invitation to the first communication session, ([0047] The first communication service provider 120 may send the call invitation 142 to one or more second devices (e.g., the second device 140) via the second communication connection 128 to initiate the session 150 with the first device 130. The call invitation 142 may be based on the request 136 (or the request 168) sent to the first communication service provider 120, the access information, or both.)
wherein acceptance of the invitation by the second user device causes the second user device to engage in the first communication session. ([0047] The session 150 may be automatically initiated when the particular application 166 is received. The particular application 166 may provide the multimedia service to the second device 140. The first device 130 may communicate with the second device 140 when the session 150 has been initiated for the multimedia service. The connection 160 may facilitate communication between the second device 140 and the first device 130 via the session 150 for the multimedia service.)
Siegel teaches on determining if the second device is registered or not and on receiving an acceptance of the call invitation 142 ([0023][0024]). However, Siegel is silent on receiving, from the second user device via a communication processing system, a registration request.
Root teaches receiving, from the second user device via a communication processing system, a registration request; ([0021] Each request for registration on the server 11A includes identification information specific to each communication device. In conjunction with the registration request, the IP address for each of the communication devices that are granted access to the server 11A is detected or passed in the registration request message and stored on server 11A and can be used during communication sessions to identify the location of the device for packet routing purposes.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Siegel per Root to include receiving, from the second user device via a communication processing system, a registration request. This would have been advantageous as discussed above, as it would allow the modified system to provide a complete session setup by allowing for registration requests to be received from devices that have been invited to a session.
Regarding Claims 5, 18, 25:
Siegel (as modified by Root) teaches the inventions of claims 4, 17, 24 as described.
Siegel teaches further comprising: receiving, from the second user device, an acceptance of the invitation (ie. notification of acceptance) to the first communication session; (Fig 4, Step 414 “Receive a notification that the second device has accepted the call invitation”. [0024] The first communication service provider 120 may send a call invitation, such as a call invitation 142, to the second device 140 based on the request 136. The call invitation 142 may invite the second device 140 to initiate the session 150 with the first device 130. The call invitation 142, when accepted, may enable the second device 140 to initiate the session 150 for a particular multimedia service associated with a request ( e.g., the request 136).)
and establishing the first communication session between the first user device and the second user device. ([0047] The session 150 may be automatically initiated when the particular application 166 is received. The particular application 166 may provide the multimedia service to the second device 140. The first device 130 may communicate with the second device 140 when the session 150 has been initiated for the multimedia service. The connection 160 may facilitate communication between the second device 140 and the first device 130 via the session 150 for the multimedia service.)
Regarding Claims 6, 19, 26:
Siegel (as modified by Root) teaches the inventions of claims 4, 17, 24 as described.
Siegel teaches on determining if the second device is registered or not and on receiving an acceptance of the call invitation 142 (Fig 4, [0023][0024]). However, Siegel is silent on wherein the registration request comprises location information for the second user device.
Root teaches wherein the registration request comprises location information for the second user device. ([0021] Each request for registration on the server 11A includes identification information specific to each communication device. In conjunction with the registration request, the IP address for each of the communication devices that are granted access to the server 11A is detected or passed in the registration request message and stored on server 11A and can be used during communication sessions to identify the location of the device for packet routing purposes.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Siegel per Root to include wherein the registration request comprises location information for the second user device. This would have been advantageous as discussed above, as it would allow the modified system to provide verification of the invited user device, by verifying location information provided in the registration request.
Claim(s) 28, 29, 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0128108 A1 (Siegel) in view of US 2012/0303831 A1 (Toshniwal).
Regarding Claims 28, 29, 30:
Siegel teaches the inventions of claims 1, 14, 21 as described.
Siegel teaches on utilizing SIP and SIP requests ([0028][0041]). However, Siegel is silent on wherein the message comprises a SIP publish message.
Toshniwal teaches, in the same field of endeavor, on a method for authorizing access by a user device to at least one service offered over an Internet Protocol (IP) network, Abstract.
Toshniwal teaches wherein the message comprises a SIP publish message. ([0009] The message includes a Session Initiation Protocol (SIP) REGISTER request. In some embodiments, the message includes a SIP PUBLISH request, a SIP OPTIONS request or a SIP NOTIFY request. In some embodiments, the message includes a SIPINVITE request, a SIP SUBSCRIBE request or a SIP REFER request.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Siegel per Toshniwal to include wherein the message comprises a SIP publish message. This would have been advantageous as discussed above, as it would allow the modified system to provide further options utilizing SIP, where the SIP publish message offers options for including presence information and device capabilities, allowing this information to be shared with other peer devices, see Toshniwal [0039].
Conclusion & Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHEL J HACKENBERG whose telephone number is (571)272-5417. The examiner can normally be reached 9am-5pm M-F.
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, Glenton B Burgess can be reached on (571)272-3949. 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.
/RACHEL J HACKENBERG/Primary Examiner, Art Unit 2454
Prosecution Insights