DETAILED ACTION
This action is responsive to the application filed on August 29, 2023.
Claims 1-16 are pending and presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The drawings filed on August 29, 2023 are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated August 29, 2023 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [001] recites “The present disclosure related to information technology.” The word “related” is grammatically incorrect and should be changed to --relates--.
Paragraph [008] recites “alternatively include include remote function calls.” The word “include” is duplicated and the second occurrence should be deleted.
Paragraph [0019] recites “FIG. 10 is a flow chart of a flow chart of a method.” The phrase “a flow chart of” is duplicated and the second occurrence should be deleted.
Paragraph [0022] recites “test box test box 130.” The phrase “test box” is duplicated and the second occurrence should be deleted.
Paragraph [0023] recites “test box test box 130,” in which the phrase “test box” is duplicated and the second occurrence should be deleted, and further recites “configuration repositor 250,” in which “repositor” is misspelled and should be changed to --repository--.
Paragraph [0026] recites “ABAP connections establish and ABAP program calling interface.” The word “and” should be changed to --an--. Paragraph [0026] further recites “depending on theconnection type,” in which a space is omitted; “theconnection” should be changed to --the connection--.
Paragraph [0027] recites “digital signed license section 810.” The word “digital” should be changed to --digitally--.
Paragraph [0028] recites “the ALEs that are located are are configured,” in which the word “are” is duplicated and the second occurrence should be deleted, and further recites “the RFCs that are located are configured for the text box,” in which “text box” should be changed to --test box--.
Paragraph [0023] is further objected to because the paragraph describes the inbound connections between test box 130 and servers 205, 210 and 215, yet recites “another outbound connection 232 between test box test box 130 and server 210, and a further outbound connection 238 between test box 130 and server 215.” The claims distinguish between inbound and outbound integrations. Clarification is required as to whether connections 232 and 238 are inbound or outbound, and the word “outbound” should be changed to --inbound-- in each instance if inbound connections are being described.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites a database coupled to the application in line 3. There is insufficient antecedent basis for the limitation “the application” in the claim. It appears that “the application server” was intended, as recited in claim 2 and in paragraph [006] of the specification. Claims 2-8 are rejected as depending from claim 1.
Claim 1 further recites wherein in all future conversion simulations in which a new test box is created, inbound and outbound configurations can be imported from the configuration repository in lines 11-12. There is insufficient antecedent basis for “inbound and outbound configurations”; the claim previously recites “inbound and outbound integrations,” and it cannot be determined whether the two terms are intended to be the same. In addition, the recitation that the configurations “can be” imported states a capability rather than a positively recited step, so that it cannot be determined whether importation is required to infringe.
Claim 1 further recites such that data can be exported from a first database platform to a second database platform and another and vice versa in lines 14-15. The term “and another” has no antecedent basis, and it cannot be determined what element “another” refers to or what relationship “vice versa” requires among the recited platforms. The metes and bounds of the clause cannot be ascertained. Claim 9 is rejected for the same reason, as it recites the identical clause.
Claims 5 and 6 recite “remote functional call” while parent claim 4 recites “remote function calls.” There is insufficient antecedent basis for “a trusted remote functional call connection” in claim 5 and for “remote functional call connections” in claim 6, and it cannot be determined whether a different structure is intended. Claim 13 is rejected for the same reason. Claim 14 recites “remote function call connections” and is therefore not included in this ground.
Claim 9 is drawn to an apparatus (“An enterprise system… comprising”) but recites, in passive form and without identifying the actor, that all of the inbound and outbound integrations of the test box are configured and that the configured integrations are exported to the configuration repository. Neither clause states that the recited acts are performed by the claimed system. The specification indicates that they are performed by personnel rather than by the system, explaining that the configuration information cannot be copied directly to the test box and that it “is supplied by relevant IT personnel when the outbound connections are first made” (paragraph [0022]). It therefore cannot be determined whether infringement of claim 9 occurs upon making the recited enterprise system or upon the subsequent performance of the recited acts by a user. See IPXL Holdings, L.L.C. v. Amazon.com, Inc., 430 F.3d 1377, 1384 (Fed. Cir. 2005); MPEP § 2173.05(p)(II). Claims 10-16 are rejected as depending from claim 9.
Claim 9 further recites the enterprise network. There is insufficient antecedent basis for this limitation in the claim. The preamble of claim 9 recites An enterprise system; no enterprise network is previously recited in claim 9. Amending the preamble to read --An enterprise system of an enterprise network for which multiple system conversion simulations are performed-- would overcome this rejection. Claim 16, which recites characteristics of the enterprise network, is rejected for the same reason, as are claims 10-15 as depending from claim 9.
Claim 7 recites the load balancing configuration. There is insufficient antecedent basis for this limitation in the claim. Parent claim 6 recites logon group load balancing configurations, in the plural and modified by “logon group,” and it cannot be determined which of the recited configurations, or what subset of them, the singular term refers to. Amending “the load balancing configuration” to read --each logon group load balancing configuration-- would overcome this rejection. Claim 15 is rejected for the same reason with respect to parent claim 14.
Claim 10 recites that the test box is configured to import the configured integrations to perform a conversion simulation without reciting the source from which the configured integrations are imported. Because claim 9 recites that the configured integrations are exported to a configuration repository, it cannot be determined whether claim 10 requires importation from that repository or permits importation from any source. Amending the claim to recite --to import the configured integrations from the configuration repository-- would overcome this rejection.
Claims 1 and 9 each recite that the located integrations connect the test box to the other servers in the manner of the reproduced application server and database (claim 1) and in the manner of the copied application server and database (claim 9). The phrase “in the manner of” does not identify what characteristic of the reproduced or copied application server and database the connections must share, and the metes and bounds of the limitation cannot be ascertained. Replacing “in the manner of” with language identifying that characteristic, for example --using the same connection parameters as-- , would overcome this rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 8-13 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over SAP AG, “SAP System Landscape Copy for SAP NetWeaver and mySAP Solutions,” Best Practice for Solution Management, Version Date: February 2006 (hereinafter “SAP”) in view of Kulkarni et al. (U.S. Pub. No. 2008/0183776, hereinafter “Kulkarni”). With respect to claim 1, Sap teaches A method of preserving integration of an enterprise network throughout multiple system conversion simulations comprising: (SAP is a published procedure for copying an SAP system landscape — a set of interconnected SAP application server systems, “all installed on separate servers,” among which business data is distributed (p. 4) — onto a target landscape, and for repeatedly refreshing that target landscape from production. SAP identifies preservation of the connections among those systems as the central problem the procedure exists to solve: it explains that if a target system retains a connection to a source system, test activity in the target can send messages into production and damage production data, and concludes that “all system connections must be carefully adjusted in the complete target environment” (p. 5). The recurring character of the exercise is expressly recited in SAP’s “Refresh” copy scenario, in which the target landscape already exists and only its data is refreshed from production (p. 7), so that the same target landscape is rebuilt from production repeatedly over its life.)
reproducing an application server and a database coupled to the application in a test box (SAP’s “PRD → NPS” copy scenario copies (clones) the production system landscape onto a non-productive landscape, “for example for creating a test environment” (p. 6). The unit that is copied is an SAP Web Application Server together with its database: SAP frames the scope question by observing that copying a solution “often requires more than just copying a single SAP Web Application Server and its database” (p. 5), i.e., the application-server-plus-database pair is the base unit of the copy. Step 4.3 then directs the administrator to “Provide the target system with the data copied from the source system” (p. 37), executed by one of the copy technologies of pp. 8-10 (R3load export and import, database restore, file copy, or split-mirror). The resulting non-productive target system, which is a reproduction of a production application server and its database, is the claimed test box.)
[[executing a program script]] to locate all inbound and outbound integrations that functionally connect the test box to other servers in the enterprise network in the manner of the reproduced application server and database (SAP directs that the complete set of connection definitions by which the target system communicates with the other systems of the landscape be identified on that system before it is overwritten. Step 2.1 enumerates the items to be located and identifies, for each, the transaction from which it is obtained: RFC destinations (transaction SM59), ALE partner profiles (transaction BD64), logon groups (transaction SMLG), logical system names (transaction BD54 or table V_TBDLS), connections to legacy systems, and the “List of outbound destinations and registered inbound queues” obtained from transactions SMQS and SMQR (pp. 23-24). The last of these is expressly directional — outbound destinations and inbound queues — and the remainder are the definitions by which the copied application server exchanges data with the other application servers of the landscape, that is, they connect the target system to those other servers in the same manner as the production application server and database from which it was reproduced. That the set located is the complete set is confirmed by Step 6.4, which instructs the administrator to “Adapt, disable or delete all interfaces to any systems of the production environment” (p. 42) and tabulates the interface types to be checked: RFC and R/3 connections, HTTP, TCP/IP, registered programs, the Java connector, trusted/trusting systems, R/2 connections, CPIC, SAP XI communication, adapters, file, batch input, DB links, archive link, SAP phone, SAP connect, and email (p. 42). Step 3.5 is to the same effect, directing that the administrator “Save the initial configuration of all parameters you are changing” and identifying queue status and RFC destinations among them (p. 28).)
configuring all of the inbound and outbound integrations of the test box (Step 6.4, “Adjust system connections,” configures each located integration on the target system (pp. 41-43). Transaction SM59 is used to adapt all RFC destinations and other communication entries so that the correct target host names of the non-productive landscape and the corresponding user logon data are used (p. 42). Trusted and trusting system connections are deleted or adapted through transactions SMT1 and SMT2, the trusting relations residing in tables RFCSYSACL and RFCTRUST (p. 42). Where ALE is in use, the host names, IP addresses, and logon data within the existing RFC destinations are modified to match the target environment (p. 43). SAP further directs that RFC users and passwords be checked or created for the non-productive environment (p. 42), confirming that this configuration is supplied to the target system by the administrator rather than carried across by the data copy.)
exporting all of the configured inbound and outbound integrations in a configuration repository (Step 2.1 directs that the configured connection settings be taken out of the target system and placed in a store from which they can later be returned: “Export any data that needs to be preserved, for example using the SAP transport mechanism” (p. 23). SAP states the purpose of the step as saving the configuration information that must be preserved before the refresh, so that the information can later be re-entered into the target systems (p. 23). Because a transport request written by the SAP transport mechanism resides outside the target system’s database, it survives the overwrite of that database and is available for the re-import that Step 6.9 performs (p. 47). It is that persistent, external store of exported connection configuration that answers the claimed configuration repository. The order recited in the claim — configure, then export — is likewise met. SAP’s Refresh cycle is iterative: the target system’s integrations are configured at Step 6.4 following one copy (pp. 41-43), those configured integrations are exported at Step 2.1 in preparation for the next copy (p. 23), and they are re-imported at Step 6.9 after that copy completes (p. 47). What Step 2.1 exports is therefore the configured state produced by the preceding Step 6.4.)
performing a conversion simulation on the test box and enterprise network (Under the broadest reasonable interpretation consistent with paragraphs [004] and [0020] of the specification, a “conversion simulation” is a trial execution of a conversion or upgrade performed on a reproduced system rather than on production. SAP teaches exactly this use for the copied landscape: upgrades are to be performed first in a test system, and integration testing is used to verify the interaction of processes and components in more complex system landscapes before new functionality is put into operation (p. 4). SAP’s enumerated purposes for the copy include quality assurance tests, integration tests, upgrade tests, operating system migration, database migration, change of hardware, and Unicode conversion (p. 4). The simulation runs on the target system in its landscape, because the target system’s connections to the other systems of that landscape are the very thing Step 6.4 configures (pp. 41-43).)
wherein in all future conversion simulations in which a new test box is created, inbound and outbound configurations can be imported from the configuration repository (Step 6.9, “Import saved information from step 2.1,” is expressly designated as applicable for Refresh of the target landscape and directs that the new target system be provided with the information saved from the old target system before the refresh was done (p. 47). Because the Refresh scenario is by definition repeated — the target landscape already exists and only its data is refreshed from production (p. 7) — the Step 2.1 export and the Step 6.9 import recur on each successive rebuild of the target system. To the extent this clause is given patentable weight, SAP therefore teaches it; as noted in the § 112(b) rejection above, the clause recites a capability rather than a positively performed step.)
wherein the inbound and outbound integrations are preserved across migrations or conversions between different database platforms such that data can be exported from a first database platform to a second database platform and another and vice versa (SAP defines a Heterogeneous System Copy as one in which the operating system or database system of the target differs from that of the source, also termed an OS/DB Migration (p. 7), and requires that a migration key be obtained from SAP for changing the operating system or database platform (pp. 5, 7). SAP performs such a copy with R3load, which exports and imports the database of an SAP system in a database independent format (p. 8), so that the content of a source database on a first platform is loaded into a target database on a second platform, and the same tool performs the copy in either direction. Critically, SAP does not condition the Step 2.1 export or the Step 6.9 import on the copy technology or on whether the copy is homogeneous or heterogeneous; those steps are keyed to the Refresh scenario (pp. 23, 47) and therefore apply equally to a copy in which the database platform changes. The located and configured integrations are accordingly preserved across a conversion between different database platforms.)
SAP is silent to disclose executing a program script; however, in an analogous art, Kulkarni teaches executing a program script to locate the configuration that is to be preserved across a rebuild of a target system.
Kulkarni is directed to automated refresh and cloning of a database and its application from a source environment to a target environment, where the refreshed or cloned target is used for development, testing, training, or reporting (paragraphs [0003], [0008]). Kulkarni’s control environment includes a discovery module 242 and a script generator 240 (paragraph [0030]). The script generator automatically generates the scripts from information about the source and target environments and writes commands to text files that are then used by shell scripts to perform the backup and cloning tasks (paragraph [0033]). In the discovery phase 302, which is implemented by the discovery module 242 (paragraph [0076]), a shell script reads the configuration parameter values and performs a discovery operation (paragraph [0052]); connectivity between the source server and the target server is checked, and the connectivity server functions and execution functions are written to text files “which will be executed as shell scripts” (paragraph [0078]); and the object lists are retrieved from the source and target databases (paragraph [0080]). Kulkarni then generates export and import scripts for the items that are to be preserved through the clone (paragraphs [0083]-[0084]), writes those exports to a directory on the target server (paragraph [0032], EXPORT_TARGET_DIRECTORY), preserves the exported items “across clones” (paragraph [0032], SAVE_PASSWORD_SCHEMA), and retains metadata for “repeated refresh and clone operations” (paragraph [0074]). Kulkarni thus accomplishes by an automatically generated program script the same locating function that SAP accomplishes by manual inspection of transaction screens.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to.execute the locating of the target system’s inbound and outbound integrations taught by SAP by means of an automatically generated program script as taught by Kulkarni. SAP directs that this configuration be captured by hand — by taking screenshots of transaction settings and by hand-assembling a transport (pp. 23-24) — and directs that the capture be repeated before every refresh of the target landscape (Step 2.1, p. 23; Step 6.9, p. 47), so that the same manual capture recurs on every cycle. Kulkarni identifies the need for a cost effective and efficient automated refresh and cloning method across networked, heterogeneous environments (paragraph [0007]) and teaches that automatic generation of the scripts “provides an important advantage over conventional systems and methods that require user intervention” (paragraph [0089]). One of ordinary skill would therefore have been motivated to substitute Kulkarni’s script-driven discovery for SAP’s manual capture in order to reduce the time and labor consumed by each refresh cycle and to eliminate the transcription errors inherent in re-entering connection settings by hand, with a reasonable expectation of success because Kulkarni’s discovery scripts operate on the same source-environment-and-target-environment pair, and on the same refresh and clone operation, that SAP’s procedure addresses.
With respect to claim 2, SAP teaches further comprising: after an initial simulation: reproducing the application server and the database coupled to the application server in the test box again (SAP’s Refresh copy scenario is the second and subsequent iteration recited: the target non-productive landscape already exists and only its data is refreshed from production (p. 7). The reproduction is performed by the same Step 4.3 data copy that produced the target system in the first instance, which provides the target system with the data copied from the source system and which SAP designates as the main step for a Refresh of the target system (p. 37), executed by R3load export and import, database restore, file copy, or split-mirror (pp. 8-10). The application server and its coupled database are therefore reproduced into the existing test box a further time after the initial simulation.) importing the inbound and outbound configurations to the test box from the configuration repository (SAP designates both halves of this exchange as applicable specifically to a Refresh of the target landscape. Step 2.1 exports the target system’s connection configuration before the refresh by means of the SAP transport mechanism (p. 23), and Step 6.9, “Import saved information from step 2.1,” directs that the new target system be provided with the information that was saved from the old target system before the refresh was done (p. 47). The configuration returned to the rebuilt test box is therefore imported from the store into which it was exported, rather than re-entered from scratch.) and performing a conversion simulation on the test box and enterprise network (The refreshed target landscape is then used for the purposes for which SAP builds it, which SAP enumerates as quality assurance tests, integration tests, upgrade tests, operating system migration, database migration, change of hardware, and Unicode conversion (p. 4). The simulation runs on the target system within its landscape, because the connections between that system and the other systems of the landscape are what Step 6.4 configures (pp. 41-43) and what Steps 2.1 and 6.9 preserve across the refresh (pp. 23, 47).) With respect to claim 3, SAP teaches wherein the integrations include application link enabling structured data messages (Step 2.1 lists “ALE partner profiles” among the items to be preserved from the target system and states that the export can be done with transaction BD64 (p. 24). ALE is SAP’s Application Link Enabling facility, and SAP identifies the payload it carries: ALE “may be used, for example, for exchanging IDocs between the systems, downloading organizational units from the backend OLTP system, or for central user administration” (p. 43). An IDoc — an intermediate document — is the structured data message ALE exchanges between systems, corresponding to the application link enabling structured data messages recited. SAP further warns that new RFC destinations and logical systems must not be created in the target landscape, because ALE distribution would then no longer work, and directs instead that the host names, IP addresses, and logon data within the existing RFC destinations be modified to match the target environment (p. 43) — confirming that the ALE configuration is among the integrations that are located, configured, and preserved.) With respect to claim 4, SAP teaches wherein the integrations include remote function calls (Step 2.1 lists “RFC destinations” among the items to be located and preserved on the target system, obtained from transaction SM59 (p. 24). The interface table of Step 6.4 lists “RFC and R/3 connections” as its first entry, maintained with transaction SM59 (p. 42), and Step 6.4 directs that transaction SM59 be used to adapt all RFC destinations and other communication entries so that the correct target host names and corresponding user logon data are used (p. 42). RFC — remote function call — is thus expressly among the integrations SAP locates, configures, exports, and re-imports.) With respect to claim 5, SAP teaches wherein the integrations further include trust configurations required to receive a trusted remote functional call connection (The Step 6.4 interface table lists “Trusted/Trusting Systems” as a connection type to be checked and maintained with transactions SM59, SMT1, and SMT2 (p. 42). SAP further instructs that where trusted/trusting system connections are used between SAP systems in the landscape, those connections must be deleted or adapted through transactions SMT1 and SMT2, and identifies tables RFCSYSACL and RFCTRUST as holding the trusting relations (p. 42). A trusting relation held in those tables is the configuration by which the receiving system accepts an incoming remote function call from a designated calling system as trusted; it is accordingly a trust configuration required to receive a trusted remote function call connection, and it is treated by SAP as part of the same set of connection configurations that Step 6.4 adjusts and that Steps 2.1 and 6.9 preserve across the refresh (pp. 24, 47).) With respect to claim 8, SAP teaches wherein the integrations include license configurations based on hardware and database characteristics of the enterprise network (SAP places the license among the configurations that must be established on the target landscape, devoting Step 6.11, “Install new SAP license,” to it (p. 48), and marking that step applicable to every copy scenario in the procedure overview (p. 19). Step 6.11 conditions the license configuration on hardware: after migrating a system to another hardware a new SAP license is required for the system, a new license is required for a new non-productive system, and when refreshing a non-productive system the existing license needs to be reinstalled into that system (p. 48) — the last of which places the license configuration within the set of configurations restored on each rebuild of the target system, alongside the Step 6.9 import (p. 47). SAP conditions the licensing of the copy on the database as well. SAP requires that the administrator “register to get a migration key from SAP for changing the operating system or database platform” (p. 5), and states that a Heterogeneous System Copy — defined as a copy in which the operating system or database system of the target system differs from that of the source system — “requires a migration key that will be provided by SAP” (p. 7). Step 1.4 places obtaining that migration key among the preparations of the target environment (p. 22). The license configurations SAP requires for the target landscape are accordingly conditioned both on the hardware of the system and on the database platform on which it runs, as recited.) With respect to claim 9, Claim 9 recites limitations similar to claim 1, differs only in reciting an enterprise system comprising a network of connected application servers each coupled to a database, a test box comprising a copy of one of the application servers and the database coupled to the application server, and a configuration repository coupled to the test box, and is rejected for the same reasons set forth for claim 1 (SAP pp. 4-8, 12, 22-24, 28, 37, 41-43, 47-48; Kulkarni paragraphs [0007], [0030], [0032]-[0033], [0052], [0074], [0076], [0078], [0080], [0083]-[0084], [0089]). The differing limitations are addressed below.
a network of connected application servers, each application server being coupled to a database (SAP describes the enterprise landscape it operates upon as several different SAP systems and components, “all installed on separate servers,” among which business data is distributed (p. 4), and characterizes the base unit of each such system as an SAP Web Application Server together with its database (p. 5). SAP treats those systems as connected: it describes the system connections by which the systems exchange messages with one another and the data exchange dependencies between the components of the landscape (pp. 5-6), and Step 6.4 maintains the RFC, HTTP, TCP/IP, trusted-system, and further connections running between them (p. 42).)
a test box comprising a copy of one of the application servers and the database coupled to the application server (SAP’s “PRD → NPS” scenario copies the production landscape onto a non-productive landscape for the purpose of creating a test environment (p. 6), the copy being carried into the target system at Step 4.3 (p. 37) by R3load export and import, database restore, file copy, or split-mirror (pp. 8-10). The resulting non-productive target system is a copy of a production application server and the database coupled to it.) and
a configuration repository coupled to the test box (Step 2.1 exports the target system’s preserved configuration by means of the SAP transport mechanism (p. 23). The transport so written resides outside the target system’s database and therefore survives the overwrite of that database during the copy, and Step 6.9 imports its contents back into the rebuilt target system (p. 47). That persistent store, which both receives from and delivers to the target system, is a configuration repository coupled to the test box.)
With respect to claim 10, claim 10 recites limitations similar to claim 2 and is rejected for the same reasons set forth for claim 2.
With respect to claim 11, claim 11 recites limitations similar to claim 3 and is rejected for the same reasons set forth for claim 3
With respect to claim 12, claim 12 recites limitations similar to claim 4 and is rejected for the same reasons set forth for claim 4.
With respect to claim 13, claim 13 recites limitations similar to claim 5 and is rejected for the same reasons set forth for claim 5.
With respect to claim 16, claim 16 recites limitations similar to claim 8 and is rejected for the same reasons set forth for claim 8.
Claims 6-7 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over SAP AG, “SAP System Landscape Copy for SAP NetWeaver and mySAP Solutions,” Best Practice for Solution Management, Version Date: February 2006 (hereinafter “SAP”) in view of Kulkarni et al. (U.S. Pub. No. 2008/0183776, hereinafter “Kulkarni”) and further in view of Rehm et al. (U.S. Pub. No. 2010/0153524, hereinafter “Rehm”). With respect to claim 6, SAP teaches wherein the integrations further include logon group load balancing configurations [[for remote functional call connections]] (Step 2.1 lists “Logon groups” among the items to be preserved from the target system before the refresh, obtained from transaction SMLG (p. 24), and Step 6.9 returns the saved information to the rebuilt target system (p. 47). SAP identifies the load balancing function those logon groups perform: adapting the logon groups and application servers of the target system is required in order to “prevent the message server of a target system from routing requests to application servers of the productive system” (p. 12). Distribution of incoming requests by the message server among the application servers designated by a logon group is load balancing, so the logon group settings SAP locates, configures, exports and re-imports are logon group load balancing configurations, carried within the same set of connection configurations as the RFC destinations of Step 2.1 (p. 24).)
SAP and Kulkarni are silent to disclose that the logon group load balancing configurations are for remote functional call connections; however, in an analogous art, Rehm teaches load balancing groups for remote function call connections.
Rehm is directed to managing application servers in a distributed system of the SAP NetWeaver type, in which each system includes multiple application servers that receive and process requests from client applications (paragraph [0003]). Rehm identifies, among the internal requests directed to the application servers of an instance, an RFC (remote function call) handler and a load balancer, the load balancer being the component that distributes requests to one application server or another based on the current workload of each (paragraph [0022]). Rehm then states expressly that an application server placed in an isolated state “is excluded from all existing load balancing methods (e.g., RFC and GUI (graphical user interface) groups)” (paragraph [0026]), and that requests from resources including RFC are blocked from such a server “because these resources rely on the list of application servers that can be used within the system” (paragraph [0028]). Rehm therefore teaches that a group-based load balancing configuration is maintained for, and governs, remote function call connections. It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to apply the logon group load balancing configuration that SAP preserves and re-imports across each refresh of the target system to remote function call connections, as taught by Rehm. SAP maintains the target landscape’s inter-system communication through RFC and R/3 connections (p. 42) and preserves both the RFC destinations and the logon groups as a single set of connection configurations (pp. 24, 47), and Rehm teaches that in such a system the load balancing groups govern RFC requests as well as dialog logons (paragraphs [0022], [0026], [0028]). One of ordinary skill would therefore have been motivated to enable the preserved logon groups for remote function call connections in order to distribute RFC workload across the available application servers of the rebuilt target system rather than concentrating it on a single server, with a reasonable expectation of success because both references address the same SAP NetWeaver style landscape of multiple application servers served by a message server. With respect to claim 7, SAP and Kulkarni are silent to disclose wherein the load balancing configuration is dependent on a name of the application server; however, in an analogous art, Rehm teaches this limitation. Rehm teaches that the load balancing configuration in a distributed system of application servers takes the form of a list in which each application server is individually designated. The central server determines the state of the application servers and generates a list of application servers, and a filtered list that excludes those in an inactive mode, which filtered list is passed to the client applications (Abstract; paragraphs [0012]-[0013]). Rehm states that the resources whose requests are load balanced — HTTP, RFC, updates and batch creation — “rely on the list of application servers that can be used within the system,” and that “[i]f the application server is not present on the list, it is not available to these resources” (paragraph [0028]). Rehm further describes how the load balancer uses that designation: when an application posts a request, the load balancer “could get a list … and get to one application server and get the address to the application server to enable performing a local request on the application server,” and the applications “can only address the application servers that are known from the reduced list” (paragraph [0047]). Rehm identifies the form of that designation, explaining that a server may be referred to “directly (e.g., via identifier or address)” (paragraph [0014]), and that an application server is made inactive or isolated “based on a status indicator, flag, identifier, etc., associated with the application server” (paragraph [0026]).
The identifier by which each application server is designated in, and reached from, that list is a name of the application server within the meaning of the claim. The specification supplies no definition of “name” beyond the recitation itself (paragraphs [0024], [0026]), and under the broadest reasonable interpretation a “name of the application server” encompasses the identifier by which that application server is designated within the system and by which requests are addressed to it. Rehm’s load balancing configuration is dependent on that designation in the operative sense the claim requires: whether the load balancer routes a request to a given application server turns entirely on whether that application server is designated in the list (paragraphs [0028], [0047]). That teaching is consistent with SAP, which requires the logon groups of a copied system to be adapted precisely because the configuration carried over by the copy continues to designate the application servers of the production system, so that the target system’s message server would otherwise route requests to those production application servers (p. 12).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to implement the logon group load balancing configuration that SAP preserves and re-imports across each refresh of the target system as a configuration dependent on the designation of each constituent application server, as taught by Rehm. SAP requires that the logon groups be adapted after the copy so that the target system’s message server does not route requests to the production application servers (p. 12), which presupposes that the configuration designates particular application servers, and Rehm teaches the corresponding implementation — a list in which each application server is individually designated and from which the load balancer obtains the address needed to reach it (paragraphs [0028], [0047]). One of ordinary skill would therefore have been motivated to key the preserved logon group configuration to the identifier of each application server in order to control which application servers of the rebuilt target system receive balanced requests and, as SAP requires, to keep those requests away from the production application servers, with a reasonable expectation of success because Rehm describes this list-based designation in the same kind of multiple-application-server landscape that SAP’s procedure copies.
With respect to claim 14, claim 14 recites limitations similar to claim 6 and is rejected for the same reasons set forth for claim 6.
With respect to claim 15, claim 15 recites limitations similar to claim 7 and is rejected for the same reasons set forth for claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Chopra et al. (U.S. Pub. No. 2009/0228512), teaches scanning one or more SAP application systems with a surveyor to extract the application configuration data, saving the extracted data as an asset in a repository, and uploading and installing selected configuration elements onto an instance of the application (paragraphs [0010]-[0011], [0031]).
Musiri et al. (U.S. Pub. No. 2010/0174811), teaches cloning a web server, a database server, and an application server as virtual computing systems deployed within a fenced virtual computing environment for testing, while preserving in that environment the state of the original computing environment including its network configuration, IP addresses, and machine names, across multiple concurrently deployed instances of the same set of virtual computing systems (paragraphs [0017]-[0018], [0038]).
Haefele et al., “SAP Landscape Management 3.0 and IBM Power Systems Servers”, teaches automated SAP System Clone, SAP System Copy, and SAP System Refresh of a source system onto a target system (§ 2.2.4), post-copy automation task lists that manage the steps run before a system refresh and after a system copy or refresh (§ 2.3.1), and an automated discovery operation that locates the managed SAP systems, their instances, and their corresponding hosts (§ 2.3.6).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights