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 preliminary amendment filed January 8, 2024. Claims 3-5, 12 and 13 have been amended. Claims 10-11, and 14-15 have been cancelled. Claims 16-24 have been newly added. Claims 1-9, 12, 13, and 16-24 are pending.
Information Disclosure Statement
The IDS filed 2/4/2025 has been considered.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-9, 12, 13, and 16-24 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Drose et al. (US 9083770, hereinafter referred to as “Drose”).
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.).
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).
Claims 6 and 7 are similar to claim 1, but from a perspective of a host terminal. Nevertheless, the rationale for rejecting claim 1 also applies to claims 6 and 7.
Regarding claim 8, Drose teaches the live interaction establishment method according to claim 7, 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 a 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 allow information to the viewer terminal through a first server, wherein the allow information indicates an agreement on the live interaction with the viewer terminal (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).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tian et al., US 20240406223 - WebRTC communication.
Miller et al., US 20200099789 - Establishing call setup using WebRTC.
Sayko, US 20140126714 - Establishing call setup using WebRTC.
Wang et al., CN 107948665 – sending feedback information to adjust live broadcasting.
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