DETAILED ACTION
This action is in response to communication filed on 06 March 2026. Claims 1 and 11 are amended. Claims 2-3 and 12-13 are canceled. No claim has been added. Claims 1, 4-11 and 14-19 are pending in the application and have been considered below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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.
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:
“a communicator configured to receive” in claims 11, 14 and 18
“a controller configured to” in claims 11 and 14-18
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.
Response to Arguments
Applicant argues that ["Thus, the Examiner's reliance on Moinzadeh is misplaced. The mechanisms disclosed in Moinzadeh relate to mobile-terminal interaction with vehicle systems, while the present application is limited to server-directed content management within the head unit itself. Accordingly, Moinzadeh does not teach-or even suggest-the features recited in Claims 2 and 3" (Page 10)].
Examiner respectfully disagrees. Cited figs. 4-8 of MOINZADEH depict the mobile phone acts as an IP gateway to make the connection possible between the server and the head unit, therefore content flowing between the server and the head unit through the mobile terminal. For example, MOINZADEH discloses “In block 805, the software 332 generates and sends signaling to cause the IP gateway software 331 on the mobile phone 320 to operate as an IP gateway for forwarding applications to the head unit 321 similar to the scheme described in FIG. 4. In one example, similar to FIG. 4, such signaling includes communications to dynamically load the mobile phone 320 with the software 331 to cause the software 331 to operate thereon for the download to vehicle. This signaling may not take place if the mobile phone 320 is already loaded with the software 331 and ready for IP gateway operation. In other examples, the signaling 345 could originate from the control software 330 on the head unit 321 after the connection 540 is established” (par. 0075); or “in block 503 the software 232 generates and sends signaling 245 to cause the IP gateway software 231 on the mobile phone 220 to operate as an IP gateway for forwarding applications to the head unit 221” (fig. 5, par. 0049). Therefore, MOINZADEH teaches “server-directed content management within the head unit” (see also figs. 4-5; see also fig. 8, boxes 805-807, pars. 0075-0077).
Applicant further argues that ["Thus, the claim itself makes clear that the method is not related to any terminal-to-vehicle interworking framework, and therefore the Examiner's reliance on Moinzadeh whose teachings are premised entirely on mobile-terminal interaction with vehicle systems-is misplaced. For the reasons set forth above, Applicants respectfully submit that the applied references-whether considered individually or in any combination-fail to disclose or render obvious each and every element of claim 10. Accordingly, withdrawal of the rejection of claim is respectfully requested (Pages 11-12)].
Examiner respectfully disagrees. As stated above, in one aspect, MOINZADEH discloses server-head unit communication utilizing the mobile terminal as an IP gateway (see MOINZADEH figs. 4-8, pars. 0049 and 0075-0077).
Thus, the combination of MOINZADEH, TAMP and GODFREY adequately discloses applicant's claimed limitation. Examiner respectfully reminds Applicants that during examination, the claims must be interpreted as broadly as their terms reasonably allow. In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 U.S.P.Q.2d 1827, 1834 (Fed. Cir. 2004).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over MOINZADEH (US20110093153A1) in view of TAMP (US20160352712A1) and further view of GODFREY et al. (US20110289416A1).
As to claim 1, MOINZADEH teaches a method for managing content of a head unit for a vehicle (see par. 0009, wherein FIG. 1 illustrates a system to control the use of a head unit as an extended interface for a phone application in a safe and intelligent manner; as taught by MOINZADEH),
the method comprising: receiving, at the head unit from a server, a content change notification (see figs. 5-8, par. 0049, wherein if the check by the software 232 indicates that the download directory 239 includes at least one application … in block 503 the software 232 generates and sends signaling 245 to cause the IP gateway software 231 on the mobile phone 220 to operate as an IP gateway for forwarding applications to the head unit 221; see also par. 0076, wherein in block 806, the software 332 generates and sends IP packets 545 to download the data from the selected one of the directories onto the vehicle, e.g. either applications M-P and configuration A or applications Q-S and configuration B. The IP packets 545 are received by the mobile phone 320 and forwarded by operation of the software 331 to the head unit 321. It should be understood that in this particular illustration the IP packets 545 include both applications and a configuration for the graphical user interface, but in other scenarios the IP packets 545 might contain either an application or a configuration; see also figs. 4-5; see also fig. 8, boxes 805-807, pars. 0075-0077, wherein the mobile phone acts as an IP gateway to make the connection possible between the server and the head unit; paras taught by MOINZADEH);
indicating an occurrence of a content change for a first user among multiple users (see figs. 5-8, par. 0084, wherein a vehicle user can create a plurality of profiles corresponding to the vehicle using the profile creation portion 930 of the user web portal 905. A profile can be created for each person that may use the vehicle. A field 927 requests a unique phone number or other unique identifier of a mobile phone respectively corresponding to each person. A name of each person or other information for each person may be gathered with the phone number(s). After or during profile creation, server 322 creates a download directory for each profile and updates the mapping 350 for each number/directory combination; as taught by MOINZADEH);
and in response to receiving the content change notification at the head unit, performing an operation by the head unit based on i)an activation state of the vehicle (see figs. 1-8, par. 0051, wherein a user of the vehicle can operate the applications J-L using the head unit 221 as an interface. It should be understood that the software 230 and 232 can operate according to any of the principles described in FIGS. 1-3. For example, the software 230 and 232 can regulate utilization of the I/O resources of the head unit 221 by the active application(s) according to current vehicle status; see also par. 0077, wherein in block 807, the software 330 receives the IP packets 545 and installs the applications included therein on the vehicle (installation can be on components of the head unit 321 or other vehicle components). The software 330 also processes the configuration from the IP packets 545 using the web code renderer 399 to generate a particular graphical user interface based on the detected phone number; see also pars. 0026-0027; as taught by MOINZADEH);
and ii) performing, by the head unit, an update with the server according to the content change for the first user (see fig. 5, see par. 0049, wherein in In one example, signaling 245 includes communications to dynamically load the mobile phone 220 with the software 231 in response to the determination in block 502 and cause the software 231 to operate thereon for the download to vehicle; see also par. 0050, wherein in block 505, the software 230 receives the IP packets 230 and installs the applications 240 (J-L) on the vehicle; see also figs. 4-9; as taught by MOINZADEH);
wherein, when the activation state of the vehicle is a turned-on state and the user currently logged in the head unit is the first user, and wherein, when the activation state of the vehicle is the turned-on state and the user currently logged in the head unit is the second user different from the first user (see fig. 5, par. 0047, wherein In block 501, in response to the vehicle being powered up, the control software 230 sends a signal 244 to the server 222 indicating vehicle power-up; see par. 0048, wherein In block 502, the software 232 checks a download directory 239 (sometimes referred to as a “sandbox”) associated with the vehicle to determine if there are any applications to be downloaded to the vehicle; see also par. 0049, wherein in In one example, signaling 245 includes communications to dynamically load the mobile phone 220 with the software 231 in response to the determination in block 502 and cause the software 231 to operate thereon for the download to vehicle. The signaling 245 may not take place if the mobile phone 220 is already loaded with the software 231 and ready for IP gateway operation. In other examples, the signaling 245 could originate from the control software 230 on the head unit 221 in response to detecting vehicle power-up; see also par. 0050, wherein in block 504, the software 232 generates and sends IP packets 250 to download the applications 240 onto the vehicle; as taught by MOINZADEH).
MOINZADEH does not expressly teach and ii) whether a user currently logged into the head unit is the first user or a second user different from the first user, the operation being one of i) setting, by the head unit, a content change flag for the first user and performing the operation comprises performing the update according to the content change for the first user, performing the operation comprises setting the content change flag for the first user.
In similar field of endeavor, TAMP teaches and ii) whether a user currently logged into the head unit is the first user or a second user different from the first user (see figs. 1-6, par. 0018, wherein the primary task for all users may include interacting with a screen of the shared-screen system. For example both the driver and passenger(s) of a vehicle can interact with the vehicle head unit. A shared-screen system may also require or provide for sign-in on the system, and the ability to sign in multiple accounts, corresponding to the different users; see also par. 0097, wherein the vehicle head unit of any of Examples 1-3, wherein the vehicle head unit is included in a shared-screen environment, wherein the at least one module is operable by the at least one processor to: determine one or more indications that indicate at least a role or identity of at least one of the first user or the second user in the shared-screen environment; compare the one or more indications to a set of one or more criteria to determine the role or identity of the at least one of the first user or the second user in the shared-screen environment; and responsive to receiving an indication of user input from the at least one of the first user or the second user in the shared-screen environment, execute, based at least in part on the role or identity of the at least one of the first user or the second user, one or more operations; as taught by TAMP).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the MOINZADEH apparatus to include the teachings of TAMP for ii) whether a user currently logged into the head unit is the first user or a second user different from the first user. Such a person would have been motivated to make this combination as it would be beneficial to determine which user is logged in so that the output can be tailored for that user based on permissions and privileges.
MOINZADEH and TAMP do not expressly teach the operation being one of i) setting, by the head unit, a content change flag for the first user and performing the operation comprises performing the update according to the content change for the first user, performing the operation comprises setting the content change flag for the first user.
In similar field of endeavor, GODFREY teaches the operation being one of i) setting, by the head unit, a content change flag for the first user (see par. 0034, wherein an update flag is set at step 312, to indicate that pending content updates are present at or otherwise available at the relay service 116. The master loader 210 then exits this process flow at step 314. The update flag is later utilized by a separate module of the workstation 118 to acquire the updated content if it is relevant to the workstation or the logged on user; as taught by GODFREY).
performing the operation comprises performing the update according to the content change for the first user (see par. 0034, wherein at step 310, the master loader 210 receives a UDP message from relay service 116. An update flag is set at step 312, to indicate that pending content updates are present at or otherwise available at the relay service 116. The master loader 210 then exits this process flow at step 314; as taught by GODFREY),
performing the operation comprises setting the content change flag for the first user (see par. 0034, wherein at step 310, the master loader 210 receives a UDP message from relay service 116. An update flag is set at step 312, to indicate that pending content updates are present at or otherwise available at the relay service 116. The master loader 210 then exits this process flow at step 314; as taught by GODFREY).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the MOINZADEH and TAMP apparatus to include the teachings of GODFREY for the operation being one of i) setting, by the head unit, a content change flag for the first user and performing the operation comprises performing the update according to the content change for the first user, performing the operation comprises setting the content change flag for the first user. Such a person would have been motivated to make this combination as it would be beneficial for the users to have a notification when an update is available so that the user does not have to keep checking.
As to claim 10, MOINZADEH, TAMP and GODFREY teach a method for managing content of a head unit for a vehicle, the method comprising: when the vehicle is activated, determining whether there is content change flag that is set in response to receiving, at the head unit from a server, a content change notification indicating an occurrence of a content change for a first user, among multiple users, at the server; determining whether a user currently logged into the head unit is the first user; i) performing an update based on the content change [see rejection of the claim 1 above].
GODFREY further teaches in response to determining that there is a content change flag that is set (see par. 0034, wherein an update flag is set at step 312, to indicate that pending content updates are present at or otherwise available at the relay service 116. The master loader 210 then exits this process flow at step 314. The update flag is later utilized by a separate module of the workstation 118 to acquire the updated content if it is relevant to the workstation or the logged on user; as taught by GODFREY), and based on determining that the user currently logged into the head unit is the first user, ii) turning off the content change flag, and based on determining that the user currently logged into the head unit is not the first, maintaining the content change flag (see figs. 3A-6, for example fig. 3C, par. 0038, wherein If the master loader 210 is configured to force updates of content on each timeout, execution proceeds to step 330, where information for all relevant slide shows/content is pulled from the relay service 116. Alternatively, if the master loader 210 is configured to publish updates of content, then at step 332 the system determines if the pending update flag is set. In the event that the update flag is not set, the master loader 210 loops back to continue checking the timeout status of the update first timer and execution is returned to step 326. If, on the other hand, the update flag is set then the system obtains a list or other identifying means, of content/slide shows that have been updated, at step 332. Utilizing the list of updated content/slide shows, the system pulls the relevant updates from the relay service 116, at step 334; as taught by GODFREY). The motivation for combining MOINZADEH, TAMP and GODFREY is the same as the rejection for claim 1 [see above].
Claims 4-7 are rejected under 35 U.S.C. 103 as being unpatentable over MOINZADEH (US20110093153A1) in view of TAMP (US20160352712A1) and further view of GODFREY et al. (US20110289416A1) and further view of AMIREDDY et al. (US20110289416A1).
As to claim 4, MOINZADEH, TAMP and GODFREY teach the limitations of claim 1. MOINZADEH, TAMP and GODFREY teach setting the content change flag for the first user [see rejection of claim 1].
MOINZADEH, TAMP and GODFREY do not expressly teach wherein, when the activation state of the vehicle is a turned-off state, receiving the content change notification includes receiving a wake-up command from the server, performing the operation comprises and entering a sleep state of the head unit.
In similar field of endeavor, AMIREDDY teaches wherein, when the activation state of the vehicle is a turned-off state, receiving the content change notification includes receiving a wake-up command from the server, performing the operation comprises and entering a sleep state of the head unit (see figs. 1-4, col. 8, ll. 20-32, wherein When the head unit 118 is known by the publish-subscribe message distribution application 124 and/or by the messaging gateway 122 to be in a sleep state and a remote operation command is received from the UE 102, the publish-subscribe message distribution application 124 and/or the messaging gateway 122 may send a high priority short message service (SMS) message to the head unit 118. Even in the sleep mode of operation, a voice channel radio transceiver of the head unit 118 may be operable to receive and process a SMS message. As discussed further hereinafter, the head unit 118 may respond to a high priority SMS message by transitioning from the sleep state to the awake state under some conditions; see also col. 11, ll. 46-55, wherein the remote operations event handling application 158 may also send a head unit awake status message when it initiates to the publish-subscribe message distribution application 124 or to another application that executes in the messaging gateway 122. Alternatively, some other application may send a head unit awake status message to the publish-Subscribe message distribution application 124 or to another application that executes in the messaging gateway 122 when the head unit 118 transitions from a low-power or dormant state to a powered or awake State; see also col. 11, ln. 64-col. 12, ln. 8, wherein when the head unit 118 transitions from the powered or awake state to the low-power or dormant state, the head unit 118 may transmit a head unit asleep status message to the messaging gateway 122, to the publish-subscribe message distribution application 124, and/or to the vehicle remote operations client 106. The head unit 118 may transition to the low-power or dormant state under a variety of conditions, for example in response to a door lock event in combination with an engine off condition. The head unit 118 may transition to the low-power or dormant state in response to an engine off condition and passage of a pre-defined time duration after the engine off event; as taught by AMIREDDY).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the MOINZADEH, TAMP and GODFREY apparatus to include the teachings of AMIREDDY wherein, when the activation state of the vehicle is a turned-off state, receiving the content change notification includes receiving a wake-up command from the server, performing the operation comprises and entering a sleep state of the head unit. Such a person would have been motivated to make this combination as it would be beneficial for the users to have the flag set for availability of an update even when the vehicle and the head unit are off so that when the vehicle is started next time, the update is marked ready for download.
As to claim 5, MOINZADEH, TAMP, GODFREY and AMIREDDY teach the limitations of claim 4. MOINZADEH, TAMP, GODFREY further teach when the content change flag is set for the first user, determining whether the user currently logged into the head unit is the first user, and when the user currently logged into the head unit is the first user, performing the update according to the content change for the first user [see rejection of claim 1].
AMIREDDY further teaches and the activation state of the vehicle changes to a turned-on state after entering of the sleep state (see figs. 1-4, col. 11, ll. 46-55, wherein the remote operations event handling application 158 may also send a head unit awake status message when it initiates to the publish-subscribe message distribution application 124 or to another application that executes in the messaging gateway 122; see also col. 12, ll. 51-57, wherein At block 202, a head unit wake-up reason is determined. A variety of events may occur to cause the head unit 118 to wake up or transition out of dormant operation mode into awake operation mode. One event is receipt of a short message service (SMS) message. The SMS message may be examined to determine if it is a high priority SMS message. See also col. 8, ln. 45, for an engine start vehicle remote operation command; as taught by AMIREDDY).
As to claim 6, MOINZADEH, TAMP, GODFREY and AMIREDDY teach the limitations of claim 5. TAMP teaches when the user currently logged into the head unit is the first user [see claim 1 rejection].
MOINZADEH further teaches turning off the content change flag set for the first user (see par. 0049, wherein signaling 245 may not take place if the mobile phone 220 is already loaded with the software 231 and ready for IP gateway operation; see also par. Also 0084, wherein a vehicle user can create a plurality of profiles corresponding to the vehicle using the profile creation portion 930 of the user web portal 905. A profile can be created for each person that may use the vehicle. A field 927 requests a unique phone number or other unique identifier of a mobile phone respectively corresponding to each person. A name of each person or other information for each person may be gathered with the phone number(s). After or during profile creation, server 322 creates a download directory for each profile and updates the mapping 350 for each number/directory combination. In some examples, the portion 930 can be configured to allow a user to rank the created profiles so that, if the head unit can be coupled to more than one of the mobile devices simultaneously (it can depend on the connection protocol whether this is possible), a higher ranked one of the corresponding profiles will be used; as taught by MOINZADEH) [i.e. the users are distinguished by unique phone numbers, and each user has a designated directory created when there is an update. Thus, if the phone numbers are the same, the users logged on are the same, and if there is one directory, it means there is an update to be downloaded. See also GODFREY, figs. 3a-3C, par. 0034].
As to claim 7, MOINZADEH, TAMP, GODFREY and AMIREDDY teach the limitations of claim 5. TAMP teaches when the user currently logged into the head unit is the second user different from the first user [see claim 1 rejection].
MOINZADEH further teaches maintaining the content change flag set for the first user (see par. 0084, wherein a vehicle user can create a plurality of profiles corresponding to the vehicle using the profile creation portion 930 of the user web portal 905. A profile can be created for each person that may use the vehicle. A field 927 requests a unique phone number or other unique identifier of a mobile phone respectively corresponding to each person. A name of each person or other information for each person may be gathered with the phone number(s). After or during profile creation, server 322 creates a download directory for each profile and updates the mapping 350 for each number/directory combination. In some examples, the portion 930 can be configured to allow a user to rank the created profiles so that, if the head unit can be coupled to more than one of the mobile devices simultaneously (it can depend on the connection protocol whether this is possible), a higher ranked one of the corresponding profiles will be used; as taught by MOINZADEH) [i.e. the users are distinguished by unique phone numbers, and each user has a designated directory created when there is an update. Thus, if the phone numbers are different, the users logged on are not the same, and if there are directories associated with both if there are updates to be downloaded. See also GODFREY, figs. 3a-3C, par. 0034, for setting the flag].
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over MOINZADEH (US20110093153A1) in view of TAMP (US20160352712A1) and further view of GODFREY et al. (US20110289416A1) and further view of WINN et al. (US20110289416A1) and further view of SILBERSTEIN et al. (US20150134781A1).
As to claim 8, MOINZADEH, TAMP and GODFREY teach the limitations of claim 1. MOINZADEH, TAMP and GODFREY do not expressly teach wherein performing the update comprises: requesting and receiving thumbnail information comprising a thumbnail of each of at least one first content of which an original is stored in the server; when a selection command corresponding to at least a portion of at least one thumbnail in the received thumbnail information is received, determining at least one third content of which an original is to be requested from the server based on the at least one thumbnail corresponding to the selection command and at least one second content of which an original is pre-stored in a memory of the head unit; and receiving the original of the at least one third content from the server.
In similar field of endeavor, WINN teaches wherein performing the update comprises: requesting and receiving thumbnail information comprising a thumbnail of each of at least one first content of which an original is stored in the server (see figs. 1-6, pars. 0035-0036, 0041, 0050-0052, 0084 and 0107; wherein WINN teaches causing an interface to be displayed. Providing thumbnails display to the user. receiving a selection of a thumbnail. The system is applied on a client server network; as taught by WINN).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the MOINZADEH, TAMP and GODFREY apparatus to include the teachings of WINN wherein performing the update comprises: requesting and receiving thumbnail information comprising a thumbnail of each of at least one first content of which an original is stored in the server. Such a person would have been motivated to make this combination as it would be beneficial for the users who would like to have a visual indication of what content is being downloaded and stored.
MOINZADEH, TAMP,GODFREY and WINN do not expressly teach when a selection command corresponding to at least a portion of at least one thumbnail in the received thumbnail information is received, determining at least one third content of which an original is to be requested from the server based on the at least one thumbnail corresponding to the selection command and at least one second content of which an original is pre-stored in a memory of the head unit; and receiving the original of the at least one third content from the server.
In similar field of endeavor, SILBERSTEIN teaches when a selection command corresponding to at least a portion of at least one thumbnail in the received thumbnail information is received, determining at least one third content of which an original is to be requested from the server based on the at least one thumbnail corresponding to the selection command and at least one second content of which an original is pre-stored in a memory of the head unit; and receiving the original of the at least one third content from the server (see figs. 1-7, pars. 0047-0054, for example par. 0049, wherein intermediate node 116 can also generate a recommendation for client device 102, which can significantly increase the performance observed by a user at client device 102 when navigating through the catalogue or when consuming high-bitrate data streams. For example, a storage device for intermediate node 116 can also store a plurality of historical interests, and the interest metadata. When the user at client device 102 navigates to a catalogue page that presents information for a movie, client device 102 may disseminate an interest for a thumbnail image to display on the catalogue page. Intermediate node 116 may determine that this thumbnail image is highly correlated with the movie's video stream, by analyzing the historical interests and the interest metadata, and generates a recommendation that includes one or more content objects that make up a beginning portion of the video stream (e.g., a 1 minute video stream). This allows client device 102 to automatically pre-populate the local cache to improve the responsiveness of the user interface in case the local user decides to view the video stream; as taught by SILBERSTEIN).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the MOINZADEH, TAMP, GODFREY and WINN apparatus to include the teachings of SILBERSTEIN when a selection command corresponding to at least a portion of at least one thumbnail in the received thumbnail information is received, determining at least one third content of which an original is to be requested from the server based on the at least one thumbnail corresponding to the selection command and at least one second content of which an original is pre-stored in a memory of the head unit; and receiving the original of the at least one third content from the server. Such a person would have been motivated to make this combination as it would be beneficial for the users who would like to have a better control and performance for downloading the desired content.
As to claim 9, MOINZADEH, TAMP, GODFREY, WINN and SILBERSTEIN teach the limitations of claim 8. WINN further teaches when the original of the at least one third content is received from the server, outputting, via a display of the head unit, a content corresponding to the at least one thumbnail corresponding to the selection command (see figs. 1-6, pars. 0074-0076, wherein WINN teaches third content and update display of the suggested content on the interface. For example, see fig. 2, par. 0074, wherein in block 220, it is determined whether further image selections are received. For example, the further image selections may be received via second user input. In some implementations, the images indicated by the further image selections may include at least one of the one or more second images. In some implementations, the images indicated by the further image selections may include at least one of the one or more recent images. If further image selections are received, the method proceeds to block 214. In some implementations, one or more third images in the image library may be identified. For example, the one or more third images may be identified based on determining characteristics of a selected image from the further image selections; see also par. 0076, wherein the one or more third images may be selected using techniques similar to those used for selecting the one or more second images. In the implementations where one or more third images are identified, the user interface may be updated to include the one or more third images; as taught by WINN).
Claims 11 and 14-19 amount to the system for executing the method of claims 1 and 4-9, respectively. Accordingly, claims 11 and 14-19 are rejected for substantially the same reasons as presented above for claims 1 and 4-9, and based on the references’ disclosure of the necessary supporting hardware and software.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Publication Number
Filing Date
Title
US20140106726A1
2013-03-08
System and Method for Monitoring Apps in a Vehicle to Reduce Driver Distraction
US20140179274A1
2013-12-19
Efficient headunit communication integration
US9109917B2
2013-09-26
Systems and methods for providing input suggestions via the head unit of a vehicle
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOOROSH NEHCHIRI whose telephone number is (408)918-7643. The examiner can normally be reached M-F, 11-7 PST.
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, William L. Bashore can be reached at 571-272-4088. 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.
/KOOROSH NEHCHIRI/Examiner, Art Unit 2174
/WILLIAM L BASHORE/ Supervisory Patent Examiner, Art Unit 2174