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
This action is in response to the claimed listing filed on 09/25/2023.
Claims 1-20 are pending.
Claim Objections
Claim 18-20 are objected to under 37 CFR 1.75 as being a substantial duplicate of claims 7-9. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
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-3, 7-9, 10-12, 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Bhatti, US PAP, Pub. No. US 2018/0232404 A1.
As per Claim 1: Bhatti discloses,
1. A system, comprising:
one or more processors; and
one or more hardware storage devices that store instructions that are executable by the one or more processors to configure the system to (Standard computing component/element such as a computer see [0002]):
receive a client-specific dataset, the client-specific dataset being interpretable to facilitate one or more end use operations (See FIG.1, #12, ‘obtain a document containing initial instructions to transform data’: In this feature, ‘a document’ interpreted as client-specific dataset, and one or more end user operations is as JSON. And see Abstract: ‘an internal data schema with programs that adaptively expand their own set of instructions based on operation of the programs on API or IMS database responses’: facilitate one or more end use operations ), the client-specific dataset comprising at least:
a first set of interpretable code, the first set of interpretable code comprising one or more first computer-interpretable languages; and
a second set of interpretable code, the second set of interpretable code comprising one or more second computer-interpretable languages that are different from the one or more first computer-interpretable languages; and
(See [0029], see [0030] Referred to: ‘term “ initial instructions ” is used to refer to
instructions expressly encoded in the document’… ‘In some cases , the program may be characterized as being expressed in a homoiconic programming language in which the data the program operates upon includes the program itself” . See [0031] [0032] [0033]: The JSON is a first set of interpretable code , and the document contains itself another program: a second set of interpretable code)
generate a homoiconic representation of the client-specific dataset, the homoiconic representation comprising a single syntax for depicting logic components, content components, and structural components, (See [0026] ‘the document is a program composed by a developer in the format in which it was composed , i.e., in source-code format . The document may contain a plurality of ( and often more than 50 ) instructions that indicate how to transform data from an internal representation in an internal data schema to an external representation in a target external data schema, for instance , associated with a target API of a target SaaS application.’ (emphasis added), ‘the external representation in a target external schema’ reads on generate a homoiconic representation of the client-specific dataset )
the single syntax being different than syntaxes associated with the one or more first computer-interpretable languages and the one or more second computer-interpretable languages.
(See [0026] above and see Abstract ‘diverse set of target application program interfaces ( APIs ) having different respective external data schemas’: These features appear the transformation from source document such as with JASON/programs into different schemas, i.e. ‘homoiconic representation of the client-specific dataset’ in the target SaaS has the different syntax from the source document, where as shown, the source document include at least first set of interpretable code and second set of interpretable code)
As per Claim 2: Regarding,
2. The system of claim 1, wherein generating the homoiconic representation comprises:
performing a first set of parse operations on the first set of interpretable code to generate a first subset of the homoiconic representation; and
performing a second set of parse operations on the second set of interpretable code to generate a second subset of the homoiconic representation.
(See [0029]: ‘In some embodiments , the document may explicitly express ( i. e. , in source - code format ) the instructions in a hierarchical format , like in a tree format , such as an
abstract syntax tree . This is in contrast to many forms of program code where the program code must be parsed by a parser into an abstract syntax tree from the format in which the program code is stored . Some embodiments may explicitly arrange the data in the tree format in the document . This is expected to expedite operations by avoiding the need to
parse data into an abstract syntax tree’ (emphasis added): It indicates that if document in source code format, it requires parsing, if it is in AST, it was parsed)
As per Claim 3: Regarding,
3. The system of claim 1, wherein the single syntax for depicting the logic components, the content components, and the structural components contributes to a usability of the homoiconic representation as input to generate a runtime representation that is interpretable to facilitate the one or more end use operations.
(See FIG. 2, the target schema meets the runtime requirement of “third-party SaaS Application”, and see Abstract ‘transforming data exchanged between a diverse set of target application program interfaces ( APIs ) having different respective external data schemas’ (emphasis added))
As per Claim 7: Regarding,
7. The system of claim 1, wherein the one or more first computer-interpretable languages comprise one or more markup languages.
(See [0025] JSON or XML)
As per Claim 8: Regarding,
8. The system of claim 7, wherein the one or more second computer-interpretable languages comprise one or more programming languages.
(See [0029] [0030], referred to ‘program’)
As per Claim 9: Regarding,
9. The system of claim 8, wherein the homoiconic representation represents structure associated with the one or more markup languages and commands associated with the one or more programming languages with the single syntax..
(referred to [0026] as addressed to claim 1, and see [0025], such as target API, SOAP etc., of a target SaaS)
As per Claim 18: Regarding,
18. The system of claim 1, wherein the one or more first computer-interpretable languages comprise one or more markup languages.
(Duplicated from claim 7: See rationale addressed in claim 7)
As per Claim 19: Regarding,
19. The system of claim 18, wherein the one or more second computer-interpretable languages comprise one or more programming languages.
(Duplicated from claim 8: See rationale addressed in claim 8)
As per Claim 20: Regarding,
20. The system of claim 19, wherein the homoiconic representation represents structure associated with the one or more markup languages and commands associated with the one or more programming languages with the single syntax..
(Duplicated from claim 9: See rationale addressed in claim 9)
As per Claim 10: Claim 10 as given with limitations below recites the reversed limitations as recited in claim 1, that would be read on the exchange transformation addressed in Bhatti:
10. A system, comprising:
one or more processors; and
one or more hardware storage devices that store instructions that are executable by the one or more processors to configure the system to (Standard computing component/element such as a computer see [0002]):
receive a homoiconic representation of a client-specific dataset, the homoiconic representation comprising a single syntax for depicting logic components, content components, and structural components associated with the client-specific dataset that defines one or more end use operations; and generate a runtime representation using the homoiconic representation of the client-specific dataset, the runtime representation being interpretable to facilitate the one or more end use operations, wherein the runtime representation
(See Abstract: ‘The transformation process of transforming data exchanged between a diverse set of target application program interfaces ( APIs ) having different respective external data schemas and an identity management system ( IMS ) database having an internal data schema with programs that adaptively expand their own set of instructions based on operation of the programs on API or IMS database responses.’ (emphasis added)
In Claim 1 the rational is depicted to a schema transformed between source to a target that have different formats and single syntax that run by SaaS Application: The terms ‘exchange’ and ‘different’ and the illustration of FIG.2 show a reversal, and read the claimed limitation as depicted from generate a homoiconic representation step in claim 1) comprises at least:
a first set of interpretable code, the first set of interpretable code comprising one or more first computer-interpretable languages; and
a second set of interpretable code, the second set of interpretable code comprising one or more second computer-interpretable languages that are different from the one or more first computer-interpretable languages, wherein syntaxes associated with the one or more first computer-interpretable languages and the one or more second computer-interpretable languages are different than the single syntax.
(See the rationale in claim 1 in the steps: a first set of interpretable code and a second set of interpretable code)
As per Claim 11: Regarding,
11. The system of claim 10, wherein generating the runtime representation comprises performing a recursive descent transform operation using the homoiconic representation as input.
(Incorporated with the limitations of claim 10, and the rationales addressed in claim 1, see further in the loop back within #16 in FIG. 1)
As per Claim 12: Regarding,
12. The system of claim 11, wherein the single syntax for depicting the logic components, the content components, and the structural components contributes to a usability of the homoiconic representation as input to the recursive descent transform operation to generate the runtime representation.
(Incorporated with the limitations of claims 10 and 11, and the rationales addressed in claim 1, see in FIG. 1 with #12, #14, and instructions in data in #32 as usability of the homoiconic representation as input to the recursive descent transform operation to generate the runtime representation )
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.
Claims 4-6, and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatti, US PAP, Pub. No. US 2018/0232404 A1, in view of Tedder et al., US Patent US 8,700,682 B2.
As per Claim 4: Regarding,
4. The system of claim 3, wherein the one or more end use operations comprise at least a user input acquisition operation and a template generation operation.
Per above limitation, Bhatti discloses a user input acquisition operation (FIG. 1, inputs from 12, 14), but in the mechanism of FIG. 1,
Bhatti does not explicitly discloses a template generation operation. However, template is well use in any editor that is provided with markup language, that allows user to depict a template then fills the code within.
Tedder discloses a template based generation for end use operations with input acquisition operation and “a template generation operation” (See FIG. 10, #1004, # 1010, #1012)
It would be obvious to an ordinary of skills in the art before the effective filing of the application to include in the template based generation of Tedder to the end use operations of Bhatti, the combination would yield results predictable because template is well in certain editors associated with programming languages such as XML, allowing user to enter correct formats of code and assisting the user in the time saving manner.
As per Claim 5: Regarding,
5. The system of claim 4, wherein the client-specific dataset comprises one or more client-defined preferences related to end use functionality of the user input acquisition operation and the template generation operation.
Per above limitation, incorporate with the limitation of claim 5 above, Tedder discloses the template generation operation (as being incorporated in claim 4 above)
Bhatti further discloses one or more client-defined preferences related to end use functionality of the user input acquisition operation (See FIG. 1, #12, document containing initial instructions to transform data, (i.e. XML, JSON in [0025]))
It would be obvious to an ordinary of skills in the art before the effective filing of the application to further combination the template based generation of Tedder and client-defined preferences as in FIG. 1 of Bhatti. The combination would yield results predictable because template associated with user/client defined preference allowing user enter his own code with a template.
As per Claim 6: Incorporated with claim 5, with Bhatti and Tedder in combination, Bhatti discloses,
6. The system of claim 5, wherein the one or more client-defined preferences are defined according to a predefined schema (i.e. the transform data between schema. See FIG. 1 and [0010] ).
As per Claims 13-15: Claims are directed to a system having claims limitation corresponding to the limitation of claims 4-6, the rejection of the claim is applied with the same rationales addressed in claim 4 above.
As per Claim 16: Incorporated with the limitations of claims 13-15, that are addressed in combing Bhatti and Tedder, Regarding,
16. The system of claim 15, wherein end use functionality of the user input acquisition operation is constrained by a predefined data model.
Per above limitation, Bhatti discloses FIG.1 that is with of the user input acquisition operation is constrained by a predefined data model. See [0020]: ‘..program interfaces of other applications (referred to as " target applications ” to distinguish from the source application ) having differing data models represented in different data schemas’ . Thus a target of schema is predefined data model)
Allowable Subject Matter
Claim 17 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ted T Vo whose telephone number is (571)272-3706. The examiner can normally be reached 8am-4:30pm ET.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
TTV
September 6, 2025
/Ted T. Vo/
Primary Examiner, Art Unit 2191