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 .
Status of Claims
In response to communications filed on 20 May 2026, claims 1, 2, 4-11, 13, 15, 16, and 18-21 are presently pending in the application, of which, claims 1, 7, and 15 are presented in independent form. The Examiner acknowledges amended claims 1, 2, 4, 6, 7, 10, 15-16, and 18-20, newly added claim 21, and cancelled claims 12 and 14. Claims 3 and 17 were previously cancelled.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 20 May 2025 has been entered.
Response to Remarks/Arguments
All objections and/or rejections issued in the previous Office Action, mailed 20 May 2026, have been withdrawn, unless otherwise noted in this Office Action.
Applicant’s arguments with respect to claims 1, 2, 4-11, 13, 15, 16, and 18-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1, 2, 4-11, 13, 15, 16, and 18-21 are rejected under 35 U.S.C. 103 as being anticipated by Borochoff, Adam et al (U.S. 2019/0324989, filed 14 February 2019 and known hereinafter as Borochoff) in view of Chheda, Mahendra, et al (U.S. 2021/0109907, filed 04 December 2020, which is a continuation of U.S. Patent 10,960,550, filed 30 March 2017, and known hereinafter as Chheda)(newly presented).
As per claim 1, Borochoff teaches a method comprising:
receiving, at a database system from a client application at a client device over a network (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a computing system including a client-side service capable of supporting interactions between a database system and a native application over a computer network.), a request for a graphical user interface (GUI) display associated with a virtual application supported by the database system (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a client mobile device to support one or more GUI displays generated or otherwise provided by a native application on a display device, where the database system includes one or more application servers that support an application platform capable of providing instances of virtual applications over the network.);
identifying, at the database system, a component of the GUI display comprising a reference to an application programming interface (API) at an external system coupled to the database system over the network (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.);
providing, by the database system over the network (e.g. Borochoff, see Figure 4, where user devices are connected to a database system over a network.), a second request to the external system that includes input parameter values for the designated version of the API at the external system using the versioned network path to retrieve (e.g. Borochoff, see Figure 7, paragraphs [0103], which discloses as well as being versioned, a data set may be immutable, where a new version of the data set corresponding to a new data set item is created for the data set in the system, pre-existing data set items of the data set are not overwritten by the new data set item. Additionally, see paragraph [0105], where a transaction (e.g. first, second third request, etc) against the data set may create a new version of the data set without deleting, removing, or modifying pre-existing data set versions.), at the database system, data from the external system over the network via the API to the external system using the versioned path (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may store or retrieve data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.); and
generating, using the data retrieved from the external system in accordance with the version designation (e.g. Borochoff, see paragraph [0109], which discloses a catalog may provide data set provenance at the transaction level of granularity, where the transformation may be performed daily after data sets and are updated daily in the context of transactions, the result being multiple versions of data sets.), a graphical representation of the component within the GUI display of the virtual application provided to the client application at the client device (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog generates the data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.).
Borochoff does not explicitly disclose identifying, at the database system, within code associated with the component of the GUI display, a version designation for the API at to the external system, using a versioning schema associated with the external system, wherein the versioning schema associated with the external system is different from a standard versioning schema associated with the database system; constructing, at the database system, a versioned path for the version designation of the API at the external system using the version designation and an integration file associated with the external system.
Chheda teaches identifying, at the database system, within code associated with the component of the GUI display (e.g. Chheda, see paragraph [0053] and Figure 6, which discloses a client may send a request to create a schema via a GUI and/or API, where the scheme manager may create or allocate space for the schema in working schema store.), a version designation for the API at to the external system, using a versioning schema associated with the external system (e.g. Chheda, see paragraphs [0055-0056], which discloses the client may submit a request to apply a schema to a hierarchical data structure, where an update may include a new version of the schema.), wherein the versioning schema associated with the external system is different from a standard versioning schema associated with the database system (e.g. Chheda, see Figure 8, which implements versioning schemas for hierarchical data structures, where storage node request handler (e.g. constructing a versioned path) to handle a request to access an object, which may identify the hierarchical data structure, the object (e.g. by including a name, identifier, or location, such as a file path), and/or information indicating the type of access request, etc., as described in paragraph [0056] and Figure 7.);
dynamically constructing, at the database system at run-time, a versioned network path for interacting (e.g. Chheda, see paragraph [0044], which discloses a schema can be applied to multiple directories, serving as a blue print for constructing and maintaining the different directories (e.g. network paths), where the schema may itself be dynamically modified so that each directory that applies the schema can apply the modified version of the schema.) with a designated version of the API at the external system using the version designation and an integration file associated with the external system (e.g. Chheda, see paragraphs [0059-0062], which discloses validation of updates to a new version of a schema may be performed when an attempt is made to apply the new version of the schema to a hierarchical data structure, where the schemas may be published or otherwise made available, where for example a copy of the new version of the schema may be stored in a public directory, file, container, or other location (e.g. versioned path) from which requests to apply the new version of the schema may be stored. Additionally, see Figure 8, which implements versioning schemas for hierarchical data structures, where storage node request handler (e.g. constructing a versioned path) to handle a request to access an object, which may identify the hierarchical data structure, the object (e.g. by including a name, identifier, or location, such as a file path), and/or information indicating the type of access request, etc., as described in paragraph [0056] and Figure 7.);
Borochoff is directed to resource dependency system and graphical user interface. Chheda is directed to versioning schemas for hierarchical data structures. Both are directed to data versioning and therefore it would have been to one of ordinary skilled in the art at the time the invention was filed to modify the teachings of Borochoff with the teachings of Chheda to include the claimed features with the motivation to improve versioning schema.
As per claim 2, the modified teachings of Borochoff with Chheda teaches the method of claim 1, wherein:
the component of the GUI display comprises a configured web component associated with the GUI display that includes the reference to the API at the external system (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a client mobile device to support one or more GUI displays generated or otherwise provided by a native application on a display device, where the database system includes one or more application servers that support an application platform capable of providing instances of virtual applications over the network.).
As per claim 4, the modified teachings of Borochoff with Chheda teaches the method of claim 1, wherein the versioning schema comprises a custom versioning schema associated with the external system that is different from a standard versioning schema associated with the database system (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses identifying the catalog that includes versioned immutable data sets, where the data sets may encompass an ordered set of conceptual data set items, where the catalog may store information about the data sets including identifying different versions of the data set and display it on a GUI).
As per claim 5, the modified teachings of Borochoff with Chheda teaches the method of claim 2, wherein generating the graphical representation of the component comprises generating a graphical representation of the configured web component using the data retrieved from the versioned path for the version designation of the API at the external system (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog generates the data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.).
As per claim 6, the modified teachings of Borochoff with Chheda teaches the method of claim 1, wherein:
dynamically constructing the versioned network path comprises generating a uniform resource locator (URL) address for an endpoint at the external system associated with the version designation for the API using the integration file (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may include sets of files that are stored in the system where the catalog may store paths or other identifiers of the set of files where the data set version corresponds to the identifier assigned to the transaction that created the data set version.); and
retrieving the data comprises the virtual application at the database system retrieving the data using the URL address to generate the graphical representation of the component within the GUI display associated with the virtual application (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may store or retrieve data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.).
As per claim 7, Borochoff teaches a method comprising:
identifying, at a database system, an action added to a region on a graphical user interface (GUI) display at a client device corresponding to an action component of a virtual application (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.), wherein the action comprises a reference to an external system coupled to the database system over a network (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a computing system including a client-side service capable of supporting interactions between a database system and a native application over a computer network.);
identifying, at the database system, a plurality of different versions associated with the action based at least in part on an integration file associated with the external system at the database system (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses identifying the catalog that includes versioned immutable data sets, where the data sets may encompass an ordered set of conceptual data set items, where the catalog may store information about the data sets including identifying different versions of the data set and display it on a GUI);
providing, by the database system over the network (e.g. Borochoff, see Figure 4, where user devices are connected to a database system over a network.), a second request to the external system that includes input parameter values for the designated version of the API at the external system using the versioned network path to retrieve (e.g. Borochoff, see Figure 7, paragraphs [0103], which discloses as well as being versioned, a data set may be immutable, where a new version of the data set corresponding to a new data set item is created for the data set in the system, pre-existing data set items of the data set are not overwritten by the new data set item. Additionally, see paragraph [0105], where a transaction (e.g. first, second third request, etc) against the data set may create a new version of the data set without deleting, removing, or modifying pre-existing data set versions.), at the database system, data from the external system over the network via the API to the external system using the versioned path (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may store or retrieve data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.);
populating, by the database system, a GUI element within the GUI display at the client device with the plurality of different versions associated with the action using the integration file (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may include sets of files that are stored in the system where the catalog may store paths or other identifiers of the set of files where the data set version corresponds to the identifier assigned to the transaction that created the data set version.);
identifying, at the database system, a version designation of the plurality of different versions via the GUI element (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.);
automatically generating, at the database system, configured code for the action component comprising indication of the version designation for the reference to the external system (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may store or retrieve data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.); and
updating code for a web page associated with the virtual application to include a second reference to the action component (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog generates the data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.).
Borochoff does not explicitly disclose identifying, at the database system, within code associated with the component of the GUI display, a version designation for the API at to the external system, using a versioning schema associated with the external system, wherein the versioning schema associated with the external system is different from a standard versioning schema associated with the database system; constructing, at the database system, a versioned path for the version designation of the API at the external system using the version designation and an integration file associated with the external system.
Chheda teaches identifying, at the database system, a version designation for the API at to the external system, via the GUI element (e.g. Chheda, see paragraphs [0055-0056], which discloses the client may submit a request to apply a schema to a hierarchical data structure, where an update may include a new version of the schema. See further paragraph [0053] and Figure 6, which discloses a client may send a request to create a schema via a GUI and/or API, where the scheme manager may create or allocate space for the schema in working schema store.)), wherein the versioning schema associated with the external system is different from a standard versioning schema associated with the database system (e.g. Chheda, see Figure 8, which implements versioning schemas for hierarchical data structures, where storage node request handler (e.g. constructing a versioned path) to handle a request to access an object, which may identify the hierarchical data structure, the object (e.g. by including a name, identifier, or location, such as a file path), and/or information indicating the type of access request, etc., as described in paragraph [0056] and Figure 7.);
wherein the virtual application is configurable to construct a versioned path for the version designation of the API at the external system using the version designation and an integration file associated with the external system (e.g. Chheda, see paragraphs [0059-0062], which discloses validation of updates to a new version of a schema may be performed when an attempt is made to apply the new version of the schema to a hierarchical data structure, where the schemas may be published or otherwise made available, where for example a copy of the new version of the schema may be stored in a public directory, file, container, or other location (e.g. versioned path) from which requests to apply the new version of the schema may be stored. Additionally, see Figure 8, which implements versioning schemas for hierarchical data structures, where storage node request handler (e.g. constructing a versioned path) to handle a request to access an object, which may identify the hierarchical data structure, the object (e.g. by including a name, identifier, or location, such as a file path), and/or information indicating the type of access request, etc., as described in paragraph [0056] and Figure 7.).
Borochoff is directed to resource dependency system and graphical user interface. Chheda is directed to versioning schemas for hierarchical data structures. Both are directed to data versioning and therefore it would have been to one of ordinary skilled in the art at the time the invention was filed to modify the teachings of Borochoff with the teachings of Chheda to include the claimed features with the motivation to improve versioning schema.
As per claim 8, the modified teachings of Borochoff with Chheda teaches the method of claim 7, wherein identifying the version designation comprises identifying a user configuration of the GUI element on the GUI display corresponding to the version designation of the plurality of different versions (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.).
As per claim 9, the modified teachings of Borochoff with Chheda teaches the method of claim 8, wherein:
populating the GUI element comprises populating a drop-down menu GUI element with an ordered listing of the plurality of different versions using a respective version associated with a respective version of the plurality of different versions according to an ordering defined at the external system within the integration file (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may include sets of files that are stored in the system where the catalog may store paths or other identifiers of the set of files where the data set version corresponds to the identifier assigned to the transaction that created the data set version.); and
identifying the user configuration comprises identifying the respective version selected by a user of the client device within the ordered listing via the drop-down menu GUI element (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses identifying the catalog that includes versioned immutable data sets, where the data sets may encompass an ordered set of conceptual data set items, where the catalog may store information about the data sets including identifying different versions of the data set and display it on a GUI).
As per claim 10, the modified teachings of Borochoff with Chheda teaches the method of claim 9, wherein:
automatically generating the configured code comprises generating a configured action web component comprising the indication of the version designation for API at the external system (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.).
As per claim 11, the modified teachings of Borochoff with Chheda teaches the method of claim 10, wherein updating the code for the web page comprises updating the code for the web page to incorporate the configured action web component (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.).
As per claim 13, the modified teachings of Borochoff with Chheda teaches the method of claim 7, wherein populating the GUI element comprises populating a drop-down menu GUI element with an ordered listing of the plurality of different versions using respective versions of the plurality of different versions according to an ordering defined at the external system within the integration file (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog generates the data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.).
As per claim 15, Borochoff teaches a non-transitory machine-readable storage medium that provides instructions that, when executed by a processor, are configurable to cause the processor to perform operations comprising:
receiving, at a database system from a client application at a client device over a network (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a computing system including a client-side service capable of supporting interactions between a database system and a native application over a computer network.), a request for a graphical user interface (GUI) display associated with a virtual application supported by the database system (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a client mobile device to support one or more GUI displays generated or otherwise provided by a native application on a display device, where the database system includes one or more application servers that support an application platform capable of providing instances of virtual applications over the network.);
identifying, at the database system, a component of the GUI display comprising a reference to an application programming interface (API) at an external system coupled to the database system over the network (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.);
retrieving, at the database system, data from the external system over the network in accordance with the version designation for the API to the external system using the versioned path (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may store or retrieve data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.); and
providing, by the database system over the network (e.g. Borochoff, see Figure 4, where user devices are connected to a database system over a network.), a second request to the external system that includes input parameter values for the designated version of the API at the external system using the versioned network path to retrieve (e.g. Borochoff, see Figure 7, paragraphs [0103], which discloses as well as being versioned, a data set may be immutable, where a new version of the data set corresponding to a new data set item is created for the data set in the system, pre-existing data set items of the data set are not overwritten by the new data set item. Additionally, see paragraph [0105], where a transaction (e.g. first, second third request, etc) against the data set may create a new version of the data set without deleting, removing, or modifying pre-existing data set versions.), at the database system, data from the external system over the network via the API to the external system using the versioned path (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog may store or retrieve data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.);
generating, using the data retrieved from the external system in accordance with the version designation, a graphical representation of the component within the GUI display of the virtual application provided to the client application at the client device (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses the catalog generates the data sets including the different versions to the external system, based on the stored paths or other identifiers used to identify the different data set version of the set of files.).
Borochoff does not explicitly disclose identifying, at the database system, within code associated with the component of the GUI display, a version designation for the API at to the external system, using a versioning schema associated with the external system, wherein the versioning schema associated with the external system is different from a standard versioning schema associated with the database system; constructing, at the database system, a versioned path for the version designation of the API at the external system using the version designation and an integration file associated with the external system.
Chheda teaches identifying, at the database system, a version designation for the API at to the external system, via the GUI element (e.g. Chheda, see paragraphs [0055-0056], which discloses the client may submit a request to apply a schema to a hierarchical data structure, where an update may include a new version of the schema. See further paragraph [0053] and Figure 6, which discloses a client may send a request to create a schema via a GUI and/or API, where the scheme manager may create or allocate space for the schema in working schema store.)), wherein the versioning schema associated with the external system is different from a standard versioning schema associated with the database system (e.g. Chheda, see Figure 8, which implements versioning schemas for hierarchical data structures, where storage node request handler (e.g. constructing a versioned path) to handle a request to access an object, which may identify the hierarchical data structure, the object (e.g. by including a name, identifier, or location, such as a file path), and/or information indicating the type of access request, etc., as described in paragraph [0056] and Figure 7.);
wherein the virtual application is configurable to construct a versioned path for the version designation of the API at the external system using the version designation and an integration file associated with the external system (e.g. Chheda, see paragraphs [0059-0062], which discloses validation of updates to a new version of a schema may be performed when an attempt is made to apply the new version of the schema to a hierarchical data structure, where the schemas may be published or otherwise made available, where for example a copy of the new version of the schema may be stored in a public directory, file, container, or other location (e.g. versioned path) from which requests to apply the new version of the schema may be stored. Additionally, see Figure 8, which implements versioning schemas for hierarchical data structures, where storage node request handler (e.g. constructing a versioned path) to handle a request to access an object, which may identify the hierarchical data structure, the object (e.g. by including a name, identifier, or location, such as a file path), and/or information indicating the type of access request, etc., as described in paragraph [0056] and Figure 7.).
Borochoff is directed to resource dependency system and graphical user interface. Chheda is directed to versioning schemas for hierarchical data structures. Both are directed to data versioning and therefore it would have been to one of ordinary skilled in the art at the time the invention was filed to modify the teachings of Borochoff with the teachings of Chheda to include the claimed features with the motivation to improve versioning schema.
As per claim 16, the modified teachings of Borochoff with Chheda teaches the non-transitory machine-readable storage medium of claim 15, wherein:
the component comprises a configured web component associated with the GUI display that includes the reference to the API (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a client mobile device to support one or more GUI displays generated or otherwise provided by a native application on a display device, where the database system includes one or more application servers that support an application platform capable of providing instances of virtual applications over the network.).
As per claim 18, the modified teachings of Borochoff with Chheda teaches the non-transitory machine-readable storage medium of claim 15, wherein the version designation uses a custom versioning schema associated with the external system (e.g. Borochoff, see Figure 7, paragraphs [0100-0110], which discloses identifying the catalog that includes versioned immutable data sets, where the data sets may encompass an ordered set of conceptual data set items, where the catalog may store information about the data sets including identifying different versions of the data set and display it on a GUI).
As per claim 19, the modified teachings of Borochoff with Chheda teaches the non-transitory machine-readable storage medium of claim 15, wherein:
the component comprises a configured web component associated with the GUI display (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a client mobile device to support one or more GUI displays generated or otherwise provided by a native application on a display device, where the database system includes one or more application servers that support an application platform capable of providing instances of virtual applications over the network.); and
the instructions are configurable to cause the processor to generate a graphical representation of the configured web component using the data retrieved from the versioned path for the version designation of the API (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.).
As per claim 20, the modified teachings of Borochoff with Chheda teaches the non-transitory machine-readable storage medium of claim 15, wherein the versioned path comprises a uniform resource locator (URL) address for an endpoint at the external system associated with the version designation for the API (e.g. Borochoff, see Figure 1, paragraphs [0075-0082], which discloses a instances of the native application and/or the virtual application for users associated with a particular resource owner, where the application configuration metadata may include values or fields that define the layout, sequences, or parameters associated with one or more GUI displays.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. See attached PTO-892 that includes additional prior art of record describing the general state of the art in which the invention is directed to.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARHAN M SYED whose telephone number is (571)272-7191. The examiner can normally be reached M-F 8: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, Apu Mofiz can be reached at 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 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.
/FARHAN M SYED/Primary Examiner, Art Unit 2161 August 7, 2026
Prosecution Insights