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 action is responsive to application filed on 02 May 2025. Claims 1-24 are pending in the case. Claims 1, and 13 are the independent claims. This action is non-final.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-24 are rejected under 35 U.S.C. 103 as being unpatentable over Tran et al. (US 2022/0414115 A1) in view of Muni et al. (US 2012/0078913 A1).
Regarding claim 1, Tran teaches a system for converting a source data feed into a canonical data product, comprising:
at least one memory for storing computer-executable instructions; and at least one processor for executing the instructions stored on the at least one memory, wherein execution of the instructions programs the at least one processor to perform operations comprising (see Tran, Paragraph [0061], “A system 740 includes hardware (e.g., a set of one or more server devices) and software to provide service(s) 742, including the data movement service.”):
receiving a source data feed having a source schema (see Tran, Paragraphs [0014], [0026], “The data movement system 110 may provide a data movement service that moves data between the source systems 120 and the target systems 130. In the context of data movement, a source system is a system from which data is moved from and a target system is a system to which that data is moved to. As an example that will be used herein throughout the description to help illustrate implementations, source system 120A may be an e-Commerce system that implements a digital storefront, source system 120B may be an order management system that manages order processing and shipping, and source system 120C may be a data warehouse system that stores archived order history. … and use this information to access the source systems 120 and obtain details about the schemas 310 (e.g., the columns/fields of the respective schemas and what they represent) from the respective source systems 120.” [Source systems (i.e., a source data feed having a source schema) may be obtained (i.e., receiving).]);
identifying a plurality of data fields of the source schema (see Tran, Paragraphs [0026]-[0027], “and use this information to access the source systems 120 and obtain details about the schemas 310 (e.g., the columns/fields of the respective schemas and what they represent) from the respective source systems 120.” [The columns/fields (i.e., a plurality of data fields) may be identified about the source systems schemas.]);
assigning a data category from a plurality of predefined data categories to each data field of the plurality of data fields (see Tran, Paragraph [0032], “the mappings 320 including mappings between the schemas used by the source systems 120 and a common schema 330 (also referred to as a canonical schema). This way, a schema used by one system can be mapped to a schema used by another source system by going through the common schema 330 without having to define individual mappings between each of the schemas. A mapping 320 may include one-to-one column/field mappings and/or column/field mappings that involve more complex formula-like operations.” [The schemas may be mapped to a common schema, which involves mapping (i.e., assigning) column/fields (i.e., a data category from a plurality of predefined data categories) to the column/fields (i.e., data fields of the plurality of data fields) of the source systems schemas.]);
modifying the source schema based on predefined parameters, wherein the source schema is modified to match a target schema (see Tran, Paragraphs [0032]-[0034], “if one schema stores a person's full name (first name and last name) in a “name” field but another schema stores a person's first name and last name separately in a “firstName” and “lastName” field, then the mapping between the schemas may involve splitting the full name in the “name” field into first name and last name (e.g., using a space character as a delimiter) and storing the first name and last name in the “firstName” and “lastName” fields, respectively.” [Mapping the source systems schemas into target schemas involves splitting the full name in the name field into first name and last name (i.e., modifying the source schema based on predefined parameters).]);
However, Tran does not explicitly teach:
comparing the modified source schema to the target schema;
Muni teaches:
comparing the modified source schema to the target schema (see Muni, Paragraph [0062], “Instance mapping module 130 compares instance data of the source and target schema elements.” [The source and target schema may be compared.]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Tran (teaching system and architecture for standardizing and centralizing data movement between systems) in view of Muni (teaching system and method for schema matching), and arrived at a system that compares source and target schemas. One of ordinary skill in the art would have been motivated to make such a combination for the purposes of efficiently matching source and target schemas (see Muni, Paragraph [0005]). In addition, both the references (Tran and Muni) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as schemas. The close relation between both the references highly suggests an expectation of success.
The combination of Tran, and Muni further teaches:
and in response to a determination that the modified source schema matches the target schema, converting the source data feed to a canonical data product having the target schema based on the assigned data categories (see Tran, Paragraphs [0032], [0034], “the mappings 320 including mappings between the schemas used by the source systems 120 and a common schema 330 (also referred to as a canonical schema). ” [The source systems may convert the data into a canonical schema (i.e., canonical data product).]).
Regarding claim 2, Tran in view of Muni teaches all the limitations of claim 1. Tran further teaches:
wherein the source schema is associated with at least one financial institution (see Tran, Paragraphs [0014], [0026], “source system 120A may be an e-Commerce system that implements a digital storefront, source system 120B may be an order management system that manages order processing and shipping, and source system 120C may be a data warehouse system that stores archived order history.” [The source systems schemas may be associated with an e-Commerce system, order management system, and data warehouse system (i.e., financial institutions).]).
Regarding claim 3, Tran in view of Muni teaches all the limitations of claim 1. Tran further teaches:
wherein the canonical data product is a financial canonical data product (see Tran, Paragraph [0032], “the mappings 320 including mappings between the schemas used by the source systems 120 and a common schema 330 (also referred to as a canonical schema).” [The schemas may be mapped to a canonical schema (i.e., financial canonical data product).]).
Regarding claim 4, Tran in view of Muni teaches all the limitations of claim 1. Muni further teaches:
determining, for each data field of the plurality of data fields, a confidence level associated with the assigned data category (see Muni, Paragraph [0085], “The similarity check is performed to evaluate the syntactic and semantic similarity between the source and the target schema elements. A similarity value is calculated based on the similarity check. In an embodiment of the present invention, the similarity value is in the range of 0 to 1, wherein 0 is the similarity value between two unrelated schema elements and 1 represents the similarity value of identical schema elements.” [A similarity value (i.e., confidence level) may be determined.]).
Regarding claim 5, Tran in view of Muni teaches all the limitations of claim 4. Muni further teaches:
wherein the confidence level is represented as a percentage (see Muni, Paragraphs [0093]-[0096], “if the ‘predetermined exact match threshold value’ is 0.98, then for each set of target schema elements corresponding to source schema elements, the target schema elements with 98% or more similarity to the corresponding source schema elements may be classified as exact matches.” [The similarity value (i.e., confidence level) may be represented as a percentage.]).
Regarding claim 6, Tran in view of Muni teaches all the limitations of claim 1. Tran further teaches:
wherein identifying the plurality of data fields of the source schema includes identifying a data type of each data field of the plurality of data fields (see Tran, Paragraphs [0027]-[0031], “The data movement system 110 may use these credentials to access these systems and obtain details about the schemas from these systems.” [The details as shown in paragraphs [0028], [0029], and [0031] identify the data types of the column/fields of the source systems schema (i.e., data fields of the source schema).]).
Regarding claim 7, Tran in view of Muni teaches all the limitations of claim 6. Tran further teaches:
applying a plurality of data patterns to each data field of the plurality of data fields to identify the data type (see Tran, Paragraphs [0032]-[0034], “if one schema stores a person's full name (first name and last name) in a “name” field but another schema stores a person's first name and last name separately in a “firstName” and “lastName” field, then the mapping between the schemas may involve splitting the full name in the “name” field into first name and last name (e.g., using a space character as a delimiter) and storing the first name and last name in the “firstName” and “lastName” fields, respectively.” [Splitting the full name in the name field into first name and last name using a space character as a delimiter (i.e., applying a plurality of data patterns to each data field of the plurality of data fields to identify the data type).]).
Regarding claim 8, Tran in view of Muni teaches all the limitations of claim 7. Tran further teaches:
wherein each data pattern of the plurality of data patterns corresponds to at least one regular expression (see Tran, Paragraphs [0032]-[0034], “if one schema stores a person's full name (first name and last name) in a “name” field but another schema stores a person's first name and last name separately in a “firstName” and “lastName” field, then the mapping between the schemas may involve splitting the full name in the “name” field into first name and last name (e.g., using a space character as a delimiter) and storing the first name and last name in the “firstName” and “lastName” fields, respectively.” [Splitting the full name in the name field into first name and last name using a space character as a delimiter (i.e., at least one regular expression).]).
Regarding claim 9, Tran in view of Muni teaches all the limitations of claim 1. Tran further teaches:
wherein modifying the source schema based on predefined parameters includes modifying a name of a data field, modifying a data type of a data field, consolidating multiple data fields, or any combination thereof (see Tran, Paragraphs [0032]-[0034], “if one schema stores a person's full name (first name and last name) in a “name” field but another schema stores a person's first name and last name separately in a “firstName” and “lastName” field, then the mapping between the schemas may involve splitting the full name in the “name” field into first name and last name (e.g., using a space character as a delimiter) and storing the first name and last name in the “firstName” and “lastName” fields, respectively.” [Mapping the source systems schemas into target schemas involves splitting the full name in the name field into first name and last name (i.e., modifying a name of a data field).]).
Regarding claim 10, Tran in view of Muni teaches all the limitations of claim 9. Tran further teaches:
wherein modifying the name of the data field includes replacing at least one term in the name with at least one term from a predefined list of terms (see Tran, Paragraphs [0032]-[0034], “if one schema stores a person's full name (first name and last name) in a “name” field but another schema stores a person's first name and last name separately in a “firstName” and “lastName” field, then the mapping between the schemas may involve splitting the full name in the “name” field into first name and last name (e.g., using a space character as a delimiter) and storing the first name and last name in the “firstName” and “lastName” fields, respectively.” [Mapping the source systems schemas into target schemas involves splitting the full name in the name field into first name and last name (i.e., replacing at least one term in the name with at least one term from a predefined list of terms).]).
Regarding claim 11, Tran in view of Muni teaches all the limitations of claim 1. Muni further teaches:
evaluating, via a matching function, a match level between the modified source schema and the target schema (see Muni, Paragraph [0091], “At step 308, a list of matching source and target schema elements is obtained based on the similarity value. The matches identified are one of, but not limited to, an exact match, a highly liked match, a potential match and a non-match.” [A type of match (i.e., match level) may be determined (i.e., evaluated).]).
Regarding claim 12, Tran in view of Muni teaches all the limitations of claim 11. Muni further teaches:
comparing the match level to a minimum accuracy threshold; and in response to a determination that the match level meets or exceeds the minimum accuracy threshold, converting the source data feed to the canonical data product (see Muni, Paragraphs [0093]-[0096], “for a particular domain, if the similarity value is greater than or equal to a ‘predetermined exact match threshold value’, then the match is classified as an exact match.” [A threshold is incorporated in order to determine the type of matches between the source and target schemas.]).
Regarding claims 13-24, Tran in view of Muni teaches all of the limitations of claims 1-12, in system form rather than in method form. Tran also discloses a method [0020]. Therefore, the supporting rationale of the rejection to claims 1-12, applies equally as well to those elements of claims 13-24.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUSAM TURKI SAMARA whose telephone number is (571)272-6803. The examiner can normally be reached on Monday - Thursday, Alternate Fridays.
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, Apu Mofiz can be reached on (571)-272-4080. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
HUSAM TURKI SAMARA/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161