Don't delete dependent claims, just add new dependent claims.
If dependent claims are allowed, add them separately to independent claims, pay for the extra independent claims, if necessary.
Saturday, January 3, 2009
Kyle's preferred format
Claims 1-4, 6-10, and 28-33.
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Kyle's preferred format
Claims 1-4, 6-10, and 28-33.
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Subscribe to:
Posts (Atom)