DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 21 January 2026 has been entered.
Response to Arguments
Applicant's arguments filed 21 January 2026 have been fully considered but they are not persuasive.
Applicant argues “in Nave, a given identifier identifies a repeated sequence of graphic commands, not a given identifier identifies a unique rendering element as recited in the independent claims” (Remarks, pg. 2). Nave gives an example of a sequence of commands to “draw an object” in paras. 146-153 in which parameters are set and then the object is drawn. Since the sequence of commands in Nave is used to draw a single object, the sequence of commands associated with the object can be considered a unique graphic rendering element.
Applicant argues “a unique rendering element as recited in the independent claims which has a definition comprising an element type and parameters having defined values. In particular, in Nave, a same sequence can be associated with different parameters/parameter values from one execution to another execution while in the invention as claimed an identifier is assigned to a unique graphic rendering element associated with parameters having defined values (i.e. not different parameter values)” (Remarks, pg. 2). The Examiner respectfully disagrees.
Paragraphs 145 and 156 of Nave describe an optional embodiment of separating the commands and parameters. For context, Nave first recites “When the video game presents the same 3D object at the same place on the screen frame after frame, it may use the same set of graphics commands and parameters in each frame” (para. 144). Nave then recites “In cases in which the parameters of the commands are different in each execution, the parameters can be encoded separately” (para. 145). Nave presents two situations: 1) the parameters are the same for each frame, and 2) the parameters are different for each frame. The wording of para. 145 shows that encoding commands and parameters separately is done when the parameters are different for each frame, meaning they would be encoded together in the alternative situation.
A few paragraphs later, Nave recites “This sequence of commands, along with the associated parameters, will be repeated for each frame in a series of frames in which the object remains the same” (para. 153). Nave then recites “it may be desired to manage the commands and the data (commands parameters) separately as in some cases the commands may repeat but with updated command parameters” (para. 156, emphasis added). The phrases “it may be desired” and “in some cases” show that encoding the commands and parameters separately is an optional technique that can be employed in particular circumstances, but one can see that encoding the commands and parameters together would be employed in the disclosed circumstances where parameters do not change between frames.
When paragraphs 145 and 156 of Nave, which describe storing commands and parameters separately, are read in the context of the immediately preceding paragraphs of Nave, one can see that the separate storage of commands and parameters is merely an optional technique that can be employed in particular circumstances, as opposed to a default configuration of storing the commands and parameters together, as in the current claims.
Applicant argues that Nave does not disclose “an indication whether the definition of the unique graphic rendering element has been already sent to the second computing device ... There is no processing to determine if a unique rendering element has already been sent” (Remarks, pg. 3). The Examiner respectfully disagrees. Nave specifically recites “If the server detects a sequence that was already sent, it can send only the sequence identifier to the client instead ... When the server detects a new identifier, the whole sequence is sent to the client” (para. 154). This very clearly teaches an indication of whether the definition of the unique graphic rendering element (i.e. the sequence of graphics commands) has already been sent to the client.
Applicant argues that the use of the Least Recently Used (LRU) algorithm to manage the cache on the server and client proves that there is no indication whether the definition of the unique graphic rendering element has already been sent to the client. However, the selected cache replacement policy (e.g. Lease Recently Used (LRU), First in First out (FIFO), Last in first out (LIFO), etc. are common options) is tangential, at best, to determining which sequences have already been sent to the client. Since Nave says that the server “detects a sequence that was already sent” and “detects a new identifier,” this teaches the claimed indication of whether the definition of a unique graphic rendering element has already been sent.
Applicant argues “in the invention as claimed, the structure of the dictionary as claimed obviates the need for previously tracking the repeated graphic command using the GPU, as the use of the indication (defined from the bit field) in association with each unique rendering element (both defined by an element type and defined parameter values) enables identifying whether a unique rendering element has already been sent or not” (Remarks, pg. 4). The Examiner does not allege that Nave teaches the claimed bit field. Instead, the secondary reference Sharpe is used to teach the claimed bit field.
Applicant argues “the Office Action does not assert anywhere that Nave expressly or inherently discloses at least one processing logic is configured to determine if the unique graphic rendering element has not been already sent to the second computing device using the indication associated with the rendering element in the dictionary' as recited in the independent claims” (Remarks, pg. 5). The Examiner respectfully disagrees. As described previously, Nave specifically recites “If the server detects a sequence that was already sent, it can send only the sequence identifier to the client instead ... When the server detects a new identifier, the whole sequence is sent to the client” (para. 154). This very clearly teaches an indication of whether the definition of the unique graphic rendering element (the sequence of graphics commands) has or has not already been sent to the client.
Applicant argues, in reference to the bit field limitations, “While Tymes mentions the use of a bit field, Tymes does not disclose a dictionary or a unique graphic rendering element” (Remarks, pg. 6). Tymes is not used in this Office Action to teach the claimed bit field. Instead, a new reference Sharpe is used to teach the bit field limitations. However, Applicant’s argument against Tymes applies equally to Sharpe. It is true that Sharpe does not teach the claimed dictionary of unique graphic rendering elements. However, Sharpe does disclose transmitting graphical data (in the form of video data) to a plurality of clients, and for each element of graphical data, a bit field specifying which clients will receive the data, where each client is assigned a specific bit position in the bit field. When this teaching is applied to the transmission of graphics data of Nave, the resulting combination (e.g. the dictionary of unique graphic rendering elements of Nave being modified to use the bit fields of Sharpe) would render obvious using a bit field corresponding to each unique graphic rendering element, where each bit in each bit field corresponds to a client and indicates whether the unique graphic rendering element should be (or has already been) transmitted to the client.
Any remaining arguments are considered moot based on the foregoing.
Claim Rejections - 35 USC § 112
The previous rejection under 35 U.S.C. 112(b) is withdrawn in view of the claim amendments.
Claim Rejections - 35 USC § 103
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, 3, 4, 7, and 11-15 are rejected under 35 U.S.C. 103 as being unpatentable over Nave et al. (US 2011/0157196; hereinafter “Nave”) in view of Sharpe (US 5,619,498).
Regarding claim 1, Nave discloses A first computing device comprising: a communication endpoint configured to establish a connection with a remote second computing device (Server 102 of Fig. 1 connected to Remote UI 106), the first computing device being responsible for the execution of one or more applications that are controlled from the second computing device (“enables a user to execute, operate and interact with a software application, such as a video game, on a client (also referred to herein as an end user device) wherein the software application is executing on a remote server,” para. 6); an access to a dictionary of unique graphic rendering elements, a unique graphic rendering element being a graphic rendering command or a graphic rendering parameter, the dictionary comprising, for each unique graphic rendering element: a definition of the unique graphic rendering element, the definition of the unique graphic rendering element comprising a type of element and defined values of parameters associated with the type of element; a unique id (“the video game … may use the same set of graphics commands and parameters in each frame,” para. 144; “draw an object … This sequence of commands, along with the associated parameters, will be repeated for each frame in a series of frames in which the object remains the same … such command sequences are detected … When a drawing command is issued, the current graphic state of the GPU is encoded into a set of commands. The set of commands is inserted into a cache and given an identifier,” paras. 146-154); and an indication of whether the definition of the unique graphic rendering element has been already sent to the second computing device (“the server detects a sequence that was already sent,” para. 154); at least one processing logic configured to: determine, for a frame to be displayed by the second computing device, an input set of graphic rendering elements using at least one rendering command and a renderstate of a graphic API for said frame (“command sequences are detected by tracking the render state of a GPU that comprises part of the server. All the commands that change the graphic state of the GPU are tracked,” para. 154); convert said input set of graphic rendering elements to a transmission set of unique graphic rendering elements belonging to said dictionary; and send to the second computing device, for each unique graphic element of the transmission set: the unique id of the unique graphic rendering element; and if the unique graphic rendering element has not been already sent to the second computing device, the definition of the unique graphic rendering element (“The client manages the same dictionary of sequences. If the server detects a sequence that was already sent, it can send only the sequence identifier to the client instead. The client uses the identifier to obtain the sequence of commands from its internal dictionary and issues them on its local GPU. When the server detects a new identifier, the whole sequence is sent to the client (encoded with additional encoding) to be stored as part of the client's dictionary,” para. 154), wherein said at least one processing logic is configured to determine if the unique graphic rendering element has not been already sent to the second computing device using the indication associated with the rendering element in the dictionary (“detects a sequence that was already sent … detects a new identifier,” para. 154); wherein the sent information is used by the second computing device to display the frame (“The client uses the identifier to obtain the sequence of commands from its internal dictionary and issues them on its local GPU,” para. 154).
Nave does not disclose wherein the dictionary further comprises, for each unique rendering element, a bit field, the second computing device being associated with a defined position in the bit field, and wherein the indication of whether the definition of the unique graphic rendering element has been already sent to the second computing device is provided by the value of the bit at the defined position in the bit field.
In the same art of transmitting graphical data to a plurality of clients, Sharpe teaches for each [video] element (“video channels being transported,” col. 3, line 40; e.g. the ATM cell of Fig. 3), a bit field, the second computing device being associated with a defined position in the bit field (“one or more bits of the flag bit field (of the ATM cell preamble) that are associated with customer sites requesting that channel,” col. 4, lines 40-65), and wherein the indication of whether the [element should be] sent to the second computing device is provided by the value of the bit at the defined position in the bit field (“The state of each bit of the flag field of the ATM cell preamble will therefore indicate whether or not that ATM cell is intended for the customer premises associated with the bit,” col. 4, lines 40-65).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the bit field indicators of Sharpe to the dictionary of unique rendering elements of Nave. Both Nave and Sharpe transmit graphical data elements to a plurality of clients (Nave transmits unique graphic rendering elements and Sharpe transmits video data elements packaged into ATM cells). In order to determine whether a particular graphical data element should be sent to a particular client, Sharpe employs a bit field for each graphical data element where each individual bit of the bit field indicates whether the graphical data element should be sent to that particular client. Since Nave teaches determining whether a graphical data element should be sent to a particular client (phrased in the claims as whether the unique graphic rendering element “has been already sent”), the bit field indicators of Sharpe are applicable to the unique graphic rendering elements of Nave. The motivation would have been for “reduced complexity” (Sharpe, col. 1, lines 15-20).
Regarding claim 3, the combination of Nave and Sharpe renders obvious for at least one graphic rendering element, to: verify if it has an impact on the display of the frame; if and only if it has an impact on the display of the frame, add it to the input set (“In cases in which an object will not be displayed because it is not larger than a predetermined number of pixels, all the commands that are related to such an object are omitted from the 3D command stream,” Nave, para. 194).
Regarding claim 4, the combination of Nave and Sharpe renders obvious upon the conversion of a graphic rendering element of the input set to a unique graphic rendering element of the transmission set, to: verify if the unique graphic rendering element is already present in the dictionary; if and only if it is not already present in the dictionary, create an entry in the dictionary for the unique graphic rendering element, with a new unique id, and an indication that the element has not been already sent to the second computing device (“When sending a new object to the client, the server may add it to the mapping as it will now be cached by the client. In a case in which the object is not cached, the object is sent to the client. When delivered, the client stores the object in its local persistent storage and also uses it with the relevant graphic command,” Nave, para. 186).
Regarding claim 7, the combination of Nave and Sharpe renders obvious send, separately from said transmission set, to the second computing device synchronization information relative to the dictionary (“during initialization of a game session, the client may send a map of all the objects stored in its cache to the server so that the server can determine in advance which objects are cached,” Nave, para. 186).
Regarding claim 11, Nave discloses A second computing device comprising: a communication endpoint configured to establish a connection with a first computing device (Remote UI 106 of Fig. 1 connected to Server 102), the first computing device being responsible for the execution of one or more applications that are controlled from the second computing device (“enables a user to execute, operate and interact with a software application, such as a video game, on a client (also referred to herein as an end user device) wherein the software application is executing on a remote server,” para. 6); an access to at least one display (“displayed on the remote UI,” para. 35); an access to a dictionary of unique graphic rendering elements, a unique graphic rendering element being a graphic rendering command or a graphic rendering parameter, the dictionary comprising, for each unique graphic rendering element: a definition of the unique graphic rendering element, the definition of the unique graphic rendering element comprising a type of element and defined values of parameters associated with the type of element; and a unique id (“the video game … may use the same set of graphics commands and parameters in each frame,” para. 144; “draw an object … This sequence of commands, along with the associated parameters, will be repeated for each frame in a series of frames in which the object remains the same … such command sequences are detected … When a drawing command is issued, the current graphic state of the GPU is encoded into a set of commands. The set of commands is inserted into a cache and given an identifier,” paras. 146-154); and at least one processing logic configured to: receive, from said first computing device, a transmission set of unique graphic rendering elements for a frame to be displayed by said second computing device, said transmission set comprising, for each unique graphic rendering element: the unique id; and if the unique graphic rendering element is not already present in said dictionary, a definition of said unique graphic rendering element; convert said transmission set of unique graphic rendering elements to an output set of graphic rendering elements belonging to said dictionary using, for each unique graphic rendering element, its definition as found in the dictionary or received from the first processing device (“If the server detects a sequence that was already sent, it can send only the sequence identifier to the client instead. The client uses the identifier to obtain the sequence of commands from its internal dictionary and issues them on its local GPU. When the server detects a new identifier, the whole sequence is sent to the client (encoded with additional encoding) to be stored as part of the client's dictionary,” para. 154); generate at least one rendering command and a renderstate of a graphic API based on said output set of graphic rendering elements (“command sequences are detected by tracking the render state of a GPU,” para. 154; “the commands associated with the first frame are transferred to the client … the client renders the commands associated with the first frame,” para. 158); and trigger the display, on said at least one display, of the frame based on said renderstate (“the client … render the objects on the display,” para. 239), wherein the dictionary of the second computing device mirrors a part of a dictionary handled by the first computing device (“The client manages the same dictionary of sequences,” para. 154), said dictionary handled by the first computing device further comprising, for each unique rendering element, an indication of whether the definition of the unique graphic rendering element has been already sent to the second computing device (“detects a sequence that was already sent,” para. 154).
Nave does not disclose said indication being determined from a bit field, a defined position in said bit field being associated with the second computing device said indication being provided by the value of the bit at the defined position in the bit field.
In the same art of transmitting graphical data to a plurality of clients, Sharpe teaches for each video element (“video channels being transported,” col. 3, line 40; e.g. the ATM cell of Fig. 3), said indication being determined from a bit field, a defined position in said bit field being associated with the second computing device (“one or more bits of the flag bit field (of the ATM cell preamble) that are associated with customer sites requesting that channel,” col. 4, lines 40-65) said indication being provided by the value of the bit at the defined position in the bit field (“The state of each bit of the flag field of the ATM cell preamble will therefore indicate whether or not that ATM cell is intended for the customer premises associated with the bit,” col. 4, lines 40-65).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the bit field indicators of Sharpe to the dictionary of unique rendering elements of Nave. Both Nave and Sharpe transmit graphical data elements to a plurality of clients (Nave transmits unique graphic rendering elements and Sharpe transmits video data elements packaged into ATM cells). In order to determine whether a particular graphical data element should be sent to a particular client, Sharpe employs a bit field for each graphical data element where each individual bit of the bit field indicates whether the graphical data element should be sent to that particular client. Since Nave teaches determining whether a graphical data element should be sent to a particular client (phrased in the claims as whether the unique rendering element “has been already sent”), the bit field indicators of Sharpe are applicable to the unique rendering elements of Nave. The motivation would have been for “reduced complexity” (Sharpe, col. 1, lines 15-20).
Regarding claim 12, it is rejected using the same citations and rationales described in the rejections of claims 1 and 11.
Regarding claim 13, it is rejected using the same citations and rationales described in the rejection of claim 1.
Regarding claim 14, it is rejected using the same citations and rationales described in the rejection of claim 11.
Regarding claim 15, the combination of Nave and Sharpe renders obvious A computer program product, stored on a non-transitory computer readable medium, comprising computer code instructions for executing a method according to claim 13 (“Main memory has stored therein control logic,” Nave, para. 289).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Nave and Sharpe in view of Adiletta et al. (US 2020/0326955; hereinafter “Adiletta”).
Regarding claim 5, the combination of Nave and Sharpe does not specifically describe execute a virtual graphic driver, and wherein the input set of graphic rendering elements of a frame to be displayed by the second computing device is a frame buffer to be displayed, generated by a window composer.
In the same art of remote graphics display, Adiletta teaches execute a virtual graphic driver (“native graphics thrower 808 [of Fig. 8] is implemented as a virtual graphics driver … Graphic commands and content corresponding to both the software rendering path and hardware rendering path that are output from graphic APIs 704 are sent to native graphics thrower 808 … graphics commands and content is trapped, buffered, and sent to native graphics catcher 810,” para. 114), and wherein the input set of graphic rendering elements of a frame to be displayed by the second computing device is a frame buffer to be displayed (e.g. Display Buffer 805 of Fig. 8), generated by a window composer (“Compositor 718 [of Fig. 8] is used for ‘composing’ the final graphics content that is shown on the graphic device's display screen,” para. 111).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the teachings of Adiletta to the combination of Nave and Sharpe. The motivation would have been “the real-time remote graphics rendering performance under the Android thrower-catcher architecture is very good, and is substantially faster” (Adiletta, para. 159).
Claims 8 and 9 rejected under 35 U.S.C. 103 as being unpatentable over the combination of Nave and Sharpe in view of Hellge et al. (US 2023/0326113; hereinafter “Hellge”).
Regarding claim 8, the combination of Nave and Sharpe does not disclose wherein the unique graphic rendering elements are defined hierarchically, higher-level unique graphic rendering elements being dependent upon lower-level unique graphic rendering elements.
In the same art of transmitting graphics data, Hellge teaches wherein the unique graphic rendering elements are defined hierarchically, higher-level unique graphic rendering elements being dependent upon lower-level unique graphic rendering elements (“Each node can contain an array called children that contains the indices of its child nodes. So each node is one element of a hierarchy of nodes, and together they define the structure of the scene as a scene graph,” para. 128).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the teachings of Hellge to the combination of Nave and Sharpe. The motivation would have been for “increasing the efficiency in describing a scene” (Hellge, para. 62).
Regarding claim 9, the combination of Nave and Sharpe does not disclose wherein each unique graphic rendering element of the transmission set is represented as a node of a tree, and, for each node representing a defined unique graphic rendering element: the descendants of said node are the unique graphic rendering elements that have an impact on said graphic unique rendering element; said unique graphic rendering element, comprises as parameters, the unique ids of the unique graphic rendering elements of the children of said node.
In the same art of transmitting graphics data, Hellge teaches wherein each unique graphic rendering element of the transmission set is represented as a node of a tree (“Each scene contains an array of nodes, which are the indices of root nodes of the scene graphs,” para. 127), and, for each node representing a defined unique graphic rendering element: the descendants of said node are the unique graphic rendering elements that have an impact on said graphic unique rendering element (see Fig. 2); said unique graphic rendering element, comprises as parameters, the unique ids of the unique graphic rendering elements of the children of said node (“Each node can contain an array called children that contains the indices of its child nodes,” para. 128).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the teachings of Hellge to the combination of Nave and Sharpe. The motivation would have been for “increasing the efficiency in describing a scene” (Hellge, para. 62).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Nave, Sharpe, and Hellge, and further in view of Sahm et al. (“Efficient representation and streaming of 3D scenes”; hereinafter “Sahm”).
Regarding claim 10, the combination of Nave, Sharpe, and Hellge renders obvious include in the transmission set all the unique graphic rendering elements in said tree (“a data stream [e.g. the scene description data] … transferred via a data communication connection,” Hellge, para. 332; see claim 9 for motivation to combine).
The combination of Nave, Sharpe, and Hellge does not disclose transmitting elements except those that correspond to descendants of nodes corresponding to unique graphic rendering elements that have been already sent to the second computing device.
In the same art of transmitting graphics data, Sahm teaches transmitting elements except those that correspond to descendants of nodes corresponding to unique graphic rendering elements that have been already sent to the second computing device (“the server selects the elements, which have to be transmitted to a specific client. If an element already exists on the client, then it is ignored,” pg. 21, col. 2, para. 2).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the teachings of Sahm to the combination of Nave, Sharpe, and Hellge. The motivation would have been “to improve the rendering efficiency of the Element Graph” (Sahm, pg. 22, col. 1, para. 1).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Nave in view of Hellge.
Regarding claim 16, Nave discloses A first computing device comprising: a communication endpoint configured to establish a connection with a remote second computing device (Server 102 of Fig. 1 connected to Remote UI 106), the first computing device being responsible for the execution of one or more applications that are controlled from the second computing device (“enables a user to execute, operate and interact with a software application, such as a video game, on a client (also referred to herein as an end user device) wherein the software application is executing on a remote server,” para. 6); an access to a dictionary of unique graphic rendering elements, a unique graphic rendering element being a graphic rendering command or a graphic rendering parameter, the dictionary comprising, for each unique graphic rendering element: a definition of the unique graphic rendering element, the definition of the unique graphic rendering element comprising a type of element and defined values of parameters associated with the type of element; a unique id (“the video game … may use the same set of graphics commands and parameters in each frame,” para. 144; “draw an object … This sequence of commands, along with the associated parameters, will be repeated for each frame in a series of frames in which the object remains the same … such command sequences are detected … When a drawing command is issued, the current graphic state of the GPU is encoded into a set of commands. The set of commands is inserted into a cache and given an identifier,” paras. 146-154); and an indication of whether the definition of the unique graphic rendering element has been already sent to the second computing device (“the server detects a sequence that was already sent,” para. 154); and at least one processing logic configured to: determine, for a frame to be displayed by the second computing device, an input set of graphic rendering elements using at least one rendering command and a renderstate of a graphic API for said frame (“command sequences are detected by tracking the render state of a GPU that comprises part of the server. All the commands that change the graphic state of the GPU are tracked,” para. 154); convert said input set of graphic rendering elements to a transmission set of unique graphic rendering elements belonging to said dictionary; and send to the second computing device, for each unique graphic element of the transmission set: the unique id of the unique graphic rendering element; and if the unique graphic rendering element has not been already sent to the second computing device, the definition of the unique graphic rendering element (“The client manages the same dictionary of sequences. If the server detects a sequence that was already sent, it can send only the sequence identifier to the client instead. The client uses the identifier to obtain the sequence of commands from its internal dictionary and issues them on its local GPU. When the server detects a new identifier, the whole sequence is sent to the client (encoded with additional encoding) to be stored as part of the client's dictionary,” para. 154); wherein the sent information is used by the second computing device to display the frame (“The client uses the identifier to obtain the sequence of commands from its internal dictionary and issues them on its local GPU,” para. 154).
Nave does not disclose wherein each unique graphic rendering element of the transmission set is represented as a node of a tree, and, for each node representing a defined unique graphic rendering element: the descendants of said node are the unique graphic rendering elements that have an impact on said graphic unique rendering element; said unique graphic rendering element, comprises as parameters, the unique ids of the unique graphic rendering elements of the children of said node.
In the same art of transmitting graphics data, Hellge teaches wherein each unique graphic rendering element of the transmission set is represented as a node of a tree (“Each scene contains an array of nodes, which are the indices of root nodes of the scene graphs,” para. 127), and, for each node representing a defined unique graphic rendering element: the descendants of said node are the unique graphic rendering elements that have an impact on said graphic unique rendering element (see Fig. 2); said unique graphic rendering element, comprises as parameters, the unique ids of the unique graphic rendering elements of the children of said node (“Each node can contain an array called children that contains the indices of its child nodes,” para. 128).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the teachings of Hellge to Nave. The motivation would have been for “increasing the efficiency in describing a scene” (Hellge, para. 62).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ryan McCulley whose telephone number is (571)270-3754. The examiner can normally be reached Monday through Friday, 8:00am - 4: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, Kee Tung can be reached at (571) 272-7794. 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.
/RYAN MCCULLEY/Primary Examiner, Art Unit 2611
Prosecution Insights