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 .
This action is in response to the amendment filed May 11, 2026. Claims 1, 6, 8, and 9, have been amended. Claims 7, 10-11, and 14-15 have been cancelled. Claims 1-6, 8, 9, 12, 13, and 16-24 are pending.
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) 1-6, 8, 9, 12, 13, and 16-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Drose et al. (US 9083770, hereinafter referred to as “Drose”) in view of Pastro (US 20150036690).
Regarding claim 1, Drose teaches a live interaction establishment method applicable to a viewer terminal, comprising:
sending request information to a first server, wherein the request information indicates a request for live interaction with a host terminal (abstract - receive a real time communication request from a client device);
receiving response information from the first server as feedback to the request information (col. 3, lines 14-29: The streamer 106 can also be responsible for all the measurements and feedback notifications required to ensure the quality of the session for all the peers participating. This can apply in both directions of media streams--from client to the streamer 106 and vice versa. When ensuring the stream quality from peers to the streamer 106, the server-side component measures the loss, one-way packet queuing delay and generates Real-time Transport Control Protocol (RTCP) receiver report (as per RFC 3550) feedback messages sent to the clients.); and
initiating a first connection of real time communication (RTC) to a second server based on the response information before receiving allow information from the host terminal as feedback to the request information (figure 3; col. 8, lines 47-61: After the client SDK 175 establishes the management link to the Streamer 106, the RTC client 165 will first try to use this protocol. If the UDP communication fails (most likely due to a firewall restriction), the RTC client 165 will try to reach the Streamer 106 over the TCP fallback transport type. The P2P mode of the UDP based protocol is used as an optimization in case there are only two peers connected to a scope. The state transitions between different media connection types are shown in the FIG. 3. Initially, UDP probing 300 is performed. Is successful, a UDP relay 302 is established with a UDP P2P 304. UDP probing 300 fails, TCP connecting 306 is pursued. If successful, a TCP/TLS session 308 transpires. Disconnection occurs upon a disconnect state of a failed TCP connection 306.),
wherein the allow information indicates that the host terminal agrees on live interaction with the viewer terminal (figure 4; col. 16, lines 17-29: The RTC application includes a mechanism for a service provider to bill a client who wishes to use his/her services. In the GUI 400, a service provider "Kavan" receives a call from a user or a client "Bob" who wishes to talk to Kavan. The service provider can choose whether to accept or reject the call from the client. If the service provider chooses to accept the call, the service provider may also choose to bill the call. The service provider may send the charge to the client using the mechanism, e.g., a button "Bill Bob?" provided on the GUI 400. The client can choose to accept or reject the charge as explained at least with reference to FIGS. 4-7. Accordingly, embodiments of the disclosed technology enables billing a user in a single click of a button.).
However, Drose does not teach a transmission process of the allow information and an initiating process of the first connection of the RTC are performed independently of each other.
In an analogous art, Pastro teaches a transmission process of the allow information and an initiating process of the first connection of the RTC are performed independently of each other ([0006] A method is provided for establishing a connection between a first communication terminal and a second communication terminal. The connection may be a direct media connection, a media connection anchored in a TURN server, or a media connection or other type of data connection that is established between the first and second terminals via at least one gateway. The first communication terminal may have a WebRTC client. The method includes the steps of the first communication terminal sending a first message for establishing the connection with the second communication terminal, a first gateway receiving the first message, the first gateway modifying information included within the first message in response to receiving the first message and sending a second message that has the modified information toward the second communication terminal, and after sending the first message to the first gateway, the first communication terminal sending at least one third message to the first gateway identifying at least one first Interactive Connectivity Establishment Protocol ("ICE") candidate for facilitating formation of the connection between the first and second communication terminals sought to be established by the first communication terminal sending the first message. The method may also include the steps of the second communication terminal receiving the second message from the first gateway, the second communication terminal answering the second message by sending a fourth message to the first communication terminal to accept the establishing of the connection, the first gateway receiving the fourth message, and, in response to receiving the fourth message, the first gateway determining whether the second communication terminal has a WebRTC client based on the received fourth message. Upon a determination that the second communication terminal does not have a WebRTC client, the first gateway facilitates the establishment of the connection without forwarding the at least one first ICE candidate identified by the first communication terminal in the at least one third message. Upon a determination that the second communication terminal has a WebRTC client, the first gateway sends the fourth message to the first communication terminal and sends a fifth message to identify the at least one first ICE candidate that the first communication terminal identified to the first gateway in the at least one third message such that the second communication terminal receives information identifying the at least one first ICE candidate.).
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to enable the transmission procession and initiating process to be performed interpedently of each other because separating signaling/approval workflows can reduce session setup latency, thus improving RTC connectivity establishing time.
Regarding claim 2, Drose teaches the live interaction establishment method according to claim 1, wherein the first connection of the RTC comprises initialization of the RTC, channel join of the RTC, and streaming transmission of the RTC (figure 3), the initiating the first connection of the RTC to the second server based on the response information before receiving the allow information from the host terminal as the feedback to the request information comprises:
performing the initialization of the RTC before receiving the allow information (figure 3; col. 8, lines 47-61: RTC initialization occurs during pending state; media transmission does not occur until acceptance); and the method further comprises:
performing the channel join of the RTC and streaming transmission of the RTC to establish the first connection of the RTC, after receiving the allow information (figure 4; col. 16, lines 17-29: acceptance enables audio/video streaming).
Regarding claim 3, Drose teaches the live interaction establishment method according to claim 1, further comprising, after the initiating the first connection of the RTC to the second server based on the response information before receiving the allow information from the host terminal as the feedback to the request information: receiving the allow information during an establishment of the first connection of the RTC (figure 3: acceptance may arrive while RTC setup is going on); or releasing the first connection of the RTC in response to not receiving the allow information within a preset time period after completion of the establishment of the first connection of the RTC (col. 9, lines 21-24: The RTC client 165 will try to establish the TCP streaming connection when the UDP probing timeout occurs.).
Regarding claim 4, Drose teaches the live interaction establishment method according to claim 1, further comprising: receiving the allow information sent from the host terminal through the first connection of the RTC in response to completion of an establishment of the first connection of the RTC, after initiating the first connection of the RTC to the second server (col. 9, lines 21-28: The TLS over TCP connection is treated as a fallback for clients behind restrictive firewall devices. The RTC client 165 will try to establish the TCP streaming connection when the UDP probing timeout occurs. The connection is made to the same host and the same port as with the management link--port 443. Once the TCP and TLS connection is established, the connection is considered as functional and the media packets flow will start.).
Regarding claim 5, Drose teaches the live interaction establishment method according to claim 1, further comprising: receiving the allow information sent from the host terminal through the first server (figure 1: server 105 mediates acceptance messages).
Claim 6 is similar to claim 1, but from a perspective of a host terminal. Nevertheless, the rationale for rejecting claim 1 also applies to claim 6.
Regarding claim 8, Drose teaches the live interaction establishment method according to claim 6, wherein the sending the allow information through the second connection of the RTC comprises: sending the allow information to the second server through the second connection of the RTC, wherein the second server sends the allow information to the viewer terminal through the first connection of the RTC (figure 1: streaming server 105 acts as mediator and accepts requests from devices 130-155 and forwards requests to other servers 115-125).
Regarding claim 9, Drose teaches the live interaction establishment method according to claim 6, further comprising: sending the allow information to the viewer terminal through a first server l (figure 4 and 5).
Regarding claim 12, Drose teaches an electronic device, comprising: a memory for storing computer programs (figure 9: memory 910); a processor for performing, by invoking the computer programs (figure 9: processors 905), the live interaction establishment method according to claim 1 (figures 1, 3 and 5).
Regarding claim 13, Drose teaches a non-transitory computer-readable storage medium (figure 9: storage devices 920) stored thereon a computer program that, when executed by a processor, implements the live interaction establishment method according to claim 1 (figures 1, 3 and 5).
Regarding claim 16, Drose teaches an electronic device (figure 9), comprising: a memory for storing computer programs (figure 9: memory 910); a processor (figure 9: processors 905) for performing, by invoking the computer programs, the live interaction establishment method according to claim 2 (figures 3 and 4).
Regarding claim 17, Drose teaches an electronic device (figure 9), comprising: a memory for storing computer programs (figure 9: memory 910); a processor for performing (figure 9: processors 905), by invoking the computer programs, the live interaction establishment method according to claim 3 (col. 9, lines 21-24).
Regarding claim 18, Drose teaches an electronic device (figure 9), comprising: a memory for storing computer programs (figure 9: memory 910); a processor for performing (figure 9: processors 905), by invoking the computer programs, the live interaction establishment method according to claim 4 (col. 9, lines 21-28).
Regarding claim 19, Drose teaches an electronic device (figure 9), comprising: a memory for storing computer programs (figure 9: memory 910); a processor for performing (figure 9: processors 905), by invoking the computer programs, the live interaction establishment method according to claim 5 (figure 1).
Regarding claim 20, Drose teaches a non-transitory computer-readable storage medium (figure 9: storage devices 920) stored thereon a computer program that, when executed by a processor, implements the live interaction establishment method according to claim 2 (figures 3 and 4).
Regarding claim 21, Drose teaches a non-transitory computer-readable storage medium (figure 9: storage devices 920) stored thereon a computer program that, when executed by a processor, implements the live interaction establishment method according to claim 3 (col. 9, lines 21-24).
Regarding claim 22, Drose teaches a non-transitory computer-readable storage medium (figure 9: storage devices 920) stored thereon a computer program that, when executed by a processor, implements the live interaction establishment method according to claim 4 (col. 9, lines 21-24).
Regarding claim 23, Drose teaches a non-transitory computer-readable storage medium (figure 9: storage devices 920) stored thereon a computer program that, when executed by a processor, implements the live interaction establishment method according to claim 5 (figure 1).
Regarding claim 24, Drose teaches a non-transitory computer-readable storage medium (figure 9: storage devices 920) stored thereon a computer program that, when executed by a processor, implements the live interaction establishment method according to claim 6 (figure 1).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-6, 8, 9, 12, 13, and 16-24 have been considered but are moot because the new ground of rejection now further includes a newly found reference US 20150036690 by Pastro.
Specifically, abstract as well as paragraph [0006] of Pastro teaches a WebRTC-based signaling and media establishment architecture in which session control signaling (including offer/answer exchange and user acceptance/”answer” signaling) is handled independently from the underlying ICE connectivity establishment and media path information. In particular, Pastro teaches that ICE candidate gathering and connectivity checks are initiated and executed as part of a media-state machine that operates asynchronously relative to signaling-layer acceptance events, such that media connection establishment proceeds without awaiting completion of user acceptance signaling. This is interpreted as the clamed connection being performed “independently” of each other.
Conclusion
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 ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
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, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458
Prosecution Insights