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 .
This action is in response to the Amendment filed on 4/29/2026.
Claims 7-13, 18-30 are pending. Claims 7-13, 18 have been amended. Claims 1-6, 14-17 have been cancelled. Claim 19-30 are newly added.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. (FP 7.30.05)This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “3D display volume managing unit” in Claim 7, 10, 11 Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. (FP 7.30.06).
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.
Claim 26 is 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 pre-AIA the applicant regards as the invention. Claims 26 recites
the limitation "maintaining the child location relative…" in Page 7, Line 12.
the limitation “the parent 3D display…” in Page 7, Line 14.
There is insufficient antecedent basis for this limitation in the claim. Therefore, rejected under the same rationale.
Claim 26 is also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite. The recitation "The method of claim 26" creates a circular dependency because the claim refers back to itself. This self-reference makes the scope of the claim impossible to determine, as the claim essentially attempts to incorporate its own limitations recursively, leaving the boundaries of the invention unclear.
Note: It appears the applicant may have intended to depend on Claim 25, which establishes the "tree structure" and "parent/child" relationship that Claim 26 seeks to further limit.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 26 is rejected under 35 U.S.C. 112(d) as being an improper dependent claim. A dependent claim must contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. Claim 26 recites in the preamble "The method of claim 26, further comprising: maintaining the child location relative to a real-world environment based at least in part upon (1) whether the 3D display volume managing unit belongs to a group, and (2) whether the parent 3D display volume managing unit or a child 3D display volume managing unit also belongs to the group, and (3) a type of transform applied to the parent 3D display volume managing unit or the child 3D display volume managing unit." Because Claim 26 refers to itself rather than a preceding claim, it fails to comply with the formal statutory requirements for a dependent claim.
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.
Claim(s) 7-11, 18-19, 21-22, 27-28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 7596766 B1, hereinafter Sharma) in view of Murphy et al. (US 20190018567 A1, hereinafter Murphy)
Regarding Claim 7, Sharma teaches A method for opening and placing an application (Sharma, Column 5, Line 43-46 , "Execution of the preview window generator application 150-1 in this manner produces preview window generator process 150-2") [[in an augmented reality environment]], the method comprising:
receiving a user input from a user indicating a request for new content, the new content being associated with a link (Sharma, Column 6, Line 33-35, step 350, "the preview window generator 150 senses a presence of navigation input applied to a resource reference 165 (e.g., link) <read on link> displayed in an application window 160") [[from a web page]]; in response to receiving the user input indicating the request for the new content, launching an application to render the new content (Sharma, Column 8, Line 45-49, step 535, "the preview window generator 150 displays the context view 175 in the preview window 170 to include a view of the stored content (as specified by the resource reference 165) as if the stored content were opened in a native application typically launched <read on launching an application> to view the stored content"); instantiating a mini display volume for displaying the new content that is to be rendered (Sharma, Column 8, Line 24-26, step 525, "the preview window generator 150 displays a preview window 170 <read on mini display volume> including the context view 175 created in step 520"), wherein a page preview for the new content associated with the link from the web page is displayed in the mini display volume <read on preview window> (Sharma, Column 2, Line 34-36, the context view displayed in the preview window includes a pictorial view of resources specified in the file path”; Column 8, Line 11-13, step 520, "the preview window generator 150 creates a context view 175 including a representation of the stored content as specified by resource reference 165"), [[and the 3D display volume managing unit is created in response to instantiating the application]]; receiving a separate user input indicating a placement of the mini display volume [[at a location in an augmented reality environment]] (Sharma, Column 8, Line 62-67, "the preview window generator 150 detects input provided to the preview window 170. For example, as the user 108 directs the pointer 300 to be placed within the preview window in order to manipulate or select the icons in the context view, the preview window generator 150 detect such pointer activity occurring in the preview window 170"); and in response to receipt of the separate user input indicating the placement of the mini display volume at the location, programmatically expanding the mini display volume into a [[3D]] display volume managing unit at the location (Sharma, Column 9, Line 1-5, "the preview window generator 150 transitions display of the transparent representation to display of an opaque representation of the context view"), the [[3D]] display volume managing unit displaying the new content that is fully loaded within the [[3D]] display volume managing unit (Sharma, Column 8, Line 43-, step 535, " the preview window generator 150 displays the context view 175 in the preview window 170 to include a view of the stored content (as specified by the resource reference 165) as if the stored content were opened in a native application typically launched to view the stored content").
But Sharma does not explicitly disclose augmented reality environment, link from a web page, 3D display volume managing unit is created in response to instantiating the application, placement of the mini display volume at a location in an augmented reality environment, and programmatically expanding the mini display volume into a 3D display volume managing unit at the location.
However, Murphy teaches a method for opening and placing an application in an augmented reality environment (Murphy, Paragraph [0089], " input device 500 , even when limited to three DOF motion tracking . For example , input device 500 can be used to both select a virtual object, such as an application window in a VR / AR environment <read on augmented reality>, and interface with the contents of the application window"; [0003], "Augmented reality ( AR ) or mixed reality ( MR ), on the other hand , can superimpose virtual images on a real world environment "), the new content being associated with a link from a web page (Murphy, Paragraph [0069], "Touch pad 520 can be used to interface a VR / AR environment in a number a ways including object manipulation , text entry, navigation selection (e. g., selecting icons or links on an application page in the VR / AR environment "; [0094], "Any virtual object can be selected including interactive windows (e.g., web browser <read on web page>)"), the 3D display volume managing unit is created in response to instantiating the application (Murphy, Paragraph [0094], "Any virtual object can be selected including interactive windows (e.g., web browser), 3D objects … or any other user accessible object in a VR/AR <read on 3D> environment"; [0089], "select a virtual object, such as an application window <read on 3D display volume managing unit> in a VR/AR environment"), receiving a separate user input indicating a placement of the mini display volume at a location in an augmented reality environment (Murphy, Paragraph [0089], "the application window can be moved within the VR/AR <read on augmented reality> environment based on a tracked motion of the input device in 3D space while the application window remains selected"; [0093], "first input data from a first input element on the input device indicating that the first input element is activated while the cursor is positioned over a virtual object in the VR/AR environment"), programmatically expanding the mini display volume into a 3D display volume managing unit at the location (Murphy, Paragraph [0079], "a scaling function can be performed on a virtual object by first selecting the virtual object via trigger 530, and pressing one of regions 630 to "scale" or resize the selected virtual object. For example, selecting the virtual object and pressing a first portion of region 630 can cause the selected virtual object to increase in size <read on expanding>").
Sharma and Murphy are analogous since both are directed to user interface techniques that facilitate the display and manipulation of computer resources. Sharma provides a way to reduce user navigation steps by using a preview triggered by a link, while Murphy provides a method for interacting with such virtual objects in a 3D AR space. It would have been obvious to a person of ordinary skill in the art to incorporate the 3D placement and "grabbing" interaction of Murphy into the preview system of Sharma. This would enable a user to pick up a content preview initiated from a link and manually position it at a specific physical or virtual location within their augmented environment, thereby making the workflow more intuitive and spatially organized.
Regarding Claim 8, the combination of Sharma and Murphy teaches the invention in Claim 7.
The combination further teaches wherein the separate user input is responsive to a cursor movement over the link from the web page (Sharma, Column 8, Line 3-10, “At sub-step 515 of step 510, the preview window generator 150 detects a pointer 300 placed over the resource reference 165 <read on cursor movement over the link> displayed in the application window").
However, Sharma does not explicitly disclose the web page is displayed in a browser application, and the browser application is displayed inside of a 3D bounded display volume within an augmented reality environment.
But Murphy teaches the web page is displayed in a browser application, and the browser application is displayed inside of a 3D bounded display volume within an augmented reality environment presented to the user (Murphy, Paragraph [0077], "a web browser or other substantially 2D window within a 3D virtualized space <read on 3D bounded display volume>"; [0094], "Any virtual object can be selected including interactive windows (e.g., web browser <read on browser application>)").
As explained in rejection of claim 7, the obviousness for combining of Murphy into Sharma is provided above.
Regarding Claim 9, the combination of Sharma and Murphy teaches the invention in Claim 8.
The combination further teaches the separate user input is further responsive to a selection of the link (Sharma, Column 8, Line 62-63, “At step 540, the preview window generator 150 detects input provided to the preview window 170"; Column 9, Line 25-28, “the preview window generator 150 can detect when a user clicks on a Sub-folder displayed in context view 175<read on selection of the link>").
Sharma does not explicitly disclose but Murphy teaches movement of the mini display volume (Murphy, Paragraph [0089], " select an application window in the VR/AR environment when a corresponding cursor is placed over the application window, and the application window can be moved <read on movement of the mini display volume> within the VR/AR environment based on a tracked motion of the input device in 3D space ").
As explained in rejection of claim 7, the obviousness for combining of Murphy into Sharma is provided above.
Regarding Claim 10, the combination of Sharma and Murphy teaches the invention in Claim 7.
The combination further teaches the [[3D]] display volume managing unit replaces the mini display volume when the mini display volume expands into the [[3D]] display volume managing unit (Sharma, Column 9, Line 1-4, step 545, "the preview window generator 150 transitions display of the transparent representation to display of an opaque representation of the context view <read on replaces the mini display volume when expands>").
Sharma does not explicitly disclose but Murphy teaches the same replacement concept in the AR context (Murphy, Paragraph [0079], "selecting the virtual object and pressing a first portion of region 630 can cause the selected virtual object to increase in size <read on replaces … when expands>").
As explained in rejection of claim 7, the obviousness for combining of Murphy into Sharma is provided above.
Regarding Claim 11, the combination of Sharma and Murphy teaches the invention in Claim 7.
The combination further teaches wherein the new content is loaded into the [[3D]] display volume managing unit while the user is moving the mini display (Sharma, Column 11, Line 50-52, "The "new" icons provided in the context view 175 of the preview window 170 are continually updated as a user inputs file path information <read on new content is loaded … while user is moving>").
Murphy further teaches simultaneous moving and content interaction but in 3D display (Murphy, Paragraph [0089], "a user can select and move an application window in a VR/AR environment while simultaneously interacting with content on the application window via touch pad 520 <read on loaded … while moving the mini display>").
As explained in rejection of claim 7, the obviousness for combining of Murphy into Sharma is provided above.
Regarding Claim 18, Claim 18 recites substantially the same overall scope/limitations as Claim 7 with the additional limitation that "the user input includes a cursor movement over a link on a web page displayed in a browser application, and the browser application is displayed inside of a 3D bounded display volume within an augmented reality environment presented to the user."
Sharma teaches the user input includes a cursor movement over a link on a web page displayed in a [[browser]] application (Sharma, Column 8, , step 515, "the preview window generator 150 detects a pointer 300 placed over the resource reference 165 <read on cursor movement over a link> displayed in the application window"; step 350, "the preview window generator 150 senses a presence of navigation input applied to a resource reference 165 (e.g., link) displayed in an application window 160"). The remaining limitations are taught as set forth above for Claim 7 (see rejection on Claim 7).
But Sharma does not explicitly disclose the browser application is displayed inside of a 3D bounded display volume within an augmented reality environment presented to the user.
However, Murphy teaches the browser application is displayed inside of a 3D bounded display volume within an augmented reality environment presented to the user (Murphy, Paragraph [0249], "Any virtual object can be selected including interactive windows (e.g., web browser <read on browser application>)"; [0212], "a web browser or other substantially 2D window within a 3D virtualized space <read on 3D bounded display volume within an augmented reality environment>"; [0239], "an application window in a VR/AR environment").
The rationale for combining Murphy with Sharma is the same as set forth for Claim 7: a POSITA would combine Sharma's link-hover preview mechanism with Murphy's AR environment in which web-browser application windows are displayed inside 3D bounded volumes, so that the preview triggered by a cursor over a link inside an AR-displayed browser can be expanded into a full 3D AR-application-window.
Regarding Claim 19, the combination of Sharma and Murphy teaches the invention in Claim 18.
The combination further teaches facilitating, for displaying the mini display volume (Sharma, Column 8, Line 24-26, step 525, "the preview window generator 150 displays a preview window 170 <read on mini display volume> including the context view 175 created in step 520"), …presenting the page preview”; Column 8, Line 10-13, "the preview window generator 150 creates a context view 175 including a representation of the stored content <read on page preview> as specified by resource reference 165").
But Sharma does not explicitly disclose the 3D display volume managing unit, a first body dynamic type to accommodate 3D movement of the user or a portion of thereof in a three-dimensional environment, new content in response to the 3D movement in one or more dimensions, while ignoring the 3D movement in at least one other dimension, and locking the at least one other dimensions for the 3D movement.
However, Murphy teaches facilitating, for displaying the mini display volume or the 3D display volume managing unit (Murphy, Paragraph [0089], "input device 500 can be used to both select a virtual object, such as an application window <read on 3D display volume managing unit> in a VR/AR environment"; [0077], "a web browser or other substantially 2D window within a 3D virtualized space"), a first body dynamic type (Murphy, Paragraph [0077], "certain movements that are allowable for an object depending on the type of object <read on body dynamic type>"; [0011], "applying a context-specific control schema <read on body dynamic type> to the virtual object, the control schema configured to control how a common set of input types affect the selected virtual object based on the object type of the virtual object"), to accommodate 3D movement of [[the user or]] a portion of thereof in a three-dimensional environment (Murphy, Paragraph [0084], "very natural hand movements <read on a portion of the user> can be detected as one can move their hand in any direction in 3D space <read on three-dimensional environment> and in any orientation, which can be translated in kind in a corresponding VR/AR environment"), at least by presenting the [[page preview or]] the new content in response to the 3D movement in one or more dimensions (Murphy, Paragraph [0089], "the application window can be moved within the VR/AR environment based on a tracked motion of the input device in 3D space <read on 3D movement in one or more dimensions> while the application window remains selected. Furthermore, a user interface (e.g., touch pad 520) can be used to access and control content <read on presenting … the new content> on the selected application window"), while ignoring the 3D movement in at least one other dimension of the three-dimensional environment (Murphy, Paragraph [0091], "the IMU may be configured to only detect 3-DOF rotational movements of input device 500 and/or translational movements of input device 500 detected by the IMU may be dismissed <read on ignoring … 3D movement in at least one other dimension>"), by locking the at least one other dimensions for the 3D movement (Murphy, Paragraph [0077], "a web browser or other substantially 2D window within a 3D virtualized space may be limited from panning, yawing, and/or tiling <read on locking the at least one other dimensions> to prevent the 2D window from being positioned in a manner that would make content of the window illegible").
Sharma and Murphy are analogous since both are directed to user interface techniques that facilitate the display and manipulation of computer resources. Sharma provides a way to reduce user navigation steps by using a preview triggered by a link, while Murphy provides a method for interacting with such virtual objects in a 3D AR space. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Murphy's per-object-type movement restrictions and 3-DOF dismissal-of-translation policy into the modified invention of Sharma such that the application window (i.e., 3D display volume managing unit) is presented with a movement policy ("first body dynamic type") that responds to the user's hand motion in some axes while locking other axes. The motivation is to preserve readability/usability of the window content during user motion, as discussed by Murphy in Paragraph [0077] ("to prevent the 2D window from being positioned in a manner that would make content of the window illegible"), and to minimize drift-related inadvertent movements in 3-DOF tracking (Murphy, Paragraph [0091], "By limiting detection to 3-DOF rotational movements, undesirable effects of drift can be minimized (e.g., inaccurate location determination, inadvertent movements of a cursor in a virtual environment)").
Regarding Claim 21, the combination of Sharma and Murphy teaches the invention in Claim 18.
The combination further teaches for displaying the mini display (Sharma, Column 8, Line 24-26, step 525, "the preview window generator 150 displays a preview window 170 <read on mini display > including the context view 175 created in step 520"),
Sharma does not explicitly disclose but Murphy teaches facilitating, for displaying the [[ mini display ]] volume or the 3D display volume managing unit, a second body dynamic type that is different from the first body dynamic type. (Murphy, Paragraph [0011], "applying a context-specific control schema to the virtual object, the control schema configured to control how a common set of input types affect the selected virtual object based on the object type of the virtual object <read on second body dynamic type … different from the first body dynamic type>"; [0077], "certain virtual objects may have (possibly differing) object-specific controls associated with the object").
As explained in rejection of claim 18, the obviousness for combining of Murphy into Sharma is provided above.
Regarding Claim 22, the combination of Sharma and Murphy teaches the invention in Claim 18.
The combination further teaches in response to selecting the link (Sharma, Column 9, 24-26, step 555, "the preview window generator 150 can detect when a user clicks on a sub-folder displayed in context view 175 <read on selecting the link>"; Column 6, Line 33-40, step 350, "the preview window generator 150 senses a presence of navigation input applied to a resource reference 165 (e.g., link) displayed in an application window 160"), provisioning opening, instantiation (Sharma, Column 8, Line 25-31, step 525, "the preview window generator 150 initiates display of the preview window 150 and corresponding context view 175 (including at least a representation of the stored content) when sensing that a user-controlled prompt (e.g., navigation input from pointer activity) is moved in close proximity to the resource reference 165 (e.g. link) <read on provisioning opening, instantiation … in response to selecting the link>"), while the [[3D]] display [[volume managing unit]] is being prepared for display to the user (Sharma, Column 8, Line 45-50, step 535, "the preview window generator 150 displays the context view 175 in the preview window 170 to include a view of the stored content (as specified by the resource reference 165) as if the stored content were opened in a native application typically launched <read on being prepared for display> to view the stored content").
But Sharma does not explicitly disclose placing the mini display volume for the link in the augmented reality environment, placement of the application, and the 3D display volume managing unit.
However, Murphy teaches placing the mini display volume for the link in the augmented reality environment (Murphy, Paragraph [0089], "trigger 530 can be activated (depressed) to select an application window in the VR/AR <read on augmented reality> environment when a corresponding cursor is placed over the application window, and the application window < read on mini display volume > can be moved within the VR/AR environment based on a tracked motion of the input device in 3D space <read on placing … in the augmented reality environment> while the application window remains selected"; [0069], "Touch pad 520 can be used to interface a VR/AR environment in a number a ways including … selecting icons or links <read on for the link> on an application page in the VR/AR environment"), placement of the application (Murphy, Paragraph [0089], "the application window can be moved within the VR/AR environment based on a tracked motion of the input device in 3D space <read on placement of the application>"), the 3D display volume managing unit is being prepared for display to the user — concurrent / simultaneous preparation (Murphy, Paragraph [0089], "Trigger button 530 and touch pad 520 can function independently of one another and support simultaneous operation. For example, a user can select and move an application window in a VR/AR environment while simultaneously interacting with content on the application window <read on while the 3D display volume managing unit is being prepared for display to the user>").
Sharma and Murphy are analogous since both are directed to user interface techniques that facilitate the display and manipulation of computer resources. Sharma provides a way to reduce user navigation steps by using a preview triggered by a link, while Murphy provides a method for interacting with such virtual objects in a 3D AR space with concurrent / simultaneous preparation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the AR placement-of-application-window functionality of Murphy into the link-triggered opening/instantiation flow of Sharma such that the selection of a link both opens/instantiates the preview ("mini display volume") and concurrently places the application window (3D display volume managing unit) in the AR environment while the full window is being prepared for display. The motivation is to enable efficient and concurrent selection-and-placement workflow so the user can begin positioning the application window in the AR space at the same time the full content is being loaded/prepared, as discussed by Murphy in Paragraph [0089] (independent and simultaneous operation of select and move/interact).
Regarding Claim 27, it recites limitations similar in scope to the limitations of Claim 7 and the combination of Sharma and Murphy teaches all the limitations as of Claim 7. And Sharma discloses these features can be implemented on a computer readable storage medium (Sharma, Column 5, Line 34-38, "The memory system 112 can be any type of computer readable medium and, in this example, is encoded with a preview window generator application 150-1 that supports generation, display, and implementation of functional operations").
Regarding Claim 28, it recites limitations similar in scope to the limitations of Claim 19 and therefore is rejected under the same rationale.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 7596766 B1, hereinafter Sharma) in view of Murphy et al. (US 20190018567 A1, hereinafter Murphy) as applied to Claim 7 above and further in view of Grinberg et al. (US 20130307842 A1, hereinafter Grinberg).
Regarding Claim 12, the combination of Sharma and Murphy teaches the invention in Claim 7.
The combination does not explicitly disclose but Grinberg teaches wherein the location is anchored to an object in the augmented reality environment (Grinberg, Paragraph [0012], "computer vision (CV) dynamic 3D integration of the computer generated image (CGI) to the real world using real world objects as markers (hard anchoring), to which the virtual objects are realistically related <read on the location is anchored to an object in the augmented reality environment>"; [0018], "The video image received by the cameras installed on the see through device is the reference of the real world from which the software identifies real objects as markers, using computer vision applications and respective algorithms, in order to “hard anchor” (i.e., tight relative connection between the virtual object and the says real object) the CGI to the real world."; [0019], "hard anchoring is anchoring to objects in the real world <read on an object in the augmented reality environment>, pin-pointed by the markers"; [0048], "He sees a table. On the table there is a virtual cup of tea. This is because the algorithm recognizes that this specific cup of tea should be on that specific table <read on the location is anchored to an object> and with the very same geo-position").
Grinberg is analogous to Sharma as both relate to the management of virtual content overlaid on real-world references. While Sharma provides a preview window triggered by a link, Grinberg provides a sophisticated "hard anchoring" technique that binds computer-generated images to specific physical objects identified as markers. It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the anchoring logic of Grinberg to the mini display volume placement of Sharma such that the user could select a web link and physically "pin" the resulting content volume to a specific object in their room (such as a table or wall) rather than having it float in abstract 3D space. This provides a more stable and contextually integrated user experience by ensuring the virtual window maintains a fixed relative position to physical furniture.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 7596766 B1, hereinafter Sharma) in view of Murphy et al. (US 20190018567 A1, hereinafter Murphy), further in view of Grinberg et al. (US 20130307842 A1, hereinafter Grinberg) as applied to Claim 12 above and further in view of Oguz (US 20130086508 A1).
Regarding Claim 13 the combination of Sharma and Murphy teaches the invention in Claim 7.
The combination does not explicitly disclose but Oguz teaches facilitating opening, instantiation, and placement of the application at least by selecting the link and placing the mini display volume for the link in the augmented reality environment while the 3D display volume managing unit is being prepared for display to the user (Oguz, Paragraph [0046], "Some embodiments may include application launch functionality based on the displacement of an icon associated with an application utilizing one or more touch displays from a multi-display device."; Oguz, Paragraph [0105], "displacing the icon from the first position along a path of the movement of the user input during the detected movement of the user input along the surface of the first touch display; and/or returning the displaced icon to the first position after the processor has begun launching the instance of the application."; [0111], "At block 610-a, a user input may be detected through the first touch display at the icon at the first position <read on selecting>. At block 615-a, a movement of the user input may be detected along at least a surface of the first touch display from the first position on the first touch display <read on placing>. At block 620-a, the instance of the application may be launched <read on opening, instantiation> by a processor upon detecting an end to the movement of the user input. At block 505-a, the window representing the instance of the application may be displayed on at least the first touch display or a second display <read on the 3D display volume managing unit is being prepared for display to the user>").
Oguz and Sharma/Murphy/Grinberg are analogous since address management/launching of application windows in response to user input on a content reference (icon/link) which optimizing the workflow for starting applications and presenting their windows to a user. Sharma and Murphy establish the link-selection, preview, and AR-placement steps, and Grinberg establishes the real-world-object anchoring. Oguz specifically teaches a mechanism where moving or "displacing" an icon triggers the launch process, allowing the system to begin preparing the application while the icon is being moved. It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the launch-on-displacement behavior taught by Oguz into modified invention of Sharma such that selecting the link and placing the mini display volume at the anchored AR location concurrently triggers opening/instantiation of the application while the corresponding 3D display volume managing unit is being prepared for display. The motivation is to maximize efficiency by allowing the user to complete the necessary spatial task of placement during the time the system requires for loading and initialization, thereby reducing the perceived latency of the application launch.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 7596766 B1, hereinafter Sharma) in view of Murphy et al. (US 20190018567 A1, hereinafter Murphy) as applied to Claim 19 above and further in view of Abercrombie et al. (US 20150206351 A1, hereinafter Abercrombie).
Regarding Claim 20, the combination of Sharma and Murphy teaches the invention in Claim 19.
The combination further teaches first body dynamic type with locked dimensions (Murphy, Paragraph [0077], "a web browser or other substantially 2D window within a 3D virtualized space may be limited from panning, yawing, and/or tiling"; [0091], "translational movements of input device 500 detected by the IMU may be dismissed")
But the combination of Sharma and Murphy do not explicitly disclose modifying the first body dynamic type at least by unlocking the at least one other dimension … while accommodating the 3D movement in the at least one other dimension.
However, Abercrombie teaches modifying the first body dynamic type (Abercrombie, Paragraph [0135], "Such an arrangement might be considered to be a suspension or an "override" of the default behavior of the display space <read on modifying the first body dynamic type>. Enabling rotation of the display space as described would not necessarily alter the more general behavior of the display space … but could rather allow for an exception to the default behavior"; [0132], "The behaviors as previously described with regard to world space, sphere space, and display space might for at least some embodiments be more properly considered to be default behaviors rather than absolute restrictions"), at least by unlocking the at least one other dimension (Abercrombie, Paragraph [0134], "typically display space 312D rotates with the viewer 306D, such that there is substantially zero relative rotation of the display space 312D with respect to the viewer 306D. However, for at least some embodiments it may be useful to enable rotation of the display space 312D <read on unlocking the at least one other dimension> with respect to the viewer 306D, under at least some circumstances"; [0139], "typically display space 312E translates with the viewer 306E, such that there is substantially zero relative translation of the display space 312E with respect to the viewer 306E. However, for at least some embodiments it may be useful to enable translation of the display space 312E <read on unlocking the at least one other dimension> with respect to the viewer 306E"), to display the [[mini display volume or]] the 3D display volume managing unit <read on display space / entities therein> while accommodating the 3D movement in the at least one other dimension (Abercrombie, Paragraph [0134], "if at some point the viewer wishes to stop and read an incoming message, it may be useful to enable rotation of the display space, so that the viewer may move the message entity into his or her central vision to be read <read on display the 3D display volume managing unit while accommodating the 3D movement in the at least one other dimension>"; [0136], "exceptions to the default behavior … a display rotation stimulus (i.e. to produce rotation of a display space relative to a viewer) might include a user input").
Abercrombie and combination of Sharma/Murphy are analogous since all three address user-interface behavior in three-dimensional virtual/AR spaces — SHARMA (2D preview windows), MURPHY (AR application windows with dimension-limiting movement policies), and ABERCROMBIE (world/sphere/display spaces with default behaviors and exception mechanisms in mixed/augmented reality). Murphy's body dynamic / movement policy (panning/yawing/tiling locked for a 2D web browser window; translational input dismissed) is a static policy: once dimensions are locked. Abercrombie teaches toggling them back to an unlocked state at runtime which is an "exception" mechanism that overrides the default locked behavior of the display space, enabling translation or rotation of the display space (previously locked) in response to a stimulus such as a user input, hand gesture, or voice command. It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Abercrombie's exception-based override of default-locked dimensions into the modified invention of Sharma/Murphy AR system such that the otherwise-locked dimensions of the 3D display volume managing unit's movement policy can be unlocked at runtime to accommodate user 3D movement in that previously-locked dimension. The motivation is to give users the flexibility to toggle a window's movement policy at runtime (e.g., to bring a peripheral message entity into central vision for reading) without changing the general/default behavior of the system, as discussed by Abercrombie in Paragraph [0134] ("if at some point the viewer wishes to stop and read an incoming message, it may be useful to enable rotation of the display space, so that the viewer may move the message entity into his or her central vision to be read").
Claim(s) 23, 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 7596766 B1, hereinafter Sharma) in view of Murphy et al. (US 20190018567 A1, hereinafter Murphy) as applied to Claim 18, 27 above respectively and further in view of Hart (US 20150046284 A1).
Regarding Claim 23, the combination of Sharma and Murphy teaches the invention in Claim 19.
The combination does not explicitly disclose but Hart teaches persistently placing, based at least in part upon one or more criteria for the user wearing an augmented reality display system, a launcher with a fixed relationship to a location in a real-world environment (Hart, Paragraph [0016], " an augmented reality system that is capable of anchoring digital content <read on launcher> to digital airspace having a particular latitude, longitude, and altitude <read on a fixed relationship to a location in a real-world environment>"; Abstract, "an augmented reality digital content can be displayed on the at least one screen, the augmented reality digital content positioned at the physical location";"After a user is oriented towards a physical location, an augmented reality digital content can be displayed on the at least one screen … displayed on the at least one screen only when the user is facing the physical location <read on one or more criteria for the user>"), so that, when the one or more criteria are satisfied, the augmented reality display system presents the launcher at the location in the real-world environment (Hart, Paragraph [0075], "entrance into the geofence 272 can trigger a coupon to appear on a user's augmented reality device <read on presents the launcher at the location> that directs the user to digital content inside or outside the geofence 272"; [0073], "an initial user position 278 can be logged from which the user travelled into the geofence 272"), even if the augmented reality display system was shut down after persistently placing the launcher (Hart, Paragraph [0084], "The loading of digital content into the digital airspace can result in some or all augmented reality devices to be updated with data corresponding to the presence of digital content in the assigned physical location <read on persists across devices/shutdowns — content lives in the digital airspace, not in any one device's runtime>"; [0083], "Initially, the routine 280 has digital airspace corresponding to a particular physical location being purchased in step 282 and subsequently loaded with digital content specific to the purchaser"), wherein the one or more criteria comprise whether the user returns to vicinity of the location (Hart, Paragraph [0073], "Through continuous, sporadic, and routine user position tracking by an augmented reality device in association with the geofence 272, an initial user position 278 can be logged from which the user travelled into the geofence 272 <read on the user returns to vicinity of the location>"; [0075], "entrance into the geofence 272 can trigger a coupon to appear").
Hart and Sharma/Murphy are analogous since all three address presentation of content/windows to a user. Sharma and Murphy together establish placement of an application window / preview in the AR environment, but neither addresses (a) persistence of the placement across system shutdowns, (b) anchoring to a real-world geographic location, or (c) re-presentation when the user returns to the vicinity. Hart provides all three — digital content (which the claim broadly calls a "launcher") is anchored to a real-world physical location (latitude/longitude/altitude), persists in the digital airspace (separate from any one device), and is presented to the user's AR display when the user enters a geofence around that location (i.e., returns to the vicinity). It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate real-world-location-anchored, geofence-triggered, server-side persistent digital content presentation taught by Hart into the modified Sharma/Murphy AR system, such that a launcher for the application is persistently placed at a real-world location and re-presented when the user (wearing the AR display system) returns to the vicinity of that location, even across device shutdowns. The motivation is to allow users to leave persistent, location-anchored AR launchers/content in real-world places that re-appear when they (or other users) return to the location — providing a "seamless combination of physical and augmented realities," as discussed by Hart in Paragraph [0018] ("ideally delivering a seamless combination of physical and augmented realities via an augmented reality device") and Paragraph [0084] (digital content loaded into the digital airspace is reflected on all augmented reality devices entering the assigned physical location).
Regarding Claim 29, it recites limitations similar in scope to the limitations of Claim 23 and therefore is rejected under the same rationale.
Claim(s) 24-26, 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 7596766 B1, hereinafter Sharma) in view of Murphy et al. (US 20190018567 A1, hereinafter Murphy) as applied to Claims 18, 27 above respectively and further in view of Kurtenbach et al. (US 20060125822 A1, hereinafter Kurtenbach).
Regarding Claim 24, the combination of Sharma and Murphy teaches the invention in Claim 18.
The combination further teaches creating a user interface for the [[3D]] display [[volume managing unit]] (Sharma, Column 7, Line 38-41, "The display screen 130 displays an application window 160 and a preview window 170, which is created by the preview window generator 150. The application window 160 includes a dialog box 163 <read on user interface>").
Sharma does not explicitly disclose but Murphy teaches in response to a request for creating the 3D display volume managing unit (Murphy, Paragraph [0089], "trigger 530 can be activated (depressed) to select an application window in the VR/AR environment when a corresponding cursor is placed over the application window").
As explained in rejection of claim 18, the obviousness for combining of Murphy into Sharma is provided above.
But the combination of Sharma and Murphy do not explicitly disclose creating the 3D display volume managing unit as a first node; creating a user interface for the 3D display volume managing unit as a second node; and placing the second node as a child node of the first node.
However, Kurtenbach teaches in response to a request for creating the 3D display volume managing unit (Kurtenbach, Paragraph [0047], "an application, such as the manager of a 3D drawing program requesting the allocation of one or more volumetric drawing windows <read on 3D display volume managing unit>. This is an application started within the volumetric display and it asks for display space"), creating the 3D display volume managing unit as a first node (Kurtenbach, Paragraph [0049], "The volume manager uses a data structure such as depicted in FIG. 16. This data structure is a list data structure having a root node 280 and can take the shape of a linear list or a tree of VW nodes 282 <read on first node>"; [0047], "The volume manager allocates 240 a VW data structure (see FIG. 16) for each of the volumetric windows requested by the application"), creating a user interface for the 3D display volume managing unit as a second node (Kurtenbach, Paragraph [0041], "FIG. 13 illustrates a volume window 210, actually a visible bounding box of a volume window <read on volume managing unit> , having an attached volume activation region 212 that acts like the title bar <read on user interface> at the top of a typical 2D window … Within the activation region 212 are four controls that could be considered among the typical controls for a volume window. These controls include a move volume window control 214, a maximize volume window control 266, a minimize volume window control 218 and a resize volume window control 220"), and placing the second node as a child node of the first node (Kurtenbach, Paragraph [0052], "ParentVW, by default is the RootVW. However, if subVW are defined, then the parentVW will not be the RootVW but instead the true owner of the subVW <read on placing the second node as a child node of the first node>"; [0054], "Volume windows can be related hierarchically such that a window can have volume sub-windows <read on child node>").
Kurtenbach and Sharma/Murphy are analogous since all three deal with displaying and managing application/content windows on a display, they address the common problem of organizing window content and associated UI elements for user interaction. Sharma and Murphy together provide the AR placement and link-driven instantiation of a 3D display volume managing unit, but neither addresses how the volume and its UI elements are organized internally in a node hierarchy. Kurtenbach provides exactly that — a tree-of-nodes data structure for volume windows, where each window is a node, where sub-windows act as children of a parent, and where the volume window has an attached title bar / activation region carrying the move/maximize/minimize/resize controls (i.e., a user interface). It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Kurtenbach's tree-of-volume-window-nodes (with the UI title-bar/activation-region implemented as a sub-node child of the volume-window node) into the modified Sharma/Murphy AR system so that the 3D display volume managing unit and its UI can be programmatically managed as related nodes. The motivation is to provide an organized data-structure-based management of volume windows and their associated UI controls (move, maximize, minimize, resize) so that operations on the parent automatically affect its UI/sub-window children, as discussed by Kurtenbach in Paragraph [0054] ("It is preferred that all sub-windows obey the operations of the parent in the hierarchy … if a parentVW is minimized or closed, the subVW does comply").
Regarding Claim 25, the combination of Sharma and Murphy teaches the invention in Claim 18.
The combination does not explicitly disclose but Kurtenbach teaches creating the 3D display volume managing unit as a node in a tree structure (Kurtenbach, Paragraph [0049], "The volume manager uses a data structure such as depicted in FIG. 16. This data structure is a list data structure having a root node 280 and can take the shape of a linear list or a tree of VW nodes 282 <read on node in a tree structure>"), creating a parent 3D display volume managing unit as a parent node for the 3D display volume managing unit in the tree structure (Kurtenbach, Paragraph [0052], "ParentVW <read on volume managing unit>, by default is the RootVW. However, if subVW are defined, then the parentVW will not be the RootVW but instead the true owner of the subVW <read on parent node for the 3D display volume managing unit>"), wherein the node corresponds to a space that corresponds to the 3D display volume managing unit (Kurtenbach, Paragraph [0052], "The contentVRgn defines the space the volume window owns <read on node corresponds to a space>, relative to the application … boundingBoxPositionVW specifies the absolute position of the VW relative to the (0, 0, 0) origin of the volumetric display"), the parent node corresponds to a parent space that corresponds to the parent 3D display volume managing unit (Kurtenbach, Paragraph [0054], "Volume windows can be related hierarchically such that a window can have volume sub-windows <read on parent node corresponds to a parent space>"; [0052], "ParentVW … is … the true owner of the subVW"), and a child location of the 3D display volume managing unit remains unchanged even when a parent location of the parent 3D display volume managing unit is changed (Kurtenbach, Paragraph [0054], " If a parent gets moved all of the children are moved by the same amount and in the same direction. A Subv W does not necessarily move with the parentVW <read on a child location … remains unchanged even when a parent location … is changed>"; [0054], "A parent may or may not "clip" the display of its children against its own bounding box. That is, children may exist outside of the volume of the parent").
Kurtenbach and Sharma/Murphy are analogous since all three deal with displaying and managing application/content windows on a display, they address the common problem of organizing window content and associated UI elements for user interaction. Sharma and Murphy together establish the AR placement of the 3D display volume managing unit but neither describes a tree-structured parent-child node organization where each node corresponds to a 3D space and the child's position can be independent of the parent's. Kurtenbach supplies exactly this — a VW tree where each volume window has its own space (contentVRgn / boundingBoxPositionVW), where a parent VW owns sub-VWs, and where a sub-VW does not necessarily move with the parent. It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Kurtenbach's tree-organized VW hierarchy with independent child positioning into the modified Sharma/Murphy AR system. The motivation is to provide flexible spatial organization of multiple related volume windows in 3D space, so that some children stay anchored in place while a parent is repositioned (e.g., letting an anchored AR application window stay where the user placed it even if a containing parent window is moved), as discussed by Kurtenbach in Paragraph [0054] ("A SubVW does not necessarily move with the parentVW … children may exist outside of the volume of the parent").
Regarding Claim 26 (depends on Claim 26 — apparent typo; treated as depending on Claim 25) below, the combination of Sharma, Murphy and Kurtenbach teaches the invention in Claim 25.
The combination further teaches maintaining the child location relative to a real-world environment (Murphy, Paragraph [0003], "Augmented reality (AR) or mixed reality (MR), on the other hand, can superimpose virtual images on a real world <read on real-world> environment, or otherwise combine them"; [0089], "the application window can be moved within the VR/AR environment based on a tracked motion of the input device in 3D space while the application window remains selected").
As explained in rejection of claim 18, the obviousness for combining of Murphy into Sharma is provided above.
But combination of Sharma and Murphy do not explicitly disclose maintaining the child location … based at least in part upon (1) whether the 3D display volume managing unit belongs to a group, and (2) whether the parent … or a child … also belongs to the group, and (3) a type of transform applied to the parent … or the child …
However, Kurtenbach teaches maintaining the child location … based at least in part upon (1) whether the 3D display volume managing unit belongs to a group <read on parent-child hierarchy> (Kurtenbach, Paragraph [0054], "Volume windows can be related hierarchically <read on belongs to a group> such that a window can have volume sub-windows. It is preferred that all sub-windows obey the operations of the parent in the hierarchy"), and (2) whether the parent 3D display volume managing unit [[or a child 3D display volume managing unit]] also belongs to the group (Kurtenbach, Paragraph [0052], "ParentVW, by default is the RootVW. However, if subVW are defined, then the parentVW will not be the RootVW but instead the true owner of the subVW <read on parent … also belongs to the group>"; [0054], "A child preferably inherits properties or attributes of the parent volumetric window"), and (3) a type of transform applied to the parent 3D display volume managing unit [[or the child 3D display volume managing unit]] (Kurtenbach, Paragraph [0054], "if a parent window is deleted all children of the parent are also deleted. If a parent gets moved all of the children are moved by the same amount and in the same direction. A SubVW does not necessarily move with the parentVW. However, if a parentVW is minimized or closed, the subVW does comply <read on type of transform applied to the parent … determines whether child location is maintained>").
Kurtenbach and Sharma/Murphy are analogous since all three deal with displaying and managing application/content windows on a display, they address the common problem of organizing window content and associated UI elements for user interaction. Sharma and Murphy establish placement of windows in AR/real-world environment but do not address group-based, transform-type-based maintenance of child position. Kurtenbach supplies exactly this: a hierarchical grouping (parent + sub-windows form a hierarchy) and explicit, transform-type-dependent propagation rules — delete and minimize/close propagate to children, while move does not necessarily propagate. It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Kurtenbach's hierarchical-grouping and transform-type-dependent child-location policy into the modified Sharma/Murphy AR system to maintain a child volume's location in the real-world environment based on its grouping with the parent and on the type of transform applied. The motivation is to allow consistent, intuitive behavior of grouped/related volume windows in AR — children obey parent operations like close/minimize but can retain their independent real-world placement under move operations — as discussed by Kurtenbach in Paragraph [0054].
Regarding Claim 30, it recites limitations similar in scope to the limitations of Claim 25 and therefore is rejected under the same rationale.
Response to Arguments
Regarding claim interpretation based on 35 U.S.C. 112(f) for Claims 1-5, 8-22. As stated in MPEP 2181, I: examiners will apply 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph to a claim limitation if it meets the following 3-prong analysis:
(A) the claim limitation uses the term "means" or "step" or a term used as a substitute for "means" that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for" (e.g., "means for") or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function
For example, “3D display volume managing unit” in Claim 7, 10, 11 is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because it uses a generic placeholder: “unit” coupled with functional language “configured to generate control stream data” without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier. “tiling” simply modifies the “unit” by its functionality, and fail to provide structural description for the “unit”. Therefore, The § 112(f) interpretation of "3D display volume managing unit" in claims 7, 10, and 11 is maintained. Applicant is reminded that if Applicant does not wish the "3D display volume managing unit" to be interpreted under § 112(f), Applicant may amend the claim limitation to affirmatively recite the structural identity of the unit — e.g., by describing the "3D display volume managing unit" as a bounded volumetric display space (Prism) having defined structural properties — or may present a showing demonstrating that "3D display volume managing unit" has a recognized, sufficiently definite structural meaning to one of ordinary skill in the relevant art. See MPEP § 2181(I); Office Action at p. 4–5.
Applicant’s arguments with respect to claim 7, 18 filed on 4/29/2026, with respect to rejection under 35 USC § 103 in regard to prior art does not teaches the limitation(s) have been considered but are moot in view of the new ground(s) of rejection. it has now been taught by the combination of prior arts Sharma and Murphy.
In regard to Claims 8-13 they directly/indirectly depends on independent Claim 7. Applicant does not argue anything other than the independent claim 7. The limitations in those claims in conjunction with combination previously established as explained.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YUJANG TSWEI whose telephone number is (571)272-6669. The examiner can normally be reached 8:30am-5:30pm EST.
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, Kent Chang can be reached at (571)272-7667. 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.
/YuJang Tswei/Primary Examiner, Art Unit 2614
Prosecution Insights