Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
2. 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.
3. Claims 1, 3, 4, 5, 7, 8, 10, 11, 12, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over EKAMBARAM et al. Pub. No. US 2018/0203793 A1 (hereafter EKAMBARAM) and in further view of VYSOTSKY et al. Pub. No. US 2019/0342378 A1 (hereafter VYSOTSKY) and Amadio et al. Pub. No. US 2014/0320592 A1 (hereafter Amadio).
4. Regarding claim 1, EKAMBARAM teaches “A … system to test websites across a plurality of remote devices ([Abs, 0001-0002] teaches mobile application testing for various types of mobile devices); wherein the system comprising: a user browser installed on a user device that is controlled by at least one processor (EKAMBARAN Fig. 1, [0020-0025] teaches a browser on a computer that includes a processor),
wherein the user browser is used to log-in and connect to a cloud server that comprises representations of the plurality of remote devices wherein the user browser is used to remotely connect to a remote device on the cloud server, (EKAMBARAN Fig. 1, [0021-0025] teaches a shell that enables user access to resources such as application programs, which includes the browser. Browser enables communication with app testing server. Fig. 4 [0039-0040] teaches a cloud service with access to the device list which represents the plurality of mobile devices to be tested).
EKAMBARAN does not explicitly teach a video injection system to test websites on remote devices.
VYSOTSKY teaches a video injection method such that it teaches the limitations “A video injection system to test websites across a plurality of remote devices ([0007-0010] teaches video injection techniques), and wherein the remote device uses a remote device's browser to access a website by performing a network call, which retrieves a web-page response associated with the website; and a proxy layer present in the cloud server intercepts the retrieved web-page response and injects a java-script into the retrieved web-page response,
(Fig. 1 [0026-0032] & Fig. 3 [0068-0071] teach a virtual desktop server that is remote, a proxy that is used to intercept and inject the HTML content from a web server to be retrieved, such that a network call was implicitly made to the web server);
wherein when the user accesses a camera of the remote device via the remote device's browser (Fig. 3 [0045-0047] teaches framework that provides real-time media application; WebRTC API functionality on the client side which allows for users to access the camera of a remote device; VYSOTSKY [0105] shows that API may request to access local media device such as a camera).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the teachings of VYSOTSKY with the invention of EKAMBARAN of implementing a video injection when testing websites on remote devices. A person having ordinary skill in the art would have been motivated to make this combination to optimize real time connection to reduce high latency and low media quality issues when streaming live between remote devices (VYSOTSKY [0008]).
The combination does teach the injected code causing the media stream to redirect with a particular video element (VYSOTSKY [0118-0122]), however it does not explicitly teach that the injected content is a video sample that is captured by the camera of the remote device.
Amadio teaches a virtual camera with views obtained from physical/synthetic cameras into a single video stream such that it teaches the limitation “the injected java-script injects a video sample that was uploaded on a storage platform to the web page response, so that the injected video sample is captured by the camera of the remote device. ([0027] teaches a virtual camera connected to a video pipeline as if it were a real camera. Fig. 4,[0038] teaches the virtual camera establishing connections with frame sources such as a pre-recorded video such that it would be captured from a camera. Fig. 7 [0060-0061] shows a data store which acts as the storage of the video sample).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the teachings of Amadio with the combination of EKAMBARAN and VYSOTSKY, implementing a virtual camera with pre-recorded videos, with the method of injecting a video sample when the camera is accessed. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of simulating a seamless, low latency, low bandwidth usage stream of a camera, and may be beneficial for software that expects an actual camera stream (Amadio [0018-0020]), allowing flexibility and compatibility among devices when testing older remote devices.
5. Regarding claim 8, it is similar to that of claim 1, and is rejected for the same reason. Claim 8 is directed towards “a method (EKAMBARAN [0003])”.
6. Regarding claim 15, it is similar to that of claim 1, and is rejected for the same reason. Claim 15 is directed towards “A non-transitory computer storage (EKAMBARAN [0080])”.
7. Regarding claim 3, the EKAMBARAN teaches that the app testing server may also include or access a database containing reviews, however does not teach it containing a plurality of video samples [0027].
Amadio teaches a data store in communication with a server object such that the data store “The video injection system as claimed in claim 1, further comprising a plurality of video samples that are uploaded on the storage platform that is in communication with the cloud server (Amadio Fig. 7, [0061-0062] teaches the data store 730 may be implemented in accordance with embodiments such that it can store frame sources such as pre-recorded videos [0024])”.
It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the structure of Amadio with the combination of EKAMBARAN and VYSOTSKY, implementing a data store in communication with the cloud testing server. A person having ordinary skill in the art would have been motivated to make this combination for the purpose streamlining video injections with an accessible storage of video samples.
The combination also teaches “and wherein the injected java-script retrieves one of the uploaded video samples from the storage platform and injects the video sample on the remote device's browser when the user accesses the camera of the remote device. (VYSOTSKY [0069-0072], [0129-0130] teaches when a call is started (user accesses camera of another device) the APIs are intercepted before then, reports it to the media app via the server, and creates the place holder such that the sample was retrieved from the second stream and injected into the actual video stream).”
8. Regarding the method of claim 10, it is similar to that of claim 3, and is rejected for the same reason.
9. Regarding claim 4, wherein the combination, VYSOTSKY teaches “The video injection system as claimed in claim 1, wherein when the network call is made to load the website, the website sends the web-page response which contains web components associated with the website, and wherein when the web-page response reaches the proxy layer, the java-script is injected into the web-page response which becomes a part of the user' s web-page source. ([0069-0071] teaches a proxy used to intercept HTML content such that a call was made and the HTML contents are the components of the web-page response, and the java-script is then added by the proxy, causing the app to be intercepted).”
10. Regarding the method of claim 11, it is similar to that of claim 4, and is rejected for the same reason.
11. Regarding claim 5, the combination teaches “The video injection system as claimed in claim 4, wherein once the website loads, and each time the camera is accessed, a call is made to a system function, which is intercepted by the injected java-script to stream one of the uploaded video samples instead of direct video stream from the camera of the remote device and supplies the stream to the website as output of the camera. (VYSOTSKY [0105] teaches the API getUserMedia enabling a call to access a camera, where it is then intercepted by the java-script code (VYSOTSKY [0069-0072]) to redirect the real-time media app to stream a sample video from a virtual as taught in Amadio [0023-0024] to connect to a frame source, such as a pre-recorded video, and stream as if it were a real camera (Amadio [0027])).”
12. Regarding the method of claim 12, it is similar to that of claim 5, and is rejected for the same reason.
13. Regarding claim 7, the combination teaches “The video injection system as claimed in claim 1, wherein the proxy layer that modifies the web page response received by the remote device's browser: converts streaming of the uploaded video sample via the injected java-script into a media stream object (VYSOTSKY [0203], [0217] teaches the WebRTC API getDisplayMedia which captures content as a MediaStream object and the element is intercepted such that it may be the uploading & conversion of a video sample by the java-script injection code); creates a video object from the streamed uploaded video sample, which is played into a canvas object; and generates a media stream object from the canvas object. (VYSOTSKY [0113-0114] teaches after intercepting and redirecting the media, WebRTC renders received video streams by connecting a MediaStream object to an HTML5 video element, such that the media stream object is generated by the HTML5 element, the canvas object).”
14. Regarding the method of claim 14, it is similar to that of claim 7 and is rejected for the same reason.
15. Claims 2 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over EKAMBARAM, VYSOTSKY, and Amadio as used in claims 1 and 8, and in further view of Lilienthal et al. Pub. No. US 2019/0020554 A1 (hereafter Lilienthal).
16. Regarding claim 2, wherein the combination, EKAMBARAN teaches “The video injection system as claimed in claim 1, wherein the cloud server assigns a remote device from the plurality of remote devices (Fig. 4, [0039] teaches the cloud service selects a mobile device based on the documentation of the app to be tested).
The combination does not explicitly teach the screen of the remote device being streamed to the user browser.
Lilienthal teaches a system for remotely viewing a screen image using a web browser such that it teaches the limitation “wherein the cloud server streams the assigned remote device to the user browser so that the user is enabled to view an actual screen of the assigned remote device on the user browser (Fig. 6, [0096] teaches the browser displaying the current screen view of a remote customer device).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the teachings of Lilienthal with the combination of EKAMBARAN, VYSOTSKY, and Amadio for implementing a screen view feature when testing remote devices. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of convenience when testing and ease of establishing connection and accessing many devices rapidly [Lilienthal 0004].
17. Regarding the method of claim 9, it is similar to that of claim 2, and is rejected for the same reason.
18. Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over EKAMBARAM, VYSOTSKY, and Amadio as used in claims 1 and 8, and in further view of MYLAVARAPU et al. Pub. No. US 2024/0314193 A1 (hereafter MYLAVARAPU).
19. Regarding claim 6, the combination does not explicitly teach the proxy server altering the Content-Security-Policies to allow for the injected java-script to be loaded onto the website.
MYLAVARAPU teaches a proxy server modifying a request header to allow non-whitelisted origin requests such that it teaches the limitation “The video injection system as claimed in claim 1, wherein the proxy layer that modifies the web page response received by the remote device's browser alters: the Content-Security-Policies that are set in plurality of response headers to allow the injected java-script to be loaded on the website; and the Cross-origin resource sharing (CORS) policy that is set in the multiple response headers of the web-page response, to enable loading of the uploaded video samples from the storage platform that is not whitelisted on the website under test. ([0018-0024] teaches modifying the initial header request field to avoid a CORS error and allow for loading a request from a non-whitelisted origin).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the teachings of MYLAVARAPU with the combination of EKAMBARAN, VYSOTSKY, and Amadio for implementing a method of updating response headers when injecting samples from non-whitelisted origins. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of overcoming client-side security policies when receiving information from remote destinations. (MYLAVARAPU [0002]).
20. Regarding the method of claim 13, it is similar to that of claim 6, and is rejected for the same reason.
Conclusion
21. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON A NGUYEN whose telephone number is (571)272-6074. The examiner can normally be reached Mon-Fri (10am-6pm).
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, Aimee Li can be reached at (571) 272-4169. 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.
/BRANDON NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195