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 .
Claims 1-22 are pending.
Claim Objections
Claims 9, 16 and 22 are objected to because of the following informalities:
Claims 9, 16 and 22 recite an abbreviation “SPU” without reciting full text. Applicant is encourage to express full text in parentheses at a first time, for example, CPU (central processing unit).
Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 10-22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. 12093699 B2 Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the patent perform the same steps as the claims in the instant application.
It would have been obvious to one of ordinary skill in the art to modify and/or to omit the additional elements of claims 1-12 of Patent to arrive at the claims 10-22 of the instant application because the ordinary skilled person would have realized that the remaining elements would perform the same functions as before. Omission and/or additional of elements and its function in combination is obvious expedient if the remaining elements perform the same functions as before.
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-9 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 the limitation "the host" and “the host server” in lines 7 and 8. There are insufficient antecedent basis for this limitation in the claim.
Claims 2-9 are rejected because of their dependencies.
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 10-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ciocari et al. (hereinafter Ciocari) (US 20200301616 A1) in view of Cockrell et al. (hereinafter Cockrell) (US 20140282815 A1)1
As to claim 10, Ciocari teaches a system [FIG.1: electronic device 10] comprising:
a storage device controller [FIG. 1: processor 25], resident in a host server [FIG.1], wherein the storage device controller is further to:
receive an image [0014: “the process may download OS image files including OS loader files among others from a preconfigured network location.”];
store content from the image to a virtual volume which is accessible to the host server only through the storage device controller [0015: “The processor 25 saves computer operation system files 49 in the virtual memory device 20…The processor 25 loads the operating system boot sequence 30 by processing the computer operating system files 49 from the virtual memory device 20.”]; and
present the virtual volume as a boot volume for the host server [0015: “the processor 25 loads the operating system boot sequence 30 by processing the computer operating system files 49 from the virtual memory device 20.”].
Ciocari does not teach being configured to access a Uniform Resource Locator, and downloading the image from the URL.
Cockrell teaches accessing a Uniform Resource Locator and downloading image from the URL [0031: “The web boot module 204 is configured to determine a remote boot address containing a boot image, open a secure connection to the web server 104, to download the boot image, and execute the boot image as a firmware application…the remote boot address is a standard uniform resource locator (‘URL’) specifying the use of HTTPS and the location of the remote boot image.”].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teaching of accessing the URL to download the image as suggested in Cockrell into Ciocari to implement booting. One having ordinary skill in the art would have been motivate to make such modification to improve the flexibility by obtaining up to date version of OS from remotely.
As to claim 11, Cockrell teaches wherein the storage device controller accesses the URL through the Internet [0031: “The web boot module 204 is configured to determine a remote boot address containing a boot image, open a secure connection to the web server 104 to download the boot image, and execute the boot image as a firmware application. The web boot module 204 may be embodied as a UEFI boot option. The remote boot address is a standard uniform resource locator ("URL") specifying the use of HTTPS and the location of the remote boot image.” ].
As to claim 12, Cockrell teaches wherein a management system provides the image at the URL [0043: “In some embodiments, in block 410 the mobile computing device 102 may determine the remote boot address based on the context of the mobile computing device 102, for example, based on location, mode, current user, current network, or the like. The mobile computing device 102 may use sensors to determine if the context is appropriate for the remote boot address; these sensors may include location (e.g., geo-fencing) as sensed by GPS in the mobile computing device 102, identity as sensed by a password entered by a user or a biometric input (e.g., voice, fingerprint, iris scan, USB dongle, near-field communication), or other criteria (e.g., date and time). For example, in some embodiments, the context of the mobile computing device 102 may include the location of the mobile computing device 102, as determined using the location sensor(s) 130. As such, the mobile computing device 102 may determine a different remote boot addresses when the mobile computing device 102 is located at the user's work and at the user's home. In some embodiments (not illustrated), the remote boot address may be the same, and boot policies--that is, selection of boot images--may be performed by the web server 104. For example, the mobile computing device 102 may include context information in the request to the web server 104 as part of an HTTP POST request. The web server 104 may include logic to return a particular boot image based on the information received from the mobile computing device 102. Such logic may be implemented as an ordinary web application of the web server 104.”].
As to claim 13, Cockrell teaches wherein the management system selects, from among a plurality images, the image corresponding to an operating system ran by the host server, wherein the plurality of images correspond to a plurality of different operating systems [0031: “the remote boot address is a standard uniform resource locator (‘URL’) specifying the use of HTTPS and the location of the remote boot image.”] [0042: “The remote boot address is illustratively embodied as a uniform resource locator ("URL") that identifies the web server 104 and specifies a particular remote resource containing a remote boot image. Selection of the remote boot address thus may allow selection of a particular boot policy. The remote boot address may specify the use of secure HTTP (using URL scheme name "https").”].
As to claim 14, Cockrell teaches wherein the management system selects the image based on a template [0042: “the remote boot address is stored in the data storage 126 or in non-volatile flash memory storage of the mobile computing device 102. Such embodiments enable several use cases: the remote boot address may be specified by the user and stored for later use, software of the mobile computing device 102 may configure a remote boot address for use upon reboot, and/or the manufacturer of the computing device 102 may pre-program a selection of one or more remote boot addresses. Further, in such embodiments, the manageability engine 132 may not be included or otherwise required in the computing device 102. In some embodiments, the mobile computing device 102 receives the remote boot address from a dynamic host configuration protocol ("DHCP") server. For example, the RFC 5970 proposed standard specifies DHCPv6 options to configure a computing device for network booting. In some embodiments, in block 406 the mobile computing device 102 receives the remote boot address from the manageability engine 132. In such embodiments the remote boot address may be supplied to the manageability engine 132 using its out-of-band network communications capability. For example, the remote boot address may be supplied by enterprise information technology staff, allowing configuration of the remote boot address without intervention by the user of the mobile computing device 102. In some embodiments, the remote boot address may be stored in the secure memory space of the manageability engine 132. Additionally, in some embodiments, in block 408 the mobile computing device 102 receives the remote boot address from console input of the mobile computing device 102. The console of the mobile computing device 102 may be embodied as a display and keyboard, a touch screen, or any other user interface peripheral device of the mobile computing device 102. Thus, the user of the mobile computing device 102 may provide the remote boot address manually.”].
As to claim 15, Cockrell teaches wherein configuration instructions are communicated to the storage device controller, the configuration instructions including the URL [ 0043].
As to claim 16, Ciocari teaches wherein the storage device controller comprises at least one of a SPU, a storage card, or a storage service provider device [FIG. 1: processor 25].
As to claim 17, Ciocari teaches a method comprising:
using a storage device controller [FIG. 1: processor 25] that is resident in a host server [FIG.1: electronic device 10];
receiving an image [0014: “the process may download OS image files including OS loader files among others from a preconfigured network location.”];
storing content from the image to a virtual volume which is accessible to the host server only through the storage device controller [0015: “The processor 25 saves computer operation system files 49 in the virtual memory device 20…The processor 25 loads the operating system boot sequence 30 by processing the computer operating system files 49 from the virtual memory device 20.”]; and
presenting the virtual volume as a boot volume for the host server [0015: “the processor 25 loads the operating system boot sequence 30 by processing the computer operating system files 49 from the virtual memory device 20.”].
Ciocari does not teach being configured to access a Uniform Resource Locator, and downloading the image from the URL.
Cockrell teaches accessing a Uniform Resource Locator and downloading image from the URL [0031: “The web boot module 204 is configured to determine a remote boot address containing a boot image, open a secure connection to the web server 104, to download the boot image, and execute the boot image as a firmware application…the remote boot address is a standard uniform resource locator (‘URL’) specifying the use of HTTPS and the location of the remote boot image.”].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teaching of accessing the URL to download the image as suggested in Cockrell into Ciocari to implement booting. One having ordinary skill in the art would have been motivate to make such modification to improve the flexibility by obtaining up to date version of OS from remotely.
As to claim 18, Cockrell teaches the method of claim 17, further comprising: selecting the URL for the storage device controller; communicating the URL to the storage device controller using a management system that is remote from the host server; and maintaining the image at the URL [0031: “the remote boot address is a standard uniform resource locator (‘URL’) specifying the use of HTTPS and the location of the remote boot image.”] [0042: “The remote boot address is illustratively embodied as a uniform resource locator ("URL") that identifies the web server 104 and specifies a particular remote resource containing a remote boot image. Selection of the remote boot address thus may allow selection of a particular boot policy. The remote boot address may specify the use of secure HTTP (using URL scheme name "https").”].
As to claim 19, Cockrell teaches wherein the selecting the URL includes selecting from among a plurality of URLs that are respectively associated with a plurality of images maintained by the management system [0031: “the remote boot address is a standard uniform resource locator (‘URL’) specifying the use of HTTPS and the location of the remote boot image.”] [0042: “The remote boot address is illustratively embodied as a uniform resource locator ("URL") that identifies the web server 104 and specifies a particular remote resource containing a remote boot image. Selection of the remote boot address thus may allow selection of a particular boot policy. The remote boot address may specify the use of secure HTTP (using URL scheme name "https").”].
As to claim 20, Cockrell teaches wherein the plurality of images includes images respectively for different operating system [0043: “As such, the mobile computing device 102 may determine a different remote boot addresses when the mobile computing device 102 is located at the user's work and at the user's home. In some embodiments (not illustrated), the remote boot address may be the same, and boot policies--that is, selection of boot images--may be performed by the web server 104. For example, the mobile computing device 102 may include context information in the request to the web server 104 as part of an HTTP POST request. The web server 104 may include logic to return a particular boot image based on the information received from the mobile computing device 102. Such logic may be implemented as an ordinary web application of the web server 104.”].
As to claim 21, Cockrell teaches wherein the selecting the URL includes selecting a storage template based at least in part on one or more characteristics of the host server, wherein the URL selected is associated with the storage template selected [0042: “the remote boot address is stored in the data storage 126 or in non-volatile flash memory storage of the mobile computing device 102. Such embodiments enable several use cases: the remote boot address may be specified by the user and stored for later use, software of the mobile computing device 102 may configure a remote boot address for use upon reboot, and/or the manufacturer of the computing device 102 may pre-program a selection of one or more remote boot addresses. Further, in such embodiments, the manageability engine 132 may not be included or otherwise required in the computing device 102. In some embodiments, the mobile computing device 102 receives the remote boot address from a dynamic host configuration protocol ("DHCP") server. For example, the RFC 5970 proposed standard specifies DHCPv6 options to configure a computing device for network booting. In some embodiments, in block 406 the mobile computing device 102 receives the remote boot address from the manageability engine 132. In such embodiments the remote boot address may be supplied to the manageability engine 132 using its out-of-band network communications capability. For example, the remote boot address may be supplied by enterprise information technology staff, allowing configuration of the remote boot address without intervention by the user of the mobile computing device 102. In some embodiments, the remote boot address may be stored in the secure memory space of the manageability engine 132. Additionally, in some embodiments, in block 408 the mobile computing device 102 receives the remote boot address from console input of the mobile computing device 102. The console of the mobile computing device 102 may be embodied as a display and keyboard, a touch screen, or any other user interface peripheral device of the mobile computing device 102. Thus, the user of the mobile computing device 102 may provide the remote boot address manually.”].
As to claim 22, Ciocari teaches wherein the storage device controller comprises at least one of a SPU, a storage card, or a storage service provider device [FIG. 1: processor 25].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to XUXING CHEN whose telephone number is (571)270-3486. The examiner can normally be reached M-F 9-5:30PM.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/XUXING CHEN/ Primary Examiner, Art Unit 2176
1 Ciocari and Cockrell were cited in the IDS filed on 08/09/2024.