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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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-6,9,10, and 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20140130035 A1; Desai; Mehul et al. (hereinafter Desai) in view of US 20230315734 A1; Buchmann; Daniel et al. (hereinafter Buchmann)
Regarding claim 1, Desai teaches A computer-implemented method of engineering a variant of a physical system family, the method including: providing engineering information including a model characterizing physical properties of the physical system family in a data storage platform; (Desai [0108] A mobile transaction platform may include reference implementations for elements such as containers, wallets, widgets, and for applications such as finance, retail, health, government, and the like. The features and functions of a mobile transaction platform may be delivered through multiple deployment models, which may include the use of a native client application (e.g. a container or mClient) that may be supported [0118] The ecosystem 600 may further be characterized by capabilities and features such as three-dimensional security for personalized transactions (e.g. device, domain, and user), multiple functionality tiers (e.g., an architecture with personalization, service, enabling tier, expert, and experience framework tiers or layers), support for multiple independent containers on a client device 602, multiple distinct widgets within a container, multiple distinct and independent wallets within a container, single widget access to multiple wallets, single wallet access by multiple widgets, support for a plurality of trust models...[0253] As separately executable units of code, widgets 2306 may be effectively isolated one from the other via the execution separation functions available from a mobile operating system and/or by aspects of the mClient including the runtime environment provided by a container. In addition, widgets 2306 may be developed by a service provider (e.g. an issuer of instruments, and the like) who may configure the widget to incorporate provider-specific security elements that may make it hard for other service-provider developed widgets from accessing its resources, workflows, and the like. A mobile transaction platform that may include such widgets, containers, wallets, service provider software (including without limitation various aspects of a wallet service center described later herein), and the like may enforce strong and diverse security in all such aspects so that, for example, widgets developed by service provider A may not access resources (e.g. server-based) of service provider B. Such strong security may be important for a variety of reasons including keeping domain-specific information separate and confidential from other domains that the user may interact with through the user's mobile device (e.g. financial domains, health domain, legal domains, business domains, personal domains, identity domains, and the like).[267-275] elaborates on the matter [FIG.1 & 3] shows the corresponding steps) creating a second connector linking the model artifact to a variant model artifact included in the variant lifecycle information and stored in the lifecycle database, respectively; (Desai [0078] including various deployment models, configurable ecosystem rules, underlying aggregation security architecture and configurable security trust models, necessary tools, utilities, web-services, mobile device and server applications (e.g. wallets, containers, widgets, wallet companion domains), and the like. The result may be high quality service delivery in a highly scalable enterprise environment for ensuring the different ecosystem participants can be integrated and new participants can be added without burdensome overhead.[0082] In exemplary and non-limiting embodiments, the MTP may be configured for providing the wallet, the widget, and manage the transaction along with all the relevant business services that may be associated with delivering wallets to a universe of diverse mobile environments. In exemplary and non-limiting embodiments, the MTP may be configured for providing an improved SDK that may to help build a wallet and ecosystem of service providers that may create widgets with elaborate feature sets without having to worry about handset fragmentation. In exemplary and non-limiting embodiments, the MTP may be configured for establishing connectors with various ecosystems to deliver a dynamic user experience and diverse set of services to the end user that may be accessed irrespective of time and geographical location. [0095] the host integration framework may a layer including various connectors that may be plugged into the server to communicate with the back-end systems for facilitating the transactional services. The host integration framework may include a series of interface definitions which may have to be implemented by the service developer in the form of connectors to communicate with external host systems. [0351] The MTP 2902 may have a plurality of roles. For example, the MTP may perform a wallet and transaction management along with all the relevant business services that may be associated with delivering wallets to a plurality of diverse mobile environments 2912. In an example, the MTP 2902 may provide an establishment of the ecosystem of the service providers 2910 and the third-party developers that build widgets for the wallet without having to worry about handset fragmentation. In an example, the MTP 2902 may establish a plurality of connectors with various ecosystems (for example, the ecosystem of service providers 2910, plurality of mobile environments). The connectors along with the MTP 2902 may provide an improved user experience and a diverse set of services, which may be accessible to the end user irrespective of time or location.[78-88] elaborate on the matter [FIG.1 & 3] shows the corresponding steps) creating a third connector linking the model to the variant model included in the variant engineering information and stored in the data storage platform, respectively; creating a fourth connector linking the variant model artifact stored in the lifecycle database to the variant model stored in the data storage platform; (Desai [0082] In exemplary and non-limiting embodiments, the MTP may be configured for providing the wallet, the widget, and manage the transaction along with all the relevant business services that may be associated with delivering wallets to a universe of diverse mobile environments. In exemplary and non-limiting embodiments, the MTP may be configured for providing an improved SDK that may to help build a wallet and ecosystem of service providers that may create widgets with elaborate feature sets without having to worry about handset fragmentation. In exemplary and non-limiting embodiments, the MTP may be configured for establishing connectors with various ecosystems to deliver a dynamic user experience and diverse set of services to the end user that may be accessed irrespective of time and geographical location. [0095] the host integration framework may a layer including various connectors that may be plugged into the server to communicate with the back-end systems for facilitating the transactional services. The host integration framework may include a series of interface definitions which may have to be implemented by the service developer in the form of connectors to communicate with external host systems. [167] A third component may include at least one trust model. The trust model may facilitate implementation for different authentication schemes for the services, including support to operate within individual trust clusters with their independent TSMs.[0351] The MTP 2902 may have a plurality of roles. For example, the MTP may perform a wallet and transaction management along with all the relevant business services that may be associated with delivering wallets to a plurality of diverse mobile environments 2912. In an example, the MTP 2902 may provide an establishment of the ecosystem of the service providers 2910 and the third-party developers that build widgets for the wallet without having to worry about handset fragmentation. In an example, the MTP 2902 may establish a plurality of connectors with various ecosystems (for example, the ecosystem of service providers 2910, plurality of mobile environments). The connectors along with the MTP 2902 may provide an improved user experience and a diverse set of services, which may be accessible to the end user irrespective of time or location. [166-169] elaborate on the matter [FIG.1 & 3] shows the corresponding steps) and amending the variant model, the variant model artifact, or the variant model and the variant model artifact in the engineering database upon request of a user of the engineering database. (Desai [0270] In accordance with exemplary and non-limiting embodiments, widgets 2306 stored and capable of running within the secure environment of the client container 2302 may be updated for any of a variety of purposes (e.g. periodically, such as weekly, to provide current pricing or offers, increase a spending limit, in response to a user request, to improve security, to add access to a different trust model, and the like). In one exemplary embodiment, after reviewing and publishing the widget 2306, a widget provider may create and issue an alert indicating the availability of a new or newer version of one or more widgets 2306.[0273] In accordance with other exemplary embodiments, a widget 2306 itself may be informed through a workflow of the widget issuer that an update is available and based on aspects of the updated widget (e.g. a security update), the installed widget might take an action (e.g. disable itself, notify the user that it is no longer current, update portions of itself rather than replacing it with a new widget, etc). Another update mechanism may be realized through operation of the wallet. For example, a wallet may be updated and, as a result, may indicate that a widget is out of date, triggering various widget actions (e.g., notify the user, automatically update, request an update, and the like [0438] The mobile transaction processing system as described herein for providing an ecosystem for secure personalized transactions may facilitate trust model determination for a mobile transaction. Model determination may include configuring a plurality of servers deployed in a network to facilitate transactions between a client device and a provider-specific server via any of a plurality of trust models including a single trust domain, a single trust cluster, multiple trust clusters, and a direct trust relationship. [FIG.1 & 3] shows the corresponding steps) Desai lacks explicitly and orderly teaching copying the lifecycle information of the physical system family to create variant lifecycle information of the variant in the lifecycle database; copying the engineering information of the physical system family to create variant engineering information of the variant in the data storage platform; providing the variant model and the variant model artifact to an engineering database; Buchmann teaches copying the lifecycle information of the physical system family to create variant lifecycle information of the variant in the lifecycle database; copying the engineering information of the physical system family to create variant engineering information of the variant in the data storage platform; (Buchmann [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances. [0041] The present disclosure provides techniques that can be used to allow a schema to be constructed where different artifacts in a schema are able to access data using different methods, and where the access methods can be created according to various rules. The present disclosure also provides techniques where a schema allows the same basic data artifact to be accessed in different ways, such as a schema allowing access to a data artifact via data federation, if recent data is needed, or access to a local copy (e.g., replicated data [0050] When source data is not located at the primary data source (in which the schema/data artifact hierarchy is being implemented), a data artifact can be created to access data from a remote data source, such as via federation or by creating by replicating data (thus, essentially creating a local copy of the data, even if the data source is not the primary data source of the data).[0066] The schema 230 includes a first set of data artifacts 236, 238 that are runtime artifacts that correspond to the cube modelling artifact 210 and the modelling artifact 214, respectively. The data artifacts 236, 238 are associated with a first type of data source. For instance, the data artifacts 236, 238 may refer to a remote, but not necessarily federated, data source. In a particular example, the data artifacts 236, 238 are defined in SAP HANA Cloud (available from SAP SE, of Walldorf, Germany), but the underlying data is stored at an on-premise installation of SAP HANA. Thus, a query using one or both of the data artifacts 236, 238 is sent to the on-premise database, and responsive data (which can be the entire contents of a data artifact, such as a table, but is typically limited using various filter conditions) is returned to the cloud-based database. In another example, the data artifacts 236, 238 can be local data artifacts that maintain a primary copy of relevant data, or can be replicated data artifacts. In a further example, at least one higher level artifact can reference a lower-lever artifact.[62-68 &109-115] elaborate on the matter [FIG.1 & 15] show the corresponding steps) providing the variant model and the variant model artifact to an engineering database; (Buchmann [0038] Typically, when a data model or a data query are created, particular data components (such as a field of a database table) are associated with a particular data source, and data model artifacts and data queries can be created in a manner appropriate for the relevant data source or sources. [0052] The client system 104 includes a modelling schema 112. The modelling schema 112 can be, in some cases, a virtual data model. In other cases, the modelling schema 112 can be a design time construct that is used to create corresponding runtime artifacts, which can include creating artifacts in a virtual data model or in the data store 108. When a virtual data model is used, artifacts in the virtual data model can reference corresponding artifacts in the data store 108. [0054] The data store 108 can include data 118, such as data stored in various data artifacts 120 (shown as 120a-120d), such as tables or views in a relational database system (serving as the data store). In other cases, the data artifacts do not directly store the data, but provide access to data. For example, the data artifacts can be objects in a virtual data model that are mapped to data in data sources such as tables or views in a relational database system (or other sources of structured, semi-structured, or unstructured data). [0063] FIG. 2 illustrates a scenario where dynamic access to data artifacts corresponding to modelling artifacts in a data model 200 can be implemented in a way that provides dynamic, variable access to data. The data model 200 is illustrated with two modelling artifacts, a modelling object 210 representing a cube (e.g., an OLAP cube) that references a modelling artifact 214 representing a lower-level source of data, such as a table or view. That is, the data model 200 is organized hierarchically, where higher-level artifact, like the cube artifact 210, build on lower-level objects like the modeling artifact 214. In this particular example, the cube modelling artifact 210 may select dimensions or facts associated with the modelling artifact 214.[0080] FIG. 3 is similar to FIG. 2, in that it includes a data model 300 and a schema 330, such as a schema of runtime data artifacts. The data model 300 is slightly more complex than the data model 200, in that the data model 300 includes a query modelling artifact 308 in addition to a cube modelling artifact 312, and a table or view artifact 316 (or other type of data artifact, construct, or object). [53-59] elaborate on the matter [FIG.1 & 2] shows corresponding steps) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Buchmann in order to efficiently facilitate data access and output of the system (Buchmann [AB.] Techniques and solutions are described for providing flexible access to data during execution of a data access request. Multiple instances of a data artifact are created, where different instances of the data artifact provide access to different data sources having data associated with the data access request. When a data access request is executed, a particular data artifact instance can be used during execution of the data access request. In some cases, switching logic can be used to determine which data artifact instance is to be used in executing the data access request. Also described are technologies for facilitating creation of data artifact instances corresponding to a modelling artifact.] [0005] Typically, when a data model or a data query are created, particular data components (such as a field of a database table) are associated with a particular data source, and data model artifacts and data queries can be created in a manner appropriate for the relevant data source or sources. However, complications can arise when it is not clear how data access/data sources should be structured, such as when a data model is imported. In addition, typical data models are static in how they reference associated data. This can limit flexibility, such as when different circumstances would benefit from having different options for accessing data. Accordingly, room for improvement exists.[0110] Variable access can also facilitate top-down modelling approaches. Such approaches can be taken by end users (e.g., developers working for a company that is customizing a software solution from another provider or creating models ab initio). Top-down modelling can be useful for a number of reasons, including because it may be easier to start defining artifacts based on how they will be used in a software application before determining a model that is best for storing data referenced by higher-level artifacts. Top-down modelling can also assist in having the most knowledge/relevant users define artifacts. In the above example, an application developer, data scientist, or end user may be in the best position to know what data is needed and the best format for accessing the data (including based on application performance considerations), but a database administrator may be most familiar with the performance of a database in which the underlying data in stored. [FIG.1 ] shows the overall system which is providing improvement)
Corresponding product claim 13 is rejected similarly as claim 1 above. Additional Limitations: computer readable medium capable of reading and executing instructions (Desai [FIG.1&3] show the corresponding methods which include system with computer readable medium capable of reading and executing instructions [0546] The methods and systems described herein may be deployed in part or in whole through a machine that executes computer software, program codes, and/or instructions on a processor. The processor may be part of a server, client, network infrastructure, mobile computing platform, stationary computing platform, or other computing platform. A processor may be any kind of computational or processing device capable of executing program instructions, codes...[546-554] elaborate on the matter)
Regarding claim 2, Desai and Buchmann teach The computer-implemented method of claim 1, wherein a respective unique identifier is assigned to the respective model artifact, and wherein the respective connector linking the model artifacts among each other uses the respective unique identifier. (Buchmann [0046] In another implementation, multiple instances of a data artifact can exist for one or more data artifacts in a hierarchy, but access is not determined for a particular request based on a switching view, or similar construct. In some cases, the request itself can specify the appropriate data artifact instance for a particular access method desired (e.g., the data artifact instances can have identifiers that differ such as a user can select data artifact instance A or A′, which are instances of the same data artifact whose data is accessed using different techniques). Or, other types of switching logic can be included in request processing logic. For instance, logic can specify that lower-level artifacts should be used unless a particular access method is available for a given data artifact.[0070] Switch criteria can be specified in any suitable manner. One example of switch criteria is operations, data sources, or values specified in a data request (e.g., a database query, such as in SQL). For instance, a join that involves a particular database table, or a particular column of a database table, can be used to select one of multiple possible data sources. Or, that a join operation is specified at all can be sufficient to select one of multiple possible data artifact instances. Data requests can be given names or identifiers, and these names or identifiers can be used to select a data artifact instance. Similarly, an identifier of a user, computing system, application, or application process may be used to select between data artifact instances. Data requests may contain, or be provided with, information useable as switching criteria. For example, a query can be sent with an indicator or flag indicating whether it is time sensitive or whether data accuracy (i.e., obtaining most recent data) is preferred. [0098] FIG. 5 illustrates code 500 (in pseudo-CSN, or a format similar to CSN) that can be included in an artifact, such as a modelling artifact. The code 500 includes a plurality of data elements 504 specified for the artifact, where at least a portion of the data elements 504 can be associated with data in (or obtainable using) one or more data artifacts created using disclosed technologies. A given data element 504 can be associated with a name/identifier 508 and a type 510 [FIG.1&15] shows corresponding visual)
Corresponding product claim 14 is rejected similarly as claim 2 above.
Regarding claim 3, Desai and Buchmann teach The computer-implemented method of claim 1, further including:copying the lifecycle information of the physical system family and the variant lifecycle information from the lifecycle database to the data storage platform; (Buchmann [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances. [0041] The present disclosure provides techniques that can be used to allow a schema to be constructed where different artifacts in a schema are able to access data using different methods, and where the access methods can be created according to various rules. The present disclosure also provides techniques where a schema allows the same basic data artifact to be accessed in different ways, such as a schema allowing access to a data artifact via data federation, if recent data is needed, or access to a local copy (e.g., replicated data [0050] When source data is not located at the primary data source (in which the schema/data artifact hierarchy is being implemented), a data artifact can be created to access data from a remote data source, such as via federation or by creating by replicating data (thus, essentially creating a local copy of the data, even if the data source is not the primary data source of the data).[0066] The schema 230 includes a first set of data artifacts 236, 238 that are runtime artifacts that correspond to the cube modelling artifact 210 and the modelling artifact 214, respectively. The data artifacts 236, 238 are associated with a first type of data source. For instance, the data artifacts 236, 238 may refer to a remote, but not necessarily federated, data source. In a particular example, the data artifacts 236, 238 are defined in SAP HANA Cloud (available from SAP SE, of Walldorf, Germany), but the underlying data is stored at an on-premise installation of SAP HANA. Thus, a query using one or both of the data artifacts 236, 238 is sent to the on-premise database, and responsive data (which can be the entire contents of a data artifact, such as a table, but is typically limited using various filter conditions) is returned to the cloud-based database. In another example, the data artifacts 236, 238 can be local data artifacts that maintain a primary copy of relevant data, or can be replicated data artifacts. In a further example, at least one higher level artifact can reference a lower-lever artifact.[62-68 &109-115] elaborate on the matter [FIG.1 & 15] show the corresponding steps) and linking the model artifact and the variant model artifact in the lifecycle database to the model artifact (Desai [0034] FIG. 18 illustrates a widget lifecycle from development to execution. [0079] FIG. 1 illustrates a dynamic ecosystem 100 for secure mCommerce and mPayment transactions. The ecosystem 100 may be described herein. The MTP 114 may be configured to power a dynamic ecosystem for secure mCommerce and mPayment transactions as described below. The MTP may be set up in a network provider's domain 102 and integrated into a system of the network provider 104. In an example, an enterprise service bus (ESB) 108 of the network provider 104 may be used for integration. The MTP 114 may be connected to an ecosystem of service and security providers 110, which may include one or more trusted service managers (TSMs), for example, 112a, 112b. The network provider 104 may use the MTP 114 to create a branded mobile application targeting a specific business vertical. In an example, the mobile application may be a mWallet for the retail/financial domain or a mHealth application for the healthcare vertical. In an example, the mobile application may provide a core set of services to a user, specific to a domain for which it may have been created. For the purpose of this invention, the mobile application may be a wallet assuming a retail domain application. In an example, the wallet may also facilitate, application lifecycle and security, standardized user experience and widget management responsibilities.[0082] the MTP may be configured for establishing connectors with various ecosystems to deliver a dynamic user experience and diverse set of services to the end user that may be accessed irrespective of time and geographical location.[0090] The interface module may provide connectors developed to facilitate communication with various backend systems that may collaborate to fulfill the complete end to end service.[0222] In some exemplary and non limiting embodiments a first phase in widget life-cycle may be widget development. In an example, the mobile transaction platform (MTP) may support a Microsoft Visio based widget development toolkit to automate Widget development. The widget development may take place in an issuer domain. The widget may be made up of a plurality of widget artifacts. In an example, the widget may be made up of a screen.xml file, a content.xml file, a theme.xml file, a plurality of script files, a plurality of images, and a widget descriptor. In an example, the widget development toolkit may generate widget's artifacts like screen, content etc. along with the widget descriptor [220-227] elaborate on the matter [FIG.1 & 18] show the corresponding steps) and the variant model artifact copied to the data storage platform via respective connectors. (Buchmann [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances. [0041] The present disclosure provides techniques that can be used to allow a schema to be constructed where different artifacts in a schema are able to access data using different methods, and where the access methods can be created according to various rules. The present disclosure also provides techniques where a schema allows the same basic data artifact to be accessed in different ways, such as a schema allowing access to a data artifact via data federation, if recent data is needed, or access to a local copy (e.g., replicated data [0050] When source data is not located at the primary data source (in which the schema/data artifact hierarchy is being implemented), a data artifact can be created to access data from a remote data source, such as via federation or by creating by replicating data (thus, essentially creating a local copy of the data, even if the data source is not the primary data source of the data).[0066] The schema 230 includes a first set of data artifacts 236, 238 that are runtime artifacts that correspond to the cube modelling artifact 210 and the modelling artifact 214, respectively. The data artifacts 236, 238 are associated with a first type of data source. For instance, the data artifacts 236, 238 may refer to a remote, but not necessarily federated, data source. In a particular example, the data artifacts 236, 238 are defined in SAP HANA Cloud (available from SAP SE, of Walldorf, Germany), but the underlying data is stored at an on-premise installation of SAP HANA. Thus, a query using one or both of the data artifacts 236, 238 is sent to the on-premise database, and responsive data (which can be the entire contents of a data artifact, such as a table, but is typically limited using various filter conditions) is returned to the cloud-based database. In another example, the data artifacts 236, 238 can be local data artifacts that maintain a primary copy of relevant data, or can be replicated data artifacts. In a further example, at least one higher level artifact can reference a lower-lever artifact.[62-68 &109-115] elaborate on the matter [FIG.1 & 15] show the corresponding steps)
Corresponding product claim 15 is rejected similarly as claim 3 above
Regarding claim 4, Desai and Buchmann teach The computer-implemented method of claim 1, wherein providing the engineering information of the physical system family including the model in a data storage platform and providing the lifecycle information of the physical system family including the model artifact in the lifecycle database includes: creating initial requirements which the physical system family needs to satisfy in the lifecycle database; (Desai [0138] A method or process of breaking down parts of the overall transaction, service or process into the multi-tiered ecosystem platform may be based on a combination of analytics, heuristics and requirements, optionally aided by tools including expert engines based on artificial intelligence concepts. Such a method or process may take into account the perspectives and requirements of all participating--present and anticipated in future--entities in the ecosystems including, but not limited to, service providers; service requirements; customer requirements; end-user requirements; regulatory mandates & guidelines; security mandates, guidelines and requirements; trust models; economic models; business logic and workflow; commonality with other services; operational factors; design & technology factors; target devices & platforms; projected technology evolution; other related & unrelated services; and operating constraints. [0170] In an example, a device manufacturer may determine that NFC functionality will be offered as a new communication option on a new device, in order to support the business objectives of the company. Upon detection of the availability of the new NFC functionality, the business needs and device functionality allocation engine 1302 may review the requirements of the device manufacturer and allocate the device functionality to the enabling tier 1304. [216] configured to fulfill various security requirements. [433] meets the security/risk requirements of the service provider [471-478] elaborate on the matter [FIG.1 &14] show corresponding visual) creating the engineering information of the physical system family including the model in the engineering database upon request of the user of the engineering database after at least some of the initial requirements have been communicated to the user of the engineering database; (Desai [0109] A multi-tiered secure mobile transactions enabling platform may satisfy enterprise service delivery environment expectations and demands with the necessary support for scalability, redundancy, inter-operability, service delivery, message definitions, and the like. The platform may be delivered either through a hosted model for service/issue/acquisition providers and/or through a managed service model. The MTP facilitates implementing rules (e.g. business, transaction, trust, and the like) across an ecosystem as described herein, which can govern various ecosystem operations including on-boarding of participants into the ecosystem, how the participants access and consume the various services through the ecosystem, how a participant may be removed from the ecosystem, how different participants within the ecosystem may cooperate with each other, how different participants may cooperate with entities outside of the ecosystem, how participants acquire customers, how participants will support customers, how participants may capture data related to users and transactions (static and dynamic), how participants will use such data, share such data, and monetize such data--within the ecosystem as well as outside, among other things.[0244] The widget approval process as illustrated in FIG. 22 may involve a user 2202, a widget certification manager 2204, a widget repository manager 2208, a static verification utility 2210 and a binary package generator 2212. The user 2202 may select a widget bundle 2214 from various widget bundles available to the user. In an example, the widget bundle 2214 may contain an applicaition.xml file, a content.xml file, a theme.xml file and a widget descriptor (these files may be same as described above). The widget bundle 2214 may be sent to the widget certification manager 2204 by the user 2202. The widget certification manager 2204 may also be the widget approval manager. The widget certification manager 2204 may be the main controller class driving approval process. The widget certification manager 2204 may send the widget bundle 2214 to the widget repository manager 2208, the widget repository manager 2208 may manage details about all the certified and uncertified widgets with proper timestamp details. The widget repository manager 2208 may have access to a widget repository 2218. The widget repository 2218 may contain all the certified and uncertified widgets with proper timestamp details. This information may help for audit trailing and for static verification. The widget certification manager 2204 may send the widget bundle 2214 to the static verification utility 2210. The static verification utility 2210 may validate the widget bundle 2214 against static rules. For example, if a client may have already declared client_Check_CardStatus as one of its custom actions, then any other issuer then the client itself may not be allowed to use this particular action. The static verification utility 2210 may check the widget bundle 2214 in the widget repository 2218 for any accidental/incorrect reference to assets that may be owned by other widgets. The static verification utility 2210 may automate a part of the access verification process, but manual verifications may still be required. The widget certification manager 2204 may receive the widget bundle 2214 verified against static rules from the static verification utility 2210. The widget certification manager 2204 may send the widget bundle 2214 to the binary package generator 2212. The binary package generator 2212 may generates the final binary package corresponding to the widget bundle 2214. The binary package may be ready for over-the-air download and delivery. The binary package generator 2212 may send a binary widget file 2220 to the user 2202. [461-469] elaborate on the matter [FIG.1 &14] show corresponding visual) linking the initial requirements stored in the lifecycle database to the model stored in the engineering database; (Desai [0078] The methods and systems of a multi-tier mobile transaction platform for secure personalized transactions in a multi-domain ecosystem may facilitate establishing and operating a market place or exchange of transaction-related credentials. These credentials may be tokenized or may not be tokenized, subject to the requirement of their respective issuers and acquirers, related to payment and non-payment services, and the like. These credentials may be transacted over-the-air and in proximity environments over host of channels, such as point of sale terminals, and the like. By employing these methods and systems that may enable such a transaction-related credential exchange, a key business problem related to scaling such an ecosystem may be solved. This exchange of transaction-related credentials may completely remove the need for a single service provider to embed themselves as the effective exchange of such transaction credentials, and rather allow for existing issuers, acquirers and service providers (and/or consumers of such credentials) to continue to leverage their existing systems, business, and risk-management practices. Such an exchange will add value by leveraging the aspects of the mobile transaction platform described herein including various deployment models, configurable ecosystem rules, underlying aggregation security architecture and configurable security trust models [0088] definition for the object and implementation for the rules governing the object's lifecycle and transaction. A third component may include at least one trust model. The trust model may facilitate implementation for different authentication schemes for the services, including support to operate within individual trust clusters with their independent TSMs.[0136] The methods and systems described herein of multi-domain ecosystem secure personalized transactions includes a method that includes analyzing one or more of a set consisting of ecosystem participants, service requirements, customer requirements, regulatory requirements, transaction security requirements, trust models, and electronic transaction communication channels. The method may further include determining, based in the analysis, one or more ecosystem features to configure in a platform comprising at least one of a service tier, an enabling tier, and a personalization tier. The method may further include configuring the one or more ecosystem features in accordance with the determination. In an embodiment, the one or more ecosystem features may be configured to ensure satisfaction of each analyzed requirement within a context of a service provider business model. The platform may additionally include an expert engine tier and an experience framework tier [0137] Methods for selecting eco system features for inclusion in each of an enabling tier, a service tier, and a personalization tier may include analyzing ecosystem participants, service requirements, customer requirements, regulatory requirements [136-144] further elaborate [FIG.1 &14] show corresponding visual) creating the model artifact in the lifecycle database upon request of the user of the engineering database; (Buchmann [0047] In a yet further example, multiple queries (or requests, more generally) can be defined, where each query provides a different combination of access techniques for data artifacts in the query. Thus, a user or process need simply select the appropriate query for execution without needing to construct the query or have detailed knowledge of the relevant schema. Selection can be indirect, such as selecting user interface elements providing criteria[0048] Disclosed technologies can also facilitate implementing the disclosed flexible access techniques. For instance, given a particular schema as an input, a software process can create appropriate data artifact instances for an artifact of the input schema. For instance an artifact in a schema (a model or design time data artifact) can be used to instantiate a runtime data artifact referencing a lower-level artifact, a runtime data artifact providing access to data via replication or federation, and optionally switching logic or data artifacts (e.g., switching views). Default switching logic can also be provided.[0049] A user or process may choose to enable the disclosed flexible access techniques, such as by including a suitable annotation in a model data artifact which triggers code to create the runtime data artifact instances as described above.[0089] As explained with respect to a particular example artifact discussed in Example 8, disclosed technologies can facilitate the creation of data artifact instances, relationships between data artifacts, and the execution of data access requests using a data artifact instance using disclosed techniques.[0090] For example, logic can be implemented that automatically creates data artifact instances for a modelling artifact. Such action can be explicitly requested. For example, a command or user process can call functionality to create data artifact instances for artifacts in a particular artifact schema or for selected artifacts. Or, a schema or artifacts in the schema can have annotations indicating that data instances should be created. Instructions to create data artifact instances can include information usable to help determine the nature of the data artifact instances, to configure logic used to select between data artifact instances, and to establish relationships between data artifacts and data artifact instances at different levels of a hierarchy of data artifacts. A schema can be analyzed to determine which artifacts have been selected for data artifact instance creation, and suitable data artifacts (and optionally switching logic) created.[0091] FIG. 4 illustrates example code 400 (in pseudo-CSN) for defining an artifact 404, such as a modelling artifact, including annotating the artifact to indicate that the artifact should be created with flexible deployment options. [92-102] elaborate on the matter [FIG.1 & 4] shows corresponding visual) linking the initial requirements to the model artifact in the lifecycle database; (Desai [0078] The methods and systems of a multi-tier mobile transaction platform for secure personalized transactions in a multi-domain ecosystem may facilitate establishing and operating a market place or exchange of transaction-related credentials. These credentials may be tokenized or may not be tokenized, subject to the requirement of their respective issuers and acquirers, related to payment and non-payment services, and the like. These credentials may be transacted over-the-air and in proximity environments over host of channels, such as point of sale terminals, and the like. By employing these methods and systems that may enable such a transaction-related credential exchange, a key business problem related to scaling such an ecosystem may be solved. This exchange of transaction-related credentials may completely remove the need for a single service provider to embed themselves as the effective exchange of such transaction credentials, and rather allow for existing issuers, acquirers and service providers (and/or consumers of such credentials) to continue to leverage their existing systems, business, and risk-management practices. Such an exchange will add value by leveraging the aspects of the mobile transaction platform described herein including various deployment models, configurable ecosystem rules, underlying aggregation security architecture and configurable security trust models [0088] definition for the object and implementation for the rules governing the object's lifecycle and transaction. A third component may include at least one trust model. The trust model may facilitate implementation for different authentication schemes for the services, including support to operate within individual trust clusters with their independent TSMs.[0136] The methods and systems described herein of multi-domain ecosystem secure personalized transactions includes a method that includes analyzing one or more of a set consisting of ecosystem participants, service requirements, customer requirements, regulatory requirements, transaction security requirements, trust models, and electronic transaction communication channels. The method may further include determining, based in the analysis, one or more ecosystem features to configure in a platform comprising at least one of a service tier, an enabling tier, and a personalization tier. The method may further include configuring the one or more ecosystem features in accordance with the determination. In an embodiment, the one or more ecosystem features may be configured to ensure satisfaction of each analyzed requirement within a context of a service provider business model. The platform may additionally include an expert engine tier and an experience framework tier [0137] Methods for selecting eco system features for inclusion in each of an enabling tier, a service tier, and a personalization tier may include analyzing ecosystem participants, service requirements, customer requirements, regulatory requirements [136-144] further elaborate [FIG.1 &14] show corresponding visual) copying the model stored the engineering database to the data storage platform; (Buchmann [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances. [0041] The present disclosure provides techniques that can be used to allow a schema to be constructed where different artifacts in a schema are able to access data using different methods, and where the access methods can be created according to various rules. The present disclosure also provides techniques where a schema allows the same basic data artifact to be accessed in different ways, such as a schema allowing access to a data artifact via data federation, if recent data is needed, or access to a local copy (e.g., replicated data [0050] When source data is not located at the primary data source (in which the schema/data artifact hierarchy is being implemented), a data artifact can be created to access data from a remote data source, such as via federation or by creating by replicating data (thus, essentially creating a local copy of the data, even if the data source is not the primary data source of the data).[0066] The schema 230 includes a first set of data artifacts 236, 238 that are runtime artifacts that correspond to the cube modelling artifact 210 and the modelling artifact 214, respectively. The data artifacts 236, 238 are associated with a first type of data source. For instance, the data artifacts 236, 238 may refer to a remote, but not necessarily federated, data source. In a particular example, the data artifacts 236, 238 are defined in SAP HANA Cloud (available from SAP SE, of Walldorf, Germany), but the underlying data is stored at an on-premise installation of SAP HANA. Thus, a query using one or both of the data artifacts 236, 238 is sent to the on-premise database, and responsive data (which can be the entire contents of a data artifact, such as a table, but is typically limited using various filter conditions) is returned to the cloud-based database. In another example, the data artifacts 236, 238 can be local data artifacts that maintain a primary copy of relevant data, or can be replicated data artifacts. In a further example, at least one higher level artifact can reference a lower-lever artifact.[62-68 &109-115] elaborate on the matter [FIG.1 & 15] show the corresponding steps) creating the first connector linking the model artifact stored in the lifecycle database to the model stored in the data storage platform. (Desai [0078] including various deployment models, configurable ecosystem rules, underlying aggregation security architecture and configurable security trust models, necessary tools, utilities, web-services, mobile device and server applications (e.g. wallets, containers, widgets, wallet companion domains), and the like. The result may be high quality service delivery in a highly scalable enterprise environment for ensuring the different ecosystem participants can be integrated and new participants can be added without burdensome overhead.[0082] In exemplary and non-limiting embodiments, the MTP may be configured for providing the wallet, the widget, and manage the transaction along with all the relevant business services that may be associated with delivering wallets to a universe of diverse mobile environments. In exemplary and non-limiting embodiments, the MTP may be configured for providing an improved SDK that may to help build a wallet and ecosystem of service providers that may create widgets with elaborate feature sets without having to worry about handset fragmentation. In exemplary and non-limiting embodiments, the MTP may be configured for establishing connectors with various ecosystems to deliver a dynamic user experience and diverse set of services to the end user that may be accessed irrespective of time and geographical location. [0095] the host integration framework may a layer including various connectors that may be plugged into the server to communicate with the back-end systems for facilitating the transactional services. The host integration framework may include a series of interface definitions which may have to be implemented by the service developer in the form of connectors to communicate with external host systems. [0351] The MTP 2902 may have a plurality of roles. For example, the MTP may perform a wallet and transaction management along with all the relevant business services that may be associated with delivering wallets to a plurality of diverse mobile environments 2912. In an example, the MTP 2902 may provide an establishment of the ecosystem of the service providers 2910 and the third-party developers that build widgets for the wallet without having to worry about handset fragmentation. In an example, the MTP 2902 may establish a plurality of connectors with various ecosystems (for example, the ecosystem of service providers 2910, plurality of mobile environments). The connectors along with the MTP 2902 may provide improved user experience and a diverse set of services, which may be accessible to the end user irrespective of time or location [78-88] elaborate on the matter [FIG.1 & 3] shows the corresponding steps)
Corresponding product claim 16 is rejected similarly as claim 4 above
Regarding claim 5, Desai and Buchmann teach The computer-implemented method of claim 1, further including: receiving, by the lifecycle database, a query from the user of the engineering database to provide at least a queried part of a queried model among one of the models to the engineering database; (Buchmann [0038] a data model or a data query are created, particular data components (such as a field of a database table) are associated with a particular data source, and data model artifacts and data queries can be created in a manner appropriate for the relevant data source or sources. However, complications can arise when it is not clear how data access/data sources should be structured, such as when a data model is imported. In addition, typical data models are static in how they reference associated data. This can limit flexibility, such as when different circumstances would benefit from having different options for accessing data. Accordingly, room for improvement exists [0047] In a yet further example, multiple queries (or requests, more generally) can be defined, where each query provides a different combination of access techniques for data artifacts in the query. Thus, a user or process need simply select the appropriate query for execution without needing to construct the query or have detailed knowledge of the relevant schema. Selection can be indirect, such as selecting user interface elements providing criteria that are tied to flags indicating what type of query should be selected. In particular, a user interface screen can provide a user with options to define a query (e.g., selecting particular fields of interest and selection criteria) and to indicate, for example, whether data recency or query speed is more important, and then software logic can construct or select the appropriate query. .[0080] FIG. 3 is similar to FIG. 2, in that it includes a data model 300 and a schema 330, such as a schema of runtime data artifacts. The data model 300 is slightly more complex than the data model 200, in that the data model 300 includes a query modelling artifact 308 in addition to a cube modelling artifact 312, and a table or view artifact 316 (or other type of data artifact, construct, or object)[0083] Given the absence of explicit switching logic, other mechanisms can be used to select data artifact instances at different levels of the hierarchy (where multiple data artifacts are defined, not all levels of a hierarchy are required to have multiple data artifact instances, at least in some implementations). In some cases, a user can manually select particular data artifact instances for a query, where information can be provided allowing a user to understand the nature of data access for given data artifacts (e.g., the query can be labelled “view stack” or “federation”). Similarly, such queries may be defined for a user and a user can simply select the appropriate query (where information about the query, at least as to what benefit might be achieved by selecting one query over another, can be provided). In other cases, some or all of the criteria described for the switch views 250, 252 can be used to define (or modify) a query. For instance, data artifacts can be named using standard naming conventions. When a query is received, the switching rules/criteria can be used to select the relevant data artifact names to be used in query execution. [38-47 & 80-83] elaborate on the matter [FIG.1 & 15] shows corresponding visual) determining, by the lifecycle database, a queried model artifact among the model artifacts using the corresponding connectors, wherein the queried model artifact is linked to the queried model; (Buchmann [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances.[0038] a data model or a data query are created, particular data components (such as a field of a database table) are associated with a particular data source, and data model artifacts and data queries can be created in a manner appropriate for the relevant data source or sources. [0044] In a particular implementation, switching between data artifact instances can be accomplished using a switch view. The switch view can have conditional statements, where the conditions define which of the multiple available data artifacts are used for a given data request (e.g., a query). For instance, a query, such as in SQL, can reference the switch view. Elements in the query (e.g., operations specified in the query, data sources specified in the query, parameters specified in the query, such as values used to filter data, or combinations therefore) or semantic flags in the query (e.g., “using data artifact X,” “with federation,” “using local,” “time sensitive,” “use recent data”) can be used to determine which of the multiple instances of the data artifact should be used for processing the query.[0047] In a yet further example, multiple queries (or requests, more generally) can be defined, where each query provides a different combination of access techniques for data artifacts in the query. [0080] FIG. 3 is similar to FIG. 2, in that it includes a data model 300 and a schema 330, such as a schema of runtime data artifacts. The data model 300 is slightly more complex than the data model 200, in that the data model 300 includes a query modelling artifact 308 in addition to a cube modelling artifact 312, and a table or view artifact 316 (or other type of data artifact, construct, or object). [57-66] elaborate on the matter [FIG.1 &15] shows corresponding visual) importing the at least queried part of the queried model from the data storage platform to the engineering database using the queried model artifact and the corresponding connectors; and amending the at least queried part of the queried model in the engineering database upon request of the user of the engineering database. (Buchmann [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances. [0038] a data model or a data query are created, particular data components (such as a field of a database table) are associated with a particular data source, and data model artifacts and data queries can be created in a manner appropriate for the relevant data source or sources. However, complications can arise when it is not clear how data access/data sources should be structured, such as when a data model is imported.[0044] In a particular implementation, switching between data artifact instances can be accomplished using a switch view. The switch view can have conditional statements, where the conditions define which of the multiple available data artifacts are used for a given data request (e.g., a query). For instance, a query, such as in SQL, can reference the switch view. Elements in the query (e.g., operations specified in the query, data sources specified in the query, parameters specified in the query, such as values used to filter data, or combinations therefore) or semantic flags in the query [0047] multiple queries (or requests, more generally) can be defined, where each query provides a different combination of access techniques for data artifacts in the query. Thus, a user or process need simply select the appropriate query for execution without needing to construct the query or have detailed knowledge of the relevant schema. Selection can be indirect, such as selecting user interface elements providing criteria that are tied to flags indicating what type of query should be selected. In particular, a user interface screen can provide a user with options to define a query [0057] A federated data artifact 120c is similar to the replica data artifact 120b, but the data is not permanently stored in the data store. Although, replicated data can be subject to deletion or modification, (such as by a source data artifact, from which data is replicated to the data store 108, or through deletion of the replica data artifact) stored in the data store 108. That is, federated data can be obtained from a data artifact 124 in a data store 128 of a remote system 130 and used for a particular purpose (e.g., a query) [131-140] elaborate on the matter [FIG.1 &15] shows corresponding visual)
Corresponding product claim 17 is rejected similarly as claim 5 above
Regarding claim 6, Desai and Buchmann teach The computer-implemented method of claim 1, further including: updating the respective lifecycle information including the respective model artifact stored in the lifecycle database and/or stored in the data storage platform upon amendment of the respective lifecycle information including the respective model artifact stored in the engineering database by the user of the engineering database using the respective connectors; (Buchmann [0018] FIG. 2 is a diagram illustrating how multiple instances of a data artifact corresponding to a modelling artifact can be used with switching logic in executing data access requests. [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances.[0053] The modelling schema 112 can include, as shown, a number of hierarchically arranged artifacts 116 (for instance, modelling artifacts). The artifacts 116 can build upon one another, such as having a higher-level artifact selecting data from lower-level artifacts, and optionally supplementing or altering aspects of the lower-level artifacts...[0062] One other type of data artifact definition (and optionally data artifacts, not shown, in the data 118) in the data dictionary 132 is a virtual artifact definition 148. A virtual artifact definition 148 can include a definition of a structure of a data artifact (whether local or remote) and can indicate where the data is located, such as with a logical pointer. The value of the logical pointer can be updated, such as dynamically, to point to different data artifacts, including at different locations, holding data that should be used when the data artifact is used, such as in a query. For example, a logical pointer can be updated to point to a replicated data artifact [90-97] elaborate on the matter [FIG.1 & 15] show the corresponding visual) and updating the respective engineering information including the respective model stored in the data storage platform upon amendment of the respective engineering information including the respective model stored in the engineering database by the user of the engineering database using the respective connectors. (Desai [0137] Methods for selecting eco system features for inclusion in each of an enabling tier, a service tier, and a personalization tier may include analyzing ecosystem participants, service requirements, customer requirements, regulatory requirements, transaction security requirements, trust models, and electronic transaction communication channels to determine ecosystem features to configure in a service tier, an enabling tier, and a personalization tier to ensure satisfaction of each analyzed requirement within the context of a service provider business model. Features may be similarly determined for additional tiers, such as expert engine and experience framework tiers.[0270] In accordance with exemplary and non-limiting embodiments, widgets 2306 stored and capable of running within the secure environment of the client container 2302 may be updated for any of a variety of purposes (e.g. periodically, such as weekly, to provide current pricing or offers, increase a spending limit, in response to a user request, to improve security, to add access to a different trust model, and the like [0438] The mobile transaction processing system as described herein for providing an ecosystem for secure personalized transactions may facilitate trust model determination for a mobile transaction. Model determination may include configuring a plurality of servers deployed in a network to facilitate transactions between a client device and a provider-specific server via any of a plurality of trust models including a single trust domain, a single trust cluster, multiple trust clusters, and a direct trust relationship. Model determination may further include...[521-526] elaborate on the matter [FIG.1 & 3] shows the corresponding steps)
Corresponding product claim 18 is rejected similarly as claim 6 above.
Regarding claim 9, Desai and Buchmann teach The computer-implemented method of claim 1, wherein providing the engineering information in a data storage platform includes: creating the model in the engineering database upon request of the user of the engineering database; (Desai [0013] Aspects of a secure multi-domain ecosystem environment may extend the environment to the consumer. Once a consumer is authenticated into such an environment one may have the ability to establish trust models that may enable delivery of a particular instance of services by a single trust model. Other products/services may be delivered by the use of other trust models.[0014] Also, the methods and systems herein may facilitate extending a security tunnel to merchants that may be embodied as a tunnel within a tunnel, which may enable a core security architecture. In this way businesses can avoid getting bogged down with security rather than focusing on applications that will provide a sustainable business model. In an example, the methods and systems herein may enable a business person to look at the frequency of use of applications (e.g., 3.times./day vs. 3.times./month) to help envision a significantly different trust model for each of a range of different user interaction models.[0265] In accordance with exemplary and non-limiting embodiments, the use of more than one trust model may reflect differences in the environment in which the client device and associated widgets 2306 are deployed. As noted elsewhere herein, wallet and widget issuers may select one or more trust models when configuring elements of an ecosystem. For example, an issuer, perhaps comprising a service provider, may deploy a first widget 2306 to perform secure banking transactions over the air wherein the transactions have a first level of trust. The issuer may further, for example, deploy a second widget to perform secure banking transactions at a point of sale (POS) kiosk wherein the transactions have a second higher level of trust owing to the client devices proximity to the kiosk and/or access to independent verification of the user of the device. Either or both of these widgets may be deployed to a single client device and the selection of a widget for execution may be performed by the wallet 2304, such as based on the nature of the transaction as described, the security of the available OTA network, and the like.[270] user request, to improve security, to add access to a different trust model [430-438] elaborate on the matter [FIG.1 & 3] show corresponding visual) importing the model artifact from the lifecycle database to the engineering database; (Buchmann [0008] a data access request, where a selection is made between two or more instances of a data artifact to be used in executing the data access request. A first data access request is received. The first data access request specifies at least a first data artifact in a hierarchy that includes a plurality of data artifacts distributed among a plurality of levels of the hierarchy. At least a portion of the plurality of data artifacts have a plurality of different instances. Different instances of a data artifact specify data associated with the data artifact at different storage locations.[0011] In a further aspect, a method is provided for instantiating multiple data artifact instances corresponding to a modelling artifact. A modelling schema is received that includes a plurality of modelling artifacts distributed among a plurality of levels of a hierarchy [0020] FIG. 4 presents example code illustrating how artifacts can be annotated with information that facilitates the creation of multiple data artifact instances and processing of data access queries using such data artifact instances.[0048] Disclosed technologies can also facilitate implementing the disclosed flexible access techniques. For instance, given a particular schema as an input, a software process can create appropriate data artifact instances for an artifact of the input schema. For instance an artifact in a schema (a model or design time data artifact) can be used to instantiate a runtime data artifact referencing a lower-level artifact, a runtime data artifact providing access to data via replication or federation, and optionally switching logic or data artifacts (e.g., switching views). Default switching logic can also be provided. [40-48] elaborate on the matter[FIG.1 & 15] show corresponding visual) and creating a further connector linking the model to the model artifact stored in the engineering database, respectively. (Buchmann [0038] a data model or a data query are created, particular data components (such as a field of a database table) are associated with a particular data source, and data model artifacts and data queries can be created in a manner appropriate for the relevant data source or sources. However, complications can arise when it is not clear how data access/data sources should be structured, such as when a data model is imported. In addition, typical data models are static in how they reference associated data. This can limit flexibility, such as when different circumstances would benefit from having different options for accessing data. Accordingly, room for improvement exists.[0054] The data store 108 can include data 118, such as data stored in various data artifacts 120 (shown as 120a-120d), such as tables or views in a relational database system (serving as the data store). In other cases, the data artifacts do not directly store the data, but provide access to data. For example, the data artifacts can be objects in a virtual data model that are mapped to data in data sources such as tables or views in a relational database system (or other sources of structured, semi-structured, or unstructured data). In other cases, the data artifacts can be physical tables or views, or similar constructs in other sources of structures, semi-structured, or unstructured data.[0065] The data model 200 can be translated into a schema 230 of runtime data artifacts (where at least some of the data artifacts are instantiated as two, or more, different instances, which together are referred to collectively as a “data artifact” for ease of presentation, as each instance corresponds to a common artifact, which just the source of data differing between the instances). The runtime data artifacts can represent data artifacts in a virtual data model or in a physical data model associated with one or more data sources. For instance, the data artifacts can represent virtual data artifacts that are mapped to (i) physical data artifacts, (ii) physical data artifacts, (iii) or a combination of (i) and (ii). Examples of physical data artifacts includes database tables and database views. Examples of virtual data artifacts include definitions of virtual tables, virtual views, or artifacts or data that modify how the virtual tables or views store data or are processed. Views can include views that provide a definition of an OLAP cube, such as view on a star or snowflake schema of a database, or a view on top of another view that is defined with respect to a star or snowflake schema. [0080] FIG. 3 is similar to FIG. 2, in that it includes a data model 300 and a schema 330, such as a schema of runtime data artifacts. The data model 300 is slightly more complex than the data model 200, in that the data model 300 includes a query modelling artifact 308 in addition to a cube modelling artifact 312, and a table or view artifact 316 (or other type of data artifact, construct, or object). [48-54] elaborate on the matter [FIG.1 & 15] show corresponding visual)
Regarding claim 10, Desai and Buchmann teach The computer-implemented method of claim 1, wherein at least two of the engineering database, the lifecycle database, and the data storage platform are located remotely from each other and/or separated from each other by at least one firewall. (Desai [0099] The mClient runtime 402 may include a database component 440. The database 440 may provide services to store, update, remove and find data from a local database. [0158] A secure ecosystem infrastructure that may enable multiple types of electronic wallets in a multi-domain ecosystem of issuers, service providers, and acquirers of instruments may include client-side functionality including a wallet container operable on a mobile device that facilitates isolation of a plurality of distinct wallets and further facilitates accessing each distinct wallet through widget modules configured into the wallet container and securely maintained as separate modules, wherein each widget must be authenticated to access any wallet. Such an ecosystem infrastructure may also include personalized service provider modules operating remotely from the mobile device and distinctly from each other wherein a service provider module communicates [384] device operating in a remote environment. The communication link may be an wired communication link, a wireless communication link, an NFC link, a Bluetooth link, a local area network link, a wide area network link or the like. [0548] The methods and systems described herein may be deployed in part or in whole through a machine that executes computer software on a server, client, firewall...[392-401] elaborate on the matter [FIG.1 & 3] show corresponding visual)
Claims 7,8,11,12, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20140130035 A1; Desai; Mehul et al. (hereinafter Desai) in view of US 20230315734 A1; Buchmann; Daniel et al. (hereinafter Buchmann) and US 20220414157 A1; OLINER; Adam et al. (hereinafter Oliner).
Regarding claim 7, Desai and Buchmann teach The computer-implemented method of claim 1 the combination lack explicitly and orderly teaching further including:receiving information on a deficiency of a deficient variant of the physical system family; determining the deficient model, a deficient model artifact, or the deficient model and the deficient model artifact of the deficient variant that is related to the received information on the deficiency; determining one or more affected models among the models and one or more affected model artifacts among the model artifacts linked via the corresponding connectors to the deficient model and/or the deficient model artifact that is/are related to the received information on the deficiency; and outputting the one or more affected models, the one or more affected model artifacts, or the one or more affected models and the one or more affected model artifacts. However Oliner teaches receiving information on a deficiency of a deficient variant of the physical system family; determining the deficient model, a deficient model artifact, or the deficient model and the deficient model artifact of the deficient variant that is related to the received information on the deficiency; (Oliner [0057] Beyond storing the models themselves, model repositories often include metadata associated with each ML model. The primary goal of this metadata is to facilitate a full understanding of the lineage/provenance for any given ML model; this metadata is commonly used for model reproducibility (i.e., can we understand how to reproduce a given ML model “from scratch”?) as well as the experimentation part of model development workflows (e.g., “what training algorithm configurations have I already tried and what were their performance metrics?”). In a VCS, these would take the form of comments and experiment logs explaining the relationship between code changes and bugs/performance effects. In a model repository, metadata instead includes things such as hyperparameters used to configure model training algorithms as well as statistical quality metrics for the model's performance on some reference dataset.[0069] Second, the performance of ML models is usually driven by statistical algorithms; this has a few notable ramifications: one can often only make statistical claims (instead of absolute claims) about whether an ML model meets business requirements. This drives corollary requirements for supporting systems: testing infrastructure needs to ensure that the input domain for an ML model is sufficiently represented by validation data to validate coverage of requirements. ML model monitoring infrastructure also needs to track the statistical distributions of input data to compare against the distributions of the training/validation datasets (discrepancies between these two are often called “feature drift”). Finally, to mitigate the impact of issues like feature drift, there needs to be a higher-level continuous retraining pipeline that orchestrates the collection and labeling of relevant samples, trains new versions of affected models, and deploys them to production if they pass validation requirements. [69-78] elaborate on the system [FIG.5] shows corresponding visual) determining one or more affected models among the models and one or more affected model artifacts among the model artifacts linked via the corresponding connectors to the deficient model and/or the deficient model artifact that is/are related to the received information on the deficiency; (Oliner [0024] The following terms are used in this disclosure: [0025] Raw Data (also called Natural Data): Unstructured data, such as images, video, audio, text, and graphs in a native (non-augmented) form at the time of system ingestion. [0026] Data Source: A user-specified mechanism for providing data to be processed. Examples include SQL tables, JSON or CSV files, S3 buckets and the like. FIG. 1 shows data sources 150_1 through 150_N. [0027] Connector: A persistent service which pulls new data from a specified Data Source at regular intervals. [0036] FIG. 2 illustrates the process to form the entity database 142. The raw data processor 141 includes an entity builder 200 with instructions executed by processor 130. The entity builder 200 instantiates connectors 202. That is, the user at client machine 102_1 logs into the raw data processor 141. If this is the first time, a unique username is created for the user. This information, along with metadata for the user account is stored in memory 140. A connection manager allocates storage space for connectors and schedules the times that the connectors are operative 204. The Entity Builder 200 allocates storage space for entities in the Entities database 142 [36-41] elaborates on the matter [FIG.1 &2] shows corresponding visual) and outputting the one or more affected models, the one or more affected model artifacts, or the one or more affected models and the one or more affected model artifacts. ( Oliner [0020] FIG. 1 illustrates a system 100 configured in accordance with an embodiment of the invention. The system 100 includes a set of client devices 102_1 through 102_N that communicate with a server 104 via a network 106, which may be any combination of wired and wireless networks. Each client device includes a processor (e.g., central processing unit) 110 and input/output devices 112 connected via a bus 114. The input/output devices 112 may include a keyboard, mouse, touch display and the like. A network interface circuit 116 is also connected to the bus 114. The network interface circuit 116 provides connectivity to network 106. [0079] An executor is a piece of code and an environment in which that code is run which takes one or more artifacts as inputs and produces a new artifact as an output. The model repository uses containers as its implementation of executors, though other implementations are possible as well. Examples of executors include: (1) a container which takes three artifacts: a training dataset, a transformer architecture, and a set of hyperparameters and when run produces a BERT-style model, (2) a container which takes a set of training data, and through some statistical process augments that training set with new examples. In FIG. 5, the blocks 500, 504, 508, 512 and 516 are executors. [0095] The computation of some metadata (e.g., the performance of a model on a reference data set) may suffer from the same performance obstacles described above. In some sense, one can think of metadata as the output of an execution which is implicitly defined by the model repository. In this sense, the solution is the same: metadata is cached according to an implementation-specific policy to reduce the overhead of handling queries which might otherwise require an arbitrarily large amount of computation. [76-83] elaborate on the matter [FIG.1 & 5] show corresponding visuals) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Oliner in order to efficiently identify issues/deficiencies and resolve them (Oliner [0044] The user can optionally enable continuous pre-training for trunk models. This uses the data in the Entity Database 142 as inputs to an unsupervised training procedure. The flow for this process is identical to that of enrichment training. Supervised pre-training may also be utilized. For example, the trunk model may be updated with the aim of improving performance on one or more specific tasks.[0070] Finally, ML models often require specialized hardware for efficient execution. Both development and deployment infrastructure as well as a model repository must have access to this specialized hardware [0057] Beyond storing the models themselves, model repositories often include metadata associated with each ML model. The primary goal of this metadata is to facilitate a full understanding of the lineage/provenance for any given ML model; this metadata is commonly used for model reproducibility (i.e., can we understand how to reproduce a given ML model “from scratch”?) as well as the experimentation part of model development workflows (e.g., “what training algorithm configurations have I already tried and what were their performance metrics?”). In a VCS, these would take the form of comments and experiment logs explaining the relationship between code changes and bugs/performance effects. In a model repository, metadata instead includes things such as hyperparameters used to configure model training algorithms as well as statistical quality metrics for the model's performance on some reference dataset. [0076] At a high level, the disclosed model repository can be thought of as a typed version control system which tracks not only artifacts, but the arbitrary computations that produced them. Traditional VCSs are defined in terms of a single type of artifact: code. They have mechanisms for tracking changes to code, and code-specific strategies for resolving conflicts when two or more users make different changes to code (e.g., if two different users add different lines of code, accept both, but if two users edit the same line of code, ask the owner of the code to choose which they prefer). The disclosed model repository tracks multiple different types of artifacts: models, datasets, etc. and has type-specific strategies for dealing with conflicts. For example, it has different strategies for resolving conflicts when two users edit the same dataset as when two users modify the same hyperparameter. [69-76] elaborate on the matter)
Corresponding product claim 19 is rejected similarly as claim 7 above
Regarding claim 8, Desai, Buchmann and Oliner teach The computer-implemented method of claim 7, further including:amending the deficient model, the deficient model artifact, or the deficient model and the deficient model artifact intended to remedy the deficiency upon request of the user of the engineering database; (Oliner [0057] Beyond storing the models themselves, model repositories often include metadata associated with each ML model. The primary goal of this metadata is to facilitate a full understanding of the lineage/provenance for any given ML model; this metadata is commonly used for model reproducibility (i.e., can we understand how to reproduce a given ML model “from scratch”?) as well as the experimentation part of model development workflows (e.g., “what training algorithm configurations have I already tried and what were their performance metrics?”). In a VCS, these would take the form of comments and experiment logs explaining the relationship between code changes and bugs/performance effects. In a model repository, metadata instead includes things such as hyperparameters used to configure model training algorithms as well as statistical quality metrics for the model's performance on some reference dataset.[0076] At a high level, the disclosed model repository can be thought of as a typed version control system which tracks not only artifacts, but the arbitrary computations that produced them. Traditional VCSs are defined in terms of a single type of artifact: code. They have mechanisms for tracking changes to code, and code-specific strategies for resolving conflicts when two or more users make different changes to code (e.g., if two different users add different lines of code, accept both, but if two users edit the same line of code, ask the owner of the code to choose which they prefer). The disclosed model repository tracks multiple different types of artifacts: models, datasets, etc. and has type-specific strategies for dealing with conflicts. For example, it has different strategies for resolving conflicts when two users edit the same dataset as when two users modify the same hyperparameter.[0096] The disclosed model repository supports many of the same core operations provided by a VCS. The key difference is that these operations are reframed in the context of providing access to typed artifacts as opposed to just source code. The user requests versioned artifacts from the repository and describes the changes they wish to persist by providing the repository with an execution. Key to this process is that the model repository has different strategies for tracking changes to and resolving conflicts between changes to artifacts of different types. [69-76] elaborate on the matter [FIG.5] shows corresponding visual) and propagating the amendment of the deficient model, of the deficient model artifact, or of the deficient model and the deficient model artifact to the one or more affected models, the one or more affected model artifacts, or the one or more affected models and the one or more affected model artifacts using the corresponding connectors. (Oliner [0036] FIG. 2 illustrates the process to form the entity database 142. The raw data processor 141 includes an entity builder 200 with instructions executed by processor 130. The entity builder 200 instantiates connectors 202. That is, the user at client machine 102_1 logs into the raw data processor 141. If this is the first time, a unique username is created for the user. This information, along with metadata for the user account is stored in memory 140. A connection manager allocates storage space for connectors and schedules the times that the connectors are operative 204. The Entity Builder 200 allocates storage space for entities in the Entities database 142 [0038] The user defines one or more connectors which point to their data (instantiate connectors 202). This data could be multi-modal and reside in very different data stores (e.g., an S3 bucket versus a SQL table). A Data Source is an abstract representation of a pointer to a user's data. Data Sources can contain user login credentials, as well as metadata describing the data (e.g., the separator token for a csv file). Once the user has configured a Data Source, that Data Source can be used to create a Connector.[0076] At a high level, the disclosed model repository can be thought of as a typed version control system which tracks not only artifacts, but the arbitrary computations that produced them. Traditional VCSs are defined in terms of a single type of artifact: code. They have mechanisms for tracking changes to code, and code-specific strategies for resolving conflicts when two or more users make different changes to code (e.g., if two different users add different lines of code, accept both, but if two users edit the same line of code, ask the owner of the code to choose which they prefer). The disclosed model repository tracks multiple different types of artifacts: models, datasets, etc. and has type-specific strategies for dealing with conflicts. For example, it has different strategies for resolving conflicts when two users edit the same dataset as when two users modify the same hyperparameter.[0111] Datasets can be represented as ordered lists of tuples. Two datasets which contain tuples of different arity are incompatible and the conflict must be resolved manually. Conflicts between datasets with identical arity tuples can be identified by checking for additions, deletions, and modifications [36-41 &106-112] elaborates on the matter [FIG.1 &2] shows corresponding visual)
Corresponding product claim 20 is rejected similarly as claim 8 above
Regarding claim 11, Desai, Buchmann and Oliner teach The computer-implemented method of claim 7, further comprising:engineering, modeling, simulating, analyzing, producing and/or operating the variant of the physical system family using the variant engineering information, the variant lifecycle information, and the corresponding connectors (Buchmann [0011] In a further aspect, a method is provided for instantiating multiple data artifact instances corresponding to a modelling artifact. A modelling schema is received that includes a plurality of modelling artifacts distributed among a plurality of levels of a hierarchy. It is determined that a plurality of instances of a first data artifact corresponding to a first modelling artifact of the plurality of modelling artifacts are to be created. A first instance of the first data artifact is instantiated. The first instance of the first data artifact is instantiated at a first level of a hierarchy of a data artifact schema that includes data artifacts corresponding to at least a portion of the plurality of modelling artifacts. The first instance of the first data artifact includes first data, or indicates a source of first data corresponding to the first data artifact.[0017] FIG. 1 is a diagram illustrating a computing architecture having a hierarchical modelling schema and data artifacts corresponding to artifacts in the modelling schema.[0018] FIG. 2 is a diagram illustrating how multiple instances of a data artifact corresponding to a modelling artifact can be used with switching logic in executing data access requests. [0052] The client system 104 includes a modelling schema 112. The modelling schema 112 can be, in some cases, a virtual data model. In other cases, the modelling schema 112 can be a design time construct that is used to create corresponding runtime artifacts, which can include creating artifacts in a virtual data model or in the data store 108. When a virtual data model is used, artifacts in the virtual data model can reference corresponding artifacts in the data store 108.[0090] For example, logic can be implemented that automatically creates data artifact instances for a modelling artifact. Such action can be explicitly requested. For example, a command or user process can call functionality to create data artifact instances for artifacts in a particular artifact schema or for selected artifacts. Or, a schema or artifacts in the schema can have annotations indicating that data instances should be created. Instructions to create data artifact instances can include information usable to help determine the nature of the data artifact instances, to configure logic used to select between data artifact instances, and to establish relationships between data artifacts and data artifact instances at different levels of a hierarchy of data artifacts. A schema can be analyzed to determine which artifacts have been selected for data artifact instance creation, and suitable data artifacts (and optionally switching logic) created. [109-117] elaborate on the matter[FIG.1 & 15] show the corresponding visual)
Regarding claim 12, Desai and Buchmann teach The computer-implemented method of claim 11, further comprising: stopping producing or operating the affected variant of the physical system family. (Desai [173] the wallet may be suspended. In an example, the wallet may stop executing [0199] In accordance with the exemplary and non-limiting embodiments, the present disclosure describes a use case Suspend Widget, wherein the widget state may be transitioned to SUSPENDED and it may no longer be actively downloaded. In an example, the EOE may log into the MTP system management console and select a link for suspending widgets in the widget management section. The system may show all widgets in the PUBLISHED state and the EOE may select a widget to suspend the widget. The EOE may enter any comments/remarks and select a SUSPEND publish. Further, the system may prompt for confirmation and the EOE may confirm the suspension of the widget. Accordingly, the system may change the state of widget to SUSPENDED and may confirm that the widget has been suspended. In an example, the system may generate an email notification to the service provider that the widget has been suspended. [209] Status may identify status (e.g., created, activated, suspended, and the like [257] wallets are resident is shut off or when a user has deactivated a wallet (e.g. for enhanced security of the wallet resources), an associated widget may be limited from accessing client device and network resources, wallet content, and the like normally controlled by or accessed through the wallet.[0341] In an example, the PoS terminal may perform various processing operations while performing a transaction. The PoS terminal may format the SELECT command as discussed above and may verify the formatting of the FCI that may be included in the response message of the SELECT command. In an example, the PoS terminal may verify the formatting of the FCI in accordance with the table CAT12. If it may be detected that the FCI is not formatted in accordance with the table CAT 12, the PoS terminal may terminate processing and ensure de-selection of the applet. [342-347] elaborate on the matter [FIG.1 & 35] show corresponding visual)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARYAN D TOUGHIRY whose telephone number is (571)272-5212. The examiner can normally be reached Monday - Friday, 9 am - 5 pm.
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, Aleksandr Kerzhner can be reached at (571) 270-1760. 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.
/ARYAN D TOUGHIRY/Examiner, Art Unit 2165
Prosecution Insights