Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101.
Claims 1-9 are rejected under 35 U.S.C. 101 as claiming the same invention as that of claims 1-9 of prior U.S. Patent No. 11,991,234. This is a statutory double patenting rejection.
Instant Application
U.S. Patent No. 11,991,234
1.An end user station for adaptive-rate content streaming of digital content comprising: a client module configured to be connected to a network having at least one server and further configured to request digital content over the network via at least one transmission control protocol (TCP) connection, wherein at least two different copies of the digital content are each encoded at different bit rates and stored on the at least one server, wherein each copy of the digital content is divided into a plurality of streamlets, each of the plurality
of streamlets of a corresponding copy comprising a different portion of the digital content during presentation, wherein corresponding streamlets across the at least two different copies comprise the same corresponding portions of the digital content during presentation, and wherein the client module streams the digital content by:
requesting a first streamlet from the at least one server; automatically requesting from the at least one server subsequent portions of
the digital content by requesting for each subsequent portion one of the streamlets from the different copies of the digital content dependent upon successive determinations by the client module to change a currently requested bit rate to a higher or lower bit rate, the automatically requesting including repeatedly generating a factor indicative of a current ability to receive digital content at a rate sufficient for presenting the digital content as the digital content is received; making the successive determinations to change the digital content bit rate based on the factor using the streamlets of one of the different copies of the digital content having the highest bit rate determined receivable for presentation so that the client module selects a higher bit rate one of the different copies when the factor is greater than a first threshold and selects a lower bit rate one of the different copies when the factor is less than a second threshold; and arranging the streamlets requested from the at least one server in order of ascending presentation time for output to a presentation device.
2. The end user station of claim 1, wherein at least some streamlets are requested from the at least one server via a hypertext transfer protocol (HTTP) GET request.
3. The end user station of claim 1, wherein the at least one server comprises at least two servers and wherein at least one streamlet is requested from a first of the at least one server and at least one other streamlet is requested from a second server of the at least one server other than the first server.
4. The end user station of claim 1, wherein the client module repeatedly generates the factor based on a moving time window.
5. The end user station of claim 1, wherein the client module generates the factor based on a current read ahead margin.
6. The end user station of claim 1, wherein a first streamlet of each copy of the digital content has the same first duration and corresponds to a same first temporal portion of the digital content, wherein a second streamlet of each copy of the digital content have the same second duration and correspond to a same second temporal portion of the digital content.
7. The end user station of claim 6, wherein the first and second duration of the first streamlets of each copy are different from the durations of the second streamlets of each copy.
8. The end user station of claim 6, wherein each of the first streamlets has a first duration that is arranged of 0.1 to 5 seconds.
9. The end user station of claim 1, wherein the client module is further configured to transmit at least one virtual timeline request to retrieve a virtual timeline corresponding to the digital content and to receive the virtual timeline from the at least one server; and arrange the streamlets requested from the at least one server using the virtual timeline.
1. An end user station for adaptive-rate content streaming of digital content comprising: a client module configured to be connected to a network having at least one server and further configured to request digital content over the network via at least one transmission control protocol (TCP) connection, wherein at least two different copies of the digital content are each encoded at different bit rates and stored on the at least one server, wherein each copy of the digital content is divided into a plurality of streamlets, each of the plurality of streamlets of a corresponding copy comprising a different portion of the digital content during presentation, wherein corresponding streamlets across the at least two different copies comprise the same corresponding portions of the digital content during presentation, and wherein the client module streams the digital content by: requesting a first streamlet from the at least one server; automatically requesting from the at least one server subsequent portions of the digital content by requesting for each subsequent portion one of the streamlets from the different copies of the digital content dependent upon successive determinations by the client module to change a currently requested bit rate to a higher or lower bit rate, the automatically requesting including repeatedly generating a factor indicative of a current ability to receive digital content at a rate sufficient for presenting the digital content as the digital content is received; making the successive determinations to change the digital content bit rate based on the factor using the streamlets of one of the different copies of the digital content having the highest bit rate determined receivable for presentation so that the client module selects a higher bit rate one of the different copies when the factor is greater than a first threshold and selects a lower bit rate one of the different copies when the factor is less than a second threshold; and arranging the streamlets requested from the at least one server in order of ascending presentation time for output to a presentation device.
2. The end user station of claim 1, wherein at least some streamlets are requested from the at least one server via a hypertext transfer protocol (HTTP) GET request.
3. The end user station of claim 1, wherein the at least one server comprises at least two servers and wherein at least one streamlet is requested from a first of the at least one server and at least one other streamlet is requested from a second server of the at least one server other than the first server.
4. The end user station of claim 1, wherein the client module repeatedly generates the factor based on a moving time window.
5. The end user station of claim 1, wherein the client module generates the factor based on a current read ahead margin.
6. The end user station of claim 1, wherein a first streamlet of each copy of the digital content has the same first duration and corresponds to a same first temporal portion of the digital content, wherein a second streamlet of each copy of the digital content have the same second duration and correspond to a same second temporal portion of the digital content.
7. The end user station of claim 6, wherein the first and second duration of the first fi streamlets of each copy are different from the durations of the second streamlets of each copy.
8. The end user station of claim 6, wherein each of the first streamlets has a first duration that is a range of 0.1 to 5 seconds.
9. The end user station of claim 1, wherein the client module is further configured to transmit at least one virtual timeline request to retrieve a virtual timeline corresponding to the digital content and to receive the virtual timeline from the at least one server, and arrange the streamlets requested from the at least one server using the virtual timeline.
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3-4 and 8 of U.S. Patent No. 8,868,772 in view of Carmel et al. – hereinafter Carmel (US 6,389,473)
Instant Application
U.S. Patent No. 8,868,772
1. An end user station for adaptive-rate content streaming of digital content comprising:
a client module configured to be connected to a network having at least one server
and further configured to request digital content over the network via at least one transmission control protocol (TCP) connection,
wherein at least two different copies of the digital content are each encoded at different bit rates and stored on the at least one server,
wherein each copy of the
digital content is divided into a plurality of streamlets,
each of the plurality of streamlets of a corresponding copy comprising a different portion of the digital content during presentation,
wherein corresponding streamlets across the at least two different copies comprise the same corresponding portions of the digital content during presentation, and
wherein the client module
streams the digital content by:
requesting a first streamlet from the at least one server;
automatically requesting from the at least one server subsequent portions of the
digital content by requesting for each subsequent portion one of the streamlets from the different copies of the digital content dependent upon successive determinations by the client module to change a currently requested bit rate to a higher or lower bit rate,
the automatically requesting
including repeatedly generating a factor indicative of a current ability to receive digital content at a rate sufficient for presenting the digital content as the digital content is received;
making the successive determinations to change the digital content bit rate based
on the factor using the streamlets of one of the different copies of the digital content having the highest bit rate determined receivable for presentation
so that the client module selects a higher bit rate one of the different copies when the factor is greater than a first threshold
and selects a lower bit rate one of the different copies when the factor is less than a second threshold; and
arranging the streamlets requested from that least one server in order of ascending presentation time for output to a presentation device.
A method for presenting rate-adaptive streams, the method comprising:
streaming by a media player operating on an end user station a video from a set of one or more servers,
wherein each of a plurality of different copies of the video encoded at different bit rates is stored as multiple files on the set of servers,
wherein each of the multiple files yields a different portion of the video on playback,
wherein the multiple files across the different copies yield the same portions of the video on playback, each of said files having a time index such that the files whose playback is the same portion of the video for each of the different copies have the same time index in relation to the beginning of the video, and
wherein the streaming comprises: requesting by the media player a plurality of sequential ones of the files of one of the copies from the set of servers over a plurality of Transmission Control Protocol (TCP) connections based on the time indexes;
automatically requesting by the media player from the set of servers over the plurality of TCP connections subsequent portions of the video by requesting for each such portion one of the files from one of the copies dependent upon successive determinations by the media player to shift the playback quality to a higher or lower quality one of the different copies,
said automatically requesting including, repeatedly generating a set of one or more factors indicative of the current ability to sustain the streaming of the video using the files from different ones of the copies, wherein the set of one or more factors relate to the performance of the network; and
making the successive determinations to shift the playback quality based on at least one of the set of factors to achieve continuous playback of the video using the files of the highest quality one of the copies determined sustainable at that time; and
presenting the video by playing back with the media player on the end user station the requested files in order of ascending playback time.
3. The method of claim 1, wherein said making the successive determinations to shift comprises: upshifting to a higher quality one of the different copies when the at least one factor is greater than a first threshold; and determining if the higher quality playback can be sustained.
4. The method of claim 3, wherein said making the successive determinations to shift comprises downshifting to a lower quality one of the different copies when the at least one factor is less than a second threshold.
8. The method of claim 1, wherein said presenting comprises sequentially arranging the requested files from the different copies in the order of ascending playback time for playback with the media player on the end user station.
The patents claims fail to teach a client module configured to be connected to a network having at least one server and further configured to request digital content over the network via at least one transmission control protocol (TCP) connection, and dividing wherein each copy of the digital content is divided into a plurality of streamlets, which are independently requestable by the client
Carmel discloses client module configured to be connected to a network having at least one server and further configured to request digital content over the network via at least one transmission control protocol (TCP) connection (Col 6 line 50 – Col 7 line 2; After preparing the multimedia sequence, computer 34 uploads the sequence over network 28, preferably using the Internet File Transfer Protocol (FTP). Alternatively, other Internet protocols may be used, such as the TCP/IP, UDP or RT(x) protocols; Fig. 1) and
dividing wherein each copy of the digital content is divided into a plurality of streamlets, (Col 2 lines 1-21; a transmitting computer generates a data stream and broadcasts the data stream via a network server to a plurality of clients. The data stream is divided into a sequence of segments or slices of the data, preferably time slices, wherein the data are preferably compressed. Each slice is preferably assigned a respective slice index. The transmitting computer uploads the sequence of slices to the server substantially in real time, preferably using an Internet protocol, most preferably the File Transfer Protocol (FTP), as is known in the art; The clients download the data stream from the server, preferably using an Internet protocol, as well, most preferably the Hypertext Transfer Protocol (HTTP), or alternatively, using other protocols, such as UDP or RTP, which are similarly known in the art))
It would have been obvious for the teachings of the patent at the time of invention to be able to independently request streamlets of data at higher or lower quality based upon the current determined factor in a client server networking using TCP protocol and use the slice index to maintain proper synchronization of the playback when playing the stream. This would have been beneficial to maintain synchronization allows the broadcast to go on substantially in real time without the use of special-purpose hardware.. (Carmel, Col 2 lines 1-21)
Allowable Subject Matter
The following is a statement of reasons for the indication of allowable subject matter:
. A relevant prior art, Grigorovitch et al. (US 2005/0066063) teaches that a single file stores a portion of a video stream and audio stream in multiple bit-rates as performing multi-bit- rate encoding and are selected based on a bandwidth. It also teaches that the media cache will create a segment for each portion of the received stream that is not immediately adjacent in time, when the user uses a seek bar to forward or rewind the playback media.
Srivara (US 2003/0204519) stores the entire song in multiple bit-rate encoding files and transmit the entire file in a single bit-rate in accordance with the quality selection. The prior art are different from the claimed invention in that the each streamlet correspond to a portion of a video, and is encoded at a response one of the plurality of different bitrate and refers to the same portion of the video in the low stream, medium quality and high quality stream and transmit only that portion which has the same duration at the at the requested bitrate for playback as requested.
Ogdon (US 6,161,137) discloses a presentation with different version of the same duration is stored and the leader changes the scripts in the middle of a presentation based on user feedback. The claim limitations is directed to that the end user station requests individual streamlets of various bitrate upon successive determinations to change the bitrates to a higher or lower bitrate and request individual streams based upon upper and lower threshold. Ogdon teaches away from the claim limitation as it the leader who chooses to change scripts in the middle of a presentation based on user feedback as opposed to end user requesting the individual streamlets of varying bitrates of the same duration based on successive determination based on a factors of various thresholds, as claimed.
Allen (WO 2002075482) teaches the streaming content is encoded into a single stream at a source and delivered to local broadcasters who encode the signal into the optimum format based on the characteristics of the user in the last mile, and that is independent of the user's individual viewing device, network connectivity bit rate and supported stream format. This teaches away from the current claims in the current claims support storing streamlet of different bit rates at the server and the client can select the optimal bit rate based on the factors of the first and second threshold and the selection of the bitrate is controlled by the client as opposed to the edge server at the last mile and delivers the stream in a single format (each duration is of the same bitrate) in Allen.
Shetyn (US 7,529,806) is directed to teaching a download approach that allows for a low or negligible play-out latency. It split the content files into multiple part and the size of the parts is based upon the play-out latency which is controlled by the communications bandwidth. Content parts can have different formats. It also teaches that the second segment is passed on from the buffer to the decoding playing module upon completion of playing out the first segment and the second file segment is downloaded and stored in a buffer while the first file segment is played out. Although it teaches portions of the prior art in that the user can select to download the first segment in higher quality and next segments in lower quality, it fails to teach each of the portions are of a fixed duration of multiple bitrates as the size of the parts is based upon the play-out latency which is controlled by the communications bandwidth and fails to teach the client selects an individual streamlet of bitrates based on factor of a current ability to receive digital content at a rate sufficient for presenting the digital content as the digital content is received between the first and second threshold, as claimed.
A close review of Carmel et al. (US 6,389,473) as argued in litigation teaches dividing a stream into a sequence of files, the files having a predetermined data size and encoding each file into a corresponding sequence of file, each having the own index and uploading to a server equal to the data rate of the stream. Carmel teaches each slice duration is different as the slice duration of the split up files are different and can be adjusted as Carmel discloses per Col 9 lines 39-48, as the slice duration is adjusted based upon the link bandwidth. Carmel “Col 9 lines 39-48, “Preferably, computer 34 monitors the rate of data being transmitted over each of links 60, 62, 64, etc., and allocates files 42, 44, 46, 48, etc., according to the data rates. The sizes of the files may be varied by adjusting slice durations T.sub.1, T.sub.2, T.sub.3, etc., and a relatively greater volume of data may be transmitted through links exhibiting relatively greater data rates.” This teaches away from the current claim language where each duration is of a fixed length, not a fixed size with variable duration that can be adjusted based on the current bandwidth, as shown above, as taught by Carmel. A POSITA would know that a higher quality streamlet would be a larger file, as in the number of bytes or megabytes, than a lower quality streamlet for a given duration (1 second, 5 seconds, 1 minute) and the size would not be a predetermined data size as taught by Carmel. Carmel shows this concepts per the disclosure on Col 8 line 56 — Col 9 line 5. Carmel, Col 8 line 56- Col 9 line 5, “. Size identifier 61 describes the size of those slices in stream 41 that have a fixed size associated therewith, wherein typically the size (or the corresponding resolution) of the level #1 video slices is smaller than that of the level #2 slices.”
A thorough review of the prior art teaches portions of the claim language with respect to client-side monitoring of the ability to receive the streamlet at the current bitrate, the client adjusting the higher and lower bitrates based upon the determination and the parsing and encoding of the stream into a plurality of streamlets. However, it fails to disclose or render obvious,
“automatically requesting from the at least one server subsequent portions of the
digital content by requesting for each subsequent portion one of the streamlets from the different copies of the digital content dependent upon successive determinations by the client module to change a currently requested bit rate to a higher or lower bit rate, the automatically requesting including repeatedly generating a factor indicative of a current ability to receive digital content at a rate sufficient for presenting the digital content as the digital content is received; making the successive determinations to change the digital content bit rate based on the factor using the streamlets of one of the different copies of the digital content having the highest bit rate determined receivable for presentation so that the client module selects a higher bit rate one of the different copies when the factor is greater than a first threshold and selects a lower bit rate one of the different copies when the factor is less than a second threshold”
Conclusion
The prior art made of record and not relied upon is considered pertinent toapplicant's disclosure. See PTO-892 form.
Any inquiry concerning this communication or earlier communications from theexaminer should be directed to Chirag R Patel whose telephone number is (571)272-7966. The examiner can normally be reached on Monday to Friday from 8:00AM to 4:30PM. If attempts to reach the examiner by telephone are unsuccessful, theexaminer's supervisor, Glenton Burgess, can be reached on 571-272-3949. The fax phone number for the organization where this application or proceedingis assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status informationfor published applications may be obtained from either Private PAIR or PublicPAIR. Status information for unpublished applications is available throughPrivate PAIR only. For more information about the PAIR system, seehttp://pairdirect.uspto.gov. Should you have questions on access to the PrivatePAIR system, contact the Electronic Business Center (EBC) at 866-217-9197(toll free).
/Chirag R Patel/
Primary Examiner, Art Unit 2454