DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim(s) 4-5, 7, 12-13, 15 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 102
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-3, 6, 8-11, 14, 16-20 is/are rejected under 35 U.S.C. 102(a)(1) as being disclosed by Suryavanshi et al (hereinafter Suryavanshi), US Patent PUB 20140029477 A1 (publication date January 2014).
As per claim{s} 1, 9, 17, Suryavanshi discloses a method for transmitting a media data stream, performed in a server (Suryavanshi: e.g., Server 500) [0051; Fig. 5], the method comprising:
obtaining a first data fragment (Suryavanshi: e.g., media stream ‘data chunk’) [0076] from a first media data stream (Suryavanshi: e.g., ‘primary media’ stream, such as ‘audio / video’ streamed during a RTCweb session) [0083;] as an RTP load (Suryavanshi: e.g., RTP Payload_604) [0087; Fig. 6];
obtaining a second data fragment (Suryavanshi: e.g., media stream ‘data chunk’) [0076] from a second media data stream (Suryavanshi: e.g., ‘application-generated data’ {i.e., ‘opaque data’} that is also streamed as part of the RTCweb session, such as a ‘video overlay’ {stream} based on ‘touch events’ during a video-telephony session {i.e., a user ‘draws’ an image / animation using a device touch surface, which is sent to the RTCweb endpoint as part of the session ) [0055;];
adding the second data fragment into an RTP extension header (Suryavanshi: e.g., in a RTP multimedia session, the ‘RTP extension header’ can be utilized to deliver the arbitrary or opaque media / data {‘chunk' / fragment}, in conjunction with the ‘primary media’, such as audio/video. Specifically, the ‘opaque data’ can be included ‘within the RTP extension header’ while the ‘RTP payload’ for the same RTP packet carries the corresponding ‘primary media’) [0083; Fig. 8]; and
generating an RTP packet comprising the RTP extension header and the RTP load (Suryavanshi: e.g., As such, in a ‘video chat session’, for example, if a first user ‘draws’ an animation on his or her UI, the ‘video’ will be transported in the ‘RTP payload’ while the ‘animation’ will be transported in the ‘RTP extension header’ belonging to the same RTP packet(s)) [0083; Fig. 8] (e.g., Thus, in a given RTP session, the ‘RTP packets’ would carry ‘primary media’ and ‘opaque data’ if an ‘RTP extension’ header is present, or only primary media if no RTP extension header is present) [0086] (e.g., steps 820-830 [Wingdings font/0xE0] At 820, the Sender 802 starts receiving opaque data generated by the user drawing on the UI', for example. This causes the sender 802 to generate and send a number of RTP packets with header extensions, as indicated by the solid lines. On the Sender 802 side, the ‘RTP packet’ is ‘constructed’ such that the time instant at which the ‘opaque data and the primary media are generated’ is the same. The opaque data is included in the ‘extension header’ and the primary media in the ‘RTP payload’, and sent to the ‘Receiver 804’ side) [0094-0095; Fig. 8].
Claim(s) 9, 17 recite(s) substantially the same limitations / features as claim 1, is/are distinguishable only by its/their statutory category (device, non-transitory storage medium), and accordingly rejected on the same basis.
As per claim{s} 2, 10, 18, Suryavanshi discloses a method further comprising transmitting the RTP packet to a terminal device (Suryavanshi: e.g., At 820, the sender 802 starts receiving opaque data generated by the user drawing on the UI, for example. This causes the sender 802 to generate and send a number of RTP packets with header extensions, as indicated by the solid lines. On the Sender 802 side, the ‘RTP packet’ is constructed such that the time instant at which ‘the opaque data and the primary media are generated’ is the same. The ‘opaque data’ is included in the ‘extension header’ and the ‘primary media’ in the ‘RTP payload’ {of the RTP packet}, and sent to the ‘Receiver 804’ side) [0094; Fig. 8] (e.g., ‘Transmit the Plurality of Packets of Data to a Target User Device’_1150) [0109; Fig. 11].
As per claim{s} 3, 11, 19, Suryavanshi discloses a method further comprising when the second data fragment is a start fragment of the second media data stream, setting a start field representing that the second data fragment is the start fragment in the RTP extension header; and when the second data fragment is an end fragment of the second media data stream, setting an end field representing that the second data fragment is the end fragment in the RTP extension header (Suryavanshi: e.g., In the RTP header 700, the extension bit ‘X’ can be set to indicate the existence of the extension header 710 {which comprises supplement / auxiliary or ‘second fragment / data chunk’ [i.e., ‘opaque data’] embedded in the RTP extension header; and accordingly, when the X-bit subsequently indicates the ‘non-existence of the header data’, this can signal the end of the second fragment / data chunk [i.e., there is no auxiliary / second data chunk embedded or included in the RTP packet] } ) [0089; Fig. 7].
As per claim{s} 6, 14, 20, Suryavanshi discloses a method further comprising
receiving an offer generated based on a session description protocol (SDP) and transmitted by a terminal device, wherein the offer comprises media description and extension information, the media description is configured for representing description information related to transmission of the first media data stream, and the extension information is configured for representing description information related to transmission of the second media data stream in the RTP extension header; generating an answer to the offer (Suryavanshi: e.g., The signaling for the use of an extension header as the means of opaque data transfer could be agreed upon by the two endpoints by means of an ‘Offer / Answer’ protocol like SDP. The out-of-band signaling channel can be used to instruct the receiver to create a data channel based on the ‘RTP extension header’…) [0090]; and transmitting the answer to the terminal device, to complete SDP negotiation with the terminal device (Suryavanshi: e.g., FIG. 8 illustrates an exemplary P2P call flow 800 between a Sender 802 and a Receiver 804. At 810, the network performs ‘session negotiation’ between the sender 802 and the receiver 804 with RTP as the transport protocol) [0093; Fig. 8].
As per claim{s} 8, 16, Suryavanshi discloses the method further comprising wherein
obtaining the first data fragment from the first media data stream as the RTP load comprises fragmenting the first media data stream to obtain a plurality of fragments (Suryavanshi: e.g., a media stream consists of a plurality of ‘data chunks’) [0076], wherein each fragment is used as one first data fragment (Suryavanshi: e.g., a given ‘data chunk’) [0076]; and obtaining the second data fragment from the second media data stream comprises obtaining, for each first data fragment, a data fragment with a collection period the same as a collection period of the first data fragment from the second media data stream as a second data fragment (Suryavanshi: e.g., On the sender 802 side, the RTP packet is constructed such that ‘the time instant’ at which the opaque data and the primary media are generated ‘is the same’) [0094; Fig. 8] (e.g., At 910, the network performs session negotiation between the sender 902 and the receivers 904 and 906 with RTP as the transport protocol. The sender 902 then begins sending a media stream comprising a number of standard RTP packets, as indicated by the dashed lines…At 920, the sender 902 starts receiving opaque data generated by, for example, the user drawing on the UI. This causes the sender 902 to generate and send a number of RTP packets with header extensions, as indicated by the solid lines. On the sender 902 side, the RTP packet is ‘constructed’ such that the ‘time instant at which the opaque data and the primary media are generated is the same’. The opaque data is included in the extension header and the primary media in the RTP payload.) [0096-0097; Fig. 9].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-7989. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451