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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/24/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of U.S. Patent No. 12,282,461. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims are obvious variants as the independent claims of the instant invention are broader than the independent claims of Patent No. 12,282,461 as shown in the comparison table below (see differences based on the underlined portions of the claims).
Instant Application Claims
Patent No. 12,282,461
Claim 1. A method, comprising:
receiving, from a client device, an input/output (I/O) request pursuant to a first protocol, the first protocol being a standards-based I/O protocol; communicating the I/O request to a proxy communicatively coupled with a mainframe server,
the mainframe server being configured to communicate using a second protocol, the second protocol being a proprietary, mainframe protocol that is inconsistent with the first protocol;
accessing a database having a mapping of a plurality of I/O requests of the first protocol to a plurality of corresponding capabilities of the second protocol;
converting the I/O request pursuant to the first protocol to a corresponding capability pursuant to the second protocol;
enforcing, using the proxy, security and management policies associated with the mainframe server;
executing the I/O request on the mainframe server, using the corresponding capability pursuant to the second protocol;
receiving data from the mainframe server, in response to the I/O request;
determining whether the data requires transformation in order to be consistent with the first protocol;
in response to determining that the data requires transformation, transforming the data received from the mainframe server into a data format consistent with the first protocol; and
communicating the transformed data to the client device in response to the I/O request.
Claim 1. A method, comprising:
receiving, at a proxy communicatively coupled with a mainframe server, from a client device, an input/output (I/O) request pursuant to a first protocol, the first protocol being a standards-based I/O protocol;
the mainframe server being configured to communicate using a second protocol, the second protocol being a proprietary, mainframe protocol that is inconsistent with the first protocol;
accessing a database having a mapping of a plurality of I/O requests of the first protocol to a plurality of corresponding capabilities of the second protocol;
converting the I/O request pursuant to the first protocol to a corresponding capability pursuant to the second protocol;
enforcing, using the proxy, security and management policies associated with the mainframe server for executing the converted I/O request;
executing the converted I/O request on the mainframe server, using the corresponding capability pursuant to the second protocol;
receiving data from the mainframe server, in response to the converted I/O request;
determining whether the data requires transformation in order to be consistent with the first protocol;
in response to determining that the data requires transformation, transforming the data received from the mainframe server into a data format consistent with the first protocol; and
communicating the transformed data to the client device in response to the I/O request.
Claim 3. The method of Claim 1, further comprising: receiving a plurality of additional I/O requests pursuant to the first protocol, from the client; for each of the additional I/O requests received pursuant to the first protocol: communicating the additional I/O request to a proxy communicatively coupled with the mainframe server; accessing the database having a mapping of a plurality of I/O requests of the first protocol to a plurality of corresponding capabilities of the second protocol; converting the additional I/O request pursuant to the first protocol to an additional corresponding capability pursuant to the second protocol; executing the additional I/O request on the mainframe server, using the corresponding additional capability pursuant to the second protocol; receiving additional data from the mainframe server, in response to the additional I/O request; determining whether the additional data requires transformation in order to be consistent with the first protocol; in response to determining that the additional data requires transformation, transforming the additional data received from the mainframe server into the data format consistent with the first protocol; and communicating the transformed additional data to the client device in response to the I/O request.
Claim 2. The method of claim 1, further comprising: receiving additional I/O requests pursuant to the first protocol, from the client device; for each of the additional I/O requests received pursuant to the first protocol: communicating the additional I/O request to a proxy communicatively coupled with the mainframe server; accessing the database having a mapping of a plurality of I/O requests of the first protocol to a plurality of corresponding capabilities of the second protocol; converting the additional I/O request pursuant to the first protocol to an additional corresponding capability pursuant to the second protocol; executing the converted additional I/O request on the mainframe server, using the corresponding additional capability pursuant to the second protocol; receiving additional data from the mainframe server, in response to the converted additional I/O request; determining whether the additional data requires transformation in order to be consistent with the first protocol; in response to determining that the additional data requires transformation, transforming the additional data received from the mainframe server into the data format consistent with the first protocol; and communicating the transformed additional data to the client device in response to the additional I/O request.
Claim 4. The method of Claim 1, wherein the security and management policies govern the operation of the mainframe including determining backup policies, file size policies and encryption policies associated with the mainframe server.
Claim 3. The method of claim 1, wherein the security and management policies associated with the mainframe server include backup policies, file size policies and encryption policies associated with the mainframe server.
Claim 5
Claim 4
Claim 6
Claim 5
Claim 7
Claim 6
Claim 8 (same/similar to claim 1)
Claim 7
Claim 10
Claim 8
Claim 11
Claim 9
Claim 12
Claim 10
Claim 13
Claim 11
Claim 14
Claim 12
Claim 15 (same/similar to claims 1 & 8)
Claim 13
Claim 17
Claim 14
Claim 18
Claim 15
Claim 19
Claim 16
Claim 20
Claim 17
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required:
Claims 2, 9 and 16 recite “determining whether the data received from the mainframe server requires filtering in order to be consistent with the I/O request and the first protocol; in response to determining that the data received from the mainframe server requires filtering in order to be consistent with the I/O request and the first protocol, filtering the data received from the mainframe server; and wherein communicating the transformed data to the client device in response to the I/O request comprises communicating the transformed and filtered data to the client device in response to the I/O request.” However, the applicant’s specification fails to disclose any references to filtering data, and is objected to as failing to provide proper antecedent basis for the claimed subject matter.
Claims 3, 10 and 17 recite “receiving a plurality of additional I/O requests…,” “communicating the additional I/O request…,” “converting the additional I/O request…,” “executing the additional I/O request…,” “receiving additional data…,” “determining whether the additional data…,” “in response to determining that the additional data…,” and “communicating the transformed additional data…” However, the applicant’s specification fails to disclose receiving additional requests and performing the communicating, converting, executing, receiving, and determining steps on additional requests, and is objected to as failing to provide proper antecedent basis for the claimed subject matter.
Claims 4, 11 and 18 recite “wherein the security and management policies govern the operation of the mainframe including determining backup policies, file size policies and encryption policies associated with the mainframe server.” However, the applicant’s specification fails to disclose determining backup policies, file size policies and encryption policies associated with the mainframe server, and is objected to as failing to provide proper antecedent basis for the claimed subject matter.
Claims 6, 13 and 20 recite “wherein the client device comprises a Microsoft SQL server, and the database comprises a mapping of a plurality of I/O requests associated with Microsoft SQL with a plurality of corresponding capabilities associated with VSAM.” However, the applicant’s specification fails to disclose wherein the client device comprises a Microsoft SQL server, and the database comprises a mapping of a plurality of I/O requests associated with Microsoft SQL with a plurality of corresponding capabilities associated with VSAM, and is objected to as failing to provide proper antecedent basis for the claimed subject matter.
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 2-4, 9-11 and 16-18 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.
Claims 2, 9 and 16 recite filtering data in order to be consistent with the I/O request and the first protocol, and it is unclear what is meant by filtering of data to be consistent with the request and the first protocol. The applicant’s specification fails to disclose any filtering of data such that it is unclear how to ascertain the metes and bounds of filtering in order to be consistent with the I/O request and the first protocol. Therefore, the claims are rejected for failing to clearly and distinctly disclose what filtering data in order to be consistent with the I/O request and the first protocol entails. For examination purposes, filtering of data will be seen as returning data per the data request.
Claims 3, 10 and 17 recite the limitation "the client" in lines 2, 3 and 3, respectively. There is insufficient antecedent basis for this limitation in the claims as the claims disclose a client device.
Claims 3, 10 and 17 recite the limitation "the additional I/O request" in lines 4, 5 and 6, respectively. There is insufficient antecedent basis for this limitation in the claims as the claims disclose additional I/O requests.
Claims 3, 10 and 17 recite the limitation "the I/O request" in lines 20, 21 and 22, respectively. There is insufficient antecedent basis for this limitation in the claims as the claims disclose an/the additional I/O request.
Claims 4, 11 and 18 recite the limitation "the operation" in lines 1-2, 1-2 and 2, respectively. There is insufficient antecedent basis for this limitation in the claims.
Claims 4, 11 and 18 recite the limitation "the mainframe" in lines 2, 2 and 2, respectively. There is insufficient antecedent basis for this limitation in the claims as the claims disclose a/the mainframe server.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claims are directed to signals per se. Claim 15 is directed to a computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith. As described in the applicant’s specification, paragraphs [0018]-[0020] do not expressly and unambiguously limit that medium to solely non-transitory forms via a definition or similar limiting language nor do they disclose that this computer-readable storage medium excludes transitory signals such that the claimed medium encompasses transitory forms and is ineligible. Claims 15-20 therefore fail to definitely and clearly recite a medium that is non-transitory. The examiner suggests amending the claims to include non-transitory.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 1-4, 7-11 and 14-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lock et al. (U.S. Patent Application Publication No. 2016/0021064; hereinafter Lock) in view of Hartman et al. (U.S. Patent Application Publication No. 2003/0154401; hereinafter Hartman) and further in view of Chen et al. (U.S. Patent Application Publication No. 2022/0164351; hereinafter Chen).
Regarding claim 1, Lock discloses a method, comprising:
receiving, from a client device, an input/output (I/O) request pursuant to a first protocol, the first protocol being a standards-based I/O protocol {¶¶ [0016], [0023], [0024], [0047] client request according to a standardized OData protocol (e.g., such as a standards-based I/O protocol)};
communicating the I/O request to a proxy communicatively coupled with a mainframe server, the mainframe server being configured to communicate using a second protocol, the second protocol being a proprietary, mainframe protocol {¶¶ [0025], [0047] the request is communicated to a proxy/gateway for translation to a proprietary protocol of a backend server}, but fails to explicitly disclose a mainframe server and mainframe protocol that is inconsistent with the first protocol;
accessing a database having a mapping of a plurality of I/O requests of the first protocol to a plurality of corresponding capabilities of the second protocol {¶¶ [0021], [0023], [0033], [0040]-[0042], [0049], [0050] a mapping table is accessed for translating the request from the OData protocol to the backend server protocol based on the appropriate functions (e.g., such as capabilities) denoted in the request};
converting the I/O request pursuant to the first protocol to a corresponding capability pursuant to the second protocol {¶¶ [0025], [0050] the OData client request is translated to the proprietary protocol};
enforcing, using the proxy, security and management policies associated with the mainframe server {¶¶ [0015], [0030], [0038], [0043] encryption services are implemented prior to the data request being passed to the backend server}, but fails to explicitly disclose a mainframe server;
executing the I/O request on the mainframe server, using the corresponding capability pursuant to the second protocol {¶¶ [0025], [0050] processing the translated request by the backend server}, but fails to explicitly disclose a mainframe server;
receiving data from the mainframe server, in response to the I/O request {¶¶ [0025], [0050] the response to the request is received from the backend server}, but fails to explicitly disclose a mainframe server;
transforming the data received from the mainframe server into a data format consistent with the first protocol {¶¶ [0025], [0050] the response from the backend server is translated back to the OData protocol}, but fails to explicitly disclose a mainframe server and in response to determining that the data requires transformation; and
communicating the transformed data to the client device in response to the I/O request {¶¶ [0025], [0050] the OData response is transmitted back to the requesting client}.
Lock also fails to disclose determining whether the data requires transformation in order to be consistent with the first protocol.
However, Hartman discloses:
mainframe server {¶¶ [0005], [0192] back-end system such as mainframe servers};
communicating the I/O request to a proxy communicatively coupled with a mainframe server, the mainframe server being configured to communicate using a second protocol, the second protocol being a proprietary, mainframe protocol that is inconsistent with the first protocol {¶¶ [0096], [0119], [0192] a proprietary protocol of a server/mainframe is different from a specific protocol of an application specific format/protocol utilized by a user device}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which said subject matter pertains, having the teachings of Lock and Hartman before him/her, to modify the teachings of Lock with the teachings of Hartman. The motivation for doing so would combine the backend server and proprietary protocol of Lock with the back-end system/mainframe server and proprietary protocol of Hartman to provide encryption, translation, parsing or conversion services that may enhance the overall security for the system and allow different transport protocols, communication channels, encoding schemes, etc. to be used for or with communications within the system as disclosed by Hartman [0096].
The combination of Lock and Hartman fails to explicitly disclose; however, Chen discloses:
determining whether the data requires transformation in order to be consistent with the first protocol {¶¶ [0073], [0082], claim 25: determines whether a user device does not comprehend the query results from the system protocol and needs to be translated back to the user device protocol};
in response to determining that the data requires transformation {¶¶ [0073], [0082], claim 25: determines whether a user device does not comprehend the query results from the system protocol and needs to be translated back to the user device protocol}, transforming the data received from the mainframe server into a data format consistent with the first protocol.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which said subject matter pertains, having the teachings of Lock, Hartman and Chen before him/her, to modify the teachings of Lock with the teachings of Chen. The motivation for doing so would combine the protocol translation of Lock with the protocol translation of Chen to provide query translation into an appropriate format/dialect between incompatible protocols for query/data comprehension as disclosed by Chen [0001], [0080].
Regarding claim 2, the combination of Lock, Hartman and Chen discloses the method of Claim 1, further comprising:
determining whether the data received from the mainframe server requires filtering in order to be consistent with the I/O request and the first protocol {Lock: ¶¶ [0025], [0050]; Hartman: ¶ [0160]; Chen: ¶ [0080]};
in response to determining that the data received from the mainframe server requires filtering in order to be consistent with the I/O request and the first protocol, filtering the data received from the mainframe server {Lock: ¶¶ [0025], [0050]; Hartman: ¶ [0160]; Chen: ¶ [0080]}; and
wherein communicating the transformed data to the client device in response to the I/O request comprises communicating the transformed and filtered data to the client device in response to the I/O request {Lock: ¶¶ [0025], [0050]; Hartman: ¶ [0160]; Chen: ¶ [0080]}.
Regarding claim 3, the combination of Lock, Hartman and Chen discloses the method of Claim 1, further comprising:
receiving a plurality of additional I/O requests pursuant to the first protocol, from the client {Lock: ¶¶ [0016], [0023], [0024], [0042], [0047]};
for each of the additional I/O requests received pursuant to the first protocol:
communicating the additional I/O request to a proxy communicatively coupled with the mainframe server {Lock: ¶¶ [0025], [0042], [0047]; Hartman: ¶¶ [0005], [0192]};
accessing the database having a mapping of a plurality of I/O requests of the first protocol to a plurality of corresponding capabilities of the second protocol {Lock: ¶¶ [0021], [0023], [0033], [0040]-[0042], [0049], [0050]};
converting the additional I/O request pursuant to the first protocol to an additional corresponding capability pursuant to the second protocol {Lock: ¶¶ [0025], [0042], [0050]};
executing the additional I/O request on the mainframe server, using the corresponding additional capability pursuant to the second protocol {Lock: ¶¶ [0025], [0042], [0050]; Hartman: ¶¶ [0005], [0192]};
receiving additional data from the mainframe server, in response to the additional I/O request {Lock: ¶¶ [0025], [0042], [0050]; Hartman: ¶¶ [0005], [0192]};
determining whether the additional data requires transformation in order to be consistent with the first protocol {Chen: ¶¶ [0073], [0082]};
in response to determining that the additional data requires transformation, transforming the additional data received from the mainframe server into the data format consistent with the first protocol {Lock: ¶¶ [0025], [0042], [0050]; Hartman: ¶¶ [0005], [0192]; Chen: ¶¶ [0073], [0082]}; and
communicating the transformed additional data to the client device in response to the I/O request {Lock: ¶¶ [0025], [0042], [0050]}.
Regarding claim 4, the combination of Lock, Hartman and Chen discloses the method of Claim 1, wherein the security and management policies govern the operation of the mainframe including determining backup policies, file size policies and encryption policies associated with the mainframe server {Lock: ¶¶ [0015], [0030], [0038], [0043]}.
Regarding claim 7, the combination of Lock, Hartman and Chen discloses the method of Claim 1, wherein the client device comprises a computer running either a Microsoft Windows operating system or a Linux operating system {Lock: ¶¶ [0013], [0024]; Hartman: ¶¶ [0120], [0175]: MS Windows}.
Claims 8-11 and 14-18 contain corresponding limitations as claims 1-4 and 7 and are therefore rejected for the same rationale.
Claim(s) 5, 12 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lock et al. (U.S. Patent Application Publication No. 2016/0021064; hereinafter Lock) in view of Hartman et al. (U.S. Patent Application Publication No. 2003/0154401; hereinafter Hartman) in view of Chen et al. (U.S. Patent Application Publication No. 2022/0164351; hereinafter Chen) and further in view of Crew et al. (U.S. Patent Application Publication No. 2012/0144157; hereinafter Crew).
Regarding claim 5, the combination of Lock, Hartman and Chen discloses the method of Claim 1, but fails to disclose wherein the mainframe server comprises a z/OS server employing a virtual storage access method (VSAM).
However, Crew discloses wherein the mainframe server comprises a z/OS server employing a virtual storage access method (VSAM) {¶¶ [0015], [0017], [0062] mainframe server running z/OS operating system with VSAM}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which said subject matter pertains, having the teachings of Lock, Hartman, Chen and Crew before him/her, to modify the teachings of Hartman with the teachings of Crew. The motivation for doing so would combine the mainframe of Hartman with the mainframe of Crew to provide a mainframe computer with large data VSAM data stores for high-speed and high-volume input/output connections as disclosed by Crew [0017], [0021].
Claims 12 and 19 contain corresponding limitations as claim 5 and are therefore rejected for the same rationale.
Claim(s) 6, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lock et al. (U.S. Patent Application Publication No. 2016/0021064; hereinafter Lock) in view of Hartman et al. (U.S. Patent Application Publication No. 2003/0154401; hereinafter Hartman) in view of Chen et al. (U.S. Patent Application Publication No. 2022/0164351; hereinafter Chen) in view of Crew et al. (U.S. Patent Application Publication No. 2012/0144157; hereinafter Crew) and further in view of Beaumont et al. (U.S. Patent Application Publication No. 2004/0073511; hereinafter Beaumont).
Regarding claim 6, the combination of Lock, Hartman, Chen and Crew discloses the method of Claim 5, but fails to explicitly disclose wherein the client device comprises a Microsoft SQL server, and the database comprises a mapping of a plurality of I/O requests associated with Microsoft SQL with a plurality of corresponding capabilities associated with VSAM.
However, Beaumont discloses wherein the client device comprises a Microsoft SQL server, and the database comprises a mapping of a plurality of I/O requests associated with Microsoft SQL with a plurality of corresponding capabilities associated with VSAM {¶¶ [0035], [0050] client software can be Microsoft Access, SQL, DataBase II, Oracle, and the like; the customer transactional data can be stored as rules (Microsoft Access, SQL, DataBase II, Oracle, and the like) which are converted from the client software format to the format of the database/VSAM for which they will be utilized for processing}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which said subject matter pertains, having the teachings of Lock, Hartman, Chen, Crew and Beaumont before him/her, to modify the teachings of Lock with the teachings of Beaumont. The motivation for doing so would combine the mapping table of Lock with the rules database of Beaumont to provide for defining an action to be taken based on a condition upon the occurrence of an event, and storing the event, the condition, and the action as a business rule such that, upon the occurrence of the event, the action is taken with respect to accounts that satisfy the condition as disclosed by Beaumont [0009], [0010].
Claims 13 and 20 contain corresponding limitations as claim 6 and are therefore rejected for the same rationale.
Support for Amendments and Newly Added Claims
Applicants are respectfully requested, in the event of an amendment to claims or submission of new claims, that such claims and their limitations be directly mapped to the specification, which provides support for the subject matter. This will assist in expediting compact prosecution and reducing potential 35 USC § 112(a) or 35 USC § 112, 1st paragraph issues that can arise when claims are amended. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.121(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient. The examiner thanks the Applicant in advance for providing support for any amendments or newly added claims.
Examiner cites particular columns and line numbers or paragraphs in the references as applied to claims above 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 be applied as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIEDRA M MCQUITERY whose telephone number is (571)272-9607. The examiner can normally be reached Monday - Thursday, 8 am - 6 pm (C.S.T.).
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, Sanjiv Shah can be reached at (571)272-4098. 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.
/Diedra McQuitery/Primary Examiner, Art Unit 2166