DETAILED ACTION
Claims 1-20 are pending.
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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
As per claim 1, in step 1 of the 101 analysis, the examiner has determined that the claim is directed to an apparatus. Therefore, the claim is directed to one of the four statutory categories of invention.
In step 2A prong 1 of the 101 analysis, the examiner has determined that the claim recites a judicial exception. Specifically, the limitation “resolving the encoded data to identify the structure name; based on the structure name, accessing the registered structure having the structure name; and decoding the encoded data according to the accessed structure, wherein the decoding includes generation of a first value that corresponds to a first data element of the encoded data, and the first value is generated such that the first value is formatted according to a first attribute mapped to the first data element in the accessed structure” recite mental processes. Determining which table to use and use it to translate an encoded message constitutes a mental process of observation, evaluation, and judgement because a human with the aid of pen and paper can convert a message using a table or codebook that correlates encoded data to a definition.
In step 2A prong 2 of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not integrate the judicial exceptions into a practical application for the following rationale:
The limitations “a first application”, “a second application”, “a non-transitory computer-readable medium” (claim 12) and “one or more processors” (claim 12) apply judicial exceptions on a generic computer. "Alappat 's rationale that an otherwise ineligible algorithm or software could be made patent-eligible by merely adding a generic computer to the claim was superseded by the Supreme Court's Bilski and Alice Corp. decisions" so therefore applying judicial exceptions on a generic computer do not integrate the judicial exceptions into a practical application (MPEP 2106.05(b)).
The limitation “registering a structure” and “receiving, at the second application, encoded data from the first application, wherein the encoded data includes values for the data elements encoded according to the structure and the encoded data includes an indication of the structure name” represent insignificant, extra-solution activities. The term "extra-solution activity" can be understood as "activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim" (MPEP 2106.05(g)). The examiner has determined that the limitation is directed to mere data gathering activities and data transmission which are categories of insignificant extra-solution activities (MPEP 2106.05(g)).
In step 2B of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not recite significantly more than the abstract ideas identified above for the following rationale:
The limitations “a first application”, “a second application”, “a non-transitory computer-readable medium” (claim 12) and “one or more processors” (claim 12) apply judicial exceptions on a generic computer and therefore do not provide significantly more.
The limitation “registering a structure” and “receiving, at the second application, encoded data from the first application, wherein the encoded data includes values for the data elements encoded according to the structure and the encoded data includes an indication of the structure name” represent insignificant, extra-solution activities and are well-understood, routine, or conventional because they are directed to "receiving or transmitting data" (MPEP 2106.05(d)). These are additional elements that the courts have recognized as well understood, routine, or conventional (MPEP 2106.05(d)). The citation of court cases in the MPEP meets the Berkheimer evidentiary burden since citation of a court case in the MPEP is one of the 4 types of evidentiary support that can be used to prove that the additional elements are well-understood, routine, or conventional (see 125 USPQ2d 1649 Berkheimer v. HP, Inc.). Thus, the limitations do not amount to significantly more than the abstract idea.
Considering the additional elements individually and in combination and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. The claim is not patent eligible.
As per claim 12, it is a media type claims of claim 1, so it is rejected for the same reasons as claim 1.
As per claims 2 (and similarly for claims 13), they recite similar limitations as those described in claim 1, with an additional structure. These limitations do not provide significantly more than the abstract idea and only describe the generic computing components.
As per claims 3, (and similarly for claim 14), they recite limitations that further explain the format of the encoded data as received in claim 1. As such, these claims do not provide significantly more than the abstract idea and the analysis for claim 1 applies.
As per claims 4, (and similarly for claim 15), they recite limitations that further explain the approach to not being able to decode the encoded data as received in claim 1 due to not having the associated structure registered to perform the conversion. As such, these claims do not provide significantly more than the abstract idea and the analysis for claim 1 applies.
As per claims 5, (and similarly for claim 16), they recite limitations that further discuss the structure version of the structure in claim 1. As such, these claims do not provide significantly more than the abstract idea and the analysis for claim 1 applies.
As per claims 6, (and similarly for claim 17), they recite limitations that further explain the resolving step identified above as abstract idea. The resolving step constitutes a mental step as it is used to determine the version of the registered structure used to convert the encoded message. As such, these claims do not provide significantly more than the abstract idea.
As per claims 7, (and similarly for claim 18), they recite limitations that further discuss the format of the received data in claim 1. As such, these claims do not provide significantly more than the abstract idea and the analysis for claim 1 applies.
As per claims 8, (and similarly for claim 19), they recite limitations that further discuss the additional structure for modified mappings used for converting encoded data. As such, these claims do not provide significantly more than the abstract idea.
As per claim 9, it recite limitations that further discuss the content of the encoded data. As such, this claim does not provide significantly more than the abstract idea.
As per claims 10-11, they recite limitations that further discuss the generic computing components used to apply the abstract idea. As such, these claim does not provide significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 8-13, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (US 2007/0005613 A1).
Regarding claim 1, Singh teaches the invention substantially as claimed including a method of dynamic structured data communication between a first application and a second application ([0003] Applications need to communicate with other heterogeneous systems when performing tasks. These heterogeneous systems may use data in a format that is different from the internal format of the host application. In order to be able to process information received in the different data format, the host-application may have to parse the external data format to its own internal data format. The host application can then process the parsed information in the internal data format. After processing, the processed information is then built into the external data format. Accordingly, the software application can then effectively communicate with external heterogeneous systems that process data in a different data format than the internal data format used by the software application.; Fig. 11 system 1006; [0118] Parse/build engine 1004 is configured to receive an input message stream 1010 from a system 1006 and parse the message into an internal message format. The internal message format (IMF) may then be processed by other components, such as a business services application shown in gateway 104; wherein system 1006 corresponds to the first application and the business service application corresponds to the second application), the method comprising:
registering a structure, wherein the structure is defined for data communication between a first application and a second application, the structure includes a structure name and a mapping between data elements and attributes related to the data elements, and the structure is registered such that the structure is accessible to the second application ([0142] In step 1406, the schemas in schema definition files 1026 are loaded into registry 1022 from disk or other storage repository into DRAM memory using schema loader 1024.; [0122] For each message format that may be parsed and built by parse/build engine 1004, a corresponding schema may be provided. Each schema name is associated with a schema object that defines the “grammar,” the composition of a message stream in the external format. The composition may include a field sequence, field type, length, character encoding, and other fields that are optional or required.; [0130] These field definitions describe the properties of the field, such as field sequence, field type, length, character encoding, the names of the hander needed, etc.; [0123] The business services application also provides the schema name 1011 to parser component 1016.);
receiving, at the second application, encoded data from the first application, wherein the encoded data includes values for the data elements encoded according to the structure and the encoded data includes an indication of the structure name ([0118] Parse/build engine 1004 is configured to receive an input message stream 1010 from a system 1006 and parse the message into an internal message format. The internal message format (IMF) may then be processed by other components, such as a business services application shown in gateway 104. [0119] Systems 1006 and 1008 may send/receive messages in many different formats such as ISO 8583 messages, extensible mark-up language (XML), HTML, etc. The input message stream may also be in any of multiple encoding schemes, such as ASCII, EBCDIC, BCD, etc., and have different data types, such as numeric, string, byte-array etc.; [0122]; [0123] An example flow will now be described. As shown in FIG. 11, when a message is received, a business services program calls the parse/build engine 1004. The message 1010 (a message stream in wire format) is sent to the parse/build engine, where it is first received by parser component 1016. The business services application also provides the schema name 1011 to parser component 1016. The parser component creates an internal message format (IMF) object in which to store the values from the message fields once they are translated into the IMF. In one embodiment, parser component 1016 recognizes the origin of message 1010 and determines which schema is needed for messages 1010 sent from the origin. In another embodiment, information in message 1010 may be parsed to determine the data format and thus a corresponding schema that should be used. Further, message 1010 may indicate which schema corresponds to the data format.);
resolving the encoded data to identify the structure name ([0122] Schema table 1026 includes various schemas, labeled schema name 1, name 2, . . . , name N. For each message format that may be parsed and built by parse/build engine 1004, a corresponding schema may be provided. Each schema name is associated with a schema object that defines the "grammar," the composition of a message stream in the external format.; [0123] In one embodiment, parser component 1016 recognizes the origin of message 1010 and determines which schema is needed for messages 1010 sent from the origin. In another embodiment, information in message 1010 may be parsed to determine the data format and thus a corresponding schema that should be used. Further, message 1010 may indicate which schema corresponds to the data format.);
based on the structure name, accessing the registered structure having the structure name ([0124] In one example, the parser component 1016 first looks up a root schema corresponding to the format of message detected, such as an ISO 8583 financial message.); and
decoding the encoded data according to the accessed structure, wherein the decoding includes generation of a first value that corresponds to a first data element of the encoded data, and the first value is generated such that the first value is formatted according to a first attribute that is mapped to the first data element in the accessed structure ([0132] A first data format attribute 1208 is the data format for the value of the field as found in the external format (also referred to as the wire-format). A second data format attribute 1210 is the internal format in which the field is stored in the IMF and processed by the business services.; [0156] In step 1608, the handler translates the fields of the message. A handler for each field is invoked. The handlers use the field definitions in the schema to translate values of the fields into the IMF.; [0163] In step 1710, the value is translated from the field in IMF object 1018 according to the attributes of the field definition for the field. Accordingly, a value found in the IMF format is translated into a format compatible with another system.).
Singh does not explicitly teach a first application it does teach a first system as the one shown in Fig. 11 labeled 1006. However, Singh does teach in [0003] “Applications need to communicate with other heterogeneous systems when performing tasks. These heterogeneous systems may use data in a format that is different from the internal format of the host application…Accordingly, the software application can then effectively communicate with external heterogeneous systems that process data in a different data format than the internal data format used by the software application.” And [0119] “Systems 1006 and 1008 may be any system that is configured to send messages 1010 and/or receive messages 1012 from parse/build engine 1004 (or gateway 104). In one embodiment, systems 1006 and 1008 may be point of sale devices, smart card devices, transaction processors 108, any system configured to process transactions, such as an acquirer, issuer, a service provider, a transaction authenticator, etc”. As such, one of ordinary skill in the art would have understood Singh’s system to encompass applications as a point of sale system/app may need to communicate with applications such as Visa to deduct payment from a card etc, see at least [0034]. Accordingly, Singh reasonably teaches the limitation as claimed.
Regarding claim 2, Singh teaches further comprising:
receiving from the first application an additional structure, wherein the additional structure includes an additional structure name and an additional mapping between the data elements and the attributes related to the data elements ([0007] As formats change, new formats or changes to old formats can be dynamically added to the parse/build engine by loading new schema and handlers.; [0122] The schemas and any associated handlers not already loaded, may be loaded from schema definition file 1026 into schema table 1028 and handler table 1030 using the schema loader 1024. Schema table 1026 includes various schemas, labeled schema name 1, name 2, . . . , name N. For each message format that may be parsed and built by parse/build engine 1004, a corresponding schema may be provided. [0146] During run-time, schemas may be dynamically updated and added to parse/build engine 1004. The schemas may be updated by changing message definition objects or may be added by adding new message definition objects. If new handlers are needed, they may also be dynamically added to parse/build engine 1004 as compiled objects.);
registering the additional structure such that the additional structure is accessible to the second application ([0007]; [0122] The schemas and any associated handlers not already loaded, may be loaded from schema definition file 1026 into schema table 1028 and handler table 1030 using the schema loader 1024. Schema table 1026 includes various schemas, labeled schema name 1, name 2, . . . , name N. For each message format that may be parsed and built by parse/build engine 1004, a corresponding schema may be provided.);
receiving additional data from the first application, the additional data that is encoded according to the additional structure and the additional data includes an indication of the additional structure name ([0118] Parse/build engine 1004 is configured to receive an input message stream 1010 from a system 1006 and parse the message into an internal message format. The internal message format (IMF) may then be processed by other components, such as a business services application shown in gateway 104. [0119] Systems 1006 and 1008 may send/receive messages in many different formats such as ISO 8583 messages, extensible mark-up language (XML), HTML, etc. The input message stream may also be in any of multiple encoding schemes, such as ASCII, EBCDIC, BCD, etc., and have different data types, such as numeric, string, byte-array etc.; [0123] An example flow will now be described. As shown in FIG. 11, when a message is received, a business services program calls the parse/build engine 1004. The message 1010 (a message stream in wire format) is sent to the parse/build engine, where it is first received by parser component 1016. The business services application also provides the schema name 1011 to parser component 1016. The parser component creates an internal message format (IMF) object in which to store the values from the message fields once they are translated into the IMF. In one embodiment, parser component 1016 recognizes the origin of message 1010 and determines which schema is needed for messages 1010 sent from the origin. In another embodiment, information in message 1010 may be parsed to determine the data format and thus a corresponding schema that should be used. Further, message 1010 may indicate which schema corresponds to the data format.);
reviewing the received additional data to identify the additional structure name ([0123] In one embodiment, parser component 1016 recognizes the origin of message 1010 and determines which schema is needed for messages 1010 sent from the origin. In another embodiment, information in message 1010 may be parsed to determine the data format and thus a corresponding schema that should be used. Further, message 1010 may indicate which schema corresponds to the data format.);
based on the additional structure name, accessing the additional structure from a plurality of registered structures that includes both the additional structure and the structure ([0124] In one example, the parser component 1016 first looks up a root schema corresponding to the format of message detected, such as an ISO 8583 financial message.); and
decoding the additional data according to the accessed additional structure ([0132] A first data format attribute 1208 is the data format for the value of the field as found in the external format (also referred to as the wire-format). A second data format attribute 1210 is the internal format in which the field is stored in the IMF and processed by the business services.; [0156] In step 1608, the handler translates the fields of the message. A handler for each field is invoked. The handlers use the field definitions in the schema to translate values of the fields into the IMF.).
Regarding claim 8, Singh teaches further comprising receiving from the first application an additional structure, wherein:
the additional structure includes an additional structure name and a modified mapping ([0148] FIG. 16 depicts a simplified flowchart 1500 of a method for dynamically adding or updating a schema in parse/build engine 1004 according to one embodiment of the present invention. In step 1502, a request to dynamically add or update a schema is received from an application); and
the modified mapping includes the mapping of the structure except for a change to a first attribute related to a first data element of the data elements ([0146] During run-time, schemas may be dynamically updated and added to parse/build engine 1004. The schemas may be updated by changing message definition objects or may be added by adding new message definition objects. If new handlers are needed, they may also be dynamically added to parse/build engine 1004 as compiled objects.).
Regarding claim 9, Singh teaches wherein: the data elements include a username, a password, and a role name ([0034] A transaction may be a credit card authorization, debit card transaction or an electronic check transaction. Other examples of transactions include awarding of points or other rewards in an awards program, checking a password for a Verified by Visa authentication; [0041] In one example, clients 102 may include a point of sale (POS) device that receives user information, such as credit card information, a pin number, name, etc., for a credit card authorization, check card transaction, etc.; [0058]); and the attributes related to the data elements include a datatype of each of the username, the password, and the role name ([0130] parse/build fields encoded in different encodings like ASCII, EBCDIC, BCD etc., and different data types like numeric, string, byte-array etc.).
Regarding claim 10, Singh teaches wherein the first application is different from the second application ([0119] Systems 1006 and 1008 may be any system that is configured to send messages 1010 and/or receive messages 1012 from parse/build engine 1004 (or gateway 104). In one embodiment, systems 1006 and 1008 may be point of sale devices, smart card devices, transaction processors 108, any system configured to process transactions, such as an acquirer, issuer, a service provider, a transaction authenticator, etc; [0118] a business services application).
Regarding claim 11, Singh teaches wherein: the first application is installed at a first computing device ([0119] In one embodiment, systems 1006 and 1008 may be point of sale devices, smart card devices, transaction processors 108, any system configured to process transactions, such as an acquirer, issuer, a service provider, a transaction authenticator, etc.); the second application is installed at a second computing device ([0043] Gateway 104 includes a system configured to receive transactions from clients 102 and to route the transactions to transaction processors 108 through networks 106.); the first computing device is a management device ([0071] Administration module 218 is configured to allow for administrative actions to be performed. Administration module 218 may be used by a user agent to administer one or more gateways 104.); and the second computing device is a device managed by the management device ([0068] Also, coordinator 216 provides services for application management, software distribution, system monitoring and failover capabilities to gateway 104.).
Regarding claim 12, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 13, it is a media/product type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 19, it is a media/product type claim having similar limitations as claim 8 above. Therefore, it is rejected under the same rationale above.
Regarding claim 20, it is a media/product type claim having similar limitations as claim 9 above. Therefore, it is rejected under the same rationale above.
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (US 2007/0005613 A1) in view of Chen et al. (US 2017/0186311 A1).
Regarding claim 3, Singh teaches wherein: one of the attributes of the structure includes datatypes of the data elements ([0130] These field definitions describe the properties of the field, such as field sequence, field type, length, character encoding, the names of the hander needed, etc. The field definitions may be used to parse/build fields encoded in different encodings like ASCII, EBCDIC, BCD etc., and different data types like numeric, string, byte-array etc.);
the structure includes an identifier for each of the data elements ([0130] FIG. 13B shows an example schema. The address of the schema is the first line, the message definition (MessageDef). The schema includes grammar and pointers to handlers for each of the fields in the message. In the example shown, the first field of the message is identified by a Field Definition Object (FieldDef) 1202 with index 1.0.0. This is also referred to as an OID attribute 1202);
the data encoded according to the structure associates the data elements with the identifiers such that an order of the data does not affect the decoding ([0124] In one example, the parser component 1016 first looks up a root schema corresponding to the format of message detected, such as an ISO 8583 financial message. Such an ISO message may have a bitmap at the beginning which identifies which fields are present.).
Singh teaches XML but does not expressly teach the data is formatted according to JavaScript Object Notation (JSON).
However, Chen teaches interprocess communication between a first application and a second application. Further, Chen teaches the data is formatted according to JavaScript Object Notation (JSON) ([0025]; [0027] Furthermore, when the transmission path is the first transmission path 601, the second application 4063 further transforms the encoded data to a cloud encoded data in JavaScript Object Notation (JSON) format or eXtensible Markup Language (XML) format, so that the cloud encoded data in JSON format or XML format can be transmitted to the first device 300 by the cloud server 200.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chen with the teachings of Singh to utilize JSON format for communications. The modification would have been motivated by the desire of performing a simple substitution of a known element with another to obtain predictable results.
Regarding claim 14, it is a media/product type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Claims 4-6 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (US 2007/0005613 A1) in view of Papoutsis et al. (US 7,035,635 B2).
Regarding claim 4, Singh teaches wherein: the structure is registered at a handler engine ([0121] Parse/build engine 1004 loads the identified schema and invokes the functionality of handlers associated with the schema.; [0142] In step 1406, the schemas in schema definition files 1026 are loaded into registry 1022);
the accessing the structure includes searching the handler engine for the structure name at the handler engine ([0124] In one example, the parser component 1016 first looks up a root schema corresponding to the format of message detected, such as an ISO 8583 financial message); and
the decoding the encoded data is performed responsive to the structure name being registered at the handler engine ([0124] The parser component then looks up the schema for the message type identified, which in turn provides the particular grammar and points to handlers for that message type. Schema and handlers are looked up and called only for the fields actually present in the message).
Singh does not expressly teach responsive to the structure name not being registered at the handler engine, rejecting the encoded data.
However, Papoutsis teaches responsive to the structure name not being registered at the handler engine, rejecting the encoded data (Col. 1, line 58 through Col. 2, line 7: If the receiver of a message identifies a new element which it cannot decode (since, for example, it is defined in a newer version which the receiver does not yet know) and this element is identified as being critical, it should reject the message as being incomprehensible).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Papoutsis of rejecting a message due to not knowing a definition necessary to decode the message with the teachings of Singh. The modification would have been motivated by the desire of avoiding errors in decoding, minimize message overhead and minimizing delays (See Papoutsis Background).
Regarding claim 5, Singh teaches wherein: the structure further includes a structure version associated with the first application or the second application ([0150] in-flight messages being processed are not corrupted as a result of schema change. The in-flight messages continue to use the previous version of the schema while the Schema Loader 1024 loads the updated version of the schema).
In addition, Papoutsis teaches the encoded data includes a version indicator that is representative of a version of the encoded data (Col. 4, line 4-5: The second part contains the current version of the message).
Regarding claim 6, Papoutsis teaches further comprising: further resolving the encoded data to identify the version indicator (Col. 4. Lines 11-21: the receiver can immediately identify at the start of the decoding process whether it will understand this version);
determining whether the version indicated by the version indicator is either the version of the registered structure or an earlier version (Col. 1, lines 40-55: One important factor in the development of mobile radio systems is to ensure that each new version of a protocol is compatible with older versions. This ensures in particular that more recent subscriber terminals can be correctly identified and addressed in an environment of base stations which support an older protocol version and, conversely, the subscriber terminals which support an older protocol version still operate correctly in new network environments.); and
rejecting the encoded data responsive to the version being a later version than the version of the registered structure (Col. 1, line 58 through Col. 2, line 7: If the receiver of a message identifies a new element which it cannot decode (since, for example, it is defined in a newer version which the receiver does not yet know) and this element is identified as being critical, it should reject the message as being incomprehensible)), wherein: the decoding the encoded data is performed responsive to the version indicated the version indicator is either the version of the registered structure or an earlier version (Col. 1, lines 40-55: One important factor in the development of mobile radio systems is to ensure that each new version of a protocol is compatible with older versions.); and
the resolving the encoded data is based on internal metadata (Col. 4, lines 48-61: that the number of critical changes contained in the message be signaled right at the start of the message. Any change may in this case comprise expansions in the previous sense, or else may include removing or changing already existing elements.).
Regarding claim 15, it is a media/product type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Regarding claim 16, it is a media/product type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Regarding claim 17, it is a media/product type claim having similar limitations as claim 6 above. Therefore, it is rejected under the same rationale above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Fujita (US 7,231,591 B2) teaches “a first application program generating a first internal representation of a structured document; and an encoder module encoding said internal representation of a structured document to generate an encoded document, wherein said second computer includes: a decoder module performing validation of a structure of said encoded document by using said encoded document and a document structure definition file and by decoding said encoded document to generate a second internal representation of said structured document when no error is found in said validation; and a second application program processing said second internal representation” see at least claim 7.
Fink et al. (US 2007/0179964 A1) teaches “sending a description of a data structure from a first application to a second application; receiving from the second application an identification of at least one portion of the data structure that is requested by the second application; marshalling by the first application a subset of the data structure consisting of the at least one portion that was identified; and sending from the first application to the second application the marshalled subset of the data structure.” See at least claim 11.
Engelko et al. (US 2016/0085777 A1) teaches “executing a first application, executing a second application, and providing an access schema layer that facilitates communication between applications and a data schema layer, the data schema layer including one or more tables of a database, wherein, during a maintenance procedure, the access schema layer includes: a first access schema, the first access schema facilitating exclusive communication between the first application and at least one table of the data schema layer, and a second access schema, the second access schema facilitating exclusive communication between the second application and one or more tables of the data schema layer.” See at least Background.
Wang et al. (US 10,037,309 B1) teaches “The encoded data management operation may be structured to include a plurality of comparing operations and a plurality of carrying-out operations. The first set of bits may be compared with a mapping data structure to ascertain a first encoded text data type match. Based on the first encoded text data type match, a first application embedded encoding technique may be carried-out. The fourth set of bits may be compared with the mapping data structure (e.g., the same data structure) to ascertain a second encoded text data type match. Based on the second encoded text data type match, a second application embedded encoding technique may be carried-out.”
Forman et al. (US 7,349,934 B1) teaches “bilaterally transfer data comprising the steps of: a) mapping data between a first application and a second application, i) said first application including at least one data structure, each of said at least one data structure including: (1) a data structure identifier; and (2) at least one table, each of said at least one table including: (a) a table key field; (b) a table identifier; and (c) at least one table data field configured to store data; ii) said second application including a data grid, said data grid including: (1) at least one column, at least one of said at least one column including: (a) at least one cell; and (b) a column formula; and (2) at least one row; iii) said mapping data between said first application and said second application including the steps of: (1) associating at least one of said at least one column to at least one of said at least one table data field by: (a) identifying at least one of said at least one cell; (b) identifying a mapping function; (c) identifying one of said at least one data field; (2) associating a mapping icon with the just associated said at least one column and (3) associating said table identifier with the just associated said at least one column and b) transporting data between said first application and said application by: i) identifying a transport function; ii) identifying at least one of said at least one mapping; and iii) transporting data according to the selected said at least one mapping and the selected said transport function.” See at least claim 1.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
