Detailed Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement filed on April 1, 2024 complies with the provisions of 37 C.F.R. § 1.97, 1.98, and MPEP § 609, and therefore has been placed in the application file. The information referred to therein has been considered as to the merits.
Claim Objections
The Office objects to claims 3, 5–12, and 14–20 for having the following informalities. Appropriate correction is required.
Claim 3 is missing a coordinating conjunction to join the list of steps.
Claims 5–11 and 14–20 are not complete sentences. They are each missing a principal verb necessary to connect the subject of each sentence (“The computer implemented method”) to the participle phrase that follows. As an example, consider the following correction to claim 6: “The computer-implemented method of claim 1, wherein the set of criteria [[being]] is further related to a frequency of occurrence of each sequence of actions.”
Claims 12 and 20 attempt to use the word “replacing” as a noun, but that word is not a noun. The correct noun form of replacing is replacement (“causing [[replacing]] replacement of the UI element with a second UI element in the GUI….”).
Claim Rejections – 35 U.S.C. § 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.
I. Fauchère and Shrikantiah teach claims 1, 2, 4–10, 12–18, and 20.
Claim(s) 1, 2, 4–10, 12–18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2019/0187987 A1 (“Fauchère”) in view of Manjunath Shrikantiah, Dynamic Gridview Page Size Based on Screen Height (Codeproject.com, July 22, 2011) (available at https://www.codeproject.com/Articles/229798/Dynamic-gridview-page-size-based-on-screen-height).
Claim 1
Fauchère teaches:
A computer-implemented method of improving user operation with multiple computer devices, comprising:
“FIG. 3 is a flow diagram of a first example process 300 for automation of a sequence of actions.” Fauchère ¶ 48. Specifically, process 300 creates computer macros by determining a “qualified sequence” of “multiple actions” eligible for creation of the macros. Fauchère ¶ 48.
With respect to the “multiple computer devices” claim language, process 300 searches a “repository” of “similar sequences” based on the qualified sequence, as part of its algorithm for creating a new macro. Fauchère ¶ 48. As shown in FIG. 1, and to be discussed in greater detail below, the repository and/or the system 100 that performs process 300 makes these sequences of actions available to multiple users 150. See Fauchère ¶ 23.
Fauchère does not explicitly anticipate thresholding the number of sequences it selects, let alone thresholding the number of sequences based on the shape or size of the GUI. However, this was an obvious difference before the effective filing date of the claimed invention, for reasons that will be discussed below.
selecting, by a processor, one or more sequences of digital actions (actions) as one or more compound actions from a list of sequences of actions,
Upon detecting that a user performed a sequence of actions, “sequence monitor 110 will determine whether an existing macro could be found to match with the newly updated sequence at block 330.” Fauchère ¶ 51. Specifically, the search for an existing macro is conducted within the repository, which contains a large list of said macros. See Fauchère ¶ 62.
Also, please note that while this example describes obtaining only one macro from the repository, Fauchère further teaches embodiments where “macros having similar sequences of actions in the beginning, middle, or end of the macro may all be returned as candidate macros for the user to choose.” Fauchère ¶ 30. Thus, Fauchère indeed teaches selecting “one or more” sequences.
the one sequence of actions of the one or more sequences of actions being performed by multiple computer devices of a plurality of computer devices,
“System 100, as disclosed herein, monitors actions from users 150 and can automatically generate macros from multi-user sequences.” Fauchère ¶ 35. For example, in some sequences, “[o]ne user's action may be conditioned on another user's action.” Fauchère ¶ 35.
including at least one input device and at least one output device,
The computer(s) that implement system 100 (and perform process 300) include “input/output (I/O) ports 550 [and] input/output (I/O) components 560.” Fauchère ¶ 73; see also Fauchère ¶ 78.
the one or more sequences of actions
According to Fauchère’s disclosure, the macro obtained from the macro repository satisfies criteria related to a number of actions in each sequence of actions for a few different reasons.
For one, sequence monitor 110 ensures that every sequence—regardless of whether it makes it into the repository—must at least “include[] two or more actions.” Fauchère ¶ 59. So, any qualified sequence obtained from the repository is required to include at least two actions.
Second, beyond the two-action minimum, “macro generator 130 determines the qualification for a sequence to be persisted as a macro based on thresholds for various properties of the sequence, such as the frequency, the duration, and the complexity of the sequence.” Fauchère ¶ 31. “The complexity of an action refers to the computational complexity,” or “the time complexity for users,” or “other aspects in executing the action.” Fauchère ¶ 42. Computational complexity and time complexity are both fall within the scope of “criteria related to a number of actions in each sequence of actions,” because the claim language “related to” broadens the scope of the claim to more than merely the number of actions itself. That is, claim 1 does not say that the criteria are the number of actions, it only says that the criteria must somehow “relate” to the number of actions.
Both computational complexity and time complexity at least “relate” to the number of actions in a sequence, because more sequences with more actions necessarily require more computation and time to complete than sequences having fewer actions. For example, suppose one sequence consists of pressing the spacebar key twice, while a second sequence consists of pressing the spacebar key three times. The second sequence necessarily requires more computation and time to perform than the first sequence, because the first sequence never requires that third spacebar press.
Finally, in addition to all of the macros in the repository meeting multiple criteria related to the number of actions in their sequences, the one or more sequence that process 300 actually obtains from the repository must meet yet another criterion related to a number of actions in each sequence of actions. Specifically, to obtain macro(s) from the repository, “sequence monitor 110 queries macro manager 140 whether the sequence matches any existing macro.” Fauchère ¶ 29. A “matching” requirement is necessarily a criteria related to the number of actions in the macro, because macros that contain a different number of actions cannot match.
creating, by the processor, a deep link as a shortcut representing a specific compound action of the one or more compound actions, the shortcut when invoked causing performing the specific compound action and producing a specific result;
“Macro generator 130 may assign the macro into a menu that may be invoked via a user interface to prompt users to use macros. Further, macro generator 130 may assign a keyboard shortcut to the newly generated macro so the user may invoke the macro quickly.” Fauchère ¶ 33.
causing presenting the shortcut as an UI element in the GUI.
“If an existing macro with a similar sequence is identified, information of the matching macro or macros, such as the description of the macro and the keyboard shortcut of the macro, is provided to the user at block 340.” Fauchère ¶ 52.
As mentioned above, Fauchère does not explicitly disclose limiting the number of macros it obtains from the repository based on the shape or size of the user interface. However, limiting the number of results retrieved from a database based on the shape and size available in a user interface to display those results was a known improvement technique prior to the effective filing date of the claimed invention. For example, Shrikantiah teaches a method comprising:
determining a threshold based on a shape or size of a graphical user interface (GUI);
Shrikantiah teaches a technique for dynamically setting the “page size” of an ASP.NET gridview object. Shrikantiah 1. As those of ordinary skill in the art know (and as explicitly shown in Shrikantiah’s code example), the gridview class is a module of the ASP.NET framework with code responsible for displaying the values of a data source in a table, where each column represents a field and each row represents a record. For example, as shown in the example in the bottom half of Shrikantiah, whenever a user requests this example web page, the server executes the Page_Load() function, wherein the 300 rows of data are stored in DataTable dt using UIHelper.GetData(300), and then those rows are bound to the GridView1 (our instance of the code responsible for displaying the table). See Shrikantiah 5.
“Page size” in this case refers to the maximum number of items that will be presented in on the webpage at the same time. To determine this number, Shrikantiah teaches us to first, “[g]et the screen or window height,” then “[s]tore window height in a session variable,” and finally, “[u]se the window height to calculate page size.” Shrikantiah 1. Shrikantiah also suggests considering “offset required for header, bottom offset required for footer, row height, etc,” Shrikantiah 1, thus teaching both the shape and size limitations of claim 1.
selecting, by a processor, one or more [items] . . . from a list,
When the page is loaded, the ASP.NET server calls the executes the code on pages 5–6 to determine how many items from the 300 total items to display, which is the number set by the pageSize variable.
that is no more than the threshold
Per line 11 of the Code Behind Page code (page 5 of the Shrikantiah reference), the pageSize variable that limits the number of items displayed in the table is set dynamically, according to the formula (Session["WindowHeight"]) - gridTopOffset - gridBottomOffset) / 20) – 3. Recall from earlier that Session["WindowHeight"] holds the current window height. See also Shrikantiah 3 (“On document ready function, SaveWindowHeight web service method will be called to store the window”). Accordingly, Shrikantiah explicitly teaches selecting no more than a threshold number of items from a data source for display that is based on the shape and size of the GUI.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply Shrikantiah’s known technique to Fauchère’s known method 300 and/or system 100, ready for improvement, to yield the predictable result of selecting only up to a threshold number of macros that is based on user’s window height.
The rationale to support this conclusion of obviousness is that “a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art,” and that “[o]ne of ordinary skill in the art would have been capable of applying this known technique to a known device (method, or product) that was ready for improvement and the results would have been predictable to one of ordinary skill in the art.” MPEP § 2143 (subsection (I.)(D.)).
Consistent with the guidance that MPEP § 2143 (subsection (I.)(D.)) provides for reaching this conclusion, the relevant findings of fact (and the evidence that supports those findings) are as follows:
(1) The prior art contained a “base” device and method upon which the claimed invention can be seen as an “improvement.” The evidence for this finding was provided in the first half of this rejection, where each claim element taught in Fauchère’s system 100 and method 300 was mapped to its corresponding teaching in the Fauchère reference. Those findings are hereby reincorporated into this paragraph, by reference.
(2) The prior art contained a known technique that is applicable to the base device and method. The evidence for this finding was provided in the second half of this rejection, where Shrikantiah’s item paging technique was discussed relative to each corresponding claim element. Once again, those findings are hereby reincorporated into this paragraph by reference.
(3) One of ordinary skill in the art would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system. The evidence for this finding includes Shrikantiah’s explicit suggestion that the technique is an improvement over less flexible approaches. See Shrikantia 6 (“This can be used as a powerful UI feature, when user wants his page size to vary based on this screen rather than the pre-defined one.”).
In view of the foregoing findings, the Office concludes that claim 1 would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention.
Claim 2
Fauchère and Shrikantiah teach the computer-implemented method of claim 1, further comprising
receiving, from the plurality of computer devices, tracked action data including, for each action of a plurality of actions, a device identifier identifying a computer device which performed the action, a timestamp indicating when the action was performed, a user identifier identifying a user who issued a user command to perform the action, or an action identifier identifying the action performed,
As shown in FIG. 2, each of the sequences 220, and each of the actions 210 of each of the sequences, are stored in the repository together with property metadata describing each of the actions and each of the sequences. Fauchère teaches many different examples of what the metadata may include, but the following is a list of the properties that, at a minimum, teach a device identifier identifying a computer device which performed the action, a user identifier identifying a user who issued a user command to perform the action, or an action identifier identifying the action performed. (Since claim 2 enumerates the action data with the disjunctive “or,” the broadest reasonable interpretation is that only one of the recited action data items must be disclosed or taught to meet the requirements of the claim).
In Fauchère, this includes the following:
(1) “In one embodiment, action 210 is an operation for photo editing.” Fauchère ¶ 41;
(2) “Property 212 is TOOL, and value 214 is the name of the tool, for instance, rectangular marquee tool, move tool, polygon lasso tool, magic wand tool, crop tool, slice tool, brush tool, clone stamp tool, eraser tool, blur tool, dodge tool, notes tool, zoom tool, etc.” Fauchère ¶ 41;
(3) “Property 226 and value 228 may represent the frequency of the sequence being performed by the same user.” Fauchère ¶ 45.
(4) “sequence 220 may have other properties and corresponding values, such as the location of performing the sequence, [(5)] the resources required to execute the sequence, the collaborative users involved in the sequence, [(6)] the project associated with the sequence, [(7)] the user preference of the user who performed the sequence, and so forth depending on the actual implementation.” Fauchère ¶ 47.
In addition to the seven piece of data above, Fauchère further discloses storing “the identity of the user, the timestamp, the location, or the nature of the operation (e.g., which button is being clicked)” in association with each action. See Fauchère ¶ 59.
the one or more sequences of actions being extracted from the tracked action data.
“In some embodiments, the weight associated with an action may be learned by the system, e.g., via monitoring how the action is executed by users.” Fauchère ¶ 42. “[W]hen the detected operation is recognized by action manager 120 as one of the existing actions, sequence monitor 110 will add the action to a sequence.” Fauchère ¶ 43.
Claim 4
Fauchère and Shrikantiah teach the computer-implemented method of claim 2, further comprising
generating a generalized action associated with one or more users from the tracked action data, the generalized action incorporating parameters to be given values at run time, which represent a computer device, a computer application, or a parameter of the computer application.
“With the preprocessed information of the macro, such as the auto-generated title, description, and keyboard shortcut, the user will be prompted to validate the new macro at block 370. The user now has a chance to review the proposed macro. The user may adjust the properties of the macro, such as the title, description, or keyboard shortcut.” Fauchère ¶ 55. The custom keyboard shortcut at least falls within the scope of the claimed “parameter of the computer application” to be “given values at run time,” because the keyboard shortcut is an input interpreted by the application that causes the macro to run. And since Fauchère teaches at least one of the items in the claimed list of alternatives (“a computer device, a computer application, or a parameter of the computer application”), Fauchère’s teaching falls within the scope of the claimed list.
Claim 5
Fauchère and Shrikantiah teach the computer-implemented method of claim 1,
the one sequence of actions including an action corresponding to a user interaction with an input device of the at least one input device or an output device of the at least one output device.
“The term ‘action’ or ‘user action’ refers to any operation performed by a user to interact with the computing system. User actions are meant to trigger the execution of software codes via an act of the user, such as clicking on a link or button via a user interface interaction, issuing a command via a command console, etc.” Fauchère ¶ 20.
Claim 6
Fauchère and Shrikantiah teach the computer-implemented method of claim 1,
the set of criteria being further related to a frequency of occurrence of each sequence of actions.
“[M]acro generator 130 determines the qualification for a sequence to be persisted as a macro based on thresholds for various properties of the sequence, such as the frequency . . . of the sequence.” Fauchère ¶ 31.
Claim 7
Fauchère and Shrikantiah teach the computer-implemented method of claim 1,
the specific compound action leading to the specific result, including performance of an input operation by a specific input device of the at least one input device or performance of an output operation by a specific output device of the at least one output device.
“As used herein, the term ‘macro’ specifically refers to reusable sequences of actions that are recognized by the computer system. A macro includes at least one sequence of actions. In some embodiments, a macro includes two or more sequences of actions. Each sequence of action can independently perform a function, and all sequences of actions in a macro can collectively perform a more complex function.” Fauchère ¶ 22. For example, “[t]he execution of the chain of actions in sequence 220 will result in a change in the system, such as a status change of an item in the system, e.g., via a database update.” Fauchère ¶ 40.
Claim 8
Fauchère and Shrikantiah teach the computer-implemented method of claim 1,
the shortcut being invoked via a single gesture or utterance or an automatic conditional trigger.
“[M]acro generator 130 may assign a keyboard shortcut to the newly generated macro so the user may invoke the macro quickly.” Fauchère ¶ 33.
Claim 9
Fauchère and Shrikantiah teach the computer-implemented method of claim 1,
the shortcut being presented via a specific output device of the at least one output device.
“Macro generator 130 may assign the macro into a menu that may be invoked via a user interface to prompt users to use macros.” Fauchère ¶ 33.
Claim 10
Fauchère and Shrikantiah teach the computer-implemented method of claim 1,
the one or more sequences of actions maximizing a sum of, for each sequence, a product of the number of actions in the sequence raised to a power related to the number of actions in the sequence and a frequency of occurrence of the sequence.
Careful readers of claim 10 will notice that the claimed method does not recite a step for calculating “a sum of, for each sequence, a product of the number of actions in the sequence raised to a power related to the number of actions in the sequence and a frequency of occurrence of the sequence.” Since “[c]laim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed,” MPEP § 2111.04 (subsection I.), the prior art does not need to show a step of calculating the sum recited in claim 10.
Instead, claim 10 merely requires the one or more sequences to conform to formula described in the claim language—even if by happenstance. To that end, since the claim only requires a minimum of “one or more sequences of actions,” any sequence Fauchère selects necessarily meets the requirements of claim 10, at least in cases where the list from which the sequence is selected comprises only one sequence. By selecting that sequence, we’ve necessarily chosen a combination of sequences that gives the maximum number for Σ B-t (Lt)af-t, since only one combination exists.
Claim 12
Fauchère and Shrikantiah teach the computer-implemented method of claim 1, further comprising
causing replacing the UI element with a second UI element in the GUI representing a second deep link associated with a second compound action based on a frequency of invocation of the second deep link by one or more users during a recent period of time.
“In some embodiments, macro manager 140 may replace a stale macro with another newly formed macro if they perform substantially the same function.” Fauchère ¶ 36. Note that since Fauchère teaches embodiments that use frequency of invocation as the criteria for deciding when to add any macro to the menu, see Fauchère ¶ 31, it follows that the newly formed macro would be one that conforms to the frequency criteria in those embodiments.
Claims 13–18 and 20
Claims 13–18 and 20 are directed to computer-readable storage media encoded with instructions that cause a computer to implement exactly the same computer-implemented method as recited in corresponding claims 1, 2, 4–7, and 12. Therefore, the findings and rationale from the rejections of claims 1, 2, 4–7, and 12 are hereby reincorporated by reference as applied to their corresponding claims 13–18 and 20, taken in conjunction with Fauchère’s further teaching of storing those method steps as instructions on a computer readable medium. See Fauchère ¶ 74.
II. Fauchère, Shrikantiah, and Leno teach claim 3.
Claim(s) 3 is rejected under 35 U.S.C. 103 as being unpatentable over Fauchère in view of Shrikantiah as applied to claim 2 above, and further in view of Volodymyr Leno et al., Identifying Candidate Routines for Robotic Process Automation from Unsegmented UI Logs, 2020 2nd International Conference on Process Mining (October 2020), available at https://doi.org/10.1109/ICPM49681.2020.00031.
Claim 3
Fauchère and Shrikantiah teach the computer-implemented method of claim 2, further comprising:
extracting, from the tracked action data, a certain series of actions resulting from user commands issued sequentially by one user;
“Action 310 is identified, e.g., by action manager 120 as a recognizable action in the system. At block 320, sequence monitor 110 will determine whether action 310 may be added to any monitored sequences.” Fauchère ¶ 49.
using the timestamp associated with each action of the certain series of actions, grouping the certain series of actions into a plurality of sequences of actions;
“In some embodiments, multiple temporary sequences are being monitored by sequence monitor 110, for instance, for individual users, for different groups, for all users in a domain, etc. Action 310 may be added to one or many temporary sequences.” Fauchère ¶ 49. “In some embodiments, action 310 may be added to a temporary sequence based on the timing, location, or another characteristic of action 310. For example, action 310 can be added to the temporary sequence whose most recent action is close to the timing, location, or the other characteristic of action 310.” Fauchère ¶ 50. Other parts of Fauchère’s disclosure also explicitly use the word “timestamp” to describe the analysis of the timing of actions, see Fauchère ¶¶ 59 and 61, although those reviewing this rejection are reminded that Fauchère does not need to use the exact same terminology as the claimed invention in order to reach a finding of anticipation or conclusion of obviousness. See MPEP § 2131 (citing In re Bond, 910 F.2d 831, 15 USPQ2d 1566 (Fed. Cir. 1990)).
calculating a frequency of occurrence for each sequence of actions of the plurality of sequences of actions as a
“The system keeps track of sequences of actions associated with attributes such as frequency.” Fauchère ¶ 16.
Neither Fauchère nor Shrikantiah appear to explicitly disclose normalizing the frequency of each sequence with respect to the other sequences that occur in a common duration.
Much like Fauchère and the claimed invention, Leno also teaches a process for “automating repetitive sequences of interactions between a user and one or more software applications,” by mining the users’ activity logs “to identify routines that are prone to automation.” Leno 153. However, unlike Fauchère, Leno’s process further includes the technique of:
extracting, from the tracked action data, a certain series of actions resulting from user commands issued sequentially by one user;
Given a log of user activity data, Leno proposes extracting a set of non-overlapping subsequences of user actions, “such that each subsequence represents the execution of a task performed by an employee from start to end” (also known as routines). Leno 154.
calculating a frequency of occurrence for each sequence of actions of the plurality of sequences of actions as a normalized frequency with respect to other sequences of actions that occur in a common duration.
In order to find potential candidate routines to recommend for robotic process automation (i.e., a macro), Leno uses an algorithm that discovers all of the “frequent closed sequential patterns” in the set of UI log segments. Leno 157. Importantly, a “closed” pattern is “a pattern that is not included in another pattern having exactly the same support,” and Leno defines the “support” of a sequential pattern as “the ratio of its occurrences and the total number of segments.” Leno 157. Accordingly, as part of its search for ideal candidate routines, Leno calculates the “support” for each routine, the “support” being the ratio of its occurrences and the total number of segments.
In simpler terms, Leno normalizes the frequencies of action sequences seen in the user activity data so that they are all expressed as a relative percentage of the dataset as a whole.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve Fauchère’s search for potential macros with Leno’s technique of calculating the “support” of each sequence as part of the algorithm for finding the best ones to recommend. One would have been motivated to apply this algorithm, which includes calculating the “support” for each sequence found in the data, because by knowing the “support” of each subsequence, one can limit the search for candidate sequences to only those sequences that are “closed,” thus avoiding the generation of unnecessary subsequences, obtaining more compact results, and saving computational time and space costs.
III. Fauchère, Shrikantiah, and Godin teach claims 11 and 19.
Claim(s) 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Fauchère and Shrikantiah as applied to claims 1 and 13 above, and further in view of U.S. Patent Application Publication No. 2020//0273255 A1 (“Godin”).
Claim 11
Fauchère and Shrikantiah teach the computer-implemented method of claim 1,
the UI element indicating
“Macro generator 130 may assign the macro into a menu that may be invoked via a user interface to prompt users to use macros.” Fauchère ¶ 33.
Neither Fauchère nor Shrikantiah teach a UI element that indicates both of the claimed input modes together. Godin, however, teaches a UI element with exactly that:
the UI element indicating multiple input modes, including a first mode to accept a physical interaction with the UI element as a selection of the UI element and a second mode to accept a specific utterance as a voice command associated with the specific compound action as the selection of the UI element.
“In some examples, a user may say ‘Next step’ to go to the next step, as an alternative to selecting the ‘next step’ button. In some examples, selectable buttons may also include an indication of the voice command that may be used to select the button. For instance, in some examples, the ‘Next Step’ button includes text at the bottom of the Next Step button that says, ‘Say Next Step.’” Godin ¶ 72.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve Fauchère’s menu element in the same way that Godin improved its own UI element (a button), i.e., by providing means for both physically interacting with the button and voice activation for the same, and further providing on-screen instructions that remind the user of the voice modality for activating the button. One would have been motivated to improve Fauchère’s menu element in the same way that Godin improved its own button because a user’s ability to interact with the user interface may differ in different circumstances: “For example, in some circumstances, a user’s hands may not be free to perform gestures, and in some circumstances, the environment be too noisy for voice commands.” Godin ¶ 72.
Claim 19
Claim 19 is directed to same computer readable medium as recited in claim 13, whose instructions further perform the method in the manner recited in claim 11. Therefore, claim 19 is rejected over the combined findings and rationale set forth in the rejections of claims 11 and 13, above.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 C.F.R. § 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 C.F.R. § 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 C.F.R. § 1.111(a). For a reply to final Office action, see 37 C.F.R. § 1.113(c). A request for reconsideration while not provided for in 37 C.F.R. § 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1–20 (hereafter the “Pending” claims) are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4–7, 9, 11, 14, 16, 17, and 19 of U.S. Patent No. 11,868,789 B2 (hereafter the “Patented” claims) in view of Shrikantiah.
Each Pending Claim is mapped to a corresponding Patented Claim as follows:
Pending
1
2
3
4
5
6
7
8
9
10
11
12
Patented
1
4
5
6
1
7
1
1
1
7
9
11
Pending
13
14
15
16
17
18
19
20
Patented
14
16
6
14
7
14
17
19
Additionally, as part of this rejection, the Examiner hereby incorporates by reference the text of each Pending claim, presented side-by-side with the text of its corresponding Patented claim (as set forth in the table above), also incorporated by reference. Please keep in mind that every dependent claim of either set is to be read as including all of the elements of its parent claim. See 35 U.S.C. § 112(d).
Looking at the claims together, there are only three categories of differences between what was previously patented, and what is now claimed, and all three categories were obvious before the effective filing date of the present application for the following reasons.
The first category of differences concerns every element or limitation recited in the Patented version of the claims that is missing from its corresponding Pending claim. None of the differences in this category are patentably distinct from one another, because the Pending claims each use the “comprising” transitional phrase, meaning any extra element or limitation recited in its corresponding Patented claim simply falls within its open-ended scope. See MPEP § 2111.03.
The second category of differences concerns Pending Claims 15 and 17, which this rejection maps to Patented Claims 6 and 7. Pending Claims 15 and 17 are directed to computer-readable media that store instructions, whereas Patented Claims 6 and 7 describe the same (or narrower) computer-implemented method that the computer-readable medium of Pending Claims 15 and 17 cause a computer to perform as part of its normal operation. Since a computer readable medium necessary for implementing any method on a computer, it would have been obvious to one of ordinary skill in the art as of the filing date of this invention to store the instructions for Patented Claims 6 and 7 on a computer readable medium, as recited in Pending Claims 15 and 17.
The final category of differences is that Patented claims 1 and 14 do not recite the additional steps of determining a threshold based on a shape or size of a graphical user interface (GUI), and subsequently limiting the number of sequences obtained based on the shape or size of the user interface. However, limiting the number of results retrieved from a database based on the shape and size available in a user interface to display those results was a known improvement technique prior to the effective filing date of the claimed invention. For example, Shrikantiah teaches a method comprising:
determining a threshold based on a shape or size of a graphical user interface (GUI);
Shrikantiah teaches a technique for dynamically setting the “page size” of an ASP.NET gridview object. Shrikantiah 1. As those of ordinary skill in the art know (and as explicitly shown in Shrikantiah’s code example), the gridview class is a module of the ASP.NET framework with code responsible for displaying the values of a data source in a table, where each column represents a field and each row represents a record. For example, as shown in the example in the bottom half of Shrikantiah, whenever a user requests this example web page, the server executes the Page_Load() function, wherein the 300 rows of data are stored in DataTable dt using UIHelper.GetData(300), and then those rows are bound to the GridView1 (our instance of the code responsible for displaying the table). See Shrikantiah 5.
“Page size” in this case refers to the maximum number of items that will be presented in on the webpage at the same time. To determine this number, Shrikantiah teaches us to first, “[g]et the screen or window height,” then “[s]tore window height in a session variable,” and finally, “[u]se the window height to calculate page size.” Shrikantiah 1. Shrikantiah also suggests considering “offset required for header, bottom offset required for footer, row height, etc,” Shrikantiah 1, thus teaching both the shape and size limitations of claim 1.
selecting, by a processor, one or more [items] . . . from a list,
When the page is loaded, the ASP.NET server calls the executes the code on pages 5–6 to determine how many items from the 300 total items to display, which is the number set by the pageSize variable.
that is no more than the threshold
Per line 11 of the Code Behind Page code (page 5 of the Shrikantiah reference), the pageSize variable that limits the number of items displayed in the table is set dynamically, according to the formula (Session["WindowHeight"]) - gridTopOffset - gridBottomOffset) / 20) – 3. Recall from earlier that Session["WindowHeight"] holds the current window height. See also Shrikantiah 3 (“On document ready function, SaveWindowHeight web service method will be called to store the window”). Accordingly, Shrikantiah explicitly teaches selecting no more than a threshold number of items from a data source for display that is based on the shape and size of the GUI.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply Shrikantiah’s known technique to Fauchère’s known method 300 and/or system 100, ready for improvement, to yield the predictable result of selecting only up to a threshold number of macros that is based on user’s window height.
The rationale to support this conclusion of obviousness is that “a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art,” and that “[o]ne of ordinary skill in the art would have been capable of applying this known technique to a known device (method, or product) that was ready for improvement and the results would have been predictable to one of ordinary skill in the art.” MPEP § 2143 (subsection (I.)(D.)).
Consistent with the guidance that MPEP § 2143 (subsection (I.)(D.)) provides for reaching this conclusion, the relevant findings of fact (and the evidence that supports those findings) are as follows:
(1) The prior art contained a “base” device and method upon which the claimed invention can be seen as an “improvement.” The evidence for this finding was provided in the first half of this rejection, where each Patented claim element mapped to its corresponding Pending claim element. Those findings are hereby reincorporated into this paragraph, by reference.
(2) The prior art contained a known technique that is applicable to the base device and method. The evidence for this finding was provided in the second half of this rejection, where Shrikantiah’s item paging technique was discussed relative to each corresponding claim element. Once again, those findings are hereby reincorporated into this paragraph by reference.
(3) One of ordinary skill in the art would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system. The evidence for this finding includes Shrikantiah’s explicit suggestion that the technique is an improvement over less-flexible approaches. See Shrikantia 6 (“This can be used as a powerful UI feature, when user wants his page size to vary based on this screen rather than the pre-defined one.”).
In view of the foregoing findings, the Office concludes that claims 1 and 13 would have been obvious to a person of ordinary skill in the art before their filing date, based on the combination of Shrikantia with respective Patented Claim 1 (for pending claim 1) or Patented Claim 14 (for pending claim 13).
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