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 .
Response to Arguments/Amendments
Applicant's amendment filed on July 24, 2026 have been fully considered.
Applicant's arguments filed July 24, 2026 have been fully considered but they are not persuasive.
In pages 7 of the remarks, the applicant argues that Hamaker et al. (US 20200035206 A1, hereinafter “Hamaker”) fails to disclose the elements described in page 1 of the remarks with respect to the newly amended limitation of claims 9, and 12:
“upon the reception from said computing device of a command to display, an identifier of said a previously saved layout and at least one value of at least one command parameter of said previously saved layout,
retrieving, using said identifier, said previously saved layout from said storage medium, and displaying said previously saved layout according to said at least one value of said at least one command parameter”
Applicant further argues that Hamaker’s “host [11] sends to the VR headset [12] both instructions and metadata (see Hamaker [0131]). In the wording of claim 1, this would mean that each time a layout is to be displayed, the complete layout including commands is sent to be displayed”.
Examiner respectfully disagrees.
In Hamaker’s system described in paragraph 143, 118, and 166, the memory in the NED (surround buffer 52, and memory 55) stores pre-generated full-screen events with corresponding layouts and can be triggered by a single-packet flag containing identifiers and parameters to execute such full-screen event such as the explosion [84], so it can be shown with almost no delay. This means that the layout for the full-screen event is already previously saved in the memory of the NED and is triggered by only a single-packet flag, therefore, Hamaker’s system is not limited to only “that each time a layout is to be displayed, the complete layout including commands is sent to be displayed” as argued by the applicant. The single-packet flag must contain an identifier to distinguish which specific event to trigger (among other pre-set full screen events), otherwise, the system will not know which events to trigger. (Hamaker: ¶118, “the compositor [14] contains an additional memory [55] for pre-set full-screen events. These might include, for example: [0119] Explosion whiting out the screen beyond the Moving Foreground [0120] ‘Game Over’ screen [0121] Shattering or obscured pilot's visor”; ¶143, “A special case is the use of a pre-generated full-screen event from the memory [55] in the compositor [14], such as the explosion [84] shown in FIG. 8 and described below. The use of a pre-generated full-screen event could be triggered by a signal or command from the host [11], or by some other input such as user interaction with a controller or some particular sensor input. However, it is most likely that the host [11] will trigger the display of a full-screen event. The trigger could be in the form of a single-packet flag, which could be sent over the connection to the headset [12] very quickly, meaning that a pre-generated full-screen event could be shown with almost no delay. . .”, ¶166, “FIG. 8 shows an example of a full-screen event, . . . In this example, the full-screen event is an explosion, which is therefore likely to be an event spanning a period of time, and may also be accompanied by other output such as sound, vibration, smell, etc. as permitted by the user interface”).
In Hamaker paragraph 144, discloses an event where the host only sends new locations for the spaceships instead of sending fresh display data, if the surround buffer 52B (which is a memory) contains the previously saved layout of the Middleground Scene with the spaceship sprite and location. This means that the host only sends new location within the single-packet flag, the coordinates to display the new layout of the spaceships. In this case, the full screen-event associated with the previously saved spaceship layout of the Middleground Screen is the spaceships location change, the host sends a single-packet flag including the identifier for the spaceship event; and at least one value of at least one command parameter of said previously saved spaceship layout, which is the new location coordinates of the spaceship to reflect the change. (Hamaker: ¶144, “The frames may also be re-composed if the compositor [14] receives a signal from the host [11] via the input engine [51] that the content of the display data has changed: for example, the spaceships [24] in the Moving Middleground Scene [3B] have moved. This will likely be accompanied by fresh display data showing the spaceships [24] in their new locations, though if the surround buffer [52B] for the Moving Middleground Scene [3B] is in fact represented by sprites and locations, the change may consist only of new locations for the spaceships [24]”).
Therefore, Hamaker teaches:
upon the reception from said computing device a command to display, an identifier of a previously saved layout, and at least one value of at least one command parameter of said previously saved layout (NOTE: As cited and discussed above, upon the reception from the host a command to display, which is the signal or the single-packet flag to trigger full screen events and display previously saved layout of the Middleground Scene with spaceship sprites and locations previously saved in the buffer in the headset. The single-packet flag includes the identifier that distinguishes which specific event to trigger; and the at least one value of at least one command parameter of said previously saved layout is the new location coordinates of the spaceship. Host sends command to display via a single packet flag > upon reception of the NED of the single packet flag > triggers the change in location of the spaceship according to the new location parameters > display the layout of the Middleground Scene reflecting the new locations of the spaceships.),
retrieving, using said identifier, said layout from said storage medium, and displaying said previously saved layout according to said at least one value of at least one command parameter (NOTE: As cited and discussed above, the host sends a single packet flag including the new coordinates of the spaceships, which is the at least one parameter > NED receives single packet flag and identify which event to trigger based on the signal from the host > determines that the event is associated with a previously saved layout, which is the Middleground Scene previously stored in the Buffer >> display the Middleground Scene with new spaceship locations according to the location parameters received from the host.).
In regards to the Sunakawa et al. (US 20080211825 A1, hereinafter “Sunakawa”), Sunakawa is only relied upon the explicit disclosure of a host sending a packet including a save command to save a layout to a client device, because Hamaker does not explicitly disclose which side (host/client) of the system commands to store the pre-set full screen event layouts in the client’s NED memory.
Sunakawa is relied upon to teach:
a command to save said layout on said storage medium (Sunakawa: ¶224, “. . . the multi-display server 63 generates layout command packets by packetizing the layout instruction information (layout commands) that instructs the layout of image contents, and transmits them to the display units 71 to 79. . .; ¶190, “. . . The layout command packet stores layout commands . . .”; ¶218, “. . . the packet analysis unit 153 analyzes the accepted (received) layout command packets, and stores layout commands in the layout storage unit 111. . .”; ¶551, “. . . The layout storage unit 2111 stores layout commands based on the layout command packet. . .; NOTE: The command to save the layout is in the layout command packet. Sunakawa explicitly discloses that the layout commands are stored in a layout storage unit 111 of the receiver’s display units 71-79 based on the layout command packet transmitted by the host.)
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to combine Hamaker and Sunakawa and include: a command to save said layout on said storage medium.
The reason for doing so is “since the image content data and layout commands are transmitted using packet communications of the same communication scheme, the image content data and layout commands can be handled by the same packet processing system. Therefore, . . . the interface can be simplified” (Sunakawa: ¶225).
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.
The limitation “display means configured to display . . .” in claim 9 is interpreted under 35 U.S.C. 112(f):
Function: “to display one or more display resources”
Structure: “The display means may be for example an OLED display” as described in paragraph 40, and equivalents thereof.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 9, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Hamaker et al. (US 20200035206 A1, hereinafter “Hamaker”) in view of Sunakawa et al. (US 20080211825 A1, hereinafter “Sunakawa”).
Regarding claim 9,
Hamaker teaches:
A Near-Eye Display device (Hamaker: ¶96, “. . . virtual-reality headset [12] . . .”; also see Fig. 1)
comprising: - a communication endpoint configured to establish a connection with a computing device (Hamaker: ¶96, “. . . a virtual-reality headset [12] connected to a host device [11] . . . using a connection that may be wired or wireless, or even over a network such as the Internet, but is preferably wireless. . .; ¶112, “. . . Data transmitted to the headset [12] from the host [11] is sent directly to the compositor [14], which receives it through an input engine [51]. . . “; NOTE: The computing device is the host device, and the communication endpoint is the input engine);
display means configured to display one or more display resources (Hamaker: ¶96, “. . . set of goggles [13], which incorporates two eyepieces [16]. Each eyepiece [16] is a small independent display device which in use is positioned in front of the user's eye so as together to create an impression of stereoscopic—and therefore three-dimensional—vision.”);
a storage medium (Hamaker: ¶110, “FIG. 5 . . . showing four surround buffers [52], a second memory [55] and two finished frame buffers [54] . . .; ¶112, “. . . The surround buffers [52] are areas of memory that store all the image data . . .”; ¶118, “. . . an additional memory [55] for pre-set full-screen events . . .”);
at least one processing logic (Hamaker: ¶97, “. . . The compositor [14] is a processor . . . programmable processor, . . . it receives display data and outputs two frames of composited image data. . .”; ¶176, “Functionality of the modules may be embodied in one or more hardware processing device(s) e.g. processors and/or in one or more software modules . . . software instructions to implement the described methods. . .”; NOTE: The software instructions is the processing logic that are processed by the processors.)
configured to:- upon the reception from said computing device (Hamaker: ¶32, “. . . receiving, from the host device, display data and/or display elements that the host device determines may be needed for compositing into an image at a future time . . .”; ¶131, “. . . At Step S62, the data is transmitted to the compositor [14] in the virtual reality headset [12]. It will be received by the input engine [51], which determines the nature of the data and its destination. The host [11] may transmit instructions and metadata to the compositor [14], which will also be received by the input engine [51] and transmitted directly to the composition engine [53] in order to change its behaviour. . .”; NOTE: The Near Eye Display receives the data and instructions from the host is data reception from said computing device. The computing device is the host.)
of a layout comprising at least one graphical command, each of said at least one graphical command being defined by an identifier and at least one command parameter (Hamaker: : ¶36, “wherein the image comprises at least display data forming a background layer, display elements forming one or more foreground layers and an overlay data layer ¶106, “. . . a single sprite of a spaceship—perhaps a three-dimensional wireframe allowing it to be rotated—could be stored together with the locations at which different spaceships are to be displayed and their relative sizes so that the sprite could be translated and transformed . . .”; ¶131, “. . . The host [11] may transmit instructions and metadata to the compositor [14]. . . Display data, however, is identified as such by, for example, flags in a packet header, and is placed in the appropriate surround buffer [52]. . . ”; ¶141, “. . . the composition engine [53] will compose new frames for display at Step S66. In order to do this it will take display data from each surround buffer [52] in the location of the required view, which may be stored as a set of co-ordinates indicating the four corners of the view, as a single co-ordinate and a set of dimensions, or in any other appropriate format.. . .”; NOTE: Applicant’s argues that Hamaker’s host is only limited to transmit “in practice an image” as noted in applicant’s remarks page 10. Hamaker paragraph 131 explicitly discloses that the host transmits “instructions and metadata” received by the compositor which is a part of the NED. These instructions are graphical commands because it causes the NED to composite new frames for display from the host. The identifiers are flags in the packet header, and the command parameter is the location information in the display data for the layout of an object or sprite to render to their assigned location. Host transmits graphical commands (instructions and metadata) to the NED received by the compositor >> compositor executes the graphical commands to compose new frames, therefore, the host sends a layout with graphical commands)
upon the reception from said computing device a command to display, an identifier of a previously saved layout, and at least one value of at least one command parameter of said previously saved layout (Hamaker: ¶118, “the compositor [14] contains an additional memory [55] for pre-set full-screen events. These might include, for example: [0119] Explosion whiting out the screen beyond the Moving Foreground [0120] ‘Game Over’ screen [0121] Shattering or obscured pilot's visor”;
¶143, “A special case is the use of a pre-generated full-screen event from the memory [55] in the compositor [14], such as the explosion [84] shown in FIG. 8 and described below. The use of a pre-generated full-screen event could be triggered by a signal or command from the host [11], or by some other input such as user interaction with a controller or some particular sensor input. However, it is most likely that the host [11] will trigger the display of a full-screen event. The trigger could be in the form of a single-packet flag, which could be sent over the connection to the headset [12] very quickly, meaning that a pre-generated full-screen event could be shown with almost no delay. . .”,
¶166, “FIG. 8 shows an example of a full-screen event, . . . In this example, the full-screen event is an explosion, which is therefore likely to be an event spanning a period of time, and may also be accompanied by other output such as sound, vibration, smell, etc. as permitted by the user interface”;
¶144, “The frames may also be re-composed if the compositor [14] receives a signal from the host [11] via the input engine [51] that the content of the display data has changed: for example, the spaceships [24] in the Moving Middleground Scene [3B] have moved. This will likely be accompanied by fresh display data showing the spaceships [24] in their new locations, though if the surround buffer [52B] for the Moving Middleground Scene [3B] is in fact represented by sprites and locations, the change may consist only of new locations for the spaceships [24]”).
NOTE: As cited and discussed above, upon the reception from the host, a command to display, which is the signal or the single-packet flag to trigger full screen events and display previously saved layout of the Middleground Scene with spaceship sprites and locations previously saved in the buffer in the headset or NED. The single-packet flag includes the identifier that distinguishes which specific event to trigger; and the at least one value of at least one command parameter of said previously saved layout is the new location coordinates of the spaceship. Host sends command to display via a single packet flag > upon reception of the NED of the single packet flag > triggers the change in location of the spaceship according to the new location parameters > display the layout of the Middleground Scene reflecting the new locations of the spaceships.),
retrieving, using said identifier, said layout from said storage medium, and displaying said previously saved layout according to said at least one value of at least one command parameter (NOTE: As cited and discussed above, host sends a single packet flag including the new coordinates of the spaceships, which is the at least one parameter > NED receives single packet flag and identify which event to trigger based on the signal from the host > determines that the event is associated with a previously saved layout, which is the Middleground Scene previously stored in the Buffer >> display the Middleground Scene with new spaceship locations according to the location parameters received from the host.).
Although Hamaker teaches receiving resources from a host device and reading them from a surround buffer, Hamaker does not explicitly disclose which side (host/client) of the system commands to store the pre-set full screen event layouts in the client’s NED memory. Therefore, Hamaker fails to explicitly disclose if the host device sends: a command to save said layout on said storage medium.
The analogous art Sunakawa teaches:
a command to save said layout on said storage medium (Sunakawa: ¶224, “. . . the multi-display server 63 generates layout command packets by packetizing the layout instruction information (layout commands) that instructs the layout of image contents, and transmits them to the display units 71 to 79. . .; ¶190, “. . . The layout command packet stores layout commands . . .”; ¶218, “. . . the packet analysis unit 153 analyzes the accepted (received) layout command packets, and stores layout commands in the layout storage unit 111. . .”; ¶551, “. . . The layout storage unit 2111 stores layout commands based on the layout command packet. . .; NOTE: The command to save the layout is in the layout command packet. Sunakawa explicitly discloses that the layout commands are stored in a layout storage unit 111 of the receiver’s display units 71-79 based on the layout command packet transmitted by the host.)
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to combine Hamaker and Sunakawa and include: a command to save said layout on said storage medium.
The reason for doing so is “since the image content data and layout commands are transmitted using packet communications of the same communication scheme, the image content data and layout commands can be handled by the same packet processing system. Therefore, . . . the interface can be simplified” (Sunakawa: ¶225).
Regarding claim 12, depending on 9,
method claim 12 is drawn to the method corresponding to the configuration of using same as claimed in apparatus of claim 9. Therefore, method claim 12 corresponds to the configuration of the apparatus of claim 9, and is rejected for the same reasons of obviousness as used above.
Regarding claim 14, depending on 12,
CRM claim 14 is drawn to the CRM corresponding to the method of using same as claimed in claim 12. Therefore, CRM claim 14 corresponds to the method in claim 12, and is rejected for the same reasons of obviousness as used above.
Claims 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Hamaker in view of Sunakawa further in view of Lee et al. (US 20160085266 A1, hereinafter “Lee”)
Regarding claim 17, depending on 9,
The combination of Hamaker and Sunakawa teaches:
The Near-Eye display device of claim 9,
Hamaker further teaches:
wherein display resources belonging to a same application or program installed in the computing device are stored in a same configuration in the storage medium of the Near-Eye Display device (Hamaker: ¶129, “At Step S61, the host [11] generates display data in layers, such as those shown in FIG. 3. Different layers may be generated by different parts of a single application . . .”; ¶106, “. . . a layer may be represented by, for example, a collection of sprites and the locations in which they are to be displayed . . . could be stored together with the locations . . .”; ¶112, “. . . The surround buffers [52] are areas of memory that store all the image data comprising the display element or elements in each layer. . .”; NOTE: the generated layers which are the display resources from the same or single application are stored in a same configuration in the NED or the VR device of Hamaker in the surround buffers 52 which is the configuration.),
However, Hamaker and Sunakawa fails to teach said configuration corresponding to a defined folder.
The analogous art Lee teaches:
said configuration corresponding to a defined folder in a storage medium (Lee: ¶196, “. . . the photographing device can save the photographed photo to a preset location. In this case, the preset location may include at least one of an internal storage place of the photographing device . . . the preset location may include a specific folder in the internal storage place . . .”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to combine Hamaker, Sunakawa, and Lee and implement Lee’s method of creating specific folder as preset save location for files such that said configuration corresponding to a defined folder in a storage medium.
The reason for doing so is for better file organization such as preventing overwriting files with same file names; simplifying data management such as deleting application data all at once without affecting files of other applications.
Regarding claim 18, depending on 17,
The combination of Hamaker, Sunakawa, and Lee teaches:
The Near-Eye display device of claim 17,
Lee further teaches:
wherein the at least one processing logic is configured to receive from said computing device commands to perform one or more of:
obtaining a list of configurations in said Near-Eye Display device;
setting one of the configurations in said list as an active configuration;
reading the content of a configuration;
writing the content of a configuration (Lee, paragraph 193 “Having received the remote save command, the photographing device can save the photographed photo to a preset location . . the photographing device can save the photographed photo to a preset location. In this case, the preset location may include at least one of an internal storage place of the photographing device . . . the preset location may include a specific folder in the internal storage place . . .”; NOTE: The configuration is the specific folder. When the photo which is the content is saved in the specific folder, it writes the content to that specific folder. Saving is writing data.);
creating a configuration; deleting a configuration.
Claims 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Hamaker in view Sunakawa further in view of Lee further in view of Naga et al. (US 20110191544 A1, hereinafter “Naga”).
Regarding claim 19, depending on 17,
The combination of Hamaker, Sunakawa and Lee teaches:
The Near-Eye display device of claim 17, wherein the at least one processing logic is configured to receive commands from the computing device to:
Although the above combination teaches receiving a command from a host device to delete content (Lee: ¶194, “. . . the controller 180 can transmit a remote delete command to the photographing device [S311]. Having received the remote delete command, the photographing device can delete the photographed photo. . .), the above combination fails to teach: prior to create a configuration or save a display resource to obtain an amount of free space; if said free space is not sufficient to create the configuration or save the display resource, delete an other configuration.
The analogous art Naga teaches:
prior to create a configuration or save a display resource to obtain an amount of free space to: obtain an amount of free space (Naga: ¶30, “. . . identifying an amount of free space in the cache prior to the step of including the cache object and the child object in the cache. . . NOTE: The creating a configuration is the step of including the cache object, the cache object is the configuration);
if said free space is not sufficient to create the configuration or save the display resource, delete an other configuration (Naga: ¶30, “on determining that there is insufficient space in the cache, identifying a replaceable cache object and deleting one or more child objects associated with the replaceable cache object and/or the replaceable cache object from the cache. . .; ¶82, “. . . space is created in the cache by deleting folders . . .”).
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to combine Hamaker, Sunakawa, Lee, and Naga to implement deletion of folders or objects if insufficient space is determined to include: prior to create a configuration or save a display resource to obtain an amount of free space; if said free space is not sufficient to create the configuration or save the display resource, delete an other configuration.
The reason for doing so is to “ensure that related objects will be included in the cache and appropriate measures may be taken if there is insufficient space in the cache to accommodate both the cache object and the child object” (Naga: ¶9).
Regarding claim 20, depending on 19,
The combination of Hamaker, Sunakawa, Lee, and Naga teaches:
The Near-Eye display device of claim 19,
Naga further teaches:
wherein the other configuration is the configuration that has been set as active configuration since the longest time (Naga: ¶31, “. . .deleting one or more child objects associated with the replaceable cache object and/or the replaceable cache object from the cache . . .; ¶35, “The replaceable cache object may be identified as the object which has been least recently used among all objects of the cache”; ¶85, “. . . space is created . . . by deleting folders according to how often they have been accessed. Other criteria for identifying replaceable cache objects . . . pseudo least recently used (PLRU), . . .”; NOTE: the configuration that has been set as active is the time the object was last accessed or used. Naga’s system identifies a replaceable object for deletion based on its least recently used data. The least recently used object is an object that has not been access for the longest time and is identified as a replaceable object for deletion.)
Regarding claim 21, depending on 19,
The combination of Hamaker, Sunakawa, Lee, and Naga teaches:
The Near-Eye display device of claim 19,
Naga further teaches:
wherein the other configuration is the configuration that is set as active configuration the least often (Naga: ¶31, “. . .deleting one or more child objects associated with the replaceable cache object and/or the replaceable cache object from the cache . . .; ¶34, “The replaceable cache object may be identified on the basis of a frequency at which cache objects are accessed”; ¶85, “¶85, “. . . space is created . . . by deleting folders according to how often they have been accessed . . . least frequently used (LFU). . . NOTE: the configuration that has been set as active is the number of times the object was accessed or used. Naga’s system identifies a replaceable object for deletion based on a frequency at which cache objects are accessed. The least frequently used object is an object that is used the least often and is identified as a replaceable object for deletion.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PATRICK GALERA whose telephone number is (571)272-5070. The examiner can normally be reached Mon-Fri 0800-1700 ET.
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, King Poon can be reached at 571-270-0728. 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.
/PATRICK P GALERA/Examiner, Art Unit 2617 /KING Y POON/Supervisory Patent Examiner, Art Unit 2617
Prosecution Insights