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 .
This communication is in response to the application filed on 05/01/2025. Claims 1-20 are currently pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/01/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-20 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 1 and 18 recite the limitation “controlling the flow of input data to the second computer system based on the determination” in the last line. There is insufficient antecedent basis for this limitation in the claim. Other claims are rejected due to dependency on either claim 1 or 18.
Claim interpretation
Claim 18 limitation of this application is given a broadest reasonable interpretation (BRI) under 112(f) because of recitation of “input transformation engine configured to receive a set of data”, “a core which is configured to determine whether the set of input data is valid”, and content checking device is further configured to control the flow of input data…in claim 18 and
“each verification engine is configured to process a respective data portion… in claim 20.
PRONG 1: The use of the term configured to with a functional language indicates a presumption that applicant intends to invoke 112(f).
In this case the limitation “input transformation engine configured to receive a set of data”, “a core which is configured to determine whether the set of input data is valid”, and
content checking device is further configured to control the flow of input data
that appear in claim 18 and
“each verification engine is configured to process a
respective data portion… in claim 20 establish the applicant presumption to invoke 112(f).
PRONG 2: These nonce terms (input transformation engine and a core) are modified by functional language:
“input transformation engine configured to receive a set of data”
“a core which is configured to determine whether the set of input data is valid”
“content checking device is further configured to control the flow of input data…”
“each verification engine is configured to process a respective data portion…”
This prong also establishes the applicant presumption to invoke 112(f).
PRONG 3: Applicant does not recite sufficient structure, material or acts in the claim to entirely perform the recited functions of:
“receive a set of data”
“determine whether the set of input data is valid”
“control the flow of input data…”
“process a respective data portion…”
However, 112(f) is not invoked on the application because applicant recites enough structure to perform the aforementioned functions in FIG. 1 that comprises all the devices including gateway 104, the clients, and transaction processors to execute the method, and wherein the input transformation engine comprises of hardware core and FIGs. 5-7 show the structure of the core. Also, paragraphs 48 and 54 disclose implementation of the input transformation engine and the core in hardware, and paragraph 70 specifically discloses the use of hardware data diode by the transformation engine to implement its functionality. The disclosure in paragraph 105 of applicant specification states that verification engines 400, 401, 402, 403, 404, 405, 406 that are implemented in hardware as programmable logic on an FPGA(s) and/or baked into silicon as an ASIC(s).
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.
Claims 1-4, 8-10, 12, 14-17, and 18-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US. PGPub. No. 20070005613 to Singh et al (hereinafter Singh).
Regarding claim 1, Singh discloses a method (FIG. 2) to be used in a content checking (¶0058, “Security manager 206 is configured to provide security features for the transactions. For example, security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc…”) device (¶0055, “…gateway 104…”) for checking data (¶0058, “…security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc…”) transmitted from a first computer system to a second computer system (¶0043, “Gateway 104 includes a system configured to receive transactions from clients 102 and to route the transactions to transaction processors 108 through networks 106…”), wherein the method comprises:
receiving a set of input data from the first computer system, wherein the set of input data is received in a first format (¶0056, “Request handlers 202 are configured to receive transactions from clients 102. Clients 102 may send transactions in different protocols and formats…”);
transforming the set of input data from the first format to an intermediate format which is known to the content checking device (¶0007, “…The engine converts the messages in different formats into a common format, and the common format message is then processed by a business service application…”), wherein the intermediate format has a canonical data structure (¶0007, “…The common format is a canonical message format that is referred to as an internal message format…”) comprising a set of unambiguous serialised data portions (¶0056-¶0057, “Request handlers 202 are configured to receive transactions from clients 102. Clients 102 may send transactions in different protocols and formats, such as hypertext transfer protocol (HTTP), file transfer protocol (FTP), extensive markup language (XML), ISO 8583 standards, etc. Request handlers 202 provide an interface for transactions sent in various protocols and formats, and provide the transactions to inbound message stream parser 204…Inbound message stream parser 204 is configured to receive a transaction from request handlers 202 and convert the request into a canonical form. Inbound message stream parser 204 can receive messages in different formats and process those requests into a canonical format that can then be processed by other components of gateway 104…”), (FIG. 2, step 204, wherein the plurality of transactions received in parallel which are distinguishable from each other are canonical converted into a common inbound message. The canonical conversion of distinguishable transactions in parallel is an indication of an unambiguous serialized data portion);
determining whether the set of input data is valid by comparing a data portion to reference data for that data portion (¶0058, “Security manager 206 is configured to provide security features for the transactions. For example, security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc. may be provided…”, wherein file integrity fundamentally entails comparing a file’s current status against a trusted reference point to verify that the file has not been altered, corrupted, or tampered with); and
controlling the flow of input data to the second computer system based on the determination (¶0058, “…The pluggable authentication and authorization feature provides a standard interface for authentication and authorization and hence allows newer methods of authentication and access control to be added without impacting existing methods…”), see also ¶0065, “…The flow specification is the sequence of services that determines how the incoming message is handled. Each service is a software application code that performs a specific function. New services and flow specifications can be loaded dynamically to gateway 104.”).
Regarding claim 18, Singh discloses a content checking device (¶0040, FIG. 1, “system 100”), comprising:
an input transformation engine (¶0043, “Gateway 104”) configured to receive a set of input data from a first computer system in a first format (¶0056, “Request handlers 202 are configured to receive transactions from clients 102. Clients 102 may send transactions in different protocols and formats…”); and
transform the set of input data from the first format to an intermediate format which is known to the content checking device (¶0007, “…The engine converts the messages in different formats into a common format, and the common format message is then processed by a business service application…”), wherein the intermediate format has a canonical data structure (¶0007, “…The common format is a canonical message format that is referred to as an internal message format…”) comprising a set of unambiguous serialised data portions (¶0056-¶0057, “Request handlers 202 are configured to receive transactions from clients 102. Clients 102 may send transactions in different protocols and formats, such as hypertext transfer protocol (HTTP), file transfer protocol (FTP), extensive markup language (XML), ISO 8583 standards, etc. Request handlers 202 provide an interface for transactions sent in various protocols and formats, and provide the transactions to inbound message stream parser 204…Inbound message stream parser 204 is configured to receive a transaction from request handlers 202 and convert the request into a canonical form. Inbound message stream parser 204 can receive messages in different formats and process those requests into a canonical format that can then be processed by other components of gateway 104…”), (FIG. 2, step 204, wherein the plurality of transactions received in parallel which are distinguishable from each other are canonical converted into a common inbound message. The canonical conversion of distinguishable transactions in parallel is an indication of an unambiguous serialized data portion); and
a core which is configured to determine whether the set of input data is valid by comparing a data portion to reference data (¶0058, “Security manager 206 is configured to provide security features for the transactions. For example, security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc. may be provided…”, wherein file integrity fundamentally entails comparing a file’s current status against a trusted reference point to verify that the file has not been altered, corrupted, or tampered with);
wherein the content checking device is further configured to control the flow of input data to the second computer system based on the determination (¶0058, “…The pluggable authentication and authorization feature provides a standard interface for authentication and authorization and hence allows newer methods of authentication and access control to be added without impacting existing methods…”), see also ¶0065, “…The flow specification is the sequence of services that determines how the incoming message is handled. Each service is a software application code that performs a specific function. New services and flow specifications can be loaded dynamically to gateway 104.”).
Regarding claim 2, Singh discloses the method of claim 1, wherein:
a or each serialised data portion of the set comprises header information and payload information; and comparing a data portion to reference data comprises comparing the payload information to the reference data (¶0108, “…Gateway 104 may convert inbound request payloads into a canonical internal message format. The internal message format (IMF) may then be processed by business services. The outbound message stream builder 212 converts the IMF to a response payload for sending to a transaction processor 108. Accordingly, wireless transactions may be processed by gateway 104.”, wherein the inbound request payloads typically comprise both headers and payloads.).
Regarding claim 3, Singh discloses the method of claim 1 or 2, wherein the canonical data structure is a hierarchical nodal data structure wherein each data portion corresponds to a node and one or more of the data portions are embedded within a payload of another data portion (¶0129, FIG.4B, “FIG. 14B shows the hierarchical format with object ID codes, indices to the field definitions for the fields shown in FIG. 13A. The OID allows the indexing for various fields in an IMF object 1018. Field definitions are accessed for fields in IMF object 1018 using the OID. In one embodiment, the OID is an eight-byte number that is represented by the dotted decimal representation shown. The OID for the first field is encoded as 1.0.0. Any subfields are encoded as 1.1.0, 1.2.0, and so on. The second field is encoded as 2.0.0, with any subfields encoded as 2.1.0, 2.2.0, and so on.”), (¶0136, “… FIG. 14B shows a portion of the total hierarchical object IDs for the complete set of fields in the internal message format. As can be seen, message 1010 only includes the portion of these fields that it needs”).
Regarding claim 4, Singh discloses the method of claim 1 or 2, wherein the canonical data structure is flattened in that the data portions are stored and processed independently of one another (¶0136, FIG. 14A, “FIG. 14A depicts an example of the fields used for a particular message object 1010 which includes a number of object IDs (OIDs) for different fields, OIDs 1.0.0, 1.1.0, 1.1.1, 2.0.0, 2.2.0, 4.0.0, and 4.1.0…”).
Regarding claim 8, Singh discloses the method of any preceding claim, wherein the step of determining whether the set of input data is valid by comparing a data portion to reference data is carried out by hardware (FIG. 2), (¶0166, “The present invention can be implemented in the form of control logic in software or hardware or a combination of both…”).
Regarding claim 19, Singh discloses the content checking device of claim 18, wherein the core is implemented on hardware (FIG. 2), (¶0166, “The present invention can be implemented in the form of control logic in software or hardware or a combination of both…”).
Regarding claim 9, Singh discloses the method of any preceding claim, wherein each serialised data portion comprises data having a single data type (¶0056, “Request handlers 202 are configured to receive transactions from clients 102. Clients 102 may send transactions in different protocols and formats, such as hypertext transfer protocol (HTTP), file transfer protocol (FTP), extensive markup language (XML), ISO 8583 standards, etc. Request handlers 202 provide an interface for transactions sent in various protocols and formats, and provide the transactions to inbound message stream parser 204. For example, an ISO message handler is configured to receive ISO 8583 requests from clients 102 and pass them to inbound message stream parser 204. Also, an XML message handler, an HTTP request handler, and an FTP request handler can handle XML, HTTP, and FTP messages and/or requests. Accordingly, request handlers 202 allow gateway 104 to receive messages in different protocols and formats.”), (¶0057).
Regarding claim 10, Singh discloses the method of any preceding claim, wherein comparing a data portion to reference data is performed by passing the data portion to a programmable logic verification engine that has been preconfigured to compare one or more attributes of the data portion to reference data defined for the data type (¶0057, “Inbound message stream parser 204 is configured to receive a transaction from request handlers 202 and convert the request into a canonical form. Inbound message stream parser 204 can receive messages in different formats and process those requests into a canonical format that can then be processed by other components of gateway 104. Accordingly, transaction requests in many different formats may be processed by gateway 104. Inbound message stream parser 204 also provides an extensible architecture in that new formats that may be processed by gateway 104 may be enabled. If a new format is added, the translation from the new format to the canonical format is added to inbound message stream processor 104. Thus, because the canonical format is used, changes to all components in gateway 104 are not needed when new formats are added. Rather, inbound message stream parser 204 is configured to parse a request into a canonical format that can be processed by other components of gateway 104…”), (¶0058, “Security manager 206 is configured to provide security features for the transactions. For example, security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc. may be provided…”, wherein file integrity fundamentally entails comparing a file’s current status against a trusted reference point to verify that the file has not been altered, corrupted, or tampered with).
Regarding claim 12, Singh discloses the method of any preceding claim, wherein determining whether the set of input data is valid further comprises checking that the set of input data has been correctly transformed to the intermediate format by comparing the set of input data with predefined reference data that indicates a valid data structure (¶0007, “…A parser examines the message and determines an appropriate schema for the particular format of message received. The schema is a data structure in a schema registry that includes a grammar structure for the received format as well as pointers to handlers for converting the different fields of the message into the internal message format using the grammar structure (the "grammar" can include field sequence, field type, length, character encoding, optional and required fields, etc.)...”), (¶0141, “In step 1404, the schemas found in schema definition files 1026 are validated. The schemas are validated by a number of procedures, such as verifying that the correct type of data is referred to, that the handlers identified by the schema actually exist, etc.”). see also ¶0149-¶0150.
Regarding claim 14, Singh discloses the method of any preceding claim, wherein the method comprises, in response to determining that the set of input data is valid, converting the set of input data from the intermediate format to a final format which is for use by the second computer system (¶0066, “After flow handler 210 processes the transaction in a flow, the message is sent to an outbound message stream builder 212. Builder 212 is configured to build an outbound message from a canonical format based on a message form expected by the determined transaction processor 108. Builder 212 is thus configured to generate a message in any message format based on the canonical message format…”).
Regarding claim 15, Singh discloses the method of claim 14, wherein the final format is the same as the first format (¶0066, “After flow handler 210 processes the transaction in a flow, the message is sent to an outbound message stream builder 212. Builder 212 is configured to build an outbound message from a canonical format based on a message form expected by the determined transaction processor 108. Builder 212 is thus configured to generate a message in any message format based on the canonical message format.”).
Regarding claim 16, Singh discloses the method of any preceding claim, wherein:
the content checking device (¶0040, “system 100”) comprises a processing core of programmable logic verification engines which are suitable for comparing respective data portions to reference data (FIG. 1. “Transaction processors 108”), (¶0166, “The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information-processing device to perform a set of steps disclosed in embodiment of the present invention.”); and
the reference data specifies a known or predicted number of data portions in the set of input data and the core is dynamically configured for the set of input data to activate a number of verification engines which matches the known or predicted number of data portions (¶0058, “Security manager 206 is configured to provide security features for the transactions. For example, security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc. may be provided…”, wherein file integrity fundamentally entails comparing a file’s current status against a trusted reference point to verify that the file has not been altered, corrupted, or tampered with), (¶0136, “FIG. 14A depicts an example of the fields used for a particular message object 1010 which includes a number of object IDs (OIDs) for different fields, OIDs 1.0.0, 1.1.0, 1.1.1, 2.0.0, 2.2.0, 4.0.0, and 4.1.0. These are the fields pointed to by the schema of FIG. 13B. Thus, for this example message, only the fields identified in FIG. 14C would be populated in the message object, which is shown in FIG. 13A. FIG. 14B shows a portion of the total hierarchical object IDs for the complete set of fields in the internal message format. As can be seen, message 1010 only includes the portion of these fields that it needs. For example, object IDs 1.2.0, 3.0.0 and 4.2.0 are not used.”).
Regarding claim 17, Singh in view of Eytan discloses the method of claims 10 and 11 combined, and optionally claim 16.
Singh further discloses wherein: the predefined condition is specific to a known or predicted data type of the data portion in the set of input data (¶0008, “…The root schema would point to a handler which determines what type of message has been received (e.g., authorization message, reconciliation message, etc.). The parser then loads the schema for the message type identified, which in turn provides the particular grammar and points to the handlers for that message type. Thus, the entire grammar and handlers for all types of financial messages need not be loaded, only the subset actually needed, thus limiting the memory needed and improving performance…”), (¶0124, “…the root schema would point to a handler, which is called and parses a type field to determine what type of message has been received (e.g., authorization message, reconciliation message, etc.). The parser component then looks up the schema for the message type identified, which in turn provides the particular grammar and points to handlers for that message type. Schema and handlers are looked up and called only for the fields actually present in the message…”); and a verification engine is dynamically configured for the set of input data to check whether the content of the data portion satisfies the predetermined condition which is specific to the data portion (¶0062, “Rules database 222 includes rules for determining a service for a transaction in addition to a network 106 and processor 108 to process the transaction. The rules may also express criteria for a client. For example, in order for a service to be selected, certain context information and application level content should be satisfied for the rules. Clients may provide client-specific rules that may be used to select a service for the transaction. In one example, when a transaction is received for a client 102, adaptive route selector 208 may determine a client's specified selection rules and determine a service that can handle the transaction. In order to switch the transaction to a service provider that provides the service, application level content is determined from the transaction and/or dynamic context information is determined from context information database 224. The application level content and/or context information is applied to the rules to determine a service provider that can process the transaction according to the rules…”), (¶0085-¶0090, FIGs. 5 and 14, “In step 506, rules for routing the requests for the service are generated. These rules may specify criteria that need to be satisfied based on application level content and/or the current state of the network transport environment in order for the service to be selected.”).
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 7 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20070005613 to Singh et al. (hereinafter Singh) in view of US. PGPub. No. 20150205964 to Eytan et al. (hereinafter Eytan).
Regarding claim 7, Singh discloses the method of any preceding claim, further comprising, in response to determining that the set of input data is not valid (¶0058, “Security manager 206 is configured to provide security features for the transactions. For example, security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc. may be provided…”, wherein file integrity fundamentally entails comparing a file’s current status against a trusted reference point to verify that the file has not been altered, corrupted, or tampered with): or
modifying the set of input data such that the modified set of input data is suitable for use by the second computer system (¶0139, “… If it is determined that a field that is necessary to be used is not included in a received message 1010, the field may be populated by the business services module for inclusion in the message to be built for retransmission. Thus, the "required" fields in the schema of FIG. 13B may be added to an IMF object 1018 if not included in message 1010.”).
However, Singh does not explicitly disclose discarding or ignoring the set of input data such that it is not used by the second computer system in response to determining that the set of input data is not valid;
Eytan discloses discarding or ignoring the set of input data such that it is not used by the second computer system in response to determining that the set of input data is not valid (¶0013, “…analyze the received data file with the plurality of anti-malware engines includes to analyze each data file of the batch of data files with a plurality of anti-malware engines, and to determine whether the received data file includes malware includes to determine whether each data file of the batch includes malware based on the analysis. In an embodiment, to discard the received data file includes to discard each data file of the batch in response to a determination that one or more of the data files of the batch includes malware. In another embodiment, to discard the received data file includes to discard each data file in the batch determined to include malware…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Singh to include discarding or ignoring the set of input data in response to determining that the data is not valid (contains malware) as disclosed by Eytan and be motivated in doing so in order to protect the systems and data of an organization from malware-Eytan abstract in parts.
NOTE: The above motivation also applies to claim 11
Regarding claim 11, Singh discloses the method of any preceding claim, wherein:
the reference data for a given data portion indicates a predefined condition which can be used by the content checking device to characterise the data portion as being valid or invalid (¶0057, “Inbound message stream parser 204 is configured to receive a transaction from request handlers 202 and convert the request into a canonical form…”, wherein parsing inbound message/data fundamentally entails/involves predefined conditions such as rules to convert to structured format.); and
the method comprises checking whether the content of the data portion satisfies the predetermined condition stipulated by the reference data for the data portion (¶0058, “Security manager 206 is configured to provide security features for the transactions. For example, security features such as pluggable authentication and authorization, role-based access control (RBAC), encryption, file integrity, etc. may be provided…”, wherein file integrity fundamentally entails comparing a file’s current status against a trusted reference point to verify that the file has not been altered, corrupted, or tampered with),
However, Singh does not explicitly disclose the following limitation:
and determining whether the set of input data is valid or invalid based on the result of that.
Eytan discloses determining whether the set of input data is valid or invalid based on the result of that (¶0013, “… analyze the received data file with the plurality of anti-malware engines includes to analyze each data file of the batch of data files with a plurality of anti-malware engines, and to determine whether the received data file includes malware includes to determine whether each data file of the batch includes malware based on the analysis. In an embodiment, to discard the received data file includes to discard each data file of the batch in response to a determination that one or more of the data files of the batch includes malware…”), see also ¶0014.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Singh to include discarding determining that the data is valid or not valid (contains malware) based on the analysis result as disclosed by Eytan and be motivated in doing so in order to protect the systems and data of an organization from malware-Eytan abstract in parts.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20070005613 to Singh et al. (hereinafter Singh) in view of US. PGPub. No. 20160092557 to Stojanovic et al. (hereinafter Stojanovic).
Regarding claim 13, Singh discloses the method of claim 12.
However, Singh does not explicitly disclose the following limitation:
wherein the step of comparing a data portion to reference data for that data portion is only performed on the condition that the set of input data has been correctly transformed to the intermediate format.
Stojanovic discloses wherein the step of comparing a data portion to reference data for that data portion is only performed on the condition that the set of input data has been correctly transformed to the intermediate format (¶0025, “…a method includes receiving an input data set from one or more input data sources. The input data set may be formatted into one or more columns of data. The method may include comparing the input data set to one or more reference data sets obtained from a reference source. The reference source may be a knowledge source provided by a knowledge service. The input data set may be compared to the one or more reference data sets using one or more of graph matching or semantic similarity matching…”), (¶0076, “…The transform specification may include transformation instructions that indicate how and when to perform each of the set of transforms on the data produced by profile engine 326 and the recommendation for enriching the data determined by recommendation engine 308. Examples of the atomic transformation may include, without limitation, transforms to headers, conversions, deletions, splits, joins, and repairs. The data that is transformed according to the set of transforms may undergo a series of changes, each of which results in intermediate data the data is enriched. The data generated for intermediate steps for the set of transforms may be stored in a format such as an Resilient Distributed Dataset (RDD), text, a data record format, a file format, any other format, or a combination thereof.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Singh to include comparing a data portion to reference data for that data portion is only performed on the condition that the set of input data has been correctly transformed to the intermediate format as disclosed by Stojanovic and be motivated in doing so in order to use the intermediate data format for data enrichment service-Stojanovic ¶0077.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20070005613 to Singh et al. (hereinafter Singh) in view of US. PGPub. No. 20160140196 to KOBAYASHI et al. (hereinafter KOBAYASHI).
Regarding claim 20, Singh discloses the content checking device of claim 18 or 19, wherein: the set of input data comprises plural data types and each data portion includes data of a respective one of the data types only (FIG. 2, ¶0056-¶0058, “Clients 102 may send transactions in different protocols and formats, such as hypertext transfer protocol (HTTP), file transfer protocol (FTP), extensive markup language (XML), ISO 8583 standards, etc. Request handlers 202 provide an interface for transactions sent in various protocols and formats, and provide the transactions to inbound message stream parser 204. For example, an ISO message handler is configured to receive ISO 8583 requests from clients 102 and pass them to inbound message stream parser 204. Also, an XML message handler, an HTTP request handler, and an FTP request handler can handle XML, HTTP, and FTP messages and/or requests. Accordingly, request handlers 202 allow gateway 104 to receive messages in different protocols and formats…”);
However, Singh does not explicitly disclose the following limitation:
the core comprises a plurality of verification engines; and each verification engine is configured to process a respective data portion only, by comparing the data portion to reference data for that data type only.
KOBAYASHI discloses the core comprises a plurality of verification engines (¶0034, FIG. 1, FIG. 1 is a diagram depicting one example of the processing method according to a first embodiment. In FIG. 1, a system 100 is a distributed-parallel CEP system that includes multiple engine nodes 101. In the system 100, event data generated by, for example, a sensor is transmitted to the engine nodes 101, which process the event, data, and a final result is output”); and
each verification engine is configured to process a respective data portion only, by comparing the data portion to reference data for that data type only (¶0042, “Thus, in the first embodiment, upon receiving the data 111, the engine node 101 reconstitutes only a specific portion of the data 111, compares the reconstituted specific portion to a condition for identifying a query processing subject, and determines whether to discard the data 111. In cases where the engine node 101 determines not to discard the data 111, the engine node 101 reconstitutes all the data 111, thereby reducing unnecessary deserialization”), see also the abstract.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Singh, to include each verification engine is configured to process a respective data portion only, by comparing the data portion to reference data for that data type only as disclosed by KOBAYASHI and be motivated in doing so in order to determining whether to discard the received data, based on the specific portion of the received data-KOBAYASHI abstract in parts.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20070005613 to Singh et al. (hereinafter Singh) in view of US. PGPub. No. 20160092557 to Stojanovic et al. (hereinafter Stojanovic) and further in view of US. PGPub. No. 20040255163 to Swimmer et al. (hereinafter Swimmer).
Regarding claim 5, Singh discloses the method of any preceding claim, wherein: a data portion of the set of input data comprises text string data (¶0119, “…The input message stream may also be in any of multiple encoding schemes, such as ASCII, EBCDIC, BCD, etc., and have different data types, such as numeric, string, byte-array etc.”);
However, Singh does not explicitly disclose the following limitation:
the reference data comprises one or more predefined text strings which represent banned or denied information;
comparing the data portion to the reference data comprises comparing the text string data to the predefined text string; and
the set of input data is determined to be invalid if the data portion comprises a text string that matches the predefined text string.
Stojanovic discloses the reference data comprises one or more predefined text strings which represent banned or denied information (¶0099, “the transform engine 322 can automatically generate transform scripts to repair data at the data source. Repairs may include automatically renaming columns, replacing strings or patterns within a column, modifying text case, reformatting data, etc… The transform engine 322 may also remove columns based on the data source profiles received from profile engine 326 (e.g., to remove empty columns, or columns that include information that is not desired by the user).;
comparing the data portion to the reference data comprises comparing the text string data to the predefined text string (¶0027, “…creating trigrams for the word; comparing each of the trigrams to the indexed trigram table; identifying a word in the indexed trigram table associated with a trigram that matches a first trigram in the trigrams; and storing the word in a trigram augmented data set. The method may include comparing the trigram augmented data set to the one or more reference data sets and determining a match between the trigram augmented data set and the one or more reference data sets based on the comparing. Identifying the match between the input data set and the one or more reference data sets may be performed using the match between the trigram augmented data set and the one or more reference data sets based on the comparing.”), see also ¶0158-¶0159;
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Singh to include comparing the data portion to the reference data comprises comparing the text string data to the predefined text string as disclosed by Stojanovic and be motivated in doing so in order to improve automated identification of closely related data sets having semantic similarity to the input data set-Stojanovic ¶0019 in parts.
However, the combination of Singh and Stjanovic does not explicitly disclose the following limitation:
the set of input data is determined to be invalid if the data portion comprises a text string that matches the predefined text string.
Swimmer discloses the set of input data is determined to be invalid if the data portion comprises a text string that matches the predefined text string (¶0022, “The intrusion limitation subsystem preferably comprises a pattern filter connected to the code extractor for receiving extracted malicious code strings and for identifying patterns within a processed data stream that match the extracted code strings to prevent further intrusions based on the malicious code strings…”, wherein the data is invalid because it matches malicious code string).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Singh and Stojanovic to include the set of input data is determined to be invalid if the data portion comprises a text string that matches the predefined text string as disclosed by Swimmer and be motivated in doing so in order to prevent further intrusions using said malicious code strings-Swimmer abstract in parts.
Regarding claim 6, Singh in view of Stojanovic and further in view of Swimmer discloses the method of claim 5.
Stojanovic further discloses wherein the method further comprises skipping or ignoring at least one whitespace character of the text string data when comparing the text data string to the predefined text string (¶0097, “…the recommendation engine can recommend a transform that obfuscates the entries (e.g., truncating, randomizing, or deleting, all or a portion of the entries). Other examples of transformation may include, reformatting data (e.g., reformatting a date in data), renaming data, enriching data (e.g., inserting values or associating categories with data), searching and replacing data (e.g., correcting spelling of data), change case of letter (e.g., changing a case from upper to lower case), and filter based on black list or white list terms. In some embodiments, recommendations can be tailored for particular users, such that the recommendations describe at a high level what data repairs or enrichments are available. For example, an obfuscation recommendation may indicate that the first five digits of the entries will be deleted…”), (¶0099, “the transform engine 322 can automatically generate transform scripts to repair data at the data source. Repairs may include automatically renaming columns, replacing strings or patterns within a column, modifying text case, reformatting data, etc. For example, the transform engine 322 can generate a transformation script to transform a column of dates based on a recommendation from recommendation engine 308 to modify, or convert, the formats of the dates in the column…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Singh, Stojanovic, and Swimmer to include skipping or ignoring at least one whitespace character of the text string data when comparing the text data string to the predefined text string as disclosed by Stojanovic and be motivated in doing so in order to repair data at the data source-Stojanovic ¶0099 in parts.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-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, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights