Detailed Action
Claims 1-20 are pending
Claims 1-20 are rejected.
Double Patenting
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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12177280. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims have a broader scope than the patent claims.
Instant claims
Patent Claims
1. An ultra-low latency server system comprising: - a first hardware platform comprising a processor and an operating system; - a first network connection; - an ultra-low latency remote service executing within said operating system and on the processor, wherein the processor causes the ultra-low latency remote service to: - receive a rendered image of an application executing on the processor, the rendered image comprising a plurality of frames that do not include a cursor image in the plurality of frames; - generate a video stream from the rendered image using video compression and encoding techniques that use data from one or more frames to compress information in later frames; - transmit the video stream over the first network connection to a remote browser operating on a client device; wherein the ultra-low latency server system is configured to establish the first network connection by receiving a connection request from the client device comprising the remote browser having a JavaScript engine, and transmitting connection instructions to the remote browser, wherein the connection instructions comprise a hyper-text markup language (HTML) page and executable JavaScript and cursor information, the cursor information comprising cursor location information representing a location of the cursor in each frame of the plurality of frames before the cursor image was removed and cursor image information comprising a bitmap of the cursor to facilitate rendering of the cursor by the remote browser; whereby, in use, a user of the remote browser experiences real-time or near real-time control of the application executing on the processor of the first hardware platform.
1. An ultra-low latency server system comprising: - a first hardware platform comprising a processor and an operating system; - a first network connection; - an ultra-low latency remote service executing within said operating system and on the processor, wherein the processor causes the ultra-low latency remote service to: - receive a rendered image of an application executing on the processor, the rendered image comprising a plurality of frames; remove a cursor image from each frame of the plurality of frames of the rendered image; - generate a video stream from the rendered image using video compression and encoding techniques that use data from one or more frames to compress information in later frames, whereby latency is introduced into the system, the video compression and encoding techniques having a configuration setting that facilitate adjusting the encoding technique; - transmit the video stream over the first network connection to a remote browser operating on a client device; wherein the ultra-low latency server system is configured to establish the first network connection by receiving a connection request from the client device comprising the remote browser having a JavaScript engine, and transmitting connection instructions to the remote browser, wherein the connection instructions comprise a hyper-text markup language (HTML) page and executable JavaScript and cursor information, the cursor information comprising cursor location information representing a location of the cursor in each frame of the plurality of frames before the cursor image was removed and cursor image information comprising a bitmap of the cursor to facilitate rendering of the cursor by the remote browser; wherein embedding the executable JavaScript in the HTML page permits the remote browser on the client device to execute the application of the processor without creating, supporting, and downloading native applications that would be specific to each hardware and software platform of any client device; wherein the video compression and encoding techniques are tuned to minimize buffering by using a minimum number of the plurality of frames during a compression process to reduce the latency in the system; wherein the connection instructions further comprise executable code that, when executed, captures at least a portion of the cursor information within the remote browser, receives the cursor information from the remote browser; and transmits the cursor information to the application; whereby, in use, a user of the remote browser experiences real-time or near real-time control of the application executing on the processor of the first hardware platform.
2. The ultra-low latency server system of claim 1, wherein the processor further causes the remote service to: receive the connection request from the remote browser, the connection request comprising displayable screen dimensions on the remote browser.
2. The ultra-low latency server system of claim 1, wherein the processor further causes the remote service to: receive the connection request from the remote browser, the connection request comprising displayable screen dimensions on the remote browser.
3. The ultra-low latency server system of claim 2, wherein the displayable screen dimensions are smaller than dimensions of the rendered image.
3. The ultra-low latency server system of claim 2, wherein the displayable screen dimensions are smaller than dimensions of the rendered image.
4. The ultra-low latency server system of claim 2, wherein the processor further causes the remote service to: generate the video stream to match the displayable screen dimensions.
4. The ultra-low latency server system of claim 2, wherein the processor further causes the remote service to: generate the video stream to match the displayable screen dimensions.
5. The ultra-low latency server system of claim 2, wherein the processor further causes the remote service to: cause the rendered image to match the displayable screen dimensions.
5. The ultra-low latency server system of claim 2, wherein the processor further causes the remote service to: cause the rendered image to match the displayable screen dimensions.
6. The ultra-low latency server system of claim 2, the remote browser being configured to pan and/or zoom the video stream.
6. The ultra-low latency server system of claim 2, the remote browser being configured to pan and/or zoom the video stream.
7. The ultra-low latency server system of claim 2, wherein the processor further causes the remote service to: receive updated displayable screen dimensions from the remote browser; and change the video stream to match the updated displayable screen dimensions.
7. The ultra-low latency server system of claim 2, wherein the processor further causes the remote service to: receive updated displayable screen dimensions from the remote browser; and change the video stream to match the updated displayable screen dimensions.
8. The ultra-low latency server system of claim 1, wherein the processor further causes the remote service to: transmit a cursor identifier, the cursor identifier identifying a displayed cursor by the application.
8. The ultra-low latency server system of claim 1, wherein the processor further causes the remote service to: transmit a cursor identifier, the cursor identifier identifying a displayed cursor by the application.
9. The ultra-low latency server system of claim 8, wherein the processor further causes the remote service to: transmit a cursor boundary, the cursor boundary identifying a region within the video stream for which the cursor identifier is valid.
9. The ultra-low latency server system of claim 8, wherein the processor further causes the remote service to: transmit a cursor boundary, the cursor boundary identifying a region within the video stream for which the cursor identifier is valid.
10. The ultra-low latency server system of claim 9, wherein the video stream comprises an audio channel.
10. The ultra-low latency server system of claim 9, wherein the video stream comprises an audio channel.
11. The ultra-low latency server system of claim 2 further comprising: a connection management system executing the processor, the connection management system that: receives, and optionally authenticates, the connection request from the remote browser, the connection request being for remote access to an application server through the remote browser, wherein the connection request comprises the displayable screen dimensions for the remote browser; determines a set of configuration settings for the application server; causes the application server to be configured with the set of configuration settings; determines a set of connection settings for the remote browser; and transmits the set of connection settings to the remote browser; the connection management system optionally comprising a load balancer that selects the application server from a plurality of application servers.
11. The ultra-low latency server system of claim 2 further comprising: a connection management system executing the processor, the connection management system that: receives, and optionally authenticates, the connection request from the remote browser, the connection request being for remote access to an application server through the remote browser, wherein the connection request comprises the displayable screen dimensions for the remote browser; determines a set of configuration settings for the application server; causes the application server to be configured with the set of configuration settings; determines a set of connection settings for the remote browser; and transmits the set of connection settings to the remote browser; the connection management system optionally comprising a load balancer that selects the application server from a plurality of application servers.
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 1-20 are 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 1 states “a location of the cursor in each frame of the plurality of frames before the cursor image was removed” which implies that the plurality of frames used to include the cursor image. However, the claim never stated the removing of the cursor image and explicitly states “a plurality of frames that do not include a cursor image in the plurality of frames”. Thus, it is not clear how the cursor image was removed from the plurality of frames if the plurality of frames never included a cursor image.
Claims 2-10 depends on claim 1 and are rejected under the same rationale.
Claims 12-20 contains a similar language and are rejected under the same rationale.
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 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 of this title, 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, 12-13 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kacmarcik et al (US 2015/0188973 A1) in view of Kominac (US 2012/0151371 A1) and Gilboa et al (US 2012/0011280 A1).
Regarding claim 1, Kacmarcik discloses: an ultra-low latency server system comprising: - a first hardware platform comprising a processor and an operating system (Kacmarcik, Fig 1 item 104, 152 or 162);- a first network connection (Kacmarcik, Fig 1, paragraph 0022);- an ultra-low latency remote service executing within said operating system and on the processor (Kacmarcik, Fig 1, paragraph 0023-0024), wherein the processor causes the ultra-low latency remote service to: - receive a rendered image of an application executing on the processor, the rendered image comprising a plurality of frames that do not include a cursor image in the plurality of frames (Kacmarcik, Fig 1-2, paragraph 0028, Computing service module 166 may be further configured to use video codec 175 to compress or encode images of server runtime/desktop 172 (including open cloud-application window 173) as image frames in a video stream (e.g., video stream 200, FIG. 2) to be transmitted over network 190 to project a remote desktop on computing device 102);- generate a video stream from the rendered image using video compression and encoding techniques that use data from one or more frames to compress information in later frames(Kacmarcik, Fig 1-2, paragraph 0028, Computing service module 166 may be further configured to use video codec 175 to compress or encode images of server runtime/desktop 172 (including open cloud-application window 173) as image frames in a video stream (e.g., video stream 200, FIG. 2) to be transmitted over network 190 to project a remote desktop on computing device 102); - transmit the video stream over the first network connection to a remote browser operating on a client device (Kacmarcik, Fig 1-2, paragraph 0028-0030, Computing service module 166 may be further configured to use video codec 175 to compress or encode images of server runtime/desktop 172 (including open cloud-application window 173) as image frames in a video stream (e.g., video stream 200, FIG. 2) to be transmitted over network 190 to project a remote desktop on computing device 102), - wherein the ultra-low latency server system is configured to establish the first network connection by receiving a connection request from the client device comprising the remote browser (Kacmarcik, Fig 1-2, paragraph 0026, 0028-0030, Computing service module 166 may be further configured to use video codec 175 to compress or encode images of server runtime/desktop 172 (including open cloud-application window 173) as image frames in a video stream (e.g., video stream 200, FIG. 2) to be transmitted over network 190 to project a remote desktop on computing device 102);- whereby, in use, a user of the remote browser experiences real-time or near real-time control of the application executing on the processor of the first hardware platform (Kacmarcik, Fig 1-2, paragraph 0026-0028, Cloud computing service module 166 may be configured so that when a user of computing device 102 selects, for example, a network-hosted file or document (e.g., network-hosted file 170) from cloud data storage (e.g., cloud data storage service 158) for opening or processing, cloud computing service module 166 selects an appropriate network-hosted application (e.g., network-hosted application 171) to open or process network-hosted file 170 on server 160). Kacmarcik does not explicitly disclose that remote browser having a JavaScript engine wherein the connection instructions comprise a hyper-text markup language (HTML) page and executable JavaScript and cursor location information representing a location of the cursor in each frame of the plurality of frames before the cursor image was removed and cursor image information comprising a bitmap of the cursor to facilitate rendering of the cursor by the remote browser. However, Kominac discloses that remote browser having a JavaScript engine wherein the connection instructions comprise a hyper-text markup language (HTML) page and executable JavaScript (Kominac, Fig 1, paragraph 0057, wherein the present disclosure can include or utilize a HTML5 compatible web browser having a 2D canvas, e.g., 530 in FIG. 5. The HTML5 specification provides for a 2D canvas, which allows for dynamic, real-time, scriptable rendering of 2D shapes and bitmap images. In one aspect, being scriptable can mean or include reference to utilizing JavaScript for rendering a 2D image. The canvas consists of a drawable region defined in HTML code with height and width attributes. JavaScript code may access the area through a full set of drawing functions similar to other common 2D APIs, thus allowing for dynamically generated graphics) and cursor location information representing a location of the cursor in each frame of the plurality of frames before the cursor image was removed (Kominac, Fig 1, Fig 2A, paragraph 0076, wherein the remote desktop client adapter 350 may receive a user's input information, data, or commands (e.g., mouse, keyboard, and touch events) from HTTP handler 344 and translate the input information/commands into respective remote desktop input calls).
Therefore, it would have been obvious to an ordinary skilled person in the art before the effective filing date of the invention to combine Kacmarcik and Kominac as claimed because this would have provided a way to allow remote desktop session via HTML and JavaScript which eliminates the need to have a protocol-specific software application that executes on the user's specific operating system and platform or plug-in for a specific browser (see Kominac abstract, paragraph 0003).Kacmarcik and Kominac do not explicitly disclose that:- the cursor image information comprising a bitmap of the cursor to facilitate rendering of the cursor by the remote browser. However, Gilboa discloses that:- the cursor image information comprising a bitmap of the cursor to facilitate rendering of the cursor by the remote browser (Gilboa, paragraph 0042, wherein “Returning to FIG. 1A, in both client mouse mode and server mouse mode, cursor graphics information is sent from server 110 to client 105. Cursor graphics information may include a bitmap of the cursor, a palette) and a mask of the cursor (which identifies what areas of background are hidden by cursor, which areas are not hidden, and which areas are a combination of the cursor and the background). In one embodiment, the cursor graphics information is sent to client 105 when the cursor graphics information changes”).
Therefore, it would have been obvious to a an ordinary skilled person in the art before the effective filing date of the invention to combine Kacmarcik and Kominac in view of Gilboa to include bitmap of the cursor as claimed because this would have provided a way to reduce high latency and improve the performance of the system (see Gilboa paragraph 0004).
Claims 12-13 and 17 are rejected under the same rationale as claim 1.
Claims 2-7, 11, 14-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kacmarcik et al (US 2015/0188973 A1) in view of Kominac (US 2012/0151371 A1), Gilboa et al (US 2012/0011280 A1) and Yamta et al (US 2013/0117659 A1).
Regarding claim 2, Claim 1 is incorporated and discloses Kacmarcik wherein the remote service further causes the processor to: receive the connection request from the remote browser (Kacmarcik, Fig 1-2, paragraph 0026-0028, Cloud computing service module 166 may be configured so that when a user of computing device 102 selects, for example, a network-hosted file or document (e.g., network-hosted file 170) from cloud data storage (e.g., cloud data storage service 158) for opening or processing, cloud computing service module 166 selects an appropriate network-hosted application (e.g., network-hosted application 171) to open or process network-hosted file 170 on server 160). Kacmarcik, Kominac and Gilboa do not explicitly disclose wherein the connection request comprising displayable screen dimensions on the remote browser. However, Yamta further discloses: wherein the connection request comprising displayable screen dimensions on the remote browser (Yamta, abstract, Fig 2 item 224, Fig 3 steps 315-325, paragraph 0031-0033, where the web client application 110 sends a request for application content 222. According to embodiments, the desired size input parameter may be sent to the server 104 as part of a request).
Therefore, it would have been obvious to a an ordinary skilled person in the art before the effective filing date of the invention to combine Kacmarcik and Kominac and Gilboa in view of Yamta to include the displayable screen dimensions on the remote browser in the request as claimed because this would have provided a way to reduce the video/image size to the available area in the browser which reduces the load in the network and improves the efficiency of the system (see Yamta paragraph 0033).
Regarding claim 3, Claim 2 is incorporated and Yamta further discloses: wherein the displayable screen dimensions are smaller than dimensions of the rendered image (Yamta, abstract, Fig 2 item 224, Fig 3 steps 315-325, paragraph 0031-0033, generate the requested application content 222 using the desired size input parameter to determine an optimal image size for the target display resolution).
Regarding claim 4, Claim 2 is incorporated and Kacmarcik and Yamta further discloses: wherein the remote service further causes the processor to: generate the video stream to match the displayable screen dimensions (Kacmarcik, paragraph 0017, 0042-0043, Yamta, abstract, Fig 2 item 224, Fig 3 steps 315-325, paragraph 0031-0033, generate the requested application content 222 using the desired size input parameter to determine an optimal image size for the target display resolution));
Regarding claim 5, Claim 2 is incorporated and Kacmarcik and Yamta further discloses: wherein the remote service further causes the processor to: cause the rendered image to match the displayable screen dimensions (Kacmarcik, paragraph 0017, 0042-0043, Yamta, abstract, Fig 2 item 224, Fig 3 steps 315-325, paragraph 0031-0033, generate the requested application content 222 using the desired size input parameter to determine an optimal image size for the target display resolution));
Regarding claim 6, Claim 2 is incorporated and Kacmarcik and Kominac and Gilboa in view of Yamta do not explicitly disclose: the remote browser being configured to pan and/or zoom the video stream. However, having a pan and/or zoom function in a browser to zoon/pan video content is well known in the art.
Therefore, it would have been obvious to a an ordinary skilled person in the art before the effective filing date of the invention to modify Kacmarcik and Kominac, Gilboa and Yamta to include pan/zoom function as claimed because this would have provided a way to improve the user experience and achieve better user satisfaction.
Regarding claim 7, Claim 2 is incorporated and Kacmarcik and Yamta further discloses: wherein the processor further causes the remote service to: receive updated displayable screen dimensions from the remote browser; and change the video stream to match the updated displayable screen dimensions (Kacmarcik, paragraph 0017, 0042-0043, Yamta, abstract, Fig 2 item 224, Fig 3 steps 315-325, paragraph 0031-0033, generate the requested application content 222 using the desired size input parameter to determine an optimal image size for the target display resolution));
Regarding claim 11, Claim 2 is incorporated and Kominac and Yamta further discloses: connection management system executing the processor, the connection management system that: receives, and optionally authenticates, the connection request from the remote browser, the connection request being for remote access to an application server through the remote browser (Kacmarcik, Fig 1-2, paragraph 0026-0028, Cloud computing service module 166 may be configured so that when a user of computing device 102 selects, for example, a network-hosted file or document (e.g., network-hosted file 170) from cloud data storage (e.g., cloud data storage service 158) for opening or processing, cloud computing service module 166 selects an appropriate network-hosted application (e.g., network-hosted application 171) to open or process network-hosted file 170 on server 160), wherein the connection request comprises the displayable screen dimensions for the remote browser (Yamta, abstract, Fig 2 item 224, Fig 3 steps 315-325, paragraph 0031-0033, where the web client application 110 sends a request for application content 222. According to embodiments, the desired size input parameter may be sent to the server 104 as part of a request); determines a set of configuration settings for the application server; causes the application server to be configured with the set of configuration settings (Yamta, abstract, Fig 2 item 224, Fig 3, paragraph 0031-0033, where generate the requested application content 222 using the desired size input parameter to determine an optimal image size for the target display resolution. The server 104 may open the file containing the requested content 222, which may be a presentation file, and start rendering the content, for example, slides within the presentation. The server 104 may use the web client application-provided desired size input parameter to determine an optimal size for the target display resolution and dynamically generate images 222 that are sized appropriately); determines a set of connection settings for the remote browser; and transmits the set of connection settings to the remote browser; the system optionally comprising a load balancer that selects the application server from a plurality of application servers (Yamta, abstract, Fig 2 item 224, Fig 3, paragraph 0036, where the server 104 sends the requested application content 222 to the web client application 110, the application content 222 being rendered according to the desired size input parameter. At OPERATION 335, the web client application 110 receives the application content 222 and displays the content in the web browser pane 202).
Claims 14-16 and 18-20 are rejected under the same rationale as claims 2-11.
Claims 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Kacmarcik et al (US 2015/0188973 A1) in view of Kominac (US 2012/0151371 A1), Gilboa et al (US 2012/0011280 A1), and Miyamoto et al (US 2013/0050275 A1).
Regarding claim 8, Claim 2 is incorporated and Kacmarcik and Kominac and Gilboa in view of Yamta do not explicitly disclose: wherein the remote service further causes the processor to: transmit a cursor identifier, the cursor identifier identifying a displayed cursor by the application. However, Miyamoto discloses wherein the remote service further causes the processor to: transmit a cursor identifier, the cursor identifier identifying a displayed cursor by the application (Miyamoto, paragraph 0008, wherein the server creates drawing data, which is to be displayed, corresponding to the input event transmitted from the client to the server, and then creates a table in which cursor IDs are related to object area information included in the drawing data. The server transmits the created table and drawing data to the client. The client moves the mouse cursor in a state in which the drawing data corresponding to the input event is displayed. The client then determines, from the table, the cursor ID in the object area corresponding to the position to which the mouse cursor has been moved, and draws the shape of the mouse cursor corresponding to the cursor ID at the position to which the mouse cursor has been moved).
Therefore, it would have been obvious to a an ordinary skilled person in the art before the effective filing date of the invention to modify Kacmarcik and Kominac, Gilboa and Yamta with Miyamoto to include cursor identifier as claimed because this would reduce a communication frequency involved in mouse cursor movement in the server drawing method which reduces the load in the network and improves the efficiency of the system (see Miyamoto paragraph 0008).
Regarding claim 9, Claim 8 is incorporated and Miyamoto further discloses: wherein the processor further causes the remote service to: transmit a cursor boundary, the cursor boundary identifying a region within the video stream for which the cursor identifier is valid (Miyamoto, paragraph 0008, wherein the server creates drawing data, which is to be displayed, corresponding to the input event transmitted from the client to the server, and then creates a table in which cursor IDs are related to object area information included in the drawing data. The server transmits the created table and drawing data to the client. The client moves the mouse cursor in a state in which the drawing data corresponding to the input event is displayed. The client then determines, from the table, the cursor ID in the object area corresponding to the position to which the mouse cursor has been moved, and draws the shape of the mouse cursor corresponding to the cursor ID at the position to which the mouse cursor has been moved
Regarding claim 10, Claim 9 is incorporated and Miyamoto further discloses: wherein the video stream comprises an audio channel (Miyamoto, paragraph 0008, wherein the server creates drawing data, which is to be displayed, corresponding to the input event transmitted from the client to the server, and then creates a table in which cursor IDs are related to object area information included in the drawing data. The server transmits the created table and drawing data to the client. The client moves the mouse cursor in a state in which the drawing data corresponding to the input event is displayed. The client then determines, from the table, the cursor ID in the object area corresponding to the position to which the mouse cursor has been moved, and draws the shape of the mouse cursor corresponding to the cursor ID at the position to which the mouse cursor has been moved).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
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, Wing Chan can be reached on (571) 272-7493. 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.
/HAMZA N ALGIBHAH/ Primary Examiner, Art Unit 2441