Detailed Action
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Continued Examination under 37 C.F.R. § 1.114
A request for continued examination under 37 C.F.R. § 1.114, including the fee set forth in 37 C.F.R. § 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 C.F.R. § 1.114, and the fee set forth in 37 C.F.R. § 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 C.F.R. § 1.114. Applicant's submission filed on October 29, 2025 has been entered.
Response to Amendment
This Non-Final Office action is responsive to the Request for Continued Examination filed on October 29, 2025 (hereafter “Response”). The amendments to the claims are acknowledged and have been entered.
Claims 25, 32, 33, 40, and 41 are now amended.
Claims 25–44 are pending in the application.
Response to Arguments
The 35 U.S.C. § 102 rejection of the method claims are hereby withdrawn, responsive to the Applicant’s amendment requiring the contingencies recited in the contingent limitations of those claims. This ground of rejection is replaced with a new ground of rejection under 35 U.S.C. § 103 involving the same findings and rationale as presented in the 35 U.S.C. § 103 rejections of the non-method claims in the previous Office Action. Accordingly, claims 25, 26, 28, 29, 31, 32, 41, 42, and 44 stand rejected under pre-AIA 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent Application Publication No. 2010/0228740 A1 (“Cannistraro”) in view of U.S. Patent Application Publication No. 2007/0085840 A1 (“Asaka”), with this ground of rejection now extending to the method claims as well. The Applicant’s remarks concerning both references have been considered, but are not persuasive.
The Applicant contends that “Asaka does not disclose a toggle button which, when selected, causes the GUI to toggle between a queue representing a playback sequence and a history.” (Response 6). However, the Applicant’s remarks in support of this position appear to only support the Examiner’s findings, rather than undercut them. Specifically, the Applicant argues that “the only time Asaka describes replacing a play list display with a history list is in association with selecting the text string for ‘played order list’,” but the Applicant also argues that “selection of the Mode button changes the playlist that is presented in the display region, and also changes which character string is highlighted . . . from ‘play list’ to ‘played order list.’” (Response 7). Putting these two arguments together, it seems the Applicant simply agrees with the Examiner that (1) selecting the Mode button moves the cursor to the played order list text, and (2) moving the cursor to the “played order list” text is when Asaka discloses “replacing a play list display with a history list.” It is not clear how replacing a play list with a history list in response to selection of a mode toggling button is any different from what is claimed.
The Applicant also argues that “Asaka does not describe changing the display to show a played order list,” (Response 7) but FIG. 20 clearly shows otherwise. Accordingly, the Examiner is not persuaded of error with respect to Asaka.
Nor is the Examiner persuaded by the Applicant’s remarks concerning the Cannistraro reference. Specifically, the Applicant contends that Cannistraro’s voting buttons are not the same as the claimed “action items,” because the Applicant does not consider Cannistraro’s voting buttons to be “based on a status of the at least one media item with respect to the user profile” as claimed. (Response 9). Under the Applicant’s reading, the criteria for displaying Cannistraro’s voting buttons cited in the rejection (i.e., whether or not the user is allowed to vote on songs at this time) merely “describe a status of the user,” rather than “a status of a media item.” The Examiner respectfully disagrees for two reasons.
For one, Cannistraro explicitly discloses a third example of criteria for displaying the voting buttons that falls within the Applicant’s narrower reading of the claim language, which was cited but not fully discussed in the previous Office Action.1 Specifically, Cannistraro further teaches that “users get only one vote,” but that “they can change their vote.” Cannistraro ¶ 46. Accordingly, with this feature, the decision to present voting buttons for each particular song to each particular user depends upon whether that particular user has already voted for that particular song. Once a user votes for a song, the status of that song with respect to that user is that it is ineligible for a second vote, whereas the status of the other songs with respect to that user is that they are eligible for the user to change his vote. And, as mentioned elsewhere in the rejection, the user interface will only display the voting icons for the songs that “can be voted upon.” Cannistraro ¶ 57.
But, second, the Examiner also respectfully disagrees with the Applicant’s premise about the two disenfranchisement examples. These above two examples at least fall within a broad but reasonable interpretation of the claim language, because when a user account is banned or limited from casting further votes on all of the songs, then the status of all the songs with respect to user account is that the user is prohibited from voting on all of the songs. A status that applies to all of the songs with respect to the user’s account falls within the scope of “a status of the at least one media item with respect to the user profile,” because “all” necessarily includes at least one. The claim language is very careful not to limit the “media items” to different subsets of media items for the same user account, meaning, a status concerning all of the songs with respect to a user account necessarily teaches a status of “at least one” of the songs.
For these reasons, and since each claim stands rejected over the prior art, the request for a notice of allowance is respectfully denied.
Claim Rejections – 35 U.S.C. § 103
The following is a quotation of pre-AIA 35 U.S.C. § 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. § 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 C.F.R. § 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. § 103(c) and potential pre-AIA 35 U.S.C. § 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. § 103(a).
I. Cannistraro and Asaka teach claims 25, 26, 28, 29, 31–34, 36, 37, 39–42, and 44.
Claims 25, 26, 28, 29, 31–34, 36, 37, 39–42, and 44 are rejected under pre-AIA 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent Application Publication No. 2010/0228740 A1 (“Cannistraro”) in view of U.S. Patent Application Publication No. 2007/0085840 A1 (“Asaka”).
Claim 25
Cannistraro teaches:
A non-transitory computer readable medium comprising computer readable code executable by one or more processors to:
“Embodiments within the scope of the present invention may [] include tangible computer-readable media for carrying or having computer-executable instructions or data structures stored thereon.” Cannistraro ¶ 98.
control display of a graphical user interface (GUI)
“FIG. 5 illustrates a sample user interface for a portable device.” Cannistraro ¶ 44.
depicting a toggle
As shown in FIG. 5, “the device displays queued songs 506–512.” Cannistraro ¶ 44. Additionally, the user interface provides a mechanism for toggling between each one of those three parts, e.g., “[a] downward sweeping gesture reveals songs previously played while an upward sweeping gesture reveals additional queued songs.” Cannistraro ¶ 44.
detect selection of the toggle
“While not shown in this figure, a user of the portable device can access [the] additional songs in the playlist by manipulating the device.” Cannistraro ¶ 44.
in response to detecting the selection of the toggle button, replace the queue with a history list representing one or more recently played media items;
As mentioned above, the manipulation (e.g., a downward sweeping gesture) causes the user interface to “reveal[] songs previously played.” Cannistraro ¶ 44.
present a plurality of action items next to at least one media item in the history list
The user interface further provides “icons 518 and 520 that allow users of the paired portable devices to vote a song up 520 or down 518,” Cannistraro ¶ 45, and in addition to FIG. 5 illustrating this feature for the queued items, Cannistraro further teaches that this voting mechanism is available for “songs [to be] re-requested after they have been played,” Cannistraro ¶ 58, i.e., the songs that are in the history list.
based on a status of the at least one media item with respect to the user profile;
The voting buttons may be presented on a contingent basis, depending on whether or not the song is eligible for voting. See Cannistraro ¶ 57 (explaining that the user interface will only display the voting icons for the songs that “can be voted upon”). Cannistraro teaches several reasons as to why a song is would be eligible or ineligible to receive votes from a user, and many those reasons depend on a status of the song with respect to a user profile:
In one example, all of the songs (and thus, “at least one”) may appear ineligible for voting on a particular user’s device because the host disenfranchised that particular user from voting. See Cannistraro ¶ 60.
In another example, all of the songs (and thus, “at least one”) may appear ineligible for voting because that particular user hit a per-account request limit set by the host. Cannistraro ¶ 58.
These above two examples at least fall within a broad but reasonable interpretation of the claim language, because the claim language is very careful not to limit the “media items” to different subsets of media items for the same user account. In other words, when a user account is banned or limited from casting further votes on all of the songs, then the status of all the songs with respect to user account is that the user is prohibited from voting on all of the songs. A status that applies to all of the songs with respect to the user’s account falls within the scope of “a status of the at least one media item with respect to the user profile,” because “all” necessarily includes at least one.
That being said, Cannistraro also teaches a third example that falls within even the Applicant’s narrow interpretation of the claim language, which would require different media items to have different statuses with respect to the same user profile.2 Specifically, Cannistraro further teaches that “users get only one vote,” but that “they can change their vote.” Cannistraro ¶ 46. Accordingly, with this feature, the decision to present voting buttons for each particular song to each particular user depends upon whether that particular user has already voted for that particular song. Once a user votes for a song, the status of that song with respect to that user is that it is ineligible for a second vote, whereas the status of the other songs with respect to that user is that they are eligible for the user to change his vote. And, as mentioned earlier, the user interface will only display the voting icons for the songs that “can be voted upon.” Cannistraro ¶ 57.
and in response to receiving a selection of at least one action item of a plurality of action items, perform at least one action that corresponds to the at least one action item.
“For every positive vote cast by selecting icon 520, the song's voting score 516 is raised one integer.” Cannistraro ¶ 45. Additionally, “[t]he order of the queued songs 506, 508, 510, 512 can be affected by each song's voting score 516.” Cannistraro ¶ 46.
Accordingly, in view of the foregoing, the only difference between the claimed invention and the Cannistraro is the use of a toggle button, specifically, rather than a generic means for toggling between the history and the queue.
Asaka, however, teaches:
A non-transitory computer readable medium comprising computer readable code executable by one or more processors to:
A computer program that directs a CPU 11 to execute the functions described below is stored either on a ROM 12 or removable media 21. Asaka ¶ 179.
control a display device to display a graphical user interface (GUI)
“FIG. 17 illustrates an example of the configuration of the play list screen [411].” Asaka ¶ 341.
depicting a toggle button
Play list screen 411 includes a “mode button 342.” Asaka ¶ 353 (still referring to FIG. 17).
and a queue representing a playback sequence of one or more media items;
In FIG. 17, “the current display mode is a play list mode.” Asaka ¶ 353. While in the play list mode, the play list display section 421 displays a list of songs, and “the play list sequentially plays back the content data,” starting with the “currently-played content data is indicated by the cursor 431.” Asaka ¶ 349. “After the playback of the content data indicated by the cursor 431 ends, the cursor 431 moves to the next content name and artist name (whose content data is ranked second), and then corresponding content data is played back.” Asaka ¶ 349.
detect selection of the toggle button;
The device is configured to detect “[w]hen a user's finger or touch pen pushes the mode button 342.” Asaka ¶ 353.
in response to detecting the selection of the toggle button, replace the queue with a history list representing one or more recently played media items;
“When a user's finger or touch pen pushes the mode button 342, the play list displayed on the play list display section 421 is switched to another one,” where “another one” refers another one of the three modes listed in 422, which include a “Played Order List.” Asaka ¶ 353. Specifically, as shown in FIG. 20, the device replaces the play list display section 421 from FIG. 17 with “a play list where the played content data are listed. The play list of playback history mode lists the content data in order of playback date and time: the recently played content data is listed at the top.” Asaka ¶ 366.
It would have been obvious to a person of ordinary skill in the art at the time of the claimed invention to substitute or supplement the scrolling mechanism that Cannistraro teaches for toggling between the history list and queue, with Asaka’s mode button 342. One would have been motivated to substitute or supplement the scrolling mechanism with the mode button, and there would have been a reasonable expectation of success, because a singular button requires less effort for the user to engage than scrolling to reach the different sections of the list, particularly if the list is very long.
Claim 26
Cannistraro and Asaka teach the non-transitory computer readable medium of claim 25, further comprising computer readable code to:
in response to a determination that a recently played media item meets a first criterion, add the recently played media item to the history list.
“The history lists songs that have already played in ITUNES DJ.” Cannistraro ¶ 82. Hence, the claimed “first criterion” includes a criterion that the song was played. To be clear, however, this is not the only criteria that Cannistraro teaches, and to the extent the claim language might be interpreted to require something more specific, Cannistraro further teaches “[t]he user can specify the number of visible songs in the ITUNES DJ play history.” Cannistraro ¶ 71. In this case, the first criterion (or a second criterion, in addition to simple playback) would include a requirement that the song was one of the last n songs played, where “n” is set by the user.
Asaka likewise provides an overlapping teaching: “The playback history mode displays a play list listing the content data played back in the past.” Asaka ¶ 344.
Claim 28
Cannistraro and Asaka teach the non-transitory computer readable medium of claim 26,
wherein the first criterion comprises full playback of the recently played media item.
The history lists songs that have already played in ITUNES DJ.” Cannistraro ¶ 82.
Claim 29
Cannistraro and Asaka teach the non-transitory computer readable medium of claim 25,
wherein the one or more recently played media items are listed sequentially in the history list based on playback order.
The playback history mode is also referred to as a “played order list” mode, see Asaka ¶ 343, and is therefore understood to be a list that is ordered according to the order in which the media was played in the past.
Claim 31
Cannistraro and Asaka teach the non-transitory computer readable medium of claim 25,
wherein the toggle button is displayed within a header portion of the GUI, wherein the toggle button remains within a fixed position in the header portion of the GUI.
The mode button 342 is displayed within an “operation setting display section 422,” Asaka ¶ 353, which remains fixed relative to changes that are applied to the adjacent play list display section 421. See Asaka ¶ 354.
Claim 32
Cannistraro and Asaka teach the non-transitory computer readable medium of claim 25,
wherein the one or more recently played media items in the history list are each displayed concurrently with one or more of the plurality of action items, wherein the one or more of the plurality of action items include purchase, play now, play next, add to queue, or a combination thereof.
Some examples of action buttons in Cannistraro that fall within the scope of this claim language include: “icons 518 and 520 that allow users of the paired portable devices to vote a song up 520 or down 518,” Cannistraro ¶ 44, or “button 514” for requesting to add another song to the queue. Cannistraro ¶ 51.
Claims 33, 34, 36, 37, 39, and 40
Claims 33, 34, 36, 37, 39, and 40 recite exactly the same method that the computer readable medium of corresponding claims 25, 26, 28, 29, 31, and 32 cause a computer to perform as part of its normal operation. Therefore, claims 33, 34, 36, 37, 39, and 40 are hereby rejected over the same findings and rationale as provided above for the corresponding claims.
Claims 41, 42, and 44
Claims 41, 42, and 44 recite a computer system with general purpose computer hardware—including exactly the same (or broader) computer readable media that stores the same (or broader) instructions as the computer readable medium recited in corresponding claims 25, 26, and 28.
Asaka and Cannistraro teach the foregoing computer readable medium for all of the reasons given in the rejections of claims 25, 26, and 28, which are hereby reincorparted by reference. Additionally, to the extent claims 41, 42, and 44 further require the actual computer system and processor in which the media of claims 25, 26, and 28 is said to operate, Asaka likewise teaches a computer with a processor that executes the same instructions. See Asaka ¶¶ 173–180.
II. Cannistraro, Asaka, and Sukanen teach claims 27, 35, and 43.
Claims 27, 35, and 43 are rejected under pre-AIA 35 U.S.C. § 103(a) as being unpatentable over Cannistraro and Asaka as applied to claims 26 and 42 above, respectively, and further in view of U.S. Patent Application Publication No. 2010/0235328 A1 (“Sukanen”).
Claim 27
Cannistraro and Asaka teach the non-transitory computer readable medium of claim 26, but neither reference explicitly discloses “a minimum play time parameter of the recently played media item.”
Sukanen, however, teaches setting a first criterion for determining whether an item has been recently played,
wherein the first criterion comprises a minimum play time parameter of the recently played media item.
“According to one embodiment, a computer-readable storage medium carries instructions which, when executed by a processor, cause the one or more processors to at least perform the step of determining whether elapsed play time for particular content is greater than a threshold duration. The one or more processors are caused to perform steps further comprising, based on the determination that elapsed play time is greater than the threshold duration, initiating storage of data that indicates the particular content is to be indicated in a list of played content.” Sukanen ¶ 3.
It would have been obvious to a person of ordinary skill in the art at the time of the claimed invention to improve Asaka and Cannistraro with Sukanen’s technique of requiring a threshold duration of playtime before marking a song as played. One would have been motivated to improve Asaka and Cannistraro with Sukanen’s technique because “[a] threshold duration [] indicates a user's desire or interest in the played content.” Sukanen ¶ 65.
Claim 35
Claim 35 describes the same method that the computer readable medium of claim 27 causes a computer to perform during its normal operation, and is therefore rejected over the same findings and rationale as provided above for the rejection of claim 27.
Claim 43
Claim 43 describes a general purpose computer system that performs the same method as described in claim 35 during its normal operation, and is therefore rejected over the same findings and rationale as provided above for the rejection of claim 35, taken in conjunction with either or both of the prior art references’ disclosures regarding implementing their respective methods on general purpose computer hardware.
III. Cannistraro, Asaka, and McCormack teach claims 30 and 38.
Claims 30 and 38 are rejected under pre-AIA 35 U.S.C. § 103(a) as being unpatentable over Cannistraro and Asaka as applied to claim 25 above, and further in view of U.S. Patent Application Publication No. 2006/0156247 A1 (“McCormack”).
Claim 30
Cannistraro and Asaka teach the non-transitory computer readable medium of claim 25,
wherein the toggle button is displayed within a header portion of the GUI,
The mode button 342 is displayed within an “operation setting display section 422.” Asaka ¶ 353.
Asaka does not explicitly disclose hiding the mode button 342 until a pointing device comes within its range. McCormack, however, teaches a computer program configured to display menu buttons,
wherein the toggle button remains hidden from view until a user pointing device is within the header portion of the GUI.
As shown in FIGS. 2A and 2B, “floating action buttons 212 are presented onscreen so long as pointer icon 208 remains within hover over zone 210. When pointer icon 208 is moved outside of hover over zone 210, floating action buttons 212 are removed from the screen.” McCormack ¶ 39.
It would have been obvious to a person of ordinary skill in the art at the time of the claimed invention to improve Cannistraro and Asaka’s user interface by applying McCormack’s floating action button technique to the operation setting display section 422. One would have been motivated to improve Asaka’s user interface with the technique because “the amount of screen space available to a GUI is limited by physical monitor size and/or screen resolution.” McCormack ¶ 16.
Claim 38
Claim 38 describes the same method that the computer readable medium of claim 30 causes a computer to perform during its normal operation, and is therefore rejected over the same findings and rationale as provided above for the rejection of claim 30.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin R. Blaufeld whose telephone number is (571)272-4372. The examiner can normally be reached M-F 9:00am - 4:00pm 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, James K Trujillo can be reached at (571) 272-3677. 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.
Justin R. Blaufeld
Primary Examiner
Art Unit 2151
/Justin R. Blaufeld/Primary Examiner, Art Unit 2151
1 In this Office Action, the rejection is now updated to include a full discussion of this third example.
2 See Request for Continued Examination 9 (October 29, 2025) (arguing Cannistraro’s first two examples only describe the status of a user, without describing the status of a media item).