Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Response to Arguments
Applicant’s arguments with respect to independent claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner withdraws 101 rejection due to added limitations that provided significantly more than the abstract idea of mere conversion through the use of a parser performing conversion within a data channel.
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.
Claim/s 1, 5, 6, 8 9, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stupachenko (Pat. No. US 10,740,217) in view of Agtneeswaran (Pub. No. US 2011/0029672) in further view of Ferrar (Pub. No. US 2022/0092062).
Claim 1, 9, 10, Stupachenko teaches “a method of container virtualization in a processor circuit, the method comprising: operating, by the processor circuit, a host operating system ([Fig. 1] host OS 145); and operating, by the processor circuit, a container in which application software is implemented ([Fig. 1] VM 150 with applications guest OS, Agent, Application 155); and wherein the processor circuit operates a logging service of the host operating system independently of the one container ([Fig. 1] debugging component 147), wherein the container or the application software implemented in the container is coupled by a data channel to the host operating system ([Fig. 1] agent connection to host OS), wherein the application software outputs at least one message regarding an operation event of the application software in a first format into the data channel ([Col. 3, Lines 30-36] The agent may be a computer application that operates as a server to the debugger (e.g., client) and may allow connections from the debugger into the virtual machine. The agent may provide basic information (e.g., raw values from memory and processor registers) to the debugger upon the occurrence of trigger events in the guest operating system. [Col. 8, Lines 36-45] The agent 156 may identify and/or detect certain triggering events of the guest OS 157 and send the information pertaining to the guest OS 157 to the debugger 148. The triggering events may include breakpoints in computer instructions executed by the guest OS 157, watchpoints in data of the guest OS 157, single steps of the guest OS 157, and so forth. The triggering events that are monitored by the agent 156 may be configurable, and the initial triggering events detected by the agent 156 may be configured by a developer of the agent 156. [Col. 2, Lines 34-41] Using virtual machines, it may be possible to utilize more than one operating system on the same computing device. A first operating system may be running on a computing device and a virtual machine may be instantiated on that computing device to run a second operating system where the first and second operating systems have differing kernel types. Alternatively, a user may use two separate computing devices that are running operating systems having differing kernel types to achieve their desired goals.), wherein a conversion unit is operated in the host operating system, wherein the conversion unit receives the at least one message output by application software via the data channel, converts the at least one message from the first format into at least one converted message having a host-specific second format ([Col. 3, Lines 32-53] (15) Additionally, one or more scripts and/or plugin additions may be used by the debugger on the first operating system to interpret incoming information related to the second operating system from the agent and convert the incoming information into user friendly output or perform certain debugging operations. For example, to support non-native system level debugging of the guest operating system, the scripts for the debugger may access the symbolic information from a symbol server associated with the kernel type of the guest operating system. The scripts may use the information received from the agent to obtain the symbolic information and convert the symbolic information into symbolic names for any labels, variables and addresses, etc. Accordingly, the scripts may enable the debugger that is not native to the guest operating system to perform one or more debugging operations for the guest operating system using the symbolic names.), and transfers the at least one converted message to the logging service, wherein the logging service logs the operation event ([Col. 2, Lines 2-8] Example debugging operations may include listing a current stack (backtrace) for an operating system, enumerating threads for a current process of the operating system, displaying information about any processor, writing internal system structures (e.g., interrupt tables, memory paging, etc.) of the operating system to memory, among other operations discussed below.)”.
However, Stupachenko may not explicitly teach a VM is a container.
Agtneeswaran teaches a “container ([0005] Virtual machines (VMs) often form the basis for executing various user applications (providing services to end users) in such environments. As is well known, a virtual machine is a container in which user applications are executed.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Agtneeswaran with the teachings of Stupachenko in order to provide a system that teaches a VM is a container. The motivation for applying Agtneeswaran teaching with Stupachenko teaching is to provide a system that allows for evidence Stupachenko VM is a container that executes applications. Stupachenko, Agtneeswaran are analogous art directed towards virtualized environments. Together Stupachenko, Agtneeswaran teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Agtneeswaran with the teachings of Stupachenko by known methods and gained expected results.
However, the combination may not explicitly teach the new limitations.
Ferrar teaches “wherein the conversion unit includes a parser that receives data output by the application software via the data channel ([0059] In the customer environment 342 within a single customer host/server 344, the LA (log analytics) agent 333 takes the log monitoring configuration data 332 (e.g., sniffer configuration or target-side configuration materials), and calls a log file 336 sniffer (also referred to herein as the “log collector”) to gather log data from one or more log files 338. [0060] The LA agent 333 sends the gathered log data to the gateway agent 330. The gateway agent 330 packages up the log data that is collected from multiple customer hosts/servers, essentially acting as an aggregator to aggregate the log content from multiple hosts. The packaged content is then sent from the gateway agent 330 to the edge services 306. The edge services 306 receive a large amount of data from multiple gateway agents 330 from any number of different customer environments 342. [Fig. 3A] Log processing pipeline as conversion unit including parser), parses the data by a message pattern that is characteristic of the at least one message in the first format ([0062] The retrieved log data undergoes a “parse” stage 312, where the log entries are parsed and broken up into specific fields. As discussed in more detail below, the “log type” configured for the log specifies how to break up the log entry into the desired fields. [0063] In the “normalize” stage 314, the identified fields are normalized. For example, a “time” field may be represented in any number of different ways in different logs. This time field can be normalized into a single recognizable format (e.g., UTC format). As another example, the word “error” may be represented in different ways on different systems (e.g., all upper case “ERROR”, all lower case “error”, first letter capitalized “Error”, or abbreviation “err”). This situation may require the different word forms/types to be normalized into a single format (e.g., all lower case un-abbreviated term “error”). [0088] In some embodiments, a log source is created by specifying a source name and description for the log source. The definition of the log source may comprise included file name patterns and excluded file name patterns.), and converts the data in the data channel with the message pattern into the at least one converted message that is transferred to the logging service ([0064] The “transform” stage 316 can be used to synthesize new content from the log data. As an example and which will be discussed in more detail below, “tags” can be added to the log data to provide additional information about the log entries. As another example, field extraction can be performed to extract additional fields from the existing log entry fields. [0066] A log writer 320 then writes the processed log data to one or more data stores 324. In some embodiments, the processed data is stored within both a text/indexed data store (e.g., as a SOLR cluster) and a raw and/or historical data store (e.g., as a HDFS cluster). The log writer can also send the log data to another processing stage 322 and/or downstream processing engine.), and wherein the parser ignores the data without the message pattern in the data channel ([0088] The file name patterns are patterns that correspond to files (or directories) to include for the log source. The excluded file name patterns correspond to patterns for files (or directories) to explicitly exclude from the log source, e.g., which is useful in the situation where the included file name pattern identifies a directory having numerous files, and some of those files (such as dummy files or non-log files) are excluded using the excluded file name pattern. For each pattern, the system captures the pattern string, the description, and the base parser (log type) that will be used to parse the file. The base parser may define the basic structure of the file, e.g., how to parse the data, hostname, and message from the file.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ferrar with the teachings of Stupachenko, Agtneeswaran in order to provide a system that teaches details of logging. The motivation for applying Ferrar teaching with Stupachenko, Agtneeswaran teaching is to provide a system that allows for design choice of capturing logs. Stupachenko, Agtneeswaran, Ferrar are analogous art directed towards virtualized environments. Together Stupachenko, Agtneeswaran, Ferrar teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Ferrar with the teachings of Stupachenko, Agtneeswaran by known methods and gained expected results.
Claim 5, the combination teaches the claim, wherein Stupachenko teaches “the method according to claim 1, wherein the conversion unit is provided as a plugin for operating software of the at least one container, and wherein the operating software routes data received from the at least one container via the data channel through the plugin ([Col. 3, Lines 37-53](15) Additionally, one or more scripts and/or plugin additions may be used by the debugger on the first operating system to interpret incoming information related to the second operating system from the agent and convert the incoming information into user friendly output or perform certain debugging operations. For example, to support non-native system level debugging of the guest operating system, the scripts for the debugger may access the symbolic information from a symbol server associated with the kernel type of the guest operating system. The scripts may use the information received from the agent to obtain the symbolic information and convert the symbolic information into symbolic names for any labels, variables and addresses, etc. Accordingly, the scripts may enable the debugger that is not native to the guest operating system to perform one or more debugging operations for the guest operating system using the symbolic names.)”.
Claim 6, the combination teaches the claim, wherein Stupachenko teaches “the method according to claim 1, wherein the logging service performs at least one of: logging ([Col. 2, Lines 2-8] Example debugging operations may include listing a current stack (backtrace) for an operating system, enumerating threads for a current process of the operating system, displaying information about any processor, writing internal system structures (e.g., interrupt tables, memory paging, etc.) of the operating system to memory, among other operations discussed below.), diagnostics, status monitoring, or privacy management”.
Claim 8, the combination teaches the claim, wherein Stupachenko teaches “the method according to claim 1, further comprising: operating, by the processor circuit or a further processor circuit, a further host operating system, wherein the further host operating system operates a further container with further application software and receives one or more messages of the further application software by a further data channel, wherein the further host operating system operates a further logging service for one or more messages in a third format, and wherein the further host operating system operates a further conversion unit that converts messages from the further data channel into the third format ([Col. 11, Lines 20-25] Further, while only a single example computer system is illustrated, the term “computer” shall also be taken to include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein. [Claim 1] 1. A method comprising: establishing a connection between a debugger native to a host operating system and an agent of a virtual machine executing a guest operating system, wherein the host operating system and the guest operating system are of different kernel types. Examiner notes, this claim is interpreted as a second computer and would be obvious to one ordinarily skilled in the art, the teachings of Stupachenko is applied to another computing system)”.
Claim/s 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stupachenko, Agtneeswaran, Ferrar in further view of Gladkikh (Pub. No. US 2020/0125533).
Claim 2, the combination may not explicitly teach the limitation.
Gladkikh teaches “the method according to claim 1, wherein the data channel includes one or more of: a standard output, STDOUT, of the host operating system, a standard error output, STDERR, of the host operating system ([0029] For the purposes of this disclosure, “standout error” (stderr) and “standard output” (stdout) are standard output streams created by the operating system between a main process running in a container and the main processes' execution environment (e.g., a container runtime). ), a port of a network interface of the host operating system, Socket, a system call, Syscall, of the host operating system, or an interprocess communication, IPC, of the host operating system that transfers the at least one message using a Shared Memory or a Pipe”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Gladkikh with the teachings of Stupachenko, Agtneeswaran, Ferrar in order to provide a system that teaches stderr. The motivation for applying Gladkikh teaching with Stupachenko, Agtneeswaran, Ferrar teaching is to provide a system that allows for design choice of capturing logs. Stupachenko, Agtneeswaran, Ferrar, Gladkikh are analogous art directed towards virtualized environments. Together Stupachenko, Agtneeswaran, Ferrar, Gladkikh teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Gladkikh with the teachings of Stupachenko, Agtneeswaran, Ferrar by known methods and gained expected results.
Claim/s 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stupachenko, Agtneeswaran, Ferrar in further view of Chadrasekaran (Pub. No. US 2022/0261306).
Claim 3, the combination may not explicitly teach a plurality of applications.
Chadrasekaran teaches “the method according to claim 1, wherein the application software is for a plurality of applications operated in the at least one container, wherein the at least one message includes a plurality of messages respectively generated by the plurality of applications ([0119] Log files 704 may be, for example, one or more system level log files, such as a syslog, event log, authentication log, kernel log, boot log, scheduled job (e.g., cron) log and so on. Alternatively or additionally, log files 704 may include application-level log files for mail services, web services, database services, and so on. These files may be stored in main memory or written to persistent storage. Generally, each of log files 704 consists of a time-ordered series of entries (e.g., text strings) written in accordance to a pre-established format. These entries may identify one or more of a timestamp, the source application of applications 702, a user of the source application, a severity, and a message. Not all entries explicitly indicate errors, but some may (e.g., when a source application is experiencing an error, it may write a message indicating the error to a log file). Further, error conditions may be inferred from a series of entries (e.g., a series of repeated log entries from a source application may indicate that the source application is unable to operate in an expected or desirable manner). Advantageously, the pre-established format for log entries may facilitate pattern matching and parsing of these entries (e.g., by way of regular expressions or finite state machines). Thus, proactive error identifier 602 may be able to programmatically determine errors from log files 704.), wherein each of the plurality of messages is generated in the first format as a host- independent standard format, and wherein the conversion unit converts the plurality of messages into the host-specific second format (Stupachenko [Col. 3, Lines 32-53] (15) Additionally, one or more scripts and/or plugin additions may be used by the debugger on the first operating system to interpret incoming information related to the second operating system from the agent and convert the incoming information into user friendly output or perform certain debugging operations. For example, to support non-native system level debugging of the guest operating system, the scripts for the debugger may access the symbolic information from a symbol server associated with the kernel type of the guest operating system. The scripts may use the information received from the agent to obtain the symbolic information and convert the symbolic information into symbolic names for any labels, variables and addresses, etc. Accordingly, the scripts may enable the debugger that is not native to the guest operating system to perform one or more debugging operations for the guest operating system using the symbolic names.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Chadrasekaran with the teachings of Stupachenko, Agtneeswaran, Ferrar in order to provide a system that teaches details of capturing log data of Stupachenko. The motivation for applying Chadrasekaran teaching with Stupachenko, Agtneeswaran, Ferrar teaching is to provide a system that allows for design choice. Stupachenko, Agtneeswaran, Ferrar, Chadrasekaran are analogous art directed towards virtualized environments. Together Stupachenko, Agtneeswaran, Ferrar, Chadrasekaran teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Chadrasekaran with the teachings of Stupachenko, Agtneeswaran, Ferrar by known methods and gained expected results.
Claim/s 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stupachenko, Agtneeswaran, Ferrar in further view of Twist (Pub. No. US 2019/0012217).
Claim 7, the combination may not explicitly teach the claim.
Twist teaches “teaches “the method according to claim 1, wherein the logging service includes a plurality of logging services ([Fig. 7] logging serves myAnalytics, Acme stats), wherein the conversion unit includes a plurality of conversion units respectively corresponding to the plurality of logging services ([0059] App 714 begins execution on Mobile Device 712, and at 758, an indication of App 714 executing is provided to Adapters Module 716. In response to this indication, Adapters Module 716 obtains a list of adapters mapped to App 714 by sending request 760, for the mappings, to Adapter Mappings Server 706 and receiving the mappings and corresponding configuration data at 762. Adapters Module 716 then obtains all the adapters specified in the received mappings by activating, at 764, the links in each adapter mapping, and in response receiving the adapters at 766. While example 700 shows only a single adapter repository, the links in the mappings can link to different adapter repositories.), wherein the at least one message includes a plurality of messages, and wherein each of the plurality of conversion units converts one of the plurality of messages addressed to one of the logging services into a particular host-specific and service-specific format required by the one of the logging services ([0012] For example, a logging adapter can be an interface that aggregates user actions identified in events into a profile and sends the profile to a log server to store or generate reports on the data. As another example, a logging adapter can be an interface to a third party analytics system such as Google Analytics®. Such a third party interface can format the event data for the third party system and transmit the formatted data. Adapters can be created, e.g., by an entity that produced the application or a third party such as an analytics provider, the open source community, etc. Where an application produces standardized events, the adapter can be a generic interface that multiple applications can use to interface with an analytics service. [0058] Example 700 begins at 750 with Client 702 making a request to Web Server 708 for an adapter management utility, in this case a web interface that provides inputs to manage the mappings in App-To-Adapter Mappings 710. Web Server 708 responds to the request by providing, at 752, Adapter Management Utility 704. Adapter Management Utility 704 includes several dropdowns that include applications the current user has specified he is the administrator of. Upon selecting an application from the dropdown, a wizard is presented allowing the user to establish mappings between that application and adapters that will work for that application. In example 700, the user has selected app1 from a first dropdown and added two mappings for app1, one to an adapter for an analytics service called myAnalytics and a second for a service called Acme Stats. The user has selected app2 from a second dropdown and has also added two mappings for app2, one for the Acme Stats service and another called Numerals. While not shown, upon selection of each mapping, a meta-descriptor for the selected adapter is obtained and the user is prompted to enter configuration data specified in the meta-descriptor. This configuration data is saved with each mapping. At 754, the four selected mappings are send to the Web Server 708. At 756, Web Server 708 stores these mappings in the App-to-Adapter Mappings 710.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Twist with the teachings of Stupachenko, Agtneeswaran, Ferrar in order to provide a system that teaches adapters. The motivation for applying Twist teaching with Stupachenko, Agtneeswaran, Ferrar teaching is to provide a system that allows for configuring logs for third part services. Stupachenko, Agtneeswaran, Ferrar, Twist are analogous art directed towards logging information. Together Stupachenko, Agtneeswaran, Ferrar, Twist teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Twist with the teachings of Stupachenko, Agtneeswaran, Ferrar by known methods and gained expected results.
Claim/s 11-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stupachenko, Agtneeswaran, Ferrar in further view of Rietschin (Pub. No. US 2021/0182078).
Claims 13, 11, 12, the combination the claim, wherein Stupachenko teaches “the method according to claim 1, wherein the application software is executed in the container ([Fig. 1] VM 150 with applications guest OS, Agent, Application 155)”.
However, the combination may not explicitly teach the remaining limitations.
Rietschin teaches “the application software performs file access to only a file system defined or determined by the container ([Fig. 1] application file access to A 141), and wherein the data channel is implemented as a file descriptor that is inserted by the host operating system in the file system defined or determined by the container as a virtual file that can be opened by the application software ([0020] For example, if the exemplary application 152, executing within the container environment 150, were to edit the exemplary file 141, as illustrated by the edit action 155, such a modification can result in a file 144, representing an edited version of the file 141, being part of the container file system 171. [0017] More specifically, and as illustrated by the exemplary system 100 of FIG. 1, the exemplary host computing environment 110 can have executing thereon a host operating system, such as in the form of the exemplary host operating system 120. As part of the host operating system 120, one or more file system drivers, filters, mini-filters, and other like file system components, generally illustrated in FIG. 1 as the host file system drivers 130, can obtain data in structured form from one or more storage media, such as the exemplary storage media 111, and can parse such data into file constructs that can be presented to applications and other processes executing on the host operating system 120. For example, an application 151, executing on the host computing environment 110 can be presented with multiple files, such as the exemplary files 141, 142 and 143, as part of the host file system 131. Analogously, a container operating system, such as the exemplary container operating system 160, can execute within the exemplary container 150. To provide for file system virtualization, however, the exemplary container operating system 160 can present different files then the host file system 131.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Rietschin with the teachings of Stupachenko, Agtneeswaran, Ferrar in order to provide a system that teaches details of file access. The motivation for applying Rietschin teaching with Stupachenko, Agtneeswaran, Ferrar teaching is to provide a system that allows for design choice. Stupachenko, Agtneeswaran, Ferrar, Rietschin are analogous art directed towards logging information. Together Stupachenko, Agtneeswaran, Ferrar, Rietschin teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Rietschin with the teachings of Stupachenko, Agtneeswaran, Ferrar by known methods and gained expected results.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199
Prosecution Insights