DETAILED ACTION
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-10 are pending.
Claim Objections
Claims 2 and 7 are objected to because of the following informalities:
There is a typographical error in the claims. For the purpose of this office action the Examiner is interpreting the claim to read:
“…when the version number of any one of the functional modules of the client configuration stored at the server is updated…”.
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-10 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 pre-AIA the applicant regards as the invention.
With respect to claims 1-10, the use of the phrases “if there is”, “whether/when there is” an “when it is determined” (see claims 1, 2, 3, 6, 7, and 8), adds ambiguity to the scope of the claimed invention.
The Examiner therefore suggests amending the claims to further clarify the claimed invention, such as:
as per claim 1, “…determining an update to a client configuration is stored at the server based on the configuration header data; and,
updating a corresponding configuration at the client according to the version header data”;
as per claim 2, “…setting a value of a corresponding digit in the response header data to an agreed value representing an update…”;
as per claim 3, “…determining an update to a client configuration is stored at the server based on the configuration header data, comprises: determining whether the configuration header data contains the agreed value representing an update”;
as per claim 6, “…configured to determine an update to the client configuration is stored at the server based on the configuration header data; an operation unit, configured to update a corresponding configuration at the client according to the version header data”;
as per claim 7, “…and the first setting subunit sets a value of the corresponding digit in the configuration header data to an agreed value representing an update”;
as per claim 8, “an update determination subunit, which is used to determine the configuration header data contains an agreed value representing an update.”
As per claim 4, “the functional modules” (i.e., “…to detect the functional modules that need to be updated”) lacks antecedent basis in the claim. For the purpose of this office action, the Examiner is interpreting the claim to read:
“…to detect [[the]] functional modules that need to be updated”.
In addition, as per claims 6-10, the limitations: (see claim 6) “information receiving unit”, “information extraction unit”, “update judgment unit”, and “operation unit”; (see claim 7) “message setting unit“, “first setting subunit”, “second setting subunit”, and “response header generating subunit”; (see claim 8) “update judgment unit” and “update determination subunit”; (see claim 9) “operation unit”, “data comparison subunit”, “module update subunit”, and “data replacement subunit”, have been interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because they use a generic placeholder (i.e., “unit” or “subunit”), that is modified by functional language, without reciting sufficient structure, material or acts for performing the claimed function (see MPEP §2181).
Since the claim limitations invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claims 6-10 have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
For a computer-implemented means-plus-function claim limitation invoking 35 U.S.C. 112(f) the Federal Circuit has stated that “a microprocessor can serve as structure for a computer-implemented function only where the claimed function is ‘coextensive’ with a microprocessor itself” (see MPEP §2181(B) (internal citations omitted)), of which the Federal Circuit has recognized the functions of “receiving”, “storing”, “processing” data as being “coextensive” with a microprocessor. Id. Thus, "[a] microprocessor or general purpose computer lends sufficient structure only to basic functions of a microprocessor. All other computer-implemented functions require disclosure of an algorithm." Id.
Thus, as is the case here, with respect to the “information receiving unit”, which is directed to basic computer functions (i.e., “receiving a response message…”) Applicant’s disclosure of a general purpose computer or microprocessor (i.e., client, see Fig. 8) is sufficient for the privilege of invoking 35 U.S.C. 112(f).
For a computer-implemented means-plus-function limitation invoking 35 U.S.C. 112(f) claim limitation to a specific computer function, as is the case here with respect to the functions performed by the following units/subunits: (see claim 6) “information extraction unit”, “update judgment unit”, and “operation unit”; (see claim 7) “message setting unit“, “first setting subunit”, “second setting subunit”, and “response header generating subunit”; (see claim 8) “update judgment unit” and “update determination subunit”; (see claim 9) “operation unit”, “data comparison subunit”, “module update subunit”, and “data replacement subunit”, the specification must disclose an algorithm for performing the claimed specific computer function (see MPEP §2181(B)).
In this case, however, the specification does not appear to describe, in sufficient detail, a corresponding algorithm for performing the claimed function associated with the above units/subunits. Thus claims 6-9 are rejected as failing to distinctly claim the subject matter which applicant regards as the invention.
In response to the Office action, if applicant does not want to have the claim limitation interpreted under 35 U.S.C. 112(f), applicant may: (1) Present a sufficient showing to establish that the claim limitation recites sufficient structure to perform the claimed function so as to avoid interpretation under 35 U.S.C. 112(f); or (2) amend the claim limitation in a way that avoids interpretation under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function).
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 of this title, 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.
Claims 1, 4, 6, 8, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Azami (US 2009/0063842)(“Azami”) in view of Chiles et al. (US 6,167,567)(“Chiles”).
As per claim 1, Azami teaches a method for achieving timely updating of client configuration (i.e., a plurality of types of software for a client/printer, see abstract), characterized by comprising steps:
…
obtaining a response header data (i.e., “firm header”, see Fig. 2) containing client configuration update information from the response message (i.e., “identification information about the firmware to be updated”, see ¶0029), wherein the response header data includes a configuration header data (e.g., “designation of data” and/or “version management target flag”, see Fig. 2) and a version header data (e.g., “data version”, see Fig. 2); and,
determining whether there is an update to a client configuration stored at the server based on the configuration header data (see Fig. 3, ref. S104-S105, ¶0035-0037); and,
updating a corresponding configuration at the client according to the version header data, if there is an update (see Fig. 3, ref. S106).
As per claim 1, Azami does not expressly teach receiving the response message (i.e., update package) fed back by a server after a client initiates any request to the server.
Nevertheless, initiating a request to a server for software/firmware updates was well known in the art, prior to the earliest effective filing date of the claimed invention (see for example, Chiles, abstract and col. 9, lines 35-46).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to modify the teaching of Azami to request from a server the update package/firmware. The obvious motivation for doing so would have been to support remotely updating software/firmware at the client/printer in Azami.
As per claim 4, Azami further teaches
comparing the response header data that is newly obtained with a local response header data stored at the client (information in ROM, see ¶0037) to detect functional modules (e.g., software) that need to be updated (see abstract); and,
updating the local response header data to the response header data newly obtained (although not expressly recited, impliedly once updated or following update completion, see ¶0039, the information in ROM, see ¶0037, will be updated to reflect the newly installed version).
As per claim 4, Azami does not expressly teach obtaining a corresponding URL to update a corresponding functional module based on the detected functional modules that need to be updated.
Nevertheless, using a URL to update corresponding software was well known in the art prior to the earliest effective filing date of the claimed invention (see for example Chiles Fig. 4B, ref. 458, also see col. 13, line 53 - col. 14, line 15).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to use a URL to access the updated software/firmware (i.e., functional module) in Azami. The obvious motivation for doing so would have been 1) to reduce the size of the update package and 2) to ensure the client/printer in Azami is provided with the latest software/firmware (i.e., functional module).
Claim 6 is rejected under the same rationale as claim 1 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
As per claim 8, Azami further teaches the update judgment unit comprises: an update determination subunit, which is used to determine whether the configuration header data contains an agreed value representing an update (see “data version in the firm header”, ¶0037, which impliedly represents a programmed or “agreed value” representing an update); and,
if yes, it is determined that there is an update in the client configuration (see ¶0037, i.e., “when the software update corresponds to the version update (YES in step S105)”).
Azami does not expressly teach the software update being stored at the server.
Nevertheless, similar to above, storing updates on a server was well known in the art prior to the earliest effective filing date of the claimed invention (see for example Chiles Fig. 4B, ref. 458, also see col. 13, line 53 - col. 14, line 15, where the web site associated with updated files, is impliedly associated with a server).
The same motivation for combining Azami and Chiles in claim 4, applies equally well to claim 8.
Claim 9 is rejected under the same rationale as claim 4 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
Allowable Subject Matter
Claims 2-3, 5, 7 and 10, though rejected under 35 U.S.C. §112(b), are objected to, for purpose of 35 U.S.C. §102 and §103, as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
The prior art does not teach or render obvious, before the effective filing date of Applicant' s claimed invention, in the specific combinations and manner recited within the claims, the features of:
As per claims 2-3, and 5, “…the response header data is generated by the server according to rules of response header data agreed with the client, and the method comprises steps:
initializing the configuration header data to a set of fixed digits, wherein a digit count of the configuration header data is determined by a count number of modules of the client configuration stored at the server, and each digit of the configuration header data represents one functional module of the client configuration stored at the server; and,
setting a value of a corresponding digit in the response header data to an agreed value representing an update, when there is an update to a functional module of the client configuration stored at the server; and,
setting the version header data, which consists of configuration version numbers that correspond to the functional modules of the client configuration stored at the server respectively, and a discrete request time of the client; wherein each configuration version number represents a version number of the corresponding functional module of the client configuration stored at the server; and,
updating a value of the corresponding configuration version number, when the version number of anyone of the functional modules of the client configuration stored at the server is updated: and setting the discrete request time; and,
combining the configuration header data and the version header data to generate the response header data.”
Claim 7 recites substantially identical subject matter as claim 2. Therefore claims 7 and 10 are indicated as allowable over the prior art for the same reason as noted above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brendan Higa whose telephone number is (571)272-5823. The examiner can normally be reached Monday - Friday 8:30 AM - 5: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, James Hwang can be reached at (571) 272-4036. 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.
/BRENDAN Y HIGA/Primary Examiner, Art Unit 2441