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 .
Response to Arguments
Applicant’s arguments with respect to claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. It is noted that Crandall is still being used in rejecting a few dependent claims; however, Starkovich when combined with Crandall are considered to render the dependent claims obvious, and Examiner has provided a motivation to combine.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 7, 13-16, 18, 20 and 21 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Starkovich et al. (U.S. Patent No. 6,993,585 B1, hereinafter referred to as “Starkovich”).
Regarding claim 1, Starkovich discloses a computer-implemented method for operating legacy computing environments in conjunction with open computing environments, the computer-implemented method comprising: (“It provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and communications options.”)(e.g., abstract and col 8 lines 22-24)
interpreting data in a first environment structure of a first format used in a first environment to a second structure of a second format used in a second environment, the data as interpreted stored in an intermediate storage; (“The XGate runtime software component 322 (XGate.exe) acts as a conduit between the Windows NT DCOM environment 314 and the Open/OLTP environment 312. Adapters 324 accept requests from DCOM Clients, and then forward the parameters over a named pipe to the XGate runtime 322. Xgate repackages the XML message into the view format required by the Open/OLTP transaction manager 317. The DCOM Server 324 could also include a variety of distributed objects. The stub software component 326 accepts remote procedure calls from object proxies on client PCs and converts them to interface calls to the DCOM Server application 324.” “Xgate prepares the service request buffer from the output of Adapter 502 in accordance with the format described by Input View Definition 510. The service request buffer is provided to connector 506, which transfers it to Server Transaction 508 as described above.”)(e.g., col 9 lines 26-37 and col 10 lines 52-56)
activating a program in the second environment, wherein the program is executed by a broker configured to use data from the intermediate storage, to produce output to be stored in a second intermediate storage; and (“A plurality of adapters convert each of the differing request formats into a single input format for the single generic gateway. In this manner, a client may make a service request via C++, ASP (i.e., an active server page from a web browser), or other format. The appropriate corresponding adapter converts the service request to a standardized format and presents the information to the generic gateway.” “Each of the respective clients sends its service requests to the respective associated adapter as shown. Client 0 92 service requests are sent to Adapter 0 84. Client 1 90 service requests are sent to Adapter 1 86, and Client m 94 service requests are sent to Adapter m 88. As explained above, each of these adapters (i.e., 84, 86, and 88) converts the inputs to a single format for input to GGATE 72.”)(e.g., col 3 lines 42-49 and col 6 line 63 – col 7 line 2)
upon the program termination, interpreting the output in the second intermediate storage from the second structure to the first structure, wherein interpreting the data and the output is performed using a mapper which maps between the first format and the second format, the mapper allowing for two-way translation, thereby interpreting the input from the first environment structure to the second environment, and interpreting the output in the reverse direction using the same definitions, and wherein the first format is different from the second format at least in that at least one data field in the first format is absent in the second format, or at least one data field in the second format is absent in the first format, or in that at least one data field in the first format is formatted differently in the second format, or data fields in the second format have different order from data fields in the first format, (“The XGate runtime software component 322 (XGate.exe) acts as a conduit between the Windows NT DCOM environment 314 and the Open/OLTP environment 312. Adapters 324 accept requests from DCOM Clients, and then forward the parameters over a named pipe to the XGate runtime 322. Xgate repackages the XML message into the view format required by the Open/OLTP transaction manager 317. The DCOM Server 324 could also include a variety of distributed objects. The stub software component 326 accepts remote procedure calls from object proxies on client PCs and converts them to interface calls to the DCOM Server application 324.”)(e.g., col 9 lines 26-37)
wherein the data comprises a tree structure, and wherein the interpretation of data depends on content and position and according to the tree data structure. (“XML is quickly becoming the middleware-independent message interchange format of choice for business-to-business and business-to-customer Internet commerce. A client is now able to use this standards based, self-describing message format to access mainframe transactions.” “Clients 514, 516, 520, and 522 may each interact with a number of mainframe services via XML message format.”)(e.g., col 4 lines 8-13 and col 11 lines 1-3).
Regarding claim 2, Starkovich discloses the method of Claim 1. Starkovich further discloses wherein the first environment is an open environment and the second environment is a legacy environment. (“It provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and communications options.”)(e.g., col 8 lines 22-24).
Regarding claim 3, Starkovich discloses the method of Claim 1. Starkovich further discloses wherein the first environment is a legacy environment and the second environment is an open environment. (“It provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and communications options.”)(e.g., col 8 lines 22-24).
Regarding claim 4, Starkovich discloses the method of Claim 1. Starkovich further discloses further comprising activating the program in the second environment, and providing the program with access to the intermediate storage. (“An intermediate server having an adapter responsively coupled to said user terminal which converts said transaction request to an intermediate format; b. A middleware generic gateway located within said intermediate server interposed between said adapter and said legacy enterprise server which converts said transaction request from said intermediate format to said legacy format; and c. a request buffer created by said middleware generic gateway containing said plurality of request parameters for transfer of said transaction request to said legacy enterprise server.”)(e.g., claim 1 – col 11 lines 34-45).
Regarding claim 5, Starkovich discloses the method of Claim 1. Starkovich further discloses wherein the program is configured to use an Application Program Interface (API) to get values from the intermediate storage and put values into a second intermediate storage. (“As explained above, these adapters provide the formatting necessary to convert the received XML message to a format to interface with Xgate 532, which is the common gate. The connectors shown (i.e., HTPic 534, COMAPI 536, and Queue2 538) each provide an interface from Xgate 532 to a different legacy mainframe system. As described above, the connectors accommodate the differing formats to these different legacy mainframe systems and enable each to interface with the common Xgate 532.”)(e.g., col 11 lines 10-19).
Regarding claim 13. Starkovich discloses a system for operating legacy computing environments in conjunction with open computing environments, the system having a processor, the processor being adapted to perform the steps of: (“It provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and communications options.” System having processor)(e.g., abstract, figure 1 and col 8 lines 22-24)
interpreting data in a first environment structure of a first format used in a first environment to a second structure of a second format used in a second environment, the data as interpreted stored in an intermediate storage; (“The XGate runtime software component 322 (XGate.exe) acts as a conduit between the Windows NT DCOM environment 314 and the Open/OLTP environment 312. Adapters 324 accept requests from DCOM Clients, and then forward the parameters over a named pipe to the XGate runtime 322. Xgate repackages the XML message into the view format required by the Open/OLTP transaction manager 317. The DCOM Server 324 could also include a variety of distributed objects. The stub software component 326 accepts remote procedure calls from object proxies on client PCs and converts them to interface calls to the DCOM Server application 324.” “Xgate prepares the service request buffer from the output of Adapter 502 in accordance with the format described by Input View Definition 510. The service request buffer is provided to connector 506, which transfers it to Server Transaction 508 as described above.”)(e.g., col 9 lines 26-37 and col 10 lines 52-56)
activating a program in the second environment, wherein the program is configured to use data from the intermediate storage, to produce output to be stored in a second intermediate storage; and (“A plurality of adapters convert each of the differing request formats into a single input format for the single generic gateway. In this manner, a client may make a service request via C++, ASP (i.e., an active server page from a web browser), or other format. The appropriate corresponding adapter converts the service request to a standardized format and presents the information to the generic gateway.” “Each of the respective clients sends its service requests to the respective associated adapter as shown. Client 0 92 service requests are sent to Adapter 0 84. Client 1 90 service requests are sent to Adapter 1 86, and Client m 94 service requests are sent to Adapter m 88. As explained above, each of these adapters (i.e., 84, 86, and 88) converts the inputs to a single format for input to GGATE 72.”)(e.g., col 3 lines 42-49 and col 6 line 63 – col 7 line 2)
upon the program termination, interpreting the output in the second intermediate storage from the second structure to the first structure, wherein interpreting the data and the output is performed using a mapper which maps between the first format and the second format, the mapper allowing for two-way translation, thereby interpreting the input from the first environment structure to the second environment, and interpreting the output in the reverse direction using the same definitions, and wherein the first format is different from the second format at least in that at least one data field in the first format is absent in the second format, or at least one data field in the second format is absent in the first format, or in that at least one data field in the first format is formatted differently in the second format, or data fields in the second format have different order from data fields in the first format, (“The XGate runtime software component 322 (XGate.exe) acts as a conduit between the Windows NT DCOM environment 314 and the Open/OLTP environment 312. Adapters 324 accept requests from DCOM Clients, and then forward the parameters over a named pipe to the XGate runtime 322. Xgate repackages the XML message into the view format required by the Open/OLTP transaction manager 317. The DCOM Server 324 could also include a variety of distributed objects. The stub software component 326 accepts remote procedure calls from object proxies on client PCs and converts them to interface calls to the DCOM Server application 324.”)(e.g., col 9 lines 26-37)
wherein the data comprises a tree structure, and wherein the interpretation of data depends on content and position and according to the tree data structure. (“XML is quickly becoming the middleware-independent message interchange format of choice for business-to-business and business-to-customer Internet commerce. A client is now able to use this standards based, self-describing message format to access mainframe transactions.” “Clients 514, 516, 520, and 522 may each interact with a number of mainframe services via XML message format.”)(e.g., col 4 lines 8-13 and col 11 lines 1-3).
Regarding claim 14, Starkovich discloses the system of Claim 13. Starkovich further discloses wherein the first environment is an open environment and the second environment is a legacy environment or the first environment is a legacy environment and the second environment is an open environment. (“It provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and communications options.”)(e.g., col 8 lines 22-24).
Claims 15, 16 and 18 have substantially similar limitations as stated in claims 4, 5 and 7, respectively; therefore, they are rejected under the same subject matter.
Regarding claim 20. Starkovich discloses a computer program product for operating legacy computing environments in conjunction with open computing environments, the computer-implemented method, the computer program product comprising a non-transitory computer readable medium retaining program instructions, which instructions when read by a processor, cause the processor to perform: (“The detailed descriptions which follow are presented largely in terms of algorithms and symbolic representations of operations on data bits within a computer memory.” “It provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and communications options.” System having processor)(e.g., abstract, figure 1 and col 4 lines 59-61 and col 8 lines 22-24)
interpreting data in a first environment structure of a first format used in a first environment to a second structure of a second format used in a second environment, the data as interpreted stored in an intermediate storage; (“The XGate runtime software component 322 (XGate.exe) acts as a conduit between the Windows NT DCOM environment 314 and the Open/OLTP environment 312. Adapters 324 accept requests from DCOM Clients, and then forward the parameters over a named pipe to the XGate runtime 322. Xgate repackages the XML message into the view format required by the Open/OLTP transaction manager 317. The DCOM Server 324 could also include a variety of distributed objects. The stub software component 326 accepts remote procedure calls from object proxies on client PCs and converts them to interface calls to the DCOM Server application 324.” “Xgate prepares the service request buffer from the output of Adapter 502 in accordance with the format described by Input View Definition 510. The service request buffer is provided to connector 506, which transfers it to Server Transaction 508 as described above.”)(e.g., col 9 lines 26-37 and col 10 lines 52-56)
activating a program in the second environment, wherein the program is configured to use data from the intermediate storage, to produce output to be stored in a second intermediate storage; and (“A plurality of adapters convert each of the differing request formats into a single input format for the single generic gateway. In this manner, a client may make a service request via C++, ASP (i.e., an active server page from a web browser), or other format. The appropriate corresponding adapter converts the service request to a standardized format and presents the information to the generic gateway.” “Each of the respective clients sends its service requests to the respective associated adapter as shown. Client 0 92 service requests are sent to Adapter 0 84. Client 1 90 service requests are sent to Adapter 1 86, and Client m 94 service requests are sent to Adapter m 88. As explained above, each of these adapters (i.e., 84, 86, and 88) converts the inputs to a single format for input to GGATE 72.”)(e.g., col 3 lines 42-49 and col 6 line 63 – col 7 line 2)
upon the program termination, interpreting the output in the second intermediate storage from the second structure to the first structure, wherein interpreting the data and the output is performed using a mapper which maps between the first format and the second format, the mapper allowing for two-way translation, thereby interpreting the input from the first environment structure to the second environment, and interpreting the output in the reverse direction using the same definitions, and wherein the first format is different from the second format at least in that at least one data field in the first format is absent in the second format, or at least one data field in the second format is absent in the first format, or in that at least one data field in the first format is formatted differently in the second format, or data fields in the second format have different order from data fields in the first format, (“The XGate runtime software component 322 (XGate.exe) acts as a conduit between the Windows NT DCOM environment 314 and the Open/OLTP environment 312. Adapters 324 accept requests from DCOM Clients, and then forward the parameters over a named pipe to the XGate runtime 322. Xgate repackages the XML message into the view format required by the Open/OLTP transaction manager 317. The DCOM Server 324 could also include a variety of distributed objects. The stub software component 326 accepts remote procedure calls from object proxies on client PCs and converts them to interface calls to the DCOM Server application 324.”)(e.g., col 9 lines 26-37)
wherein the data comprises a tree structure, and wherein the interpretation of data depends on content and position and according to the tree data structure. (“XML is quickly becoming the middleware-independent message interchange format of choice for business-to-business and business-to-customer Internet commerce. A client is now able to use this standards based, self-describing message format to access mainframe transactions.” “Clients 514, 516, 520, and 522 may each interact with a number of mainframe services via XML message format.”)(e.g., col 4 lines 8-13 and col 11 lines 1-3).
Claim 21 has substantially similar limitations as stated in claim 2; therefore, it is rejected under the same subject matter.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6, 8, 9, 11, 12, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Starkovich in view of Crandall et al. (U.S. Publication No. 2008/0155224 A1. Hereinafter referred to as “Crandall”).
Regarding claim 6, Starkovich discloses the method of Claim 5. However, Starkovich does not appear to specifically disclose wherein the program in the second environment can access dynamically allocated memory locations for reading and writing, in accordance with business logic of the program in the second environment.
On the other hand, Crandall, which relates to performing input/output operations on a data processing platform that supports multiple memory page sizes (title), does disclose wherein the program in the second environment can access dynamically allocated memory locations for reading and writing, in accordance with business logic of the program in the second environment. (“Legacy OS 200 is adapted to communicate directly with various legacy I/O Processors (IOPs) such as legacy IOP 204, which includes I/O hardware of a type typically found on a legacy platform. Legacy IOP 204 provides an interface between main memory 100 and the HBAs such as fibre channel HBA 106 and SCSI HBA 108. Legacy OS 200 includes data protection and other security features that ensures that I/O operations initiated by the legacy OS will maintain the data stored within mass storage devices 109 in a coherent state. The legacy OS also has sophisticated protection mechanisms in place to guard against unintentional or unauthorized data deletions or updates.”)(e.g., paragraph [0063]).
Both Starkovich and Crandall relate to legacy computing systems where data is converted so that it can be accessible to both legacy and native systems. Starkovich provides that service requests are processed that are presented as XML messages having a number of formats within a single gateway. E.g., abstract. However, Starkovich does not appear to specifically disclose the second environment can access dynamically allocated memory locations for reading and writing, in accordance with business logic of the program in the second environment. Starkovich does not appear to specifically disclose whether the data includes an array. On the other hand, Crandall does disclose access to dynamically allocated memory locations, which provides visibility that allows the commodity OS to readily facilitate the updating of data to any of these mass storage devices according to user commands or requests issued from application programs. E.g., paragraphs [0010] and [0063]. Therefore, it would have been obvious to incorporate these features as disclosed in Crandall to Starkovich to enhance the user’s experience by providing enhanced visibility to enable users to access and modify data across the legacy and native platforms, along with various types of data that includes data including arrays.
Regarding claim 7, Starkovich discloses the method of Claim 5. Starkovich further discloses wherein the second format is a format accessible to the API. (“The adapter of DCOM Server 70 converts the service request input to the standardized input utilized by GGATE 72. This generic gateway is described in greater detail in the above incorporated, co-pending, and commonly assigned patent applications. After processing, GGATE 72 routes the service request via the appropriate of the plurality of Connector 0 73, Connector 1 74, or Connector 2 75. The selected connector transfers the service request to End Service Provider 78, which honors the service request.” “The connectors shown (i.e., HTPic 534, COMAPI 536, and Queue2 538) each provide an interface from Xgate 532 to a different legacy mainframe system. As described above, the connectors accommodate the differing formats to these different legacy mainframe systems and enable each to interface with the common Xgate 532.”)(e.g., col 6 lines 48-56 and col 11 lines 14-19).
Regarding claim 8, Starkovich discloses the method of Claim 1. However, Starkovich does not appear to specifically disclose wherein the program in the second environment is adapted to: receive an address of the intermediate storage; read data from the intermediate storage; and write data to a second intermediate storage.
On the other hand, Crandall, which relates to performing input/output operations on a data processing platform that supports multiple memory page sizes (title), does disclose wherein the program in the second environment is adapted to: receive an address of the intermediate storage; (“Commodity OS 113 is not adapted to initiate I/O operations using legacy IOP 204. During system initialization, commodity OS 113 will determine that some unidentified type of hardware device (i.e., legacy IOP 204) is coupled to the system and will cause the appropriate driver to be loaded, which in this example is shown as IOP driver 206. This IOP driver 206 provides an interface that allows the commodity OS to communicate in a limited fashion with the legacy IOP 204. However, IOP driver 206 does not allow the commodity OS 113 to communicate directly with the HBAs. In fact, the legacy IOP 204 hides the existence of the HBAs from the commodity OS. As a result, the commodity OS 113 will not attempt to perform I/O operations to/from mass storage devices 109. This protects the data from any unauthorized inadvertent and/or malicious update activities that may be initiated via commodity OS 113.” “The request packet includes the address(es) of the data buffer(s) in main memory to which, or from which, the data will be transferred.”)(e.g., paragraphs [0064] and [0069])
read data from the intermediate storage; and write data to a second intermediate storage. (“Commodity OS 113 is not adapted to initiate I/O operations using legacy IOP 204. During system initialization, commodity OS 113 will determine that some unidentified type of hardware device (i.e., legacy IOP 204) is coupled to the system and will cause the appropriate driver to be loaded, which in this example is shown as IOP driver 206. This IOP driver 206 provides an interface that allows the commodity OS to communicate in a limited fashion with the legacy IOP 204. “ “Legacy OS may initiate an I/O operation to transfer legacy data on behalf of application programs (APs) 205A. For instance, APs 205A may make a request to legacy OS 200 to read data from, or write data to, mass storage devices 109. When this occurs, the requesting one of APs 205A provides one or more addresses to data buffers in main memory to which, or from which, the data will be transferred.”)(e.g., paragraph [0064], [0066], [0069], [0075] and [0085]).
It would have been obvious to combine Crandall with Starkovich for the same reasons as provided in claim 6, above.
Regarding claim 9, Starkovich in view of Crandall discloses the method of Claim 8. Crandall further discloses wherein the second format is a format accessible to the program in the second environment. (“Legacy OS 200 is adapted to communicate directly with various legacy I/O Processors (IOPs) such as legacy IOP 204, which includes I/O hardware of a type typically found on a legacy platform. Legacy IOP 204 provides an interface between main memory 100 and the HBAs such as fibre channel HBA 106 and SCSI HBA 108. Legacy OS 200 includes data protection and other security features that ensures that I/O operations initiated by the legacy OS will maintain the data stored within mass storage devices 109 in a coherent state. The legacy OS also has sophisticated protection mechanisms in place to guard against unintentional or unauthorized data deletions or updates.”)(e.g., paragraph [0063] and [0157]).
Regarding claim 11, Starkovich discloses the method of Claim 1. However, Starkovich does not appear to specifically disclose wherein the data comprises an array.
On the other hand, Crandall, which relates to performing input/output operations on a data processing platform that supports multiple memory page sizes (title), does disclose wherein the data comprises an array. (“If the call is successful, commodity OS returns an array of page descriptors that provides the starting physical addresses of the pages in physical memory that have been allocated to the buffer in virtual address space.”)(e.g., paragraphs [0052] and [0110]).
It would have been obvious to combine Crandall with Starkovich for the same reasons as provided in claim 6, above.
Regarding claim 12, Starkovich in view of Crandall discloses the method of Claim 11. Crandall further discloses wherein the array is a multi-dimensional array. (“If the call is successful, commodity OS returns an array of page descriptors that provides the starting physical addresses of the pages in physical memory that have been allocated to the buffer in virtual address space.”)(e.g., figures 4-5 and paragraphs [0052] and [0110]).
Claim 17 has substantially similar limitations as stated in claim 6; therefore, it is rejected under the same subject matter.
Regarding claim 19, Starkovich discloses the system of Claim 13. However, Starkovich does no appear to specifically disclose wherein the program in the second environment is adapted to receive an address of the intermediate storage; read data from the intermediate storage; and write data to a second intermediate storage, and wherein the second format is a format accessible to the program in the second environment.
On the other hand, Crandall, which relates to performing input/output operations on a data processing platform that supports multiple memory page sizes (title), does disclose wherein the program in the second environment is adapted to: receive an address of the intermediate storage; read data from the intermediate storage; and write data to a second intermediate storage, and (“Commodity OS 113 is not adapted to initiate I/O operations using legacy IOP 204. During system initialization, commodity OS 113 will determine that some unidentified type of hardware device (i.e., legacy IOP 204) is coupled to the system and will cause the appropriate driver to be loaded, which in this example is shown as IOP driver 206. This IOP driver 206 provides an interface that allows the commodity OS to communicate in a limited fashion with the legacy IOP 204. “ “The request packet includes the address(es) of the data buffer(s) in main memory to which, or from which, the data will be transferred.” “Legacy OS may initiate an I/O operation to transfer legacy data on behalf of application programs (APs) 205A. For instance, APs 205A may make a request to legacy OS 200 to read data from, or write data to, mass storage devices 109. When this occurs, the requesting one of APs 205A provides one or more addresses to data buffers in main memory to which, or from which, the data will be transferred.”)(e.g., paragraph [0064], [0066], [0069], [0075] and [0085]) wherein the second format is a format accessible to the program in the second environment. (“Legacy OS 200 is adapted to communicate directly with various legacy I/O Processors (IOPs) such as legacy IOP 204, which includes I/O hardware of a type typically found on a legacy platform. Legacy IOP 204 provides an interface between main memory 100 and the HBAs such as fibre channel HBA 106 and SCSI HBA 108. Legacy OS 200 includes data protection and other security features that ensures that I/O operations initiated by the legacy OS will maintain the data stored within mass storage devices 109 in a coherent state. The legacy OS also has sophisticated protection mechanisms in place to guard against unintentional or unauthorized data deletions or updates.”)(e.g., paragraph [0063] and [0157]).
It would have been obvious to combine Crandall with Starkovich for the same reasons as provided in claim 6, above.
Conclusion
The prior art made, listed on form PTO-892, of record and not relied upon is considered pertinent to applicant's disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD L BOWEN whose telephone number is (571)270-5982. The examiner can normally be reached Monday through Friday 7:30AM - 4:00PM EST.
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, Aleksandr Kerzhner can be reached at (571)270-1760. 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.
/RICHARD L BOWEN/ Primary Examiner, Art Unit 2165
Prosecution Insights