DETAILED ACTION
Claims 1-16 have been examined and are rejected.
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 .
Claim Status
Claims 1-20 are pending. Applicant responded to the Restriction Requirement and elected, without traverse, Group I, claims 1-16 for examination.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9-16 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 9 recites “A miracast providing system, comprising: an instant cloud server…” However, claim 9 fails to recite that the system comprises a processor. Therefore, claim 9 does not require a processor. It is unclear how the claimed system and instant cloud server can perform the steps in the claims without a processor. This rejection may be overcome by adding the limitation “processor” to claim 9. Claims 10-16 fail to remedy the deficiency of claim 9 and are rejected.
Claim Rejections - 35 USC § 103
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 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.
Claims 1-7 are rejected under 35 U.S.C. 103 as being unpatentable over Bei et al. (U.S. PGPub 2014/0096165) in view of Ito (U.S. PGPub 2021/0409554) further in view of Jin Chang Ki (KR 101970200), hereafter "Ki".
Regarding claim 1, Bei teaches A method of providing miracast, the method comprising: transmitting, by the transmitting device, a second packet constituting the image data to a receiving device through miracast; (Bei, see figs. 1, 10; see paragraphs 0024-0025 ...WFD-capable (e.g., Miracast) device able to receive video content from the source device 12, and display the video content …; a Miracast sink device conforming to the WFD specification…; see paragraph 0024 a packet transmitted to the receiving/sink device, recovery information that allows the sink device to decode a video frame even when some video data corresponding to the video frame...)
checking, by the receiving device, whether the second packet is a damaged packet; (Bei, see figs. 6 and 10; see paragraphs 0089-0090 it is determined that an I-frame has not been received correctly...in response to determining (at block 382) that the I-frame has not been received correctly, the source device is requested to resend at least a portion of the I-frame (i.e., compressed video data corresponding to at least a portion of the I-frame). In one embodiment, for example, the sink device sends the source device a message requesting the IDR picture.)
based on the second packet being a damaged packet, making, by the receiving device, a request for a packet corresponding to the damaged second packet to the instant cloud server; (Bei, see fig. 10; see paragraphs 0089-0090 it is determined that an I-frame has not been received correctly...in response to determining (at block 382) that the I-frame has not been received correctly, the source device is requested to resend at least a portion of the I-frame (i.e., compressed video data corresponding to at least a portion of the I-frame). In one embodiment, for example, the sink device sends the source device a message requesting the IDR picture.)
receiving, by the receiving device, a packet corresponding to the damaged packet through the instant cloud server; (Bei, see fig. 10; see paragraphs 0089-0090 it is determined that an I-frame has not been received correctly...in response to determining (at block 382) that the I-frame has not been received correctly, the source device is requested to resend at least a portion of the I-frame (i.e., compressed video data corresponding to at least a portion of the I-frame). In one embodiment, for example, the sink device sends the source device a message requesting the IDR picture.)
outputting, by the receiving device, the image data; and (Bei, see paragraph 0009 provide, via a wireless channel, a video stream to a sink device for display by the sink device; see paragraph 0025 sink device 14 is any WFD-capable (e.g., Miracast) device able to receive video content from the source device 12, and display the video content on a display 16.)
However, Bei does not explicitly teach generating a URL accessible to an instant cloud server;
transmitting, by a transmitting device, a first packet constituting image data to the instant cloud server through the URL;
Ito teaches generating a URL accessible to an instant cloud server; (Ito, see figs. 7 and 9-10; see paragraphs 0086-0087 uploading the image data to the cloud 102... a parameter specified in the generation of a shared URL. The parameter specified in the information 804 means that the generated shared URL is a URL accessible by anyone...; see paragraphs 0114-0115 image data generated by a document being read on the image processing apparatus 101 in a shared office or a coworking space is easily available for a user via a URL generated by the cloud 102.... the cloud 102 to generate a shared URL ...)
transmitting, by a transmitting device, a first packet constituting image data to the instant cloud server through the URL; (Ito, see figs. 7 and 9-10; see paragraphs 0086-0087 uploading the image data to the cloud 102... a parameter specified in the generation of a shared URL. The parameter specified in the information 804 means that the generated shared URL is a URL accessible by anyone...; see paragraphs 0114-0115 image data generated by a document being read on the image processing apparatus 101 in a shared office or a coworking space is easily available for a user via a URL generated by the cloud 102.... the cloud 102 to generate a shared URL ...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Bei and Ito to provide the technique of generating a URL accessible to an instant cloud server and transmitting, by a transmitting device, a first packet constituting image data to the instant cloud server through the URL of Ito in the system of Bei in order to allow a content of the file to be displayed on a browser or a file to be downloaded via the URL (Ito, see paragraph 0008).
However, Bei-Ito does not explicitly teach deleting the URL based on terminating the connection between the transmitting device and the receiving device.
Ki teaches deleting the URL based on terminating the connection between the transmitting device and the receiving device. (Ki, see page 5, paragraph 5 - page 6, paragraph 1 when the communication session is disconnected , the information receiver 220 can delete the URL information…)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Bei-Ito and Ki to provide the technique of deleting the URL based on terminating the connection between the transmitting device and the receiving device of Ki in the system of Bei-Ito in order to protect personal information (Ki, see page 5, paragraph 1).
Regarding claim 2, Bei-Ito-Ki teaches further comprising recording, by the transmitting device, numbering information in a packet transmitted to the instant cloud server and a packet transmitted to the receiving device. (Bei, see fig. 6; see paragraph 0071 recovery information is identified in the current packet received at block 302. The recovery information is indicative of an arrangement of an earlier portion of the compressed video data, and/or content of the earlier portion of the compressed video data)
Regarding claim 3, Bei-Ito-Ki teaches wherein the receiving device receives the packet corresponding to the damaged packet through the instant cloud server based on the numbering information. (Bei, see fig. 6; see paragraphs 0070-0071 it is determined either that an earlier packet (of the plurality of packets) that was received by the sink device contains errors, or that the earlier packet was lost...recovery information is identified in the current packet received at block 302. The recovery information is indicative of an arrangement of an earlier portion of the compressed video data, and/or content of the earlier portion of the compressed video data)
Regarding claim 4, Bei-Ito-Ki teaches further comprising, based on a packet received for a first time or more being the damaged packet, receiving, by the receiving device, the packet corresponding to the damaged packet for a second time through the instant cloud server. (Bei, see fig. 10; see paragraphs 0089-0090 it is determined that an I-frame has not been received correctly...in response to determining (at block 382) that the I-frame has not been received correctly, the source device is requested to resend at least a portion of the I-frame (i.e., compressed video data corresponding to at least a portion of the I-frame). In one embodiment, for example, the sink device sends the source device a message requesting the IDR picture.)
Regarding claim 5, Bei-Ito-Ki teaches wherein the instant cloud server comprises at least one of a network storage or a local storage. (Bei, fig. 1; see paragraph 0025 y accessing a video file stored in source device 12, etc.)…; see paragraph 0061 video initially stored as a file at the source device (e.g., in memory 27 of FIG. 1), or video initially downloaded (e.g., as a live video feed) from the Internet by the source device. )
Regarding claim 6, Bei-Ito-Ki teaches wherein the second packet comprises a plurality of frames constituting the image data. (Bei, see figs. 5-6; see abstract video frames of a plurality of video frames in the video stream, such that the one or more video frames are not provided to the sink device, reconfiguring a video encoder operating on the plurality of video frames,...; see paragraph 0024 allows the sink device to decode a video frame even when some video data corresponding to the video frame, and/or corresponding to an earlier video frame, ... providing a mechanism for resending I-frames that are not received correctly.)
Regarding claim 7, Bei-Ito-Ki teaches further comprising: receiving a transmission scheme switching input from a user; and (Ito, see figs. 7; see paragraph 0069 the user instructs a start to the image processing apparatus 101 to start the image processing apparatus 101.; see paragraph 0074 cloud 102 receives the image data via the communication unit 503 from the image processing apparatus 101. In step S707, the CPU 401 of the cloud 102 instructs the file management unit 504 to store the received image data in the HDD 404...)
receiving, by the receiving device, a packet through the instant cloud server based on the transmission scheme switching input. (Ito, see figs. 7; see paragraph 0069 the user instructs a start to the image processing apparatus 101 to start the image processing apparatus 101.; see paragraph 0074 cloud 102 receives the image data via the communication unit 503 from the image processing apparatus 101. In step S707, the CPU 401 of the cloud 102 instructs the file management unit 504 to store the received image data in the HDD 404...) The motivation regarding to the obviousness to claim 1 is also applied to claim 7.
Claims 8 and 16 rejected under 35 U.S.C. 103 as being unpatentable over Bei-Ito-Ki in view of Kim et al. (U.S. PGPub 2014/0226561).
Regarding claim 8, Bei-Ito-Ki teaches all of the features of claim 1. However, Bei-Ito-Ki does not explicitly teach further comprising deleting, by the instant cloud server, the first packet received from the transmitting device based on terminating the connection between the transmitting device and the receiving device.
Kim teaches further comprising deleting, by the instant cloud server, the first packet received from the transmitting device based on terminating the connection between the transmitting device and the receiving device. (Kim, see paragraph 0019 indicate that user equipment has terminated a communication session associated with a video or multimedia service. For example, a base station can be configured to determine a port number associated with the communication session in the reset message. The base station can then remove packets associated with the communication session from a transmit buffer so that the packets are not transmitted subsequently to the user equipment...; see paragraph 0006 Terminating a communication session may cause buffered or in-flight packets to be discarded without being played back.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Bei-Ito-Ki and Kim to provide the technique of deleting, by the instant cloud server, the first packet received from the transmitting device based on terminating the connection between the transmitting device and the receiving device of Kim in the system of Bei-Ito-Ki in order to improve throughput of a service (Kim, see paragraph 0033).
Regarding claim 16, Bei-Ito teaches all of the features of claim 9. However, Bei-Ito does not explicitly teach wherein the instant cloud server deletes the URL and
Ki teaches wherein the instant cloud server deletes the URL and (Ki, see page 5, paragraph 5 - page 6, paragraph 1 when the communication session is disconnected , the information receiver 220 can delete the URL information…)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Bei-Ito and Ki to provide the technique of deleting the URL based on terminating the connection between the transmitting device and the receiving device of Ki in the system of Bei-Ito in order to protect personal information (Ki, see page 5, paragraph 1).
However, Bei-Ito-Ki does not explicitly teach deleting the first packet received from the transmitting device based on terminating the connection between the transmitting device and the receiving device.
Kim teaches deleting the first packet received from the transmitting device based on terminating the connection between the transmitting device and the receiving device. (Kim, see paragraph 0019 indicate that user equipment has terminated a communication session associated with a video or multimedia service. For example, a base station can be configured to determine a port number associated with the communication session in the reset message. The base station can then remove packets associated with the communication session from a transmit buffer so that the packets are not transmitted subsequently to the user equipment...; see paragraph 0006 Terminating a communication session may cause buffered or in-flight packets to be discarded without being played back.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Bei-Ito-Ki and Kim to provide the technique of deleting the first packet received from the transmitting device based on terminating the connection between the transmitting device and the receiving device of Kim in the system of Bei-Ito-Ki in order to improve throughput of a service (Kim, see paragraph 0033).
Claims 9-15 rejected under 35 U.S.C. 103 as being unpatentable over Bei et al. (U.S. PGPub 2014/0096165) in view of Ito (U.S. PGPub 2021/0409554).
Regarding claim 9, Bei teaches A miracast providing system, comprising: a receiving device receiving and outputting image data; (Bei, see paragraph 0009 provide, via a wireless channel, a video stream to a sink device for display by the sink device; see paragraph 0025 sink device 14 is any WFD-capable (e.g., Miracast) device able to receive video content from the source device 12, and display the video content on a display 16.)
transmit a second packet constituting the image data to the receiving device through miracast, (Bei, see figs. 1, 10; see paragraphs 0024-0025 ...WFD-capable (e.g., Miracast) device able to receive video content from the source device 12, and display the video content …; a Miracast sink device conforming to the WFD specification…; see paragraph 0024 a packet transmitted to the receiving/sink device, recovery information that allows the sink device to decode a video frame even when some video data corresponding to the video frame...)
wherein based on the second packet being a damaged packet, the receiving device makes a request for a packet corresponding to the damaged second packet to the instant cloud server and receives a packet corresponding to the damaged packet through the instant cloud server. (Bei, see fig. 10; see paragraphs 0089-0090 it is determined that an I-frame has not been received correctly...in response to determining (at block 382) that the I-frame has not been received correctly, the source device is requested to resend at least a portion of the I-frame (i.e., compressed video data corresponding to at least a portion of the I-frame). In one embodiment, for example, the sink device sends the source device a message requesting the IDR picture.)
However, Bei does not explicitly teach an instant cloud server generating an accessible URL;
a transmitting device configured to transmit a first packet constituting image data to the instant cloud server through the URL and
Ito teaches an instant cloud server generating an accessible URL; (Ito, see figs. 7 and 9-10; see paragraphs 0086-0087 uploading the image data to the cloud 102... a parameter specified in the generation of a shared URL. The parameter specified in the information 804 means that the generated shared URL is a URL accessible by anyone...; see paragraphs 0114-0115 image data generated by a document being read on the image processing apparatus 101 in a shared office or a coworking space is easily available for a user via a URL generated by the cloud 102.... the cloud 102 to generate a shared URL ...)
a transmitting device configured to transmit a first packet constituting image data to the instant cloud server through the URL and (Ito, see figs. 7 and 9-10; see paragraphs 0086-0087 uploading the image data to the cloud 102... a parameter specified in the generation of a shared URL. The parameter specified in the information 804 means that the generated shared URL is a URL accessible by anyone...; see paragraphs 0114-0115 image data generated by a document being read on the image processing apparatus 101 in a shared office or a coworking space is easily available for a user via a URL generated by the cloud 102.... the cloud 102 to generate a shared URL ...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Bei and Ito to provide the technique of generating a URL accessible to an instant cloud server and transmitting, by a transmitting device, a first packet constituting image data to the instant cloud server through the URL of Ito in the system of Bei in order to allows the content of the file to be displayed on a browser or the file to be downloaded via the URL (Ito, see paragraph 0008).
Regarding claim 10, Bei-Ito teaches wherein the transmitting device records numbering information in a packet transmitted to the instant cloud server and a packet transmitted to the receiving device. (Bei, see fig. 6; see paragraph 0071 recovery information is identified in the current packet received at block 302. The recovery information is indicative of an arrangement of an earlier portion of the compressed video data, and/or content of the earlier portion of the compressed video data)
Regarding claim 11, Bei-Ito teaches wherein the receiving device receives the packet corresponding to the damaged packet through the instant cloud server based on the numbering information. (Bei, see fig. 6; see paragraphs 0070-0071 it is determined either that an earlier packet (of the plurality of packets) that was received by the sink device contains errors, or that the earlier packet was lost...recovery information is identified in the current packet received at block 302. The recovery information is indicative of an arrangement of an earlier portion of the compressed video data, and/or content of the earlier portion of the compressed video data)
Regarding claim 12, Bei-Ito teaches wherein based on a packet received for a first time or more being the damaged packet, the receiving device receives the packet corresponding to the damaged packet for a second time through the instant cloud server. (Bei, see fig. 10; see paragraphs 0089-0090 it is determined that an I-frame has not been received correctly...in response to determining (at block 382) that the I-frame has not been received correctly, the source device is requested to resend at least a portion of the I-frame (i.e., compressed video data corresponding to at least a portion of the I-frame). In one embodiment, for example, the sink device sends the source device a message requesting the IDR picture.)
Regarding claim 13, Bei-Ito teaches wherein the instant cloud server comprises at least one of a network storage or a local storage. (Bei, fig. 1; see paragraph 0025 y accessing a video file stored in source device 12, etc.)…; see paragraph 0061 video initially stored as a file at the source device (e.g., in memory 27 of FIG. 1), or video initially downloaded (e.g., as a live video feed) from the Internet by the source device. )
Regarding claim 14, Bei-Ito teaches wherein the second packet comprises a plurality of frames constituting the image data. (Bei, see figs. 5-6; see abstract video frames of a plurality of video frames in the video stream, such that the one or more video frames are not provided to the sink device, reconfiguring a video encoder operating on the plurality of video frames,...; see paragraph 0024 allows the sink device to decode a video frame even when some video data corresponding to the video frame, and/or corresponding to an earlier video frame, ... providing a mechanism for resending I-frames that are not received correctly.)
Regarding claim 15, Bei-Ito teaches wherein the receiving device is configured to receive a transmission scheme switching input from a user and (Ito, see figs. 7; see paragraph 0069 the user instructs a start to the image processing apparatus 101 to start the image processing apparatus 101.; see paragraph 0074 cloud 102 receives the image data via the communication unit 503 from the image processing apparatus 101. In step S707, the CPU 401 of the cloud 102 instructs the file management unit 504 to store the received image data in the HDD 404...)
receive a packet through the instant cloud server based on the transmission scheme switching input. (Ito, see figs. 7; see paragraph 0069 the user instructs a start to the image processing apparatus 101 to start the image processing apparatus 101.; see paragraph 0074 cloud 102 receives the image data via the communication unit 503 from the image processing apparatus 101. In step S707, the CPU 401 of the cloud 102 instructs the file management unit 504 to store the received image data in the HDD 404...) The motivation regarding to the obviousness to claim 9 is also applied to claim 15.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
U.S. PGPub 2018/0278947, which describes a device adapted to extract a reference frame coded by intra-frame compression from an image stream;
U.S. PGPub 2020/0322694, which describes using non-reference perceptual video quality analysis (NR VQA) scores, network statistics and machine learning techniques, with user device and video source pairs to produce a network scoring system that can approximate a video mean opinion score (VMOS) for streaming video without decrypting the streaming video; and
U.S. PGPub 2015/0067819, which describes a method for fetching a content from a web server to a client device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG VANG whose telephone number is (571)270-7023. The examiner can normally be reached M-F 8AM-2PM, 3PM-5PM.
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, NICHOLAS TAYLOR can be reached at (571) 272-3889. 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.
/MENG VANG/
Primary Examiner, Art Unit 2443