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 .
DETAILED ACTION
1. The pending claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 103
2. 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.
3. 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.
4. 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.
5. 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.
6. Claims 1-5, 7-12 and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Wilshinsky et al (US 20210173854 A1, hereinafter “Wilshinsky”) in view of TSERKOVNY et al (U.S. 20090154699 A1 hereinafter, “TSERKOVNY”), and further in view of DORAIRAJAN et al (U.S. 20170242863 A1 hereinafter, “DORAIRAJAN”), and further in view of TROTTER (U.S. 20180336554 A1 hereinafter, “TROTTER”).
7. With respect to claim 1,
Wilshinsky discloses a system comprising:
a processor; and
a non-transitory computer-readable medium comprising instructions that are executable by the processor to cause the processor to perform operations comprising:
generating a set of enriched files (Wilshinsky [0013] – [0014], [0064], [0121] e.g. translated) by:
generating a set of entity (Wilshinsky [0002], [0056] – [0058] and Fig. 1 e.g. entity – organization, company) functions (Wilshinsky [0013] – [0014], [0170] – [0171], [0182] e.g. functions), a set of user (Wilshinsky [0013] – [0014], [0056] – [0057] e.g. user, person, personal) functions (Wilshinsky [0013] – [0014], [0170] – [0171], [0182] e.g. functions), and a set of direct updates based on a set of input files (Wilshinsky [0013] – [0014], [0182] e.g. the function for importing and update data 194), wherein each user function of the set of user functions comprises user parameters (Wilshinsky [0046], [0056] e.g. location, name of user); and
generating one or more simple object access protocol (SOAP) requests (Wilshinsky [0013] – [0014], [0182] e.g. the function for importing and update data 194) and one or more structured query language (SQL) queries based on the set of entity functions, the set of user functions, and the set of direct updates (Wilshinsky [0075], [0184], [0188] – [0189], [0357] e.g. [0075] In some embodiments, the system may perform a query of a particular PIIMAP on the fly(known herein as a “Pre Tagged” method) even though the value of the assumed monthly mortgage payment is not known. [0111] In some embodiments, the logic layer processor 40 of the server 15 may execute software modules stored in the memory 50 to perform the functions of the system 1 described herein. The software modules may include a self-aggregation data module 41 for collecting and aggregating PII data from the user 10 from the plurality of electronic resources 20A, 20B, and 20C denoted ER1, ER2,. . . ERQ, a PII classifier module 42 for classifying the PII data of the user 10 into types and/or classes of PII data, an artificial intelligence (AI), algorithm, and/or set of rules module 43 for transforming the PII data of the user, a data structure manager module 44 for building, updating and maintaining a data structure 6 and/or a PII MAP 5 of the user 10 based on the PII data of the user 10, a plurality of data management software functions 45 for using the PII data and the PII MAP 5 of the user 10 to perform many of the data management software functions described herein, a graphical user interface (GUI)manager 47 for controlling the GUI 70 and/or the YP platform 80 running on the computing device 65of the user 10, and/or an application programming interface (API) manager 48. [0357] the exemplary DBMS-managed database may be specifically programmed to provide the ability to query, backup and replicate, enforce rules, provide security, compute, perform change and access logging, and/or automate optimization. … SQL), and wherein the one or more SQL queries are based at least in part on the set of direct updates (Wilshinsky [0075], [0184], [0188] – [0189], [0357] e.g. [0075] In some embodiments, the system may perform a query of a particular PIIMAP on the fly (known herein as a “Pre Tagged” method) even though the value of the assumed monthly mortgage payment is not known. [0111] In some embodiments, the logic layer processor 40 of the server 15 may execute software modules stored in the memory 50 to perform the functions of the system 1 described herein. The software modules may include a self-aggregation data module 41 for collecting and aggregating PII data from the user 10 from the plurality of electronic resources 20A, 20B, and 20C denoted ER1, ER2,. . . ERQ, a PII classifier module 42 for classifying the PII data of the user 10 into types and/or classes of PII data, an artificial intelligence (AI), algorithm, and/or set of rules module 43 for transforming the PII data of the user, a data structure manager module 44 for building, updating and maintaining a data structure 6 and/or a PII MAP 5 of the user 10 based on the PII data of the user 10, a plurality of data management software functions 45 for using the PII data and the PII MAP 5 of the user 10 to perform many of the data management software functions described herein, a graphical user interface (GUI)manager 47 for controlling the GUI 70 and/or the YP platform 80 running on the computing device 65of the user 10, and/or an application programming interface (API) manager 48. [0357] the exemplary DBMS-managed database may be specifically programmed to provide the ability to query, backup and replicate, enforce rules, provide security, compute, perform change and access logging, and/or automate optimization. … SQL);
generating a validated (Wilshinsky [0045] – [0048] e.g. validated) set of enriched files (Wilshinsky [0013] – [0014], [0064], [0121] e.g. translated), and
initiating an automatic update of a target database by transmitting the validated set of enriched files to the target database that is compatible (Wilshinsky [0024], [0299] e.g. a standardized predefined data schema - compatible, compatibility) with a format of the validated set of enriched files.
Although Wilshinsky substantially teaches the claimed invention, Wilshinsky does not explicitly indicate wherein a first SOAP request includes the set of entity functions and a second SOAP request includes the set of user functions.
TSERKOVNY teaches the limitations by stating wherein a first SOAP request includes the set of entity functions and a second SOAP request includes the set of user functions (TSERKOVNY [0019], [0026], [0043], [0065] e.g. [0019] DEB 150 may also provide delivery related functions and system related functions associated with managing data exchange in network 200. The delivery related functions may include, for example, security related processing, message validation, transport and routing of messages, ensuring quality of service (QoS), non-repudiation services, providing and/or facilitating service level agreements (SLAs), ensuring that communication sessions meet QoS requirements and SLAs, transformation and mapping of different protocols for compatibility and compliance with various standards and protocols and other delivery related functions. [0026] Provider 250 and consumer 260 may correspond to two of participants 110-140 illustrated in FIG. 1. In an exemplary implementation, provider 250 may be a data exchange endpoint entity that hosts various elements related to business functions and generates and/or provides digital data for exchange. Consumer 260 may be a data exchange endpoint entity that receives digital data from provider 250 via proxies 220 and 222 and uses the particular digital data of a provider to satisfy specific business needs. [0043] Data exchange model 500 may further include Service Offerings object 530 that includes a set of delivery functions that a consumer (e.g., consumer 260) may use and a provider (e.g., provider 250) may supply in order for a data exchange to occur. [0065] DEB 150 may receive the request and process the request (act 740). For example, DEB 150 may perform security-related processing, validation-related processing, compatibility-related processing, etc., on the request to ensure the validity of the request and that the request will be in a format compatible with the provider. DEB 150 may then initiate a business transaction with a data exchange endpoint entity associated with the selected Web service (act 740). …. DEB 150 may create and send a SOAP message request to provider 250. The SOAP message may include information associated with the request, such as an identification of consumer 260, type of information requested, etc. Provider 250 may then provide data in response to the message/request [as wherein a first SOAP (e.g. SOAP) request includes the set of entity (e.g. entity) functions (e.g. functions) and a second SOAP request includes the set of user (e.g. consumer) functions (e.g. functions)]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Wilshinsky and TSERKOVNY, to reduces the cost of the Enterprise's compliance with PII related regulations, which benefits both the consumer and Enterprises in a broad scope of industry sectors that use consumer PII (Wilshinsky [0012]).
Although Wilshinsky and TSERKOVNY combination substantially teaches the claimed invention, they do not explicitly indicate determining that a subset of the set of enriched files has an error; and removing the subset from the set of enriched files to generate the validated set of enriched files.
DORAIRAJAN teaches the limitations by stating
generating a validated by:
determining that a subset of the set of enriched files has an error; and
removing the subset from the set of enriched files to generate the validated set of enriched files (DORAIRAJAN claim 1 and [0063], [0074], [0116] e.g. 1. A method for generating a submittal register via a processing device, the method comprising: receiving a first file in a first format; converting the first file to a first file converted format; removing conversion errors from the first file in the first file converted format; applying an algorithm to the first file in the first file converted format to produce a second file; running a quality control check of the second file; applying a processing program to the second file; generating the submittal register based on the applied processing program to the second file; and presenting the final submittal register. [0063] FIG. 51 shows the example GUI screen of FIG. 50 with the upload completed and an option to validate provided. [0074] At step 105, the reviewer receives the documents (also interchangeably referred to herein as “specifications”) and validates the contents based on expertise. At step 110, the same or a different reviewer reviews in detail the documents received. [0116] Once file upload is completed, as shown in FIG. 50, the selection 5000 can be made, and the option to validate 5100 the uploaded files may be selected, as shown in FIG. 51. Once validation is completed, as shown in FIG. 52, a selection to generate submittals 5200 may be made. FIG. 53 shows an example GUI screen that may appear upon completion of the Submittals Registration [as generating a validated set of enriched files by:
determining that a subset (e.g. conversion error) of the set of enriched files (e.g. the first file in the first file converted format) has an error (e.g. error); and
removing the subset (e.g. removing conversion error from the first file in the first file converted format) from the set of enriched files to generate the validated (e.g. validate; validation) set of enriched files]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Wilshinsky, TSERKOVNY and DORAIRAJAN, to reduces the cost of the Enterprise's compliance with PII related regulations, which benefits both the consumer and Enterprises in a broad scope of industry sectors that use consumer PII (Wilshinsky [0012]).
Although Wilshinsky, TSERKOVNY and DORAIRAJAN combination substantially teaches the claimed invention, they do not explicitly indicate user parameters including an indication of whether a corresponding user is a single-sign-on (SSO) user or a non-SSO user.
TROTTER teaches the limitations by stating wherein each user function of the set of user functions comprises user parameters including an indication of whether a corresponding user is a single-sign-on (SSO) user or a non-SSO user (TROTTER [0046], [0156] – [0160], [0249] – [0251], claim 10 e.g. single sign-on; The Federated Identity System allows for a single sign-on system that permits a single user authentication process across multiple Information Technology systems or organizations at a policy level. [0156] – [0160], [0249] – [0251], claim 10: location).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Wilshinsky, TSERKOVNY, DORAIRAJAN and TROTTER, to reduces the cost of the Enterprise's compliance with PII related regulations, which benefits both the consumer and Enterprises in a broad scope of industry sectors that use consumer PII (Wilshinsky [0012]).
8. With respect to claim 2,
Wilshinsky further discloses
receiving a set of input files from an initial database that comprises data in a first format (Wilshinsky [0013] – [0014], [0064], [0121] e.g. particular data schema); and
determining that the set of input files is nonconforming to a standard associated with a second format that is different than the first format, wherein a target database is configured to store files in the second format (Wilshinsky [0009], [0064], [0067], [0094], [0121], [0122], [0129] e.g. When data needs to be exported to a particular schema, YP may export or translate the data to any standardized predefined data schema).
9. With respect to claim 3,
Wilshinsky further discloses wherein the system and the target database are associated with a first entity, and wherein the initial database is associated with a second entity that is included in a subset of the first entity (Wilshinsky [0002], [0056] – [0058] and Fig. 1 e.g. individual Electric Resource (ER) 1 to Q vs. USER 1-N in Fig.1 – individual vs. group of people [0057] In some embodiments, an entity may include any individual, group of people, non-profit organization, governmental organization, corporation, liability limited corporation (LLC), sole proprietor, and/or foreign entity that provides products and/or services as well as advice, governmental benefits, social benefits, third party benefits, for example. [0058] In some embodiments, the entity may also include a provider user, who may be an approved provider in the marketplace, such as consumer enterprises. The entity may also include commercial users that may not be in the market place, but either may receive a data export and/or a qualified/targeted lead via an API or the YOURPII, such as to automatically fill out the online form for the consumer, for example. In other embodiments, a data export may include a qualified/targeted lead.).
10. With respect to claim 4,
Wilshinsky further discloses wherein the operation of generating the set of enriched files comprises enriching the set of input files (Wilshinsky [0013] – [0014], [0064], [0121] e.g. translated) in response to determining that the set of input files is nonconforming.
11. With respect to claim 5,
Wilshinsky further discloses wherein each user function of the set of user functions comprises user parameters including a user name (Wilshinsky [0046], [0056] e.g. location, name of user) or number of a corresponding user, and a location (Wilshinsky [0046], [0056] e.g. location, name of user) associated with the corresponding user.
TROTTER further discloses a user rule set or access level of the corresponding user (TROTTER [0088], [0097] – [0099] e.g. level of access).
12. With respect to claim 7,
Wilshinsky further discloses wherein each entity function of the set of entity functions comprises entity parameters including an entity name (Wilshinsky [0056] e.g. name of entity) or number of a corresponding entity, an account name or number (Wilshinsky [0056] e.g. online accounts pertaining to the specified user) of the corresponding entity, a location (Wilshinsky [0046] e.g. location) associated with the corresponding entity, and a location corresponding to the account name or number of the corresponding entity (Wilshinsky [0052] – [0053] e.g. account … location).
13. Claims 8-12 and 14 are same as claims 1-5 and 7 and are rejected for the same reasons as applied hereinabove.
14. Claims 15-19 are same as claims 1-5 and are rejected for the same reasons as applied hereinabove.
15. Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wilshinsky in view of TSERKOVNY, and further in view of DORAIRAJAN, and further in view of TROTTER, and further in view of Sanders et al (U.S. 20030158811 A1 hereinafter, “Sanders”).
16. With respect to claim 6,
TSERKOVNY discloses validating the one or more SOAP requests by determining whether any error exists in the one or more SOAP requests and whether the set of entity functions or the set of user functions have a format that is incompatible with the format (TSERKOVNY [0065] e.g. [0065] DEB 150 may receive the request and process the request (act 740). For example, DEB 150 may perform security-related processing, validation-related processing, compatibility-related processing, etc., on the request to ensure the validity of the request and that the request will be in a format compatible with the provider. DEB 150 may then initiate a business transaction with a data exchange endpoint entity associated with the selected Web service (act 740). For example, assume that provider 250 is associated with the selected Web service. DEB 150 may create and send a SOAP message request to provider 250. The SOAP message may include information associated with the request, such as an identification of consumer 260, type of information requested, etc. Provider 250 may then provide data in response to the message/request).
Although Wilshinsky, TSERKOVNY, DORAIRAJAN and TROTTER combination substantially teaches the claimed invention, they do not explicitly indicate
validating the one or more SQL queries by determining whether the one or more SQL queries includes any error; and
in response to determining that the one or more SOAP requests is invalid, transmitting a negative notification to a user of the system and preventing the target database from being updated with the one or more SOAP requests; or
in response to determining that the one or more SOAP requests is valid, transmitting a positive notification to the user of the system and allowing the target database to be updated with the one or more SOAP requests.
Sanders teaches the limitations by stating
validating the one or more SQL queries by determining whether the one or more SQL queries includes any error (Sander [0050], [0123] – [0129] e.g. [0050] Microsoft SQL 7. [0123] Accept SOAP requests [0124] Allow for posted information from other Web Sites [0125] Allow other Web Sites to setup recurring transactions. [0126] Call CtransactionBz if Single transaction [0127] Call CrecurrSetupBz if Recurring transaction [0128] Return query string successful (if validated or transacted) [0129] Return query string containg errors (if not validated or not transacted)); and
in response to determining that the one or more SOAP requests is invalid, transmitting a negative notification to a user of the system and preventing the target database from being updated with the one or more SOAP requests; or
in response to determining that the one or more SOAP requests is valid, transmitting a positive notification to the user of the system and allowing the target database to be updated with the one or more SOAP requests (Sander [0050], [0123] – [0129] e.g. [0050] Microsoft SQL 7. [0123] Accept SOAP requests [0124] Allow for posted information from other Web Sites [0125] Allow other Web Sites to setup recurring transactions. [0126] Call CtransactionBz if Single transaction [0127] Call CrecurrSetupBz if Recurring transaction [0128] Return query string successful (if validated or transacted) [0129] Return query string containg errors (if not validated or not transacted)).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Wilshinsky, TSERKOVNY, DORAIRAJAN, TROTTER and Sanders, to reduces the cost of the Enterprise's compliance with PII related regulations, which benefits both the consumer and Enterprises in a broad scope of industry sectors that use consumer PII (Wilshinsky [0012]).
17. Claim 13 is same as claim 6 and is rejected for the same reasons as applied hereinabove.
18. Claim 20 is same as claim 6 and is rejected for the same reasons as applied hereinabove.
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure.
19. The examiner requests, in response to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
20. When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the reference cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SyLing Yen whose telephone number is 571-270-1306. The examiner can normally be reached on Mon-Fri 8:30am - 5:00pm.
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 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.
/SYLING YEN/Primary Examiner, Art Unit 2166
January 6, 2026