Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Notice for all Patent Application as subject to AIA
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 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.
RESPONSE TO AMENDMENT
Claims 1-22 are pending and remain for further examination.
The old rejection maintained
Applicant’s amendments and arguments with respect to claims 1-22 filed on September 10, 2025 have been fully considered but they are not deemed to be persuasive for the claims 1-22. The rejection is respectfully maintained as set forth in the last Office Action mailed on June 11, 2025.
Claim Rejections - 35 USC § 103
The text of those sections of title pre-AIA 35 U.S.C. 103 code not included in this action can be found in a prior Office Action.
Claims 1-9 and 21-22 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Jain et al (US Patent Application Publication No. 2005/0183120 A1) in view of Menon et al (US Patent Application Publication No. 2005/0262246 A1).
As to claim 1, Jain et al teach a method comprising: based on a request from a first device (user display/output device associated with receiver / end user), causing sending, by a computing device (receiver), to the first device, and from a network storage device (PVR server), a trick play version of a content asset (figures 1A-1B, pars. 0004-0005, figure 2A, pars. 0035-0037, 0039-0040, figure 5, par. 0046, reference teaches that in response to receiving a request for media content from an end user, receiver sends personal media streams to a user display/output device from a PVR server in response to trick play request); the trick play version is stored at the network storage device (PVR server) separately from the content asset (VOD server), and the network storage device (PVR server) is different than the computing device (receiver) (figure 1B, par. 0005, figure 6, pars. 0056-0057 & 0060, the media and media chunks with labels are stored at PVR server separately from the original media stored at VOD server, and the PVR server is different than the receiver).
However, Jain et al do not teach that causing, based on an expected request quantity (trick play requests increasing from the end users) corresponding to the trick play version of the content asset, storage of the trick play version of the content asset at a second storage device (second PVR server) associated with the content asset (VOD server).
Menon et al teach a method comprising: causing, based on an expected request quantity corresponding to the content asset, storage of the trick play version of the content asset at a second storage device associated with the content asset (figure 6, par. 0095, pars. 0026 & 0077, figures 7-8 & 10, pars. 0120-0123, reference teaches that replicating content asset (storing the content asset at a second server) in response to exceed current capacity to serve future requests).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Menon et al as stated above with the method of Jain et al for causing storage of the content asset at a second storage device based on exceed current capacity of a first storage device to serve future requests because it would have provided faster access without wasting resources and restricting the ability of the VOD system to handle very large video files or too many users, and also improved the service to manage the distribution or provide the content asset to the multiple users.
As to claim 2, Jain et al teach that the trick play version of the content asset comprises a reformatted version of the content asset (figure 6, pars. 0052-0057, the encoded media content and the media chunks with labels are the reformatted version of the original media).
As to claim 3, Jain et al teach that causing sending, to the first device, of the content asset (figure 1A, par. 0004, figure 2A, pars. 0035, figure 5, pars. 0045-0046, reference teaches that PVR server sends personal media stream to a user display/output device via receiver / end user).
As to claim 4, Jain et al teach that the determining the network storage device from a plurality of storage devices associated with the content asset (figure 10, par. 0069, reference teaches that selecting a proper PVR server from one or more PVR servers associated the management server or VOD server).
As to claim 5, Jain et al teach that the determining the network storage device after a determination that the trick play version of the content asset is not stored locally (figure 6, par. 0063, reference teaches that checks the requested media available at the PVR server or discovers a gap in the stored media being used to generate the stream (determining that the content asset is not stored locally) and rebuffering the PVR server in response to the trick play request).
As to claim 6, Jain et al teach that the causing storage of the trick play version of the content asset comprises causing storage of the trick play version of the content asset at the computing device (figure 5, pars. 0046, reference teaches that receiver stores incoming media files at a storage device that can be used to playback at a later time).
As to claim 7, Jain et al teach that determining the network storage device is based on a network location that is closest to the first device (figure 10, par. 0069, reference teaches that selecting a PVR server closer to a receiver).
As to claim 8, Jain et al teach that receiving, from the first device, a second request for a second trick play version of the content asset; causing generation of the second trick play version of the content asset; and causing sending of the second trick play version of the content asset to the first device (figure 2A, pars. 0036-0039, figure 5, par. 0046, figure 6, par. 0062, reference teaches that a user input device associated with receiver / end user requests a trick play version of the content asset from a PVR server, which generates and provides requested media to the user display/output device associated with receiver / end user).
As to claim 9, Jain et al do not teach that storing the content asset at the second storage device; and storing the trick play version of the content asset at the second storage device separately from the content asset.
Menon et al teach a method comprising: storing the content asset at the second storage device; and storing the trick play version of the content asset at the second storage device separately from the content asset (figure 6, par. 0095, pars. 0026 & 0077, figures 7-8 & 10, pars. 0120-0123, reference teaches that storing the content asset and the portion of the content asset at a second server (replicating the content asset) and the second server separately from the library server).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Menon et al as stated above with the method of Jain et al for storing the content asset and the portion of the content asset at a second server because it would have provided faster access without wasting resources and restricting the ability of the VOD system to handle very large video files or too many users, and also improved the service to manage the distribution or provide the content asset to the multiple users.
As to claim 21, Jain et al do not teach that the causing storage of the trick play version of the content asset at a second storage device comprises causing storage of the trick play version at the second storage device without storing the content asset.
Menon et al teach that the causing storage of the trick play version of the content asset at a second storage device comprises causing storage of the trick play version at the second storage device without storing the content asset (par. 0067, reference teach that each server stores part of the asset and asset information and metadata associated with the asset).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Menon et al as stated above with the method of Jain et al for storing ethe part of the content asset at each server because it would have provided faster access without wasting resources and restricting the ability of the VOD system to handle very large video files or too many users, and also improved the service to manage the distribution or provide the content asset to the multiple users.
As to claim 22, Jain et al teach that the computing device (receiver) comprises a streaming server (figure 5, par. 0049) and the first network storage device (PVR server) comprises a caching gateway (par. 0071).
Claims 10-13 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Jain et al (US Patent Application Publication No. 2005/0183120 A1) in view of Driscoll, III et al (US Patent No. 6,044,405 A).
As to claim 10, Jain et al teach a method comprising: based on a request from a first device (user display/output device associated with receiver / end user), causing sending, by a computing device (receiver), to the first device, and from a network storage device (PVR server), a trick play version of a content asset (figures 1A-1B, pars. 0004-0005, figure 2A, pars. 0035-0037, 0039-0040, figure 5, par. 0046, reference teaches that in response to receiving a request for media content from an end user, receiver sends personal media streams to a user display/output device from a PVR server in response to trick play request); the trick play version is stored at the network storage device (PVR server) separately from the content asset (VOD server), and the network storage device (PVR server) is different than the computing device (receiver) (figure 1B, par. 0005, figure 6, pars. 0056-0057 & 0060, the media and media chunks with labels are stored at PVR server separately from the original media stored at VOD server, and the PVR server is different than the receiver).
However, Jain et al do not teach that causing, based on a geographic location of the first device, storage of the trick play version of the content asset at a second storage device.
Driscoll, III et al teach a method (see abstract and figures 1-2) comprising: causing storing the trick play version of the content asset at the network storage device (primary network hub ) separately from the content asset (sender) (figures 1-2, column 7 lines 43-55, column 11 lines 20-25, storing processed document at the primary network hub); and causing, based on a geographic location of the first device (recipient), storage of the trick play version of the content asset at a second storage device (secondary network hub) (column 2 lines 53-61, figures 1-2, column 7 line 66 to column 8 line 14, column 11 lines 25-37, storing received document at the secondary network hub that is local to the recipient’s geographic location).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Driscoll, III et al as stated above with the method of Jain et al for storing the content asset at a secondary network hub that is local to the recipient’s geographic location because it would have provided data shipping service transmit large data blocks for customers at high speeds between geographically remote locations.
As to claim 11, Jain et al teach that causing sending, to the first device, of the content asset (figure 1A, par. 0004, figure 2A, pars. 0035, figure 5, pars. 0045-0046, reference teaches that PVR server sends personal media stream to a user display/output device via receiver).
As to claim 12, Jain et al teach that causing the trick play version of the content asset (encoded media content and the media chunks with labels) to be transferred from the network storage device (storage device) to a streaming server (streaming module); and causing the streaming server to send the trick play version of the content asset (figure 6 pars. 0056, 0058, 0060).
As to claim 13, Jain et al teach that causing sending, via a streaming server, of the content asset; and determining the network storage device after a determination that the trick play version of the content asset is not stored locally to the streaming server (figure 6, pars. 0062-0064, reference teaches that checks the requested media available at the PVR server or discovers a gap in the stored media being used to generate the stream (determining that the content asset is not stored locally)).
Claim 14 is rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Jain et al (US Patent Application Publication No. 2005/0183120 A1) in view of Driscoll, III et al (US Patent No. 6,044,405 A) as applied to claim 10 above, and further in view of Menon et al (US Patent Application Publication No. 2005/0262246 A1).
As to claim 14, neither Jain et al nor Driscoll, III et al teaches that determining, based on a server load indication, the network storage device.
Menon et al teach that determining, based on a server load indication, the network storage device (figures 2-3, par. 0076, reference teaches that selecting server/storage based on server load).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Menon et al as stated above with the method of Jain et al for determining the network storage device based on a server load indication because it would have provided faster access without wasting resources and restricting the ability of the VOD system to handle very large video files or too many users, and also improved the service to manage the distribution or provide the content asset to the multiple users.
Claims 15 and 17-20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Jain et al (US Patent Application Publication No. 2005/0183120 A1) in view of Friedlander et al (US Patent Application Publication No. 2007/0250512 A1).
As to claim 15, Jain et al teach a method comprising: based on a request from a receiving device (user display/output device associated with receiver / end user), sending, by a computing device (receiver) and to a content delivery system (PVR server), a locate request for a derived version of a content asset (figure 5, pars. 0046, 0050, figure 6 pars. 0052, 0055, receiver requests a specific media including trick play to the PVR server); causing sending, to the receiving device, the derived version of the content asset (figure 5, pars. 0046, figure 6, pars. 0055, 0060, the receiver provides incoming media stream to user display/output device); and causing storage of the derived version of the content asset separately from the content asset at: a network storage device (PVR server/storage device) that is associated with the content asset (VOD server); and the computing device (receiver) (figure 1B, par. 0005, figure 6, pars. 0056-0057 & 0060, the media and media chunks with labels are stored at PVR server separately from the original media stored at VOD server, and the PVR server is different than the receiver).
However, Jain et al do not explicitly teach that generating, by the computing device and based on a locate response indicating the derived version of the content asset is unavailable, the derived version of the content asset.
Friedlander et al teach that generating a derived version of the content asset in response to a locate request for the derived version of the content asset and also based on a locate response indicating the derived version of the content asset is unavailable (figures 1-2, par. 0029 lines 1-6, par. 0031, content server receives a request for off-disc content (derived version / trailers) from media viewing system, figures 1-2, par. 0032, content server determines that the requested content is not locally cached (derived version of the content is unavailable / locate response), figures 1-2, pars. 0032 lines 15-19, par. 0033, content server generates requested content from a studio content server); and causing sending, to a receiving device (user display device associated with media viewing system), the derived version of the content asset (off-disc content / trailers) (figures 1-2, par. 0026 lines 6-13, pars. 0031-0032, content server delivers off-disc content / trailers (requested content) to the user display device associated with media viewing system).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Friedlander et al as stated above with the method of Jain et al for determining that the requested content is unavailable and generating requested content because it would have improved server efficiency by saving storage space, and also improved the service to manage the distribution or provide the content asset to the multiple users.
As to claims 17-19,Jain et al teach that the derived version of the content asset comprises a trick play version of the content asset (figure 5, pars. 0046 & 0050-0051, figure 6, pars. 0062-0063); the generating the derived version of the content asset comprises reformatting the content asset (figure 6, pars. 0052-0057, the encoded media content and the media chunks with labels are the reformatted version of the original media); and the derived version comprises one or more portions of the content asset (figures 5-6, pars. 0051-0053).
As to claim 20, Jain et al do not explicitly teach that the sending the locate request is performed after a determination that the derived version of the content asset is not stored locally.
Friedlander et al teach that the sending the locate request is performed after a determination that the derived version of the content asset is not stored locally (figures 1-2, pars. 0032-0033, content server determines that the requested content is not locally cached (derived version of the content is unavailable / locate response) and content server generates requested content from a studio content server).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Friedlander et al as stated above with the method of Jain et al for determining that the requested content is unavailable and generating requested content because it would have improved server efficiency by saving storage space, and also improved the service to manage the distribution or provide the content asset to the multiple users.
Claim 16 is rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Jain et al (US Patent Application Publication No. 2005/0183120 A1) in view of Friedlander et al (US Patent Application Publication No. 2007/0250512 A1) as applied to claim 15 above, and further in view of Menon et al (US Patent Application Publication No. 2005/0262246 A1).
As to claim 16, neither Jain et al nor Friedlander et al teaches that the causing storage comprises causing, based on an expected request quantity corresponding to the derived version of the content asset, storage of the derived version of the content asset.
Menon et al teach a method comprising: causing, based on an expected request quantity corresponding to the derived version of the content asset, storage of the derived version of the content asset (figure 6, par. 0095, pars. 0026 & 0077, figures 7-8 & 10, pars. 0120-0123, reference teaches that replicating content asset (storing the content asset at a second server) in response to exceed current capacity to serve future requests).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate or combine the teaching of Menon et al as stated above with the method of Jain et al for causing storage of the content asset at a second storage device based on exceed current capacity of a first storage device to serve future requests because it would have provided faster access without wasting resources and restricting the ability of the VOD system to handle very large video files or too many users, and also improved the service to manage the distribution or provide the content asset to the multiple users.
Response to Arguments
Applicant’s amendments and arguments with respect to claims 1-22 filed on September 10, 2025 have been fully considered but they are not deemed to be persuasive for the claims 1-22.
In the remarks, the applicant argues that:
Argument: Jain, however, does not teach the receiver “causing sending” of the personalized media stream based on a request from the user display/output device [the alleged “first device”]. Thus, the cited references do not teach “based on a request from a first device, causing sending, by a computing device, to the first device, and from a first network storage device, a trick play version of a content asset ... wherein the first network storage device is different than the computing device” as in amended claim 1.
Response: Jain et al teach a method comprising: based on a request from a first device (user display/output device associated with receiver / end user), causing sending, by a computing device (receiver), to the first device, and from a network storage device (PVR server), a trick play version of a content asset (figures 1A-1B, pars. 0004-0005, figure 2A, pars. 0035-0037, 0039-0040, figure 5, par. 0046, reference teaches that in response to receiving a request for media content from an end user, receiver sends personal media streams to a user display/output device from a PVR server in response to trick play request); the trick play version is stored at the network storage device (PVR server) separately from the content asset (VOD server), and the network storage device (PVR server) is different than the computing device (receiver) (figure 1B, par. 0005, figure 6, pars. 0056-0057 & 0060, the media and media chunks with labels are stored at PVR server separately from the original media stored at VOD server, and the PVR server is different than the receiver), which implies the claimed invention; therefore, the applicant’s arguments are moot.
Argument: One of ordinary skill would have understood there would be no need to use Menon’s technique that determines when a number of users exceeds a threshold and moving a user to another server because Jain does not provide a connection to a user when the resources are not available. In other words, Menon solves a problem that Jain does not have, in a system that Jain teaches away from using, so a proper combination would need to explain why one of ordinary skill in the art would choose to disregard what the references say. Accordingly, one of ordinary skill in the art would not have combined the references as proposed in the Office Action.
Response: Jain et al disclose a system including a management server and a plurality of multi-user PVR servers (figure 10, par. 0067), and teach that the management server selects a PVR server to provide service based on a service request from a receiver (figure 10, pars. 0068-0069); and Menon et al teach a method comprising: causing, based on an expected request quantity corresponding to the content asset, storage of the trick play version of the content asset at a second storage device associated with the content asset (figure 6, par. 0095, pars. 0026 & 0077, figures 7-8 & 10, pars. 0120-0123, reference teaches that replicating content asset (storing the content asset at a second server) in response to exceed current capacity to serve future requests), which (combination of the references) teaches the claimed invention; therefore, the applicant’s arguments are moot.
Argument: Jain does not teach receiving a request from the user display/output device. Thus, for this additional reason, the proposed combination does not teach
claim 8.
Response: Jain et al teach that receiving a second request for a trick play version of the content asset; causing generation of the trick play version of the content asset; and causing sending of the trick play version of the content asset (figure 2A, pars. 0036-0039, figure 5, par. 0046, figure 6, par. 0062, reference teaches that a user input device associated with receiver / end user requests a trick play version of the content asset from a PVR server, which generates and provides requested media to the user display/output device associated with receiver / end user), which implies the claimed invention; therefore, the applicant’s arguments are moot.
Argument: Jain does not teach or suggest that the receiver at the user-end is a streaming server. Thus, for this additional reason, the proposed combination does not teach claim 22.
Response: Jain et al teach that the computing device (receiver) control and manage media streams with a processor (buffering, decoding, rendering) and a storage device (storing and providing, and act as a streaming server (figure 5, par. 0048-0051) and the first network storage device (PVR server) comprises a caching gateway (figure 8, pars. 0061 & 0071), which implies the claimed invention; therefore, the applicant’s arguments are moot.
Argument: The proposed Jain-Friedlander combination, however, does not teach “generating, by the computing device and based on a locate response indicating the derived version of the content asset is unavailable, the derived version of the content asset” as in claim 15.
Response: Friedlander et al teach that generating a derived version of the content asset in response to a locate request for the derived version of the content asset and also based on a locate response indicating the derived version of the content asset is unavailable (figures 1-2, par. 0029 lines 1-6, par. 0031, content server receives a request for off-disc content (derived version / trailers) from media viewing system, figures 1-2, par. 0032, content server determines that the requested content is not locally cached (derived version of the content is unavailable / locate response), figures 1-2, pars. 0032 lines 15-19, par. 0033, content server generates requested content from a studio content server), which implies the claimed invention; therefore, the applicant’s arguments are moot.
THIS ACTION IS MADE FINAL. 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 extension fee 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.
Content Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Bharat Barot whose telephone number is (571)272-3979. The examiner can normally be reached on 7:00AM-3:30PM.
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, Kamal B Divecha can be reached on (571)272-5863. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BHARAT BAROT/Primary Examiner, Art Unit 2453 November 19, 2025
Prosecution Insights