Ex Parte Sweatt et alDownload PDFPatent Trial and Appeal BoardMay 23, 201613195699 (P.T.A.B. May. 23, 2016) Copy Citation UNITED STA TES p A TENT AND TRADEMARK OFFICE APPLICATION NO. FILING DATE FIRST NAMED INVENTOR 13/195,699 08/01/2011 Millard E. Sweatt III 20306 7590 05/23/2016 MCDONNELL BOEHNEN HULBERT & BERGHOFF LLP 300 S. WACKER DRIVE 32NDFLOOR CHICAGO, IL 60606 UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www .uspto.gov ATTORNEY DOCKET NO. CONFIRMATION NO. 03-504-G-CON 2406 EXAMINER IDOWU, OLUGBENGA 0 ART UNIT PAPER NUMBER 2425 MAILDATE DELIVERY MODE 05/23/2016 PAPER Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte MILLARD E. SWEATT III, DON WOODWARD, CHRIS E. MATICHUK, ALAIN REGNIER, MARK NUDELMAN, PHILIPPE PIGNON, F. ANDREW VOLTMER, DAVE WESTERHOFF, MATTHEW SELF, and SUNIL MOHAN Appeal2014-008440 Application 13/195,699 Technology Center 2400 Before BRUCE R. WINSOR, DANIEL N. FISHMAN, and MICHAEL M. BARRY, Administrative Patent Judges. WINSOR, Administrative Patent Judge. DECISION ON APPEAL Appellants 1 appeal under 35 U.S.C. § 134(a) from the Final Rejection of claims 34--53, which constitute all the claims pending in this application. We have jurisdiction under 35 U.S.C. § 6(b). Claims 1-33 are cancelled. (Br. 1.) We affirm-in-part. 1 The real party in interest identified by Appellants is The DirecTV Group, Inc. (Br. 1.) Appeal2014-008440 Application 13/195,699 STATEMENT OF THE CASE Appellants' disclosed invention "relates generally to enabling web users easy access and control of media-based devices and appliances over computer networks, and more specifically, to ... remote control of a digital video recorder from a client user interface both in communication with the Internet." (Spec. i-f 7.) Claims 34 and 42, which are illustrative, read as follows: 34. A system comprising: at least one database; and a middle-tier server communicatively coupled to a first web server, a second web server, a media-based device, and the at least one database, wherein the middle-tier server 1s configured to perform each of the following functions: receiving general information from an online service; receiving specific information that is related to the media- based device; storing in the at least one database; the received general information and the received specific information; and in response to one or more Application Program Interface (API) function calls received from the first web server, (i) retrieving from the at least one database the stored general information and the stored specific information, (ii) assembling the retrieved data into a flexible data format particular to the first web server, and (iii) transmitting the assembled data to the first web server so that the first web server can assemble a presentation configured for a proprietary graphical user interface (GUI) distinctive to the first web server. 42. The web server of claim 41, wherein the functions further comprise caching the retrieved information at the web server with a frequency based upon when the user is interested in the information. 2 Appeal2014-008440 Application 13/195,699 Claims 34--41 and 43-53 stand rejected under 35 U.S.C. § 102(e) as being anticipated by Susskind (US 2001/0046366 Al; Nov. 29, 2001). (See Final Act. 3-7.) Claim 42 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over Susskind and Berstis (US 6,182,122 Bl; Jan. 30, 2001). (See Final Act. 7.) Rather than repeat the arguments here, we refer to the Appeal Brief ("Br." filed Apr. 24, 2014) and the Specification ("Spec." filed Aug. 1, 2011) for the positions of Appellants and the Final Office Action ("Final Act." mailed July 30, 2013) and Answer ("Ans." mailed July 16, 2014) for the reasoning, findings, and conclusions of the Examiner. Only those arguments actually made by Appellants have been considered in this decision. Arguments that Appellants did not make in the Briefs have not been considered and are deemed to be waived. See 37 C.F.R. § 41.37(c)(l)(iv) (2013). ISSUES The issues presented by Appellants' contentions are as follows: Whether the Examiner errs in finding that Susskind discloses "a middle-tier server communicatively coupled to a first web server, a second web server, a media-based device, and ... at least one database" (emphasis added) (the "second web server limitation"), as recited in claim 34. Whether the Examiner errs in finding that Susskind discloses (ii) assembling the retrieved data into a flexible data format particular to the first web server, and (iii) transmitting the assembled data to the first web server so that the first web 3 Appeal2014-008440 Application 13/195,699 server can assemble a presentation configured for a proprietary graphical user interface (GUI) distinctive to the first web server (the "assembling and transmitting limitation"), as recited in claim 34. Whether the Examiner errs in finding the combination of Susskind and Berstis teaches or suggests "caching the retrieved information at the web server with a frequency based upon when the user is interested in the information," as recited in claim 42. ANALYSIS CLAIM34 The Second Web Server Limitation Appellants contend "Susskind does not disclose, either expressly or inherently, 'a middle-tier server communicatively coupled to a first web server, a second web server, [and] a media-based device.' (Emphasis added.)" (Br. 5 (brackets in original).) We are not persuaded of error. The Examiner maps the recited "middle-tier server'' to Susskind's Internet Remote Control Host Sever 24 (Susskind Fig. 2), the recited "first web server" to Susskind's Internet Web Site Host 23 (id.), and the recited "second web server" to Susskind's Television Listings Server 25 (id.). (See Ans. 7 (citing Susskind i-f 35).) Appellants contend "Susskind reveals that this Internet Remote Control Host Server 24 is, at most, communicatively coupled to one Web Site Host Server (identified as reference numeral 23 in Susskind). In fact, there is no arrangement disclosed in Susskind, either expressly or inherently, that includes two Web Site Host Servers." (Br 10.) Implicit in Appellants' argument is the assumption that the recited "first web server" and "second web server" must have similar functions in the claimed invention. However, we find no such limitation recited in claim 34. Indeed, 4 Appeal2014-008440 Application 13/195,699 claim 34 recites no functional limitation whatsoever for the "second web server." Accordingly, Appellants' contention is unpersuasive because it relies on limitations not found in the language of the claim. We give claims their broadest reasonable interpretation consistent with the Specification. In re Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1369 (Fed. Cir. 2004). Although claims are interpreted in light of the Specification, "limitations are not to be read into the claims from the [S]pecification." In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993). Accordingly, arguments must be commensurate in scope with the actual claim language. In re Self, 671 F.2d 1344, 1348 (CCPA 1982). Appellants further contend as follows: Television Listings Server 25 is not a "web server" as one skilled in the art would have understood this term to mean given the context of the invention of claim 34; but rather Television Listings Server 25 is merely a "3rd-party commercial server that is not a component of the invention," which simply originates the "Vie\~1 Program Listings." (Br. 10 (citing Susskind i-f 3 5).) We agree with the following explanation provided by the Examiner: One of ordinary skill in the art will understand that a web server is storage accessible over a network such as the internet - which Television listing server 25 is. The fact that server 25 is not part of [Susskind's] current invention is non-substantial. The fact is, it was known, prior to the applicant's invention to have an Internet remote control host server (middle tier) coupled to an internet web site host (first web server) and a television listing server (second web server). (Ans. 8.) We note, for emphasis only, that nothing in claim 34 precludes the recited "online service" from being located at the "second web server." 5 Appeal2014-008440 Application 13/195,699 Appellants do not persuade us the Examiner errs in finding Susskind discloses the second web server limitation recited in claim 34. The Assembling and Transmitting Limitation Appellants contend as follows: [Susskind's] Cron Server[2] transmits any data it receives from the Video Recording Device to the database-not to the Web Server. And on the other end, the Web server retrieves from the database data it uses to present to the user. It is clear that, in Susskind, communication takes place between the Cron Server and the database and, separately, between the database and the Web Server. (Br. 7 (referring to Susskind i-fi-150-51, Fig. 4).) We are not persuaded of error. Susskind discloses that the database is located at the Internet Remote Control Server (Susskind i-fi-f 16, 41 ), which the Examiner maps to the recited "middle-tier server." Therefore, any communication with Susskind's database is communication with Susskind's Internet Remote Control Server, i.e., the recited "middle-tier server." Appellants further contend as follows: However, Susskind discloses that merely "the values for the functions are supplied by the Internet Remote Control Host Server 24," not the functions themselves, or any assembled versions of the functions. See [Susskind i-f 35]. Susskind further provides an example of these mere "values," which take the form of a simple text string: "'Cheers, Saturday 10:00 PM, Channel 12. "' Id. Notably, mere values for functions do not amount [to] 2 We note that the term "cron" refers to "[a] UNIX scheduler." Harry Newton et al., Newton's Telecommunications Dictionary 348 (27th ed), © 2013 Harry Newton, Flatiron Publishing, New York, NY; accord Newbie: Intro to cron, http://www.unixgeeks.org/ security/newbie/unix/ cron-1.html (Dec. 30, 1999) cogNitioN © 2000. Accordingly, a "cron server" is a UNIX server that provides scheduling functions. 6 Appeal2014-008440 Application 13/195,699 data that is assembled into a flexible format particular to the first web server, as claim 34 recites. (Br. 9.) We are not persuaded of error because Appellants argue limitations not found in the claim. See Van Geuns, 988 F.2d at 1184. Claim 34 does not recite that the data assembled by the middle-tier server comprise the functions themselves. Susskind's values are encompassed by the broadest reasonable interpretation of"data." See Am. Acad. of Sci. Tech. Ctr., 367 F.3d at 1369. Appellants give no other explanation as to why Susskind's values are not "assembl[ ed] ... retrieved data in[] a flexible data format particular to the first web server." We agree with the Examiner's following explanation: As it can be seen, the Internet website host 23 provides the user with information about available listings (general information), scheduled recording (specific information) and much more. This information is presented in HTML[3] format, by the Internet website host. The information is presented in a manner that simulates the video recording device - this interface is created by and therefore distinctive to the Internet host 23. With regards to the assembling the retrieved data into a flexible data format particular to the first web server and transmitting the assembled data, [Susskind i-f 35], further talks about the value of the functions used for creating the HTML pages in the Internet website host 23 coming from the Internet remote control server 24. Since the only transmission the Internet remote control server makes is to the Internet website host, the data format content is transmitted is specific to the Internet website host. Also, since the Internet website host can convert the data received from the Internet remote control host 3 Hypertext Markup Language. (Susskind i-f 30.) 7 Appeal2014-008440 Application 13/195,699 server to simulate required components, the data format 1s flexible. (Ans. 7-8.) We additionally note, for emphasis only, that providing values in a form that is suitable for use in a web page written in the widely-used HTML format (see Susskind i-f 30; accord Berstis col. 1, 11. 15-54) is, in itself, providing the values in a flexible format. Appellants further contend "Susskind merely states that 'the values for the functions are supplied by the Internet Remote Control Host Server 24,' not that the Internet Remote Control Host Server 24 affirmatively transmits the values to the Web Site Host 23." (Br. 9 (citing Susskind i-f 35).) We are not persuaded of error. For a reference to anticipate the claim, the reference must disclose the "elements ... arranged as in the claim under review, but this is not an 'ipsissimis verbis' test." In re Bond, 910 F .2d 831, 832 (Fed. Cir. 1990) (citations omitted). In view of our finding, supra, that Susskind;s Internet Remote Control Host Server includes Susskind's database (see Susskind i-fi-116, 41), the distinction drawn by Appellants is merely semantic. Susskind's Internet Remote Control Host Server supplying values for the functions of the HTML page of the Web Site Host is encompassed within the broadest reasonable interpretation of "transmitting the assembled data to the first web server," as recited in claim 34. Appellants do not persuade us the Examiner errs in finding Susskind discloses the assembling and transmitting limitation recited in claim 34. Summary Appellants do not persuade us the Examiner errs in rejecting independent claim 34. Appellants nominally argue independent claims 41 8 Appeal2014-008440 Application 13/195,699 and 49 separately (Br. 11-12); however, Appellants' arguments for claims 41 and 49 rely on the arguments made for claim 34 (id.). Claims 35--40, 43- 48, and 50-53 depend, directly or indirectly, from claims 34, 41 and 49, respectively, and are not separately argued with particularity. (Br. 13.) Accordingly, for the reasons set forth supra, we sustain the rejection of claims 3 4--41 and 4 3-5 3. CLAIM42 The Examiner relies on Berstis to teach the limitations added to claim 41 by claim 42. (Final Act. 7 (citing Berstis col. 8, 11. 26-51); see also Ans. 9 (additionally citing Berstis col. 6, 1. 60-col. 7, 1. 27).) Appellants contend as follows: At best, the cited portion of Berstis merely discloses a process for "transmitting precached downloads to a user." Berstis at col. 8, line 24. Berstis explains that a server receiving a download request may check to see if the download is precached. Id. at col. 8, lines 26-51. If so, the server may intercept the do\~1nload request; but if not, then the seP1er may fof'l{ard the request to an appropriate location. Id. However, there is no disclosure here or elsewhere in Berstis of caching information "with a frequency based upon when the user is interested in the information," as claim 42 recites. (Br. 14.) We agree with Appellants. Berstis teaches adding Web data to a registration list of Web data to be downloaded, and which may or may not be precached, based, inter alia, on the frequency of user access to the Web data. (See, e.g. Berstis col. 7, 11. 14--16, 48-53.) Thus, Berstis does teach or suggest basing whether or not Web data is precached on when the user accesses, i.e., "is interested in," the Web data. However, we find nothing in the cited passages that teaches or suggests that the frequency with which 9 Appeal2014-008440 Application 13/195,699 Berstis precaches the Web data is based on when the user accesses the Web data. Appellants persuade us the Examiner errs in rejecting claim 42. Accordingly, we do not sustain the rejection of claim 42. DECISION The decision of the Examiner to reject claims 34--41 and 43-53 is affirmed. The decision of the Examiner to reject claim 42 is reversed. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a)(l). See 37 C.F.R. § 1.136(a)(l )(iv). AFFIRMED-IN-PART 10 Newbie: Intro to cron Page 1of6 Newbie: Intro to cron Date: 30-Dec-99 Author: cog?~iTio?~ Cron This file is an introduction to cron, it covers the basics of what cron does, and how to use it. What is cron? Cron is the name of program that enables unix users to execute commands or scripts (groups of commands) automatically at a specified time/date. It is normally used for sys admin commands, like makewhatis, which builds a search database for the man -k command, or for running a backup script, but can be used for anything. A common use for it today is connecting to the internet and downloading your email. This file will look at Vixie Cron, a version of cron authored by Paul Vixie. How to start Cron Cron is a daemon, which means that it only needs to be started once, and will lay dormant until it is required. A Web server is a daemon, it stays dormant until it gets asked for a web page. The cron daemon, or crond, stays dormant until a time specified in one of the config files, or crontabs. On most Linux distributions crond is automatically installed and entered into the start up scripts. To find out if it's running do the following: cog@pingu root cog $ ps aux I grep crond 311 0.0 0.7 1284 8606 4.0 2.6 1148 112 ? 388 tty2 s s Dec24 12:47 0:00 crond 0:00 grep crond The top line shows that crond is running, the bottom line is the search we just run. If it's not running then either you killed it since the last time you rebooted, or it wasn't started. To start it, just add the line crond to one of your start up scripts. The process automatically goes into the back ground, so you don't have to force it with &. Cron will be started next time you reboot. To run it without rebooting, just type crond as root: root@pingu # crond With lots of daemons, (e.g. httpd and syslogd) they need to be restarted after the config files have been changed so that the program has a chance to reload them. Vixie Cron will automatically reload the files after they have been edited with the crontab command. Some cron versions reload the files every minute, and some require restarting, but Vixie Cron just loads the files if they have changed. Using cron There are a few different ways to use cron (surprise, surprise) . In the /etc directory you will probably find some sub directories called http://www.unixgeeks.org/security/newbie/unix/cron-1.html 5/13/2016 Newbie: Intro to cron Page 2of6 'cron.hourly', 'cron.daily', 'cron.weekly' and 'cron.monthly'. If you place a script into one of those directories it will be run either hourly, daily, weekly or monthly, depending on the name of the directory. If you want more flexibility than this, you can edit a crontab (the name for cron's config files). The main config file is normally /etc/crontab. On a default RedHat install, the crontab will look something like this: root@pingu # cat /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly The first part is almost self explanatory; it sets the variables for cron. SHELL is the 'shell' cron runs under. If unspecified, it will default to the entry in the /etc/passwd file. PATH contains the directories which will be in the search path for cron e.g if you've got a program 'foo' in the directory /usr/cog/bin, it might be worth adding /usr/cog/bin to the path, as it will stop you having to use the full path to 'foo' every time you want to call it. MAILTO is who gets mailed the output of each command. If a command cron is running has output (e.g. status reports, or errors), cron will email the output to whoever is specified in this variable. If no one if specified, then the output will be mailed to the owner of the process that produced the output. HOME is the home directory that is used for cron. If unspecified, it will default to the entry in the /etc/passwd file. Now for the more complicated second part of a crontab file. An entry in cron is made up of a series of fields, much like the /etc/passwd file is, but in the crontab they are separated by a space. There are normally seven fields in one entry. The fields are: minute hour dom month dow user cmd minute hour dom month dow user cmd This controls what minute of the hour the command will run on, and is between '0' and '59' This controls what hour the command will run on, and is specified in the 24 hour clock, values must be between 0 and 23 (0 is midnight) This is the Day of Month, that you want the command run on, e.g. to run a command on the 19th of each month, the dom would be 19. This is the month a specified command will run on, it may be specified numerically (0-12), or as the name of the month (e.g. May) This is the Day of Week that you want a command to be run on, it can also be numeric (0-7) or as the name of the day (e.g. sun). This is the user who runs the command. This is the command that you want run. This field may contain multiple words or spaces. If you don't wish to specify a value for a field, just place a * in the http://www.unixgeeks.org/security/newbie/unix/cron-1.html 5/13/2016 Newbie: Intro to cron Page 3of6 field. e.g. 01 * * * * root echo "This command is run at one min past every hour" 17 8 * * * root echo "This command is run daily at 8:17 am" 17 20 * * * root echo "This command is run daily at 8:17 pm" 00 4 * * 0 root echo "This command is run at 4 am every Sunday" * 4 * * Sun root echo "So is this" 42 4 1 * * root echo "This command is run 4:42 am every 1st of the month" 01 * 19 07 * root echo "This command is run hourly on the 19th of July" Notes: Under dow 0 and 7 are both Sunday. If both the dom and dow are specified, the command will be executed when either of the events happen. e.g. * 12 16 * Mon root cmd Will run cmd at midday every Monday and every 16th, and will produce the same result as both of these entries put together would: * 12 16 * * root cmd * 12 * * Mon root cmd Vixie Cron also accepts lists in the fields. Lists can be in the form, 1,2,3 (meaning 1 and 2 and 3) or 1-3 (also meaning 1 and 2 and 3) . e.g. 59 11 * * 1,2,3,4,5 root backup.sh Will run backup.sh at 11:59 Monday, Tuesday, Wednesday, Thursday and Friday, as will: 59 11 * * 1-5 root backup.sh Cron also supports 'step' values. A value of */2 in the dom field would mean the command runs every two days and likewise, */5 in the hours field would mean the command runs every 5 hours. e.g. * 12 10-16/2 * * root backup.sh is the same as: * 12 10,12,14,16 * * root backup.sh */15 9-17 * * * root connection.test Will run connection.test every 15 mins between the hours or 9am and 5pm Lists can also be combined with each other, or with steps: * 12 1-15,17,20-25 **root cmd Will run cmd every midday between the 1st and the 15th as well as the 20th and 25th (inclusive) and also on the 17th of every month. * 12 10-16/2 * * root backup.sh is the same as: * 12 10,12,14,16 * * root backup.sh When using the names of weekdays or months, it isn't case sensitive, but only the first three letters should be used, e.g. Mon, sun or Mar, jul. Comments are allowed in crontabs, but they must be preceded with a '#', and must be on a line by them self. Multiuser cron http://www.unixgeeks.org/security/newbie/unix/cron-1.html 5/13/2016 Newbie: Intro to cron Page 4of6 As Unix is a multiuser OS, some of the apps have to be able to support multiple users, cron is one of these. Each user can have their own crontab file, which can be created/edited/removed by the command crontab. This command creates an individual crontab file and although this is a text file, as the /etc/crontab is, it shouldn't be edited directly. The crontab file is often stored in /var/spool/cron/crontabs/ (Unix/Slackware/*BSD), /var/spool/cron/ (RedHat) or /var/cron/tabs/ (SuSE), but might be kept elsewhere depending on what Un*x flavor you're running. To edit (or create) your crontab file, use the command crontab -e, and this will load up the editor specified in the environment variables EDITOR or VISUAL, to change the editor invoked on Bourne-compliant shells, try: cog@pingu $ export EDITOR=vi On C shells: cog@pingu $ setenv EDITOR vi You can of course substitute vi for the text editor of your choice. Your own personal crontab follows exactly the same format as the main /etc/crontab file does, except that you need not specify the MAILTO variable, as this entry defaults to the process owner, so you would be mailed the output anyway, but if you so wish, this variable can be specified. You also need not have the user field in the crontab entries. e.g. min hr dom month dow cmd Once you have written your crontab file, and exited the editor, then it will check the syntax of the file, and give you a chance to fix any errors. If you want to write your crontab without using the crontab command, you can write it in a normal text file, using your editor of choice, and then use the crontab command to replace your current crontab with the file you just wrote. e.g. if you wrote a crontab called cogs.cron.file, you would use the cmd cog@pingu $ crontab cogs.cron.file to replace your existing crontab with the one in cogs.cron.file. You can use cog@pingu $ crontab -1 to list your current crontab, and cog@pingu $ crontab -r will remove (i.e. delete) your current crontab. Privileged users can also change other user's crontab with: root@pingu # crontab -u and then following it with either the name of a file to replace the existing user's crontab, or one of the -e, -1 or -r options. According to the documentation the crontab command can be confused by the su command, so if you running a su'ed shell, then it is recommended you use the -u option anyway. Controlling Access to cron http://www.unixgeeks.org/security/newbie/unix/cron-1.html 5/13/2016 Newbie: Intro to cron Page 5of6 Cron has a built in feature of allowing you to specify who may, and who may not use it. It does this by the use of /etc/cron.allow and /etc/cron.deny files. These files work the same way as the allow/deny files for other daemons do. To stop a user using cron, just put their name in cron.deny, to allow a user put their name in the cron.allow. If you wanted to prevent all users from using cron, you could add the line ALL to the cron.deny file: root@pingu # echo ALL >>/etc/cron.deny If you want user cog to be able to use cron, you would add the line cog to the cron.allow file: root@pingu # echo cog >>/etc/cron.allow If there is neither a cron.allow nor a cron.deny file, then the use of cron is unrestricted (i.e. every user can use it). If you were to put the name of some users into the cron.allow file, without creating a cron.deny file, it would have the same effect as creating a cron.deny file with ALL in it. This means that any subsequent users that require cron access should be put in to the cron.allow file. Output from cron As I've said before, the output from cron gets mailed to the owner of the process, or the person specified in the MAILTO variable, but what if you don't want that? If you want to mail the output to someone else, you can just pipe the output to the command mail. e.g. cmd I mail -s "Subject of mail" user If you wish to mail the output to someone not located on the machine, in the above example, substitute user for the email address of the person who wishes to receive the output. If you have a command that is run often, and you don't want to be emailed the output every time, you can redirect the output to a log file (or /dev/null, if you really don't want the output). e,g cmd >> log.file Notice we're using two >signs so that the output appends the log file and doesn't clobber previous output. The above example only redirects the standard output, not the standard error, if you want all output stored in the log file, this should do the trick: cmd >> logfile 2>&1 You can then set up a cron job that mails you the contents of the file at specified time intervals, using the cmd: mail -s "logfile for cmd" Copy with citationCopy as parenthetical citation